Trying Out Security Scenario Generator (SecGen)

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

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

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