Interception
Last updated
Last updated
This was a series of 3 challenges, revolving around Man-in-the-Middle (MITM) attacks.
192.168.0.1 is periodically (once every 4 seconds) sending the flag to 192.168.0.2 over UDP port 8000. Go get it.
This is a basic MITM scenario - we are in the same subnet as the victim, and we need to execute a Layer 2 attack to intercept the communication between 192.168.0.1 and 192.168.0.2.
When 192.168.0.1 sends a packet to 192.168.0.2, at the data link layer, the switch uses the MAC address to decide which device receives the packet - the IP address is invisible to the switch!
The sender must therefore specify a destination MAC address in the packet, but how does the sender know the MAC address of the receiver, given only the IP address?
The Address Resolution Protocol (ARP) is used for this purpose - it essentially allows a computer to "ask" all devices in the subnet which MAC address an IP address belongs to. In order to reduce the amount of ARP requests, each computer also has an ARP cache, where recent IP-MAC address bindings are stored.
The issue comes when an attacker sends a malicious ARP response, resulting in the sender sending packets to the wrong MAC address - that of the attacker! This allows the attacker to receive traffic not intended for him.
In fact, we can send a "gratuitous" (or unsolicited) ARP, which is an ARP response that was not prompted by an ARP request, forcing the target computer to change the bindings in its ARP cache, thereby "poisoning" the ARP cache.
Man in the middle attacks using ARP cache poisoning is much easier and common than you might expect! This is the reason why you should be careful when using public WiFi - someone might very well be assuming the identity of the network gateway.
The tools on this machine are quite limited, so we will only be able to use arping to send our malicious ARP packets.
First, we need to configure a secondary IP address to the interface, so that we can use this IP in our ARP packets. This would be the IP address of the intended receiver.
/ # /sbin/ifconfig eth0:10 192.168.0.2 up
Next, we use arping to send a gratuitous ARP (gARP) to the sender (192.168.0.1), saying that our MAC address belongs to 192.168.0.2, the intended receiver.
/ # arping -c 1 -U -s 192.168.0.2 192.168.0.1
The flag would then be sent to our UDP port 8000.
Someone on this network is periodically sending the flag to ... someone else on this network, over TCP port 8000. Go get it.
This is a slightly more complex scenario - we don't know the IP addresses of the targets!
This was honestly what came to my mind first, and for the purpose of this CTF it works.
After scanning the network and finding that there were only 90 hosts, ranging from 192.168.0.1 to 192.168.0.90, I wrote a quick shell script to send a gARP for every possible receiving IP address.
This is sent to the broadcast address (192.168.0.255), so all devices on the network will receive this gARP. Whoever the sender is, its the receiver's IP address binding in the ARP cache would definitely have been poisoned by the end of the script.
In the tcpdump output, we can then see that the sender is 192.168.0.54 and the receiver is 192.168.0.78.
In the real world, however, this would definitely be much noisier and less reliable.
Alternatively, we could simply search for an open TCP port. Since the flag is sent via TCP instead of UDP, we can check that the receiver has the TCP port 8000 open (otherwise, there's no way for it to receive the flag).
nmap -p 8000 192.168.0.0/24
We would find that 192.168.0.78 has port 8000 open.
This tells us that the target is 192.168.0.78, and we can send a single gARP broadcast for ths address.
arping -c 1 -U -s 192.168.0.78 192.168.0.255
Listening on port 8000 gives us the flag. MetaCTF{s0_m4ny_1ps_but_wh1ch_t0_ch00s3}
192.168.55.3 is periodically sending the flag to 172.16.0.2 over UDP port 8000. Go get it. By the way, I've been told the admins at this organization use really shoddy passwords.
Woah... this is significantly more complicated. So far, we have been doing Layer 2 attacks, and these won't work since the flag is being sent across different subnets. We need to execute an attack from Layer 3, the network layer.
Perhaps we can gain access to the routers somehow? Indeed, we find the Telnet port open on one of the routers.
The challenge said the admins used "shoddy passwords" - this was true because the Telnet credentials were root:admin!
Now that we have access to the router, we need to somehow route the traffic through our attacker-controlled router so that we can sniff it.
From our home directory, we can learn that the router uses BIRD, a routing daemon for Unix operating systems. The BIRD configuration file at /usr/local/etc/bird.conf contains some important information.
Importantly, the Open Shortest Path First (OSPF) routing protocol is used. Fundamentally, OSPF routers use Link State Advertisements (LSAs) to advertise routes to their neighbours, thus allowing each router to maintain the updated topology at any point in time.
To determine the shortest path (which is the one taken by the packet), each link is associated with a "cost" - this can be calculated through a variety of metrics, such as bandwidth. The path that adds up to the lowest cost is considered the shortest path. We can find the paths configured in the BIRD configuration:
In order to sniff the packets, we must make them take the red path below. However, the cost would add up to 14, which is higher than 8 for the shortest path (the blue path)
We would have to edit the configuration file, and lower the costs of the red links.
Now, the "shortest path" goes through our attacker-controlled router!
To reload the configuration, we enter the BIRD CLI:
We should now be able to capture the traffic.
