Root-me.org – network

Root-me.org is yet another site with tons of fun challenges. One of the main things there is that their challenges explicitly mention that a full write-up on a blog is not permitted. You can however provide your solution once you have the flag and it will be put under the specific challenge. For that reason, as to seek the thin line between what is and is not allowed, I will provide write-ups but only protected with the corresponding flag between curly brackets. So if the flag would be IamtheFlag, the specific post will be protected with the password {IamtheFlag}.

Since that will not help anyone seeking more knowledge in order to solve the challenges, this post will contain some guidance on basic knowledge required to solve most of the challenges.

Network analysis basics

One of the primary things to understand when doing infrastructure security, is network basics. This involves both sufficient knowledge of the various protocols such as IPv4 and IPv6, TCP, UDP and ICMP and all the application specific protocols such as DNS, DHCP, HTTP, FTP etc. A very long list of topics to be aware of and getting a good basic understanding. One of the best ways to get a basic understanding, is by rummaging through the protocols and seeing what they are made up of. During my career, the book TCP/IP Illustrated has been a great help in getting the basic theory right. But what to do next? One thing I did to get some practical hands-on stuff going, was just setting up two virtual machines, and start playing with the different protocols. On my Kali Linux box, I had Wireshark and put it in listening mode each time I made a connection using a specific protocol.

Network packets

Wireshark Basics

First off, these challenges require a basic understanding of network packets. This means not only being able to understand the plain text information in the image below (“Please specify the password”), but also knowing that the characters are a hexadecimal representation of the bits in a packet. It requires the skills to analyze the various protocols on the Datalink (Ethernet), Network (IPv4/IPv6,ICMP(v6)) and Transport (TCP/UDP) levels of the OSI model. Each of these protocol parts contain relevant information for the analysis and should not be overlooked, even though a junior analyst would probably primarily focus on the transmitted data.

Analyzing the Ethernet part of the packet

Wireshark Ethernet data

The Ethernet part of the packet is relatively simple to read. The first 6 bytes (hexadecimal pairs) contain the Destination MAC address (52:54:00:E3:DC:B4), and the subsequent 6 the Source MAC (52:54:00:15:95:C5). The next 2 bytes are the so-called EtherType which contain the identified for the protocol used in this packet. This example shows 08 00 which represents IPv4, other values can be (but not limited to) 86 dd (IPv6) and 08 06 (ARP), these values can be found on a linux machine in the file /usr/include/linux/if_ether.h.

Analyzing the IPv4 protocol part of the packet

The size of the next part depends on the type of protocol. Where an ARP packet uses the next 28 bytes, IPv6 uses 40 and IPv4 uses only 20 bytes.Wireshark ipv4 data

As this example is an IPv4 packet which could already be seen from the EtherType. The first bytes of the IP packet also give this away since they contain the value 45. This byte is actually split in two parts, the first being the Protocol Version (4) and the second part being the number of bytes the header is long, value 5 standing for 20 bytes. The next 8 bytes are bytes which I have so-far found less interesting until the tenth byte (06) which displays the Protocol used in the next part of the message. Common values can be 06 (TCP), 01 (ICMP) and 11 (UDP).

The next two bytes (90 13) represent the IPv4 Header checksum. Checksums can be found throughout various protocols and mostly help to analyze if the data to which it relates is accurate (i.e. not tampered with). The last 8 bytes represent the Source (0A 0D 25 E5) and Destination (0A 0D 25 A8) IP addresses in Hexadecimal.

Analyzing the TCP protocol part of the packet

The next and last transport part of the network packet is the TCP protocol part.

Wireshark TCP data

This part starts with the hexadecimal representation of the Source (00 15) and Destination (AE 88) Ports. As this is an FTP server response, asking for the password, the source port is 21 and the destination port is a random high number port. The next 8 bytes represent the sequence number (04 13 48 91)  and acknowledgement number ( C6 DE D9 2F ). These are (amongst others) relevant in the next section of the analysis to ensure the TCP Stream can be analyzed. Of the remaining bytes, the Flags and the Checksum (30 C4) are of most interest.

The flag value in this case being 18 which stands for PSH, ACK. Some of the TCP basic elements which imply that the sent packet contains some data that requires processing by the corresponding application protocol. Other commonly seen values are 02 (SYN), 12 (SYN,ACK), 10 (ACK) (all recognizable from the TCP Three-Way Handshake) 01 (FIN) and 11 (FIN,ACK).

Analyzing insecure (plain text) application protocols

Only when you understand those ‘lower’ layers in the OSI model, you will start to focus on the specific application layer protocols. That is when you start to learn what that whole ‘plain text protocol’ actually means. By playing around with Wireshark, you see the packets flying around and suddenly, you also see your password flying around. Protocols such as Telnet, FTP and SMTP are all plain text protocols. But how do you analyze that? First, you capture the network traffic using wireshark and once captured, you start analyzing it. First, you look up a packet that appears of interest, in the example below a Telnet packet has been selected.

wireshark_analysis1

However, just one packet may not contain all that much interesting information but the entire trace of related packets may. Therefore you right-click the packet and select Follow -> TCP Stream from the menu. This displays the entire conversation of such a plain text protocol.

telnet conversation

Obviously, the interesting parts here are the login and the password. What you will see is that for the login, each character is displayed double. This is because of the ‘echo’ effect of the telnet connection, when you try to login using telnet, each character is sent to the server and then confirmed and displayed in your terminal. For the password, nothing is displayed and therefore it is not printed in double over the connection.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.