InfoSec Write-ups – Medium–
In this write up we’ll see how we were able to combine direct sqlmap connection to a database with BMC/IPMI exploitation to compromise a big cloud-hosted client.
Getting a foothold
A couple of years ago, our team was tasked with performing an infrastructure pentest in an Openstack network. It was formed by about 2000 physical servers, hosting over 25K virtual instances. We started the pentest located in a small subnet which didn’t have a lot of outbound traffic allowed. After a quick Nmap scan, we weren’t able to find any simple vulnerabilities to exploit, so we started looking into the services available to us. Amongst them, we found an exposed PostgreSQL server, hosted in a development server. After creating a custom wordlist with multiple derivations of the company’s name, we were able to login with relatively trivial credentials. The username was Postgres, and to protect this company’s anonymity, let's say that the password was “admin”.
We proceeded to use sqlmap (https://github.com/sqlmapproject/sqlmap). This tool was created to exploit SQL injections, but it can also give you several options when establishing a direct connection to the database (when you have the credentials). One of these options is starting a command shell on the exploited database.
After testing the shell, we decided to put together a custom payload in order to receive a reverse shell, toy work more comfortably.
To do this, we started assembling a payload with msfvenom. In this case, the payload was a reverse TCP shell, for an x64 Linux machine (you can see that we had to select the DB architecture on the previous image).
An advantage of using this payload is that you can receive the connect back with a simple Netcat. Most other payloads require something like Metasploit's exploit/multi/handler module to receive the reverse connection.
After running the payload with the sqlmap shell, we got our connection from the server.
Exploiting BMC devices
Whenever you’re doing an infrastructure pentest and you compromise a machine in a new segment of the network, you should re-do your scans to check if you have new visibility. This DB allowed us to reach the company’s cloud network, including most of the virtualized instances, as well as the hosts. We were really excited to get the results of the new scan and see amongst them multiple BMC devices.
A BMC (Baseboard Management Controller) is basically an embedded device, attached to the main server, that provides you with out-of-band monitor and control. All big hardware providers have custom BMC for their products, in which you can list
- Dell DRAC
- IBM IMM
- HP iLO
- Supermicro IPMI
Another term you need to be familiar with, IPMI (Intelligent Platform Management Interface), is basically the protocol that you use to communicate with these devices (https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface).
Let's just say that IPMI is by far one of the most insecure protocols you can find. To give you an idea, IPMI 2.0 is designed in such a way that you can directly request a user’s hash from the server during the authentication phase (really, look it up). Not only this, but there’s also an authentication flaw in which you request to log in with a “cipher 0” mode, which will let you log in using any password. You can find a lot of the flaws more deeply explained/exploited in this Rapid7 post: https://blog.rapid7.com/2013/07/02/a-penetration-testers-guide-to-ipmi/
BMC devises you might find aren’t usually properly secured, since they’re the kind of device you just set up once when you’re putting together a data center, and then use sporadically whenever a server is unaccessible through the usual means.
We were able to easily authenticate to some of the devices, which had cipher 0 enabled:
Dan Farmer is a pioneer in the research of BMC/IPMI associated vulnerabilities. You can read more about how to exploit cipher 0 with the native ipmitool utility on his site: http://fish2.com/ipmi/cipherzero.html. Right now it seems to be down, but you can always read google’s cached versions. Anyways, here you can see how we logged in with a random password. Pay attention to the “-C 0” part.
Even if some devices don’t have cipher 0 enabled, you still have other means to login. The two most frequent ones are either using default credentials (which sysadmins don’t usually bother to change), or exploiting the hash disclosure vulnerability (and cracking the hashes afterwards). We had to do the latter for most of the devices.
After enumerating all the hashes, we started cracking them
A couple of minutes later, we had access to about 600 BMC’s.
There were a couple of HP ILO devices which we were unable to crack. Lucky for us, there’s also an authentication bypass in HP iLO 4, from versions 1.00 to 2.50. This allows you to create an admin account through a buffer overflow in the Connection HTTP header, handled by the webserver (https://cvedetails.com/cve/CVE-2017-12542/). The exploit uses this BO to get privileged access to the rest API, which in turn gives you accounts creation permissions.
After these steps, we had full control of 90% of the BMC devices of the company. I’m going to wrap up part 1 here. In part 2 we’ll explain how we used this device to take control of the full infrastructure, as well as how this company ended up resolving most of these issues.
How a badly configured DB allowed us to own an entire cloud of over 25K hosts (part 1/2) was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.