Blue Team Player's Guide for Pros vs Joes CTF

15 Aug 2015 in Security (Reading time: 11 minutes)

I’ve played in Dichotomy’s Pros v Joes CTF for the past 3 years – which, I’m told, makes me the only player to have done so. It’s an incredible CTF and dramatically different from any other that I’ve ever played. Dichotomy and I were having lunch at DEF CON when he said “You know what would be cool? A blue team player’s guide.” So, I give to you, the blue team player’s guide to the Pros v Joes CTF.

Basics

First, a quick review of the basics: PvJ is a 2-day long CTF. On day one, blue teams operate in a strictly defensive role. Red cell will be coming after you relentlessly, and it’s your job to keep them out. On day two, things take a turn for the red, with blue teams both responsible for defending their network, but also given the opportunity to attack the networks of the other blue teams. Offense is fun, but do keep in mind that you need some defense on day two. Your network will have been reset, so you’ll need to re-harden all your systems!

Scoring is based on several factors. As of 2015, the first day score was based on flags (gain points for finding your own “integrity” flags, lose points for having flags stolen), service uptime (lose points for downtime), tickets (lose points for failing to complete required tasks in the environment), and beacons (lose points for red cell leaving “beacons” that phone home on your system, indicating ongoing compromise). Day two scoring is similar, but now you can earn points by stealing flags from other teams and placing your own beacons on their systems to phone home.

Make sure you read the rules when you play – each year they’re a little different, and things that have been done before may not fit within the rules – or may not be to your advantage anymore!

The Environment

Before I start talking strategy, let’s talk a little bit about the environment and what to expect. Of course, Dichotomy may have new tricks up his sleeve at any time, so you have to assume almost everything below will change.

Connecting to the environment requires connecting to an OpenVPN network that provides a route to your environment as well as all of the other teams – think of it as a self-contained mini-internet. Within this environment is a large vCenter deployment, containing all of the blue team environments. You’ll get access to the vCenter server, but only to your hosts of course.

Each team will have a /24 network to protect, containing a number of hosts. In 2015, there were a dozen or so hosts per network. All blue team networks contain the same systems, providing the same services, but they will have different flags and credentials. In front of your /24 is a Cisco ASA firewall. Yes, you get access to configure it, so it’s good to have someone on your team who has seen one before. (My team found this out the hard way this year.)

While the exact hosts are likely to change each year, I feel pretty confident that many of the core systems are unlikely to be dramatically different. Some of the systems that have consistently been present include:

A Windows Server 2008 acting as a Domain Controller
Several Linux servers in multiple flavors: Ubuntu, CentOS, SuSE
A number of Windows XP machines

Responsibilties as a Blue Team Member

This is intended as a learning experience, so nobody expects you to show up knowing everything about attack and defense on every system. That’s just not realistic. But you should show up prepared to play, and there’s several things involved in being prepared:

Make sure you introduce yourself to your team mates via the team mailing list. It’s good to know who’s who, what their skill sets are, and what they’re hoping to get out of the CTF. (And yes, “have a good time” is a perfectly acceptable objective.)
Have your machine set up in advance. Obviously, you’re going to need a laptop to play in this CTF. It doesn’t need to be the fastest or newest machine, but you should have a minimum toolkit:
- OpenVPN to connect to the environment, configured and tested.
- VMWare vSphere Client to connect to the vCenter host. (Windows only, so this might also call for a VM if your host OS is not Windows.)
- An RDP Client of some sort is useful for the Windows machines in the environment.
- Tools to map out your network, such as nmap, OpenVAS, or similar.
- Attack tools for the 2nd day: Metasploit is always popular. If you’re not familiar with metasploit, consider also installing Armitage, a popular GUI front end. I usually run Kali Linux on the bare metal and have a Windows VM just for vSphere client. Make sure you run OpenVPN on your host OS so that traffic from both the host and guest gets routed to the environment properly.
Learn a few basics in advance. At a minimum, know how to connect both to Windows and Linux systems. Never used ssh before? Learn how in advance. There’s a reading list at the bottom of this article with resources that will help you familiarize yourself with many of the aspects involved before the day of the event.
You don’t have to sit there at the table the entire day both days, but you should plan for the majority of the time. If you want to go see a talk, that works, but let somebody know and make sure you’re not walking off with the only copy of a password.

