[ Beneath the Waves ]

Hack the Planet

article by Ben Lincoln


This article provides an overview of publicly-disclosed vulnerabilities I've discovered (or helped discover) in third-party products while conducting network penetration tests, red team engagements, and similar activities (as well as personal research). It does not include any discussion of vulnerabilities I've found in first-party products - that is, products made by the organizations who paid for the pen tests.

I've also included notes about third-party products that I've written password-decryption utilities for. I have mixed feelings about whether these are actually "vulnerabilities", because in some sense, any tool that needs to authenticate to other systems is going to be "vulnerable" to having that authentication misused by an attacker who compromises the system. However, I don't think there's any doubt that it's a valuable post-exploitation technique, and I'm very fond of doing it in order to capture additional credentials.

Publicly-Disclosed Vulnerabilities

OSVDB-94707 - Motorola Droid X2 Cloud Service Information Disclosure

I didn't even know about this one until I did a web search for my name and "vulnerability". This is based on my (now old) Motorola Is Listening writeup, which got some decent press at the time.

CVE-2015-5082 - Endian Firewall OS Command Injection

I discovered this one while working on my OSCP certification. Endian is a fork of IPCop. One of the built-in features is web proxy for granting internet access to internal users. The web interface includes a custom page which allowed those users to change their proxy password. Almost a decade's worth of Endian Firewall releases were vulnerable to OS command injection via the password fields. Except for very early versions, no web interface credentials were required - only a valid proxy password. OS command execution was as the nobody account, but that account had been granted permission to run a script which would change the password for root to an arbitrary value. This would grant complete control over the system to the attacker.

I originally created a Python proof-of-concept exploit script, and then a basic Metasploit module that take advantage of the vulnerability. With some minor modifications, I was able to get the Metasploit module accepted into the mainline Metasploit codebase.

CA20160721-01 / CVE-2016-6151 / CVE-2016-6152 - CA eHealth OS Command Injection

This pair of authenticated OS command injection vulnerabilities were discovered during a live pen test in 2015. I can't provide additional details publicly at this time.

CVE-2016-3547 / CVE-2016-3548 - Oracle E-Business Suite

In Oracle's idiosyncratic "non-disclosure disclosure" language, these are described as "Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle One-to-One Fulfillment. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle One-to-One Fulfillment accessible data." and "Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Marketing. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Marketing accessible data.". Amusingly, they're assigned identical CVSS 3.0 base scores even though one of them is significantly easier to exploit. I found them during a live pen test in 2015. Supposedly they're addressed in Oracle Critical Patch Update Advisory - July 2016 for EBS.

I also reported a more serious issue which - by the time the discussion took place in 2016 - had allegedly been filed by someone else as CVE-2016-0567. This one is described as "A remote user can exploit a flaw in the Oracle E-Business Intelligence Embedded Data Warehouse component to partially access data", which is a true statement, but contains little useful information about the severity of that issue.

While Oracle makes the releases of their products available for download, the same is not true for security updates, and so I'm unable to comment on whether that was actually the same issue, or whether the vulnerability was addressed by the Oracle Critical Patch Update - January 2016 for EBS as claimed.

I can't provide any additional details publicly at this time, but I will say that EBS administrators should just go ahead and apply all of the security updates on a regular basis. I'm sure EBS is not fun to patch, but based on the way my discoveries were reported, the issues are a lot worse than one would think just based on reading the release notes.

CVE-2017-5230 - Hardcoded Java Keystore Password in Nexpose

I didn't discover this one - Noah Beddome and Justin LeMay did. I just gave them a hand writing code to take advantage of it. Building utilities to decrypt credentials stored locally (whether they're encrypted with a fixed key or not) is one of my specialties, and I have a lot of practice at it. Rapid7 has a lengthy writeup, and NCC Group has a detailed discussion as well.

