Thursday, April 6, 2017

SANS Netwars Experience & CyberCity

Last week I had the wonderful opportunity to partake in the SANS Netwars competition as well as the CyberCity challenge while taking Sec504 at Pentest Austin. Let me start by saying that if you are trying to figure out if you should do it, dive right in and have some fun!!

So what is Netwars? Netwars is a game that is played by utilizing hacking methodologies to score points. The players are ranked by their points score, and how many hints they have taken. There are 5 different levels each requiring a number of points to unlock. The first two levels are played on a VM that is given to you, while levels 3 and 4 are played off of a jump box that you are given access to once you unlock the third level. Level 5 is where you defend your "castle" while attacking others.

At Pentest Austin, Netwars is a three night event that runs on select nights throughout the week. It is also one of the few places for "Coin-A-Palooza" where you can earn challenge coins for completing levels at Netwars. Since Sec504 was the first SANS class that I had taken, it was the only coin I could win. But, I was able to earn my challenge coin on the first night of the competition by advancing to level 2. 

At the end of the third night I had managed to get half-way through the third level, an accomplishment that I did not think that I would be able to do. I managed to rank 78/168 which puts me in just under the half-way mark on the leader board. I was proud of my accomplishment and grateful that I had ventured out of my comfort zone and gave it a try. Oh, and then I won the raffle for a Netwars Continuous subscription that will allow me to tackle that challenge for 4 months. I might be a little excited about starting that.

The final night was devoted to CyberCity. While Netwars had been an individual challenge, CyberCity was groups of 5.  CyberCity is a scale model of a city running real industrial control systems that you are given the chance to hack into. A team of us from Sec504 banded together to try and hack into the lighting control systems for the street lights. The scoreboard for this event is similar to NetWars in that you answer questions to direct you on what you should be doing. As our time ran out my team had managed to venture far into the control systems but came up short of our overall goal. It was a fun experience to say the least. 

So why am I writing about it? Because it is that awesome!! Really though, it was a lot of fun and if you are already immersing yourself into one of the SANS courses do yourself the favor of checking these after-hours events out. 

hackfest2016: Quaoar

VMware Fusion
Attacker: Kali Linux
Network: Host-Only
Target IP:

This walk-through will be a little different from my previous posts, mainly the lack of images. I am transitioning to a new host computer and I went through this vm before setting up a good way to do screenshots. Oh well...

This VM is the first of a series of three that gets harder as you move on. The difficulty listed on vulnhub is very easy. When you start the VM it tells you that the VM is located at

To start I ran a basic port scan utilizing the command "nmap -sV -A".  This gave me quite a few results, but what I was most interested in was that port 80 was open and nmap told me that there were sites excluded in the robots.txt file. Time to head there and figure out whats going on.

Browsing to I am greeted with a basic landing page that has a link to an image. Not much to see here... lets look at robots.txt. In that file we can see that /wordpress/ is listed. Oh... and Hackers are disallowed... funny. Looks like we will be exploiting a wordpress site for shell access.

Browsing around /wordpress/ there isn't much here. I can see that Admin created the posts, so that is a login. I wonder how easy this really is...

Yep admin:admin let's you into the admin panel of the Wordpress site. My first thought was to upload a php reverse shell as media or as a new page, but I couldn't find a way to make that work. I thought about editing the plugins that were running php to run a reverse shell, but decided to Metasploit it for added practice of that tool.

Since I have the admin credentials, I can use the module exploit/unix/webapp/wp_admin_shell_upload. I set all my options and typed exploit. I now had meterpreter shell access into the system. This allowed me to start browsing around the directories. I quickly found the first flag in /home/wpadmin.

Flag1: 2bafe61f03117ac66a73c3c514de796e

Seeing that there was a wpadmin user I got curious and tried to ssh to the box using wpadmin:wpadmin to see if the admin had made the same mistake twice. Sure enough it let me in with a /bin/sh shell. I like to utilize /bin/bash so I ran the following python script to change my shell.