Strategy

I could probably find a Sun Tzu quote that fits here (that is the security industry tradition, after all) but really, they’re getting a bit over used. What is important is realizing that you’re part of a team and that you’ll either succeed as a team or fail. Whether you fail as a team or as a bunch of individuals with no coordination depends on a lot of things, but if you’re not working together, you can be certain of failure.

With so many systems, there’s a lot of work to be done. With Red Team on the advance, there’s a lot of work to be done quickly. You need to make sure that quickly does not turn into chaotically. I suggest first identifying all of the basic hardening steps to be taken, then splitting the work among the team, making sure each task is “owned” by a team member. Some of the tasks might include:

Configure the ASA firewall to only allow in SSH, RDP, and the services you need for scoring purposes. (Note that you’re not allowed to add IP filtering against red cell, nor block beacons to the scoring server.)
Change the passwords on each system (divide this up so each individual only has 1-2 systems to handle) and document them. (A Google spreadsheet works well here.)
Start an nmap scan of your entire network as a baseline. (Doing this from one of the hosts within the environment will be much faster than doing it from your laptop over the VPN.)
Start disabling unnecessary services. (Again, responsibility for 1-2 systems per team member.)

Remember: document what you do, especially the passwords!

For the second day, I recommend a roughly 80/20 split of your team, switching after the basic hardening is done. That is, for the first hour or so, 80% of your team should be hardening systems while 20% looks for the low-hanging fruit on other team’s networks. This is a good opportunity to get an early foothold before they have the chance to harden. After the initial hardening (setup ASA, change passwords, etc.), you want to devote more resources to the offensive, but you still need some people looking after the home front.

Good communication is key throughout, but watch out how you handle it: you never know who’s listening. One year we had an IRC channel where everyone connected (over SSL of course!) for coordination so we would leak less information.

Pro Tips

Some tips just didn’t fit well into other parts of the guide, so I’ve compiled them here.

Changing all the passwords to one “standard” may be attractive, but it’ll only take one keylogger from red cell to make you regret that decision.
Consider disabling password-based auth on the linux machines entirely, and use SSH keys instead.
The scoring bot uses usernames and passwords to log in to some services. Changing those passwords may have an adverse effect on your scoring. Find other ways to lock down those accounts.
Rotate roles, giving everyone a chance to go on both offense and defense.

Conclusion

The most important thing to remember is that you’re there to learn and have fun. It doesn’t matter if you win or lose, so long as you got something out of it. Three years straight, I’ve walked away from the table feeling like I got something out of it. I’ve met great people, had great fun, and learned a few things along the way. GL;HF!

Hacker Summer Camp 2015: DEF CON

13 Aug 2015 in Security (Reading time: 10 minutes)

So, following up on my post on BSides LV 2015, I thought I’d give a summary of DEF CON 23. I can’t cover everything I did (after all, what happens in Vegas, stays in Vegas… mostly) but I’m going to cover the biggest highlights as I saw them.

The first thing to know about my take on DEF CON is that DEF CON is a one-of-a-kind event, somewhere between a security conference and a trip to Mecca. It’s one part conference, one part party, and one part social experience. The second thing to know about my take on DEF CON is that I’m not there to listen to people speak. If I was just there to listen to people speak, there’s the videos posted to YouTube or available on streaming/DVD from the conference recordings. I’m at DEF CON to participate, meet people, and hack all the things.

I generally try not to spend my entire DEF CON doing one thing, though I’d probably make an exception if I ever got to play in DEF CON CTF. (Anyone need a team member? :)) It’s a limited time (on papser, 4 days, but really, it’s about 2.5 days) and I want to get in all that I can. This year, I managed to get in a handful of major activities:

