Pages

Monday, December 28, 2015

RUCTFE and why a CTF can benefit your organizational security.

I had the great honor of being the defensive (blue) team captain for the RUCTF, a technical capture the flag event organized by a group of security professionals located in Russia. I enjoy being able to lead and teach others, learn new tactics, and be a part of a competitive team. Misec (www.michsec.org) is a collection of Michigan (and in my case, Northern Ohio) based security professionals that meet regularly to learn, compete, and socialize in different ways. In this article I have a co-author that has written about his first CTF experience. James Green is a senior at Michigan State University in East Lansing, Michigan. After you read about his experience I’ll go over why challenges of this nature can benefit your organization.


My First CTF: RUCTFE 2015 with #MISEC


What is ruCTFe?

First off, it is a capture the flag! Why am I so pumped about a game of capture the flag? It is the international hacker version of capture the flag!! Imagine this, Russia is the host and they give every team a virtual machine (vm) with a number of applications “ready” to be deployed. Each team is responsible for keeping their applications online as well trying to bring down other teams. Our Russian hosts have access to everyone’s vm 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 was written in Python, another was in C and used .cgi files. Some stored data in mysql and sqllite databases, others used files with JSON. The variety added complexity that made the game more fun. Misec arranged people into four groups. Red team focused on attacking other teams and searching for flags. Blue team was responsible for defending our applications and hardening the security of the server. Green team was operations, they built and maintained the network. Fuchsia team were our developers  and became jack of all trades because they worked alongside 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, and he walked me through a lot of what it means to be on the read team. I’m very thankful for his help. 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 (Blue lead) searched for passwords and configurations that needed to be updated. Otherwise other teams could use the default accounts to hack into our VM.

Throughout the morning, the green team worked to get the network online. As they did that, the red and 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 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 team’s 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 network 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 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 than 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 of which 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!

- James Green


As you can see, for the junior members of your organization or team members that want to learn new or improve upon existing skills, participating in CTF type challenges is invaluable experience. They are well crafted scenarios that can put you and your team in real life situations. Somewhere that you are able to practice both defensive and offensive skills and learn from a variety of people in different information security roles. Many companies don’t have the time or resources to create such elaborate scenarios for the practice that is needed for responding and handling real threats. The communication and technical skills gained from this practice will give you the upper hand no matter what role you play.

There are a variety of types of CTFs from jeopardy style where you submit certain answers (flags) for points, or in the case of RUCTFE it was an attack/defense design. If you are interested in participating you can contact a local security group or visit https://ctftime.org/ for a listing of some of the current ones that are out there. Whether you show up to organize, teach, learn, or spectate I can guarantee that you’ll leave having learned something new.