Differences
This shows you the differences between two versions of the page.
|
isc:labs:08 [2024/11/25 04:52] ebru.resul [[30p] 3. Man in the Middle] |
isc:labs:08 [2025/11/24 12:18] (current) florin.stancu |
||
|---|---|---|---|
| Line 29: | Line 29: | ||
| # let the h4x0rs in (enables the account): | # let the h4x0rs in (enables the account): | ||
| sudo usermod -e -1 -U hacker | sudo usermod -e -1 -U hacker | ||
| + | # make all tty writable by hacker | ||
| + | sudo usermod -aG tty hacker | ||
| </code> | </code> | ||
| Line 80: | Line 82: | ||
| === [10p] Discover Devices on the Network === | === [10p] Discover Devices on the Network === | ||
| - | //**STEP 1: Scan the network with nmap - ping scan**// | + | //**STEP 1: Scan the network with nmap (using ping scan)**// |
| - | * __What It Does:__ Sends ICMP Echo Requests (pings) or TCP/UDP probes to detect devices on the network. | + | * __What It Does:__ Sends ICMP Echo Requests (pings) or TCP/UDP requests to detect devices on the network. |
| * __Strengths:__ Works across subnets and can identify devices beyond the local network. | * __Strengths:__ Works across subnets and can identify devices beyond the local network. | ||
| - | * __Limitations:__ May miss devices that block ICMP or TCP probes. | + | * __Limitations:__ May miss devices that block ICMP or TCP requests. |
| - | <note> **TASK:** Run a ping scan to discover active hosts in your network using nmap (you can use CIDR notation! Remember OpenStack's network prefix?).</note> | + | <note> **TASK:** Run a nmap with ping scan to discover active hosts in your network using nmap (you can use CIDR notation! Remember OpenStack's network prefix?). Hint: Search on google how to run a "nmap with ping scan option"</note> |
| <solution -hidden> | <solution -hidden> | ||
| <code> | <code> | ||
| Line 166: | Line 168: | ||
| * __Purpose:__ Helps test UDP scanning, which is slower and behaves differently than TCP due to the lack of acknowledgments. | * __Purpose:__ Helps test UDP scanning, which is slower and behaves differently than TCP due to the lack of acknowledgments. | ||
| - | <note> **TASK:** Work in pairs. One person opens an UDP server on their VM using netcat, while the other scans for it. Choose a non-standard port (e.g., 10002). </note> | + | <note> **TASK:** Work in pairs. One person opens an UDP server on their VM using netcat, while the other scans for it. Choose a non-standard port (e.g., 10002). Hint: use -k when opening the server to allow multiple connections </note> |
| <solution -hidden> | <solution -hidden> | ||
| Line 269: | Line 271: | ||
| - Ask your colleague for their VM IP address. | - Ask your colleague for their VM IP address. | ||
| - Use `curl` to connect to their HTTP server and display the server’s response | - Use `curl` to connect to their HTTP server and display the server’s response | ||
| - | - Attempt to SSH into their VM using the credentials `hacker:student` | + | - Attempt to SSH into their VM using the credentials `hacker:student31337` |
| - If successful, send a broadcast message to your colleague’s system <code>hacker@<colleague-VM>$ wall "Wazzaap?" </code> | - If successful, send a broadcast message to your colleague’s system <code>hacker@<colleague-VM>$ wall "Wazzaap?" </code> | ||
| </note> | </note> | ||
| + | |||
| + | <note warning> | ||
| + | Unfortunately, ''wall'' [[https://sources.debian.org/src/util-linux/2.41-5/debian/NEWS#L1-L9|was removed from modern Debian systems]] :(( | ||
| + | But we gave ''hacker'' write permissions to all ''tty'', so we could do this instead: <code> | ||
| + | # check for the TTY's address | ||
| + | who # usually, the first one is the owner of the VM, coming from FEP | ||
| + | # then write your message! | ||
| + | echo "Wazzaaa" | tee /dev/pts/0 | ||
| + | </code> | ||
| + | </note> | ||
| <solution -hidden> | <solution -hidden> | ||
| Line 278: | Line 290: | ||
| curl http://<colleague-VM-IP> | curl http://<colleague-VM-IP> | ||
| ssh hacker@<colleague-VM-IP> | ssh hacker@<colleague-VM-IP> | ||
| - | wall "Wazzaap?" | + | echo "wazzzaaaaap" | tee /dev/pts/0 |
| </code> | </code> | ||
| </solution> | </solution> | ||
| Line 459: | Line 471: | ||
| ---- | ---- | ||
| - | For the following exercises, we will use Docker containers to simulate a local network vulnerable to ARP spoofing attacks. (OpenStack filters ARP packets, so you won't be able to do this there). | + | For the following exercises, we will use Docker containers to simulate a local network vulnerable to ARP spoofing attacks. |
| === [20p] ARP Cache Poisoning === | === [20p] ARP Cache Poisoning === | ||
| Line 468: | Line 480: | ||
| - | * Enable IP forwarding on the host system to allow traffic relay | + | * Ensure the host system forwards packets between devices. This is crucial for traffic to flow through the attacker container. |
| <code>sudo sysctl -w net.ipv4.ip_forward=1</code> | <code>sudo sysctl -w net.ipv4.ip_forward=1</code> | ||
| Line 474: | Line 486: | ||
| <code>docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:22.04</code> | <code>docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:22.04</code> | ||
| - | * Open an "Attacker" terminal (on the same VM): | + | * Open an "Attacker" terminal with IP forwarding enabled: |
| <code>docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:22.04</code> | <code>docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:22.04</code> | ||
| Line 493: | Line 505: | ||
| //**STEP 3: Launch the ARP spoofing attack**// | //**STEP 3: Launch the ARP spoofing attack**// | ||
| - | <note>Perform ARP cache poisoning from the attacker container to impersonate the gateway (router) for the victim.</note> | + | <note> Perform ARP cache poisoning from the attacker container to impersonate the gateway (router) for the victim.</note> |
| * Inside the "Attacker" terminal | * Inside the "Attacker" terminal | ||
| Line 505: | Line 517: | ||
| </code> | </code> | ||
| - | //**STEP 4: Monitor the network traffic**// | + | //**STEP 4: Verify the Setup**// |
| - | <note>Observe the impact of ARP poisoning and verify the attack's success.</note> | + | <note> Observe the impact of ARP poisoning and verify the attack's success. |
| + | </note> | ||
| * Open a second session on the attacker container | * Open a second session on the attacker container | ||
| - | <code> | + | <code> tcpdump -i <INTERFACE> -nvvX |
| - | tcpdump -i <INTERFACE> -nvvX | + | |
| </code> | </code> | ||
| <note> Check the victim’s ARP table to confirm the gateway MAC address has been replaced with the attacker’s MAC. The victim’s traffic should now flow through the attacker. </note> | <note> Check the victim’s ARP table to confirm the gateway MAC address has been replaced with the attacker’s MAC. The victim’s traffic should now flow through the attacker. </note> | ||
| + | <code> ip nei sh | ||
| + | </code> | ||
| - | === [10p] Task B: Test Implementation === | + | === [10p] Test Implementation === |
| //**STEP 1: Monitor DNS traffic from the victim**// | //**STEP 1: Monitor DNS traffic from the victim**// | ||
| - | * __Purpose:__ Capture DNS traffic intercepted during the MitM attack to demonstrate how attackers can steal sensitive information. | + | <note> Capture DNS traffic intercepted during the MitM attack to demonstrate how attackers can steal sensitive information.</note> |
| - | <code bash> | + | * In the attacker terminal |
| - | # In the attacker terminal | + | <code> |
| tcpdump udp port 53 -nvvX | tcpdump udp port 53 -nvvX | ||
| </code> | </code> | ||
| + | |||
| //**STEP 2: Simulate victim activity**// | //**STEP 2: Simulate victim activity**// | ||
| - | * __Purpose:__ Generate network traffic from the victim to verify interception. | + | <note> Generate network traffic from the victim to verify interception. Observe DNS traffic in the tcpdump output to confirm interception. </note> |
| - | <code bash> | ||
| - | # In the victim terminal, check the ARP table | ||
| - | ip nei sh | ||
| - | # Ping a website to generate traffic | + | * In the victim terminal, check the ARP table |
| - | ping my.secretwebsite.com | + | <code> ip nei sh</code> |
| - | # Unfortunately, IP forwarding inside containers doesn't work in this simulation, | + | * Ping a website to generate traffic |
| - | # but the tcpdump on the attacker should still show intercepted ARP or DNS traffic. | + | <code> ping my.secretwebsite.com </code> |
| - | </code> | + | |
| - | <note> **TASK:** Observe DNS traffic in the tcpdump output to confirm interception. </note> | + | * Unfortunately, IP forwarding inside containers doesn't work in this simulation, but the tcpdump on the attacker should still show intercepted ARP or DNS traffic. |
| - | === [10p] Mitigation and Defense === | ||
| - | //**STEP 1: Understand Mitigation Techniques**// | + | === Mitigation and Defense === |
| * __Why Mitigation is Necessary:__ ARP spoofing is a common attack on local networks, especially public Wi-Fi. Implementing defenses can prevent unauthorized access and secure sensitive data. | * __Why Mitigation is Necessary:__ ARP spoofing is a common attack on local networks, especially public Wi-Fi. Implementing defenses can prevent unauthorized access and secure sensitive data. | ||
| Line 556: | Line 566: | ||
| - Deploy intrusion detection systems (IDS) to monitor for unusual ARP activity. | - Deploy intrusion detection systems (IDS) to monitor for unusual ARP activity. | ||
| - | <note> **TASK:** Research how static ARP tables or DAI can be implemented on your network. If possible, try configuring them on your host or a VM. </note> | ||
| - | |||
| - | //**STEP 2: Apply Lessons Learned**// | ||
| - | |||
| - | * __Purpose:__ Consolidate knowledge by applying techniques to protect against ARP spoofing in your own environments. | ||
| - | <note> **TASK:** Document steps to configure defenses, monitor ARP activity, and secure communications. </note> | ||
| ==== [10p] 4. Feedback ==== | ==== [10p] 4. Feedback ==== | ||
