Vault - IJCTF 2021 Writeup

A robber broke into our vault in the middle of night. There's an indication that the robber tried to steal some items which are considered as confidential assets. Could you figure it out?

Flag format: IJCTF{[a-f0-9]{32}}

Author: Avilia#1337

Hint #1: "When the incident happened, the attacker got into our IP over ICMP tunnel network to access an HTTP/2 web-server with SSL enabled."

Hint #2: "Even so, our captured logs aren't precise enough. Each packet has an unusual timestamp and it's kinda messy..."

We are provided with a log.tar.xz archive from the challenge description, which we can decompress using xz and tar as so:

$ xz -d log.tar.xz

$ tar -xvf log.tar

This should produce a log.pcap file.

Running strings against the .pcap file, we pipe the output to sort and uniq to only display unique entries, then grep ...... to display only lines with length greater or equal to 6:

$ strings log.pcap | sort | uniq | grep ......

We see mentions of files flag.zip, pass.txt, download.py, and sslkeylogfile, as well as commands such as id, python3 and xargs being run.

Opening the packet capture file log.pcap in Wireshark, we see a conversation between 192.168.1.30 and 192.168.1.205 through ICMP (ping), along with some fragmented IPv4 packets.

Looking at Wireshark, we notice some of the packets have negative time values. This should not be possible, packets cannot travel back in time before the capture started. Also, the frame numbers are all over the place and are not ordered correctly.

We can fix the packet ordering issue using the reordercap tool, which should come installed with Wireshark:

$ reordercap log.pcap log_ordered.pcap

If the reordering was successful, there should be 167 fragmented IPv4 packets with size of 1514 bytes in the newly created log_ordered.pcap file. With the ordering fixed, we can then start analysing the individual packets.

Looking at one of the fragmented IPv4 packets, we see that there is a data segment with 1480 bytes of data:

At first, the data may look like random bytes. But, if we look carefully, we can see there is a malformed Ethernet header, followed by an IP header, and then a TCP header:

Searching for the bytes in the malformed Ethernet header 00 00 4a e3 f9 24 34 44 68 61 6e 73 07, we were able to determine the specific application used to establish the ICMP tunnel, called "Hans" (https://github.com/friedrich/hans). This header is inserted by the Hans application. We can also see the 0x07 byte at the end, which is defined as TYPE_DATA in the source code under src/worker.h:

We know the TCP data inside of the ICMP data has to contain the TLS traffic which the attacker used to exfiltrate data, or the handshakes associated with them. If we can somehow restore the original TLS packets, then there is a possibility where we can extract the session keys and use them to decrypt the rest of the packets.

This can be achieved by transplanting the Ethernet header from the ICMP packet to the ICMP data segment, and removing the magic/type header inserted by Hans. In fact, we can simplify it to only one cut operation by removing the TCP header and the Hans header altogether.

Using the editcap tool and following the documentation here, we cut away 33 bytes (20 bytes from TCP header of ICMP + 13 bytes from Hans) starting from offset byte 15 (after 14 bytes from Ethernet header of ICMP) for each packet, then export the packets into a log_chopped.pcap file:

$ editcap -C 15:33 log_ordered.pcap log_chopped.pcap

Opening log_chopped.pcap file in Wireshark, we see the ICMP packets have now changed into either TCP or Socks packets, the source/destination address and ports have also changed. This is likely because the attacker used a Socks proxy when attacking our victim. To combat this and allow Wireshark to read the traffic properly as TLS, we can add an entry to the "Decode As" list under the "Analyze" tab, pointing port 1080 to TLS:

This basically tells Wireshark to treat all traffic on TCP port 1080 as TLS, and not as Socks.

Earlier, when we did strings on the log.pcap file, we noticed that the attacker ran xargs -n1 -a sslkeylogfile on the victim's system, which would effectively print the contents of sslkeylogfile to the output stream. We should be able to follow this output as it is not protected by TLS, and recover the TLS session keys.

From the Mozilla NSS key log documentations, we know the sslkeylogfile follows a format of <Label> <space> <ClientRandom> <space> <Secret>. ClientRandom is encoded as 64 hexadecimal characters, and Secret is encoded as 96 hexadecimal characters (for TLS 1.0-2). For example, a key may look like this:

In log_chopped.pcap, we use Wireshark's search feature to look for the string CLIENT_RANDOM in the packet bytes. Select any packet from the search result and follow the TCP stream by right-clicking on it then clicking Follow -> TCP Stream. This should open a new window showing the entire stream as ASCII:

From here, it is trivial to extract the contents of sslkeylogfile. We can simply copy all lines containing the session keys starting from CLIENT_RANDOM and paste them into a file named sslkeylogfile.txt.

Though, we're not done quite yet. Since the attacker used xargs -n1 to display each argument into separate lines, the format of our keys is going to be incorrect. We need to replace the line characters \n between ClientRandom and Secret into space characters, and this can be done using paste as so:

$ paste -d" " - - - < sslkeylogfile.txt > sslkeylogfile

The sslkeylogfile should now contain 166 keys, as seen here:

$ wc sslkeylogfile && md5sum sslkeylogfile

With the session keys extracted, we can then decrypt the packets.

There are two ways we can approach the decryption:

Either methods will allow us to read the contents of the packets, but the editcap approach will allow us to use command-line tools later to recover the files more easily. If you want to hand transcribe hexadecimals later on, then choose method 1. ;)

