FIRST SecLounge CTF 2020 – Network Challenges

The network challenge consisted of 11 tasks we had to solve.The same PCAP file was given for the first nine challenges, and there were two other PCAPs for the last two tasks. Solving these requires a bit of knowledge of Wireshark and some OSINT search about MikroTik routers.

 

Compromise: Part 1 (capture.pcap)

What is the attacker IP address? 

The first thing to do is to open up the PCAP file in Wireshark. By looking at the traffic flow it is evident that 172.16.100.223 initiated the conversation by sending the SYN packet first. 

 

Solution: 172.16.100.223 

 

Compromise – Part 2

What is the victim IP address? 

 

Evidently the target machine would be 172.16.100.1. 

 

Solution: 172.16.100.1 

 

Compromise – Part 3

What is the service exploited? (brandname/servicename/portnumber) 

 

We see three major traffic flows between the source and destination. One on port 8291, another one on port 22, and the final being used is port 4545. A summary can be seen under Statistics/Conversations. 

As both port 22 and 4545 are encrypted, we take a look at the traffic flow for port 8291 (tcp.stream eq 0). It seems our attacker got his hands on a file user.dat and it is being exfiltrated. 

According to the MikroTik documentation, port 8291 is used for WinBox: https://wiki.mikrotik.com/wiki/Manual:IP/Services 

 

Solution: mikrotik/winbox/8291 

 

Compromise – Part 4

What is the CVE number for this vulnerability? (CVE-YEAR-NUMBER) 

 

This one was very easy as a simple Google search for “MikroTik 8291 cve” gives us: https://www.exploit-db.com/exploits/45578 

 

Solution: CVE-2018-14847 

 

Compromise – Part 5

What is the username found? 

 

Packet 12 contains what seems to be some usernames: systemadmin, admin, and masterofmasters.

As both admin and systemadmin are system managed accounts, excluding these gets us masterofmasters. 

 

Solution: masterofmasters 

 

Compromise – Part 6

What is the password found? 

 

In order to answer this question, we would have to download the MikroTik RouterOS password recovery tool called mtpass. After we have cloned the repository from https://github.com/manio/mtpass/, let’s run ./bootstrap.sh, ./configure and make, finally. If the make process fails, we are probably missing the libssl-dev library. 

 

./mtpass -d user.dat 

 

Solution: GtV453&Ol 

 

Compromise – Part 7

What is the key used to encrypt the password? 

 

In this scenario, we needed to modify the mtpass source code to print the value of user_magic: 

https://github.com/manio/mtpass/blob/3067bcb6ec2e5a66053fdab7de34f97a6b9ea229/mtpass.cpp#L164 

Off to recompiling and running the tool on user.dat again. 

 

Solution: masterofmasters283i4jfkai3389 

 

Compromise – Part 8

What is the service used by the attacker to connect to the device? 

 

This was a very simple question, as the attacker used ssh to connect to the device, which is clearly visible in the provided PCAP. 

 

Solution: ssh 

 

Compromise – Part 9

Which service/port was started on the device? (protocol/port) 

 

This one required a bit of guesswork: The port used was evident from the PCAP, but the protocol or service was not that straightforward. Sure, we needed something that can handle HTTP traffic. Our attempts included www/4545, www-ssl/4545, http/4545, and proxy/4545. 

One solution to this problem was to go through the official documentation and try to find something capable of handling HTTP traffic in some way or form: 

https://wiki.mikrotik.com/wiki/Manual:IP/Services 

 

Solution: socks/4545 

 

Compromise – Part 10 (2nd-capture.pcap): 

There is one more flag here. Can you find that? 

 

In this scenario a new capture PCAP file is provided. Usually in these scenarios, this might be a Pre-Master-Secret log file. Applying it, now we can see the decrypted traffic, including a few HTTP2 requests: 

 

The URL included in the request is alive and shows our flag: 

Pastebin.com/u1BakdQf 

Solution: Flag: 2fb0ff51a1180f35be9b786821457e8bd4e5 

 

Compromise – Bonus (cap2.pcap)

Can you find the flag? 

 

If we examine the provided PCAP closely, it is clear there is an exchange of ICMPv6 Echo and Request packets. However, packet 37 and packet 38 seems to contain some interesting data, mostly dots and dashes. One thing that comes to mind immediately is that it could be Morse code. 

Let’s google for a simple Morse code translator, copy the data from the PCAP and insert it in. Our hunch was right, and we are presented with the last flag: