CTF Friday Morning: The Ballad of Team Firewall

The meta-game of sniffing and counter-sniffing on our CTF normally makes teams paranoid about submitting flags early in the game.  This paranoia even outweighs the main benefit of submitting early: ties are broken by the time of last submission.  At this point in the game scores are normally low.

This is not a normal instance of CTF, though.  One team, Team Firewall has embraced the risks and run up their score early.  As of this morning at 8:15 AM, the scores are as follows:

1. Team Firewall – 24 points
2. Team Wireshark – 3 points
3. Team Sniffer – 1
4. Team Burp Suite – 1
5. Team Nmap – 0
6. Team Tracker – 0

This year, initial team names were chosen by the security class’ professor, Dr. Ray Vaughn.  The names don’t reflect any association with the listed open-source projects (though if the members want to work out endorsement deals, they are welcome to!).

In true nerd fashion, we’ll see how much activity we have in CTF over the weekend with the university’s Super Bulldog Weekend festivities going on.

Spring 2010 MSU Capture the Flag

Today, immediately after my rules lecture to the 9:30AM (Central) information security class, the Spring 2010 iteration of Capture the Flag here at Mississippi State University will begin.  While I have handed off much of the responsibility for running CTF to Chris Vance, our Security Lab Administrator, I will still be covering the event on this blog, much like I did last year.

The format is the same as last semester: 6 teams, trying to capture as many “flags” (10-digit hexadecimal strings. For example: 489066dd35) as possible.  They submit these flags to a scoring server that also happens to be in the target network.  There is always a very interesting meta-game between the teams, as they try to figure out how to submit their flags securely.

Last semester was the first CTF to run for multiple days, and I believe it was a huge success.  We’re continuing this time format, and the current CTF will run until 9:30 AM on Tuesday.  I will update this site with scores and a bit of commentary (though I won’t be spending as much time in the lab this time as I did last semester).

Here’s a list of posts from last semester’s CTF:

• Capture The Flag Begins Today!
• CTF Update: Wednesday 5:00PM
• CTF Update: Thursday Morning
• CTF Update: Thursday 5:00PM
• CTF Update: Friday Morning
• CTF Update: Friday 5:00PM
• CTF Weekend Update: Sunday 2:30PM
• Capture The Flag: Final Scores – Ring 0 Wins!

iTunes TOS lol

I went to download the Opera Mini web browser on my iPod Touch (quick review: nice, fast!) and it made me agree to the new iTunes/App Store terms of service.  Times like this make me glad I don’t have a credit card associated with the iTunes account at the moment:

I’d love to see some statistics on how far people make it before giving up.

MSU Red Team – Fun, Success

The guys that I brought together here at Mississippi State to serve as a Red Team for University of Alaska Fairbanks’ CCDC had a great time Saturday.  This CCDC was a “practice” run for two Alaskan teams and two Hawaiian teams, and I believe we gave them a good taste of what they’d likely face in regional and national CCDCs if they decide to run it again for-real next year and send a team to regionals (which I hope they do!).

I gathered up a team of skilled students here that had performed well in past CTF events we’ve held here at MSU, or otherwise shown some aptitude (such as the guy who developed our SCADA radio attacks).  With a good team in place, we prepared our attack with the following goals in mind:

• Fair distribution of attacks – If we were able to compromise a team’s system, once we were in, we tried to run the same kind of attack against all of the other teams.  If a team escaped the evil treatment we gave another team, it was because they had defended themselves against it, and not due to arbitrary choices of who we pick on.
• Annoyance, not destruction - Once we were in, we were careful to not do anything that the teams could not recover from.  No “rm -rf” or dropping tables.
• Increasing levels of noise – Early in the game, our goal was to get in and subvert things quietly.  As the game progressed, I instructed my Red Team to get increasingly “loud” and annoying, to see at what point the teams realized there was a compromise, and observe how they would react.

