Differences
This shows you the differences between two versions of the page.
|
isc:labs:08 [2024/11/25 04:28] ebru.resul [[30p] 2. Iptables] |
isc:labs:08 [2024/11/27 09:47] (current) ebru.resul [[30p] 1. Port Scanning] |
||
|---|---|---|---|
| Line 80: | Line 80: | ||
| === [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 166: | ||
| * __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 432: | Line 432: | ||
| ==== [30p] 3. Man in the Middle ==== | ==== [30p] 3. Man in the Middle ==== | ||
| - | The ARP protocol is widely used for translating L3 (IP) addresses into L2 (data-link) addresses. | + | The Address Resolution Protocol (ARP) is used to map IP addresses (Layer 3) to MAC addresses (Layer 2) on local networks. However, ARP is inherently vulnerable because it lacks authentication. Attackers can exploit this weakness by forging ARP responses, tricking a victim into associating a legitimate IP (e.g., the router) with the attacker’s MAC address. This allows the attacker to intercept and manipulate network traffic, a classic example of a Man in the Middle (MitM) attack. |
| - | Unfortunately, it suffers from a critical security vulnerability: due to its unauthenticated nature, a destination machine has no way of determining whether a ARP reply is valid, so an attacker can forge ARP packets and tell a victim PC to associate the router's IP address to the attacker's MAC address, such that it will send all traffic through the victim's machine. | + | Think of this as you’re mailing a letter to your bank. A middleman secretly intercepts the letter, opens it, reads all your private information, and replaces it with their own fake letter before sending it to the bank. You never realize your communication was tampered with, but the middleman now has all your sensitive details. This is essentially what a Man-in-the-Middle attack does in a digital network. |
| - | === [20p] Task A: ARP Cache Poisoning === | ||
| - | * We will use two Docker containers to simulate a vulnerable local network (OpenStack filters ARP packets, so you won't be able to do this there). | + | * **Why would you do this as an attacker?** |
| - | <code bash> | + | - To intercept sensitive information like credentials or financial data being transmitted over the network. |
| - | # turn on IP Forwarding -- for the attacker (inherited from host) | + | - To disrupt communications, redirect traffic, or inject malicious content into a victim's browsing session. |
| - | # containers don't have permission for this and we don't want to bother with capabilities | + | - To gather intelligence on a target network or exploit vulnerabilities in intercepted traffic. |
| - | sudo sysctl -w net.ipv4.ip_forward=1 | + | |
| - | # Open a "Victim" terminal (on your VM): | ||
| - | docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:22.04 | ||
| - | # Open an "Attacker" terminal (also on the same VM): | ||
| - | docker run --rm -ti --entrypoint /bin/bash --name attacker --sysctl net.ipv4.ip_forward=1 ubuntu:22.04 | ||
| - | # we need two terminals for the attacker (for the tcpdump later) | + | **Real-World Example:** |
| - | # so... in a third terminal, spawn a Docker exec shell: | + | The 2015 Superfish Visual Discovery vulnerability in Lenovo laptops exposed millions of users to Man-in-the-Middle attacks by allowing attackers to intercept and decrypt HTTPS traffic, highlighting the dangers of pre-installed software and weak security practices. |
| - | docker exec -ti attacker /bin/bash | + | |
| - | </code> | + | |
| - | * **Victim terminal** (note: we're inside a container): install prerequisites & find out the IP address given by Docker: | + | **Is MitM Still Used?** Yes, Man-in-the-Middle attacks are still used today and remain a serious threat. Their methods, however, have evolved with the advance in technology |
| - | <code bash> | + | |
| - | apt update && apt install -y iproute2 iputils-ping netcat-openbsd | + | |
| - | ip a sh | + | |
| - | </code> | + | |
| - | * **Attacker terminal:** install prerequisites & establish yourself as the Man in the Middle using ARP Spoofing: | + | * Public Wi-Fi Networks: Attackers exploit insecure hotspots to intercept traffic. |
| - | <code bash> | + | * IoT Devices: Poorly secured devices provide new opportunities for interception. |
| - | # install prerequisites for this task | + | * Advanced Techniques: Attacks like SSL/TLS downgrades and HTTPS spoofing target encrypted connections. |
| - | apt update && apt install -y dsniff tcpdump iproute2 iputils-ping | + | |
| - | # start poisoning the host's ARP cache | + | **Mitigation Today:** |
| + | |||
| + | * Strict SSL/TLS protocols and certificate validation. | ||
| + | * Secure DNS implementations like DNSSEC and DNS over HTTPS. | ||
| + | * Use of Virtual Private Networks (VPNs) for secure communication on public networks. | ||
| + | |||
| + | ---- | ||
| + | For the following exercises, we will use Docker containers to simulate a local network vulnerable to ARP spoofing attacks. | ||
| + | |||
| + | === [20p] ARP Cache Poisoning === | ||
| + | |||
| + | //**STEP 1: Set up the environment**// | ||
| + | |||
| + | <note>Create a simulated network with Docker containers to demonstrate how ARP cache poisoning works in a controlled environment.</note> | ||
| + | |||
| + | |||
| + | * 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> | ||
| + | |||
| + | * Open a "Victim" terminal (inside your VM): | ||
| + | <code>docker run --rm -ti --entrypoint /bin/bash --name victim ubuntu:22.04</code> | ||
| + | |||
| + | * 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> | ||
| + | |||
| + | * Open a third terminal for an additional attacker session: | ||
| + | <code>docker exec -ti attacker /bin/bash</code> | ||
| + | |||
| + | //**STEP 2: Configure the victim container**// | ||
| + | |||
| + | <note> Prepare the victim machine to simulate a normal user in the network. | ||
| + | </note> | ||
| + | |||
| + | * Inside the "Victim" terminal | ||
| + | <code>apt update && apt install -y iproute2 iputils-ping netcat-openbsd</code> | ||
| + | |||
| + | * Find the IP address of the victim container | ||
| + | <code>ip a sh</code> | ||
| + | |||
| + | //**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> | ||
| + | |||
| + | * Inside the "Attacker" terminal | ||
| + | <code> | ||
| + | apt update && apt install -y dsniff tcpdump iproute2 iputils-ping</code> | ||
| + | |||
| + | |||
| + | * Start ARP poisoning | ||
| + | <code> | ||
| arpspoof -i <INTERFACE> -t <VICTIM_IP> <GATEWAY_IP> -r | arpspoof -i <INTERFACE> -t <VICTIM_IP> <GATEWAY_IP> -r | ||
| </code> | </code> | ||
| - | === [10p] Task B: Test Implementation === | + | //**STEP 4: Verify the Setup**// |
| - | * **Attacker terminal:** Listen for DNS traffic from the victim: | + | <note> Observe the impact of ARP poisoning and verify the attack's success. |
| - | <code bash> | + | </note> |
| - | tcpdump udp port 53 -nvvX | + | |
| + | * Open a second session on the attacker container | ||
| + | <code> tcpdump -i <INTERFACE> -nvvX | ||
| </code> | </code> | ||
| - | * **Victim terminal:** Open a netcat server and listen for content | + | <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 bash> | + | <code> ip nei sh |
| - | # check ARP table (your gateway's MAC should be the attacker's) | + | |
| - | ip nei sh | + | |
| - | # ping your favorite website | + | |
| - | ping my.secretwebsite.com | + | |
| - | # Unfortunately, IP forwarding inside container doesn't work :( | + | |
| </code> | </code> | ||
| - | The ''tcpdump'' capture on the Attacker terminal should show the intercepted DNS requests ;) | + | === [10p] Test Implementation === |
| + | |||
| + | //**STEP 1: Monitor DNS traffic from the victim**// | ||
| + | |||
| + | <note> Capture DNS traffic intercepted during the MitM attack to demonstrate how attackers can steal sensitive information.</note> | ||
| + | |||
| + | * In the attacker terminal | ||
| + | <code> | ||
| + | tcpdump udp port 53 -nvvX | ||
| + | </code> | ||
| + | |||
| + | |||
| + | //**STEP 2: Simulate victim activity**// | ||
| + | |||
| + | <note> Generate network traffic from the victim to verify interception. Observe DNS traffic in the tcpdump output to confirm interception. </note> | ||
| + | |||
| + | |||
| + | * In the victim terminal, check the ARP table | ||
| + | <code> ip nei sh</code> | ||
| + | |||
| + | * Ping a website to generate traffic | ||
| + | <code> ping my.secretwebsite.com </code> | ||
| + | |||
| + | * 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. | ||
| + | |||
| + | |||
| + | === 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. | ||
| + | |||
| + | * **Mitigation Techniques:** | ||
| + | - Use static ARP tables to bind specific IP-MAC pairs. | ||
| + | - Enable dynamic ARP inspection (DAI) if supported by your network hardware. | ||
| + | - Use encryption protocols (e.g., HTTPS, VPNs) to secure communications even in the presence of MitM attacks. | ||
| + | - Deploy intrusion detection systems (IDS) to monitor for unusual ARP activity. | ||
| ==== [10p] 4. Feedback ==== | ==== [10p] 4. Feedback ==== | ||