A Workshop on Auditing Mobile Applications
Playing OpenCTF
Playing Capture the Packet

I also attended a few talks in the various villages, including the wireless village and the tamper evident village, worked at an event for my employer, and got lots of opportunities for finding out what others are working on and the fun & interesting projects people are doing. (And perhaps I attended a party or two…)

Auditing Mobile Applications

The auditing mobile applications workshop (taught by Sam Bowne, an instructor at CCSF) was interesting, but wasn’t as much depth as I’d hoped. Firstly, it was strictly confined to Android and didn’t cover iOS at all (though some of the techniques would still apply). Secondly, a lot of the attendees were very inexperienced at what I would consider basic tooling. I’m all for classes for every level, but having the same class for every level means teaching to the lowest common denominator. I do have to give him a lot of credit for being well prepared: he had his own wireless router, network switches, and even several pre-configured laptops for student use.

The course attempted to cover several aspects of the OWASP Mobile Top 10, but mostly focused on applications that failed to use SSL, failed to implement SSL, or failed to implement anti-reversing protections (more on that later). The first two were basically tested by installing an emulator, installing Burp Suite, and pointing the emulator to Burp. If traffic was seen as plaintext traffic, well, obviously no SSL was in use. If traffic was seen as HTTPS traffic, obviously they weren’t verifying certificates properly, as Burp was presenting its own self-signed certificate for the domain. In this case, failing connections was treated as a “success” for validation, though not all of the edge cases were being tested. (We didn’t check for valid chain, but wrong domain, or valid chain + domain, but expired or not yet valid, etc. There’s a lot that goes into SSL validation, but hopefully they’re using the system libraries properly.)

Then we got to recovering secrets from APKs. Sam demonstrated using apktool, which extracts and decompiles APKs to smali (a text-based representation of Dalvik bytecode), to look for things like hard-coded keys, passwords, and other relevant information. Using apktool is definitely an interesting approach, and shows how trivial it is to extract information from within the APK.

Next Sam started talking about what he called “code injection.” He pointed out that you could take the smali, modify it (such as to log the username & password entered into the app) and then recompile & resign the app, then upload the new version to the play store. He claimed that this is a security risk, but I quite frankly don’t agree with him there. It’s always been possible for an attacker to provide malicious binaries, including those that look like legitimate software. Though decompiling, modifying, and recompiling may reduce the bar for the attacker, it’s still the same attack. I’m not convinced this is a new threat or really can be mitigated (he suggests code obfuscators), but I think there’s room for disagreement on this one.

If you’re interested in the details, you can find Sam’s course materials online.

OpenCTF

OpenCTF is the little brother of the DEF CON CTF, with anyone able to play. There are a wide range of challenges for any skillset, and even though we didn’t spend a whole lot of time playing, we managed a 10th place finish. (Team Shadow Cats). One of my favorites was aaronp’s “Pillars of CTF”, which took you on a tour through the various areas commonly seen in CTF: reverse engineering, network forensics, and exploitation. Each area was relatively simple, but it had great variety and just enough challenge to make it interesting. Other challenges included web challenges with a bot visiting the website (so client-side exploitation was possible), more difficult PCAP forensics, and plenty of reversing. I haven’t played much CTF lately (before the week in Vegas), but it was really good to get back into it, especially since this was more of a Jeopardy-style CTF than the Attack/Defense in Pros vs Joes.

Capture the Packet

I don’t do any network forensics at work, but I find it a fascinating area of information security. Every year (save one) I’ve been to DEF CON, I’ve played in the “Capture the Packet” challenge. Basically, you get a network port on a 100Mb network, and a set of ~15 questions, and you need to find the answers to the questions in the stream of network traffic. Questions range from “What is the password for ftp user x?” to “There was a SIP call between stations 1001 and 1002. What was the secret word?” It’s non-trivial, and will stretch anyone but the most seasoned incident responder, but it’s a great opportunity to exercise your Wireshark skills.