Disclosure Evidence Screenshots
[ CVE-2016-3547 / CVE-2016-3548 - Oracle EBS ]
CVE-2016-3547 / CVE-2016-3548 - Oracle EBS
[ CVE-2016-6151 / CVE-2016-6152 - CA eHealth ]
CVE-2016-6151 / CVE-2016-6152 - CA eHealth
[ CVE-2017-5230 - Nexpose ]
CVE-2017-5230 - Nexpose

Screenshots of web content that may no longer be publicly available.


Undisclosed Vulnerabilities

I am personally a proponent of the "full disclosure" approach, including exploit code (if it exists). Pen testers are only able to do our jobs because other people contributed that kind of knowledge to the public. Additionally, without the details, the actual severity of an issue may be unclear to system owners - especially in the case of companies with extreme redaction policies, such as Oracle.

However, I also respect the policies of the companies I've worked for, and in many cases, that means that the information remains behind closed doors. I have a lot of third-party vulns that fall under that umbrella. In order to catalogue my experience in this area, this section contains details about the types of issues I've found and disclosed to vendors, while not actually identifying the vendor or the product. Company and product names in this section are typically randomly generated using A Black Path Toward The Sun or the NSA Product Generator. I've tried to limit the information in this section to just things that are novel in some way, like vulns that I discovered which led to RCE.

Undisclosed Vulnerabilities - 2012

In 2012, I was working on the internal security team at a fairly large company that I'll refer to as the Concordance Extraction Corporation, because I'm a big fan of Dead Space.

ANGRY PLOW MOROSE SEAGULL - MOROSE SEAGULL was a telecom application which was vulnerable to a host of issues. The highlights included SQL injection leading to RCE as a superuser on the host OS (via xp_cmdshell), and the use of a bizarre password-storage mechanism that was sort of halfway between hashing and Caesar-cipher encryption, incorporating the least-secure features of both. The transformation was length-preserving, but multiple input values would transform to identical output values. For example, MYpass, MspaYY, and MspaYs would all result in the same quasi-hash. If I recall correctly, this was the second time I ever wrote a password-decryption utility.

KIND OF LIKE A MANGO, I GUESS? REDFELONY - REDFELONY was another telecom product. This one had fewer easily-exploitable issues overall than MOROSE SEAGULL, but it had one of the most baffling components I've ever seen: a TCP network service which would concatenate any data it received into a Linux shell command which executed directly as the database service account. This was trivially exploitable via command injection to get a shell on the device.

ARKCHEF SLEEPY SEAGULL - SLEEPY SEAGULL was an enterprise batch-job scheduling tool. It stored credentials locally on systems with the agent installed. Years earlier, I had put together my first password-decryption utility for an earlier version of the product which used essentially a Caesar cipher. In 2012, my coworker Avik and I wrote several decryptors (using different techniques) to obtain the passwords from the current version of the product.

Undisclosed Vulnerabilities - 2013

ARKCHEF SLEEPY SEAGULL - I revisited SLEEPY SEAGULL and its proprietary communication protocol (which defaulted to plaintext) this year. Technically, TLS was supported, but it was extremely laborious to enable. In the default configuration, it would send the username and password to use when executing certain functions. An attacker with knowledge of the password-encryption algorithm could obtain the password in this way, but there was an even more severe problem: the remote system didn't actually use the password that was sent. It would simply switch user contexts based on the username. As a result, one could send a message with the username field set to root, and execute arbitrary commands as a superuser - i.e. unauthenticated RCE.

Undisclosed Vulnerabilities - 2014

DEITYARTIST LATENTSPORK - LATENTSPORK was a DevOps product. I found an XXE vulnerability in it which could be used to read arbitrary text files from the host OS. Because it was a Java application, it would also return directory listings, allowing an attacker to spider through the host OS filesystem looking for interesting content. I found an upgrade log created by the product which included the PostgreSQL system administrator password in plaintext. The database service was accessible remotely, so I was able to log on remotely and use the SA privileges to upload and enable a custom UDF which allowed OS command execution in order to get a shell on the server. This experience was why I wrote On The Outside, Reaching In.

