Yes, but with the amount of darknet markets and CSAM hidden services that have been taken down within a relatively short span of time compared to the last decade of tor’s more widespread history, it seems they may have a new vulnerability (or perhaps just a new covert post-snowden-acceptance surveillance court ruling) that allows them to identify hidden services real IP addresses. It’s speculation, but they wouldn’t use it bluntly or everyone would know there was a vulnerability and thousands more eyes would be on the tor code (or awareness of nation-state level traffic omniscience in the case of something as simple as a timing attack). A CSAM hidden service has been run by the federal governments of a few countries, so there’s no question of ethics or law in that case.
The “users” are probably the weak point. Badly configured setups leaking info, aggregation using that info to fingerprint a user, etc. When they have a user account with access they can use it to keep collecting data and digging. I imagine it’s a slow process. Nothing networked can be 100% secure though.
Edit: I’m not sure why I stayed up typing this. Maybe someone will read this comment and learn something.
I am speaking more specifically about hidden service server compromise, happening via court order if possible once the IP address is obtained through technical (not opsec issue, but perhaps parallel reconstruction) means.
Just in the last year (most last 2-4 months)… after tor DoS was ‘more fixed’ with PoW mind you… teams of government agencies have seized the following hidden services and or taken down of the teams behind them: LockBit, Hive, Blackcat/ALPHV, Ragnar, Genesis Market, xDedic, Kingdom Market, Piilopuoti, Qakbot, Skynet Market, ChipMixer, and the list goes on. I didn’t even mention all the CSAM and drug related seizures. Those are only ransomware, fraud and drug markets.
But yes /.env, /.well-known, /server-status, not verifying server ssh hash with password login in an amnesiac operating system, not running an amnesiac operating system and having multiple ssh keys (remember that GitLab fiasco)… All OPSEC mistakes an intermediate operator c(w)ould make.
Yes, but with the amount of darknet markets and CSAM hidden services that have been taken down within a relatively short span of time compared to the last decade of tor’s more widespread history, it seems they may have a new vulnerability (or perhaps just a new covert post-snowden-acceptance surveillance court ruling) that allows them to identify hidden services real IP addresses. It’s speculation, but they wouldn’t use it bluntly or everyone would know there was a vulnerability and thousands more eyes would be on the tor code (or awareness of nation-state level traffic omniscience in the case of something as simple as a timing attack). A CSAM hidden service has been run by the federal governments of a few countries, so there’s no question of ethics or law in that case.
The “users” are probably the weak point. Badly configured setups leaking info, aggregation using that info to fingerprint a user, etc. When they have a user account with access they can use it to keep collecting data and digging. I imagine it’s a slow process. Nothing networked can be 100% secure though.
Edit: I’m not sure why I stayed up typing this. Maybe someone will read this comment and learn something.
I am speaking more specifically about hidden service server compromise, happening via court order if possible once the IP address is obtained through technical (not opsec issue, but perhaps parallel reconstruction) means.
Just in the last year (most last 2-4 months)… after tor DoS was ‘more fixed’ with PoW mind you… teams of government agencies have seized the following hidden services and or taken down of the teams behind them: LockBit, Hive, Blackcat/ALPHV, Ragnar, Genesis Market, xDedic, Kingdom Market, Piilopuoti, Qakbot, Skynet Market, ChipMixer, and the list goes on. I didn’t even mention all the CSAM and drug related seizures. Those are only ransomware, fraud and drug markets.
But yes /.env, /.well-known, /server-status, not verifying server ssh hash with password login in an amnesiac operating system, not running an amnesiac operating system and having multiple ssh keys (remember that GitLab fiasco)… All OPSEC mistakes an intermediate operator c(w)ould make.
I agree 80% of it is user error and plain and simple OPSEC mistakes. SANS teaches a course on darknet OSINT and there are plenty of FOSS OSINT projects.
But tor is not foolproof even with perfect OPSEC and state actors are constantly finding ways to weaken or break it. An adversary with global passive network capabilities can and will defeat tor anonymity, as the tor projects admits itself.
Recently, there was almost a full year-long denial of service attack against tor and i2p, and it was likely a state actor identifying tor users and hidden services. Force enough connection resets, knock good guard nodes offline, and soon enough you know who’s who and where they’re connecting to with a little traffic shaping. Thankfully there is work being done to identify bad actors (PDF warning) but it IS being done.
There is much ongoing work to unmask tor users and hidden services…
https://security.stackexchange.com/questions/271828/impact-of-deep-learning-based-flow-correlation-on-tor
https://www.semanticscholar.org/paper/TIGER%3A-Tor-Traffic-Generator-for-Realistic-Lopes-Castro/f3239ef7cb3d332b96b39bad879fa7b81bbda215
https://link.springer.com/chapter/10.1007/978-981-99-7356-9_22
https://wurzel.io/Deanon-Murmur
https://dl.acm.org/doi/epdf/10.1145/3618257.3624997
Of course there is work being done to enhance tor at the same time.
https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/
https://restoreprivacy.com/torkameleon-strengthening-tor-against-deanonymization-attacks/