Here's my response to Checkpoint's statement on this IKE username sniffing and guessing issue: Regarding the usernames en clair issue, I agree that the problem is at least partly a limitation in IKE aggressive mode as was stated in the original article at http://www.nta-monitor.com/news/checkpoint.htm. However, the fact that the issue is due to the underlying protocol rather than the implementation does not mean that there is no vulnerability. The problem here is mainly one of user awareness - how many people were aware that the SecuRemote usernames were passed in the clear if IKE was used with shared secrets? This doesn't seem to be mentioned in the NG FP2 Checkpoint Desktop Security Guide which covers Firewall configuration for SecuRemote, and the management client GUI dialogs don't mention it either. Does anyone know if this is mentioned in the Checkpoint documentation anywhere? Perhaps I missed it. If the product supports a method of operation which has known security issues, then I think that this should be pointed out to the user so that they can make an informed decision. Regarding the username guessing issue, this is also partly a user awareness issue - Checkpoint rightly say that there are more secure options available, but if this is not pointed out then people won't know to use these more secure options. The fact that aggressive mode (and therefore IKE with shared secret auth) is disabled by default in NG FP1 and FP2 is a good move, although I have found many customers who are running NG FP2 with this enabled - presumably because they were using IKE with shared secret auth before and found that they needed to turn this on to "get it working". Although IKE Hybrid mode addresses the username en clair issue discussed above, I'm not sure if it also addresses the username guessing issue or not. The fact that the authentication details are encrypted with Hybrid mode doesn't by itself protect it from guessing attacks because the exploit code could easily do the necessary encryption in the same way the SecuRemote client does. Note that aggressive mode is _not_ disabled by default in Firewall-1 NG (build 50046) but it _is_ disabled by default in NG FP2 and I suspect it is also disabled by default in NG FP1. Also, although v4.1 has an "allow aggressive mode" checkbox which is enabled by default, it's not possible to disable it - even if you disable aggressive mode on v4.1 and re-install the policy, the Firewall still responds to aggressive mode requests. In addition to the user awareness issue, there are also some product design issues which could help to reduce the impact of the username guessing issue and also other similar authentication issues which may be discovered in the future. In all the items below, I'm talking mainly about IKE usernames (IDs) and passwords (shared secrets), although many of the items are also applicable to other authentication methods such as Firewall-1 password. 1. For username/password auth, don't respond with an "OK/Not OK" message until the user has submitted the password as well as the username, and then don't tell the user which one was wrong - just give a generic authentication failure message. Sure, this will require some resources on the Firewall, but not much, and if resources get tight you could always drop those half-completed authentications where the username was invalid rather than valid authentication attempts. Note that, judging from the significant CPU resources used on the Firewall with invalid user authentication attempts (95% CPU on an 800MHz AMD CPU with a packet rate of about 67 per second) suggests that the Firewall is doing some expensive operations anyway - probably the Diffie Hellman exponentiation - so continuing with the authentication process wouldn't make this any worse. 2. Limit the rate of authentication attempts from any given IP address. Sure, this won't stop DoS attacks that try to exhaust CPU or other resources, but it would make guessing much less fruitful. At the moment, there appears to be no rate limit - I've observed over 450 guesses per second over an Ethernet link with a fast Firewall CPU. I suspect that this lack of rate limiting applies to passwords as well as usernames, although I've only checked username guessing. 3. Enforce user-configurable password strength checks with reasonable defaults E.g. allow specification of minimum password length and other password strength factors such as preventing letters only, numbers only, password = username, dictionary word Etc. Most OSes let you do this. Firewall-1 allows you to put anything in the IKE secret (password) e.g. a single letter or the same as the username. Enforcing good password practice would greatly reduce the chance of a successful password guess once the username was guessed. You'd be surprised (or maybe not) on how many passwords we find the same as the username during our security tests. 4. Allow user-configurable password aging I guess this would need some client password change mechanism, but forcing the client to regularly change passwords would limit the impact of guessed usernames and passwords somewhat. This is standard practice in most modern OSes and is often set somewhere between 30 and 90 days. 5. Allow account lockout after a number of failed attempts Firewall-1 does not seem to allow account lockout - it's possible to fail authentication many times and still have a chance to successfully authenticate on the next attempt. Having account lockout configured would make password guessing pretty much worthless for an attacker. This account lockout is also standard practice in most modern OSes. A value of around 5 for this is fairly common. Roy Hills
This archive was generated by hypermail 2b30 : Wed Sep 11 2002 - 12:11:36 PDT