CSE Puzzle Challenge - Puzzle 18 - Solution

Wick ID Challenge Solution

1. Something Looks Fishy

As we begin this challenge, we are faced with an incredibly large PCAP file stuffed full of traffic: everything from connections to http://eafddirect.msedge.net/ and rickrolled.com, to Facebook and even an Ubuntu update. All of  these packets obscure the message that Moss was trying to get to Richmond. It’s not until around packet No. 118 that we begin to notice some unusual behaviour. At that point, IP address 10.0.2.15 seems to start sending an unusual number of time synchronization requests to the NTP server at 10.0.2.7. Furthermore, the requesting behaviour is not consistent; 10.0.2.15 is sending request packets everywhere from 1 - 6 seconds apart, with sizes that vary from 366 to 614 bytes in length.

2. A Little NTP Background

The Network Time Protocol (NTP) is used to synchronize system times across a network, from a time server to multiple systems. These time servers may be localized to an internal network or accessed publicly via a pool. For example, pool.ntp.org is a large cluster of virtual NTP time servers and is used as the default “time server” for most major Linux distributions Footnote 1. There are many fine-tuned aspects to the NTP protocol, all of which can be read about in RFC 5907 and RFC 7822.

2.1 NTP Modes and Packet Structure

NTP Packet Header Format Footnote 2

Extension Field Layout of NTP Packet Footnote 3

 

There are three main parts to note for this challenge: VN, Mode from the NTP packet header and all elements in the Extension Field.

  1. VN (Version Number bytes 2-4): This is the version of the NTP protocol being used. This is important to note as only NTPv4 includes an extension field.
  2. Mode (bytes 5-7): This value can help us understand who is sending the packet (client == 3/server == 4).
  3. Field Type: The values input here are separately defined in an IANA registry. Full knowledge of the registry is not required for this challenge, but it’s best to understand the relationship to the rest of the extension field.
  4. Length: This value indicates the length of the full extension section. Traditionally, the extension field length has a minimum value of 16 octets: 2 bytes for field type, 2 bytes for length, and a remaining minimum value length of 4 bytes. Maximum length is not explicitly defined, though it is limited by the maximum value that can be achieved in a 16-bit unsigned integer. It is important to note that this value can be interpreted differently depending on the Field Type.
  5. Value: This is the extension data section. Its size can be interpreted as follows:
  6. Padding: The extension data section must be zero-padded to four octets.
  7. MAC: The Message Authentication Code consists of the following:
    • Key ID: 32-bit unsigned integer used by the client and server to designate a secret 128-bit MD5 key Footnote 2.
    • Digest: 128-bit MD5 hash computed over the key followed by the NTP packet header and extensions fields (but not the Key Identifier or Message Digest fields) Footnote 2

It is also important to remember that the extension field is optional and only exists in the NTPv4 protocol. Furthermore, the MAC is also optional. That said, when the extension field does exist, it is usually accompanied by a MAC, and when an extension field does not exist, a KeyID of 0x00000000 is typically used with no digest.

3. Isolating the Covert Message

There are multiple ways to go about isolating the covert message to Richmond in the PCAP, but we will only address the two simplest here.

1. Filtering the packets: We can filter the entire PCAP file down to just the packets sent to the NTP server. To do this, we first need to identify the protocol and the source IP. We know we want to look at NTP packets and that the ones we most want to look at seem to be coming from 10.0.2.15. Thus, the filter can be implemented by typing the following expression into the Wireshark filter bar just below the menu:

Figure 1: Filtre WireShark

2. Following a stream: Another way to isolate the back and forth between the time server and the suspicious IP is to right-click on one of the suspicious packets and select Follow–>UDP Stream from the context menu. This extracts both the request and the response from the isolated packets but has the added bonus of opening the stream in a separate window that shows only the NTP data from every packet in sequential order. The different sources are highlighted in red and blue (see Figure 2). At this point, it is simple to set the Show and save data as element to Raw and save the extracted stream as a “.bin” file.

 

Figure 2: Raw Wireshark Stream

Note: Typically, clients subscribe to timeserver pools, meaning they could be reaching out to any number of different timeserver IP addresses. Following the stream in this case  would not let you see all client NTP packets, only those in the specific stream. In the case of this challenge, the Wick ID Corp. seems to be using its own local time server, so we can safely use this method.

4. Extracting The Covert Message

The steps to further extract of the covert message will depend on the method used to extract the suspicious packets. The “following a stream” method only requires us to have knowledge of the NTP packet structure and protocol. The “Filtering” method also requires knowledge of the PCAPNG file structure and packet encapsulation. Consequently, his walk through will cover the former method.

