RSM recently hosted a Capture the Flag competition for high school students in partnership with the University of Mount Union. Our team attempted to craft challenging but “solvable” problems for the participants to complete. When I was writing my challenges (they fell mostly in the Forensics category) my goal was to make problems that were something a high school student wouldn’t necessarily be able to answer off the bat, but, I included clues in each question, which were meant to direct students to sources which would be useful in solving each problem. This challenge, Forensics 200, included a packet capture file with a live exploit contained inside; specifically, the file contains traffic of a simple buffer overflow of an SLMail Server.
The Challenge
The students were given a pcap file with the following question: “The forensics200.pcap file contains some scanning traffic, followed by an exploit of a vulnerable SLMail Server. What are the first and last packets of the exploit tcp session (including TCP handshake)? (Answer format: first packet number-last packet number (e.g. 1-2)).”
Chasing Clues
Given the file type of the provided capture file, it was expected that the participants would have to undertake some very light Google-ing which would yield many useful tools, specifically, Wireshark. The second clue was “SLMail exploit” with one of the first results being this. Besides the exploit code (which, if you had knowledge about this sort of thing, should have told you all you need to know), we can see that it is a buffer overflow in the PASS command. Given no knowledge of Wireshark or how exploits work, we still have a lot with which to work. Some basic research on buffer overflows will tell you that you need a lot of user input to overwrite things (technically speaking, of course), and we know it is on the PASS command so we can start to look for the pass command in Wireshark. Even with no understanding of how TCP works, we can easily learn the basics through Wikipedia.
All of these sources provide knowledge of how the exploit works, what it should look like, where it starts and ends, and how to read the file. This is sufficient to start searching for the exploit traffic within the file itself. The jump-off point was to simply carefully examine the question and be inquisitive. Ultimately, that’s what I believe is the key to being a hacker.
Methods for Solving
Let’s start from the beginning. We have a pcap and a known exploit. So pull up the pcap in Wireshark. We can see almost 2.5k packets, so it is relatively small. Starting off, there are a lot of syn packets to different port numbers that are followed by reset ack packets.
I wouldn’t expect a high school student to know what this means (I certainly didn’t back then), so we will take a moment to discuss the theory of scanning a computer. Computers communicate on a network using ports and IP addresses. The IP address is kind of like an address to a house, it tells us where to send our messages. We also have multiple potential residents at this house (65,535 in fact) so we send our mail to the address and the specific resident at the house. Let’s say we want to find out who lives at this house. One way to do so is to send lots of mail to the different people (ports) and ones that aren’t there will typically send us back “does not live here” (reset ack packets) letters. That is what we are seeing going on right now.
Assuming we don’t know that, it is still possible to narrow down the scope in other ways. We do know that SLMail is a POP3 server which runs on port 110. So we can find only traffic to that port by using the filter bar across the top and searching for “tcp.port == 110”. The filter string looks a bit esoteric if you are not used to it, but Google leads us right to the answer if we search for “wireshark filter port”.
At this point, I will give you a little spoiler: our starting packet is displayed on the screen with just this filter.
So how do we determine which one it is? Hop back to our example exploit from exploit-db. It has the text “USER” and “PASS” part way down. Although you may not be able to read code to understand that it is sending that to the server, you can see both of these show up in our filtered display. In fact, if we enter “tcp contains “PASS”” into our filter we see only two packets. One that looks like somewhat similar to our example exploit and the other not so much.
Say we didn’t know how to search for TCP sessions that contain the text “PASS” (and I didn’t expect that from the participants). From our previous filter, we already have the packet, and, with a little bit of research, we know vaguely how a TCP handshake works. So we can trace back the list of packets to the first SYN, SYN-ACK, ACK packets starting at 1733. Then we can follow the traffic down until we find the FIN ACK and ACK packets. From Wikipedia, we know that FIN is how we begin to end the session and the last packet we see is 1746. Formatting it correctly, we have “1733-1746”, which was the solution.
That is one way to have approached the challenge. We could have have even brute forced all of the session starts and ends if we wanted, since we know how those work. It would have been tedious but I would have accepted that path to the answer.
Further Research
If you were a participant in the event, hopefully the CTF has inspired you to go out and learn more about information security. Take a look at Wireshark (or even TCPDump). Learning to use either will teach you a lot more about TCP and are quite valuable. At a higher level, be inquisitive and never be afraid to ask, “Why?” And most of all have fun.
Keep hacking!
