[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SecuRemote usernames can be guessed or sniffed using IKE exchange
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
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
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
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.