Welcome back to the continuation of the NCL Preseason Posts! Today we will be covering Part 2 of the Network Traffic Analysis portion of the NCL Preseason game - this is also the final content that was presented during this CTF. If you don’t know what the NCL is, or what these posts are about, then I suggest you go back and read my Introduction Post which can be found here!

Also, if you missed my previous write-ups for the preseason, you can find the Cryptography portion here and the Log Analysis portion here!

So without any further ado - let’s get to it!

Telnet:

For this challenge we are provided the following file: NCL-2016-Pre-Telnet.pcap

1. What is the username that was used to successfully log in?

First thing we need to do when we open up the pcap is to follow the TPC Stream. Once we do that, we are shown the Telnet stream. Keep in mind that Telnet will echo back each key (except for password) so try not to get confused.

To get our answer just look for “login”.

Answer: test

2. What is the password that was used to successfully log in?

Since we already know that the password is not echoed back in telnet, just look for “password” and we will have our answer.

Answer: capture

3. What command was executed once the user was authenticated?

Looking at line 6, we can see that “$” is displayed - meaning that this is a command line entry, thus the user has authenticated successfully. This would be the first command execution.

Answer: uname

4. In what year was this capture created?

Just look at line 8, and look for what “date” uname returned.

Answer: 2011

5. What is the hostname of the machine that was logged in to?

Knowing how uname prints out the system information will help us decipher which one is the hostname. Uname displays the hostname as the second object.

Answer: cm4116

6. What CPU architecture does the remote machine use?

Just as above, uname returns the machines hardware identifier second to last.

Answer: armv4tl

Pandora’s Box:

For this challenge we are provided the following file: NCL-2016-Pre-Pandora.pcap

And we are also provided these instructions for how the protocol works.

1. What is the IP address of the server?

This challenge was very tricky and required some in depth knowledge of how TCP/IP functions. Looking at the Custom Protocol instructions we can see that the first communication is between the Client > Server.

The Client initializes the communication by sending the total number of encryption requests that it wishes to make. If you know TPC/IP then you would understand that the Client will send out a TPC packet with the PSH Flag, as well as the ACK Flag since the server would be acknowledging the receiving data. You can read more about it here.

So first thing we must do is set a filter in Wireshark to filter out only PSH and ACK. To do that we enter “tcp.flags.push == 1 && tcp.flags.ack == 1” in the filter. When we have that set, scroll down till we find the first [PSH, ACK] packet. From here, we are able to tell is the Client IP Address is (source) and what the Server IP Address is (destination).

Answer: 10.1.0.20

2. What is the IP address of the Client?

As explained above, the Destination IP will be the IP Address of the Server.

Answer: 10.1.0.217

3. What port is the server listening on?

Looking at the first [PSH, ACK] packet in the Pandora Communication we can see what port the server is listening to by looking at the Transmission Control Protocol line in the packet, and finding the Dst Port.

Answer: 42455

4. What is the magic 2-byte ID in decimal?

Since we already know that the client first sends the number of encryptions it wants to do in its initialization message - we can see in the instructions that the next thing the client sends is the “check” or a “fixed 2-bytes integer”. So let’s simply follow the packets TPC Stream to see the information it’s sending. After you do, change the “Show data as:” to RAW. The second line will be the 2-bytes “magic” ID.

Answer: 0417

5. How many encrypt requests were made by the client?

Just like above, the first line in the TCP stream will provide us this data.

This data though is in hexadecimal, so we can easily convert it to decimal in our CLI.

root@kali:~# echo $((14#00000005))
5

Answer: 5

6. What is the length (in bytes) of the first encrypt request?

Looking back at the instructions provided to us. We see that during the Encrypt Request, the second thing the Client sends the server is a “4-byte integer” that represents the length of the data, followed by the data to be encrypted.

So a 4-byte integer would be 00 00 00 00, looking closely at line 4 (where the client is sending it’s data to be encrypted) we see 00000058, which will be the 4-byte size integer.

Once again, the data is in hexadecimal format, so we will convert it to decimal format to get the size.

root@kali:~# echo $((16#00000058))
88

Answer: 88

7. What is the length (in bytes) of the second encrypt request?

Same as above, just look for the second 4-byte integer that will represent the second portion of the request. We will see that the 2nd request’s 4-byte integer is 00000048.

As before, we convert hexadecimal to decimal to get our answer.

root@kali:~# echo $((16#00000048))
72

Answer: 72

8. How large is an individual encrypt hash in bytes?

Looking back at the instruction, we see that after the Client sends all its data, the server responds with a single encrypted response, containing hashes for each request. Simply just click on line 12 in the stream (the blue one - as this is server response) and just look what the data length is in the packet. This will be our “fixed” hash length.

Answer: 32

9. What was the encrypt response (in the form of 0xFFFF) for the first request?

Since we know that the hashes are all 32 bytes long, just grab the first hash (which is already 32 bytes) on line 12, and that will be the answer.

Answer: b8c97b08e198fa9ff79a3a9c1f0109b18687b7a1a3ff1772c29b4dc86753d711

10. What was the encrypt response (in the form of 0xFFFF) for the second request?

This is simple… since line 12 gives us a 32 byte long hash, just match up the length of the first hash to the hash on the next line.

Answer: 8817153ae81d94b5d6c745e63d1df31d5d02bd3b030b820c3c038654fdca619c

11. What is the hidden flag being sent with the protocol?

Since the only thing being sent with the protocol is the “data” (in red), let’s go ahead and grab that.

Once we have that copied, we can convert the data from hexadecimal to ASCII (as it’s in plaintext). That will provide us with the following:

XTkNMLUZKQ0ctMTYzMiBOQ0wtRkpDRy0xNjMyIE5DTC1GSkNHLTE2MzIgTkNMLUZKQ0ctMTYzMiBO
Q0wtRkpDRy0HxNjMyIE5DTC1GSkNHLTE2MzIgTkNMLUZKQ0ctMTYzMiBOQ0wtRkpDRy0xNjMyIE5D
TC1GSkkNHLTE2MzIgTkNMLUZKQ0ctMTYzMiBOQ0wtRkpDRy0xNjMyIE5DTC1GSkNHLTE2MzIgTkNM
LUZKQ0ctMTYzMiBOQ0wtRkpDRy0xNjMyIE5DWTC1GSkNHLTE2MzIgTkNMLUZKQ0ctMTYzMiBOQ0wt
RkpDRy0xNjMyIE5DTC1GSkNHLTE2MzIgTkNMLUZKQ0ctMT"YzMiBOQ0wtRkpDRy0xNjMyIE5DTC1G
SkN

This seems like it’s encoded as Base64. So let’s go ahead and decode it…

NCL-FJCG-1632

Answer: NCL-FJCG-1632

That’s all for the NCL Preseason - thanks for reading everyone!

Updated:

Leave a Comment