HITB 2011 Amsterdam Round Two Quals Binary

The provided binary is a ELF file designed to be run by inetd and accepts several character based commands followed by their parameters. The main loop reads a character from STDIN (in inetd a socket is duplicated into standard I/O descriptors) and based on the value picks a handler from an array of function pointers. The following commands exist:

• 'f' - return meta data for a given file name
• 'l' - list filenames from the home directory
• 'q' - terminate the process
• 's' - return symbolic link's path name
• 'v' - verify input with a key file's data

After mapping out all the available handlers and reviewing how they work there were no obvious vulnerabilities (e.g. buffer overflow). The handler functions that expect additional input first allocate some heap-based memory to store this input and care is taken to make sure it's not overflowed. After the handler completes its work the memory is freed. However, there's a design flaw in the way allocated memory is used when the key text is verified. Specifically, the key data is read into a allocated buffer and compared to the string supplied by a user. Once this is done the memory is simply freed, which returns the memory block to the free pool still containing the key data.

As a result, we can use another handler, which allocates memory for its operation and returns the results to the user. One such command is the 's' character, which accepts a symbolic link as a parameter. Additionally, after listing the contents of the home directory using the 'l' command we find few symbolic links that can be used for the 's' command. Thus, when requesting to view a symbolic link the real path will be copied to a allocated buffer. Since the buffer will come from the free pool and the contents were not cleared then whatever data was there will also be displayed. If the resulting path is shorter in length than the data size of the "KeyFile" we can disclose part of the secret key string.

Looking at the handler for the 'v' command it was identified that a string comparison is performed only on the last 14 bytes of the key file. This tells us how much of the disclosed key file's data we need to grab. Thus, to reproduce we need to submit the 'v' command with any key, which stores the key data into a buffer, but does not clear it after the comparison. Then, submit the 's' command to display the path of the "t1" link, which is short enough to disclose more than 14 bytes of the key file. Finally, take the last 14 bytes and submit them via the 'v' command again and this time the comparison succeeds and gives us the solution key.

The solution string is (w/o quotes): "DwightIzK00l"

Codegate 2011 Quals - Binary 300

The question is:

Find a malicious ID!!

The binary is a Browser Helper Object (BHO) DLL with a static XOR key "securecodegate", which is used to decrypt few arrays with statically assigned characters to each index. The "sub_1000233E" function is called with the array and a XOR key as input to perform the decryption. This occurs three times within a handler function "sub_1000270A".

The first two calls are irrelevant as they result in decryption of "google_ads_frame" (key "secure") and "client" (key "code"). However, the third call produces the answer string using the "gate" key.

This was identified by looking for various interesting strings in the binary and locating their use references. The XOR decryption routine is fairly simple and can be performed via a IDC script.

We used a lazy/simple option. Register the DLL ("regsvr32 b300.dll"). Launch Internet Explorer, attach a debugger, locate the handler function ("sub_1000270A"). Modify EIP to jump to the buffer initialization sequence, which is right before the decryption function call (e.g. @ 0x10002C96 for the "gate" key).

The answer is:

ca-pub-0123456789012345

Codegate 2011 Quals - Binary 200

The question is:

Reverse Me!!

The binary is a console based PE file. Running the file produces no output due to a certain routine terminating the process before the "main()" function starts. Looking around the code the "sub_401130" function stands out due to initialization of a local array with various bytes. At the end of this function a decryption routine is called ("sub_401070") with the array as input. The decryption loop performs an XOR operation using the string's length as the key.

To obtain the answer a breakpoint was placed @ 0x00401494, which calls the "ExitProcess()" library function prior to "main()". Next, modify EIP to point to the start of the array initialization routine and execute until the decryption function is called. Let it do its XOR job and look at a local buffer once complete to get the answer string.

The answer is:

http://forensic-proof.com/archives/552

Codegate 2011 Quals - Forensics 300

The question is:

we are investigating the military secret's leaking. we found traffic with leaking secrets while monitoring the network. Security team was sent to investigate, immediately. But, there was no one present. It was found by forensics team that all the leaked secrets were completely deleted by wiping tool. And the team has found a leaked trace using potable device. Before long, the suspect was detained. But he denies allegations.

Now, the investigation is focused on potable device. The given files are acquired registry files from system. The estimated time of the incident is Mon, 21 February 2011 15:24:28(KST). Find a trace of portable device used for the incident.

The Key : "Vendor name" + "volume name" + "serial number" (please write in capitals)

Enumerate a timeline of USB activity from the backup system hive

...
Disk&Ven_Corsair&Prod_UFD&Rev_0.00,Thu Feb 17 04:41:02 2011,ddf08fb7a86075&0,Thu Feb 17 04:41:03 2011,Corsair UFD USB Device,
Disk&Ven_FM&Prod_Memorette_Swing&Rev_1.00,Thu Feb 17 06:38:21 2011,2008090256000000000000BE&0,Thu Feb 17 06:38:22 2011,FM Memorette Swing USB Device,
...

The enumeration shows all of the USB devices ever connected to the system. The registry last modified times are written the first time the device is connected, but are not updated when a device is subsequently connected.

Running a timeline on the registry (via "regripper"), we see that only one USB device is connected on Feb 21:

Mon Feb 21 06:24:21 2011Z HKLM\ControlSet001\Enum\WpdBusEnumRoot\UMB\2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_CORSAIR&PROD_UFD&REV_0.00#DDF08FB7A86075&0#\Properties\{80d81ea6-7473-4b0c-8216-efc11a2c4c8b}

From there, we know that the suspect device vendor is "CORSAIR" and the serial number of the device is "DDF08FB7A86075". Inspection of this registry path reveals that the default name of the device has been changed. The registry key "FriendlyName" has a value of "PR0N33R", which is the displayed volume name when the device is connected.

The answer is:

CORSAIRPR0N33RDDF08FB7A86075

Thanks to our team member tina for the solution.

Codegate 2011 Quals - Network 100

The question is:

This data is related to any attack.
calculate the md5sum of the intended file.

(calc md5 uppercase)

The provided binary is a PCAP file containing bunch of HTTP traffic and some SMB chatter. The question mentions an attack. Since it's heavy on HTTP usage then it made sense to get a list of all requests. Two strange requests stand out:

GET /H1A1.html HTTP/1.1
GET /H1A1.exe HTTP/1.1

Carving out (using Wireshark's "Follow TCP Stream" -> "Save As") the "H1A1.exe" response and removing the HTTP response header we end up with a regular PE file. Next, calculate its MD5 checksum and convert to upper case.

The answer is:

7A5807A5144369965223903CB643C60E