Man-in-the-Middle Attack on Mobility and E-commerce

Oleg Kolesnikov

Georgia Institute of Technology

Summary

Background and LingoMan-in-the-Middle (MITM) ConceptE-commerce and MobilityAttacker’s ToolboxReal-time DemonstrationRecommendations

RSA Asymmetry

• Asymmetry:

Public to Private = NP-time Problem

Private to Public = P-time Problem

• Thus, Public Keys can be openly published to be used by Opponents

X.509 PKI

• Problem: How to distribute Public Keys ?

• Public Key Infrastructure (PKI):

Managing Public/Private Key pairs (CSRs, CRLs)

Publishing Public Keys as "certificates” in open

directories (e.g. X.500 Directory Services)

Secure Connections

• Use Public-Key Algorithm only to Exchange a Shared/Session Key or verify a Digital Signature

• Use Symmetric Key Block Cipher (3DES, DESX, Rijndael) to encrypt data

• Save Public Key or Certificate for use in subsequent sessions

Man-in-the-Middle (MITM) Attack Concept

Alice wants to send secure messages to Bob.

Charlie intercepts Alice’s messages.

Charlie talks to Alice and pretends to be Bob.

Charlie talks to Bob and pretends to be Alice.

AliceAlice BobBobCharlieCharlieEa Ec

Ec Eb

E{a,b,c} = Alice’s, Bob’s, and Charlie’s public keys, respectively

MITM Attack Concept

• Alice uses the public key she thinks she received from Bob (Charlie’s)

• Bob uses the key he thinks is Alice’s (also Charlie’s)

• As a result, Charlie not only gains access to secure information but also can modify it (e.g. transfer money to a different account etc.)

Mobility

• Internet Cafes, Conference Terminals

• Hostile Environment

• SSHv1 vs SSHv2 deployment

• PKCS#12 hassle

Mobile Users under Attack: Secure Shell (SSH) v1

• No Certificates; Public Keys are used

• Although SSHv2 is more secure, many clients and servers still use v1, e.g.

telnet ns1.securityportal.com 22

• SSHv1 saves public keys and warns you if a public key has been changed:@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that the RSA host key has just been changed

Add correct host key in ~/.ssh/known_hosts to get rid of this message.

Are you sure you want to continue connecting (yes/no)? no

Mobile Users under Attack: SSH v1 using Kerberos S/KEYs

• S/KEY is a challenge-response one-time password system.

• Does it help to solve MITM problem for SSH ?• It makes MITM Attack harder to execute but

does not eliminate the threat.

• See kdcspoof (Kerberos spoofer).

Why E-Commerce

• E-Commerce heavily relies on Public-key-based protocols

• Examples:

- HTTPS (HTTP over SSL/TLS)

- Secure Electronic Transactions (SET)

developed by Visa/MasterCard specifically for

electronic/on-line transactions

MITM Attack on E-Commerce

• Trust in HTTPS/SSL/TLS

• Until IPSEC/DNSSEC are widely deployed,

E-Commerce security is questionable

• User aspect

Users under Attack: Secure Browsers

• User is typically presented with a menu asking whether to accept new [root] certificate

• Usually, users click on “Yes” and accept new certificate without even thinking about the consequences

• ~ 60 Root Certificates in my IE5.5. Did I verify each one of them thoroughly ?

STS

• Public Key distribution is probably the most serious problem for Public Key algorithms

• Diffie, Oorschot, Wiener proposed a way to deal with the problem back in 1992 called Station to Station protocol (STS)

• Ideas from STS are used as a part of Digital Certificates concept

MITM and Certificates

• Digital Certificates designed to solve the problem but do they always help ?

• Third party CA signs Alice’s and Bob’s public keys so they exchange signed keys (certificates) instead

• Good so far ?

Trusting Certificates

• Problem: Alice and Bob must trust CA

• CA’s information must be delivered to Alice and Bob via Secure Channel

• But how CA’s information usually gets to Alice and Bob ? Via Unprotected Public Network :)

Typical Attack Description

This is where attackers come into play, they:

Obtain access to traffic by:

Breaking into a gateway

Spoofing routing tables (RIP/IGP) |

DHCP entries (default gateway)

DNS

ARP caches

Typical Attack Description

Intercept traffic at connection establishment phase and generate self-signed PKI certificates to replace originals

Start forwarding data and gain full access to sensitive information

MITM Attacker’s Toolbox

• dsniff

• Contains several ready-to-use utilities to do MITM attacks, namely:

sshmitm, webmitm, dnsspoof, and arpspoof.

• Allows attackers to hijack / sniff / analyze HTTPS and SSHv1 traffic

MITM Attacker’s Toolbox II

• Libnet: Packet construction and handling

• libpcap: Packet capturing library

• libnids: tcp stream assembly, defragmentation

• sw-mitm: Redirects Layer 2 traffic

MITM Attacker’s Toolbox III

• OpenSSL: Open Source implementation of SSLv2/3 and TLSv1

‘openssl’

Command line tool, creates RSA/DH/DSA key parameters, CSRs, CRLs, X.509 Certificates, MDs, Encrypts/Decrypts using various ciphers etc.

Notes on Setting up MITM host (dsniff)

• dsniff exec’s openssl directly using system() library call, so openssl must be in $path

• regexes for capturing passwords can be adjusted (see decode_http.c)

• Kernel IP forwarding must be on, e.g.sysctl -w net.inet.ip.forwarding=1(BSD)

Demonstration

Implications

• Attackers breaking into core routers/servers, adding ‘transparent forwarding’, and then using dsniff to capture and decrypt HTTPS/SSH1 data

• Government installing their machines at large ISPs and using MITM to decrypt HTTPS/SSL, Privacy Enhanced Mail (PEM) and other data.

Relevant Work

• Internet Key Exchange Protocol (IKE)

• Hybrid protocol which implements Oakley and Skeme Key Exchange Protocols

• IKE also implements Internet Security Association and Key Management Protocol (ISAKMP) framework

Recommendations

• Data Link Layer:– Enable port security on a switch; use static

arp entries• Network Layer:

– DNSSEC and IPSEC to prevent DNS spoofing and sniffing

• Transport Layer:– Verify root CAs and public keys before adding

them; expire your public keys; pay attention to key/certificate change notifications

Weakest Link

• User almost always is the weakest link

• Be aware of what those SSHv1 and SSL messages about adding certificates / key change mean before typing ‘y’

• Be careful with your public keys and make sure your party has access to *your* public key

Questions ?

Thank you !