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

SecurityTracker
Archives


 


Category:   Device (Encryption/VPN)  >   Dell SonicWALL Vendors:   SonicWALL
(Additional Clarification About Security Impact) Re: The VPN Implementation on SonicWALL's Tele2 and SOHO Firewalls Uses Weak IKE Authentication Keys
SecurityTracker Alert ID:  1001198
SecurityTracker URL:  http://securitytracker.com/id/1001198
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Mar 30 2001
Impact:   Disclosure of authentication information, Disclosure of system information

Version(s): firmware version 6.0.0.0
Description:   A vulnerability has been discovered in the VPN implementation of SonicWALL's Tele2 and SOHO firewalls that uses short IKE pre-share key sizes.

A user writes to clarify the issue of security in relation to 48 byte IKE pre-shared keys:

"The shared secret is used for the authentication of the keying material; the length constraints discussed do not affect overall security of the system. The shared secret is used in as a 'key' in a HMAC (see rfc 2104). Keys longer than 64 bytes (the block size of sha1 and md5) are hashed first to generate a value < 64 bytes. The only issue with security strength is that the key should be be longer than the length of the hash output (20 bytes for sha1, 16 bytes for md5)."

Quoting from rfc 2104:

The key for HMAC can be of any length (keys longer than B bytes are
first hashed using H). However, less than L bytes is strongly
discouraged as it would decrease the security strength of the
function. Keys longer than L bytes are acceptable but the extra
length would not significantly increase the function strength. (A
longer key may be advisable if the randomness of the key is
considered weak.)

Although the keystreams are dependant on the shared secret, the
dependancy is as discussed above, so there really is no problem with
security. The exact relationships can be found in rfc 2409, btw."

Impact:   VPN sessions that are created using short IKE pre-shared keys could be decrypted, even if long session keys are used.
Solution:   No solution was available at the time of this entry. However, the vendor is working on a firmware fix.
Vendor URL:  www.sonicwall.com (Links to External Site)
Cause:   Authentication error

Message History:   This archive entry is a follow-up to the message listed below.
Mar 28 2001 The VPN Implementation on SonicWALL's Tele2 and SOHO Firewalls Uses Weak IKE Authentication Keys



 Source Message Contents

Subject:  Re: SonicWall IKE pre-shared key length bug and security concern


I was originally going to reply only to Steve, but since I got some questions
from my own people about this, I thought the reply might be of general
interest.  The shared secret is used for the authentication of the keying
material; the length constraints discussed do not affect overall security of
the system.  The shared secret is used in as a 'key' in a HMAC (see rfc
2104).  Keys longer than 64 bytes (the block size of sha1 and md5) are
hashed first to generate a value < 64 bytes.  The only issue with security
strength is that the key should be be longer than the length of the hash
output (20 bytes for sha1, 16 bytes for md5).

Quoting from rfc 2104:

   The key for HMAC can be of any length (keys longer than B bytes are
   first hashed using H).  However, less than L bytes is strongly
   discouraged as it would decrease the security strength of the
   function.  Keys longer than L bytes are acceptable but the extra
   length would not significantly increase the function strength. (A
   longer key may be advisable if the randomness of the key is
   considered weak.)

Although the keystreams are dependant on the shared secret, the
dependancy is as discussed above, so there really is no problem with
security.  The exact relationships can be found in rfc 2409, btw.

Hope this helps,
rwt
---
Robert Tashjian
rwt@netopia.com

----- Original Message -----
From: "Steven Griffin" <sgriffin@BAYSTARCAPITAL.COM>
To: <BUGTRAQ@SECURITYFOCUS.COM>
Sent: Tuesday, March 27, 2001 12:34 PM
Subject: SonicWall IKE pre-shared key length bug and security concern


