This is the final part of the lecture describing Convergence as an alternative to the CA system, also covering sslstrip, sslsniff and other tools compromising SSL / TLS protocols.Let’s get back to the problem of secure protocol. (Slide 38) The problem with SSL and the secrecy is that everyone is a CA nowadays. There’s really no accountability for CAs, unless they cause an entire government to fail. And authenticity – you could probably just ask for someone else’s certificate and you might get it. There’s no harm in even asking – they’re going to tell you yes or no.
This is a good quote that I want to end this section of the lecture on is that “the security of HTTPS is only as strong as the practices of the least trustworthy and competent CA”.
The EFF’s SSL Observatory posted this map (see right-hand image) claiming that these are the countries that can intercept secure communications. Basically, these countries can strip SSL and decrypt SSL on any communications they want.The flaw with this is that – take back to those rumors of these CAs getting hacked. We can’t actually adapt to those problems. We can’t change anything. We’re locked into these trust relationships. When Comodo got hacked, the browsers could have dropped Comodo. However, they probably would have looked worse than Comodo, because they just broke 25% of the Internet.
Also, the problem with this is that market forces reward the cheapest trust vendors. And it’s only natural that we’re seeing an increase in CAs getting hacked. Now, just imagine the ones that don’t get detected and don’t get reported. The problem with the current model is also there’s no agility. We cannot adapt to disturbances in the force, and the trust becomes forever, basically.
There are some advisories on how to defend against the broken CA system, but in summary it’s really complicated. It means: “Just be prepared to use another CA”.I have to take a quick mention of convergence.io (see right-hand image). It’s a Firefox plug-in that uses trust agility, which, basically, allows you to be free from the CA system.
So I will quickly end the lecture with covering attacks on SSL without having to pick on the easy targets of the CA system.
To recap: basically, you have this first handshake; then you establish the symmetric key using asymmetric key encryption, the public key crypto, and then you begin asymmetric-key encrypted communication.There are tools for breaking this (see right-hand image). sslstrip is what I had a demo for today, but the Wi-Fi here broke it, so I’ll release the demo on my own. It basically uses ARP poisoning to perform man-in-the-middle attacks on ignorant users. It reduces HTTPS to HTTP, so you no longer get that lock and green icon on the top of your URL bar saying: “This is trusted”. It just looks like normal HTTP, so there’s no warning.
sslsniff is you get a CA cert; say, you’ve hacked Comodo on the other cert; you plug it in to sslsniff and you can decrypt all SSL and TLS traffic as long as you see that established mode of the symmetric key.
BEAST and CRIME are worth mentioning, because BEAST was proposed by Juliano Rizzo and Thai Duong. It attacks TLS 1.0 and 1.1. CRIME came out in late 2012 and attacks all versions of TLS and SSL, and the details are unknown; they’re working with the browsers to fix them.sslstrip is a simple tool. To attack a target you need 5 commands. You need to be on the same network as your victim. So, usually an attacker would be in a coffee shop, somewhere with open Wi-Fi. They need to be able to ARP spoof a victim, and what they’re going to do is they’re going to impersonate the gateway. Now, this can be a problem in Wi-Fi if the signal is stronger close to the victim, and it’s naturally messier in Wi-Fi. However, I’ll show you a demo without Wi-Fi.
Basically, what you do is, once you ARP spoof and you impersonate the gateway, the victim starts sending all this traffic to you, thinking you’re the gateway. What you do is you basically forward it to the legitimate gateway and you have proxy control over the traffic. So, once you’re able to intercept all the traffic, what sslstrip does is it looks for outgoing GET requests to a web server that has HTTPS in the packet and simply replaces every match of HTTPS with HTTP.
Basically, the first thing you need to do is you need to establish your IP forwarding. Essentially, what happens when you’re not attacking the user is you go to a website that doesn’t have strict transport security enabled and the login page will say HTTPS, as normal. You have username and password to log in, right? So, what happens when you ARP spoof them, run sslstrip and degrade the communication from HTTPS to HTTP is when that user sends out the username and password, if they don’t notice that: “Hey, this isn’t HTTPS in the URL” in plain text, you will get the username and password either of the GET or POST data sent from the client to the server.So, what’s going on in this window (see right-hand image) is that he’s performing ARP spoof – basically sending ARP packets saying: “Who is the gateway? I am the gateway” constantly, directly to the target. This is a targeted ARP spoof, and what it’s doing is it’s overwriting the ARP cache for the victim, so the victim has cache running of ARP responses, so it can keep an efficient glimpse and snapshot of the network. So he floods it with bogus ARP packets, it’s going to replace the value in the cache with whatever is most recent. You send in enough packets – this is guaranteed to happen.
Now you see the victim is trying to log in, and he’s sending all this traffic to the attacker. When the user types in google.com/accounts, instead of returning HTTPS it returns HTTP. The user enters in his username and password if he falls for it, and this gets logged. The attacker is here, printing out the log, and you can see email and password being sent in, essentially, the GET requests. So, essentially, he can log in as the user.The way to defend against this is to be a smart user. But for a website the defense is to have your website run strict transport security. This means SSL on all pages. Many websites do not do this, and there is no excuse for them not doing this. The only reason they don’t do this is because they’re completely incompetent. There’s been a lot of debate of “I can’t; I have a business, if I have SSL on all my pages it’s going to slow down all my traffic and everyone is going to leave me for my competitor, and they are not running SSL, and everyone knows that lag kills business”.
So, about a year or two ago Google considered this argument and implemented SSL on all of its services. It’s a less than 0.02 impact on all of its performance. If your engineer is telling you that you can’t do the SSL, it’s because everything’s been engineered, basically, wrong. You need to rethink things, and it shouldn’t impact your performance in any appreciable way.
With strict transport security, even if I’m running sslstrip and I’m intercepting your traffic and I’m modifying it, say: “Hey server, get me HTTPS and replace it with GET HTTP”. The server will respond with HTTPS requests anyways, because it doesn’t serve up HTTP plaintext.Another thing is sslsniff – like I said, if bad guys hack a certificate authority and get a certificate, basically, a private key, they can plug it into sslsniff and just decrypt SSL and TLS traffic on the fly and get the symmetric keys. It cannot be defended against. Basically, the defense is to not have a broken certificate authority system. We can all hope for a miracle. BEAST was a crypto attack on SSL, or rather TLS versions 1.0, 1.1 back in 2011. It can strip HTTPS cookies from a session and it takes less than 10 minutes on paypal.com. The defense is to use the latest versions.
CRIME – I don’t know anything about. It came out just last year. It’s the same team and it works against all versions. So, that is the end for today.
Read previous: Web Application Hacking 4: Notorious CA Hacks