Hack the Planet
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.
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.
This pair of OS command injection vulnerabilities were discovered during a live pen test in 2015. I can't provide additional details publicly at this time.
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|
Screenshots of web content that may no longer be publicly available.
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 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. When I have more time, I'll provide some high-level statistics.