Mini-Lecture

Hardware:

• WiPi and Alfa wireless cards
  • Both support monitor mode
• Ubertooth
• Arduino + Shield

Software:

• Mallory MITM
• Kali Linux
• Wireshark

Why are these devices so insecure?

• Weak/no passwords
• Communications can be snooped on easily

Control:

• Mobile phones with WiFi, locally or with intervening cloud
• Bluetooth
• TODO LORA

Stages:

• Capture the WiFi password
• Capture and replay
  • Doorlock
• MITM and monitor, capture, alter commands (TCP)
  • Smart lights, thermostats, switches

Does it matter? Now more common in commercial environments and infrastructure: water, electricity, traffic (SCADA).

Addressing vulnerabilities:

• Control what devices have access
• Mobile phones: deny by default; allow access to only specific devices
• Authenticate; 2FA if possible

Thermostat (TCP)

Sniffing

WPA2-PSK uses per-client and per-session keys, so in order to sniff traffic, it is necessary to capture the 4-way handshake even if you know the passphrase.

Following instructions from the previous lab, kill the DHCP server, determine the AP channel, and enable monitoring mode. Then:

• Open Wireshark
• Wireshark may cause the connection to drop; you may need to re-enter monitoring mode
• In Edit, Preferences, Protocol, IEE802.11, Decryption Keys, add the network passphrase (type wpa-pwd)
• In Capture, Interface, select the monitoring interface (mon0)
• Filter by the EAPOL protocol
• Capture the victim device’s handshake, booting them off if necessary

At this point, the victim should be able to see all HTTP traffic from the victim.

MITM

MITM attack. Phone and thermostat on two different networks, with the attacker acting as a proxy between the two.

In this experiment, two subnets were used:

• The phone is connected to one subnet with an IP assigned via DHCP
• The thermostat is on a different subnet with a static IP configured on the router
• The attacker is connected via Ethernet (WiFi packet sniffing can lead to missed packets) and is on both subnets via IP aliasing

IP aliasing:

• Nothing stops you from manually setting your own IP; stuff breaks when multiple devices have the same IP but it doesn’t mean the router will stop you?
  • https://serverfault.com/questions/188350/how-do-vlans-work VLANs would stop traffic flowing between different subnets by essentially splitting them into completely separate LANs. Subnets are layer 3 and this is not something supported by routers - this must be done by firewalls (or by having three physical interfaces - one outgoing to the internet, and one for each subnet to create separate LANs)
• https://www.kernel.org/doc/html/latest/networking/alias.html
• https://www.tecmint.com/create-multiple-ip-addresses-to-one-single-network-interface/
• https://www.freebsd.org/cgi/man.cgi?ifconfig(8)

ifconfig eth0 192.168.0.254/24

is this equivalent to ifconfig eth0 192.168.0.254 netmask 255.255.255.0?

ifconfig eth1 192.168.1.254/24

- Limitation of aliasing:

> As there is only a single physical interface on the system (eth0) and four virtuals/aliases (eth0:0 through eth0:2) on the same subnet, outbound traffic will use the eth0 IP address as the source unless the application is smart enough to declare an outbound interface.
https://serverfault.com/a/12305

iptables setup:

-A PREROUTING -S 192.168.1.0/24 -p tcp -m multiport --dports 80,443 -j REDIRECT --to-ports 8080

redirect HTTP/HTTPS traffic from the 192.168.1.x subnet to port 8080?

Enable Linux's IP forwarding feature:

```bash
echo 1 > /proc/sys/net/ipv4/ip_forward

Finally, modifying packets: mitmproxy -T --host (-T for transparent proxy), and then mitm -T --host --script script_name.py

Smart Light (UDP)

Ethernet, multiple interface.

Cannot intercept and modify; sends another packet immediately after instead.

IP Webcam

Camera streaming to FTP server through AP, capture packets.

Hardware:

• ALFA AWUS036NH USB WiFi adapter with Ralink RT3070
• WiFi router - open network in this experiment
• PC running FTP server
• AXIS 207 webcam, webcam set up to upload photos to FTP server on movement
• Attacker device

Steps:

• iwconfig: determine interface name
• ps -eaf | grep dhc then kill -9 {pid} to kill dhcp server
• airodump-ng {interface}: scan for AP and channel
• airmon-ng stop {interface}
• airmon-ng start {interface} {channel} to enter monitoring mode - note down interface name
• aireplay-ng -9 {(optionally, SSID name)} -a {BSSID} {monitoring-interface}
  • -9 runs injection test
  • NB: uplug and replug WiFi adapter if only beacon frames detected

In Wireshark:

• Select the monitoring interface and start the capture
• Filter by FTP, data packets
• Select a data packet and select ‘Follow FTP Packet Stream’ - JPEG files will likely be spread through multiple packets
• Save

Capture will likely not be perfect - the attacker can’t exactly ask for a retransmission

Bluetooth Doorlock

Hardware:

• QuickLock BTLE door lock
• Ubertooth One Bluetooth sniffer
• Victim Android device

The door lock needs to be usable by multiple devices, so the first user sets up a pin (or uses the default) that they can share with others. Although BTLE is encrypted, the encryption can be cracked if the pairing process is captured. Within the encrypted packets, the PIN is sent from the phone to the lock in plaintext when the lock is first set up, allowing an attacker that breaks BTLE encryption to get the pin and unlock the lock with their own device.

Make a pipe through which BTLE packets will be piped through: mkfifo /tmp/pipe

Set up Wireshark:

• Capture -> Option
• Manage Interfaces
• Uncheck all local interfaces
• Pipes
• Create new pipe to /tmp/pipe
• Back to input, enable promiscuous mode for that interface
• Edit, Preferences
• Protocols, DLT_USER
• Edit
• Add table with DLT of user 0 (DLT=147) payload protocol blte, header and trailer size 0

Then:

• Unpair doorlock on phone
• Turn WiFi off on attacker machine
• Start Wireshark capture
• Start BTLE piping: ubertooth-btle -f -A39 -c /tmp/pipe
  • Follow mode (instead of promiscuous)
  • Advertising channel index 39 (one of three channels (37, 38, 39) that only carry advertising packets)
  • Pipe packets to the /tmp/pipe ‘file’
• Immediately click the button on the lock
  • Hope there are packets being captured
• Using the QuickLock app, pair the lock with phone
  • Hope +1000 packets have been captured
• Lock/unlock the door with the app
• Stop the capture and save the file
• Crack the BTLE encryption key:
  • crackle -i {capture_file.pcapng} -o {output_file.pcapng}
  • Use crackle without the -o to check if the capture has the required packets
  • https://github.com/mikeryan/crackle
• Open decrypted capture in Wireshark
• Filter by btatt.opcode == 0x12 - Bluetooth Attribute Protocol write request
• Find a packet with a message that looks like a pin - there may be padding

https://security.stackexchange.com/questions/100443/security-of-bluetooth-low-energy-ble-link-layer-encryption

Active attack to force 1 byte entropy then brute force https://knobattack.com