Helping the OSINT community stay curious

Unhardened Web Servers in Tor Have No Anonymity

Hey there. This is Micah/WebBreacher and I’ve been breaking into web applications for many years now. Some of the most common suggestions I give/gave to clients was to harden their systems before placing them online. Hardening means turning off unused features, restricting access where possible, and ensuring that the web server, whatever flavour they are using, is secured using the advice in some of the checklists available online or in print (https://www.owasp.org/index.php/Secure_Configuration_Guide#2._Web_servers_misconfiguration).

Apache mod_status Information Disclosure

In 2001, Tenable’s Nessus vulnerability scanner began searching targets for the Apache mod_status information disclosure vulnerability (https://www.tenable.com/plugins/nessus/10677). Finding this issue was trivial. Using a web browser, you would make a request to an Apache web server with http(s)://example.com/server-status/. That /server-status/ part took your browser to a page that disclosed information about the Apache server. Some of the data it showed included:

Seeing this page in a vulnerability scan was always a mixed blessing. As a pentester, I always hoped that there was some sensitive content being passed in the URL parameters. This would have made the finding high risk and exciting to exploit and write up.

But usually, there were no cool bits of sensitive data and I ended up writing up a finding for the report stating that the customer needed to harden their system to prevent the low risk information disclosure vulnerability. Further, since this was a low risk issue, most places didn’t ever get to fixing these types of findings.

Into the Dark Web

Shifting our attention from the “surface web” to the “dark web”, the Tor Dark Web network focuses on keeping its users and “onion services” (sometimes called “hidden services”) anonymous. It should be challenging to figure out a certain onion service’s, like a web server running in Tor, IP address and research it on the surface web. The Tor layer is supposed to protect against that.

But what would happen to an anonymous onion service running in the dark web if it was running the Apache web server software and had the mod_status module enabled running? Let’s find out!

The above Fresh Onions URL will take you to a place on their site that displays Tor onion services that have the mod_status module enabled and where you can visit the http://ONIONADDRESS/server-status/ and see details about the server running the Tor service.

Higher Risk Finding

When we were looking on the surface web for systems that had this mod_status enabled, viewing the information about the IP address of the server, virtual domains it hosted, and submitted content was mostly a low risk, information disclosure finding. Here in the dark web, things are different. Let’s take a look at why.

The http://eplckll7rbvdupln.onion/server-status site is reachable from Tor using that onion service name as you can see at the “1” in the image below. When we look at the “2” in the image, we can see several other domains FROM THE SURFACE WEB that are also running on that system!

mod_status Server Status page from Tor onion service showing surface web hosts running on the same system as a Tor onion service

Looking at the other numbers (3, 4, and 5) in the above image, we can see other important information such as what operating system the server is running on, what client addresses are (for the surface web connections), and parameters that are being passed to the server (respectively).

This is amazing insight into an onion “hidden” service! We have leads to pursue on the surface web since those other domains are being hosted from the same computer.

mod_status Server Status page from Tor onion service showing multiple services running on the same system

But wait….there’s more! Introducing mod_info!

There happens to be another Apache web server module that should be turned off during hardening but is sometimes forgotten about. This is mod_info and it shows what modules are configured on the web server and information about the server’s configuration file. What if….what if this module was also enabled on a Tor server? It would be devastating to the anonymity of the server. Why “devastating”? Check this out.

The http://lchuditewd4ltjti.onion/server-status server (shown below) has the mod_status module enabled and we can see its output below. Nothing new here. In fact, we don’t see any other onion services or surface web hosts running on this server.

mod_status Server Status page from Tor onion service

Couple this with the mod_info disclosure issue (http://ONIONADDRESS/server-info) and we can rapidly see why it is so destructive to the Tor service’s anonymity. We visited the info page at http://lchuditewd4ltjti.onion/server-info and saw the information below: 1 – operating system data; 2 – Tor service address; 3 – Path installed in on the server.

OK. That is interesting but….so what? Keep scrolling down this page and you get what is in the image below.

mod_info Server Info page from Tor onion service showing multiple onion services configured on the system

The above graphic shows that this server, on which we had only seen a single Tor onion service running, is configure to host over 10 other hidden services! Now THAT is helpful for our investigation!

Below is a different server-info page from the http://w56m67cjc6f3qyet.onion/server-info system. This one contains operating system path data and an entry to who the “server administrator” is (we blurred the email address). There are other email addresses noted in this file too.

Wrapping It Up

Again, if properly configured, the mod_status and mod_info modules would be disabled or restricted to an admin. Since they are not, we can read files on the Tor hidden/onion services that we should not be able to read and consume the data that de-anonymizes the systems; tying them to other surface web hosts and emails we can now research using traditional, surface web techniques.

Like this:

Related

3 thoughts on “Unhardened Web Servers in Tor Have No Anonymity”

I’m impressed, I have to say. Actually not often do I encounter a blog that’s both educative and entertaining, and let me let you know, you will have hit the nail on the head. Your concept is excellent; the problem is something that not sufficient individuals are talking intelligently about. I am very completely happy that I stumbled throughout this in my search for something regarding this.

If I find multiple domains in /server-status does it actually mean that the server is running those domains? It happened that I found several domains on the same server but they resolve to different IPs. And /server-info is disabled.

I could mean that. What is truly means is that the server is configured to think that it runs those other domains. DNS does not have to support this. For instance, I set up my web server to have a section for the virtual domain google.com. If the server gets a request for google.com, it will know how to handle it. However, DNS for google.com will not resolve to my system because I don’t own that domain.

What else could this mean? Maybe someone copied the configuration file from another system that ran the virtual domains. Maybe they are planning an attack where they will hijack the DNS or routes for a certain domain. Maybe it is just an old config file and the system used to host those domains. — MIcah