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