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 [EMAIL PROTECTED] - Original Message - From: "Steven Griffin" [EMAIL PROTECTED] To: [EMAIL PROTECTED] 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
Re: Make The Netopia R9100 Router To Crash
Well, had you bothered to contact Netopia first, (what!, you didn't! shame on you!), you would have found that the problem has been resolved for some time now. The version of firmware against which you are reporting this problem (4.6) is close to a year old. The current version of firmware is 4.8.2, or two feature releases and a number of bug fixes removed. Please upgrade to 4.8.2. In the future, you should report security problems to [EMAIL PROTECTED] or call Netopia Tech Support and have the problem logged so that it can either be fixed, or as in this case, you can be directed to upgrade your firmware. rwt ps. Whose router do you have passwords to anyhow:^? And why are you trying to delete the logs:^? --- Robert Tashjian [EMAIL PROTECTED] - Original Message - From: "Julien Henry" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, January 23, 2001 1:59 PM Subject: Make The Netopia R9100 Router To Crash This post will be short because it does not need a lot of explanation. This is in a really specific case. If you have the password of the router and if you are logged to it you will not be able to delete all the traces. The router logs the connection and the disconnection of telnet sessions. If you want to delete the connection from the logs you just have to delete them. But if you want to delete the disconnection log you can't. The only way to do that is to make it crash. Just use the telnet program which is inside the router. Try to make a connection from the IP of the router to the IP of the router. It will crash it, as a consequence, you will NOT be logged ! In the log you only see things like that : 01/24/01 01:01:15 --BOOT: Warm start v4.6 01/24/01 01:01:10 * EXCEPTION: A6: 12F6890, A7: 12F67DC 01/24/01 01:01:10 * EXCEPTION: A4: 0, A5: 124B474 01/24/01 01:01:10 * EXCEPTION: A2: 125F9AC, A3: 0 01/24/01 01:01:10 * EXCEPTION: A0: 125F9D8, A1: 0 01/24/01 01:01:10 * EXCEPTION: D6: 0, D7: C1FB0028 01/24/01 01:01:10 * EXCEPTION: D4: 0, D5: 0 01/24/01 01:01:10 * EXCEPTION: D2: 0, D3: 0 01/24/01 01:01:10 * EXCEPTION: D0: 0, D1: 6 01/24/01 01:01:10 * EXCEPTION: BERR SF SP+$10: 10845AE, SP+$14: E0045 01/24/01 01:01:10 * EXCEPTION: BERR SF SP+$08: 83A, SP+$0C: F9AC 01/24/01 01:01:10 * EXCEPTION: PC: 10845AE, SR: 2004, F/V: C008
