Organizations using Check Point Firewall-1 or NG to provide remote user access (through SecuRemote or SecureClient software) are susceptible to active attacks through both IPsec (ISAKMP running on UDP port 500) and proprietary FWZ (RDP running on TCP port 259) avenues that enumerate valid usernames and collect interface and network topology information.
From a remote Internet-based perspective, attackers can perform username enumeration attacks against Check Point Firewall-1 4.1 and NG appliances that support aggressive mode IKE for authentication. Roy Hills of NTA Monitor (http://www.nta-monitor.com) demonstrated this issue in a post to the BugTraq mailing list during September 2002, mirrored at:
Roy wrote a utility called fw1-ike-userguess that enumerates valid Check Point SecuRemote users through UDP port 500. The tool isn't publicly available but is demonstrated in Example 11-4.
# fw1-ike-userguess --file=testusers.txt --sport=0 172.16.2.2 testuser User testuser unknown. test-ike-3des USER EXISTS testing123 User testing123 unknown. test-ike-des USER EXISTS guest User guest unknown. test-fwz-des User cannot use IKE test-ike-cast40 USER EXISTS test-ike-ah USER EXISTS test-ike-hybrid IKE is not properly defined for user. test-expired Login expired on 1-jan-2002.
Check Point released an advisory to tackle these issues (http://www.checkpoint.com/techsupport/alerts/ike.html), stating that hybrid mode IKE should be used where possible. You can find good technical information for configuring hybrid mode IKE when using Check Point Firewall-1 4.1 and SecuRemote at http://support.checkpoint.com/kb/docs/public/securemote/4_1/pdf/hybrid-2-10.pdf.
Check Point Firewall-1 and NG appliances can be found by running a service on TCP port 259 (as opposed to RDP, which runs on UDP port 259) that can be connected to using a telnet client that authenticates with the firewall.
After connecting to port 259 using telnet, enter a username and password combination. Depending on the response seen from the firewall, you can ascertain whether the username is valid.
If a valid username and invalid password are used, the response is:
User: fw1adm FireWall-1 password: ****** Access denied by FireWall-1 authentication User:
However, if an invalid username is used, the response is:
User: blahblah User blahblah not found User:
Interestingly, if a two-factor authentication mechanism (such as RSA SecurID) is used, a different prompt is displayed upon providing a valid username:
User: fw1adm PASSCODE:
Good background information about this issue can be found in the ISS X-Force, MITRE CVE, and SecurityFocus archives at the following locations:
Through TCP ports 264 (Firewall-1 4.1 or later) and 256 (Firewall-1 4.0 and earlier), you can enumerate the interface IP addresses of the target firewall and download topology information. Check Point Firewall-1 4.1 SP4 and earlier are susceptible to a handful of these issues.
Example 11-5 shows a tcpdump output taken when connecting to TCP port 264 of the target firewall (192.168.1.1) using telnet, entering two lines of random characters, and then disconnecting.
15:45:44.029883 192.168.1.1.264 > 10.0.0.1.1038: P 5:21(16) ack 17 win 8744 (DF) 0x0000 4500 0038 a250 4000 6e06 5b5a ca4d b102 E..8.P_at_.n.[Z. 0x0010 5102 42c3 0108 040e 1769 fb25 cdc0 8a36 Q.B......i.%...6 0x0020 5018 2228 fa32 0000 0000 000c c0a8 0101 P."(.2.......M.. 0x0030 c0a8 0a01 c0a8 0e01 ........
The bytes of interest are in bold, which translate to the following IP addresses:
These addresses are the interfaces of the firewall, which you could use to perform reverse DNS sweeping (resolving internal IP addresses to hostnames) against accessible name servers or other attacks. Background details relating to this information leak issue can be found in MITRE CVE with the reference CVE-2003-0757.
In July 2001, Haroon Meer of SensePost (http://www.sensepost.com) identified an unauthenticated vulnerability within Firewall-1 4.1 SP4 that allowed attackers to download network topology information from the target firewall running in its default configuration. He published a Perl script that can gather this information, which is available at http://www.securityfocus.com/data/vulnerabilities/exploits/sr.pl.
Example 11-6 shows the script being run from a Unix command prompt. Details of supported protocols are given (FWZ and ISAKMP in this case), along with interface IP addresses and other information.
# perl sr.pl firewall.example.org Testing firewall.example.org on port 256 :val ( :reply ( : (org.example.hal9000-126.96.36.199 :type (gateway) :is_fwz (true) :is_isakmp (true) :certificates ( ) :uencapport (2746) :fwver (4.1) :ipaddr (188.8.131.52) :ipmask (255.255.255.255) :resolve_multiple_interfaces ( ) :ifaddrs ( : (184.108.40.206) : (220.127.116.11) : (18.104.22.168) : (22.214.171.124) ) :firewall (installed) :location (external) :keyloc (remote) :userc_crypt_ver (1) :keymanager ( :type (refobj) :refname ("example.org") ) :name (org.example.hal9000-126.96.36.199) :type (gateway) :ipaddr (172.29.0.1) :ipmask (255.255.255.255) )
Details of this vulnerability and further supporting information are available from the MITRE CVE, SecurityFocus, and ISS X-Force archives at the following locations:
The Check Point Reliable Data Protocol (RDP) service listens on UDP port 259: it's used by the firewall to receive encapsulated FWZ VPN traffic. It's possible to use spoofed UDP packets and fake RDP headers to bypass firewall rules and access the internal network.
Check Point Firewall-1 4.1 SP3 and prior are susceptible to this issue by default. Within SP4 and later, RDP communication is blocked by default. The official Check Point advisory regarding this issue is accessible along with further background reading from the following locations: