Tag Archives: VirtualBox

My first CTF: ruCTFe 2015 w/ #Misec

I know there is a lot of different people reading this post; mentors, coworkers, students, friends and family. So I’ll be as thorough as possible to cover all the bases. Mainly because I’m very excited about all of this and I want to write down all of the details before it gets too late. (Feel free to skip a paragraph if it gets too boring)

what’s ruCTFe?

First off, it is capture the flag! Why am I so pumped about a game of capture the flag? It’s the international hacker version of capture the flag!! Imagine this, Russia (the ru part) is the host. They give every team a virtual machine (vm) with a number of applications “ready” to be deployed. Each team is responsible for keeping their apps online as well trying to bring down other teams apps. Our Russian hosts have access to everyone’s apps and are able to “drop” flags throughout them.  Flags are strings like “A23HFK36JG732IE436GHD8OVH1297QUF=” and you know it’s a flag because it’s 32 capital letters and numbers followed by a “=”. Each app has a unique twist that makes the game more interesting. For example, one app was written in Python, another was in C and used .cgi files (WHAT?). Some apps stored data in mysqli and sqllite databases, others used files with JSON. The variety added  complexity that made the game more fun. #Misec (a local hacker group and our team) arranged people into four groups. Red team focused on attacking other apps and searching for flags. Blue team was responsible for defending our apps and hardening the server. Green team was ops, they built and maintained the network. Fuchsia team was our developers  and became jack of all traits because they worked along side red team on code dives while implementing blue team’s defenses.

I was a part of the red team. I really enjoy penetration testing and I knew this would be great experience. Our team lead was Austen. He walked me through a lot of what it means to be on the red team. I’m very thankful for his help. This was my first time implementing a lot of tools on the Kali OS and  I had no idea what I was doing. Last weekend was a prep meeting and I found out that my old Kali box wouldn’t update, so I had to prepare a new one during the week. #Misec was really helpful every time that I got stuck or hard a question during setup.

Walk Through

My day started at 3:30am with a blaring alarm clock. That was probably the worst part of the day, which also means the day would only get better right? I arrived on site around 4:20, just in time to help hang wires and bring in equipment.  As everyone showed up, we brought out our machines, connected everything and got the VMs ready. I worked with Brad (Fuchsia lead) and Austen to reset the root password and config SSH so that I could log in from Kali. Once our environments were set up, the red team started looking for what ports were open and what  services were listening. This was the first time we found what the apps were using. Like I said earlier in the explanation, there was a wide range of databases and languages at our disposal. Brad dumped the databases and passed it around for others to try and understand while Amanda (El Conquistador and Blue team leader) searched for passwords and configurations that needed to be updated. Otherwise other teams could use the default accounts to own us.

Throughout the morning, the green team worked to get the apps online. As they did that, the red & fuchsia  teams searched high and low for vulnerabilities in our VMs that would get us an advantage against other teams. The blue team continued to check our apps and secure them as needed. I spent this time running my VM through Armitage. I wasn’t able to find any exploits right away that the apps were vulnerable to, but that was to be expected. Armitage is very automated and it’s hard to customize exploits to work with specific apps. After that turned out to be unsuccessful I turned my attention towards Burp Suite. However, I wasn’t able to configure it correctly so I turned my attention towards code dives hoping to find something obvious like SQL injection or worse. The apps were all in their own directories under home/ and it was very interesting to look through how our hosts had made the VM. As I was looking around, Austen found one of the apps used the same auth token in a cookie for every user in the app. I helped him confirm that by recreating what he did on my VM. The idea for a exploit was that if we could pick up  a player’s cookies when they dropped flags off to the host, we could get into the apps they were just at.  Austen also found a second vulnerability where for the Python app, the password was “hashed” by turning numbers into their ascii hex equivalent. I wrote a small python script to decode the hashes incase we ever got a hold of another teams JSON files. Just a quick note, this is the first script I’ve written to help break a web app and I was really excited to see how easy it seemed; the development background (and wide range of python libraries) really helped.

The apps go live

Between 11 and noon, the green team was able to bring our app online at full capacity. This was our first time being able to score points and everyone was really excited. However this also brought a new issue, where other teams could now attack us. The plan seems to be working pretty well though, we were earning points for keeping the app alive and no one seemed to be trying to attack the server too badly from the outside. As soon as the red team had access to other teams, we started to poke other teams servers to see what was possible. I tried to find a way to get my python script to work, but first I needed a way to find the json file. I tried calling it directly from the URL, SSH-ing into their application server, and just crawling through the app. This didn’t turn out very well so I tried another tactic. Now that we had real targets, maybe it’d be worth trying Armitage again, other applications might not be as hardened as ours, right? Well, like my VM, it didn’t return any easy results, so I abandoned the idea to return to poking at random teams’ apps, hoping to find a XSS or SQL injection bug somewhere. While I was digging around, my box froze. I have no idea why, but it used to happen all the time when I was running windows7 (I assume it was related to the hardware). I just rebooted Kali and continued my barrage of random attempts to attack other teams.

