Vulnerability

    SonicWall

Affected

    SonicWall

Description

    Steven Griffin found  following.  He  has 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

    Steven  was  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 configuration
    setup Steven noticed that he 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.

    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.

    Configuration information for duplication:

        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 (sonicwall config is web based  so
    we 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

Solution

    Sonicwall replicated the problem and confirmed that it is indeed a
    bug in their firmware.

    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.

    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).

    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.