Want to get hacked? Just leave debuggers enabled

You’ve probably read that it’s wise to harden your systems. You want to reduce your footprint so that you aren’t wasting resources or leaving yourself vulnerable unnecessarily. The theory sounds great but the practical implementation is a bit abstract. What could really happen if you left that service running when it’s not necessary? Let’s find out using debuggers as an example.

I have find a target webserver with the following open ports:

22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4 (Ubuntu Linux; protocol 2.0)

80/tcp open http nginx 1.14.0 (Ubuntu)

|_http-server-header: nginx/1.14.0 (Ubuntu)

Seems like a worthy example so I obtain permission and get to it.

SSH is generally not vulnerable unless it’s really old. That’s not the case here so I spidered the website using Burp Suite to capture all its links and. One of the results was the error output on http://172.16.1.139/articles/elements.html?pin=555-555-0199@example.com&btn=Confirm%2bPin

This is Python Flask website if you don’t recognize it. I haven’t worked with Flask before so I check out the documentation to learn about it. Penetration testing often requires reading the available documentation.

Did you notice the bold text? “This makes it a major security risk and therefore it must never be used on production machines.”

That’s right, I can already run remote code because the debugger is enabled.

From here I spent some time trying to get a reverse shell running but with no success. I change my tactics and check the system for backups, hoping for an old shadow file:

theplague:$6$.5ef7Dajxto8Lz3u$Si5BDZZ81UxrCWEJbbQH9mBCdnuptj/aG6mqeu9UfeeSY7Ot9gp2wbQLTAJaahnlTrxN613L6Vner4tO1W.ot/:17964:0:99999:7::: hal:$6$UYTy.cHj$qGyl.fQ1PlXPllI4rbx6KM.lW6beCJ.k32JxviVqCC2AJPpmybhsA8zPRf0/i92BTpOKtrWcqsFAcdSxEkee30:17964:0:99999:7::: margo:$6$Lv8rcvK8$la/ms1mYal7QDxbXUYiDtLAADl.yE4H7mUGF6eTlYaZ2DVPi9z1bDIzqGZFwWrPkRrB9G/kbd72poeAnyJL4c1:17964:0:99999:7::: duke:$6$bFjry0BT$OtPFpMfL/KuUZOafZalqHiNNX/acVeIDiXXCPo9dPi1YHOp9AAAAnFTfEh.2AheGIvXMGMnEFl5DlTAbIzwYc/:17964:0:99999:7:::

I run these hashes through HashCat (Wondering what that’s all about it? Check out last month’s blog on Plaintext Passwords for details) and figure out they’re using sha512 with this handy website: https://hashcat.net/wiki/doku.php?id=example_hashes

hashcat -O -m1800 hashes /usr/share/wordlists/rockyou.txt

I start cracking using a graphics card and a couple of hours later I break some passwords. So I try out SSH and just like that I am margo:

margo@thebox:~$

The next step is to download and run Linenum to help enumerate the system and check for privilege escalation paths.

There’s not much besides the default Ubuntu configuration except 1 SUID file.

Running GDB (GNU Project Debugger) against it reveals it’s vulnerable to a very basic buffer overflow using many “A”s. Note the assembly code registers for 64 bit applications shown below contain lots of “A”s on the RBP and RSP lines. If I exploit this vulnerability, I gain root access on this server.

There are a few problems, mainly ASLR, DEP, and various other protections are enabled and 64 bit applications are more complex that 32 bit applications. My previous history of writing zero day exploits is without these protections but I am determined. I fill the exploit with \x90 to nopsled into shell code - it’s very simple but effective.

I need to learn more to have a possibility of getting full control of the system so my next blog will cover the basics of return-oriented programming (ROP) chaining.

We started by discovering and exploiting a Python Flask debugger that should not have been left enabled. We finished by using GDB to do some assembly code debugging to discover the buffer overflow vulnerability. Next week we’ll cover ROP chaining and be one step closer to taking control of this server.