During my assault, Amanda came over to ask if we had done a game-wide nmap scan to list all of the active teams. The game was a almost 3/4 of the way done and no one on the red team had thought to scan everyone after we had gotten our apps up on the game network. Amanda showed me how to use RAWR, a python wrapper of nmap that allowed us to scan and log more cleanly then just saving nmap output straight to a text file. While Amanda filled me in, she was scanning some of the other teams’ servers. I used Python to create a input file for RAWR that would hit the production box for 254 ip addresses. As I started to run the scanner, Austen found another way to grab flags by recreating auth tokens for users of a Ruby app. He quickly wrote up a Ruby script to loop through different teams and a range of IDs (both were used to create the auth tokens) and distributed the code amongst the red team to try and crack as many teams as possible. He ran the code first and started to find flags on the other teams servers, however when he went to turn them in, the host’s scoreboard server was having connection issues.

Down to the wire

Since there were issues from the host, we tried to hold onto flags until we were able to reconnect to the scoreboard and turn them in.  This was risky because it was going on 2pm and the game was only live for another hour. As soon as Austen found a valid flag, the red team started running his script over different teams trying to get their apps to give up more flags. I made a couple modifications to his script on my box so that instead of going through 100 IDs on a team, then going to another team (and so on), the script would ask me for what team to scan and wouldn’t iterate to a second team. I was able to use this modification to run a few scripts at once and try to grab as many flags as possible. As we were searching, we were able to find a good amount of flags. The second modification I was trying was to add inputs for the starting and ending IDs for the script. I couldn’t get it to work and didn’t know why until after the game ended when I asked Austen to look it over. I was still able to get 6 flags in the last ten minutes of the game and I was very excited to have contributed to increasing the team’s score. It felt amazing. At the end of the game, we were ranked 118th out of over 300 teams and I was proud to have helped and learned so much, especially since we climbed 3 ranks within the last few minutes!

ruCTFe partial scoreboard
Misec beat Batman

Conclusion

I want to give a huge shout out to Misec for pooling some great local talent into an awesome team. Thanks to Steven for organizing this year’s event and to Jason for building our infrastructure/network. Also, if it wasn’t for Austen, Brad, Amanda, Wolf, Ben and everyone else who helped me and made me feel like a member of the team. I wouldn’t have been able to learn as much as I did or have as much fun without you. I can’t wait to see what will happen at ruCTFe 2016!

Step 3: Set Up Your Hacking Environment

Everyone wants to break into their neighbors wifi or steal someones password at Starbucks, but depending on National, State, and local law, even packet sniffing could be illegal. So how do we safely practice how to hack before we are ready to find Sony’s back door? We set up a environment for virtual machines on our local computer or server!

For those of you who don’t know what a Virtual Machine is, it’s a “computer” inside your computer. Using programs like VMware or Oracle’s VM VirtualBox (which is free) you can have multiple systems running on your computer depending on your computer’s RAM and processing power. I suggest you download VirtualBox to get started: https://www.virtualbox.org/wiki/Downloads

VirtualBox view of environments

After you have that installed, you need to get the operating systems that’ll make up your VMs. I suggest using Kali for your “hacker” machine and OWASP’s BWA for your “victim” machine. OWASP is a open source community for watching web application security. You should check outhttp://www.owasp.org to learn more about them. Be sure to check out their top 10 vulnerabilities for websites. You can download the files for both VMs at the links below. Special note about the BWA VM: It’s made of VMware files, there’s no installing like you would with Kali. Be sure to use an existing harddrive and select one of the files from the .zip folder you downloaded.
https://www.kali.org/downloads/
http://www.slideshare.net/michael_coates/lab-setup-28126110

Follow these tutorials to get your systems online!
Installing Kali as a Virtual Macine

Installing OWASPs BWA as a Virtual Machine

If you’ve never used a linux operating system before, I suggest you learn fast! Check out how to use the bash commands (terminal) and learn some of the tools that Kali has to offer.

Kali environment

Now, your “victim” is specifically made to have vulnerabilities! Its up to you to find them, or if you want more of a step by step then I suggest you google how to get in or check out the BWA project files

 

OWASP BWA environment

 

Confession: While writing this blog I got OWASP BWA working on my Windows machine for the first time. I’m very excited to try it out!