python -c 'import pty; pty.spawn("/bin/bash")'

I started browsing around the file system again looking for a way to become root. Knowing that in the past I've had luck with cron jobs being run as root I looked in the /etc/cron.d directory and found a file named php5. Inside of this file was not a way to root like I had hoped, but instead flag 3!!!

Flag 3: d46795f84148fd338603d0d6a9dbf8de

I continued looking and eventually found an upload directory in "/var/www". Inside of that directory there was a config.php file that had mysql credentials listed in it. root:rootpassword!

I ran "su root" and gave it the password I found and sure enough it worked!! I quickly navigated to /root/flag.txt to get the second flag.

Flag 2: 8e3f9ec016e3598c5eec11fd3d73f6fb

With all three flags found that closes out this challenge. Hopefully I'll find time to challenge myself with the others in this series.

Friday, January 20, 2017

Wallaby's: Nightmare (v1.0.2)

Wallaby's: Nightmare (v1.0.2) - vulnhub,176/


Virtualization Hardware: virtualbox
Host: Mac OSX
Attacker: Kali IP:
Victim: Wallaby IP:
Networking: Host-Only


This boot2root gave me some challenges along the way. I have been away from this for a bit and this was a big kick in the pants to try and get some of my knowledge back. As always I started out with a netdiscover to  determine what IP was given to the virtual box on my host-only network. Once I did that I was able to run nmap on it to determine open ports.

I was able to find the typical open ports (22 and 80) as well as 6667 listed as a filtered IRC port. I will start with the HTTP port, but I will be keeping that IRC port in the back of my mind. Browsing through the site gives little information. I play with the username function for a bit and get familiar with the structure of the site. (/?page=)
 I ran nikto on the site, and that's where things started to get interesting. I lost port 80. Running nmap again I see that 80 is no longer listed, but 60080 is now listed.

Browsing the new site the index pages have changed indicating that the vulnerable machine has detected that I was attempting to attack the machine. I guess that's what the description meant when it stated that the machine was a vector. Back to my nikto results, let's check out the /etc/passwd hint that it gave us.

It looks like we have stumbled across the /etc/passwd for the box. But, when looking at the page source I can see that this has been planted and is a fake.

Taking another approach I run dirb on the site in order to determine how many valid directories exist.

Taking a look at the list and trying them yields little success no success until i get to mailer. I finally get a good page, but there isn't much information here. Looking at the page source I get a hint. /?page=mailer&mailer=ls

Trying the above address it returns the contents of the html directory. Now we are getting somewhere.

After playing around with it for a bit I figure out I can use wget to upload a php reverse shell. I had originally tried to transfer the file with netcat but the response from the box was "How you gonna use nectar so obviously. Cmon man. This is all in the logs." The problem with wget is that it won't grab the file with the .php extension. That's okay, I drop the extension on my kali box where I have the file hosted (I had to install apache2 on my kali box and chmod 777 the file so that it could be grabbed by the victim box) and try again. Success! Now to cp the file to change the filename and I'm all set.

I setup my netcat listener on my kali box and navigate to to gain a limited shell on the box.

I first navigate to /etc/passwd to see the real list. I find that there are three users on the box, waldo, wallaby and ircd. The IRC username has me thinking that the IRC port that I had found earlier might play a role in gaining an elevated shell. First let me check what sudo privileges these users have on this box. Using sudo -l I find that all users have no password sudo access to iptables and that waldo has no password sudo access to another directory.

 Taking a look at iptables -l I can see that the IRC port is set to Deny for external. Let's change that and see if we can get connected.

After changing the iptables I run nmap against the box again and I am able to get more information about the IRC port.

I am now able join the IRC using Hexchat and using /list I am able to find a channel called #walabyschat. I am able to join the channel, and see that there are users already on it. Waldo and wallabysbot. Wallaby must have type of bot running on the IRC channel. Since no other information is available here, let me step back into the box and see what I can find.

