So you thought SSL was safe?

posted on August 14th, 2006


Introduction

Do you think you’re safe if you type https :// before paypal.com? I hope you’ll think twice before you login from a computer connected to a wireless network after reading this guide. Let’s start at the beginning. Let’s say you have an evil neighbour who wants your paypal credentials. He buys himself a nice laptop with a wireless card and, if you are using a wep encryption, he cracks your wep code (click here to see how). After cracking the key he logs into your network. Maybe you always allowed him to use your network because you thought it can’t do any harm to your computer. You aren’t sharing any folders so what’s the problem? Well, in the next few steps I’m going to describe the problem.

The guide

1. Let’s assume your neighbour uses linux to crack your wep key. After cracking it, he installs ettercap (http://ettercap.sourceforge.net/) on his linux system. If you want to do this at home, I would recommend you to download BackTrack because it already has everything installed. Look at the WEP cracking guide I mentioned above for more info about BackTrack. If you want to install it on your own linux distribution, download the source and install it with the following commands:

$ tar -xzvf ettercap-version.tar.gz
$ make
$ make install

2. After installing, you need to uncomment some code to enable SSL dissection. Open up a terminal window and type “nano /usr/local/etc/etter.conf”, without the quotes. Scroll down using your arrow keys until you find this piece of code:

# if you use iptables:
# redir_command_on = “iptables -t nat -A PREROUTING -i %iface -p tcp –dport %port -j REDIRECT –to-port %rport”
# redir_command_off = “iptables -t nat -D PREROUTING -i %iface -p tcp –dport %port -j REDIRECT –to-port %rport”

You need to uncomment the last two lines.

# if you use iptables:
redir_command_on = “iptables -t nat -A PREROUTING -i %iface -p tcp –dport %port -j REDIRECT –to-port %rport”
redir_command_off = “iptables -t nat -D PREROUTING -i %iface -p tcp –dport %port -j REDIRECT –to-port %rport”

3. Press CTRL+O, press enter to safe the file and then press CTRL+X.

4. Boot Ettercap and click on Sniff > Unified Sniffing > type in your wireless interface and press ok.

5. Press CTRL+S to scan for hosts

6. Go to MITM > ARP poisoning, select sniff remote connections and press ok.

7. Now you (and your neighbour!) can start sniffing! Press start > start sniffing. Walk to another computer on your network and open up paypal or any other site where you need to type in an username/password (gmail, hotmail, digg.com, etc.). All credentials will appear on the computer running Ettercap!

8. When you’re done, don’t just close Ettercap, but go to Start > Stop Sniffing, and then go to MITM > Stop mitm attack(s).

But how does all this stuff work?

Look at the following scheme:

Normally when you type in a password, host 1 (your computer) directly connects to host 2 (your modem or router). But if someone launced Ettercap on your network, host 1 isn’t sending it’s passwords to host 2, but to the Attacking host, the host that’s running Ettercap! The attacking host sends everything to Host 2. This means that host 1 isn’t noticing anything! Exactly the same happens with everything that host 2 is sending. Host 2 doesn’t send packets directly to host 1, but forst to the attacking host.

17 comments:

  1. Polster said on August 15th, 2006 at 12:34 am :

    Doesn’t paypal work with a security certificate??! In my experience with a windows based MITM programm it was very hard to get passwords with websites which worked with certificates.
    Intercepting Gmail passwords and outlook sync. passwords was easy though, because they are send in plain text.

  2. Legionnaire said on August 17th, 2006 at 4:35 pm :

    SSL *is* safe. Secure Socket Layer handshake has about 9 steps. One of them involves the server sending his certificate to you. Then you (user) generate a symmetric key and encrypt it with the server’s public key (aka certificate). That way ONLY the server may open that since only it has the private key to read the user’s message.

    In general: SSL states that both parties negotiate over a session key, that is a symmetric key to encrypt all communications (including username and password exchange). That symmetric key is exchanged between parties using the method I’ve just described so it is immune to MITM attacks.

    As I understand you capture all packets from your victim and then relay everything in and out until you capture his password. That way you *will* capture exchanged traffic. The only problem is that it will be 1024/2048-bit encrypted (during handshake) and 128/256-bit encrypted during normal traffic. So you get nothing.

  3. Nokia said on September 12th, 2006 at 11:52 pm :

    As the person above said….all you will end up with is a lot of encrypted traffic that you have to *try* and make sense of…….if you have a few spare computers and a lot of time you may crack it eventually…….however there are a lot of plain text user names / passwords you will be able to intercept, just not PayPal deatils as it says in the title………. :-/

  4. bruce said on September 14th, 2006 at 1:00 am :

    MITM attacks don’t break SSL. Victin user have to accept the certificate.

  5. admin said on November 27th, 2006 at 9:22 pm :

    @All commenter’s

    This attack really breaks SSL. Just do it and don’t forget step 2, you’ll see it works.

  6. D4rk said on February 6th, 2007 at 1:15 am :

    Lol…
    gmail sends plaintext password… LOL

    https:\\www.gmail.com

    it also depends on the encryption used, if SSL is >128 then you can forget about this working…

  7. Zin said on March 15th, 2007 at 8:55 pm :

    http://www.faqs.org/rfcs/rfc2818.html

    Section 3.1
    In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server’s identity as presented in the server’s Certificate message, in order to prevent man-in-the-middle attacks. If the client has external information as to the expected identity of
    the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server’s identity, but it must be understood that this leaves the connection open to active attack.

    ——————————-

    An SSL handshake involves these steps.

    1) SSL Server - not a proxy - will submit to the user a certificate. If the certificate is signed by an already known and trusted authority, this is transparent and the user will not see anything happen. Otherwise, the user will be prompted to accept a certificate — he should not do this unless he is certain the certificate is from a trusted source.

    2) The users computer will use the public key located on the certificate to encrypt a generated symmetric key (held in protected memory) and then send that encrypted key to the server. The server then decrypts that symmetric key using its private key (which nobody else has access to). This key which has been securely trasmitted, thus not subject to the key distribution problem, is not known by any other parties. Only this key can decrypt the symmetric key. Therefore, only the users computer and the server know the correct key to decrypt the information. This is the 128-bit key (The public and private keys are likely 1024-bit or higher RSA key pairs — nearly impossible to crack).

    3) All communications from here on in are encrypted via TLS. You cannot sniff these.

    The only way you could possibly accomplish this is by forging a certificate (I hope you’re damn good at math and birthday attacks) and then having a copy of the web server data hosted on your machine accepting SSL connections.

    Learn how HTTP over TLS works. If you’re able to perform any kind of attack like this; someone’s server side is incorrectly configured to allow connections on a non secure port which isn’t using TLS and you’re just redirecting the traffic to the non secure daemon on the server. In this case; the users browser should warn them that they’re no longer using a secure server. Yes, they might blindly hit okay and follow through with it.

  8. admin said on March 15th, 2007 at 9:04 pm :

    @Zin:

    My test computer is a PC that’s right out of the box, just like most computers non-geeks have on their desks. This’ll give the most realistic results, of course there are uberprotected configurations and users that aren’t using any firewalls/antivirus at all.

    About that hitting OK: You’re right. The victim has to hit OK, though the window looks just like a normal secure connection hit OK window most people will just hit OK. (I demonstrated this method on several locations and all “victims” (I was there on their request so not really victims) hit Ok without know that I was going to perform the attack (well, they knew it would happen that week).)

  9. OldHorizon said on July 24th, 2007 at 11:39 am :

    Now i really don’t fell save
    the only thing I can do is never hit OK to security certificate specially if it’s coming from a noun site like gmail

    thanks for the enlightenment

  10. hoodedmanwithsythe said on September 21st, 2007 at 2:27 pm :

    although it “Shouldn’t work” it does how ever if you know to look at your certificates you can see if it has been routed the methord mentioned in this tutorial is a mid-advanced level of something that is known by the name of phishing how ever this one is verging on the pharming level.
    ssl can be cracked especialy if your machine is windows as this does NOT use a REAL form of SSL it uses MS-SSL, as with java, flash, perl, etc. the Microsoft versions are Bastardized they are not real versions and have security flaws.
    luckily there is a solution to this problem! and it is called Mozilla Firefox but this is only a solution if you actually read what it tells you and if there is some one phishing then it will tell you that the host certificate is not originating from the certificates url thus in layman’s terms it is being relayed and so you know that your network is compromised.
    Footnote: true ssl and openssl are secure MS-SSL is NOT

  11. Ovidiu C. said on November 3rd, 2007 at 9:52 am :

    SSL is as strong as the implementation. If the implementation doesn’t have any known bugs, then it’s secure. Mitm attacks like the one described usually do not rely on implementation weaknesses, but on the human factor. Ettercap will present the client (the browser) with a fake certificate (usually issued by “Verysign” — with an “y”). The browser will alert the user that “Verysign” is not a legit root CA, but the user will usually choose to proceed anyway. So it’s not really SSL that’s the problem, there’s a problem with security in general, because the user can choose to ignore it.

  12. Jim said on November 4th, 2007 at 4:59 pm :

    You can’t be bothered to give a screenshot and warn “don’t just hit ‘OK’ when you see this!”?

    You show how to set up a man-in-the-middle in loving detail, and don’t show the two seconds’ worth of effort necessary to stop one?

    It isn’t SSL that’s unsafe, it’s trusting ignorant people.

    And people like you, who prey on them.

  13. admin said on November 4th, 2007 at 5:11 pm :

    @Jim:

    I don’t give a screen because you learn way more by just testing it out by yourself. I think that everyone who visits this site knows the security window and I also know that 99% of the people hit OK without reading the screen (mainly because I even get it on google AdSense if I forget to type www., and that’s not because someone hacked the computer, but because Google is just ignorant..).

    Only way to check if someone setup a MITM without reading those security certificates is by using ettercap. Forgot the function, but you can set it up to look for hackers in the network. Will write a guide about that if you want.

  14. Matt Ellsworth said on November 14th, 2007 at 5:29 pm :

    And thats why I hate wireless and use only hard wired lines… other people just call me paranoid…

  15. Z. Sodhi said on November 16th, 2007 at 8:14 pm :

    Right, so you’re rerouting the SSL certificate, as I understand it.

    Here’s a simple overview of how SSL works, sans symmetric keys.

    CLIENT TO HOST: Requesting your SSL certificate, please.
    HOST TO CLIENT: Here is my Public Certificate. It says “Add 2 to the number”
    CLIENT TO HOST: Roger that.
    CLIENT TO HOST: 4
    HOST: I have received an SSL-secured transmission, encrypted according to my public key. I should use my private key to decrypt it. My private key says “Take away 2 from the number!”
    HOST TO CLIENT: You said 2.

    What you’re suggesting is:
    CLIENT TO ROUTER: Please tell HOST that I would like his SSL certificate
    ROUTER TO SPOOF: Please give me HOST’s SSL certificate
    SPOOF TO ROUTER: Here is HOST’s SSL certificate. It says “Do function f(x) on data”
    ROUTER TO CLIENT: Here you are, mate.
    CLIENT TO ROUTER: Please send this data to HOST.
    ROUTER TO SPOOF: Here’s what the client sent!
    SPOOF TO HOST: 4
    HOST TO CLIENT: We have successfully completed the transaction.

    Or, let’s say f(x) returns the SSHA-1 of the data, which is a specially coded, irreversible algorithm that will encrypt the data according to a secret salt.
    CLIENT TO ROUTER: SSL cert. please
    ROUTER TO SPOOF: SSL cert. please
    SPOOF TO HOST: SSL cert. please
    HOST TO SPOOF: saltedsha1($salt.x)
    SPOOF TO ROUTER: saltedsha1($salt.x)
    ROUTER TO CLIENT: saltedsha1(x)
    CLIENT TO ROUTER: b50df01dfd935a5d8d47b9538bb3d831e7eee248
    ROUTER TO SPOOF: b50df01dfd935a5d8d47b9538bb3d831e7eee248
    SPOOF TO HOST: b50df01dfd935a5d8d47b9538bb3d831e7eee248
    HOST: I need to decrypt this. I can use my private key, which is actually a huge rainbow table, to decrypt the data within 0.05s, somehow, magically, because my Private Key contains the salt. Using decryptsaltedsha1(”.lol”, “b50df01dfd935a5d8d47b9538bb3d831e7eee248″);, I know the original data was roflcopter.

    You’re suggesting, if I’ve understood you correctly:
    CLIENT TO ROUTER: b50df01dfd935a5d8d47b9538bb3d831e7eee248
    ROUTER TO SPOOF: b50df01dfd935a5d8d47b9538bb3d831e7eee248
    SPOOF: Haha! I can decrypt “b50df01dfd935a5d8d47b9538bb3d831e7eee248″ without the Private Key because I’m GOD! Of course I’m bloody well God, I’m a Linux computer.

  16. What is Malware? said on November 20th, 2007 at 10:26 pm :

    Like Matt, I do not use wireless at home. And when I do need to connect via wireless, I do not allow myself to access sites that require a password.

  17. gigel said on December 2nd, 2007 at 1:04 am :

    Dude. When you do the MITM attack (that’s what you do), a properly configured browser (actually any default configured browser) will warn you that the site’s certificate is not ok any more. You _know_ that you are fooled to another site. Now if you set your browser to accept *any* certificate without checking it’s veridicity, you will be fooled by this kind of attack (which by the way, is not strictly wireless related, by the way). Otherwise, the user knows that something is not ok.

Leave a Reply