Wednesday, January 6, 2016

Gnome in Your Home Part One: Wireless Packet Analysis

The first challenges in the 2015 SANS Holiday Hack involve network packet analysis to discover a botnet communicating over DNS.

This is one of a multi-part series describing my approach to solving the 2015 SANS Holiday Hacking Challenge; watch SecurityForRealPeople.com over the next few days as solutions for each challenge are published. After reading, try your hand at the challenges at HolidayHackChallenge.com!


Part One Challenges:

  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?
Packet capture file: giyh-capture.pcap
Useful tools: Scapy, Wireshark

Summary: The gnomes communicate with a Command and Control server using covert DNS traffic; the DNS traffic contains base64-encoded commands from the server to the gnome, and a base64-encoded JPG image is sent from the gnome to the server.

I love that even more than m
ost CTFs, this one is designed to appeal to kids. My 12-year-old daughter has shown an interest in cybersecurity, so this turned into a great way to teach her a few things. Even better, most of the lessons were in response to her own questions.

My tool of choice for packet analysis is Wireshark, a tool I first used when it was still called Ethereal. To understand packet analysis though, it is useful to understand a little bit about how networks work.

Traditionally, network concepts are defined in terms of "layers." At each layer, one device talks to another, and each layer does not care what is happening at the other layers. For some basic background, check out this simplified explanation I gave to my 12 year old.

Upon opening the packet capture file (known as a pcap) in Wireshark, it pretty quickly became apparent that all of the packets fall into two types – 802.11 beacon and probe frames, and DNS traffic. Since the 802.11 traffic is all local (it is a layer 1 / layer 2 protocol, after all, which defines how WiFi devices communicate with one another), we focused on the DNS traffic first.

Viewing DNS packets in Wireshark

You may recall a previous post describing DNS as a phone book or contact list, translating human-friendly website names into computer-friendly Internet addresses. What we found was traffic between a local device 10.42.0.18 and a remote server 52.2.229.189. For kicks, I did a nslookup and a whois on the destination; it is an Amazon Web Services instance, so nothing particularly interesting at first glance.

What was interesting though was the content of the traffic. The local device repeatedly sends queries for the address of a server named cmd.sg1.atnascorp.com (which, by the way, does not resolve). The responses are, shall we say, unusual?

The DNS standard defines a variety of "resource record" types. Some common types are "A" for a computer hostname record; "MX" for a mail server; "NS" for a name server; and "TXT" for descriptive text or comments. The first handful of DNS responses in the pcap all contain in the answer a TXT record containing “Tk9ORTo=”

A DNS packet detail shown in Wireshark

Hmm … might that be base 64-encoded data?

It is indeed. It decodes to “NONE:”. By itself, that doesn’t give us much context, but it is hardly what I would expect in response to a DNS query asking for the address of a website.

The majority of the DNS packets contain similarly encoded responses, so the next step is to decode them all and see what is going on. I was not in the mood to decode over 500 packets by hand, so it’s time to do a little magic.

Our first approach was to use Wireshark to export the DNS records to a text file: File > Export Packet Dissections > as “Plain Text” file…

Exporting all DNS packets from Wireshark to a text file

The resulting export includes over 500 entries that look a bit like this; the bit of data we are interested in is at the bottom, after the field title "TXT:"

The content of a DNS packet, after exporting to a text file

Windows provides some useful built-in command line functions. The following command line parses the export file, extracting only the lines containing “TXT: ” then splitting those lines using a colon or space as a delimiter, and finally writing the second split field to a separate file. The result is that the value of the “TXT” field in every DNS answer record (i.e. the base64 encoded data I am interested in) is extracted to a separate file.

for /f "tokens=2 delims=: " %i in ('findstr /c:"TXT: " dns-export.txt') do echo %i >> strings.txt

The result looks a bit like this:

Tk9ORTo=
RklMRTovcm9vdC9QaWN0dXJlcy9zbmFwc2hvdF9DVVJSRU5ULmpwZwo=
RklMRTpTVEFSVF9TVEFURSxOQU1FPS9yb290L1BpY3R1cmVzL3NuYXBzaG90X0NVUlJFTlQuanBn
RklMRTpTVE9QX1NUQVRF
Tk9ORTo=

Which when piped through a base64 decoder yields:

NONE:
FILE:/root/Pictures/snapshot_CURRENT.jpg
FILE:START_STATE,NAME=/root/Pictures/snapshot_CURRENT.jpg
FILE:STOP_STATE
NONE:

However, something is missing here - there’s nothing between the file start, and the file stop commands. A closer look at the packet capture shows why: in between those two packets are a large number of DNS queries containing a slightly different data record:

Some DNS packets include a truncated TXT resource record

Note that the data field is labeled “TXT [truncated]:” instead of “TXT:

Knowing that though, now we can tweak the for loop a bit to extract all the truncated pieces:

for /f "tokens=3 delims=: " %i in ('findstr /c:"TXT [truncated]: " dns-export.txt') do echo %i >> strings.txt

One small gotcha: the last record in this sequence is not truncated. The data being sent to the DNS server was cut into smaller chunks that would fit in the size limit for a DNS record; the last piece of data did not need to be further divided, so is not truncated. It was easy enough to manually extract the final bit of base64 data and add it to the file though. The next step was to base64 decode the entire file and then attempt to open it in an image viewer.

