 I'm talking our next is by unit. So let's give him a big DefCon 30. Welcome. Come on. Hi everyone. My name is Jonas Cernica. And I will be presenting the organization of Tor HTTP hidden services. So I will have an introduction about Tor. Then I will speak about known the organization techniques. Then how the Http protocol can leak the IP. Other techniques developed by me then how to fix these issues because it's a configuration issues. Then demo time and closing remarks. Who am I? I'm an application security engineer. I am working for UiPad. This is my own research, personal research. City of player, PhD student, security researcher, former bug bounty hunter and former entrepreneur. The onion router known as Tor helps you to anonymize on the internet and helps you to reach the dark net where you can find the hidden services. And that URL that ends in onion, dot onion. The hidden service allow users to publish their services and it hides their identity on the internet, on the Tor network and the internet configuration. A basic configuration is when you declare a service directory where the Tor configuration files will go then the service port for the network. Then when you restart the service you will have a URL like a long URL, dot onion for your hidden service. Known the anonymization techniques are server status, key certificate, another the anonymization technique is search for the onion address or the gzip deflate. This is not the anonymization. It helps you to make an idea where the server is located in which country. File icon hash and if you are skilled enough maybe you can hack the server. So the server status technique implies to, it's only on a Apache 2 web servers. And when you go to server status maybe they didn't disable because it's enabled by default on web servers like on the Apache web servers. And maybe on the virtual host you'll find the public IP or public domain which you can visit and see on the server status of the Tor hidden service. The key certificate implies that you can take parameters like serial number or so on and you can look for them on showdown which indexes information from the internet including the TLS information like serial number. And maybe you can catch the, maybe the hidden services use the same TLS certificate on the internet and you can make a match. You also, okay it's not a big chance of success but you can search for the online address on the internet and you can search on search engines like Google, Bing, dot, dot, go or showdown. You deserve a try. The gzip compression, it's about to give you an idea where the server is located and Jose Carlos found it and he said that around 10% of the web servers leak the remote date when compressing HTTP responses. The five icon is that tiny icon from the URL bar and it is possible to make a hash of it and then try to search it on showdown. Maybe some other website is using and an example for this is the Quantum Ransomal Group which were down on Mystone Tor because they used the five icon on the internet and Talos found its equivalent on the internet. Or heck the servers with remote command execution local file or make a research on the server maybe you'll find something that leaks the IP. So downgrading the protocol, how did I find this? Some strange requests were in my access logs. Something like get slash not found along, not found, not found, not found exactly like this and it ends with HTTP 1.0, the protocol with a 400 bad request and the user agent was Muscan and for more information it gives me a website where to go and read more information about this scan. So when I entered on that website it was about the university from Germany which they said they scan all the internet and they tried to find something they didn't reveal what they were looking for but this behavior keep coming for days on my server. Also I was seeing this behavior on my honeypots and I was thinking to dump the whole request to see what's going on there because it's strange to see such a quest and what they are looking for. So when I dumped their request, the whole request I was thinking they have an exploit in the header and the access log doesn't have the parameters in headers in the log file. I replicated and I saw that one of my virtual hosts was publicly revealed in the response server and I realized that this have a big potential on Tor or even in the internet because you can find unknown or unpublished domains, virtual domains from an IP. So why this behavior? So it's not a security problem in Apache Bits based servers like Apache 2 and Genix or Tomcat. It's all about configuration. The server must choose one of the domains to forward the request. So if you downgrade the protocol to one dot zero you don't need the host header anymore and you can erase it from your request. So the server will choose the first virtual domain from the configuration file and in the response you'll find the IP or maybe something that doesn't help you, maybe local host. So the leak is in the trigger exceptions like 400 bad request, 400 free forbidden or even in 400 and four not found sometimes. But the best way to leak the IP is in server redirects. You have to trigger a redirect on the server on something else. And this is working on Genix, Apache 2 and Tomcat and it's very easy to trigger a redirect on every server. Now I just want to show you how the response is when we try to go to slash dot HTML. So it's a 400 and free forbidden. We have that server at my onion domain. It's a big one and dot onion in the end. And if I remove the host header and I downgrade the protocol now I have my IP leaked. So I just leak my IP. With 400 bad request long header via long header if you put a long header enough you trigger the bad request. And as well we have the IP address in the response server at my real IP address. Again, the result with a long URL like the university from Germany said earlier they did with the long URL. It's triggering a bad request. Maybe that's why I don't know. Maybe that's why they were doing this. Or a file upload that exceeds the server limits. There are other ways to do that to trigger a bad request. You just have to find other ways. The 400 and free forbidden is triggered when you visit something with slash dot ht. That's because the default configuration file of Apache tries to protect files like ht access or ht password so you can easily trigger this 400 and free forbidden. And you downgrade the protocol, remove the host header then you have the server at with something in there. Maybe a local host or something that doesn't helps you or the public IP maybe. The server redirects, the best way to trigger, the server redirects is the best way to find out the primary virtual host. And an example is like if you have a directory that exists on the root of the server you can try to visit it without the last slash and the server will auto redirect to the same directory but with a slash at the final. So in most cases you can find a directory on the first HTML page of the web server. Maybe you are dealing with an API server and you don't have directories but you can use the predefined directories from Apache server like CSS, icons, GS and these directories are available only if you visit from the local host IP. And in tor most of the hidden services are visited with the local host. To trigger the redirect look at the, as I said, you look on the source code of the HTML you find the directory like CSS in this case and then you try to trigger the redirect like get slash CSS without the last slash. The server tries to correct this and puts a slash at the end but redirects to your virtual host, the primary virtual host because I already downgraded the protocol. So applying this on internet maybe you can find important information if you are assist admin you have to be careful how you configure your virtual hosts. I didn't make a research on this because I don't know I'm at the limit of legality. It appears that others did this before but I don't know if they followed this problem with the downgraded of protocol. So I expect to explain domains that normally you cannot get from an IP. It's kind of DNS reverse. Another technique which would be the itag from the response header you can take its value and if the first page is a static page maybe you can look for it on the showdown search engine. Another, an example of itag you can see I make a request on the first page on the slash and their server respond with the itag and it's a unique value. You should not find this on other servers only if the same, it's a, I don't know, it's a VMware image or something. Other techniques, same network techniques implies that you have an onion, you try to de-animize it, you didn't find anything but you have a list of all the onions, all the ones, a lot of onions from the Tor network and you try to replace the host header with each one at a time with every onion address from your list and maybe one of them will respond as you would request that onion. So this implies, this can help you to increase the attack surface. You don't need to attack the first onion, maybe you can try to de-anonymize the second one. So right now I'll put the demo. At the end of the demo I have something very unimpressive finding. So right now I'm trying to access an HT anything to see that I can trigger the 403 forbidden but I have the HTTP 1.1 with the host header of my onion address on Tor. Now if I remove the host header, oh okay, now I'm showing you that I don't want to make a lot of noise so I put a dot HTML, not a really big URL like not found, not found, not found how others did. And if I remove the host header and I don't read the protocol you can find a hidden domain on my web server. And maybe that domain it's publicly available, you can come from the internet on it and you can disclose it's IP. Now I'm trying to trigger a bad request by putting a long header. So I'll put a long header to trigger the 400 bad requests and the response will be the same server at and address. So the server at hidden domain.ml. Another technique is the, as I said, is the redirect technique. So the CSS directory should be should be available by default on Apache servers but only if you visit it from the local host. And right now if I visit with my HTTP 1.1 protocol with the host header it redirects me to the onion address so nothing was leaked. If I remove the line and I don't read the protocol now in the response again we have the domain leaked. So hidden domain.ml. Now right now what I can do it I'm going to find out more about this domain. Let's take it's IP address, make a who is on it and maybe it's public from the internet. That's what I'm trying to do right now. And after that I'm trying to see if this public address it's really hosting the Torhiden service. So I'm looking at the eTog. It responds from the, I came from the internet and it has an eTog. If I go, I'm going back to the Torh network in the next few seconds you'll see that it has the same eTog. And in the end I will show that the server status will show me that there is the same server for this onion and the IP address I visited. Okay I'll go to the last demo it's from here. So right now I configure the hidden domain.ml so this is another configuration. I configure the hidden domain in front of, so I have the in front of hidden domain the cloudflare. So I'm trying to leak the IP address of a cloud domain of a cloudflare domain. So I just tried to, even I don't, I don't downgrade the protocol for the long header exception just for the long header exception it will serve me the first virtual host from the configuration file. So I can leak the IP address of the server which is protected by cloudflare. This is not a problem in cloudflare. It's just a problem on the configuration. Either it's not a problem in apache to server. It's just a problem in the way we configure the virtual host of our web servers. So right now I'm trying to insert the long header and we'll see what's happening. This is a default configuration. So I installed apache, I put cloudflare, then just I put a virtual host and then I just send the long header and let's see what's happening. Look, I just leak my IP address. So now maybe it's open for direct requests. I don't need the cloudflare anymore. No, no. So in conclusion, triggering bad requests or 403 forbidden and so on maybe can leak the IP address of your apache server. You have to choose very carefully what virtual host you configure. Even on cloudflare, this doesn't help you. It's not a problem in cloudflare. It's a problem in how you configure the virtual host. Try to not reuse the certificates from other projects and disable the server status when you give access to other persons to access your server from local host. And thank you. I'm waiting for your questions. Thank you.