From xforce@iss.net Fri Oct 6 09:20:00 2000 From: X-Force Resent-From: mea culpa To: alert@iss.net Resent-To: jericho@attrition.org Date: Wed, 27 Sep 2000 15:56:50 -0400 Subject: ISSalert: ISS Security Alert: Multiple vulnerabilities on all platforms and versions of Check Point FireWall-1 TO UNSUBSCRIBE: email "unsubscribe alert" in the body of your message to majordomo@iss.net Contact alert-owner@iss.net for help with any problems! --------------------------------------------------------------------------- -----BEGIN PGP SIGNED MESSAGE----- Internet Security Systems Security Alert September 27th, 2000 Multiple vulnerabilities on all platforms and versions of Check Point FireWall-1 Synopsis: On July 26th, Thomas Lopatic, John McDonald, and Dug Song released vulnerability information at the Black Hat 2000 briefings that exposed the following security holes in Check Point FireWall-1: 1. One-way Connection Enforcement Bypass 2. Improper stderr Handling for RSH/REXEC 3. FTP Connection Enforcement Bypass 4. Retransmission of Encapsulated Packets 5. FWA1 Authentication Mechanism Hole 6. OPSEC Authentication Spoof 7. S/Key Password Authentication Brute Force Vulnerability 8. GetKey Buffer Overflow Details: 1. One-way Connection Enforcement Bypass Any source from any security region passing the rule-base may be able to make unauthorized connections through the firewall that would otherwise be blocked by this additional security layer of FireWall-1. By using specially fragmented TCP connection requests or by closing and re-opening one-way TCP connections in conjunction with certain complex multi-connection protocols, an attacker can bypass the directionality check. All implementations of Check Point FireWall-1 prior to the new service packs that allow protocols employing unidirectional data flow connections (such as FTP and RSH STDERR) are vulnerable. 2. Improper stderr Handling for RSH/REXEC A malicious external source can open an unauthorized connection to an internal protected RSH/REXEC client by sending specially formatted stderr connection requests (as an RSH/REXEC server) to the client. These connection attempts are mishandled by FireWall-1 and are allowed through, giving connection access for possible exploitation. This attack may lead to a compromise of integrity, including relay access on targeted machines, by taking advantage of the connected service. All implementations of Check Point FireWall-1 prior to the new service packs that have explicitly enabled the VPN-1/FireWall-1 RSH/REXEC property are vulnerable. 3. FTP Connection Enforcement Bypass A malicious source can use this vulnerability to redirect connections to other systems accessible to the FTP server "bounced" off of. By exploiting the standard "FTP Bounce" attack, while advertising a small maximal segment size (server replies being split) in PASV handling of FTP, an attacker can successfully "bounce" connections off the available FTP server through the FireWall-1 daemon. This form of exploit is often used as a form of IP spoofing to obscure the source of an attack to other targets, and as a way to gain access to assets that are accessible, passing the rule-base, to the targeted FTP server. All implementations of Check Point FireWall-1 prior to the new service packs that have "FTP bounce" vulnerable FTP servers available for inbound connection with write access and do not have the latest service packs or patches to this vulnerability are susceptible to this attack. 4. Retransmission of Encapsulated Packets Any source may be able to send packets that pass normal rule-based and anti-spoofing checks, if setup and enabled, through the firewall without being an FWZ client. By sending a payload of specially encapsulated FWZ packets that match a rule in the FireWall-1 rule base, a malicious source can effectively spoof through the firewall as a FWZ client. All versions and implementations of Check Point FireWall-1 prior to the new service packs are vulnerable. 5. FWA1 Authentication Mechanism Hole An attacker may successfully compromise the authentication mechanism (but not compromise the connection encryption thereafter), and possibly flood the mechanism with successful authentications, theoretically denying service. As part of the FWA1 authentication, the server starts by sending the client a random number and a hash of the random number plus the shared secret key. The client is then required to send the server a different random number and a hash of the random number sent by the server, XORed with the client's random number's power, plus the secret key. By using 0 as the client's random number, a malicious attacker can subvert authentication (since the server's random number XORed with zero will equal itself and therefore produce the same hash sent to the server in the first step of the protocol). Although this subverts authentication, it doesn't expose the secret key and therefore prevents further transmission. All implementations prior to the new service packs, having rules that allow control connections from un-trusted sources or users. In version 4.1, by default, FW-1 control connections are allowed only from systems defined as having FireWall-1 installed on them. 6. OPSEC Authentication Spoof A remote attacker can effectively authenticate to any OPSEC channel that it is allowed to communicate with under the rules base, giving full access to any services allowed therein. For authentication, the OPSEC protocol sends a random number and a hash of the random number plus the shared secret key to the client. The client is then expected to verify the key by adding the random number to the previously known secret key, performing the same hash, and comparing it to the one received. The client then authenticates by sending what is assumed to be a different random number, in addition to their own hash of the secret key plus their random number. The server then performs the same verification, successfully authenticating the client's knowledge of the secret key and granting access. To compromise this authentication, an attacker initiates a connection, receiving the initial random number and hash from the server. The authentication process of the server is skipped, because the secret key is unknown, and the messages are replayed back to the server. The server does not verify if the random number chosen by the client is different and authenticates the previously sent message successfully, granting access to the malicious user. All implementations of Check Point FireWall-1 prior to the new service packs and those that don't constrain OPSEC communication to specifically trusted source/destinations pairs via the rule base are vulnerable to this attack. 7. S/Key Password Authentication Brute Force Vulnerability An attacker can use this vulnerability to gain user intermodule access through VPN-1 or any other access vector using this authentication in FireWall-1. As part of the FireWall-1 S/Key authentication protocol, an index number is sent to the client. The client then authenticates by sending the secret key, hashed the index number of times, back to the server. By utilizing brute force techniques, an attacker could determine the secret key by intelligently trying all possible secret keys in the given keyspace. Upon determining the secret key, the attacker will also gain authentication to all available assets. All implementations of Check Point FireWall-1 prior to the new service packs and those that use S/Key for inter-module authentication are vulnerable. Note that all 4.1 installations use FWA1 by default and are therefore not vulnerable unless the administrator specifically weakened the inter-module authentication mechanism from FWA1 to S/Key. 8. GetKey Buffer Overflow An attacker can use this vulnerability to terminate the firewall daemon, leaving the current policy intact. This represents a possible threat of integrity compromise to all assets available via policy that would otherwise not be available given other checks and services available with the firewall daemon actively running. Due to insufficient bounds checking and handling in the intermodule communication protocol, specifically within the GetKey procedure, an attacker can exploit this vulnerability by sending a specially-crafted instruction to overflow the buffer and cause the firewall daemon to terminate, leaving policy enforcement operational. All implementations of Check Point FireWall-1 prior to the new service packs or patches to this vulnerability are vulnerable. Affected Platforms: All platforms on which Check Point's FireWall-1 product is available are vulnerable to these attacks. They are platform independent, existing completely within the FireWall-1 application. Recommendations: Check Point has released service packs VPN-1/FireWall-1 4.0 SP7 and VPN-1/FireWall-1 4.1 SP2 that eliminate each of these vulnerabilities. For VPN-1 Appliances (IPSO) running version 4.0, the service pack is version 4.0 SP5 Hotfix. Service Pack information, download access, and a description of how these vulnerabilities are addressed can be accessed at: http://www.checkpoint.com/techsupport/alerts The ISS X-Force will provide additional functionality to detect these vulnerabilities in upcoming X-Press Updates for Internet Scanner and RealSecure. Additional Information: Supplemental technical notes on these vulnerabilities are available at: http://www.dataprotect.com/bh2000/blackhat-fw1.html The Common Vulnerabilities and Exposures (CVE) project has assigned the following names to these issues. These are candidates for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. CAN-2000-0804 One-way Connection Enforcement Bypass CAN-2000-0779 Improper stderr Handling for RSH/REXEC CAN-2000-0813 FTP Connection Enforcement Bypass CAN-2000-0805 Retransmission of Encapsulated Packets CAN-2000-0806 FWA1 Authentication Mechanism Hole CAN-2000-0807 OPSEC Authentication Spoof CAN-2000-0808 S/Key Password Authentication Brute Force Vulnerability CAN-2000-0809 GetKey Buffer Overflow ______ About Internet Security Systems (ISS) Internet Security Systems (ISS) is a leading global provider of security management solutions for the Internet. By providing industry-leading SAFEsuite security software, remote managed security services, and strategic consulting and education offerings, ISS is a trusted security provider to its customers, protecting digital assets and ensuring safe and uninterrupted e-business. ISS' security management solutions protect more than 5,500 customers worldwide including 21 of the 25 largest U.S. commercial banks, 10 of the largest telecommunications companies and over 35 government agencies. Founded in 1994, ISS is headquartered in Atlanta, GA, with additional offices throughout North America and international operations in Asia, Australia, Europe, Latin America and the Middle East. For more information, visit the Internet Security Systems web site at www.iss.net or call 888-901-7477. Copyright (c) 2000 Internet Security Systems, Inc. Permission is hereby granted for the redistribution of this Alert electronically. It is not to be edited in any way without express consent of the X-Force. If you wish to reprint the whole or any part of this Alert in any other medium excluding electronic medium, please e-mail xforce@iss.net for permission. Disclaimer The information within this paper may change without notice. Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties with regard to this information. In no events shall the author be liable for any damages whatsoever arising out of or in connection with the use or spread of this information. Any use of this information is at the user's own risk. -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQCVAwUBOdJQsDRfJiV99eG9AQGQiQQAopmqRgya3aUWYWmlhGpij4SOtHuiVcI+ PADRttRWykRPrh5qy8PE3kRJYGWMTuzpscV0tP8f66v+rOD03MWlg+N3YILiYMml XzU7a1kuEB6cUX1A9BFTtPa68SwaW+fP+8NyY1KdQtA5ZpN2iD0FoBhkh6cJxvMT DmTk+IGiN0w= =cbAB -----END PGP SIGNATURE-----