> I have recently found a bug in the latest firmware
> (6.0.0.0) of SonicWall's Tele2 and SOHO firewalls.
>
> Product details:
> http://www.sonicwall.com/products/tele/details.html
> http://www.sonicwall.com/products/soho/details.html
>
> Bug disovery:
> I was recently configuring the Tele2 and SOHO
> versions of these firewalls in a gateway to gateway
> VPN using IPSec with IKE pre-shared keys. The
> home office gateway was a Cisco PIX 520 running
> the PIX OS 5.2(4).  The Tele2 and SOHO firewalls
> were recently upgraded to the 6.0.0.0 firmware.
> The IPSec configuration was ESP-3DES ESP-MD5-
> HMAC. During my configuration setup I noticed that I
> could not configure an IKE pre-shared key longer
> than 48 bytes.  Doing so caused the the 2nd phase
> IKE negotiation to fail on the PIX.
>
> I contacted the vendor (SonicWall) and reported the
> problem.  They have replicated the problem and
> confirmed that it is indeed a bug in their firmware.
> I asked them for permission to inform BugTraq and
> they responded that it was indeed alright to post this
> here provided that I inform you that I found the bug
> and that to say that they will provide a fix for this
> problem as soon as possible.
>
> Security concern:
> Obviously the limitation of using only a  48 byte key
> as opposed to using a full 128 byte key degrades the
> overall security of the firewall.
>
> Workarounds:
> Do not use pre-shared keys. Use certificates, your
> own or from a third party CA, instead.
>
> If you must use pre-shared keys:
>   Use only static gateway addresses if possible.
>   Use a different key for each gateway.
>   Turn on Perfect Forwared Secrecy.
>   Set your key expiration time to a shorter interval.
>
> Configuration information for duplication:
> note: IP Addresses have been removed.
>
> PIX 520 with OS 5.2(4) relavant config:
> access-list 119 permit ip xxx.xxx.xxx.xxx
> xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
> access-list nonat permit ip xxx.xxx.xxx.xxx
> xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
>
> sysopt connection permit-ipsec
> sysopt ipsec pl-compatible
>
> crypto ipsec transform-set SonicFirewall esp-3des
> esp-md5-hmac
> crypto map Sonic-map 19 ipsec-isakmp
> crypto map Sonic-map 19 match address 119
> crypto map Sonic-map 19 set peer xxx.xxx.xxx.xxx
> crypto map Sonic-map 19 set transform-set
> SonicFirewall
> crypto map Sonic-map interface outside
>
> isakmp enable outside
> isakmp key <48-byte key here> address
> xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx
> isakmp identity address
> isakmp policy 19 authentication pre-share
> isakmp policy 19 encryption 3des
> isakmp policy 19 hash md5
> isakmp policy 19 group 1
> isakmp policy 19 lifetime 28800
>
> SonicWall with firmware 6.0.0.0
> Note: sonicwall config is web based so I will post
> field names. datatypes in square brackets "[ ]" and
> field values after a colon ":"  IP addresses have also
> been removed.
>
> Summary Tab:
> Enable VPN checkbox: Checked
> Disable all VPN Windows Networking (NetBIOS)
> broadcast [checkbox]: UnChecked
> Enable Fragmented Packet Handling [checkbox]:
> Checked
>
> Configuration Tab:
> Security Association [drop-down listbox]: SonicToPIX
> IPSec Keying Mode [drop-down listbox]: IKE using
> pre-shared secret
> Name [textbox] SonicToPix
> Disable This SA [checkbox]:UnChecked
> IPSec Gateway Address [textbox]:xxx.xxx.xxx.xxx
> Require XAUTH/RADIUS(only allows VPN clients)
> [checkbox]:UnChecked
> Enable Windows Networking (NetBIOS) broadcast
> [checkbox]:Checked
> Enable Perfect Forward Secrecy
> [checkbox]:UnChecked
> SA Life time (secs) [textbox]:28800
> Encryption Method [drop-down listbox]:Strong
> Encrypt and Authenticate (ESP 3DES HMAC MD5)
> Shared Secret [textbox]:<48-byte key here>
> Destination Networks: [sub window]:
> IP Address [textbox]:xxx.xxx.xxx.xxx
> SubnetMask [textbox]:xxx.xxx.xxx.xxx
>
>
>
> Disclaimer and closing:
> I must say that I am not a security expert and I do not
> claim to be one.  My opinions are my own.  Use my
> opinions and the information in this posting at your
> own risk.  My intention for posting this information is
> to inform the BugTraq community about a possible
> security concern.
>
> Steven Griffin
> sgriffin@baystarcapital.com
>
>
>
>
>

 
 


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 2021, SecurityGlobal.net LLC