The following is a team member spotlight on Cory Duplantis, senior security engineer and researcher at Praetorian. Cory, an avid capture the flag (CTF) wizard, has included an excerpt from his recent 2015 SANS Holiday Hack Challenge solution writeup below (spoiler alert).
Engineering Spotlight on Cory Duplantis
So Cory, why CTFs?
As an engineer, solving puzzles is part of everyday life. Any new challenge, whether it be learning a new exploitation technique or seeing a new embedded architecture for the first time, is simply another puzzle that I can learn how to solve in time. It is that mindset of always being curious and wanting to explore and apply new concepts that is utilized every day at Praetorian. This mindset is also my default when approaching capture the flag (CTF) puzzles such as the CounterHack Holiday Hack from this past year. As an internal penetration tester at Praetorian, I don’t usually dabble in the web spaces frequently, so the web challenges from the HolidayHack were a great opportunity to brush off the old web knowledge and maybe add a new web technique to the ever growing bag o’ tricks.
How did you first get involved in CTFs?
I was introduced to CTFs in college by a PhD candidate, and now associate professor at Mississippi State Univerity, Wesley McGrew. I showed up to the meeting to “hack on things”, which seemed incredibly exciting at the time. After leaving the CTF having not solved a single problem, I realized that there was a ton of information out there on Information Security that I hadn’t explored and needed to brush up on in order to seriously compete in these events.
From that point on, I tried to attend any CTF event that Wes was putting on for the undergraduates. Little by little, challenge by challenge, I started to pick up on several infosec concepts. It is one thing to hear about the theory of cross site scripting or buffer overflows, but it completley different when faced with the challenge of implementing those attacks with the goal of gaining unauthenticated information (aka a flag). It was this learning of attacks that really sparked an interest.
After competing in a few collegiate CTFs, I realized that two categories were left fairly blank across all teams: reverse engineering and binary exploitation. I made it a goal after that realization to dedicate more time into those categories to help our team garnish those points that many teams weren’t. I shortly after enrolled in a malware reverse engineering class in order to hopefully gain more of the reverse engineering knowledge and started reading writeups and blog posts on the concepts of binary exploitation.
Fast forward to now, I still feel like I am in the same boat. There are an astonishingly large number of challenges in many of these CTFs and I feel like I have only scratched the surface, which is an amazing place to be! I’m not sure what other format would force contestests to learn information quickly on the fly and then be forced to act on that knowledge. I have always said that, in CTF, one always leaves a CTF weekend with more information than going into the CTF. This montra is the main reason that I continue trying to excel at CTF.
What can you tell me about the Samurai CTF team?
Samurai is an internationally ranked CTF team with members across the globe. Many members in Samurai have been competeing in CTF since the early 2000s at Defcon and many hold black badges, the coveted lifetime membership badge to Defcon for winning the Defcon CTF. What I enjoy most about Samurai is the community is geared towards educating those we are willing to learn about the art of infosec, and in particular binary exploitation and reverse engineering. For example, we hold continuous dojos where we try and tackle a new binary exploitation challenge together.
I stumbled on Samurai by accident. I was learning an open-source Python framework at the time called pwntools. I started chatting with one of the developers Zach Riggle and he brought up Samurai when we were discussing future CTFs. I hadn’t really followed the CTF scene until then and didn’t understand who Samurai was at a large scale. Zach asked me to come on board and that decision alone is definitely the reason why I am so passionate about CTFs. To see so many others in the group excel in their professional career partly due to CTF was hugely motivating.
We’re bringing together the world’s security expertise to solve this fascinating problem. Join the Praetorian team.
Spoiler Alert! The following is a solution to the 2015 SANS Holiday Hack Challenge (part 1 of 5).
Holiday Hack 2015 Writeup by Cory Duplantis
It is that time of year again! Time for the HolidayHack presented by CounterHack! This one is going to be fairly long, but boy are there a lot of cool challenges here. Everything from network forensics, web, image forensics, and even a pwnable.
Quick background about the story this year:
There is a new Christmas toy called Gnome in your Home. Duke Dosis managed to snag one of the last Gnome in your Home toys. Upon setting it up in their home, one of Duke's children, Josh, "opened his trusty Linux laptop and ran a wireless sniffer" and was greeted with a "mysterious barrage of traffic".
It is the analysis of this traffic that leads us down the path to figuring out the back story behind who created this toy.
Part 1 – Dance of the Sugar Gnome Fairies
We are greeted with a generous .pcap present from Josh in the online game for Holiday Hack. We are also asked to answer the following two questions:
1) Which commands are sent across the Gnome’s command-and-control channel?2) What image appears in the photo the Gnome sent across the channel from the Dosis home?
We tackle the .pcap file with good ole Wireshark. After opening the .pcap, we sort by packet info content. A quick glance over the info and we see DNS TXT request packets with the response ID of 0x1337.
Hmm.. that is a bit odd.. What is in this DNS packet?
Double equals.. the obvious sign of base64 encoding.
Our task now is to extract all the DNS packets with Transaction ID of 0x1337 and base64 decode its data to see what is happening. We can utilize our trusty python pcap analysis tool Scapy to handle this task.
Our first task is to read in the pcap and grab all of the DNS packets:
from scapy.all import *import base64
packets = rdpcap(‘gnome.pcap’)
for packet in packets:
if DNSQR in packet:
print packet
Here, we are simply asking to print each packet with a DNS layer. For each of these packets, we now need to check if the Transaction ID is 0x1337 and grab the data from within that packet.
from scapy.all import *import base64
packets = rdpcap(‘gnome.pcap’)
for packet in packets:
if DNSQR in packet:
if packet[DNS].id == 0x1337:
data = packet[DNS].an.rdata
print data
Once we have the data, let’s print the decoded values and see what is being transmitted.
from scapy.all import *import base64
packets = rdpcap(‘gnome.pcap’)
for packet in packets:
if DNSQR in packet:
if packet[DNS].id == 0x1337:
data = packet[DNS].an.rdata
decoded = base64.b64decode(data)
print decoded
Let’s take a quick look at the decoded packets.
We found two things being transmitted in the weird DNS requests:
- The output from an
iwlist scan. This would be used to perform reconnaissance on wireless access points in the area. - An image of some kind.
So we have the answer to the first question:
The command being executed across the command and control is `iwlist scan` which serves as a method of gathering information about wireless access points in the vacinity of the Gnome.
Now, onto figuring out what that image is all about.
Let’s take a look again at the output right as the image is being transmitted.
EXEC: IE: Unknown: 2F0100EXEC:STOP_STATEFILE:START_STATE,NAME=/root/Pictures/snapshot_CURRENT.jpg### And lookie here.. looks like a file is being transferred.. over DNS?!FILE:JFIFC% , #&')*)-0-(0%()(C((((((((((((((((((((((((((((((((((((((((((((((((((("FILE:W!1A"Qa2q#B3R$b4r%CS&5t'c7DsTUde-!1A"Q2aq#
We see that the image being sent is a .jpg, which has the interesting file signature of JFIF in the first few bytes of its header. We can use this as indication that we are looking at the image data. The other annoying bit is that there is FILE: prepending all of the data in the transmission.
In order to extract the image, we need to do the following:
- Flag that we are looking at
.jpgimage data - Remove the
FILE:indicator prepending each line
In order to accomplish the first bullet, we will simply have a global flag that will be set to true once we see the JFIF fly by. After that point, all data will be added to a buffer that will be written to a file after the parsing has completed.
The second bullet can be accomplished in Python very easily: data = data.replace('FILE:', '').
Combining these two bullets, we should be able to extract the image with the following script:
from scapy.all import *import base64
pkts = rdpcap(‘gnome.pcap’)
commands = []
image = False
image_data = ”
# For each packet in the pcap, check for the DSN Transaction ID of 0x1337# This was identified via manual analysis of the pcap itself# Each of these packets contains a base64 encoded string containing# command information.
for packet in pkts:if DNSQR in packet:if packet[DNS].id == 0x1337:data = packet[DNS].an.rdatadecoded = base64.b64decode(data)if 'JFIF' in decoded or image:image_data += decoded.replace('FILE:', '')image = Truecontinue
# Only append commands that don't have FILE in the commandcommands.append(decoded)
with open('picture', 'wb') as f:f.write(image_data)
for command in commands:
print command
After executing the script, we are presented with the picture being sent back to the mother ship (and the answer to the second question).
We can hand in the message GnomeNET-NorthAmerica in the HolidayHack online game to receive the next challenge! Off to checkout the firmware of the SuperGnome!
