12

I was humming along with my usual routine of listening to old Defcon videos trying to understand some of the basics of what's going on in the IT Security world, when I came across one explaining man in the middle attacks.

So I got to thinking. Well, what could you really do with that? Then I thought of an odd man in the middle attack that I'm wondering, if it would work.

So we all know routers direct packets along on their way to wherever they're going. This is fine and dandy. Yet what if you set up something a little more evil. When a packet comes your way (destination of which is one of a pre-compiled list of sites), what if I pretend to be that destination? What if you say "Yes I'm paypal.com! Lets make a secure connection!". Then you make a secure connection with that thingy. After doing this, you could make a secure connection with PayPal, and do everything the user is doing, yet you grab all the information you want (i.e. how many smiley faces they are sending to their brother Steve).

The only problem I can think of running across is, if the packet decides to take a different path. I'm not sure about this, but you might be able to tell the other system that you're changing your blah blah blah, so it should connect to your real blah blah blah.

Is there anything out there to prevent this? I can't think of anything, and the idea of people being able to do this is slightly scary...

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
Griffin Nowak
  • 1,190
  • 1
  • 12
  • 19
  • 1
    More generally: [How does SSL work?](http://security.stackexchange.com/q/20803) (the answer to your question is in there, but mixed with a lot of other considerations) – Gilles 'SO- stop being evil' Apr 07 '13 at 18:29
  • Best prevention is awareness and testing, SET is a good tool, MITM is a good tool and well informed policies. But most ssl encrypted traffic can't easily be properly captured. But how do you ensure your in the most catagory, regular testing with tools as previously mentioned by myself and Rory MITM – chrisc Apr 08 '13 at 12:04

3 Answers3

16

A router misbehaving and trying to act as a fake server with regards to the client, and a fake client with regards to the true server, forwarding data in both directions, is the exact definition of a man-in-the-middle attack. Apart from routers (which act at the IP level), classic practical methods for MitM include:

(This list is in no way exhaustive.)

To defeat these attacks, we use server authentication which, in the case of SSL Web sites (like https://www.paypal.com) uses X.509 certificates. When the client (a Web browser) connects to the Paypal server, it explicitly requires a "secure connection" (because the URL begins by https://, not http://) and will reject the server unless the server uses a certificate which:

  1. is issued by one of the root CA that the browser trusts a priori (the Verisign/Entrust/Thawte/whatever that were included by the browser vendor), and:
  2. contains the expected server name in it (www.paypal.com, as specified in the URL).

On mismatch, the browser will warn the user in a spectacular way. The MitM will be successful only if one of the CA goofs up (i.e. the CA issues a certificate containing www.paypal.com to somebody who is not at all the owner of the paypal.com domain), or the user goofs up (by using a URL which says www.paypal.com.evilhacker.com, or by not paying heed to the scary warning displayed by his browser), or the user machine is already compromised (e.g. through some malware which installed a rogue root CA).

Generally speaking, SSL has been designed so that security is maintained independently of the transport mechanisms. SSL security does not rely on routers behaving "honestly". SSL assumes that routers are all hostile.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • Yet you can't spoof the certificate? – Griffin Nowak Apr 07 '13 at 18:31
  • 1
    I thought you could here http://stackoverflow.com/questions/9353340/benefits-in-security-to-a-ca-signed-ssl-certificate – Griffin Nowak Apr 07 '13 at 18:32
  • Certificates are signed. To make a fake certificate, you have to break a CA, or get your own rogue CA to be trusted. Otherwise, you can sign whatever you want, but existing clients will not accept the certificate as "valid". – Tom Leek Apr 07 '13 at 18:34
  • What prevents my from using the same signature? – Griffin Nowak Apr 07 '13 at 18:36
  • A signature is specific to both the signature key and the signed message. The signature verification algorithm (executed by the client, i.e. your browser) won't return "yeah, it's good" if it is applied to a message distinct from what was originally signed. – Tom Leek Apr 07 '13 at 18:39
  • So we agree on an encryption. Then you send my the packets encrypted. Yet without the private key I can't decrypt those packets. So how did you encrypt these packets? How can you encrypt something without knowing how to decrypt it? – Griffin Nowak Apr 07 '13 at 18:51
  • 5
    It uses [mathematics](http://security.stackexchange.com/questions/6290/how-is-it-possible-that-people-observing-an-https-connection-being-established-w/6296#6296). Mathematics are great. – Tom Leek Apr 07 '13 at 18:52
  • Like the handshake? – Griffin Nowak Apr 07 '13 at 18:52
  • Because I control the handshake. I say what we agree on. – Griffin Nowak Apr 07 '13 at 18:53
  • I had a better video but this guy kind of says the same thing http://www.youtube.com/watch?v=XUZJKLGJYw0&list=FLhRHVsDl2F370OkmHOE1Fdw – Griffin Nowak Apr 07 '13 at 18:55
  • Here it is http://www.youtube.com/watch?v=3QnD2c4Xovk – Griffin Nowak Apr 07 '13 at 18:56
  • @Griffin You can't spoof the certificate because it has a signature field. The signature field uses an algorithm. The value of the certificate signature would change if you changed any of the certificate's contents. You can validate the signature field using the public key of the signing entity (the CA). So it's not like you can spoof Verisign's certificates unless you somehow get access to their keys. – KyleM Apr 07 '13 at 19:48
  • 1
    @KyleM of course if you *do*, all bets are off... – Shadur Apr 08 '13 at 08:47
  • @Griffin You don't control the handshake; both sides already already know what they'll agree on. Unless you can convince the client to trust your spoofed certificate (which would involve convincing them to install your own CA certificate as trusted, then using that to sign a fake certificate generated on the router) you won't be able to alter the data stream without immediately being detected. – Shadur Apr 08 '13 at 09:19
  • @griffin **All** good cryptography assumes that absolutely everything between the sender and the recipient is potentially hostile and untrustworthy by definition as a starting position, and then works from there to establish a secure connection *despite* all of that. – Shadur Apr 08 '13 at 09:22
5

This is what SSL certificates are for. Your browser has a list of trusted certificates and certificate providers, and when a site says I'm PayPal.com your browser knows the certificate is wrong.

A man in the middle attack may spoof certificates or persuade you to accept an incorrect certificate, and a successful one could indeed do what you say, and steal your money. It happens a lot.

Not as scary as you think though. Usual guidance applies: keep your system up to date, use antivirus, avoid dodgy behaviour online, etc

Rory Alsop
  • 61,474
  • 12
  • 117
  • 321
4

Preventing this kind of issue depends on the type of protocol that's used. Assuming that we're talking about web access (HTTP) here then the main defence against this kind of attack is a well configured SSL setup combined with some user awareness.

If you try to intercept access to an SSL encrypted website then you need to present a certificate to the user where you pretend to be the site you're spoofing (in your example paypal.com).

However the users browser will only accept certificates which have been signed by certain "trusted root" certificates (this is usually defined at base by the browser or operating system vendor).

So as an attacker you can either try to use an untrusted certificate (one you generate yourself claiming to be www.paypal.com) in which case the user will get a warning that the certificate cannot be trusted, or you could try to present the user www.paypal.com unencrypted and hope that they don't notice. that said protections like SSL pinning and HSTS could make this type of attack more difficult or indeed impossible..

Either way if you have a MITM type setup you have a fair degree of attacks that you can carry out. For Internet connections, potentially the hardest piece would be getting to the point of being a man-in-the-middle.

Rory McCune
  • 61,541
  • 14
  • 140
  • 221