Introduction

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.

Image for post

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

Image for post

Putting together the payload with msfvenom

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.

Image for post

#security #infosec #pentesting #red-team #devops #cloud

How a badly configured DB allowed us to own an entire cloud of over 25K hosts
1.35 GEEK