Checkpoint FW-1 flaw background
Summary
1. Username Guessing: Affected versions of Checkpoint Firewall-1 permit remote users to determine if a Firewall username is valid without having to know the associated password. This allows a hostile user to guess valid usernames by using a dictionary attack where a list of potential usernames are submitted to the Firewall one by one to check if they are valid.
2. Username Sniffing: The VPN (virtual private network) usernames are passed in the clear without encryption. Therefore anyone who is able to sniff network traffic between VPN clients and the Firewall can observe the usernames in transit.
Systems Affected
Systems running Checkpoint Firewall-1 versions 4.0, 4.1, NG, NG FP1 and NG FP2 that use the IKE (Internet Key Exchange) [4] encryption scheme (known as ISAKMP/Oakley in v4.0) with shared secret authentication for remote user VPNs with SecuRemote / SecureClient.
Firewall-1 versions prior to 4.0 (e.g. 3.0b) are not affected because the IKE encryption scheme was not introduced until v4.0. Firewall-1 versions 4.1 SP2 [6] and NG FP1[7] have been certified to ITsec E3 level with the VPN capability of the Firewall included in the TOE (target of evaluation). Although version 4.0 is also certified to ITsec E3 [5], the TOE for 4.0 excludes the VPN feature and therefore the VPN facility of Firewall-1 v4.0 is not ITsec certified.
Issue Details
Username Guessing
The username guessing issue involves attempting to authenticate with the Firewall using IKE (Internet Key Exchange) [4] which is a standard protocol that forms part of the IPsec (IP Security) architecture [1]. If a remote user sends an appropriately constructed IKE packet to the Firewall containing the username to be tested, the Firewall will indicate whether that user is valid or not in it's reply packet. It is not necessary to send a password to obtain the reply from the Firewall.
The correct approach would be to wait until both the username and the password (shared secret) have been sent and then, if either is incorrect, to send a generic error message indicating that authentication had failed without detailing whether the username, password or both were incorrect. In this way, and attacker is not able to determine if a given username is valid without also knowing the associated password. This technique is standard security practice in many other authentication mechanisms including Unix login.
It is well known that users and system administrators often choose weak passwords, so once valid usernames are guessed or sniffed, it is likely that the attacker will be able to guess the password to one or more of these and thus gain access to the VPN. As many (perhaps most) VPN configurations allow full access to the company's internal network behind the Firewall, this could allow the attacker full access to the company resources.
As the Firewall does not normally restrict who can attempt to authenticate with it using IKE, this issue can be exploited by anyone on the Internet.
It was observed that the Firewall does not impose any limits on how many times a given host can attempt to authenticate and that the packet exchange required to check a username was very quick. This means that it is possible to use this issue to check a large username dictionary in a relatively short time. Tests using a program written to investigate this issue showed that over a 64Kbit/s serial connection, it took 12 minutes to check 10,000 usernames for a rate of about 14 guesses per second; over a 2Mbit/s link, it took 2 minutes 30 seconds to check the same 10,000 user dictionary for a rate of about 67 guesses per second.
For the rate tests, we used Firewall-1 v4.1 SP6 running on NT Server 4.0 SP6a on an AMD Duron 800MHz CPU with 128MB RAM. There was a serial link composed of two back-to-back Cisco routers joined with a DCE/DTE cable between the Firewall and the test system. When the serial link was running at 64Kbit/sec, the observed serial usage was 41Kbit/sec from the test system to the Firewall and the Firewall CPU loading was steady at 15% during the test. This shows that for a 64Kbit/sec link, the bandwidth is the limiting factor. With a 2Mbit/sec link, the observed usage was 210Kbit/sec and the Firewall CPU loading was steady at 95% showing that the limiting factor for a 2M link was the Firewall CPU. A faster Firewall CPU would allow a faster guessing rate with high-speed links.
In addition to just indicating whether a username is valid or not, Firewall-1 versions 4.0, 4.1 and NG (but not NG FP1 or NG FP2) will send a text string for invalid users indicating why the username is not valid for IKE. Examples of observed strings together with their meanings are:
- 1. "User testuser unknown." - User doesn't exist
- 2. "User cannot use IKE" - User exists but doesn't use IKE. Maybe uses FWZ or plain authentication.
- 3. "Login expired on 1-jan-2002.\n" - User exists but the account expired on the date shown.
- 4. "IKE is not properly defined for user." - User exists but IKE is not properly configured e.g. no shared secret.
For these versions, the issue is even worse because they leak more information which could be useful to an attacker. For example by indicating that a username does exist but does not use IKE, the Firewall tells the attacker that this is a valid username that could be exploited using another encryption scheme (such as FWZ) or plain authentication.
Username Sniffing
If shared secret authentication is used with IKE aggressive mode, the identity is passed in the 1st packet which must be in the clear because the key exchange has not completed at this point so encryption cannot be used. SecuRemote uses the username for the identity in this 1st packet and therefore the username is passed in the clear.
This ID sniffing issue is to some extent inherent in IKE aggressive mode because the ID must be passed in the clear. The problem here is that many users will not realise the potential issue and will therefore have a false sense of security.
This username sniffing issue has the same potential weak password issue as the username guessing issue mentioned above, with the same possible end result of full access to the company network via the VPN.
The vendor, Checkpoint and CERT/CC have been notified prior to public release. Bugtraq listing http://online.securityfocus.com/archive/1/290202/2002-09-01/2002-09-07/0
References [1] RFC 2401 Security Architecture for the Internet Protocol [2] RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP [3] RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP) [4] RFC 2409 The Internet Key Exchange (IKE) [5] ITsec report for v4.0 http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/crp107.pdf [6] ITsec report for v4.1 SP2 http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/CRP149.pdf [7] ITsec report for NG FP1 http://www.cesg.gov.uk/assurance/iacs/itsec/cpl/media/certreps/crp166.pdf