2016-10-07T10:59:54-04:00http://billblough.net/Octopress2016-06-02T18:50:42-04:00http://billblough.net/blog/2016/06/02/nsa-codebreaker-challenge-2015-task-2This is a continuation of my previous post on the NSA Codebreaker Challenge 2015, and covers
the second task in the challenge.

Task 2

Through SIGINT we have collected a new message file - this one appears to
have been sent to a field operative in the terrorist organization that is
of particular interest. A key file for this invidiual was collected
previously and should still be valid. We believe that this message may
contain actionable intelligence, so please report back with the message
contents as soon as possible. This task will require you to figure out how
to bypass the access controls built into the program that limit which
recipient can decode each message.

The error message gives us a starting point in IDA. We can search for the error message
and begin by looking at the surrounding code.

We can then tell IDA to follow the program flow back to the jump that led here.

Looking at the check before the jump, we see that a value in memory is getting
rotated 8 bits and compared to 0x6962. If the comparision fails, the jump is
taken and the error message displayed.

There are several ways this could potentially be circumvented. For now, we’ll
take the easy option and simply patch the program binary to eliminate the
offending jump.

After saving the modified binary, we run it and we get our message

user@host:~/nsa_codebreaker_2015/task_2$ ./secret-messenger --reveal --action tier2_msg.txt --symbol tier2_key.pem
*****SIGNATURE IS VALID*****
Message: Our plans have been set into motion - Member number 392 is ready to carry out his tasking, and in 2 weeks time the window of opportunity will be open. If it is necessary to abort the action, the authentication code to use is hw8qviacbj6xkus6wsel.
*****SIGNATURE IS VALID*****

which completes the goal for Task 2.

]]>2016-04-28T23:30:37-04:00http://billblough.net/blog/2016/04/28/nsa-codebreaker-challenge-2015Last year, the National Security Agency held a reverse engineering
competition for students. It ran from September 1st to December 31st, and
consisted of four tasks. The results page lists the participating schools
and students, along with tasks completed, rankings, and times. I represented
Florida State University and was able to complete all four tasks in just
under 53 hours.

Background Story

NSA has discovered that the leadership of a terrorist organization is using
a new method of communicating secret messages to its operatives in the
field. Intelligence suggests that each member of the organization is
provided a program that can be used to read the messages, and that a
customized cryptographic implementation is used to generate a
public/private key pair, which is then used to authenticate messages from
leadership to each member.
A copy of the program belonging to a high-ranking operative has been
recovered, along with that individual's key and a text file believed to
contain a hidden message. At first glance, the program appears to simply
check stock information, but this is likely a ruse to make it appear
innocuous. Your mission is to reverse-engineer this software and develop
capabilities to exploit the secret messaging component. There are 4
different tasks for you to complete, with each increasing in difficulty and
building off the previous task(s).

Task 1

We need your help with decoding the message that we've captured. The text
file, key file, and secret messaging program can be found below. The main
objective for this task is to figure out how to decode the message with the
program and report back on your findings.
To complete this task, you will most likely need to analyze the program
binary in order to determine how to trigger the hidden functionality and
decode the secret message.

As stated in the background story, the program appeared to be a simple
stock price query utility:

user@host:~/nsa_codebreaker_2015/task_1$ ./codebreaker3 --help
Help:
--debug true : Show debugging information
--help : Show this help message
--symbol <symbol> : The ticker symbol to reference
--action <action> :
'open' for the days opening price
'low' for the days lowest price
'high' for the days highest price
'last' for the last price
--symbol and --action are required arguments
Stock Information Powered by Yahoo!

and later on, checks whether or not the name matches secret-messenger.

Another interesting bit was a hidden command line option, reveal.

This seemed like enough to give it a try. Creating a symlink from the codebreaker3
to secret-messenger bypassed the name checks. But running the command with
the hidden option still wanted more

user@host:~nsa_codebreaker_2015/task_1$ ./secret-messenger --reveal
Missing required parameter. Run with --help for more info.

The --help text was the same as before. But before heading back to IDA to
look for more hidden options, or to figure out what has to happen next…
what if the existing options behave differently in “reveal” mode?

user@host:~nsa_codebreaker_2015/task_1$ ./secret-messenger --reveal --action tier1_msg.txt --symbol tier1_key.pem
*****SIGNATURE IS VALID*****
Message: Meet at 22:00 tomorrow at our secure location. Come alone, and do not tell anyone - this meeting is sensitive, as leadership will be present. To authenticate yourself, mention the pass code osb4rfmthy5dp22kd7qm at the door.
*****SIGNATURE IS VALID*****