I won’t go into too much detail about the scenario, in case they want to re-use parts of it, but I can give a good summary of things from the Red Team perspective without getting into spoilers.  On our end, we set up shop in the MSU NFTC’s forensics lab (our security lab is isolated from the public Internet), and connected to the CCDC network remotely using the VMWare vSphere client.  There, the organizers had set the red team up with a number of Backtrack 4 and Windows XP virtual machines.

The defending teams were given a 30 minute grace period, during which we were only allowed to perform recon.  We took the time to scan the network, and get Metasploit and other tools ready to go.  I quickly knocked together a phishing site based off the web applications the teams had to maintain.

Within the first five minutes of our attack, members of the Red Team had compromised all four teams’ DNS servers and installed back-door software that maintained access for most of the competition.  This allowed us to point the teams’ domain for web access (www.) to the phishing site I created and set up before the attack.  This site logged usernames and passwords for all teams throughout the competition, and served as a nice central place to deface and taunt them (with the phished account list) once we decided to get noisy.

While we waited for the central DNS server to update its cache for the teams’ web servers, I managed to break their web apps, so that if they did manage to point them back to the right location, they’d still have some work to do.  They were running a web hosting business that allowed new clients to select the subdomain they wanted to host their site.  I registered an account on the first team’s site and requested the “www.” subdomain.  This instantly replaced their web app with an Apache test page.  Delighted, I moved on and broke the others in the same way.  Only one team’s app survived this, but only because they had broken account creation and login (likely, by trying to secure Apache or Django’s config).

From this point on, we played cat-and-mouse with the teams on their other systems, but they never resumed business operations.  One thing we discussed with them in our post-game wrap-up was a sense of priority.  I’m not sure how it would reflect in the scoring of a regional or national CCDC, but at least in the real world, the focus should have been on getting their web sites back up and operational so that business could continue.  Everything else could work, but if you can’t sign up new clients or provide service, you’re dead in the water.  Most of the other stuff we did (compromising the mail server to send resignation letters and rude emails to the CCDC organizers on behalf of the teams, fighting for control/chatting with team members on their workstations) were distractions to keep them from kicking us out of the systems that really mattered.

Overall, though, the teams did a good job of not panicking in a bad-and-rapidly-deteriorating situation.  By the end, a couple of the teams had managed to kick us out of their DNS servers and given some more time, would have been able to restore operations.  They all seemed to be good sports about it too :)

As for my Red Team, I’m very proud.  They held it down, but kept things fair and didn’t make things hopeless for the defenders.  They quickly executed our planned attacks and kept their eyes on the goal: disrupting business, not just owning boxes.

Interesting Reading, and Red Team Action

I’ve been busy this week teaching part of the intro series of courses we have at the National Forensics Training Center, but I still wanted to post a quick update.  I figured I’d share a few interesting things I read this week, and talk a bit about some extracurricular activities going on in our lab tommorow.

For a couple of weeks now, I’ve been using Instapaper to mark articles and sites to “Read Later”.  The benefit of Instapaper is, with the integration and sync’ing between all the different computers I use and (crucial) my iPod Touch, I actually wind up reading things that I intend to read later, instead of them just getting bookmarked and forgotten.  While I’m on WiFi I can sync them all up to the iPod and read them anywhere, offline, where I don’t have the distractions of grabbing new emails and messages.

Some things I star’d and enjoyed recently:

• Should I Learn Assembly Language – HD Moore tackles the question of whether or not penetration testers have a need to learn assembly language.  Spoiler: The answer is, essentially: you can get away with not knowing it if you just use the shellcode in Metasploit, but it’s a must if use public-sourced exploits or just want to understand how the shellcode works (which you should).
• Network Time Protocol (NTP) Fun – Cool little writeup over at the carnal0wnage blog about a new module in Metasploit that performs some information gathering over NTP.
• Clueless FUD Article… – In which Steve Manzuik points out that there is a lot more information sharing going on behind the scenes in infosec than you might be aware of (or at least more than the author of a specific DarkReading article is aware of)

