[Full-disclosure] [CVE-2014-1673] Check Point Session Authentication Agent vulnerability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Product Information - --- Check Point Session Authentication agent is a service that is installed on endpoint system in order to communicate with security gateway and allow it to request and obtain user's credentials. Session Authentication is a part of Legacy Authentication suite which provides different authentication methods to allow or deny access to network resources. R76 Security Gateway Technical Administration Guide[1] defines typical Session Authentication operation in the following way: 1. The user initiates a connection directly to the server 2. The Security Gateway intercepts the connection 3. The Session Authentication agent challenges the user for authentication data and returns this information to the gateway 4. If the authentication is successful, the Security Gateway allows the connection to pass through the gateway and continue to the target server Issue description - - Check Point Session Authentication agent version 4.1 and higher contains a flaw which is caused by lack of peer authentication in SSL communication. Encrypted communication between agent and security gateway has been introduced due to several issues (e.g. [2], [3]) which were revealed in the previous versions (4.0 and lower) of the product. Research showed that it is still possible to exploit previously known vulnerabilities - gateway impersonation and credential stealing - even though communication between agent and security gateway is utilizing SSL. Communication between Session Authentication agent and security gateway is performed using proprietary protocol. Since version 4.1 this communication scheme uses SSL as an underlying protocol to enable encryption of both protocol commands and user provided data. When SSL communication is negotiated between gateway and agent following cipher suites are visible in SSL Client Hello message as supported by Session Authentication agent: TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 TLS_DH_anon_WITH_RC4_128_MD5 TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA RFC2246 refers to listed cipher suites: "The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated." Taking into account above information it's possible to connect to Session Authentication agent from attacker's machine, initiate SSL-based communication, pass SSL handshake without being authenticated and use encrypted channel to control agent (e.g. prompt user for login and password). For attack to be successful attacker's machine must be allowed to connect to machine on which agent is running. Newer versions of Session Authentication agent include option to define three IP addresses which are allowed to issue authentication requests to agent. When this option is used it limits possibility of exploitation. Agent software has also "Allow any IP" option - when enabled attacker doesn't need to take additional measures in order to be able to connect to agent. Proof of Concept - Attached PoC script simulates security gateway and allows credential stealing to be performed over encrypted communication channel against Session Authentication agent version 4.1 or higher. Affected versions - - Check Point Session Authentication agent, version 4.1 and higher Vendor response - --- Vendor has been informed about the issue on 8/8/2013. On 14/8/2013 vendor informed about expected fix date: 15/10/2013. On 28/10/2013 vendor informed that due to small user base and introduction of the Identity Awareness Software Blade[4] legacy session authentication will be deprecated in the major release of 2014. Additionally vendor published SecureKnowledge article[5]. Credits - --- It should be noted that this finding is partially based on work of individuals who reported issues in the previous versions of Session Authentication agent as referenced in [2] and [3]. References - -- [1] https://sc1.checkpoint.com/documents/R76/CP_R76_SGW_WebAdmin/6721.htm [2] http://www.securityfocus.com/bid/1661/info [3] http://osvdb.org/show/osvdb/84985 [4] https://www.checkpoint.com/products/identity-awareness-software-blade/ [5] https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98263 -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJS5tZHAAoJEO2gMNQgkP1iucwP/3ruK6iKIm6FvQ6DJsCVFMn1 98iWrXvU5jG0krKERu2Q2L3EkElvfq4reSeceIuVqpS20v69cCHCMKofFVaFeK2a 0Bo2zIqjnAr/T2/7DYwI1dgdZE4SAzcEscqeA8Zh6Hi04wME+sJpYxsq0lb7u2jY FuuqbUo5R4Y2hGXNoc0wKhiVhrOJ10DhvZaug+wbenX3721v+QqYzS+PUnql1WG3 4sSevvZM5Plb+aRh
[Full-disclosure] Check Point ClusterXL/CCP issue (DoS)
Hi List, Recently I found issue with ClusterXL/CCP operation on Check Point gateways - you can find details below: Issue description - Issue occurs when specially crafted CCP packets are send to all Check Point ClusterXL cluster members. This causes clustered gateway to be confused about state of its peer(s) which can lead to situation when all cluster members end up in Ready/Standby state. Such case leads to denial of service where none cluster member will forward network traffic. For attack to be successful attacker must be able to sniff CCP traffic which requires him/her to have direct access to broadcast domain in which "Sync" or "Cluster + Sync" interfaces are located. In many cases this requirement may considerably limit attack surface. Issue concerns following ClusterXL modes: * New High Availability * Load Sharing (Unicast) * Load Sharing (Multicast) Product information --- Issue affects operation of ClusterXL clusters utilizing CCP as underlying protocol. "ClusterXL Administration Guide R75" defines ClusterXL and CCP in the following way: (page 8) "A ClusterXL cluster is a group of identical Check Point Security Gateways connected in such a way that if one fails, another immediately takes its place. ClusterXL is a software-based Load Sharing and High Availability solution that distributes network traffic between clusters of redundant Security Gateways and provides transparent failover between machines in a cluster." (page 9) "The Cluster Control Protocol (CCP) is the glue that links together the machines in the Check Point Gateway Cluster. CCP traffic is distinct from ordinary network traffic and can be viewed using any network sniffer." Technical details - High level description of the attack can be summarized in the following steps: 1. Sniff for all CCP packets generated by cluster members 2. From all sniffed packets select only "CCP Report source machine's state" packets (opcode = 1) 3. For each selected packet set all payload bytes to 0 4. Send back packet to wire leaving all other fields untouched Ad 1. CCP runs over UDP and utilizes port 8116 for both source and destination. Note that in most configurations CCP packets are send also on interfaces which are not defined as "Sync". Ad 4. Especially following fields should match those from original frame: * CCP header fields * Source MAC should match following pattern: 00:00:00:00:magic_number:member_id, where magic_number in default configuration equals to 0xfe, member_id can be random * Destination MAC in multicast mode should match 01:00:05:xx:yy:zz where xx:yy:zz reflects last 3 octets of cluster virtual IP Attached PoC consists of two files: * `ccp-kill.rb` - actual PoC code. It takes only one argument - interface name on which it will sniff and send CCP packets. It has been tested on BackTrack 5R3 with Ruby 1.8 and requires following Ruby gems: Racket, Pcaprub. * `ccp.rb` - extension file for Racket describing CCP protocol fields (based on Wireshark CCP dissector). It needs to be placed in `lib/racket/l5` dir where Racket gem is installed Running PoC on network where cluster "Sync" or "Cluster + Sync" interfaces are located will cause cluster members transitioning from Active/Standby or Active/Active states to Ready/Ready (Load Sharing) or Ready/Standby (New High Availability). In this scenario none of cluster members will handle network traffic which is utilizing cluster virtual IP address as a gateway. Affected versions - So far tests have been performed on SPLAT-based R75 Check Point gateway installation reporting following version: R75 - Build 254 and CCP packets reporting following version: 2000. My (uneducated) guess is that at least other versions from R75 line would behave in presented manner. Vendor response --- Vendor has been informed about the issue and came back with following response: "Check Point Cluster Control protocol is assumed to be sent over a trusted network. Customer may achieve this by using a dedicated physical network segment or by using VLANs. It is the responsibility of the customer to ensure that the network is trusted." Additionally vendor confirmed that in future releases packet digital signatures for CCP will be introduced. Workaround/solution --- Vendor response as well as already mentioned "ClusterXL Administration Guide R75" (page 11) give hints about proper network design that will minimize possibility of the attack. Especially running "Cluster + Sync" interfaces which usually mix both sync and 'normal' network traffic should be avoided. -- Regards, JJ ccp.rb Description: application/ruby ccp-kill.rb Description: application/ruby signature.asc Description: OpenPGP digital signature ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-c