Bingo! The action argument gets the message file, and the symbol argument gets the key file.

In the 2015 SANS Holiday Hack Challenge the goal was to determine the
true purpose of the “Gnome In Your Home” product, as well as “Who” was behind
its development and the details of their dastardly plot. This is a writeup
of my findings and how I arrived at them.

Part 1 - The packet capture

The provided pcap file contained a snapshot of the Gnome’s traffic. Inspecting
this in Wireshark made it apparent that there was covert communication
traffic masquerading as DNS traffic.

Some basic scripting with Scapy made extracting the relevant information
from the traffic pretty straightforward. The results showed commands being
executed on the Gnome via the C&C channel, and an image taken by the Gnome’s
camera being sent back to the controlling system.

Part 2 - The firmware dump

The provided firmware file contained a squashfs filesystem that was easily
unpacked by binwalk.

The firmware was based on OpenWRT and was compiled for ARM. Customized
for use in the Gnome, it contained a Node.js web application, a
MongoDB instance, and Gnome-specific programs sgdnsc2 and sgstatd.

An examination of the database yielded application credentials stored in
plaintext, including credentials for a regular user account, as well as an
admin account.

Analysis of the web application code yielded several vulnerabilities that could
be used to compromise the SuperGnomes. However, much of the relevant code was
commented out, so the vulnerabilities present in a specific SuperGnome would
depend on which version of the code it was running.

Also found in the firmware was the IP address of the first SuperGnome.

Part 3 - Finding SuperGnomes

Accessing the first SuperGnome via a web browser (using the admin credentials
found in the firmware) indicated that there were a total of five SuperGnomes.
Plugging some Gnome-specific information into Shodan quickly led to the
other four, all scattered around the world.

Part 4 - Hacking SuperGnomes

SG-01: For SG-01, no exploits were needed, however. The admin credentials
found in the firmware were enough to access the needed files, including the
gnome.conf, another packet capture, some fuzzy camera images, messages from
“GnomeNet”, and a zip file containing the sgstatd program source code.

The packet capture contained a complete SMTP session, from which the email
message could be read. The email contained plot details, and a rough diagram
of the Gnome surveillance network architecture.

Based on the GnomeNet messages, the fuzzy camera images were evidence of a
software error that caused several camera images to be XORed together.
Conveniently, all of the cameras had been shut off except for the one in the
boss' office, so XORing all of the disabled factory camera images with the garbled
image should produce an image of the boss' office (and maybe even the boss).

The sgstatd source code proved useful, since analyzing the source yielded
another vulnerability that could be exploited on the SuperGnomes.

SG-02: While it was possible to log into SG-02 using the known credentials,
file download was disabled. However, the web application’s camera image
viewer contained Local File Include and Path Traversal vulnerabilities, with the
caveat that it also contained an extension check to ensure that only files with
a .png extension could be viewed/downloaded. Fortunately, it was possible to
bypass this by using the settings upload function to create a subdirectory
named .png, and then crafting the path traversal to include our .png
directory in the path when specifying the local file to include.

With this, it was possible to download the gnome.conf, another packet capture,
and another factory camera image.

The packet capture contained another SMTP session. In this email, the Gnome
hardware order was being discussed, including ARM-based systems, WiFi adapters,
and other hardware.

SG-03: On SG-03, the admin credentials used previously did not work at all
– it wasn’t even possible to log in with them. The user credentials worked, but
did not have access to anything useful. However, the authentication routine
was vulnerable to NoSQL injection. Using Burp Suite to modify form
submissions, it was possible to pass JavaScript into the login form, affect the
DB query, and trick the system in to authenticating as admin even without the
password.

Once logged in, it was possible to download the gnome.conf, another packet
capture, and another factory camera image, all directly from the file download
page.

The packet capture contained another SMTP session. In this email, the evil
plot was revealed - to dress like Santa Claus and rob houses on Christmas Eve!

From: "c" <c@atnascorp.com>
To: <burglerlackeys@atnascorp.com>
Subject: All Systems Go for Dec 24, 2015
Date: Tue, 1 Dec 2015 11:33:56 -0500
Message-ID: <005501d12c56$12bf6dc0$383e4940$@atnascorp.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0056_01D12C2C.29E9B3E0"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AdEsVeghqBzCbZs7SUyM8aoCkrx6Ow==
Content-Language: en-us
This is a multipart message in MIME format.
------=_NextPart_000_0056_01D12C2C.29E9B3E0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
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

SG-04: The admin credentials found in the firmware allowed login to SG-04,
but as expected, file download did not work. However, file upload was enabled,
and was vulnerable to JavaScript injection.