Pro tip: I like to separate capture from analysis. If you live capture in Wireshark, it gets slow, and when the number of packets is too large, filtering becomes extremely laggy. Instead, I’ll start tcpdump in a shell session, then analyze the pcaps with Wireshark or other tools. (I’m contemplating writing a collection of domain-specific tools just for fun, and to help in future CTPs.) If you’re not a tcpdump expert, the command line I use is something like this:

tcpdump -i eth0 -s 0 -w packets -C 100

What this does is capture on interface eth0, unlimited packet size, write to files named like “packets”, and rotate the file every 100 MB. This way I can keep my cap sizes manageable, but avoid too much risk of splitting connections across multiple pcap files.

If you haven’t tried CTP before, I really recommend it. The qualifying round only takes about an hour, and some years (not sure if it was this year) it’s a black badge challenge, though you need to qualify + win finals.

Thoughts on the new venue

So, this was the first year at Bally’s/Paris combined, and it wasn’t without growing pains. The first couple of days, traffic was crazy, especially near the Track 1-4 areas in Paris, but the Goons quickly adapted and got the traffic flowing again (making one-way lanes really helped).

The best part was being on the strip. It meant it was easy to get to restaurants outside the venue without cabbing, and it was a much more attractive hotel than the Rio. (Yay no more awkward bathroom windows!)

The worst part, however, is that the conference area at Bally’s is all the way in the back, so you have to walk a non-trivial distance between the two areas. I definitely got my 10,000 steps a day in every day that week. There’s nothing DEF CON can do about this at the current venue, and I can use the exercise.

Conclusion

I had a great time, but felt like I didn’t do as much as I had hoped. I’m not sure if this was unrealistic expectations, or just a perception of doing less than I actually did. I definitely learned new things, met new people, and generally consider it a successful year, but I’m always a little wistful when it ends, and this year was no exception. I keep telling myself I’ll do something interesting enough to end up on the stage one year – maybe 24’s my lucky number.

Hacker Summer Camp 2015: BSides LV & Pros vs Joes CTF

11 Aug 2015 in Security (Reading time: 5 minutes)

I’ve just returned from Las Vegas for the annual “hacker summer camp”, and am going to be putting up a series of blog posts covering the week. Tuesday and Wednesday were BSides Las Vegas. For the uninitiated, BSides was founded as the “flip side” to Black Hat, and has spawned into a series of community organized and oriented conferences around the globe. Entrance to BSides LV was free, but you could guarantee a spot by donating in advance if you were so inclined. (I was.)

As regular readers know, I play a little bit of CTF (Capture the Flag), and BSides LV is home to one of the most unique CTF competitions I’ve ever played in: the “Pros vs Joes” CTF run by dichotomy. This CTF pits multiple defending teams (Blue Cells), each consisting of Joes + 1 Pro Captain, against a “Red Cell” consisting of professional penetration testers. Even though I work in security, my focus is on Application Security and not Network Security (which PvJ highly emphasizes) so I’ve never felt comfortable playing as a pro. Consequently, this was my 3rd year as a “Joe” in the PvJ CTF. (Maybe one day I can make it through my Impostor Syndrome).

If you’re not familiar with this CTF, here’s the rundown: on the first day, each blue cell defends their network against attack by the red cell. For the blue cells, the first day is entirely defense. On the 2nd day, the red cell is “dissolved” into the blue cells. Each blue cell gained two new pros and it was blue cell vs blue cells, so we had to take on the role of both attacker and defender. It’s great fun and requires a ton of work to set up, so my hat goes off to dichotomy for organizing and running it all.

Though I’ve played in the past, this year brought new challenges and experiences. Firstly, there was significant integration between the CTF and the Social Engineering CTF. (Apparently even more than I realized when playing.) This brough interesting components, such as people trying to social engineer information out of us or get us to help them with tasks for the SECTF, but it also brough challenges, the most significant of which was people who joined the CTF solely to gain information to help them with the SECTF. It’s my hope that next year, team captains will be allowed to “fire” team members that are obviously attempting to “leak” information.