Tomorrow afternoon, a group of guys (who have historically done well in past CTF events here at the university) and I will be acting as the red team for a cyber-defense exercise being hosted by the University of Alaska Fairbanks.  They have a nice VMWare setup in Fairbanks that all of the teams will be remoting into, and we’re really looking forward to giving the participating universities a hard time.  If you happen to be one of the readers that local enough to Mississippi State University to drop by for a visit, feel free to come by the forensics lab in Butler Hall tomorrow between 1:30 and 7:30 PM to see how things are going.

New Job at the NFTC!

Today was officially my first day at my new job.  I’ve taken a full-time position at Mississippi State University’s National Forensics Training Center.  The NFTC is a really great program we have in the Computer Science & Engineering department, that has a handful of primary tasks:

• Training law enforcement agents to respond to and investigate crimes involving digital evidence
• Giving wounded veterans digital forensic training, to give them a useful skill set and experience as they transition to other roles and jobs
• Providing equipment for “Mini-Labs” throughout the state of Mississippi to distribute the case-load of digital forensic investigation here

The training provided by the NFTC is free for the students that qualify for it.

Now that I am working at the NFTC, I will be wearing many hats:

• I will be updating the curriculum for classes we are currently teaching, and developing material for new classes (I am especially excited about adding a network forensics course later this year)
• I will be teaching the courses that we have developed to law enforcement and veterans, in our teaching lab at MSU, and wherever else we travel to teach our classes
• I will be working to build up a research focus at the NFTC, using our time between classes to develop and publish new digital forensic techniques and tools, free for use by our students and the digital forensics community as a whole.

I’m very excited about bringing my background with security, vulnerability assessment, and penetration testing to the forensics field in this job, and I’m looking forward to publishing more of our efforts in this area.  I will be blogging about forensics more often here, although it will always have a slant that will be interesting to security professionals.  We’ll also be unveiling a new NFTC website soon that will have better information about upcoming classes, and forensics news, whitepapers, and tools that will be of use to those outside of the community of our students too.

Network Forensics Puzzle #3 Finalist!

Today, results were posted for Sherri Davidoff and Jonathan Ham’s third network forensics puzzle contest. The puzzles, hosted at forensicscontest.com, are meant to encourage the development of network forensic tools that might be integrated into SANS training and toolkits. Puzzle #3 involved pulling information from an Apple TV device’s network traffic.

I participated in this contest and wrote a small Python script that generates a .CSV summary of Apple TV activity on a network and extracts .plist files from that traffic. It was a lot of fun to tinker around with, and it looks like I just managed to land in the list of finalists. You can check out the finalist entries, including mine, at the following links:

• Puzzle #3 Winners
• My Entry: atvsnarf.py and my writeup

These competitions are fun to participate in, and I’m hoping that I’ll have time to finish up my entry for Puzzle #4 before the deadline.

Using SkyGrabber to Hack Unmanned Drones?

There has been a lot of speculation today surrounding this Wall Street Journal article:

• Insurgents Hack U.S. Drones

According to this article, the insurgents were able to capture drone video feeds using software like SkyGrabber.  SkyGrabber is, according to its website, essentially a sniffer for satellite Internet connections that can recognize and extract.  This works because the data stream from the satellite to the clients on the ground is undirected.

This article has fueled a lot of discussion along the lines of “Why aren’t drone feeds encrypted?”.  There are plenty of people writing about that question, so I’m going to take it in another direction:

“What if we (including the WSJ) are missing something here?”

What if the videos found on insurgent laptops were not direct data streams from the drones themselves?  What if they were actually captured as files being shuffled from one place to another over a satellite Internet connection, after they had been recorded and saved?

