jakec / dec 2020
How does data travel from one computer to another? We’ve already explained part of it: by using an IP address and a port number, data knows where it has to go. But how do computers know what to do with that data as it travels across the internet? Thanks to things called protocols. Protocols describe what a particular type of data should look like and how it should be handled. It’s basically a fancy way of saying a set of rules, and like rules, they have to be agreed upon to work. For example, the SSH protocol describes how a computer might connect to a networking device. The computer says to the network gear, “Hey, I wanna use SSH to have a squiz at your guts.” The network gear replies, “Gross! But okay. According to RFC 4253 (https://tools.ietf.org/html/rfc4253#page-4) I need you to send me some info first.” You can literally read the RFC (Request for Comment, a document that outlines a standard for the internet; there are a lot of them) if you want to find out what that info is. Fortunately, computers do it all for us, so you don’t have to think about it too much. Then, some other stuff happens as outlined in the RFC, after which you can have a securely connected squiz at aforementioned guts.
When you’re in networking (or security), you don’t have to know protocols on the level of citing their RFC or being able to code your own communications stack. But knowing a bit about them helps because when you see them in a program like Wireshark, which we’re using today, they can serve as shorthand for how you might expect data tagged with those protocols to act.
Wireshark is a “packet analyser” which is jargon for “it watches everything that happens on your network connection.” You open it up and it immediately starts capturing every bit of data coming in and out of your computer. And by “bit of data” I mean “packet”.
See, data is broken up and rearranged as it goes out of your computer and into another device. If I send you the words “Hey babe! Wanna come over and watch Mission Impossible: Fallout?” over some IM app, it doesn’t travel as “Hey babe! Wanna come over and watch Mission Impossible: Fallout?” It’s actually not words at all; it’s bytes, machine code represented by a jumble of letters and numbers. This big blob of letters and numbers representing the words “Hey babe!” is split up into “segments”, then each segment gets a bit of extra data put on top of it, called a header, which includes the port number the data is coming from, the port it’s meant to go to on the other machine, and some other little details, like a sequence number.
Then, each segment is broken up further into “packets” and another header is added with the IP address it’s coming from and going to and its protocol type. Then, each packet is broken up into “frames” which add a header including the MAC address it’s coming from and going to. MAC addresses are specific to your computer’s motherboard; it’s as close to a literal ID for a computer as you can get.
All of this is then converted into pulses which are shot across a wire and reinterpreted as data on the other side. How? Binary, baby. With the data broken into 1s and 0s, 1 representing a higher voltage pulse and 0 representing a lower voltage pulse, computers can talk. Just, basically, by flicking a light switch on and off. Can you believe something so incredible?
(At least, that’s my understanding. Honestly the closer you get to the wire, the less I know about it.)
That’s a long lesson in a lot of stuff that isn’t particularly relevant to the challenge at hand, but will make you look cool at parties. Here are the actual questions for this challenge.
What is the IP address that initiates the ping?
What’s a ping? You remember that app “Yo!” where you could only send one thing to your contacts: a “Yo!”? A ping is like that. A hollow bit of information that nevertheless reaches out and touches somebody else and if they “Yo!” you back, tells you something about, at least, whether they’re awake or not. “Ping” is actually the name of the program; what it actually does is send what’s called an ICMP (Internet Control Message Protocol) request to a computer and then wait for an ICMP reply. So if we scroll down to where the ICMP packets begin in our Wireshark packet capture, we can see that the source IP (the address of whoever sent the first ping) is 10.11.3.2.
If we only wanted to see HTTP GET requests in our file, what filter would we use?
You’re an expert on GET requests now, so you know they’re a part of another important protocol, the Hyper Text Transfer Protocol (HTTP). Wireshark captures A LOT of traffic as soon as you trigger it — the only way to sort through it is with filters that specify what you’re looking for. One of those filters, which is useful for seeing who’s been visiting particular websites, is http.request.method == GET.
Apply this filter. What is the name of the article that the IP 10.10.67.199 visited?
You could probably do something fancy here involving more filters, but I’m just gonna scroll down and, looking at the Info column, see if there’s anything that looks like an article. We can forget about fonts and favicons, that’s just loaded by default. But /posts/reindeer-of-the-week/ seems just like what we’re looking for.
Next packet capture: Look at the captured FTP traffic. What password was leaked during the login process?
Let’s start by filtering Wireshark so it only shows FTP traffic. FTP is another protocol, the File Transfer Protocol, and it’s less prevalent these days but used to be the best way to transfer files across the internet. Unfortunately like a lot of older protocols, it doesn’t have much in the way of security, so we can see here there’s been an FTP request transferred with the text “plaintext_password_fiasco”.
What is the name of the protocol that’s encrypted?
Erasing our “ftp” filter in Wireshark to bring back all the traffic in the packet capture file, we’ve got some SSH traffic in here. Unlike FTP, SSH is encrypted by default and you can see in the Info column it even says “Encrypted packet.”
And then our final packet capture file. What is on Elf McSkidy’s wishlist that will be used to replace Elf McEager?
This tripped a few people up. It requires making some inferences about the question. First, this is explicitly a Wireshark challenge. There’s no virtual machine to connect to, no target given to brute-force or anything like that. The answer must be inside this packet capture file. Second, it will involve one of the methods already used; THM are good about building on prior skills, so this seemed likely to be a demonstration rather than an entirely new obstacle. Third, it’ll be a bit of legwork. The last one didn’t pan out so much: I filtered by GET request again (http.request.method == GET) and found two packets. The second was to 10.10.21.210/christmas.zip. Hell, that might not be “wishlist.zip” or appear connected to the question, but I wanna find out what’s inside anyway. So I went File > Export Objects > HTTP to download the zip file. I had no idea Wireshark could also capture files like this until now; I thought I might get something like a download page instead. But there in my Downloads folder, a zip archive. Unzipping it reveals some images and “elf_mcskidy_wishlist.txt”. And what’d he get to replace Elf McEager? Find out for yourself.
- Download Wireshark
- Download the .pcap files from THM.
- Open pcap3.pcap in Wireshark.
- Filter the packets to find the one I mentioned in the last paragraph.
- Export the file.
- Unzip it and check it out.
Feel free to @ me if you get it.