talk to our next spy unit. So let's give him a big DEF CON 30
welcome. Hello, everyone. My name is Jonas Cernica and I will
presenting the anonymization of Tor HTTP hidden services. So I
will have an introduction about Tor, then I will speak about
known de-anonymization techniques, then how downgrading
the HTTP protocol can leak the IP, other techniques developed
by me, then how to fix these issues because it's configuration
issues, then demo time and closing remarks. Who am I? I'm
an application security engineer and I'm working for UiPath.
This is my own research, personal research. CTF player,
PhD student, security researcher, former bug bounty
hunter, and former entrepreneur.
The only 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. The hidden
service allows 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.onion
for your hidden service. Known de-anonymization techniques are
server status, key certificate, another de-anonymization
technique is search for the onion address or the gzip deflate. This is not an de-anonymization
technique. It helps you to make a, I don't know, 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 an Apache web, Apache 2 web
servers. And when you go to server status, maybe they didn't disable because it's enabled by
some 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
onion address on the internet and you can search on certain engines like Google, Bing, DuckDuckGo or
showdown. It deserves a try. The gzip compression, it's about the same as the gzip compression.
The one thing about, to, it gives you an idea where the server is located and Jose Carlos found it and
he said that around ten percent of the web servers link the remote data when compresing the HTTP
responses. The five icon is that tiny icon from the URL bar and it is possible to make a hatch of it
then try to search it on showdown. But make sure that you keep this information on site so that you can
maybe some other website is using and an example for this is the quantum ransomware group which
were down on tour because they used the favicon on the internet and Talos found it's
equivalent on the internet. Or hack 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
down in 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 400 bad requests and in the user agent was my scan and
for more information it gave me a website where to go and read more information about this scan.
So I'm going to show you how it works. So I'm going to show you how it works. So I'm going to
show you how it works. So I'm going to show you how it works. 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
request 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 host was publicly revealed
in the response server. And this was I realized that this would 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 on Apache based servers like Apache 2
NGINX or Tomcat. It's all about configuration. The server must choose one of the domains to
forward the request. So the server must choose one of the domains to forward the request. So the
server will choose the first 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 requests, 403 forbidden or even in 404 not found some kind of
error 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 NGINX 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.HTML. So it's a 403 forbidden. We have that server at
most of the time. So it's a 403 forbidden. We have that server at most of the time. So it's a 403 forbidden.
So it's a 403 forbidden. We have that server at most of the time. So it's a 403 forbidden. So it's a
501 forbidden. We have that server at most of the time. So it's a 501 forbidden. We have that
network. And, in resulting the three steps is to encounter all of theiosity and the
with a long URL, like the university from Germany
I 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 403 forbidden is triggered when you visit something
with slash.ht, that's because the default configuration
file of Apache tries to protect files like htaccess
or htpassword, so you can easily trigger this 403 forbidden,
and you downgrade the protocol, remove the host header,
then you have the server app with something in there,
maybe a local host or something that doesn't help 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 exits on the root of the server,
it 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're not,
and you don't have directories,
but you can use the predefined directories
from a patch 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 the internet,
maybe you can find it,
but you can't find important information.
If you are a sysadmin, 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 exfiltrate domains
that normally you cannot get from an IP.
It's kind of DNS reverse.
Another technique, it would be the e-tag.
e-tag 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 e-tag,
you can see I make a request on the first page,
on the slash,
and the server respond with the e-tag,
and it's a unique value.
You should not find this on a web page.
You should find it 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, you try to, to anonymize 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,
with each one at a time,
with the, which, with the,
every onion address from your list,
and maybe one of them will response
as you would, you would request at that onion.
So, this implies, this can help you
to increase the, 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 put the demo.
At the end of the demo I have something very,
very unimpressive finding,
so right now, I'm trying to access on h-t,
anything to see that I can trigger the 400 and
a free forbidden,
but I have HTTP 1.1 with the host header
of my onion address and Tor.
Now, if I remove the host header,
ah, okay now I'm, I'm showing a DIAC address.
you that I don't want to make a lot of noise so I put a dot HTML. Not 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 is
publicly available. You can come from the Internet on it and you can disclose its IP. Now I'm
trying to trigger a bad request by putting a long header. So I put a long header to trigger the
400 bad requests. And the response will be the same server at and the address. So the server at
hidden domain dot ML. Another technique is this. I'm trying to trigger a bad request by putting
a long header. And another technique is this. I'm trying to trigger a bad request by putting a long
header. So this is a red direct technique. So the CSS directory 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 one dot one protocol with a host header, it redirects me to the one address. So
nothing was leaked. If I remove the line and I don't read the protocol. Now I'm in a run in the
now in the response again we have the domain leaked. So hidden domain.ml. Right now what
I can do, I'm going to find out more about this domain. Let's take its 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 is really hosting the
Tor hidden service. So I'm looking at the ITUG. I came from the internet and it has
an ITUG. I'm going back to the Tor network in the next few seconds. You'll see that
that it has the same etag.
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 configured the hidden domain dot ML,
so this is another configuration.
I configured the hidden domain in front of,
so I have 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 try to, even 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 is not a problem in Apache 2 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 a 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 a long header,
and let's see what's happening.
Look, I just leaked my IP address.
So now, maybe, it's open for direct request,
I don't need the Cloudflare anymore.
No, no.
So, in conclusion, triggering bad requests,
or 403 forbidden and so on,
maybe, it 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.