Slashdot Mirror
Sensitive Information Can Be Revealed From Tor Hidden Services On Apache (dailydot.com)
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.
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.
This is simply server misconfiguration. I can't comment on other distributions but Debian at least restricts /server-status URL access to localhost by default. You'd have to explicitly change this to allow from anywhere else.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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 encryption, we just don't know how much it'll change things but the smart money is on major upheavals in supposedly "secure" communication.
During WWII the Allies kept reams of intercepted communications from the German and the Japanese (and everyone else) even though it was encrypted and unreadable....because they knew that someday they'd be able to decrypt it and see what was being said. It has enormous potential military and political value even if you can't read it today.
The NSA is, or course, doing the same thing right this minute, archiving everything they can get their sticky little fingers on. They may not be able to decrypt it today, but eventually they'll be able to.
Just cruising through this digital world at 33 1/3 rpm...
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.
I only trust Microsoft IIS and ASP.Net for my web hosting needs.
You Sir, should be part of the "compress" interface!
..vice, your communication is actually comming from localhost ..
When your looking at an story, Ctrl + enlarges the text making it easier to spot typos.
Brought to you by Carl's Junior.
FTA:
$ sudo a2dismod status
Why?
Apparently some distros turn stuff on by default.
That's why I'm a huge fan of the "secure by default" philosophy.
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.
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*
I always thought it seemed kind of foolish to run the web service and the tor node on the same system. Seems like it would be better to run the tor node on its own system and act as a gateway for the web server (with all appropriate firewall rules to prevent server from talking to anyone besides tor node) This would not only prevent this kind of attack where local host traffic is semi trusted. But perhaps more significantly it would prevent the webserver from ever leaking it's public address as it can't know what it is. My 2 cents
Technology, the cause of and solution to all of life's problems.
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.
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 *eventually* has shortcomings. No use trying to pretend otherwise!
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 found methods of attack against it that were more efficient than brute force attacks.
https://en.wikipedia.org/wiki/...
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.
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.
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