Now, I haven’t used SkyGrabber, so I would like some feedback from someone who has used it on this, but there are some things that don’t really make sense to me yet about this.  Looking at the feature list for SkyGrabber and (especially) the screenshots, I see progress bars for the downloads.  A progress bar indicates that you know when the file you’re downloading will end.  That indicates, to me at least, that SkyGrabber gets most of its data from protocols like HTTP (and P2P protocols as it states on the product pages) that indicate the size and name of files that they are about to transmit.

How do you know when a live stream, such as one that a drone is transmitting, is going to end?  How likely is it that, if it does record live streams, SkyGrabber would be able to recognize whatever streaming format the drone uses?  Someone with some experience using SkyGrabber (or, more unlikely, unmanned drone communication protocols) might be able to chime in on this.

Now, if recordings are being shuffled around after a mission from location to location, then it would make sense for those to go over protocols that SkyGrabber might understand.  This would fit with the “U.S. officials” statement that there was no evidence that the flights could be controlled or interfered with.

Without any other evidence, it’s hard to take the WSJ article as the complete story.  There’s a lot of room for alternatives:

• The feeds being intercepted may not be live
• Software other than SkyGrabber might be used
• Maybe the story’s right-on and the drone is communicating over well-understood and parse-able protocols

It’s even possible that, while these incidents could have involved interception of non-live data, that the drones do communicate unencrypted and the possibility exists (with better tools) to intercept their feeds.

It’s very hard to say, but there are some of my thoughts on the matter.

Capture the Flag: Final Scores – Ring 0 Wins!

Ring 0 pulled it off in the end, with VM to VM flag submission to prevent their own flags from going out on the wire, thwarting the McGrewchebag’s attempts at automated sniffing/resubmission.  They were here all night hacking away and their devotion paid off.  I expected to find them face-down on the keyboard when I got back to the lab at 7AM, but they were still going, fueled by caffeine.

In the last moments of the game, with “Eye of the Tiger” playing from an unidentified laptop, the two top teams submitted all of the flags they had been afraid to submit earlier, along with plenty of cover traffic.  The scoring server creaked and groaned under the pressure, and I closed all of the other VMs to help out a bit.  When the clock hit 9:00 AM, I pulled the power to the hub, cutting the VM server off from the rest of the network.  The two teams congratulated each other, and we all went down to the classroom for the awards ceremony.

The final scores:

1. Ring 0 : 29 Flags
2. McGrewchebags: 23 Flags
3. Where’s Jerry?: 12 Flags
4. Team 3: 6 Flags
5. Team 5: 4 Flags

CTF Weekend Update: Sunday 2:30 PM

The lab has been very busy this weekend.  Yesterday at 3PM I received an email asking me to drop by and reboot the VMs due to sluggish performance, and I expected a handful of people in here when I arrived.  When I got to the lab, I was very surprised to see a little over half the class hacking away.  There were still several people around when I left at 8PM.

After looking into it, we have found that the “Jerry” of “Where’s Jerry”‘s name dropped the class some time back.  That team is on an even footing with the others with 4 members, so there is no injustice there.  I originally had a 1 flag bounty on Jerry’s head, if they could bring him to me, though with these circumstances, I’ve raised the bounty to 2.

Ring 0 was just awarded a flag for a social engineering attempt that I was deliberating on for a while, and another flag for something I cannot disclose at this time.  Right now, it’s a very close three-team race for first place, although it’s hard to say how many unsubmitted flags the teams could be sitting on.

The scores as of this moment:

1. McGrewchebags : 17 Flags (Time of last capture: 3:46 PM Saturday)
2. Ring 0 : 14 Flags (Time of last capture: 11:30 PM Saturday)
3. Where’s Jerry?: 12 Flags (Time of last capture: 1:51 PM Sunday)
4. Team 3: 6 Flags (Time of last capture: 8:22 PM Saturday)
5. Team 5: 4 Flags (Time of last capture: 11:57 AM Saturday)