The Glade 4.0

Law Enforcement Appliance Subverts SSL (TSL) wired


Nice!

_________________
"Men, it has been well said, think in herds; it will be seen that they go mad in herds, while they only recover their senses slowly, and one by one." Charles Mackay

Terrifying. I don't even want to think what kind of carte blanche this gives for circumventing all kinds of heinous ****.

Can't get jurisdiction to subpoena bank records for an offshore bank? Just steal his password directly!

_________________
"Aaaah! Emotions are weird!" - Amdee
"... Mirrorshades prevent the forces of normalcy from realizing that one is crazed and possibly dangerous. They are the symbol of the sun-staring visionary, the biker, the rocker, the policeman, and similar outlaws." - Bruce Sterling, preface to Mirrorshades

It was only a matter of time before someone commercialized this.

Now it's just a matter of who ends up with the technology and what will they do with it.?

The whole process requires physical access to the network and a physical device to implement... not something a casual hack can accomplish.Seems like a court order could gain access directly to the target system bypassing all this in the first place.

_________________
In time, this too shall pass.

This would have varying success. Some connections would be impossible to counterfeit.

_________________
"Men, it has been well said, think in herds; it will be seen that they go mad in herds, while they only recover their senses slowly, and one by one." Charles Mackay

Actually, casual hacks can accomplish this. You needn't install your hardware at the ISP -- it just needs to be anywhere between the target and his secure site. There are various ways of forcing your machine into the middle -- ex. DNS cache poisoning, route poisoning, ARP poisoning, and IP spoofing to name just a few. As well, a "physical device" in this case can simply be a hacker's PC (or a zombie machine he controls). This company has turned the whole thing into a "network appliance" type of device, but that's certainly not necessary. You could pull this off with any device that has an internet connection.

That said, this article is misleading. This isn't a true "man-in-the-middle" attack, per se. This is actually an endpoint security failure that exploits a bad trust model. Sadly, it's been known for quite some time that even the "big" CAs (ex. Verisign, Thawte) could not be trusted to do their job competently. It should come as no surprise that if you can fool or subvert a CA, you can fool and subvert anyone who trusts them implicitly. From a technical point of view, this is no different than stealing a server's private key. Doing so will allow you to perfectly impersonate the server and, yes, this includes setting yourself up as a man-in-the-middle.

It needs to be stressed that the SSH/TLS protocols are not vulnerable to man-in-the-middle attacks -- at least not if your browser is negotiating any of the "secure" ciphersuites. For the most part, this means either 128-bit RC4, AES-128, or AES-256. The weakest of these is RC4, but even that (as implemented by SSL/TLS) is still secure. For the foreseeable future, these ciphers are unbreakable by anyone who does not posses a functional, complex, large-scale quantum computer.

_________________
Sail forth! steer for the deep waters only!
Reckless, O soul, exploring, I with thee, and thou with me;
For we are bound where mariner has not yet dared to go,
And we will risk the ship, ourselves and all.

Those aren't casual hacks.

SSL/TLS is currently vulnerable to MITM attacks.
http://web.nvd.nist.gov/view/vuln/detai ... -2009-3555

_________________

According to the article, you do need the hardware at the ISP.

_________________
In time, this too shall pass.

Yeah, I know what the article says. But just speaking to the general case, this sort of attack could be carried out without having equipment installed at the ISP. The only reason you would want to do it that way is if you need for the attack to work against any and all hosts attached to that system. This might be desirable if you absolutely need the attack to work against a specific target, but it's not necessary if you're just a cracker looking to indiscriminately swipe data from anybody that you can successfully mis-direct to your compromised web server/network device. There are any number of ways to do this, and most of them don't require terribly much in the way of technical knowledge. For instance, a very significant portion of malware already does this, for example by modifying the system's host file or otherwise sabotaging the client's name resolver. There are also several external attacks which would not require malware on the target's machine (such as DNS cache poisoning) which will work for at least some portion of the population. In fact, I see a pretty constant stream of cache-poisoning attempts against my own BIND server on a daily basis, most likely being carried out in a fully automated way by botnets.