There were other changes as well. In the past, there were two blue cells and one red cell, this year dichotomy managed to up it to a whopping four blue cells! This brought us a total of 44 players, which was obviously no small feat for both dichotomy and the conference organizers. There was also a greater emphasis on the use of “tickets” in the scoring system. Now, I’m not a fan of the tickets myself. Most of them consist of boring inventory or asset management work, and it’s often not clear exactly what response is expected to them. Hopefully this is the sort of thing that will be tweaked by next year. (As it was, the scoring tweaks dichotomy made to the ticket system between the first and second day were a welcome improvement.)

By far, however, the most interesting change to me was obvious even upon walking in the room. As soon as I saw the tables, I noticed something new: SIP phones on each table. Yes, they were connected. To a PBX. That was in scope. And had default credentials. That was definitely new – and not something most of the teams picked up on.

All things considered, I feel that my team (“Endtroducing”) did pretty well with a 2nd place finish. The first place team just seemed unbeatable. I don’t know if it was a different ratio of attack/defense, luck, different skills or what, but it worked out well for them.

In the next week or so, I’ll be writing a blue team player’s guide based on my 3 years of experience. It’ll expose some things about the play environment that have been constant for the 3 years, some tactics I’ve used, and just some general guidance on preparing for the Pros vs Joes CTF.

Playing with the Patriot Gauntlet Node (Part 2)

20 Jun 2015 in Security (Reading time: 2 minute)

Despite the fact that it’s been over 2 years since I posted Part 1, I got bored and decided I should take another look at the Patriot Gauntlet Node. So I go and grab the latest firmware from Patriot’s website (V21_1.2.4.6) and use the same binwalk techniques described in the first post, I extracted the latest firmware.

So, the TL;DR is: It’s unexciting because Patriot makes no effort to secure the device. It seems that their security model is “if you’re on the network, you own the device”, which is pretty much the case. Not only can you enable telnet as I’ve discussed before, there’s even a convenient web-based interface to run commands: http://10.10.10.254:8088/adm/system_command.asp. Oh, and it’s not authenticated. Even if you set an admin password (which is hidden at http://10.10.10.254:8088/adm/management.asp).

The device runs two webservers: on port 80 you have httpd from busybox, and on port 8088, you have a proprietary embedded webserver called GoAhead. It uses not ASP, as the file extensions would have you believe, but actually uses an embedded JavaScript interpreter called Ejscript to generate active pages.

I don’t intend to spend much more time on this device from a security PoV: it doesn’t seem intended to be secure at all, so it’s not like there’s anything to break. The device is essentially pre-rooted, so go to town and have fun!

Lack of Updates, Turning 30

09 May 2015 in Personal (Reading time: 2 minute)

I’ve been disappointed with myself for a while for not updating more often. It’s been months! I’d been pushing myself to update regularly, but I also only want to update with genuine content. Social networks are places where I can just place random thoughts, this is a place for meaningful content that will (hopefully) be useful to others. (Though the jury’s still out on that one.)

Part of the reason for the lack of updates is burnout. For one reason or another, I just haven’t been feeling myself for a while, and so haven’t been doing as many interesting things. Some of this burnout is due to the nature of things I’ve been doing at work, but it wouldn’t be fair to blame all of it on work.

I’ve also been dealing with some (potential) health issues. Mostly it’s been a case of symptoms with no obvious cause, which is even more maddening to me. Despite reassurances from doctors, I can’t help but have a nagging feeling that something is actually wrong. It’s quite the distraction, psychologically.

So, in more timely news, I’ve made the transition from “20s” to “30s” (two weeks ago). When I was 25, I posted asking if 25 was old, because I felt like I hadn’t accomplished anything. Though I think I’ve accomplished a few things in the interceding time, I’m not convinced it was 5 quality years worth. I need to get better at prioritizing my time and making sure that I use my time in good ways. I’d like to make sure I’m either doing something I enjoy, something meaningful, or something helpful to others. Anything else is just a waste of precious time.

System Overlord

A blog about security engineering, research, and general hacking.