Wednesday, August 23, 2017

The top post on reddit.com/r/netsec this week is a pretty nifty idea: a Vulnerable VM generator. Since vulnerable VMs are my thing, I decided to check it out. Installation is pretty straightforward on Ubuntu, and generating a VM is as simple as "ruby secgen.rb run".

After everything is up and running, an nmap script scan shows a vulnerable IRC server in which a metasploit module exists to exploit.

I go to msfconsole and set everything apropriately and, quickly, I have a low privilege shell (I later upgraded to a full meterpreter shell).

After running "find / -perm -2000 -o -perm -4000" I see nmap is setuid (took me longer than I'd like to admit to find this).

A metasploit module exists to exploit this as well, so root is easy pickings.

So cool that a unique vulnerable VM was conjured in front of me from some Ruby code. Big thanks to Cliffe from GitHub for providing the community with a great resource for learning!

Thursday, March 16, 2017

An nmap scan shows a very similar port list as the first hackfest VM I did. However, this time port 8080 is open.

I find a Tomcat 7 installation...

...however I couldn't login as the manager, so I gave up on this and moved on to enumerating port 80. Uniscan found a few interesting directories.

I couldn't do much with these on their own however. That is until nikto brought up a great point.

I checked license.txt and found a useful piece of information.

I see a "BuilderEngine" installation. I went to the /builderengine/ directory and confirmed it was present. There is an exploit that exists that allowed me to upload an arbitrary file and place it in the /files/ directory on the web server. First I went to the directory used in the exploit to confirm it exists.

Then I copied the exploit code, pasted it in a file called "uploader.html" on my attacking machine and swapped out the link to match the one above.

Then I opened the file in Firefox and uploaded a php reverse shell.

Then I navigated to the /files/ directory on the server and clicked on my shell.php file and get a beautiful reverse shell.

Then I dirty COW my way to root. The exploit kills my shell, however I can just ssh to the "firefart" user it created.

According to the VM details on VulnHub there are two post exploitation flags. I'm fairly certain one of them is the Tomcat7 password found at /etc/tomcat7/tomcat-users.xml.

These credentials allowed me to login to the tomcat manager interface.

The other flag I'm pretty sure is the password for the "crackmeforpoints" user...

...but I'm going to go ahead and let someone else crack that due to my hardware limitations. Overall I really enjoyed this VM; I don't get to use exploit-db enough for web apps in VulnHub VMs so this was a pleasant surprise!

An nmap script scan of port 80 shows robots.txt is present. While there were other ports open, the details of the VM strongly suggested a web application is the correct rabbit hole so I decided to investigate that first.

I navigate to it in my browser and find a wordpress installation present.

I immediately go to the admin login and get through with "admin/admin" credentials. The description did say this was a very easy VM after all.

After logging in I navigated to "plugins > editor" and selected the "Mail Masta" plugin (since it was already active) and added a php reverse shell to one of the files. Simply clicking "update" gave me a shell.

I immediately noticed a "wpadmin" user in the /etc/passwd/ file and found the password to be "wpadmin" so I decided to ssh to that user for a more stable shell and I found the first flag.

Going through a file in the "/upload/" directory of the web root, I found a "config.php" file containing root credentials for the MySQL server.

Going along with the "very easy" theme, I tried logging into root with these credentials and was successful!

According to the VM description on VulnHub there is a post exploitation flag on the VM, however I have not been able to find it. I went through the MySQL database and searched through the file system for anything resembling a flag and had no luck. Other than that, this was a very easy VM that was still somewhat satisfying in a weird way. I will be sure to make time for the other two, more difficult hackfest VMs.

Tuesday, February 7, 2017

I completed the "Lord Of The Root VM" awhile ago (though I never posted it here), however I Dirty Cow'd my way to root after losing my patience with the buffer overflow path due to ASLR being enabled. A few days ago, a user on Twitch livestreamed his solution through the VM (short of the buffer overflow) which inspired me to take another crack at it.

The file in question is tucked away in the "/SECRET" directory in the root directory. This time, I decided it might be easier if I place the file on my Kali VM so I could diagnose the problem easier. I loaded the file in gdb and quickly found the spot EIP was overwritten using "pattern arg 300" and "pattern search" respectively.

I see EIP is overwritten 171 bytes in, so I send a new string to confirm my control over EIP.

So far so good. However, here it's important to note ASLR is turned off within gdb, though once I load up the final exploit outside of the debugger, it will be enabled. I also see ESP contains the NOPs I sent in my python script. Now I'm ready to create a python script that will brute force the program aiming for the correct address with my "/bin/sh" shellcode. I chose "0xbffff2ea" just to be "safe." Also, while reading up on ASLR exploitation, I learned a larger NOP sled is ideal in this case. Basically, by creating a large NOP sled, you increase your chances of hitting your shellcode. Since ESP allows me to create a large NOP sled, I'm going to take advantage of it to make a more reliable exploit. I chose 32,000 NOPs which produced fairly consistent results.

So after running 1258 times, the exploit worked and I get a shell. With my PoC, I decide to switch to the "Lord Of The Root" VM and continue my work there. I send the same python script through gdb and take note of the ESP address.

Now that I have a sample ESP address, I create a quick python script to automate the exploitation process. It should be noted that I chose an address slightly after ESP once again to be safe (0xbffff640 instead of 0xbffff620). It automatically finds the correct door since there is a script that runs every few minutes that changes the correct file location.