Pentest: 0day in iTop 2.4.0 gave me Domain Admin privileges

This article describes exploitation of a 0day RCE in webapp iTop 2.4.0. After getting a shell, I inserted credential sniffer, and next day walked away with a password of domain administrator.

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:

 

According to Documentation, Administrator of iTop can create local users or configure domain authentication:



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.



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.


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”.


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:
 
 


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.



After having RCE, I edited authentication script to record successful login attempts. The following string was added:

./application/loginwebpage.class.inc.php:


Few days later, I got domain admin’s password in log.txt.

0day writeup: XXE in uber.com

Hello everyone,

Today I’d love to share an interesting XXE in a popular product of Code42.com company, which could give access to backups of all users in a given company.

Back in May 2016, I was looking through Uber’s bugbounty, and faced following HTTP application:

Bruteforcing was surely not an option; there were no CVEs published of this vendor (you’ll discover later, why). After accessing https://backup.uberinternal.com:4285/api/serverEnv API it became clear that Uber was using last version of a product (5.2.0). The only option to break the service and get a bounty for pwning application was to find a 0day.

I quickly accessed Code42’s publicly available documentation, extracted all documented API methods and started bruteforcing them, trying to find which of such methods can be accessed without authentication. Likely, there was one API call, which can be accessed by any external user: https://www.crashplan.com/apidocviewer/#SsoAuthLoginResponse

Documentation clearly stated, that /api/SsoAuthLoginResponse accepts GET parameter SAMLResponse, which value is a base64-encoded string, and is meant to contain XML authentication data. I quickly constructed a trivial xml with external entities pointed to my VPS using non-standard port (since ports 80 and 443 were filtered by firewall), and got a response:

Despite exploitation string is pretty straightforward, I will not publish final HTTP request here.

It became clear, that server is vulnerable to XXE Out-of-Band (OOB) attack. Since application was using Java, I knew I could read directories, and hence I immediately launched xxe-ftp server to extract data. Greetz to guys at OnSec for coding xxe-ftp server! If you don’t know about XXE OOB exploitation, please read their research at http://lab.onsec.ru/2014/06/xxe-oob-exploitation-at-java-17.html

For those who don’t like clicking on external links, I am providing a quick description. This is how xxe-ftp server works: attacker's host has launched script, which works as HTTP server to retrieve OOB payload on port 8088, and a FTP server which accepts connections on port 8077:

As a proof-of-concept for Uber, I retrieved the contents of /home/ directory of the server, which was a nice impact illustration to my report at Hackerone:

Uber security guys were excited with this vulnerability: they contacted vendor and confirmed that this vulnerability was a 0day. What’s more, Uber team was engaged enough to ask me to elaborate the vulnerability.

I like to show impact of a given vulnerability, so you don’t have to ask me twice. Given permission to show further exploitation, I quickly found the folder, where backup logs were stored. Here is a screenshot of one of local files on the server, containing information about recently backup’ed user:

It was clear that I can read backup files of a little more than all domain accounts of a company, who has Code42 service at their perimeter.

In order to understand the impact of this 0day in the World, I searched for port 4285 in Shodan, and found that one of globally known security firms have this application installed on their perimeter:

May 6th, 2016 – Report sent to Uber through Hackerone

May 23rd, 2016 – Code42 company have updated their software, and vulnerability was patched in latest version (5.2.0.1)

Jun 28th, 2016 – Got $9000 bounty from Uber

Aug 24th, 2016 – Code42 asked to wait until update is installed on all their clients

Jan 24th, 2017 – Code42 notified that writeup will be published, no reaction.

This is a shortcut of our conversation in August 2016 (denial of responsibility):

“With regards to the blog post, we would prefer this is not written until our latest version of the product has been installed by all of our customers. This has been fixed in the latest release of the product, however, not all customers have it installed. We would prefer that you wait until that time to write about what you have found.”