Looking at the HTTP/2 packets in log_decrypted.pcap with filter http2, we see there are GET requests to /files/flag.zip and /files/pass.txt:

Alongside the HEADERS and Magic packets, we also see many DATA packets. Inspecting them further with Wireshark, we see that each of the DATA packet has a status of 206 Partial Content, they each carry either 1 or 2 bytes of data depending on if the Content-Type header is text/plain or application/zip, and nearly all of them have an unusual header Content-Range.

In essence, what's happening here - is that the attacker is gradually sending either 1 or 2 bytes of data through HTTP/2. The bytes are ordered by the Content-Range header. For example, bytes 22-23/202 would mean the data in the packet belongs in byte locations 22 to 23, out of 202 bytes. This implies, in order for us to recover the two files, we need to piece together the individual bytes of data from all of the DATA packets according to the Content-Range header.

It is possible to recover the files by hand transcribing the hexadecimals from all 166 packets (if you're up for the task). Fortunately, there is a tool that can help us with this. We can use tshark, which is a packet analysis tool much like Wireshark, but it is capable of quickly exporting the packets' range and data as columns in the command-line, allowing us to easily recover the bytes.

$ tshark -r log_decrypted.pcap -Y "http2" -T fields -e http2.headers.range -e http2.data.data | xargs -n2 > bytes.txt

Here, we first take log_decrypted.pcap as the input file (-r), using http2 as the display filter (-Y), and printing the fields (-T) of http2.headers.range and http2.data.data (-e). We also pipe the output to xargs -n2 to make each packet display neatly on one line instead of two, and finally output it to a bytes.txt file. The file should look something like this:

We have the hexadecimal bytes of flag.zip and pass.txt, but the bytes are mixed together in one file and we want to separate them. To do this, we can pass it through a few more filters:

$ cat bytes.txt | awk 'length($2)==2 {print $0}' | cut -d"=" -f2 | sort -n

This reads the contents of bytes.txt, and prints the line if the byte column has a length of 2. Then removes the "bytes=" string before the range, and sorts the values numerically. The result should be the hexadecimal bytes of pass.txt in order of the range, and will look something like this:

We can verify that no bytes are missing from the output, and that all bytes are in the correct order.

Now, we just have to remove the range column and we will get the password's hex:

$ cat bytes.txt | awk 'length($2)==2 {print $0}' | cut -d"=" -f2 | sort -n | cut -d" " -f2 > pass.hex

To convert it from hexadecimal to bytes, we can use xxd:

$ xxd -r -p pass.hex > pass.txt

Now repeat the process for flag.zip, but this time using length($2)==4 instead. We can also skip the intermediate hex file as so:

$ cat bytes.txt | awk 'length($2)==4 {print $0}' | cut -d"=" -f2 | sort -n | cut -d" " -f2 | xxd -r -p > flag.zip

Now all that's left to do is decompress flag.zip using pass.txt and get the flag!

$ unzip flag.zip

$ cat flag.txt