# Vulnerabilities in Checkpoint ICA Management Tool Written by [Mikhail Klyuchnikov](https://swarm.ptsecurity.com/author/mikhail- klyuchnikov/ "Posts by Mikhail Klyuchnikov") and [Nikita Abramov](https://swarm.ptsecurity.com/author/nikita-abramov/ "Posts by Nikita Abramov") on November 25, 2020  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...
# Vulnerabilities in Checkpoint ICA Management Tool Written by [Mikhail Klyuchnikov](https://swarm.ptsecurity.com/author/mikhail- klyuchnikov/ "Posts by Mikhail Klyuchnikov") and [Nikita Abramov](https://swarm.ptsecurity.com/author/nikita-abramov/ "Posts by Nikita Abramov") on November 25, 2020  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](https://community.checkpoint.com/t5/General- Management-Topics/ICA-Management-Tool/m-p/14674/highlight/true#M2629) Running the component without SSL 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…