KIND OF LIKE A MANGO, I GUESS? ANGRYMAESTRO - I tested the then-current version of ANGRYMAESTRO (another telecom product) in preparation for it to be deployed. The most severe issue was an undocumented, anonymously-accessible JSP page which would decompress zip archives that were POSTed to it. Like so many Java applications, it didn't prevent directory traversal via crafted zip files, so it was possible to upload an archive that would add additional JSPs into web-accessible locations - in other words, unauthenticated RCE (as a superuser). It also included multiple cross-site scripting vulnerabilities and a host of lesser problems. KIND OF LIKE A MANGO, I GUESS? sat on my report for eleven months before claiming that they'd lost it, even though something like ten of their employees had copies.

Undisclosed Vulnerabilities - 2015

MOONCHEF LINEARGIRL - LINEARGIRL was an Oracle EBS-like framework that's designed to make it somewhat easier for enterprise developers to build web applications without having to start from scratch. Normally I wouldn't consider this one worth mentioning, because all I found were a stored XSS vuln and some missing authorization checks, but I was particularly pleased with the PoC I made for the stored XSS to demonstrate the risk to the team that was implementing the product. When triggered, it would wait a random amount of time, then pop up one of several exact replicas of the logon screen, as if the user's session had timed out. This was done with a multi-stage XSS payload due to field-length limitations. If the user entered credentials, they'd be sent to a (simulated) malicious server, and their browser profile captured. I was intending to use this as the basis for a reusable internal tool (for demonstrating the severity of XSS vulnerabilities, phishing, etc.), but left the company before I had time.

In the middle of 2015, I switched jobs and began working for a security consulting company that I'll refer to as the Weyland-Yutani Corporation, because I'm a also big fan of the first few Alien films.

SOMBERBOUNCE KINEMATIC SUGARCOATING - KINEMATIC SUGARCOATING was a telecom product with a web interface. I was able to discover arbitrary file read and write vulnerabilities which were accessible after authentication during a red team engagement. The file-write vuln could (with enough effort) be used to upload a malicious JSP to get RCE on the system. I also wrote two password-decryption utilities in order to use its stored credentials for pivoting. This experience was one of two which eventually led to the development of A Black Path Toward The Sun.

Undisclosed Vulnerabilities - 2016

SEAGOING CATFISH - SEAGOING CATFISH was an open-source tool. My coworker Jessica had found an outdated instance of the tool in an NPT we were working on, and it was vulnerable to an existing CVE that let unauthenticated users download a backup of the application database. However, most of the interesting content was encrypted using a random key that was not stored in the database. I was able to discover a separate issue which allowed retrieval of the key. Decrypting the data eventually got us control over the entire environment.

REVERSION GUARANTEED - REVERSION GUARANTEED was a continuous integration application. I didn't find any vulns in the product itself, but I wrote a password decryptor for it in order to pivot during an NPT.

TACITURN MISSTATEMENT - TACITURN MISSTATEMENT was an open-source monitoring tool. I found an instance of it on a developer's laptop during a red team engagement. I was able to find seven distinct vulnerabilities in the software which could be combined to get unauthenticated RCE.

Undisclosed Vulnerabilities - 2017

SOMBERBOUNCE KINEMATIC SUGARCOATING - I revisited a newer version of KINEMATIC SUGARCOATING and discovered a set of LPE vulns that could be used to escalate to superuser access by an attacker who had access to the limited shell interface.

MANFUL HALITOSIS - MANFUL HALITOSIS was an open-source monitoring tool. By default, it was accessible without authentication, and had an OS command injection vuln that could be used to get a shell.

FLANKING YAK ATTACK - FLANKING YAK ATTACK was another open-source monitoring tool. I found two authenticated OS command injection vulns which I used to get a shell, and then an LPE vuln which could be used to gain access to an account with superuser permissions.

Undisclosed Vulnerabilities - 2018


I had some good fortune right at the beginning of 2018 and found six distinct vulnerabilities in a single product that - in combination with each other - got me RCE from the internet as a superuser. I'm really proud of the six CVEs that were assigned, and I'm looking forward to their eventual disclosure.

[ Page Icon ]