1 / 17

IPSec/IKE Protocol Hacking ToorCon 2K2 – San Diego, CA

IPSec/IKE Protocol Hacking ToorCon 2K2 – San Diego, CA. Anton Rager Sr. Security Consultant Avaya Security Consulting. Agenda. IKE Overview and Protocol Weaknesses Vendor Implementation Problems IKE Tools discussion and demo. Aggressive Mode IKE. Cookie_R.

Faraday
Télécharger la présentation

IPSec/IKE Protocol Hacking ToorCon 2K2 – San Diego, CA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPSec/IKE Protocol HackingToorCon 2K2 – San Diego, CA Anton Rager Sr. Security Consultant Avaya Security Consulting

  2. Agenda • IKE Overview and Protocol Weaknesses • Vendor Implementation Problems • IKE Tools discussion and demo

  3. Aggressive Mode IKE Cookie_R Cookie_I Responder Initiator SA_I+KE_I+Nonce_I+ID_I SA_R+KE_R+Nonce_R+ID_R+Hash_R [Hash_I] • Note: Aggressive uses ID that is independent of initiator IP

  4. Main Mode IKE Cookie_R Cookie_I Responder Initiator SA_I SA_R KE_I+Nonce_I KE_R+Nonce_R [ID_I] [ID_R] [Hash_I] [Hash_R] • Note: ID is normally IP address of each endpoint

  5. Aggressive Mode ID • ID sent in clear- Well known problem • IETF specifies that aggressive mode will send ID [UserID or GroupID] in clear • Eavesdropper can collect remote access user IDs • Some vendors have proprietary ways of hashing ID when using their client to hide ID • Interoperability [SafeNet/PGPNet] requires IETF adherence – ID leakage

  6. Aggressive Mode PSK Attacks • PSK [password or shared-secret] authentication uses a hash sent in the clear • HASH is derived from public exchanged info + PSK • Bruteforce/Dictionary attacks possible against HASH as a passive listener • Some vendors use DH private value for hash derivation to prevent passive attacks – attack must be active MITM with knowledge of hashing method

  7. Attack ProcessAggressive PSK Cracking Cookie_R Cookie_I Responder Initiator SA_I+KE_I+Nonce_I+ID_I SA_R+KE_R+Nonce_R+ID_R+Hash_R [Hash_I] Assume MD5-HMAC for Hash function – based on hash in SA Responder Hash: HASH_R=MD5-HMAC(MD5-HMAC(Guessed PSK, Nonce_I + Nonce_R), resp DH pub, init DH pub + cookie_R + cookie_I + init SA header + resp ID header)

  8. Aggressive Mode ID Enumeration • IKE protocol specification does not discuss how invalid ID should be handled. Many implementations respond with an invalid ID during the initial IKE negotiation – others just don’t respond • This can allow an active dictionary/bruteforce enumeration • Submit IKE initiator frame to concentrator with guessed ID. Concentrator will tell you if guess is wrong • Vendor Workarounds: Obfuscation responses

  9. Main Mode PSK Attacks • Similar problem to aggressive mode, except HASH is passed encrypted. • Main Mode requires an active or MITM attack to attack PSK to derive DH secret • IDs are normally the IPs of endpoints • We will guess the PSK and try to determine the encryption key for the 1st encrypted packet

  10. Attack ProcessMain Mode PSK Cracking Cookie_R Cookie_I Responder (Attacker) Initiator SA_I SA_R KE_I+Nonce_I KE_R+Nonce_R [ID_I] [ID_R] [Hash_I] [Hash_R]

  11. Attack ProcessMain Mode PSK Cracking • Collect public IKE values [Nonces, DH Public values, Cookies, headers, etc] and assume IDs are IP endpoint IPs • Collect 1ST encrypted packet • Calculate DH Secret • Choose PSK value and calculate SYKEYID, SKEYID_d, KEYID_a, KEYID_e • Generate IV from hash of DH Public values • Decrypt packet with IV and SKEYID_e – check for known plaintext to validate

  12. Main Mode Policy Enumeration • Similar to aggressive mode ID enumeration • Peer will only respond to valid IP address that has a defined policy • Attacker can send spoofed init frames to “peer” to search IP address space • Correct IP will cause an SA proposal reply from “peer” • Some vendors will send a “no proposal choosen” if SA is from invalid host

  13. Implementation Vulnerabilities • Cisco VPN Client 3.5 • Cisco VPN Client 1.1 • SafeNet/IRE SoftPK and SoftRemote • PGPFreeware 7.03 - PGPNet

  14. Tools • IKECrack – aggressive mode PSK cracker • IKEProbe – IKE packet mangler

  15. IKECrackhttp://ikecrack.sourceforge.net • IKE PSK Cracker – dictionary, hybrid, brute • Simplistic implementation – Aggressive mode only • Must use IETF HASH_R calculations (RFC 2409) • MD5 HMAC only – 93K kps on 1.8ghz P4 • PERL script that requires HMAC PerlMod and uses tcpdump –x output for capture – It’s a hack, but it works.

  16. IKEProberhttp://ikecrack.sourceforge.net • Command-line utility for building arbitrary IKE packets • Supports common IKE options and allows user specified data or repeated chars • Useful for finding BoF problems with option parsing – Used to find Cisco/PGPNet/Safenet probs • Perl based and requires NetCat in Unix -- Also a hack. • Can also be used for user enumeration

  17. Contact Info • IKE Tools and preso Download http://ikecrack.sourceforge.net • Anton Rager arager@avaya.com • Code criticism: This is proof-of-concept stuff -- fix it yourself

More Related