{"id":19505,"date":"2016-09-22T17:55:58","date_gmt":"2016-09-23T00:55:58","guid":{"rendered":"https:\/\/www.paloaltonetworks.com\/blog\/?p=19505"},"modified":"2016-09-29T09:46:27","modified_gmt":"2016-09-29T16:46:27","slug":"unit-42-labyrenth-capture-the-flag-ctf-windows-track-7-9-solutions","status":"publish","type":"post","link":"https:\/\/www2.paloaltonetworks.com\/blog\/2016\/09\/unit-42-labyrenth-capture-the-flag-ctf-windows-track-7-9-solutions\/","title":{"rendered":"LabyREnth Capture the Flag (CTF): Windows Track 7-9 Solutions"},"content":{"rendered":"

Welcome back to our blog series where we reveal the\u00a0solutions\u00a0to\u00a0LabyREnth, the Unit 42 Capture the Flag (CTF)<\/a>\u00a0challenge. We\u2019ll be revealing the\u00a0solutions<\/a>\u00a0to one challenge track per week. Next up, the Windows track challenges 7 through 9.\u00a0<\/p>\n

Windows 7 Challenge: Some guy found this pcap and executable. Ready, set, go!<\/h3>\n

Challenge Created By: Josh Grunzweig @jgrunzweig<\/a><\/em><\/p>\n

For this challenge, users were given both a PCAP and a Windows executable file. Taking a quick look at the PCAP file, we see there are a number of individual connections from 172.16.95.1 to 172.16.95.190, each about the same size.<\/p>\n

\"windows_2_1\"<\/span><\/div><\/a><\/p>\n

Figure 1 Connections in G0blinKing pcap file<\/em><\/p>\n

Looking at a specific connection, we see that each one is transferring a single byte of data at a time.<\/p>\n

\"windows_2_2\"<\/span><\/div><\/a><\/p>\n

Figure 2 Data in stream 0 for G0blinKing pcap file<\/em><\/p>\n

Presumably, we can come to the conclusion that some data is being sent from one host to another, one byte at a time. To determine what data has been generated, we need to look at the Windows executable file.<\/p>\n

Opening the file, we see a minor Easter egg, where the pdb string was overwritten.<\/p>\n

\"windows_2_3\"<\/span><\/div><\/a><\/p>\n

Figure 3 Overwritten pdb path<\/em><\/p>\n

Unfortunately for this file, it doesn\u2019t disassemble terribly well, and we see a number of functions that simply jump to the actual function containing the relevant code. This is just a byproduct of how the file was compiled. Looking through the code, however, we can see that the actual core functionality of the code starts at a function at offset 0x412300.<\/p>\n

Performing a quick triage of the sample and the functions that are called, we can get a high-level overview of what is going on. Note that I\u2019ve renamed a few of the functions in the figure below based on guesses as to what the functions may be doing.<\/p>\n

\"windows_2_4\"<\/span><\/div><\/a><\/p>\n

Figure 4 Main function of executable<\/em><\/p>\n

So, we can safely conclude that some form of encryption is being performed against the data contained in file.txt, it\u2019s then being encoded, and then sent across the network, where the PCAP was generated from. At this point we simply need to identify what is happening during encryption and encoding respectively.<\/p>\n

For encryption, we track down a function that looks to be primarily responsible. We also identify a string aptly named \u2018AWildKeyAppears!\u2019, which is most likely going to be the key used for encryption. Looking at the beginning of this function, we identify a number of constants as seen in the following figure.<\/p>\n

\"windows_2_5\"<\/span><\/div><\/a><\/p>\n

Figure 5 Encryption function<\/em><\/p>\n

A number of these constants turn out to be red herrings. However, if we look at the constant of 0x9E3769B9, we see that this constant is used in the TEA\/XTEA encryption algorithms. Further review of this function shows us that we\u2019re simply dealing with XTEA, with a few red herrings thrown in. The following original source code shows what it looked like prior to compilation.<\/p>\n

unsigned int key[4] = {0x6c695741, 0x79654b64, 0x65707041, \r\n0x21737261};\r\n\r\n#define BLOCK_SIZE 8\r\n\r\nvoid xtea_encipher(unsigned int num_rounds, uint32_t v[2], \r\nuint32_t const key[4]) {\r\n    unsigned int i;\r\n    uint32_t j, o, s, h;\r\n    j = 0xBADA55;\r\n    uint32_t delta = 0x9e3769b9;\r\n    o = 0x4913092;\r\n    s = 0x12345678;\r\n    h = 0xDEADBEEF;\r\n    uint32_t v0=v[0], v1=v[1], sum=0;\r\n    for (i=0; i < num_rounds; i++) {\r\n        v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & \r\n3]);\r\n        j += 4092;\r\n        o -+ 4092;\r\n        for (int x = 8; x < 32; x++) {\r\n          s = s*8;\r\n          j -= 64;\r\n          o -= 8;\r\n        }\r\n        h = 64;\r\n        sum += (delta + 4096);\r\n        v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + \r\nkey[(sum>>11) & 3]);\r\n    }\r\n    v[0]=v0; \r\n    v[1]=v1;\r\n}\r\n<\/pre>\n
Now we can move onto the encoding function. At a quick glance, it looks to be base64. However, if we look at the alphabet, it does not look to be standard. The following is the traditional base64 alphabet.<\/p>\n
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+\/<\/p>\n
This is the alphabet discovered within the Windows executable.<\/p>\n
qtgJYKa8y5L4flzMQ\/BsGpSkHIjhVrm3NCAi9cbeXvuwDx+R6dO7ZPEno21T0UFW<\/p>\n
Knowing this, we can now create a script that will both parse the PCAP file and decrypt the contents sent across the wire. The following script was created to accomplish this.<\/p>\n
import string\r\nimport dpkt\r\nimport sys\r\nimport base64\r\nimport struct\r\n\r\n\r\ndef xtea_decrypt(key,block, n=32, endian=\"!\"):\r\n  v0,v1 = struct.unpack(endian+\"2L\",block)\r\n  k = struct.unpack(endian+\"4L\",key)\r\n  delta,mask = 0x9e3779b9L,0xffffffffL\r\n  sum = (delta * n) & mask\r\n  for round in range(n):\r\n    v1 = (v1 - (((v0<<4 ^ v0>>5) + v0) ^ (sum + k[sum>>11 & \r\n3]))) & mask\r\n    sum = (sum - delta) & mask\r\n    v0 = (v0 - (((v1<<4 ^ v1>>5) + v1) ^ (sum + k[sum & 3]))) & \r\nmask\r\n  return struct.pack(endian+\"2L\",v0,v1)\r\n\r\nall_data = \"\"\r\n\r\ndef parse_pcap_file(filename):\r\n  global all_data\r\n  f = open(filename)\r\n  pcap = dpkt.pcap.Reader(f)\r\n  for ts, buf in pcap:\r\n    eth = dpkt.ethernet.Ethernet(buf)\r\n    ip = eth.data\r\n    tcp = ip.data\r\n    if tcp.dport == 8080 and len(tcp.data) > 0:\r\n      all_data += tcp.data\r\n\r\nif __name__ == '__main__':\r\n  if len(sys.argv) <= 1:\r\n    print \"%s [pcap file]\" % __file__\r\n    sys.exit(2)\r\n  parse_pcap_file(sys.argv[1])\r\n\r\nnew_b64_chars  = \r\n\"qtgJYKa8y5L4flzMQ\/BsGpSkHIjhVrm3NCAi9cbeXvuwDx+R6dO7ZPEno21T0UF\r\nW\"\r\nold_b64_chars = \"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+\r\n\/\"\r\n\r\nall_data = all_data.translate(string.maketrans(new_b64_chars, \r\nold_b64_chars))\r\ndata = base64.b64decode(all_data)\r\n\r\nresult = \"\"\r\nkey = 'AWildKeyAppears!'\r\nfor x in range(0, len(data)\/8):\r\n  o = xtea_decrypt(key, data[8*x:8*x+8], endian=\"<\")\r\n  result += o\r\nprint result\r\n<\/pre>\n
Running this script against the provided PCAP file, we\u2019re presented with the following output.<\/p>\n
PADDINGPADDINGPADDINGPADDINGPADDINGPADDINGPADDINGPADDINGP\r\nPAN{did_1_mention_th0se_pupp3ts_fr34ked_m3_out_recent1y?}\r\nPADDINGPADDINGPADDINGhibobPADDINGPADDINGPADDINGPAD\r\n<\/pre>\n
PAN{did_1_mention_th0se_pupp3ts_fr34ked_m3_out_recent1y?}<\/p>\n
Windows 8 Challenge: Prepare for windows kernel debugging! (smile)<\/h3>\n
Challenge Created By: Esmid Idrizovic @xedi25<\/a><\/em><\/p>\n
Initial analysis<\/h4>\n
When we open the file revloader.exe in a PE viewer we see that it\u2019s a PE64 file. The file contains three unencrypted resources in the RCData directory.\u00a0 We extract all three resource files to look at what\u2019s in these files.<\/p>\n
\"windows_2_6\"<\/span><\/div><\/a><\/p>\n
Resources of revloader.exe<\/h4>\n
Resource 101<\/strong><\/p>\n
This file is also a PE64 and contains some version information strings, which tells us that it\u2019s DSEFix. DSEFix is a tool that can bypass the driver signature enforcement in Windows by using an exploit in a signed VirtualBox driver. By using DSEFix, you can disable DSE and load any driver you want. So it looks like we\u2019ll solve this challenge by using an unsigned windows driver.<\/p>\n
\"windows_2_7\"<\/span><\/div><\/a><\/p>\n
Resource 102<\/strong><\/p>\n
This is the driver itself. It\u2019s also a PE64 and uses FLTMGR.SYS. In version information, we can see that it\u2019s a windows driver with the internal name revhunt.sys. We can also see that the file is not signed, so it makes sense that revloader.exe is going to use DSEFix to load the revhunt.sys.<\/p>\n
Resource 103<\/strong><\/p>\n
This is an INF file for the driver. We can see that it\u2019s a mini file filter driver and that it uses the altitude 31337.<\/p>\n
Revloader<\/h4>\n
Let\u2019s start with revloader.exe to verify that it\u2019s going to drop DSEFix driver and run DSEFix to disable windows driver signature enforcement. We can take a look at the import table to find important functions that might be used for this kind of work.<\/p>\n
\"windows_2_8\"<\/span><\/div><\/a><\/p>\n