Sensitive Information Can Be Revealed From Tor Hidden Services On Apache (dailydot.com) 37
Patrick O'Neill writes: A common configuration mistake in Apache, the most popular Web server software in the world, can allow anyone to look behind the curtains on a hidden server to see everything from total traffic to active HTTP requests. When an hidden service reveals the HTTP requests, it's revealing every file—a Web page, picture, movie, .zip, anything at all—that's fetched by the server. Tor's developers were aware of the issue as early as last year but decided against sending out an advisory. The problem is common enough that even Tor's own developers have made the exact same mistake. Until October 2015, the machine that welcomed new users to the Tor network and checked if they were running up-to-date software allowed anyone to look at total traffic and watch all the requests.
If you take 3 different steps to conf it public (Score:1, Informative)
First, the server admin would have to enable mod_status.
Then, by default it's visible only from the server itself - the physical console or an ssh connection.
Than to see the request urls, you have to turn ExtendedStatus on as well.
It's easy to miss one of these steps when you're TRYING to turn it on. If you're offering a hidden service, it seeme rather unlikely you'd work so hard to gather and publish extended status.
Re: (Score:3, Insightful)
I think that a hidden service sees incoming traffic as originating from itself, as that's where the TOR node is that unwraps this traffic.
On my server, it was turned on despite me not turning it on (but, of course, not open to the outside). I don't know why, BTW.
Shachar
Re:If you take 3 different steps to conf it public (Score:5, Informative)
First, the server admin would have to enable mod_status.
Then, by default it's visible only from the server itself - the physical console or an ssh connection.
Than to see the request urls, you have to turn ExtendedStatus on as well.
It's easy to miss one of these steps when you're TRYING to turn it on. If you're offering a hidden service, it seeme rather unlikely you'd work so hard to gather and publish extended status.
I just spun up a brand new Debian 8.2 VM instance, apt-get upgraded it to current, and apt-get installed apache2 - everything current as of 10ish minutes ago.
root@dev10:~# ls -l /etc/apache2/mods-enabled/status* /etc/apache2/mods-enabled/status.conf -> ../mods-available/status.conf /etc/apache2/mods-enabled/status.load -> ../mods-available/status.load
lrwxrwxrwx 1 root root 29 Jan 30 21:58
lrwxrwxrwx 1 root root 29 Jan 30 21:58
root@dev10:~# grep -i extended /etc/apache2/mods-enabled/status.conf
# Keep track of extended status information for each request
ExtendedStatus On
root@dev10:~# grep -i location -A 2 /etc/apache2/mods-enabled/status.conf /server-status>
<Location
SetHandler server-status
Require local
Both mod_status and the extended status mode are enabled by default.
Yes they are restricted to localhost only, however if one ran apache and a tor proxy on the same machine, the tor proxy would be connecting to apache over localhost and so would be allowed.
Being a debian config I would assume many debian based systems may very well have this same default config.
Looking at the first example screenshot in the article, it explicitly shows it to be apache 2.2.16 running on a debian system. That means the server came setup that way and the owner didn't disable it.
I can't speak for other distros or what the defaults are when apache is compiled from original sources and what not.
But I would certainly recommend at least looking through your 'mods-enabled' dir Just In Case (tm)
How is this in any way surprising? (Score:1)
The only way that three people can keep a secret is if two of them are dead - and even then ....
Experience has shown time and time again that there will never be perfect secrecy - just "good enough for now" is the best we can hope for.
Re: (Score:2, Interesting)
The only way that three people can keep a secret is if two of them are dead - and even then ....
Even this is no longer true. :(
-
Experience has shown time and time again that there will never be perfect secrecy - just "good enough for now" is the best we can hope for.
Worse yet is that what is secret today will be exposed tomorrow, or the next day, or the day after that. All that stuff people have encrypted or hidden will eventually be decrypted or dragged out into the light. "You can bet your ass it'll come to pass", as they say. And it will.
So you're using SuperUber-Blowfish-SupperDish crypto with a 40 garjillion-bit key? Yeah, that'll be good for a while, but not forever. Quantum-computing may in fact herald an end to meaningful encrypt
Re: (Score:1)
If you have AES-256 encrypted information on a cold drive, nothing short of a successful cryptanalysis or your nation's favorite Enhanced Torture Techniques will reveal that information.
Quantum computing is not magic, and defeatism will get you nowhere. Grow some fucking willpower.
Re: (Score:2)
Weaknesses are found constantly.
AES is great now, because it's been focused on and studied by the best cryptographers on the planet, yes. But nothings to say a shortcoming won't or can't be found in the future. How likely is that? Who knows. But never say never.
DES was the Gov't's go-to for encryption for years and years. It ended up needing to be replaced not because of a key length that suddenly made it more vulnerable to brute force attacks (that could have been remedied), but because cryptanalysis had f
Re: (Score:2)
For now. Algorithms that seemed great at one point eventually become broken or successfully analyzed.
DES stood up for a while, but computing resources overwhelmed it.
MD5 was great until people learned it was flawed.
same thing is happening now for SHA-1.
True, the later two are for hashing rather than encrypting, but something that seems utterly unbreakable today could be economically broken tomorrow, if an unthought of technique is discovered.
That's not defeatism, it's just being clear that everything *event
Server Misconfiguration is news? (Score:3)
You hit the nail on the head! (Score:3)
Literally, because exactly this is the problem here,
As a person visiting a web-site your communication with the webserver is actually comming from the localhost, leaving no way to distinguish for the webserver between a sysadmin and a normal visitor.
.. visiting a web-site running as an onion ser.... (Score:2)
..vice, your communication is actually comming from localhost ..
Re: (Score:2)
Ah, I did wonder if this was a case of "exiting from a TOR tunnel means the traffic is coming from 127.0.0.1".
To be honest that means TOR is breaking a lot of expectations about localhost. Really they ought to use some RFC1918 address space for that final hop.
Still, as-is, you could reconfigure /server-status to only be allowed from your actual local IP (and any other safe IPs), and not include localhost in the list.
Re: (Score:2)
Actually, when you configure a hidden service on Tor, you have a choice of where the traffic coming out of the tunnel will go. You can send it to any address on the host, or even to another host.
But it's easy to forget that 127.0.0.1 isn't necessarily the best choice. And, worse, the Tor project's example configuration uses it.
It's actually usually better to run the server on a separate machine from the Tor process, anyway, for a lot of reasons.
Summaries for Nerds (Score:5, Informative)
disable or restrict access to mod_status if you run a tor hidden service on Apache because mod_status is often enabled by default and serves to localhost; tor connects from localhost. mod_status shows some details of current requests which could leak info on other users.
Vote_insightful (Score:2)
You Sir, should be part of the "compress" interface!
You get what you pay for. (Score:1, Funny)
I only trust Microsoft IIS and ASP.Net for my web hosting needs.
Suggestion for editors (Score:2)
Re: (Score:2)
... or using "like" instead of "such as".
The suggested fix (Score:2)
FTA:
$ sudo a2dismod status
Why?
Apparently some distros turn stuff on by default [allanfeid.com].
That's why I'm a huge fan of the "secure by default [openbsd.org]" philosophy.
don't setup hidden services (Score:1)
Don't setup hidden services if you aren't a competent sysadmin. Really. If you don't know what you are doing and how to disable various headers etc etc, you'll be fucked. Crap like that was how silk road got taken down too(not by server status, but another page or something that showed some real IPs)
You really need to check everything that your server sends out and make damn sure there are no information leaks. No real hostnames, IP addresses etc etc.
*headdesk*
Localhost (Score:4, Insightful)
Re: (Score:2)
Yep. the loopback address is just it. An IP on one interface, which just loops back.
0.0.0.0 means ANY ip.
try it. let a tcp server listen on 10.0.0.x (lan interface) and lets say port 8080 then do:
$ nc 0 8080
you get a connection. without specifing the interface or ip on the interface.
$ nc 10.0.0.x 8080
you get a connection again
$ nc 127.0.0.1 8080
no connection
Bullshit article (Score:2)
Everybody who configures a webserver decides if he wants a status page. Normally you disable it in production and with tor you disable EVERY feature you do not ABSOLUTELY NEED. Thats just common sense.