Now that the NTP packets between addresses 10.0.2.15 and 10.0.2.7 are isolated in the “bin” file, we can open this file in a hex-editor (my hex-editor of choice  is  010Editor as  we  can  create  a  template  and  script  the  extraction  all in one place). With our new knowledge of the NTP packet structure, we can identify the NTP packet structure in the stream as shown in Figure 3.

Figure 3:  NTP Packet Layout

This layout can be reflected in a 010Editor template file using the structures defined in Listing 1.

Listing 1:  NTPv4 Packet Structures

4.0.1 Creating the template

There are a few things to keep in mind here:

  1. NTP extension blocks were only introduced in version 4 of the protocol. Thus, if a previous NTP version is used, we’ll need to limit our structure so that no attempt to collect an extension block is made.
  2. All of Moss’ NTP packets appear to have the field typ value of 0x0100. This value is undefined in the specs. As such, we use a known value field len to determine the length of the data in the extension field.
  3. The MAC as defined by RFC 5905 contains a KeyId and a Digest, and is optional. However, when evaluating the NTP packets, the following pattern proved true.
    • When the NTP version is 4 and the extension does not exist, the digest does not exist and the key ID is 0x00000000.

After defining our desired structures, the template can be applied simply by defining instances of the structures as follows:

In 010Editor, this will actually create an array of NTP PACKET structures corresponding to the full length of the file.

4.0.2 Extracting and examining the data

If we simply want to extract the extension data from Moss’ NTP packets, we can do so as follows with an 010Editor Script:

However, there is a problem here. If the data from each extension field is padded to a 4-byte length and we just put all the extension fields together, we may be adding extra bytes to Moss’ evidence. Depending on the format of Moss’ evidence these extra bytes may greatly affect our ability to reconstruct the evidence. Moss must have anticipated this...

If we take a closer look at the extension section of any packet that has plain text data, a 2-byte non-ASCII value can be found before any text starts (see Figure 4).

 

Figure 4: Unknown Added Parameter

This 2-byte value, identified by “New Value” in Figure 4, is not the same in every NTP packet sent from 10.0.2.15 (Moss). It does however seem to correspond to the number of ASCII characters that follow it. In an attempt to mask his message, Moss seems to have randomized the length of his extension fields and padded them. This added 2-byte “data length” breadcrumb Moss has left behind tells us exactly how much data to extract from each NTP extension field. We need to add this value to our 010Editor template and use it to extract the data. Thus, the new NTP EXT BLK structure should be rewritten as follows:

We can adjust the extraction script to only extract the data and not the padding by using this new value as our length variable in the SetSelection function as follows:

Note: See Appendix for full template file and extraction script.

 

Looking at the output of this script, we can see that the first 0xD1 bytes are a plain text message from Moss, followed by 0x117BE bytes of high entropy data, ending with a 0x30 byte final message from Moss in plain text. These messages from Moss are shown in Figure 5.

Figure 5: Messages from Moss

Richmond!

Richmond!!

I hope you find this in time!

Wick ID Corp. They're not what you think! They're not HUMAN!!

It's to late for me, but you can still escape!

Take this evidence, the password is RubberDuckies123

.

.

.

GET OUT RICHMOND!! GET OUT WHILE YOU STILL CAN!!!

From Moss’ messages, we know that the evidence is password encrypted in some way. Based on the magic bytes 0x504B - ‘PK’ from the high entropy data, we are looking at a password encrypted ‘.zip’ file. In fact, if we look 31 bytes into the file, we can see that this zip file contains an image file called IMG-31337.jpg. If we remove the plain text messages highlighted in Figure 5, we can then save the remaining bytes as a “.zip” file and extract it normally using the password Moss gave us (RubberDuckies123).

Figure 6: Moss’ Evidence

Congratulations!! You retrieved Moss’ evidence, now get out of there quick!!

 

5. Appendix

5.0.1 010Editor Template - NTP WickID.bt

5.0.2 010Editor Script - Extract NTP Extensions.1sc

References

Notes de bas de page

1

NTP Pool Project. pool.ntp.org. https://www.ntppool.org/en/. Accessed: 2019-06-09.

Return to first Footnote 1 referrer

2

D. Mills, J. Martin, J. Burbank, and W. Kasch. Network time protocol version 4: Protocol and algorithms specification. RFC 5905, RFC Editor, June 2010. http://www.rfc-editor.org/rfc/rfc5905.txt.

Return to first Footnote 2 referrer

3

T. Mizrahi and D. Mayer. Network time protocol version 4 (ntpv4) extension fields. RFC 7822, RFC Editor, March 2016.

Return to first Footnote 3 referrer

 

Enjoy solving puzzles? Make a career out of it!