Are TOR Hidden Services really hidden? Demystifying HS Directory surveillance by injecting Decoys inside TOR!
•Download as PPTX, PDF•
2 likes•1,471 views
TOR (The Onion Router) is a volunteer-based distributed overlay network that allows anonymous publishing of websites and other TCP services inside the Darknet. These location Hidden Services (HS) operate under the .onion TLD & can only be accessed through the TOR network, whilst maintaining anonymity of the Visitors as well as the HS Operators. Operators run HSs for a multitude of reasons. Some Operators want their HS to be public & advertise its existence in the Clearnet, whereas many want to keep the HS’s existence as private & hidden from even regular TOR users. The research questions that arise here are, “Are TOR Hidden Services really Hidden?”, “Is someone monitoring the HS Directories for private .onion addresses?”. The main idea of this paper is to answer these questions by methodologically running private unannounced HSs (aka Onion Decoys) inside the TOR Network to detect whether there is any surveillance done on HS Directories. The Onion Decoys were implemented with docker containers as honeypots for this research. The paper details the observations made from the scanning activity done on the Onion Decoys. Keywords: TOR Hidden Services, Private Onion Decoys
More Related Content
What's hot
What's hot (20)
Similar to Are TOR Hidden Services really hidden? Demystifying HS Directory surveillance by injecting Decoys inside TOR!
Similar to Are TOR Hidden Services really hidden? Demystifying HS Directory surveillance by injecting Decoys inside TOR! (20)
More from Abhinav Biswas
More from Abhinav Biswas (8)
Recently uploaded
Recently uploaded (16)
Are TOR Hidden Services really hidden? Demystifying HS Directory surveillance by injecting Decoys inside TOR!
- 1. Abhinav Biswas *Disclaimer: The QR Code actually works. *
- 2. http://AbhinavBiswas.github.io@Abhinav_BIswas Electronics Corporation of India Limited A Govt. of India (Dept. of Atomic Energy) Enterprise Security Leader of the Year Award - 2016 by DSCI, NASSCOM Playing with Dark-Side of IOT NCSS Summit, 2017 IBM Blue Scholar, 2012CISCO Certified CyberOps, EHCE by US-Council & more… Cybernetic modeling of ICS IEEE Journal, 2015 Top 100 InfoSec Maestros 2016, DynamicCISO Security Excellence Awards etc.
- 3. The Onion Router – Gateway to Anonymity A volunteer-based distributed overlay network that simply makes you anonymous online. Conceals its users’ identity and their online activity from surveillance and traffic analysis. Used by Activists, Whistle Blowers, Journalists, Sensitive Businesses, Bloggers, Military Illicit Uses: Buying/Selling Drugs &Weapons, Silk Route, Child Pornography
- 4. It’s all about Onion Routing Layers of Encryption, Peeled off at every subsequent node Each relay node knows only which node gave it data & which node it is giving data to Separate set of encryption keys for each node along the complete Circuit No observer at any single point can tell where’s the original source & where’s the final destination DataDataDataData
- 5. Establishing The Circuit Client Server Tor Cloud Relay Tor Circuit 3 Random Relays Entry/Guard Node Middle Node Exit Node3 1 2 1 2 3 DataDataDataData Data Data Data Tor Cloud Relay
- 6. Directory Authorities – The Gatekeepers of TOR Client Server 9 Directory Authorities DA 6 Tor Cloud Relay Tor Circuit Dir AuthorityDA DA 2 DA 7 DA 4 DA 9 DA 5 DA 1 DA 3 DA 8
- 7. https://facebookcorewwwi.onion https://3g2upl4pq6kufc4m.onion The .onion domain A feature of the TOR network that allows anonymous publishing of Websites and other generic TCP services. TLDPseudonymous identifier
- 8. Sneak peek into HS Features Bidirectional Server & Client Anonymity No need to buy a Domain Name No need to have a public IP address Smear-Resistance PUBLIC HS PRIVATE HS NAT Punching Self-Authentication of the Service End-to-End Encryption Perfect Forward Secrecy (PFS) It takes hardly a minute to host a Tor HS
- 9. HS Rendezvous Protocol By Routing all communication between Client & HS through a Rendezvous Point (RP) The RP connects 2 Tor Circuits one each from Client & HS 6 Relay in Total including RP - 3 picked by Client ( 3rd being the RP) - Other 3 are picked by HS Client HS RP
- 10. HS Rendezvous Protocol By Routing all communication between Client & HS through a Rendezvous Point (RP) The RP connects 2 Tor Circuits one each from Client & HS 6 Relay in Total including RP - 3 picked by Client ( 3rd being the RP) - Other 3 are picked by HS RP HSClient Tor Cloud Relay
- 11. Tor Cloud Relay Tor Circuit Client HS HS Rendezvous Protocol HSDir 6 IP 1 IP 2 IP 3 HSDir 1 HSDir 2 HSDir 3 HSDir 4 RP Tor Cloud Relay IP Introduction PointsIP Introduction Points HS Directory AuthoritiesHSDir IP Introduction Points HS Directory Authorities Rendezvous Point HSDir RP HSDir 5
- 12. Research Hypothesis Information about all existing HSs is distributed across many Tor relays (HSDirs) Any regular Tor relay may work as HSDir Anyone who deploys such HSDir nodes can also harvest onion addresses from it The adversary may find addresses that have not been publicly shared ever Is someone monitoring the HS Directories for private onion addresses? How frequently this happens & what sort of services are targeted? Interesting to Note:
- 13. Setting up the Onion Decoy Project Run Private Unannounced HSs as Honeypots (aka Onion Decoys) inside the Tor Network Implemented with Docker Containers Composed with two popular open source honeypots: & - Glastopf for HTTP - Cowrie for SSH & Telnet Exposed three ports: Port 80 (HTTP) Port 22 (SSH) Port 23 (Telnet) Experiment Decoys Days
- 14. Lots of theory… Show me how it works. 1. Hosting Tor Hidden Service in seconds with Docker Containers 2. How to setup Honeypots (aka Onion Decoys) inside TOR Network 3. Live probing of Onion Decoys to detect intrusions by attackers
- 15. Private Hidden Services are not really hidden… Out of the 50 Onion Decoys, about 32 were revealed No SSH or Telnet traffic was detected Only port that received any traffic was the port 80 (HTTP) No SQL injection attempts were detected. 0.0000 0.1000 0.2000 0.3000 0.4000 0.5000 0.6000 0.7000 0 10 20 30 40 50 60 FractionofOnionDecoys Visited Days in experiment Any Access Browser Access Cumulative accesses of Onion Decoys as function of time
- 16. Private Hidden Services are not really hidden… Majority of the traffic came after 40 days 0 100 200 300 400 500 600 700 800 0 10 20 30 40 50 60 Pageloadsperday Days in experiment Daily Page loads of the Onion Decoys
- 17. 0 100 200 300 400 500 600 700 800 0 10 20 30 40 50 60 User-AgentwisePage loadsperday Days in experiment Any Access Tor Browser Normal Browser Private Hidden Services are not really hidden… 78% of all the http requests came from Mozilla browser About 27% of the visitors with normal browsers came to the site with referrer URL http://skunksworkedp2cg.onion ‘Peace! Harry’ User-Agent wise Daily Page loads of the Onion DecoysDaily Page loads of the Onion Decoys Majority of the traffic came after 40 days
- 18. Everything can be a Honeypot, if you don’t know it fully HSDir Operators cannot be trusted HSs would remain unnoticed only for few days with high probability The adversary is neither very systematic nor intrusive ‘Security by Obscurity’ – Not Applicable • Little-known HS Authentication Feature The more you hide, The more somebody wants to know why. https://github.com/OnionDecoy
- 19. “It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.” AbhinavBiswas@ecil.gov.in @Abhinav_BIswas
Editor's Notes
- A very good morning to all of you Gentlemen. It’s a great pleasure and delight to be here at C0C0N X. First of all I would like to thank the C0C0N team for giving me this platform to share my research on Tor Hidden Services. There’s a lot of energy, lot of vibrance and a lot of dynamism here. So, tell me, how many of you here use TOR? Or at least know about TOR. Pretty much everybody it seems. Great How many of you know about TOR Hidden Services? Good, I can see a few hands. So, today I am here to talk about the hiddenness of TOR HS. I will show how you can inject decoys or honeypots inside TOR network using docker containers to detect surveillance attacks. So, Before I begin…
- I am Abhinav Biswas, Currently, working in a Public Sector Enterprise, called the Electronics Corporation of India limited (ECIL), under Department of Atomic Energy (DAE), Government of India. Talking about ECIL we make strategic electronic products for the Indian Defense & Nuclear establishments. We have our own indigenously made routers, mass encryptors, missile fuzes, the famous EVMs etc. Recently we celebrated our Golden Jubilee year. I myself have been specialising in diverse security areas like private TOR networks, Security of Industrial Control Systems (ICS), Virtualization & Hardware security, Security in Internet of Things (IOT) etc. I have been a recipient of the prestigious ‘Security Leader of the Year Award - 2016’ by Data Security Council of India (DSCI), and have won other national accolades like Top 100 InfoSec Maestros, Dynamic CISO Security Excellence Awards etc. I also posses a couple of Certifications. I can be reached on this Twitter handle. So, without further adieu, lets start with..
- The Wikipedia page says, It’s a volunteer-based distributed overlay network that simply makes you anonymous online. It conceals your identity and online activities away from prying eyes of governments, advertisers, stalkers and even your boss. It’s used by Activists, Whistle Blowers, Journalists and lots of other people who don’t want any sureillance. Quite Obviously there’s a lot of illicit use cases of Tor too like Buying/Selling Drugs &Weapons, the famous Silk Route, Child Pornography etc. But I don’t want to focus on the dark side of TOR…Lets focus on the technology part of it.
- So how tor works, It uses layers of encryption called Onion Routing. Before a data packet is sent, it is encrypted layer by layer and every relay node in the path will decrypt one layer and send it to the next node. Such that, Each node in the path will only know its predecessor and successor, but no other nodes in the circuit. So, No observer at any single point can tell where’s the original source & where’s the final destination. One thing to note here is that separate set of encryption keys are used for each node to complete the circuit. Lets see graphically how this circuit is established.
- So, Tor sends the encrypted packets through a series of intermediate computers, called relays. These relays are located all across the world and run completely by volunteers willing to give up some bandwidth for the cause. There are about 7000 relays across the world & in India about 50. Quite less indeed. Tor client randomly chooses these 3 nodes. Entry/Guard Relay - This is the entry point to the Tor network. Middle Relay - which transport traffic from the predecessor relay to the successor relay. Exit Relay - which send traffic to the final destination. Now, Since exit relays send traffic directly to the end destination, any illicit activity done through Tor appears to come from the exit relay. Hence, there are special responsibilities to consider when running an exit node. Because it leads to the rare possibility of Police raids, abuse notices, or more. If you meet an exit relay operator - thank them. They deserve it. But how do clients know what relays are active? For this, A Master list of all Tor Relays is maintained in a Live Document called the Consensus. And this Consensus is maintained by the Directory Authorities.
- DA’s are the gatekeepers of TOR network that choose what relays are valid, and live. DA’s update the Consensus every hour by a voting mechanism. There are currently 9 DA’s whose information is hardcoded into Tor clients.
- The tor network has a very interesting feature called Hidden Services that allows anonymous publishing of Websites and other TCP services. These location Hidden Services (HS) operate under the .onion TLD & can only be accessed through the Tor network. The HSs are implemented in such a way that neither the HS learns about the actual IP address of the client, nor does the clients learn about the IP address of the HS. In fact, because no public IP address is used, one can run a HS from behind a firewall. The clients know the HS only by its pseudonymous identifier. Like facebook can be accessed over TOR HS using this url.
- Now, Tor HS provide a lot of features from the service provider’s point of view. No need to buy a domain name. Rather you can generate easy to remember domain names with a bit of computation using tools like scallion. Smear-resistance: Nobody can create a bad website and cause damage to your reputation by showing that it’s urs. NAT Punching: The clients who are behind NAT need not do any sort of port forwarding in the firewall. Self-Authentication: This onion name of a HS is actually a hash of the public key of the Server. So clients can self-authenticate the server. PFS: is built in to the encryption mechansim. Hence A compromise of long-term keys will not compromise past session keys. But, the best thing about Tor HS is it hardly takes a minute to host one. I will show this during the demo. Now, HS Operators can run HSs for a multitude of reasons. Some want their HS to be public & may advertise its existence in the Internet like Facebook does, whereas many want to keep the HS’s existence as private & hidden from even regular Tor users. So there are two types of hidden services, Public HS & Private HS Now the question that arise here are, “Are TOR Hidden Services really Hidden?”, “Is someone monitoring the TOR Netwok for private .onion addresses?” For answering this let get deeper to understand how Tor HS works
- It works by routing all communication between Client & HS through a Rendezvous Point. The RP connects 2 Tor Circuits one each from Client & the HS. This looks very simple, but actually very complicated… Lets get deeper.
- So firstly, The HS chooses 3 random relays as Introduction Points and establishes tor circuits to each one of them. The Introduction Points are listed in a record called the Service Descriptor. These are short digitally signed messages created by the HS. The HS generates two Service Descriptors and uploads them to a set of 6 responsible HSDirs. The choice of HSDirs is based on a formula and deterministically depends on the onion address and current time. The HSDirs are changed every 24 hours to prevent them from becoming a good DoS (Denial of Service) target. Now, the client who wants to communicate with the HS needs to know the list of Introduction Points. In order to get these the client first computes the list of responsible HSDirs using the onion address name, creates a circuit to one of them and fetches the Descriptors from it. Next the client chooses a random Rendezvous Point and creates a circuit to it. After that, the client creates a circuit to one of the IPs and relays the RP details to the HS over the pre-built circuit created by the HS to the Introduction Point and allows the client to begin a DiffieHellman handshake. Finally, the HS creates a circuit to the RP and complete the handshake. Huh this seems complicated now. But there are some interesting points to note here.
- Information about all existing HSs is distributed across many Tor relays (HSDirs) Any regular Tor relay may work as HSDir Anyone who deploys such HSDir nodes can also harvest onion addresses from it And may find addresses that have not been publicly shared ever So, it’s time think, Is someone monitoring the HS Directories for private onion addresses? If yes, How frequently this happens & what sort of services are targeted? To answer these I ran a project called Onion Decoy.
- The idea was to Run Private Unannounced HSs as Honeypots (aka Onion Decoys) inside the Tor Network. The Honeypots or Onion Decoys were implemented with Docker Containers. The reason to choose Docker is that it is good at process and filesystem isolation, which ultimately gives the ability to run more services on the same box instead of having to deal with resource intensive virtual machines. Also, Docker containers can easily be made very clean, containing no identifying data, which makes it difficult to get identified from outside. The containers were composed with two popular open source honeypots. So, the honeypots were listening on 3 ports. Each honeypot container was linked with a separate HS container which together created the Onion Decoy having a unique onion address. The onion addresses were randomly generated and were not announced publicly anywhere. In total 50 Onion Decoys were deployed for this experiment and they were run for a period of 60 days. The attack surface of the Onion Decoys was intentionallykept simple and low-interactive in nature because the aim was to detect automated intrusion & surveillance rather than sophisticated targeted attacks on private unannounced HSs. The result of the experiment was quite interesting. But before I share the results, lets see a demo of all this.
- How to Host Tor Hidden Service with Docker Containers How to setup Onion Decoys inside TOR Network Finally I will be probing the Onion Decoys using ELK stack to detect deliberate intrusions
- Now lets come back to the results of the Onion Decoy experiment. The graph here shows the cumulative accesses of the Onion Decoys by the adversaries. 50 Onion Decoys were run for a period of 60 Days. Out of the 50 about 32 were revealed. The first access to the Onion Decoys (represented by Red line) was usually by an automated script, which was not trying to hide its nature rather included the Curl or Wget User-Agents in the http headers. The Green line shows the time when the first Tor Browser User-Agent accessed the Onion Decoys. Now, In the regular Internet or Clearnet, the most common attack vector is targeted for SSH services. Pretty much every public server in the Internet makes a perfect target for botnets to do automated SSH brute force attacks. But, in this Darknet experiment the only port of the Onion Decoys that received any traffic was the port 80 (HTTP). SSH brute forcing attacks, which are so common on the normal Internet were not visible. Also, no SQL injection attempts were detected. It is interesting to note that, the first http request came on the 13th day after the experiment was started. This means that the unannounced HS space is either not under constant scanning, or the scanning is done with very low resources. Also, the adversary should run quite a few malicious HSDirs, to get all the onion addresses.
- This graph shows the Daily Page loads of the Onion Decoys. It clearly shows that the volume of traffic grew exponentially towards the end of the experiment. If the experiment would have continued for a longer period, the traffic might have been stabilized to some value. The observation here is that the majority of the traffic came after 40 days and 600 page loads per day is not a joke rather an indication that Onion Decoys were under the serious eyes of the adversary. And if you see the User-Agent wise Daily Page loads.
- the number of people surfing the Onion Decoys with normal browsers (represented by red color) is surprisingly high. In total, 78% of all the http requests came from the User-Agent Mozilla browser & not Tor browser. This clearly means that some of the crawlers of the adversary were faking their User-Agents, because it’s certain that normal users can’t access a HS (i.e. the Onion Decoy) with normal browsers. This also demystifies the fact that adversaries who are after hidden services are also trying to confuse their identities. One interesting thing I found was that, About 27% of the visitors with normal browsers came to the site with referrer URL http://skunksworkedp2cg.onion, which is a HS whose index page just says ‘Peace! Harry’.
- The Conclusion is simple. The experiment clearly shows that HSDirs cannot be trusted and they do surveillance & spying on new onion addresses. The HSDir Surveillance operations by the malicious Relay Operators is not very large scale but also not negligible to be ignored. Based on the results, it can be said that short-lived HSs should remain unnoticed only for a few days. Also the adversary is not very systematic nor intrusive. This is actually a really complicated topic, because there are other ways available to adversaries for learning about onion addresses apart from HSDir Surveillance, each of which has its own ethical questions around how invasive the adversary has to be. For example, the adversary can harvest them by being Verizon & spying on the root name servers or being Comcast & spying on the DNS logs. The HS operators here should understand that private unannounced TOR Hidden Services does not make much sense and should not be considered as ‘Security by Obscurity’. There is a little-known feature in Tor known as HS Authentication [8] which allows to set up a HS in an extra-private mode, only accessible by trusted clients. When activated, no one (not even the HSDirs) can derive the onion address from the descriptors. But, this process isn’t so intuitive and requires external out-of-band channel sharing of cookies to the authorized clients. So finally I would say, Hidden Services is actually a misnomer and hence tor volunteers are proposing a new name for them as onion services rather than hidden services.
- With that I would like to conclude my presentation…Thank you all. And if I’m not running out of time…I’ll be happy to take some questions from the audience.