Mmm...for sufficiently small values of "casual", sure. The sorts of exploits I mentioned above are certainly trivial, though, and are routinely carried out by your typical 13-year-old 133t h4x0r. ARP poisoning and IP spoofing are trickier, and certainly not guaranteed to succeed. However, they are well known and not that technically challenging to pull off. That is, you don't have to be an "expert" cracker to exploit them.


Fair enough. This is a bone fide man-in-the-middle attack. The renegotiation gap is of somewhat limited scope, though. Don't get me wrong; a person could do a lot of damage with it. But it's not the sort of thing that a typical user doing typical things with their browser (ex. banking) is likely to be vulnerable to, though it is properly a flaw in the SSL/TLS standards themselves.

_________________
Sail forth! steer for the deep waters only!
Reckless, O soul, exploring, I with thee, and thou with me;
For we are bound where mariner has not yet dared to go,
And we will risk the ship, ourselves and all.

In the scenario you proposed above, where the intercept device is not local, ARP poisoning is not possible. Likewise, IP spoofing is not going to get you anywhere, TCP is stateful. DNS poisoning has the potential to work against an unsecured server, however, the target is not random, and so the attacker would have to get lucky on that score, or put in a lot more effort than you are allowing. Route hijacking is also a bit more difficult than you are allowing for, at least in the ARIN and RIPE regions. The LACNIC, APNIC, and AfriNIC regions are a bit more lax, but even then the route would have to propogate successfully to pull off the necessary exploit.

You are correct it is a flaw in the standard itself. The original estimation was that the IETF would be able to update the standards in Q1 of this year. I don't think they're making the deadline.

_________________

"The Middle" is a big place....

I think we may be talking about two completely different things.

The scenario I'm envisioning is that John Q. Hacker obtains a number of bogus certificates for common, frequently used, interesting sites. Ex: bankofamerica.com, gmail.com, battle.net, etc. The hacker sets up his own MITM device similar to the one marketed by Packet Forensics, only it isn't installed at anyone's ISP (obviously). Instead, it just listens on its own IP interface -- let's say 10.0.0.1 (not valid on the public Internet obviously, but you get the idea). He then releases into the wild some kind of malware/worm/virus which, when it infects its host, redirects the desired sites to 10.0.0.1. As I said, this can be as simple as modifying the system's host file. Lots of actual malware does just this, so it's certainly not an unrealistic scenario.

So far this is totally "vanilla" malware scheme, and is not beyond the capability of novice Windows crackers. There's nothing new here that hasn't already been done a million times by malware in the past. However, the critical difference is in how the hacker handles the incoming connections from his victims. In a traditional malware-aided phishing scheme, he would simply run his own "mock-up" web server that pretends to be gmail.com, or whatever. This has the disadvantage of being a non-functional mockup, and therefore much more prone to detection by the end user.

But with his bogus certificates, he can instead use his platform merely as a relay, rather than a mock-up web server -- echoing the user's traffic to the real site, and echoing its responses back to his victim. Besides being all but undetectable even to a technically knowledgeable user, this also provides a lot of additional information that wouldn't be available to a simple phishing expedition.

How useful that information might be would depend on the nature of the site so compromised. In many cases (like bank and email sites), it probably wouldn't offer much additional benefit beyond the increased "stealth". But to pick a more interesting example, suppose that our hacker has obtained a bogus cert (from the real CA) for a popular online gambling site. Depending on its design, this could allow the hacker to see other user's cards in real-time, giving him a non-trivial advantage for financial gain. I'm sure if we all thought about it long enough, we could come up with other interesting and profitable uses for the ability to spy on the interactions of random users of a particular site.

It all depends on what you're aiming for. If you need to exploit a specific person this would difficult to do without being able to place yourself in their ISP's offices (or somewhere even further upstream). But if your goal is merely to exploit non-specific users of a particular site, you need only cast your nets wide enough.

_________________
Sail forth! steer for the deep waters only!
Reckless, O soul, exploring, I with thee, and thou with me;
For we are bound where mariner has not yet dared to go,
And we will risk the ship, ourselves and all.

If an end system is infected by a bad actor, the rest of your scenario is redundant effort.

_________________