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.

Comments

How is this in any way surprising?

[BarbaraHudson]

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:How is this in any way surprising?

[JustAnotherOldGuy]

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.

Re:How is this in any way surprising?

[Anonymous Coward]

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: How is this in any way surprising?

[Anonymous Coward]

You have no idea what the gp is talking about. Just another short sighted unthinker is all you are. In 100 years everything being encrypted today will be able to be decrypted on even the most pathetically low end computer system in a matter of seconds or faster. Unfortunately it seems very few people actually think about the real future. True that almost anything being encrypted today and unencrypted in 100 really won't matter to anyone as most of us won't be alive but it could still damage a government if it comes to light they were really as bad as the conspiracy theories claim they are.

Re: How is this in any way surprising?

[Anonymous Coward]

AES-256 is protected by the laws of physics. It doesn't matter how fast a computer is in the future; you would be hard pressed to gather enough energy from the entire universe to power it long enough brute force the key. The only way AES-256 is getting decrypted is if someone discovers a weakness in the system itself.

Re:How is this in any way surprising?

[Anonymous Coward]

If you have AES-256 encrypted information on a cold drive, nothing short of a successful cryptanalysis

Stopped reading there. If you are NSA, that's not entirely an unreasonable gamble.

You're right that the laws of physics protect AES-256-encoded data. It is unknown to the general public whether the laws of mathematics offer similar protection. And even if they do, it is unknowable even to the NSA as to whether the laws of mathematics will continue to do so indefinitely.

Which is why the intelligence community hires lots of clever mathematicians to do the research. In the meantime, until every cryptographic system is broken (i.e., until forever), it's cheaper to archive everything in the event that at some point in the future a breakthrough in cryptanalysis will enable the decription of some of it. Some systems will be broken. Some systems will not be broken. If you knew in advance which systems those were, it wouldn't be called research.

At least I think that's what the other AC was trying to say. There's no magic that we know of. There's no reason to believe that quantum cryptography will turn into magic. But there are an awful lot of bugs in an awful lot of software around the world, and a bug that reduces the complexity of an attack under certain scenarios could conceivably be indistinguishable from magic. (The canonical example being differential cryptanalysis, a technique that was unknown to the general public, during the development of DES.)

Re:How is this in any way surprising?

[um... Lucas]

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!

Re: How is this in any way surprising?

[um... Lucas]

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/...

Re: How is this in any way surprising?

[Anonymous Coward]

Except DES was suspicious from the start: see the history section on that same page. The NSA made a change that only much later did anyone else know made it stronger... but at the same time reduced the key length. The NSA knew DES's shortcoming before it became a standard and intentionally designed it to be hard for anyone else to crack while being possible for them to (unclear if they actually had the computer power initially).

Re: How is this in any way surprising?

[Anonymous Coward]

What the? I didn't say never. I clearly said "if someone discovers a weakness in the system itself"
My post was simply to counter the idea that AES is similar to something like RSA where all you really need is faster and faster computers to break it. It is not possible to break AES through brute force calculations no matter what kind of computer you have.
The DES example you pulled up shows exactly why. DES had a key length of 56 bits; that's only 7x10^16 keys.... put another way, if every person on earth tried 10,000 keys we could do the entire key space.
AES 256 has a key space of 256 bits 1x10^77 in order to brute for that you would have to gather up every atom in the universe and then have each individual atom perform a calculation. Not possible.

If you enable the status page...

[Anonymous Coward]

Apache shows the status page. Wow, really?

This was big news in 1996 when I first remember reading about it before /. even existed.

If you take 3 different steps to conf it public

[raymorris]

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:If you take 3 different steps to conf it public

[Sun]

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

[Anonymous Coward]

Because it's on by default and the GP poster doesn't know how to read the article and thus posted a factually incorrect post while trying to look like a know-it-all.

In short: You got duped by him.

Re:If you take 3 different steps to conf it public

[dissy]

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*
lrwxrwxrwx 1 root root 29 Jan 30 21:58 /etc/apache2/mods-enabled/status.conf -> ../mods-available/status.conf
lrwxrwxrwx 1 root root 29 Jan 30 21:58 /etc/apache2/mods-enabled/status.load -> ../mods-available/status.load

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
                <Location /server-status>
                                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)

Server Misconfiguration is news?

[Athanasius]

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.

Re:Server Misconfiguration is news?

[Anonymous Coward]

Tor runs on the localhost address of the server.

Summaries for Nerds

[bill_mcgonigle]

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.

You hit the nail on the head!

[burni2]

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.

You get what you pay for.

[Anonymous Coward]

I only trust Microsoft IIS and ASP.Net for my web hosting needs.

Vote_insightful

[burni2]

You Sir, should be part of the "compress" interface!

.. visiting a web-site running as an onion ser....

[burni2]

..vice, your communication is actually comming from localhost ..

Suggestion for editors

[wjcofkc]

When your looking at an story, Ctrl + enlarges the text making it easier to spot typos.

Re:Suggestion for editors

[Anonymous Coward]

Or even outright grammar errors, like using "Your" instead of "You're."

Re:Suggestion for editors

[93 Escort Wagon]

... or using "like" instead of "such as".

The suggested fix

[nuckfuts]

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.

don't setup hidden services

[Anonymous Coward]

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

[SlayerofGods]

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

Re:Localhost

[Anonymous Coward]

Isn't the issue that it is leaking user-IP data? A user who goes through Tor though wouldn't be impacted, short of typing in something to a miss configured search engine running Apache something like "my name is x and i want to do y". Where x is the persons name and y is something illegal, embarrassing, or something.

I think what people are missing is this isn't a Tor issue. It is a security issue. The Tor project focuses on developing Tor. It isn't developing the web server. It isn't developing Tails. The problem right now is that I don't think we have a pre-configured solution to run a server so it's more easier to get things wrong unless your *really* knowledgeable about Tor, Apache, and various security/privacy related issues surrounding everything. Right now the best place for this information is in a tutorial/guide specific to setting up Tor servers. There are still a lot of deficiencies in Tor itself let alone the server configurations users are setting up. Particularly Tor hidden services. This is one of the *primary* things that the Tor project wants to work on and the reason it's not getting the attention it deserves is because the project doesn't have adequate general funding. We need more people to contribute financially to the development. Not governments and other organizations who may not have the same needs. Policing organizations might fund Tor to ensure they have a means of connecting to illegal sites anonymously. However they don't necessarily want Tor hidden services to work.

Re:Localhost

[Anonymous Coward]

The fundamental issue is to the web server traffic coming from the server itself is given preferential treatment in viewing the status page. The effect of an attacker viewing that status page sort of depends on the use case....

But you're sort of getting at the same point I was making. Apache wasn't made with tor in mind and that's how you can get these sort of leaks. So why even take that risk, stick your hidden service in a segregated network and limit it to only talk to tor machine. That way the server is running in the way it was intended, serving up remote requests and even if you managed comprise the server somehow you couldn't learn anything other then server's address is 192.168.0.2 and it's only allowed to talk to 192.168.0.1.
It's nice that tor might try to come up with their own webserver, but what about any other service you might want to run? Are they going to try to create their own email services? What about a chat program?
There is really no need when a simple vlan can take care of it.

Re:.. visiting a web-site running as an onion ser.

[Athanasius]

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.

Lo vs 0.0.0.0

[Anonymous Coward]

Aren't they both different?

Re:Lo vs 0.0.0.0

[allo]

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

Re:.. visiting a web-site running as an onion ser.

[Hizonner]

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.

Bullshit article

[allo]

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.