ManintheMiddle Attack on Mobility and Ecommerce Oleg Kolesnikov

Man-in-the-Middle Attack on Mobility and E-commerce • Oleg Kolesnikov • Georgia Institute of Technology

Summary ü Background and Lingo ü Man-in-the-Middle (MITM) Concept ü E-commerce and Mobility ü Attacker’s Toolbox ü Real-time Demonstration ü Recommendations

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 (3 DES, DESX, Rijndael) to encrypt data • Save Public Key or Certificate for use in subsequent sessions

Man-in-the-Middle (MITM) Attack Concept Alice Ea Ec Ec Charlie Eb Bob E{a, b, c} = Alice’s, Bob’s, and Charlie’s public keys, respectively 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.

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 • SSHv 1 vs SSHv 2 deployment • PKCS#12 hassle

Mobile Users under Attack: Secure Shell (SSH) v 1 • No Certificates; Public Keys are used • Although SSHv 2 is more secure, many clients and servers still use v 1, e. g. telnet ns 1. securityportal. com 22 • SSHv 1 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 v 1 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 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/Master. Card 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 IE 5. 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 SSHv 1 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 • Open. SSL: Open Source implementation of SSLv 2/3 and TLSv 1 ‘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. ip. forwarding=1(BSD)

Demonstration

Implications • Attackers breaking into core routers/servers, adding ‘transparent forwarding’, and then using dsniff to capture and decrypt HTTPS/SSH 1 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 SSHv 1 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 !