Further you will find a step-by-step writeup and a link to Metasploit module.
TL;DR:
- If you face iTop < 2.4.1 and log in with an unprivileged account, you can run my Metasploit module that will upload a shell for you.
- Vendor issued a patch and allowed me to publish the article.
iTop is a solution for IT Service Management. It allows administrators to manage user requests, incidents, and service catalog in a single web application. If you request a new SSD from IT Department, it will most likely appear as a ticket in iTop. When you will collect your hardware, system administrator will log into iTop and change status of SSD: “assigned to user httpsonly, desk 1337”.
Step 1: Log in by any means
During reconnaissance, I found a domain helpdesk.company.com:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifeQFVBklKTO6zlrzK5WTQP982NuN3Sf-ZY9aJYi9W0uHL3wAWJGgXPYLaXjG3UmGxTHGSsExAnFGxX04PRhXaqsLKH0Jgd5HASJ_qVrxU24T3DtKQpVby-LQp9DhGc4Jd26juYdw4pbpq/s400/2.png)
According to Documentation, Administrator of iTop can create local users or configure domain authentication:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjSpt-FxUqpAHT9teop-uLrhnpO9FrjMY9bOzFfaY1G38T3pPoAixV3cfj_2eTtC1dmhyphenhyphenGSXVm6wWJXrFpwbLyyQCEKUJLQjzuxOHvYWkFebBARm-JG4B7n-YYJblzDw_SU9_ZadjyT3dU6/s400/3.png)
In my case, I already had credentials of a domain user. Nothings stops you from trying to bruteforce passwords of local users: test:test, 111:111, user1:user1, backup:backup and so on.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiZYeINtXMEkId5hdrnFYtHv3F6arXwOV_HmONrwi4j2JEKE8GTr9EUhyaFPCuDGniuXFiYimclvYyq7hOO7Qi7p0OnOaATt7wdODBNe1uj8gKjL2xCU6FnGDrZsOJNHXT2PmNQuJs7mcHH/s640/4.png)
Cool! I am logged in as a low-level user.
Step 2: Exploit Indirect Object Reference
Low-level user can access any profile by specifying user id. Here we query user with id=1, which will likely have administrator rights. Server answers with a 302 redirect, but shows the content of the requested page.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhK2REAzfECfIxF5cY_0SR1xxlJVkQAKOQPZVwQQKUXpn-WWxldvAfLKtOccd3QQ_ehdIL1mlyw8Gr2u1n_WrJFahFeZcnd-LnzSE5rsujZvRiz9-veckxGoMUjVn1iDEQGXNZghtoxUwqB/s1600/5.png)
Cool! We have the username: “admin”.
Step 3: Change password of administrator
According to Documentation, iTop provides a powerful CSV Import feature to assist end-users (and administrators) in massively creating or updating objects in iTop.
Our low-level user does not have right to create users. Error about insufficient rights appears.
There is no error of insufficient rights if we update a password of existing user. 0day! (take a look at the patch).
Let’s try to exploit it.
During update, iTop’s parsing system correlates all POST data (first name, last name, email, login, etc) with parameters in a database: non-empty database parameters must match POST parameters. Sad, but we do not know all attributes of user admin (e.g. group membership) and cannot specify them.
Trick: if you tell iTop to copy all parameters from a given profile, it will set all non-empty parameters from profile with a given id – think of this action as a pointer to object with property “profileid=1”.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhs08hJjFHWw86yE4bLH8aFoWhQUjMXaYsJPxzwRFQ4dsSGxvDOR_3DIEQBRqVbdHqA4FFDAYBq24UK8qEkXPIHqfnnREl-sBWDbjVTQW54hQMz9wwBJkyC1nvMncLC-iq2xv_WxEjiQC5Z/s1600/6.png)
Password changed! You can find full HTTP query in my metasploit module.
Step 4: Login as admin
After we have changed administrator’s password, we can log in using new password:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipPHvQ_WUK8MTqtkEmu3Jgr4gx2_ZPCcaQPInxn3we9b6Q3UMoi4GgBEECyGLWtnDkLsDqHxW9YVzGJKUD2phMv4RUE9oRlhyphenhyphen2u3CFFdJjn2ke7gig1ACu3L2I1WrX8k1r4TPaaeFm0J0D/s640/7.png)
Step 5: RCE
Administrator can achieve RCE through ConfigEditor (functionality for editing iTop configuration file). You will be able to execute RCE and leave original configuration file unmodified.
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjGbrdTYxVd7nmu2BoU7cP_wa50cIisNqsJAQDKMSokUAPC3Jak8MTB7691wM-PYFxK3TbJnwj3q363xPNJnulQLbqh9CwLzBsgvn0zVtGjqw8YCBDEimNOVRtY4JjkUCN9Xj72YR4nyPJl/s1600/8.png)
After having RCE, I edited authentication script to record successful login attempts. The following string was added:
./application/loginwebpage.class.inc.php:
![](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4ZxsIpxpx5usRABrunvUa21nlaZOIZmtpWGkF5zQilXOV_9EqYvLzsRy7ruyW6VEsKN5KHsJPs0DTlq4PzCu36HAhFEja8kgqHDOLXqvl0wsNYTOqwQcUaklkkoYz9zK5SMMIZFaWfwi4/s1600/9.png)
Few days later, I got domain admin’s password in log.txt.