Once again using Burp Suite, it was possible to modify form submissions to
include malicious JavaScript. In this case, any JavaScript included in the
“postproc” form field would be executed on the server, making it straightforward
to display or download any files needed.

Files obtained from SG-04 were its gnome.conf, another packet capture, and
another factory camera image.

The packet capture included another SMTP session. In this email, the CEO
discusses her dislike of Christmas, her evil plot, and her motivations with her
therapist. Based on her signature, it becomes apparent that she is none other
than Cindy Lou Who, of “How the Grinch Stole Christmas” fame.

SG-05: While the found credentials allowed login to SG-05, none of the
upload or download functions were active, nor were any of the previous
exploits successful. However, a port scan of SG-05 showed that port 4242 was
open. Based on analysis of the sgstatd source code, SG-05 was likely running
sgstatd on port 4242, and was therefore likely to be vulnerable.

The earlier analysis of sgstatd revealed a hidden command whose code contained
a buffer size mismatch that could lead to a buffer overflow and arbitrary code
execution.

As an attempt to mitigate buffer overflows, sgstatd employs a stack canary
for the vulnerable function. However, the canary was a constant, so bypassing it
was as simple as ensuring that the canary value was re-copied to the correct
place as part of the exploit payload.

Developing the exploit was mostly straightforward, thanks to some hints from the
challenge instructions. The first hint indicated that stack execution
protection (NX/DEP) was not being used, and checking the sgstatd binary from
the firmware confirmed this. Another hint indicated that ASLR was being used,
and that it might be wise to use a “jmp *esp” ROP gadget to bypass it.

Armed with this information, it was simply a matter of developing the payload,
finding the ROP gadget offsets, etc. The sgstatd source could be compiled with
symbols and debugged, so much of this was simplified. In addition, the sgstatd
binary from the firmware was compiled for x86 instead of ARM, so that was
useful for finding ROP gadget offsets for the target version of the binary.

The first shellcode attempted was a reverse shell using netcat. The payload
executed successfully on the local system against the locally compiled binary,
and also the firmware binary. However, launching it against the target failed.
At the time, it seemed that a firewall was blocking outbound connections, but
this turned out not to be the case. Eventually the problem was tracked
down to an issue with the shellcode itself.

Since at the time it seemed like there was a firewall problem, a different
approach was tried. Instead of using netcat, the payload was rewritten to
reuse the socket descriptor and open a shell over the existing connection.
This was made more difficult by sgstatd using randomized socket descriptors.
Frequently, this is handled by randomly trying to “brute-force” the socket
descriptor, and eventually succeeding. However, since the socket descriptor
was passed as an argument to an earlier function call, the value was still on
the stack. And since the function calls (and therefore stack layout) are
fairly consistent, it was simple enough to find the descriptor on the stack
with the debugger, calculate the offset relative to EBP/ESP, and then have the
payload retrieve the value using the offset.

All of this worked both locally and against the target, yielding a shell and
the necessary files. Files obtained were SG-05’s gnome.conf, another packet
capture, and another factory camera image.

The packet capture contained an IMAP mail session. In this email, the Grinch
was apologizing to Cindy Lou Who for what happened in the past.

Part 5 - Attribution

As previously discovered in the email, the culprit is Cindy Lou Who, from “How
the Grinch Stole Christmas”, and her plot was to steal from families on
Christmas Eve using burglars dressed as Santa Claus.

Additionally, with all 5 factory camera images, it was possible to XOR them
together with the garbled camera image, producing an image of Cindy Lou Who,
age 62, sitting at her desk.

Comments

Overall, this was a very enjoyable challenge. Not only did it require a good
mix of skills, it was a good opportunity to brush up on old skills and pick up
some new skills at the same time. It also had a fun theme.

VLC versions before 2.1.5 contain a vulnerability in the transcode module that
may allow a corrupted stream to overflow buffers on the heap. With a
non-malicious input, this could lead to heap corruption and a crash. However,
under the right circumstances, a malicious attacker could potentially use this
vulnerability to hijack program execution, and on some platforms, execute
arbitrary code.

With a sufficiently corrupted input stream, this allows for a situation where
the buffer is allocated to contain one channel of data, but then two
channels of data are written to it, causing the write to overflow the
buffer.

Remediation

Prior to being notified of this issue, the VLC team had already made changes to
the 2.2 development branch here, here, and here that corrects this
issue by reinitilizing the filters when a format change is detected. However,
the fixes had not yet been backported to the 2.1 maintenance branch.

Once notified, the VLC team quickly resolved the issue by backporting the
relevant patches to the maintenance branch here, here, and
here. They also added an additional check on both the
development and maintenance branches for good measure.