Thursday, March 16, 2017

[VulnHub] hackfest2016: Sedna

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!

[VulnHub] hackfest2016: Quaoar

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.

Sunday, March 12, 2017

[VulnHub] pluck: 1

An nmap scan shows SSH, HTTP, and MySQL open.


Using uniscan, I find a promising LFI link.


Visiting the link I see some juicy information.


Obviously this is a great start, however, I navigated to "/admin.php" and found a very promising SQL error after trying basic injection techniques.


I wasted more time than I'd like to admit trying to leverage this. Trying everything I can think of in sqlmap, I couldn't seem to find any way to exploit this (the reason becomes clear later on).

Moving on with the /etc/passwd file, I see an interesting script associated with the "backup-user" account that might lead to something.


I view the script using the same link I used for /etc/passwd. 


It looks like this script creates a tar backup of the /home and web root directories and puts it in reach of a tftp server. I connect to the tftp server and download the tar file and extract it. 


Looking in paul's directory, I see SSH public key files. 


Logging in with id_key4 I get a "pdmenu" shell.


From here, I select "Edit file" and create a php reverse shell file and place it in paul's home directory.


Then I once again use the LFI and execute the new php file and get a reverse shell.


At this point, my number one concern was figuring out why my SQL injection efforts were futile. Viewing the "admin.php" source code, I can see I was duped. 


Moving on, I dirty COW my way to root and find the flag.


This was an enjoyable VM that gave me flashbacks to working in the OSCP labs which is always something I'm looking for!

Tuesday, February 7, 2017

[VulnHub] Lord Of The Root Privilege Escalation Walkthrough

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.


After running nearly 3000 times, a shell finally drops with root privileges.


This was a tough challenge for me as I've never attempted to bypass ASLR before, so I learned some new concepts that should aid in my future exploitation of buffer overflows.