[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!

[VulnHub] Tr0ll: 2 Privilege Escalation Walkthrough

If you've made it to the low privilege shell in Tr0ll: 2 by exploiting the Bash Shellshock vulnerability, you've probably quickly found the "nothing_to_see_here" directory and the three doors that go along with it.

Each "door" contains a binary owned by root with the SUID bit set. These files will randomly switch directories every few minutes. The one that should be exploited is the largest sized binary (8401). When executed it asks for a user input, which strongly suggests I will be buffer overflowing my way to root. I first open gdb and send a string of 1000 "A's" through the debugger to see if the program crashes. Simply entering 'r "AAAA..."' into the gdb console will do this.

So after entering in the A's you'll see the program did indeed crash. Typing in "i r" (short for "info registers"), the registers and their contents will be displayed. The main register we're looking at here is the EIP register which contains the value "0x41414141" (41414141 is "AAAA" converted from ASCII to hex). EIP is code for "instruction pointer". This register controls the execution flow of a program. By modifying EIP, you can essentially redirect execution flow to an address of your choosing.

Also, after examining the ESP register located at address 0xbffff8c0 (this may be different in your environment) by typing "x 0xbffff8c0" (short for "examine 0xbffff8c0") into the gdb console, I see the string overwrote ESP as well. This is the ideal spot to send EIP.

However, first I'll need to find the exact point in which the string overwrites EIP. To do this, I use a program built in to Kali Linux (pattern_create.rb). This program basically creates a predictable string so we can see exactly where EIP is overwritten. I ask for a string length of 1000 characters once again.

Now that I have the string, I send it through the program which once again crashes.

Now I can copy the contents of EIP and plop it in another program (pattern_offset.rb) and find the exact spot in which EIP is overwritten.

Now that I know EIP is 268 bytes in, I modify my input a little. I use python to print 268 "A's" followed by 4 "B's" which should overwrite EIP.

Perfect! I see EBP still contains the "A's" and EIP now contains the "B's" (42 in hex) like I'd planned. I check to see if ASLR is enabled. I do this by checking the "/proc/sys/kernel/randomize_va_space" file. If the value within the file is 2, it means ASLR is enabled, if it's 0 then it's been disabled. I find out it is disabled, which means ESP should contain a predictable address once our buffer length is set.

Before I check the address at ESP, I add 16 no operation or "NOP" ("\x90") instructions to the buffer. The NOPs will make sure the shellcode will smoothly make it to ESP. After I add the 16 NOPs, my pre-shellcode buffer length is set, so I can take note of the ESP register and I can overwrite EIP.

So from there, I see ESP is at the address 0xbffffb80 (again, note this may be different for you). I replace the "B's" in my buffer with the address in little endian format. My buffer now has 268 "A's" followed by the address of ESP in little endian format ("\x80\xfb\xff\xbf") followed by 16 NOP instructions ("\x90"). Now a shellcode of my choosing can be added to the buffer and will be executed within the SUID binary as the root user. I choose a simple 23 byte "/bin/sh" shellcode.

Now that my final buffer is set, I run the program with my small python script appended and I get a beautiful root shell.

Boom. It's that easy. Of course, if you ignore everything you just read, you could just use Dirty COW and pop a root shell that way.

[VulnHub] Tr0ll: 1

Starting off, an nmap script scan displays a few things of note. The FTP server allows anonymous access and shows an interesting packet capture file. Also, a "secret/" directory was found in robots.txt which, judging by the name of the VM, is surely not the right rabbit hole.

Sure enough, visiting the directory...

Gr8 b8 m8. After logging in to the FTP server and downloading the "lol.pcap" file, I take a closer look in Wireshark. It looks like a capture of a useless FTP session. However, halfway down I found something of interest.

Visiting the newly found "sup3rs3cr3tdirlol/" in the webserver, I found a file called "roflmao."

Upon further inspection, it appears to be a binary, and after executing it, I see what appears to be a memory address of some sort.

My first instinct was to use edb-debugger to perhaps find something to do with the address mentioned in the executable. Fortunately, I didn't waste much time (20 minutes lol) because after pasting the address in to the web browser...

Yeah... Anyway, I find what looks like a username list and a password list (Pass.txt) in the respective directories so I decide to go ahead and start brute forcing SSH. It took me awhile, but "Pass.txt" is literally the password for the "overflow" user.

Within minutes, I can tell escalation is going to be annoying because I'm getting kicked off seemingly randomly and my "/tmp/" files keep getting deleted. I figure this is the work of a cron job, so I take a look at "cron.log."

Taking a look at the file, I see this is indeed what is removing my tmp files.

I also see this file is writable, meaning I can simply create a setuid binary and give it root permissions and I should be good. I create a simple setuid C program and compile it in the tmp directory.

Then I modify the cleaner.py script to give the file root permissions and set the setuid bit.

After "ls -al"-ing a few times, I see the file permissions change and I'm able to execute the program and become root!

This was a very fun VM and it did actually remind me of working in the OSCP labs. I look forward to making time for Tr0ll 2.

[VulnHub] HackDay: Albania

A good old nmap script scan grabs robots.txt from the HTTP server and displays its contents for us.

The first few directories I visited gave me an interesting little philosoraptor meme in Albanian. Google Translate tells me this says "Is this a proper directory, or are jerk." Interesting.

Looking at the directories in list form, two things become clear:

1. The creator of the VM is a fan of the Billy Madison VM (/exschmenuating/).

2. All the directories are in alphabetical order with the exception of /unisxcudkqjydw/.

Going to the directory in Firefox...

Yep. I eventually ended up at "/unisxcudkqjydw/vulnbank/client/login.php" and was greeted with a login page.

Trying some basic SQL injection techniques, I got a promising error message.

I decided to play around with some basic payloads and quickly had success using a username of "test' || 1=1;#". Not only did I get in, but I also became €25,000 richer! Somewhere, a Nigerian prince is proud!

Uploading the plain old "php-reverse-shell.php" file didn't work. However simply adding the extension ".jpg" allowed me to upload the file. Once uploaded, I simply clicked "View Ticket" and I get a beautiful reverse shell.

I immediately notice a user "taviso" in the home directory, but I couldn't find an easy password. It also soon became clear there weren't going to be any kernel exploits either. After an hour or two of searching, I eventually go ahead and reference g0tm1lk's privilege escalation guide which lead to me checking file permissions in the /etc/ directory. I found /etc/passwd to be writable.

Now that I knew I could edit /etc/passwd, I decided to simply edit the password of the "taviso" user, since this user was in the sudo group. First, I copied and pasted the contents of the /etc/passwd file into a file onto my attacking machine's web server root. I then created a password hash using openssl.

Then I simply placed the new password hash where the "x" is located in the /etc/password file next to the user "taviso."

I then used wget to download the newly created passwd file onto the target machine and replaced the old passwd file. Logging in to taviso had worked and I was able to become root!

Overall, I quite enjoyed the VM, specifically the privilege escalation part, and I definitely enjoyed the humor sprinkled throughout. I would definitely recommend this VM to you if you hadn't just read the spoilers.