And … nothing. The decoded data did not make up a usable JPG image. A quick binary analysis showed that the file did in fact contain markers (in the forensics world, called "magic numbers") denoting a JPG image file, but also contained repeated instances of the text string “FILE:”. Encoded at the beginning of each DNS record's TXT field was the word “FILE:” followed by a piece of the actual file. Using a hex editor, it was easy enough to remove every instance of this string, but the file still would not open.

Tim Medin's avatar in the quest mentions a blog post by Josh Wright that hints at out-of-order packets. I tried having Wireshark sort the DNS packets based on the time stamp in each record, then exported the data and repeated the above exercise, but that still did not work. My suspicion is that Wireshark applies a sort operation to the records as it displays them, but keeps the original data for exports.

This was getting rather convoluted, so I changed tactics. I had never used scapy before, but a hint within the quest suggested scapy would make this task much easier. And it did: after installing scapy on my Linux system, it took only a few lines of Python code to extract the data, decode it, remove the extraneous FILE: strings, and generate what turned out to be a proper image:

import base64
from scapy.all import rdpcap
p=rdpcap("giyh-capture.pcap")
o=sorted(p, key=lambda ts: ts.time)
y= ""
for num in range(876, 1403):
  if hasattr(o[num], "dst") and o[num].dst=="52.2.229.189" and hasattr(o[num], "an"): y += base64.b64decode(o[num].an.rdata[1:])[5:]
jpg=open("snapshot_CURRENT.jpg",'wb')
jpg.write(y)
jpg.close()

A few notes:
  • Josh Wright's blog post describes a very simple way to sort a packet capture file by time, thereby ordering the packets in the same order they were sent.
  • By looking at the packets in Wireshark, I see that the data I am interested in is packets 877 to 1403, where the packet is a DNS query, and the destination is 52.2.229.189. Since scapy follows common coding practice of numbers starting at 0 instead of at 1, and since its range syntax will include everything from the first number in the range, to *before* the last number in the range, I changed the offset range to be 876 to 1403.
  • The "rdata" field has the field length encoded in the first position, so I use an offset of 1 to skip the first byte (which is byte 0, per the above comment), then base64 decode it.
  • The decoded data begins with "FILE:" in each record, so I grab everything from offset 5 to end (again, "FILE:" occupies offsets 0 through 4 of each line), and append it all into one big byte-string, which I then write out to a file.

The result? A picture of a child's bedroom, with the text "GnomeNET-NorthAmerica" printed at the bottom.

The payload: a base64-encoded image of a child's bedroom

  1. Which commands are sent across the Gnome’s command-and-control channel?

    Base64-encoded as TXT records in DNS communication are the following commands:
    NONE:
    EXEC:iwconfig
    EXEC:cat /tmp/iwlistscan.txt
    FILE:/root/Pictures/snapshot_CURRENT.jpg

  2. What image appears in the photo the Gnome sent across the channel from the Dosis home?

    The gnome sent a photo of a child's bedroom, with the text "GnomeNET-NorthAmerica" printed at the bottom.

Update January 8:

I used scapy and Python to solve this challenge. A colleague took a different approach that is elegant in its simplicity:

tshark -n -r c:/pcap/giyh-capture.pcap -T fields -e dns.txt -E header=n -Y dns.flags.response==1 > dns_txt.txt

-n                                      Don’t do name resolution
-r c:/pcap/giyh-capture.pcap            Read this trace file
-T fields                               Output decoded fields
-e dns.txt                              Include this field
-E header=n                             Don’t include the field header
-Y dns.flags.response==1                Apply this display filter
> dns_txt.txt                           Pipe the output to a text file

This quickly and easily extracts the TXT records from all DNS response packets using tshark, a command-line utility included with Wireshark. Having the TXT records, it is a simple matter to base64-decode them all, remote the "FILE:" text from within the truncated records, and export the image file.

Do you have something to add? A question you'd like answered? Think I'm out of my mind? Join the conversation below, reach out by email at david (at) securityforrealpeople.com, or hit me up on Twitter at @dnlongen

Whois David?

My photo

I have spent the better part of two decades in information technology and security, with roots in application developer support, system administration, and network security. My specialty is cyber threat intelligence - software vulnerabilities and patching, malware, social networking risks, etc. In particular, I strive to write about complex cyber topics in a way that can be understood by those outside the infosec industry.

Why do I do this? A common comment I get from friends and family is that complex security topics give them headaches. They want to know in simple terms how to stay safe in a connected world. Folks like me and my peers have chosen to make a profession out of hacking and defending. I've been doing this for the better part of two decades, and so have a high degree of knowledge in the field. Others have chosen different paths - paths where I would be lost. This is my effort to share my knowledge with those that are experts in something else.

When not in front of a digital screen, I spend my time raising five rambunctious teens and pre-teens - including two sets of twins. Our family enjoys archery, raising show and meat rabbits, and simply enjoying life in the Texas hill country.

For a decade I served as either Commander or a division leader for the Awana Club in Dripping Springs, Texas; while I have retired from that role I continue to have a passion for children's ministry. At the moment I teach 1st through 3rd grade Sunday School. Follow FBC Dripping Springs Kids to see what is going on in our children's ministries.