Looking back at the directories on the box with my limited shell I am able to find that the home directories for the users are available for me to look at. It takes a while, but I finally find some useful information in wallaby's home folder. Apparently walabysbot is running a service called Sopel. A quick Google search later and I have found that if I type in .help I can interact with the bot and it will give me information about the commands that I can send the bot.

The bot returns a list of commands and one of them is .run. Trying .run ls gives me the response "Hold on, you aren't Waldo?" I guess I am going to have to become Waldo for the command to work. I try to use the command "/nick Waldo",  but I get the error that Waldo is already in use.

Looking back on my notes, I remember the other no password sudo command that I found. Let me take a closer look at that.

The command that waldo can sudo without password is "/usr/bin/vim /etc/apache2/sites-available/000-default.conf." This will allow vim to open 000-default.conf and I can use that to manipulate the apache server. Next I run the command who in my limited shell and find the process id of our logged in user waldo.

sudo -u waldo /usr/bin/vim /etc/apache2/sites-available/000-default.conf

Now that I know the id (666), I just need to kill the process. Using sudo and the command from earlier I open the 000-default.conf file and run !kill 666. This kill Waldo's current session. A quick check of who confirms this.

I am now able to go back to my Hexchat session and use the command /nick waldo to change my name to waldo. Once done, I can now use the .run command with the bot to issue commands on the box.

Using the commadn whoami, I find that the commands are being run as Waldo. This would be helpful if the .run command would allow for multiple words or arguments, ut it doesn't. From my research earlier looking at the home folders, I know that Sopel runs off of Python. I can create a script to run a Python reverse shell, and Waldo will be the user that runs it. This should give me a shell as Waldo.

After playing around with several options, it looks like I will have to import the script using wget into the /tmp directory. From there I need to chmod +x to allow the file to be executed.

Now all I need to do is setup a listener on my Kali box and have the IRC bot run my script.

Now that I have a Waldo shell, let me try and access the /root directory. Denied.

Checking the sudo properties for Waldo using sudo -l I can see that Waldo should have ALL access to sudo with no password. That makes things simple. I now run "sudo ls /root" and see that the flag is sitting there. A simple "sudo cat /root/flag.txt" later and I have my flag.


Friday, September 2, 2016

RootMe - ELF32 - Stack buffer overflow basic 2

 RootMe - ELF32 - Stack buffer overflow basic 2 ~ RootMe

Attacker: Putty on Windows OS
Vulnerable Machine:
Target: .passwd


1) This this buffer overflow example we are using SSH to gain access to a machine and practice a buffer overflow. In this example we need the .passwd file for credit and we need elevated permissions in order to do so. In my case I am using Putty to SSH from a Windows box, on a Linux box like Kali i could just use the ssh command.

The challenge gives you the connection information:

Input into Putty:

After login:

2) Once I look at the file system I can see that all of our files are located in this directory. The source code for the C program is located in the directory ans I have the ability to view it (It is also located on the challenge webpage). I do not have the ability to view the .passwd file however. Let's see what ch15 does.

3)  Looking at the code tells me everything that I need to know.

The  program starts by creating two function one called shell() and one called sup(). Then we get into main where an integer called var is created with no initial value. Then we get to a void statement. This statement takes func and points it to sup. This means that unless we are able to overflow the buffer created on the next line the function that is run at the end will be sup. We can see that the buffer is created as 128 characters but once again we can use fget to write 133 characters.

4) Looks like I am going to use python again to feed ch15 a buffer overflow. Remembering the trick that I had to use before with cat in basic 1 to get my shell to not immediately time out I set out trying to get it to work. This one took me some time before I finally realized what I needed to feed the program in order to get the shell.

I knew that I needed to overflow in order to call the shell() function. I now needed to figure out how to call that function with the overflow. I used objdump to get more information.

I was able to see that <shell> is stored here:

Using that info I was able to overflow the buffer and grab the escalated privilege shell.