All Files in ‘COSC421 (2022-S1)’ Merged

00. Introduction

Practical cyber-security; no lectures, no theory. 2 hours of labs a week in Erskine 339.

Half finding holes; half setting up security infrastructure (focus on VPNs, IoT).

Labs 9-11 and 11-1 Wednesday, session in the weekend for catch-up.

4 lab reports, 15% each (but some topics are bigger). 8 weeks of work in 7 weeks (term 1) with Ray Hunt, so may require weekend sessions.

Richard Green doing 3 topics in 4 weeks in term 2; covered in exam (40%).

Section 1 course content:

Lab 01 - Wireless and Mobile Networks

WLAN Attack Taxonomy

Passive attacks:

Active attacks:

PSK (pre-shared key) used in labs: each node has string/passphrase that is combined with network SSID to generate unique encryption key for each client and session.

Tools

Several tools available pre-installed in Kali-Linux

(‘ng’ stands for ‘next generation’ - basically version 2)

Login:

WPA/WPA2 Password Cracking

Pwnagotchi

Enterprise Security

Watchguard:

Write-up

Structure:

Lab 2 - Internet of Things

Mini-Lecture

Hardware:

Software:

Why are these devices so insecure?

Control:

Stages:

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

Addressing vulnerabilities:

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:

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:

IP aliasing:

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:

Steps:

In Wireshark:

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

Bluetooth Doorlock

Hardware:

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:

Then:

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

03. Lab 3 - VPN

Mini Lecture

Set up of commercial VPNs.

Device --Encrypted Pipe–> VPN Server --> Internal Network

Does everything need to go through a VPN?

Area of risk: the internet.

Traffic through internal network can be unencrypted; but at the edge of the network (the router), the data should be encrypted as it goes through the big bad internet. Once it hits the other internal network (e.g. difference office), it can be decrypted again.

That is, VPNs create secure distributed networks.

Types of networks:

Design consideration:

Types:

OpenVPN:

SSLVPN:

IPSec:

Authentication only:

Encapsulating security payload:

IKEv2:

TODO

IKEv2 and OpenVPN, each tunnel (device) has its own IP address. Hence, pool of IP address pool required.

IP layer so no ports. So on internal network each VPN-connected device has its own virtual IP

IKEv2 done on router with hardware crypto module

04. AI Anomaly Detection

Background

Types of Anomaly Detection

Neural Networks

Introduction

Too much data, not enough analysis.

Anomalous events occur relatively infrequently, but when they do occur, their consequences can be devastating.

What are anomalies?

Related problems:

Challenges:

Aspects:

Applications:

Point Anomaly Detection

Classification-based Techniques

Main idea: build a classification model for normal/anomalous events based on labeled training data.

Models must be able to handle skewed/imbalanced class distributions: anomalous events are rare by definition.

Must be able to handle skewed/imbalanced class distributions: anomalous events are rare.

Categories:

Techniques:

Nearest Neighbor

Clustering-based Techniques

Statistical Techniques

Other techniques

Information theory:

Spectral techniques:

Visualization-based techniques:

Contextual Anomaly Detection

Online Anomaly Detection

Distributed Anomaly Detection

Intrusion detection:

AI Use Cases

Examples:

05. Deepfakes and Biosensing

Deepfakes

Theory:

Autoencoders:

Generative adversarial networks (GANs):

Use-cases:

Exploitation, intimidation, personal sabotage

Prevention:

Future of Autonomous Biosecurity Sensing

In the future, it is reasonable to expect huge swarms of low cost drones that are scanning for biosecurity etc.

Assume a central base station that controls the paths of the drones. How would you would violate the security of the drones?

05. Deepfakes

Deepfakes:

Theory:

Autoencoders:

Generative adversal networks (GANs):

Use-cases:

Exploitation, intimidation, personal sabotage

Prevention:

05. Future of Autonomous Biosecurity Sensing

In the future, it is reasonable to expect huge swarms of low cost drones that are scanning for biosecurity etc.

Assume a central base station that controls the paths of the drones. How would you would violate the security of the drones?

06. Wrapup

Autonomous Vehicles/Robots Highly Vulnerable to Cybersecurity Challenges

Driver assist: drivers ultimately in charge.

Currently works well with pre-mapped roads with line markings, but there are may scenarios (e.g. snow, dirt roads, dust storms) in which they do not work.

Autonomous levels:

Richard thinks full autonomy in late 2040s.

Cybersecurity Challenges

Autonomous vehicles difficult as very high levels of guarantees are required, which isn’t possible with ML/AI algorithms, which are complex and opaque.

Supply chains also often contain third-party, pre-trained models which could lead to supply chain attacks.

Threats:

Crashes and collisions impact not only just the safety of the passenger, but also pedestrians, bicycles, other vehicles, and related infrastructure.

Autonomous vehicles are susceptible to adversarial ML techniques such as evasion or poisoning attack. The threat model involves spoofing the pattern and facial recognition systems:

Autonomous vehicles in particular may be vulnerable to:

AI systems tend to be involved in high-stake decisions, so successful attacks can have serious impacts.

Hence, resilient and safety-critical systems must be designed with malicious attackers in mind:

Recommendations:

Successful past exploits:

Possible attacks:

As car complexity increases, updates become necessary: how secure is the update process?

Exercise: possible attacks

Exam Hints

Ray’s section:

Exam Notes

Ray

Wireless & Mobile Networks

Tools:

IoT

TCP/Thermostat:

UDP/Smart Lights:

Bluetooth/Door Lock:

VPN

Smart Cards

All Files in ‘Reports’ Merged

Lab 01—Wireless Security Infrastructure

Abstract

This report looks at the state of wireless security infrastructure, specifically the WPA standards, in both personal and enterprise environments, and finds them vulnerable to attack, especially for personal networks. We conclude that wireless security alone should not be relied upon; instead, traffic should be encrypted at higher levels of the network stack, such as through HTTPS, to ensure the confidentially and integrity of data being transmitted over the air and over the local network. To achieve this, enterprises may wish to implement two-factor authentication (2FA), reducing the risk of stolen credentials being used to enter a secure network, and look at zero trust architectures, stopping the implicit trust in devices based on them being on a local network.

Introduction

In today’s world, people have many connected devices in their lives; we carry around smartphones, laptops and smart watches around on our person and have desktops and internet-of-things (IoT) devices at home. Many of these will be connected to our home or work network via WiFi, making it critical for the data flowing through them to stay secure. Businesses too use wireless devices heavily, with many workers using laptops or phones to carry out critical work.

Today, the most common protected WiFi standards in use are WPA2-Personal (WiFi Protected Access II) and WPA2-Enterprise. WPA2-Personal uses a pre-shared key (PSK); a password shared among all users of the network, while WPA2-Enterprise uses a RADIUS server and has unique credentials for each user. This lab does a practical experiment on cracking WPA2-Personal, and does an analysis of the security of WPA2-Enterprise.

Experimental Results

Personal Networks

Cracking WPA2-PSK secured networks was extremely easy, only requiring a WiFi card with monitor mode, a Linux computer and proximity to the network. In this and subsequent labs, the RedHat Linux distribution is used as it has a large number of security and hacking tools built in.

To do this, the attacker must first determine the channel the target network is using using airodump-ng and then configure their WiFi card to use monitoring mode for that channel using airmon-ng.

After this, airodump-ng can be used to log all packets between the access point (AP) and any client devices. As WPA2’s handshake mechanism does not provide forward secrecy, it is possible for the attacker to mount a brute-force attack to crack the AP’s password using any captured handshake packets.

aircrack-ng showing found key ('P#ssw0rd'), master key, transient key, and EAPOL HMAC

Figure 1: aircrack-ng showing cracked password and keys

In the above screenshot, aircrack-ng was used with the rockyou password dictionary to determine the key and transient key, allowing the attacker to decrypt all traffic for that session or join the network.

Fortunately, a large amount of traffic used on personal networks is to the internet, which is increasingly running over HTTPS—depending on the underlying OS, between 80% (Linux) and 99% (ChromeOS) of pages loaded by Google Chrome are loaded over HTTPS [1]. Although this will minimize the impacts to home networks, attackers can still use this as a foothold for further compromise. For example, if they have IoT devices or a PC with a server running, they could use the initial access to the local network to compromise these devices, allowing them to retain access to the network even when they are not physically present.

The process of cracking the password for the access point passive and hence, cannot be detected. However, a less patient attacker can use aireplay or some other tool to send a de-authentication packet on a WiFi card that supports packet injection. Once sent, the victim device will automatically disconnect and then immediately reconnect, allowing the handshake to be captured. There exist projects such as Pwnagotchi [2] which do this disconnection on all devices it can find automatically. If done maliciously, an attacker can also use this to perform a denial-of-service (DoS) attack on all devices in the area.

Although the 802.11w-2009 standard, which is required for Wi-Fi CERTIFIED WPA3™ [3] devices (with all WiFi CERTIFIED devices requiring WPA-3 since June 2020), prevents an attacker from sending valid de-authentication packets, adoption among consumer routers seems very low.

WPA3 also provides better security through a new key exchange protocol called Simultaneous Authentication of Equals (SAE), which provides forward secrecy and prevents offline attacks. Unfortunately, several security issues that have already been discovered in WPA3.

Although WPA3 is now becoming available on newer consumer routers, most routers will likely be in WPA3 transition mode, which allows WPA2 connections with the same password. If an attacker sends beacons claiming the router only supports WPA2 and spoofs the unauthenticated first message of the 4-way handshake, the victim will send the authenticated second message of the handshake. Although the attacker will be unable to reply as the third message requires authentication, the second message from the client contains enough information to brute force the password [4].

Additionally, [4:1] also found that WPA3 is vulnerable to DoS attacks by sending spoofed handshakes. WPA3’s more computationally expensive handshake can be used to overload the AP’s CPU with minimal CPU usage on the attacker device and minimal airtime, preventing new devices from being able to connect.

Wireless Enterprise Networks

In the second part of the lab, a WPA-2 Enterprise network was set up. The hardware used was a PC acting as an HTTP server, and in the later part of the experiment, an Active Directory server, a smartphone, and the WatchGuard XTM33-W [5], an all-in-one router, WiFi AP and firewall.

The final network is as shown below:

Diagram of network setup

Figure 2: diagram of network setup

The router has three security zones:

Screenshot showing firewall rules, including the one allowing TCP port 80 from Any-Optional to Any-Trusted

Figure 3: Screenshot showing firewall rules, including the one allowing TCP port 80 from Any-Optional to Any-Trusted

Devices on different zones cannot communicate with each other unless a specific firewall rule is put in place. In this case, the top rule was added to allow TCP traffic on port 80 originating from any device on the Optional security zone to any device on the Secure zone to pass through. Hence, this will allow devices to communicate with HTTP servers on the Secure zone (but not vice-versa).

Screenshot of bridge setup

Figure 4: bridge setup

Next, a bridge in the Optional security zone was set up with DHCP, with the WiFi AP using this to bridge itself to interface 2. The bridge and interface 1 (Secure, connected to PC) are set to be on different subnets.

The AP was configured to use WPA2 Enterprise with EAP-PEAP and MS-CHAPv2. Initially, the authentication was configured to be through Firebox-DB—a database of usernames and passwords (and groups) built into the WatchGuard device that can be managed through their proprietary configuration software [5:1].

However, this will not be ideal in an enterprise environment as it will not be connected with the rest of their systems, such as user account management and logging systems. Hence, most enterprise environments will instead choose to use an external RADIUS server, often through Microsoft Active Directory. A static password is used to authenticate the AP with the RADIUS server.

WPA2-Enterprise uses unique login credentials for each user and hence, a leak of credentials only affects one user, making revoking/changing credentials much easier. In addition, it provides forward secrecy, with the RADIUS authentication returning a 256 bit pairwise master key unique to the current session [6]. Hence, even if this is brute-forced, the attacker still does not have their password and can only decrypt that single session’s contents. Contrast this to WPA2 personal where the contents of any captured session can be decrypted as long as the handshake is captured.

PEAP-MS-CHAPv2 uses a secure outer TLS tunnel (with the ‘P’ in PEAP referring to this protection) to encrypt inner authentication protocol. This requires the server to have a public key certificate that hopefully has a chain of trust leading to a trusted root CA—in the case of this experiment, a self-signed certificate was used.

On operating systems such as macOS and iOS, the first time the user connects to the network, they must first accept the certificate, giving the user the opportunity to view the certificate and domain. This reduces the chance of an evil twin attack as the attacker must either use a self-signed certificate or register a certificate on their own domain, and hope that the user will not notice or care.

Using the secure tunnel, MS-CHAPv2 is used to verify that both parties have access to the hash of the password. The (unsalted) hash must be in a specific format—NT hash, which may not possible or ideal if Active Directory is not being used.

The MS-CHAPv2 protocol can be brute forced fairly easily [7] due to its use of weak hashing functions such as MD4 and SHA-1 [8]. Hence, the security of the outer TLS tunnel is critical; if it is somehow broken, the user password can be easily extracted.

There are also other EAP methods, although due to the prevalence of Microsoft systems in business and enterprise systems, MS-CHAPv2 is the most common protocol. For example, PEAP-EAP-TLS is more secure [9] as it requires both the authentication server and connecting device to have their own certificate. Hence, to successfully infiltrate a network, the attacker must obtain both the device’s private certificate and user credentials (e.g. from a phishing attack). However, this requires the organization to create certificates for every device, which is not feasible in many situations.

Additionally, WPA2 is not invulnerable: in 2017, a vulnerability called KRACK—key reinstallation attack [10], was discovered, which worked on both personal and enterprise networks. The attack tricked victim devices into reusing keys by replaying transmissions during the handshake, resetting the nonce. As some of the traffic is predicable, a known-plaintext attack can be carried out to determine the transient key. Although a dictionary attack would have been easier on personal networks, this attack worked on enterprise networks and personal networks with strong passwords.

Although all vendors will have since patched their software, this vulnerability shows that even enterprise-grade wirelesses have security issues. Hence, enterprise networks should seek to use encryption on the higher levels of the network stack, such as the application layer, and not trust devices solely because they connected to a local network. This is called a zero trust architecture, and standards such as NIST 800-207 [11] are available which document procedures and practices to implement this.

Additionally, one significant area of weakness that was not covered in this lab is people—humans are fallible prone to reusing passwords and can be fooled into giving up their credentials through social engineering. If attackers can gain these credentials, they will gain significant access to the network. Hence, enterprises should also use 2FA wherever possible, significantly increasing the difficulty of being able to break into a network or tricking employees into giving them access. This should occur on the application layer, with devices on the WiFi network being treated as untrusted by default. For example, hardware 2FA tokens such as Yubikeys or soft tokens such as Google Authenticator could be used as a second factor to authorize logins into company-provided laptops or to allow access to internal systems.

Conclusions

This lab shows that the state of consumer-level WiFi security is very poor, with attackers being able to trivially crack passwords and cause denial-of-service attacks, even on routers supporting the newer WPA3 standard. However, enterprise setups have far better security with user-specific credentials, forwards secrecy, and prevention of evil twin attacks through the use of trusted certificates.

However, KRACK showed that serious vulnerabilities have existed and may still exist in WPA2, making it clear that wireless security alone cannot be trusted. Hence, additional encryption, such as TLS, should be implemented on top of wireless security protocols. On home networks, this is less relevant as most traffic goes to the internet, much of which now uses HTTPS. For enterprise networks, 2FA should also be implemented wherever possible, reducing the consequences of human errors through social engineering or credential stuffing attacks. This could be implemented alongside a zero trust architecture in which no device is treated as secure by default on the basis of it being connected to the local network.

Lab 02—Internet of Things

Abstract

Connected devices are becoming more common in our lives, allowing data from sensors to be streamed and actuators to be controlled remotely, streamlining both our personal lives and business operations. However, these devices are often insecure by default, set up by the factory to not use any encryption or use easily guessable, factory-set credentials, relying mostly on the security of the underlying network for protection. In addition, IoT devices often use outdated and unpatched software, with the manufacturer often not supporting them or possibly having gone out of business.

These factors lead to IoT devices being used by attackers as an entry point into a network, silently siphoning unencrypted data to gain a better understanding or the site and then taking control of vulnerable devices to spread to other devices on the local network. Due to these insecurities, people and administrators should take care to configure devices for security and, if possible, segment their network so that IoT devices are partitioned from the rest of the network, limiting the spread of any infection. This could be done via a set of strict firewall rules or a separate VLAN, with two-factor authentication being used to authenticate any user who wishes to connect to critical IoT LANs.

Introduction

The Internet of Things provides homes and businesses with the ability to remotely monitor and control sites. For homes, this may include smart lights or thermostats which reduce friction in our lives, but for businesses, this may include things such as cameras, medical devices, or industrial control equipment.

This report looks at vulnerabilities in several different devices to show how an attacker can sniff traffic from the device, modify valid commands or send rouge commands. Four devices are covered: a smart thermostat, smart light, IP webcam and a door lock, which used three different protocols: UDP, TCP and Bluetooth. Additionally, the report looks at the consequences of these vulnerabilities in a wider scope, describing possible consequences to serious business operations and mitigations.

Experimental Results

Smart Thermostat

The CT Wireless Thermostat [1:1] is a WiFi-enabled HVAC controller. The thermostat has an open and documented API that runs over HTTP (not HTTPS).

The API also leaves the thermostat wide open in another sense of the word, requiring absolutely no authentication and hence allowing any device connected to the local network full control over its operations. In commemoration of this, CVE-2013-4860 [2:1] was created. This vulnerability means that the thermostat is blindly trusting that any device on the network is secure and trusted, and that the users of the devices cannot be tricked.

In the thermostat, one of the consequences of the lack of authentication is that any device on the local network can send requests, even inadvertently. For example, if an attacker knows the local IP address of the thermostat, they can use a DNS rebinding attack to send commands to the device remotely [3:1]. As CORS—cross origin resource protection, stops JavaScript from making HTTP requests to other domains, an attacker must set up a subdomain on a domain they control to point to the thermostat’s local IP address. Once done, the attacker can send a link to the user on the domain which, when loaded, executes JavaScript that sends malicious network requests to the thermostat. Note that this does not require the user’s phone or computer to be vulnerable; this is purely a social engineering attack allowed by the thermostat’s lack of authentication.

A mitigation of this attack could be achieved by putting IoT devices on a separate VLAN (or separate subnet and blocking all traffic by default), but most home users are likely to not know even where to begin, and many businesses do not do this either. [4:2] found that 72% of healthcare VLANs mixed IoT and IT devices, giving attackers an easy way to penetrate deeper into the network. Due to the prevalence of outdated systems and the critical nature of healthcare, attackers targeting this industry have the power to cause significant financial and personal harm, whether through denial-of-service or ransomware.

Devices should be secure by default [5:2], for most people never change settings from their defaults [6:1], and even businesses can fail to implement basic security measures. As IoT devices become more common in homes and into the hands of less technically knowledgeable users and becomes ever more critical to business operations, the consequences of insecure defaults become greater and greater. For example, many IP cameras come with factory-set default passwords, allowing websites such as insecam.org [7:1] to index thousands of cameras from around the world, including those in sensitive locations such as baby cribs and military installations [8:1].

Even if an IoT device is unimportant and has no consequence to the owner if hacked or taken offline, it can still have impacts on the world. For example, the Mirai botnet [9:1] infected over 600,000 IoT devices and used this to launch massive distributed denial-of-service (DDOS) attacks, with a peak traffic nearing a terabit per second. This was used to launch several attacks on websites and DNS providers, bringing down several high-profile websites.

However, the danger is not just attackers moving from IoT systems to internal networks; the other is also true, with one example being the Kemuri water company hack [10:1]. The company had outdated external-facing systems which allowed attackers initial entry into the business network. As their SCADA systems were on the same system, this same access allowed attackers to modify programmable logic controllers that controlled chemical and water flow in their water treatment facility. At this point, they could have impacted the water of hundreds of thousands of people.

Hence, systems should be partitioned such that it can only be accessed by authorized users, preferably using two-factor authentication to reduce the likelihood of a successful phishing or leaked credentials attack. Although this is unnecessary and far too complex for home systems that control lights and similar devices, for business systems controlling critical hardware such as SCADA systems, this should be the bare minimum.

Part 1: Sniffing

Diagram of sniffing setup

Figure 1: Diagram of sniffing setup

The setup for this experiment was simple: the thermostat and an Android phone with a thermostat control app are connected to the same subnet over WiFi. An attacker is in proximity to the thermostat with a Kali Linux-based computer with a Raspberry Pi WiPi network adapter. Any WiFi card that supports monitor mode and packet injection can be used.

WPA2 encrypts traffic for each session with a unique pairwise transit key (PTK), so to decrypt traffic from the target phone, it is necessary to capture the 4-way handshake. This can be done by either waiting for the phone to connect or by forcing the phone to disconnect using a tool such as aireplay.

In this experiment, Wireshark was used for packet sniffing as it has built-in support for WPA decryption (IEEE802.11). This step also assumes that the pre-shared key (PSK)—the password for the WiFi network, is known. As this was shown previously in Lab 1, this experiment was done under the assumption that the attacker already knows the password.

At this stage, the attacker can easily observe any HTTP traffic sent by the victim phone. Hence, even if the device they are targeting is unknown by the attacker or has an undocumented API, they may be able to reverse-engineer it by passively observing the traffic. Additionally, if the API requires authentication, such as through HTTP basic authentication or through an API token in the request header, the attacker will be able to view and use these to send malicious commands.

Screenshot of Wireshark showing packet sent by phone setting thermostat temperature

Figure 2: Screenshot of Wireshark showing packet sent by phone setting thermostat temperature

Part 2: Proxying

By the end of part 1, the attacker has everything they need to send malicious commands. However, seeing the thermostat change temperature on its own may alert the user and hence, they may also take a more subtle approach by modifying traffic between the victim’s phone and thermostat and giving the victim false information on the state of the thermostat.

This type of attack was used in the hugely damaging Stuxnet virus which attacked Iran’s nuclear centrifuges, which replaced drivers and libraries so that it could send commands to the programmable logic controllers (PLC) while also hiding this activity from the rest of system [11:1].

Diagram of MITM setup showing how packets travel through the attacker machine

In order carry out this modification, the attacker must take a more active role in the network, acting as a man-in-the-middle between the thermostat and phone. In the case of this experiment, this was done by putting the phone (DHCP) and thermostat (static IP) on two different subnets while the attacker device (connected to the router via ethernet for reliability) was on both subnets.

DHCP was configured to set the default gateway to that of the attacker (on the same subnet as the phone). If the phone and thermostat were on the same subnet, they would be able to use ARP to determine the MAC address and directly communicate with each other. However, because they are on different subnets, the gateway—the attacker device, can route packets between the two and hence has the opportunity to intercept, block, or modify this traffic.

As it is acting as the gateway, it needs to be on both subnets simultaneously—otherwise, it would not be able to communicate with either the phone or thermostat. This was achieved using IP aliasing, which allows a single physical interface to act as multiple virtual interfaces.

Screenshot showing virtual IP configuration set using ifconfig

Figure 4: Virtual IP configuration

iptables was then used to redirect TCP traffic coming from the target device to port 8080 on the target device. This is required to set up mitmproxy in transparent mode, which allows the proxy to work without requiring the target phone to be configured.

Screenshot showing iptables setup

Figure 5: iptables setup

In the below example, mitmproxy was used to intercept increase the temperature sent to the thermostat by 10 degrees. Hence, when the phone sent a POST request to set the temperature to 80 degrees, the thermostat received a POST request to set it to 90 degrees.

Photo showing phone and thermostat target temperatures

Figure 6: Photo showing phone and thermostat target temperatures

Although this experiment required control over the access point and routing configuration, this could also be achieved using an evil twin attack, where the attacker masquerades as an access point. If the signal is stronger than that of the real access point and the attacker can force a disconnect, the phone will connect to it. The attacker could then use a secondary network adapter connected to the real access point to transparently proxy traffic.

Smart Lights

Smart lights are becoming increasingly common as technology improves and becomes cheaper, with hundreds of companies making their own smart lights. The bulb used in this experiment is made by Lifx, who provides an Android app which allows the user to control the bulb’s brightness and color over WiFi. The company also provides documentation for the API, with an HTTP API for remote control and a UDP API for local control. The remote API requires authentication, but the local one does not.

The set up for this experiment is similar to the thermostat; the phone and light are on separate subnets, and the attacker is on both via ethernet. However, this experiment also has a second server configured to be the DHCP server, mostly for the purpose of ensuring the IP addresses were consistent between labs. The smart light and victim phone were on different subnets, but this does not need to be the case. Hence, the access point does not need to be under the control of the attacker.

Diagram showing network setup and packet flow

Figure 7: Diagram showing network setup and packet flow. The packet is a broadcast packet, so it is sent to every device on the network (including the DHCP server, but this is not shown)

The Lifx UDP API [12] uses UDP broadcast messages instead of unicast messages, allowing a single command to control multiple lights. This also means that although the attacker can receive the packets, they cannot stop the UDP packet from reaching the smart light. As a work around, the captured packet can be modified and then immediately sent afterwards.

For example, the command below looks for packets originating from the phone with the correct length for a packet that changes the light color. It then takes the first 237 bytes, which contains information such as the message size, light MAC address etc., but not the light color. It then concatenates this first section of the packet with the contents of the file colourstring, removes the newline added by cat, and then injects the modified packet through interface 1, which is on the same subnet as the light.

hexinject -s -i eth0 -c 1 -f 'src host 10.1.1.9 && udp && len == 91' \|
cut -b 1-237 \|
cat -- colourstring \|
tr -d '\n' \|
hexinject --p -i eth1

Hence, the light color will switch momentarily to what the user selected before returning to the color defined in the colourstring file.

Additionally, packets can be saved and then sent out later, even when the victim device is no longer on the network. Although this is not as subtle as the previous attack, this can be easily exploited to cause a denial-of-service. For example, assuming that /tmp/off is a packet captured when the victim turned the light off, the following bash script:

while :; do sleep 0.5; cat /tmp/off | hexinject -p -i eth1; done

sends a command to turn off the light every half a second. The first example given only affects specific packets, while this script will override any command, hence causing a denial-of-service attack. As long as the attacker is on the network, any command sent by the user will be quickly overridden, stopping them from using their phone.

Hence, to prevent against this, two options are possible: the attacker can be prevented from joining the network, or at least the VLAN the light is on, or application-layer security could be added, ensuring only authorized users can control the light. The latter will also require a timestamp or similar mechanism to prevent replay attacks; otherwise, although the first command which modifies the packets will fail, the second command will be unaffected as it is capture of an authenticated and unmodified packet.

IP Cameras

IP cameras are a valuable target for attackers as it gives them insight into the physical state of a target site which they can use for future intrusion. For example, they could use it to determine blind spots in the surveillance system, personnel movements, or to monitor the state of other devices they have infiltrating.

Diagram showing experimental setup

Figure 8: Diagram of experimental setup

This experimental setup used an IP camera that was streaming image frames wirelessly to a server over FTP. The access point used no password to make things easier for the experiment. However, Lab 1 and the thermostat experiment described above showed how the PSK can be easily cracked and how Wireshark can decrypt traffic given the PSK and the four-way handshake. An attacker can easily send a disconnect request with aireplay-ng and then capture the resulting packets to achieve both pre-requisites.

Similar to lab 1, the initial steps are:

Wireshark screenshot showing captured FTP packets

Figure 9: Wireshark screenshot showing captured FTP packets

Then, Wireshark can be used to passively capture traffic going through the router. FTP and FTP data packets can be observed. The images span multiple packets, so Wireshark’s ‘Follow TCP Stream’ option is used to capture the full content of the image:

Screenshot showing image captured passively by Wireshark

Figure 10: Image captured passively by Wireshark

The webcam also runs an HTTP server and its website also has live stream feature. Like with the FTP traffic, the HTTP packets containing the image can also be captured, although the presence of headers makes this more annoying.

As the attacker is listening passively, it is common for capture errors, such as entire segments being missed, to occur—the attacker cannot ask for a TCP re-transmission if packets are missed. Captures are more likely to be successful in un-congested environments where the target device is close by and is using an older and hence slower networking protocol such as 802.11a. Additionally, smaller images are more likely to be successful as fewer packets need to be captured.

Like in Lab 1, this experiment shows the importance of having application-layer encryption and authentication rather than relying solely on the security of the link-layer which, under common circumstances, can be broken completely passively by an attacker with patience and physical proximity. Although the camera used in this experiment [13] provides security by default, forcing the user to set an administration password on first setup, this is not the case with may IoT devices. [4:3] found that 98% of IoT traffic was unencrypted, allowing attackers to gain insight into the physical state of the site and use this information for further infiltration.

IoT Door lock

The other three experiments showed how relying solely on the security of the WiFi and the local network leaves devices vulnerable to attack. However, other wireless protocols, such as Bluetooth, are also vulnerable to attacks.

This experiment uses a SafeTech QuickLock BTLE door lock paired with an Android phone with a compatible app, and Ubertooth One Bluetooth [14] sniffer connected to an attacker machine running Linux.

The lock has a PIN code that can be shared between users so that multiple people can use the door lock. During setup, a compatible app, such as SafeTech and Quicklock, pairs the phone with the lock, and then requests the user to enter a PIN. If entered correctly, the app will then be able to lock and unlock the smart lock.

However, if the initial encrypted BTLE connection can be cracked, the attacker will be able to see the PIN being sent and then use this to set up their own phone to control the lock. Needless to say, if this is done, this vulnerability has severe ramifications on people’s safety and security and may make the lock worse than useless by providing them with a false sense of security.

Diagram showing capture process

Figure 11: Diagram of capture process

After configuring Wireshark to ingest data from the ubertooth-btle pipe as Bluetooth traffic, the data from the Ubertooth could be captured and saved to a pcap file. After doing the initial setup of the victim phone with the lock with the capture running, the traffic could then be cracked using crackle [15], a BLE encryption cracker.

Screenshot showing Crackle output

Figure 12: Crackle output

Bluetooth LE has a ‘Just Works’ pairing mode. In legacy mode, a temporary key (TK) of 0 is used to derive a short-term key (STK) which is then used to derive the long-term key (LTK) that is used for all future connections [16]. Hence, an attacker can easily determine the LTK given the initial connection.

This mode is common in devices which have no screens or other output device, and this provides no authentication and encryption that can be easily broken if the initial pairing process is sniffed. Hence, manufacturers are expected to add their own application-layer encryption protocol, something that many manufacturers, including Quicklock, do not do.

With the link-layer encryption broken, the decrypted packet capture can be opened up in Wireshark, and the ATT (Bluetooth Attribute Protocol) write request can be found. Within one of these, the default PIN for the door lock can be found.

Wireshark screenshot showing the padded default PIN of '12345678'

Figure 13: Wireshark screenshot showing the padded default PIN of ‘12345678’

Fixing this vulnerability requires both the lock and the app to be updated; something that is unlikely to happen considering that their website copyright header still says 2016 and the SafeTech Android app has not been updated since 2017. This is one of the other major problems with IoT; often, devices are released but the software is never updated, leaving insecure devices insecure, or secure devices becoming insecure as new vulnerabilities are discovered. Software requires constant maintenance, but the manufacturer’s software support for the devices they sell are often short or non-existent, and the devices they sell can sometimes outlast the company.

Part of the reason for this is cost; software maintenance and operations is expensive, but the consumer IoT space is very competitive, leaving companies without the necessary time or profit margins to build and maintain secure software. Hence, businesses looking for IoT solutions should look at higher-cost, business-focused products from reputable companies. Subscription services should also be expected as this gives the manufacturer recurring income, giving them incentive to keep their products secure years after they are sold and confidence that the companies will not go out of business.

Conclusions

The Internet of things allows consumers to reduce friction in their homes and businesses to streamline operations, but it is also a point of vulnerability into homes and businesses. Unencrypted traffic, which makes up the majority of IoT traffic, can be sniffed and potentially allow attackers to view sensitive information. Unauthenticated endpoints allow attackers to control IoT devices, and vulnerabilities can be used to launch further attacks into the network or add them to botnets that can bring down some of the biggest websites in the world.

Hence, if IoT devices are in homes or businesses, they should all ideally be secure by default, using application-layer encryption and authentication to protect endpoints. This reduces the chance of unconfigured or misconfigured devices being used as entry points into the network, looking for vulnerable devices or sniffing unencrypted (on the application-layer) traffic from other, non-IoT devices.

In addition, long-term software support is a must, which will likely mean avoiding low-cost, consumer-focused solutions and paying a subscription for long-term support. IoT devices should also be placed on separate VLANS, or at least have strict firewall rules to prevent traffic between groups, reducing the spread of infection between systems. Two-factor authentication should be used to prevent leaked credentials from being used to access critical IoT systems.

Lab 03—Virtual Private Networks

Abstract

Virtual private networks (VPNs) are becoming increasingly necessary in today’s world, with many staff working out of the office, either for business travel or for remote work. Several solutions are available, including open-source solutions such as OpenVPN and Wireguard and standardized protocols such as IKEv2. They offer differing levels of built-in client support, but as no native options support two-factor authentication (2FA) well, client-side VPN software will almost certainly be required.

When considering a VPN, businesses should look to see if the hardware they have now has software support for any modern VPN protocols (e.g. not PPTP), or if potential solutions will integrate well with the existing organization. For example, buying hardware from the same vendors, those you have support contracts with, or those with which the staff have experience with. Networks are complex and so choosing the right hardware can reduce setup time and the chance of misconfigurations leading to network outages or security vulnerabilities. Additional considerations when selecting a VPN will be the number of simultaneous connections it must support—for high connection counts, dedicated VPN hardware will likely have far better hardware cryptography acceleration support compared to standard servers.

However, while VPNs extend the local network past the physical boundaries of the office, they also greatly increase the attack surface and present themselves as a valuable target for attackers looking to penetrate the network. Hence, 2FA should almost certainly be used, and network administrators should, if they are not already doing so, carefully monitor the network for any signs of intrusion. The economic and reputational cost of cyberattacks is far too high to take lightly and will only grow over time.

Introduction

Virtual private networks, or VPNs, are a common way of extending a secured local area network over an insecure channel such as the internet.

Several VPN architectures exist, mostly resolving around where the tunneling occurs. For example, in a branch office scenario where two offices networks are being connected, the routers/firewalls would be responsible for tunneling any traffic going between offices. However, if you want to secure a mobile device, a point-to-site configuration must be used, with the mobile device being responsible for the tunneling its own traffic. Hence, each mobile device must be individually configured to do this tunneling. This lab looks only at the latter architecture.

Additionally, many VPN protocols exist, running at varying levels of the network/OSI stack and offering different security levels, speed, and device compatibility. In this lab, we set up two different point-to-site VPNs: OpenVPN running on a stripped-down Debian server and a IKEv2 VPN running on a WatchGuard XTM33-W [1:2].

Experimental Results

OpenVPN

OpenVPN is open source VPN project which uses OpenSSL and TLS for encryption. It runs over UDP or TCP (although the latter is vulnerable to a TCP meltdown and hence not recommended) which allows it to bypass firewalls in many environments. OpenSSL supports hardware-accelerated encryption in many setups—the default cipher in recent versions of OpenVPN, AES-256-GCM [2:2], can be accelerated by AES-NI instructions [3:2] which is supported by most modern CPUs.

OpenVPN can be configured in either NAT or routing mode [4:4]. In NAT mode, the server modifies the source IP address of the packets to its own IP and picks a random port before forwarding it to the destination. Hence, traffic from all VPN devices appear to originate from a single IP address from the perspective of the local network, preventing local devices from initiating communication with the VPN devices. This downside is not present in routing mode, in which the VPN server forwards packets. However, the network must be configured to route outgoing packets through the VPN server.

Diagram of network setup under OpenVPN

Figure 1: Diagram of network setup under OpenVPN [17]

OpenVPN supports both TUN and TAP [5:3]. The former is a layer 3 IP tunnel and is supported on Android/iOS devices, while the latter is a layer 2 Ethernet tunnel which allows two physically separate ethernet networks to be bridged.

The default topology in OpenVPN for older Windows clients is net30 [6:2], which creates a virtual /30 subnet for each device. Hence, when running, the user will see that OpenVPN has created a new virtual ethernet adapter with a 255.255.255.252 subnet mask. The first IP is the network address; the second is the virtual IP for the OpenVPN server, through which traffic gets routed to; the third is the client address, and the fourth is the broadcast address [7:2]. This obviously consumes more IP addresses than necessary, so the newer, recommended topology, subnet, instead assigns each device its own IP address.

Screenshot showing new OpenVPN user being created

Figure 2: Screenshot showing new OpenVPN user being created

Figure 2 shows the OpenVPN CLI being used to add a new user, Callum. This creates an .opvn configuration file containing [8:2] the public key of the certificate authority (CA), TLS auth key [9:2] (which authenticates the TLS handshake [10:2] and hence prevents attackers from even initiating the handshake), and the public and private keys for the user profile (which are signed by the CA). These are used to negotiate a symmetric key on connection initialization. OpenVPN also supports the use of a static key [10:3], although this does not offer any forward secrecy.

Note that the configuration file protects the key with the static password. However, OpenVPN can also be configured to require a username and password that is transmitted to the server, allowing multiple users to use the same configuration file [^footnote2]. The former case is slightly more secure as it requires both the private key stored in the file and the password, but unlike OTP tokens, it is less likely to be transferred or stored securely, and cannot compare to the security offered by hardware tokens. Hence, businesses looking to use OpenVPN should look at setting up a system requiring user credentials and a second factor. This will likely be linked to the centralized user management system, such as Active Directory, through RADIUS, and use some third-party solution such as RSA SecurID for token management.

The remote key was modified to match the IP address of the server. The WatchGuard firewall was configured to allow UDP traffic over the WireGuard port, port 1194, through, and hence, clients on the external or untrusted network can establish a connection to the VPN server.

The configuration file was transferred over to the client PC with the OpenVPN client installed, and the connection was established. Figure 3 shows the /30 subnet described previously, which OpenVPN has put on the 10.0.0.0/8 IANA-designated private-only subnet.

Screenshot showing virtual TAP adapter enabled on the Windows client

Figure 3: Screenshot showing virtual TAP adapter enabled on the Windows client

Screenshot showing OpenVPN running on an Android phone

Figure 4: Screenshot showing OpenVPN running on an Android phone

The same profile was later transferred to an Android phone with the OpenVPN app installed. The phone was connected to the network setup over WiFi. Like with the Windows PC, the OpenVPN connection allowed all traffic to be piped through into the secure area of the network, giving them more access that what they could get from the optional or external areas.

IKEv2 on WatchGuard

Diagram of network setup over IKEv2

Figure 5: Diagram of network setup over IKEv2

The WatchGuard box supports IKEv2 VPN and the box has hardware support for the encryption and authentication algorithms [18]. This leads to significant speed ups and allows many more simultaneous connections than would otherwise be supported if done in purely in software.

The management software has a built-in wizard for configuring the IKEv2 VPN for mobile users; that is, a site-to-point connection. Watchguard only offers customer support for users using full tunnelling [11:2]; configurations where all traffic, not just traffic belonging to the local and secured network, goes through the tunnel. This allows the network to monitor and block any traffic (e.g. known phishing sites) but also leads to greater latency and greater resource usage when compared to split tunnelling.

Screenshot showing WatchGuard IKEv2 Phase 1 setting Screenshot showing WatchGuard IKEv2 Phase 2 setting

Figure 6: Screenshots showing phase 1 and phase 2 settings

The software has support for both classic finite-field and elliptic curve Diffie-Hellman (DH) key exchanges in both phase 1 and phase 2. However, it should be noted that some of the default phase 1 transforms are weak—for example, SHA1-3DES with DH Group2 uses the outdated and unsafe DES cipher and also uses 1024-bit finite-field DH when 2048 and above, or 224-bit elliptic curve and above should be used [12:1]. Phase 2 also supports perfect forward secrecy [13:1], creating new key independently of the DH key created in phase 1 at the beginning of the connection and during each periodic rekey.

The server address; the address that client devices point to when the VPN is set up, is set to the IP of the external interface, and Firefox-DB is set up to be the authentication server. In a real setup, Active Directory would most likely be used over the RADIUS protocol.

Like with OpenVPN, a pool of IP private addresses to assign to the client devices is required. In this case, the IP range 192.168.114.0/24 was used, meaning that under this configuration, up to 254 devices can connected simultaneously. However, hardware and licencing limits are likely to be the real limiting factors. For example, the XTM-33 used in the lab has several licencing packs going from five to 50 users, with the five-user licence costing 200 dollars [14:1].

Some firewall rules must also be set up. ISAKMP, a part of IKE, is the protocol responsible for the management of the security associations (SA). The ISAKMP pinhole rule allows external devices to communicate with the Firebox, with UDP port 500 being used for the initial connection setup and ESP being used to send traffic. However, network address translation—NAT may be used by the client network, preventing any non-TCP and -UDP protocols from being used. Hence, it can fallback to tunnelling the ESP packets over UDP port 4500.

One additional issue is that the client-side network may block these ports; this is one of the advantages of OpenVPN, which can use standard ports used by HTTPS traffic and hence are less likely to be blocked. However, it is important to note that even this can be blocked through the use of deep packet inspection as the protocol as it makes no attempts to disguise itself as normal HTTPS traffic.

Another rule, ‘Allow Ray,’ was also added. Ray was the single user that was set up in Firebox-DB, and this allows traffic from devices authenticated as that user, including traffic from and to the trusted area. In a proper setup, groups would be created and firewall rules would allow groups, rather than individual users, permission to access specific resources.

Screenshot showing firewall rules

Figure 7: Screenshot showing firewall rules

The setup wizard creates a compressed file containing the required certificates, which was transferred over to a machine connected to the untrusted interface over USB.

Screenshot showing CA Root certificate self-signed by the WatchGuard device

Figure 8: Screenshot showing CA Root certificate self-signed by the WatchGuard device

Inside the folder, we see a self-signed CA Root security certificate, which is used during the IKEv2 setup to create symmetric keys. The key was added to the trust store, and a IKEv2 connection was set up in Windows Settings, using the IP address of the server and the Ray user’s username and password—unlike with OpenVPN setup above which stored secrets in a configuration file (optionally secured by a password), IKEv2 only works with user accounts. Hence, the user must enter their username and password, with RADIUS (or in this case, Firebox-DB) being used for authentication.

If 2FA is being used, it will likely require more configuration and the installation of additional software on user devices as there is no standardized way of requesting for and sending the 2FA token. For example, if AuthPoint is used alongside Active Directory, WatchGuard supports 2FA by sending a push notification to the user’s phone that they must accept [15:1]. Hence, it allows the connecting device to use the OS’s native VPN configuration but also prevents them from using more secure factors such as hardware tokens, and requires the user’s phone to be connected to the network. Although this is a more complex and costly procedure, it greatly reduces the risk of VPNs being used as an entry point by attackers, and will cost far less than the financial and reputational damage attackers could achieve with access to internal networks.

Screenshot of Wireshark capture showing ISAKMP running to establish the IKEv2 connection

Figure 9: Screenshot of Wireshark capture showing ISAKMP running to establish the IKEv2 connection

Figure 9 shows this initial handshake being executed. Note that it is communicating directly to the WatchGuard’s external interface, which the IKEv2 subsystem is set to run through. After the handshake, we can see an ESP packet flowing—this is the first data packet transmitted after the tunnel has been created.

Screenshot showing network configuration, before and after connecting to the VPN

Figure 10: Screenshot showing network configuration, before and after connecting to the VPN

Figure 10 shows how the connection has created a new network adapter (PPP adapter Connect via IKEv2) with the IP address of 192.168.114.3, which is part the pool of private IPs configured previously.

However, Windows now has multiple network interfaces it can use, so we must configure the device to route all traffic through the IKEv2 tunnel. To do this, the command:

route add 0.0.0.0 mask 0.0.0.0 192.168.114.3 metric 35

is used. The /0 mask matches all IP addresses and the metric of 35 is the lowest metric in the routing table. Hence, Windows will now send all traffic through the VPN connection. Note that in Figure 9, the source IP address is still the initial IP address; the new network adapter is a virtual one; traffic flows through it from the perspective of the higher layers of the network stack, but traffic ultimately flows through the real ethernet adapter.

Context

In this time of COVID and with remote work becoming increasingly popular, VPNs are frequently being used to allow workers to access internal resources remotely. However, this also makes it an attractive target for attackers looking to breach internal networks from half way across the world (and in countries with no extradition treaty with the country the target is located).

For example, the hugely damaging Colonial Pipeline hack from 2021 [16:1] first accessed the network through the VPN using stolen credentials. In the OpenVPN lab, the configuration file contains the secrets necessary to connect to the network but in most enterprise setups, including the IKEv2 lab, the user must enter credentials authenticate themselves. Because Colonial Pipelines did not use two-factor authentication, the credentials alone were enough to give the attackers an entry point into their internal network, forcing the company to shut down the pipeline for six days to prevent further damage.

More recently, the disastrous Okta breach began with the Lapsus$ group accessing a VPN gateway and led to over 350 of their customers being affected [19]. Keep in mind that the company’s entire business is built on providing a secure identity management solution for enterprises… and they got hacked.

In addition, the VPN servers themselves can also have software vulnerabilities. For example, the Fortinet SSL VPN servers had a vulnerability discovered in 2018 that allowed attackers to download login credentials—in 2019, an hacker publicly leaked 500,000 VPN credentials [20], but it is likely that many more were captured privately. Although patches were released, many organizations did not apply this for several months, leaving them vulnerable to their credentials being stolen and any credentials that were already stolen from being used to enter the network.

These incidents make it clear that VPNs are large opportunity for attackers and hence, networks should ensure their VPNs are secure by hardening their configuration, keeping up-to-date with patches, and where applicable, use two-factor authentication to dramatically increase the difficulty of attackers using stolen credentials to access the internal network. Note that this alone is not a guarantee that attackers will not use VPNs; many operators, including Lapsus$ [21] may pay for insiders to provide access to VPNs. Hence, active monitoring of the network is a must, ensuring that any attackers that manage to get into the network can be detected quickly.

Conclusions

VPNs are complex systems which allows two physically separated networks or devices to be linked over an insecure network. This could be connecting two office networks together in a site-to-site connection or giving a single device remote access to a network in a point-to-site connection. The lab looked at two modern solutions, OpenVPN and IKEv2, running on a stripped-down Linux machine and a WatchGuard all-in-one networking box, and had a brief overview of some of the configuration options available for each. Although having the OS support the protocol can reduce the deployment complexity and support burden, the lack of good 2FA support means that deployments will likely require additional client software.

Additionally, the choice may be dependent on the current networking setup. If the network already uses an integrated networking solution like the WatchGuard XTM series, then using the provided option will allow the VPN configuration to be integrated with the rest of the network setup, reducing cost and the chance of misconfiguration. If this is not the case, choosing to go with vendors the staff has experience with or with which the company already has brought hardware is recommended, as it is likely to integrate better with the existing network. Additionally, if the required VPN capacity exceeds what the current installation can provide, having a dedicated VPN server may be more suitable and provide flexibility if more capacity is required in the future, such as in the event of a global pandemic.

VPNs however, are also a large area of attack as it allows remote access to internal networks without requiring the attacker to be physically present, or even in the country where the victim is located. Hence, administrators should look at implementing two-factor authentication for any staff logging into the VPN, minimize user permissions in the network, and actively monitor the network for any signs of intrusion, detecting and shutting down attackers to limit the amount of financial and reputational damage they can cause.

Lab 04—Smart Cards

Abstract

Mifare Classic is one of the most dominant forms of proximity cards in the world, with hundreds of organizations using them for transport ticketing systems and building access passes. This report makes a quick overview of the usage and structure of Mifare Classic before looking at its security, which we find is completely and irreversibly broken.

Since 2009, researchers have publicly disclosed practical attacks that allow attackers to extract keys and make full clones of any Mifare Classic card with just a few seconds of physical proximity. With this information, attackers can ride on public transport for free or gain access to secure buildings.

No organizations should consider using this broken and outdated protocol for any application where security is a concern, and organizations currently using these systems should look to migrate to solutions such as Mifare DESFire. Although the cards are more expensive and upgrading the readers and backend systems will require significant organizational resources, Mifare Classic provides minimal security against any dedicated attacker, whereas there are currently no known practical attacks against DESFire.

Security-conscious organizations should also look at pairing smart cards with a second factor, such as biometrics or a PIN code. Although this will also have significant costs, the use of two-factor authentication (2FA) prevents any vulnerabilities in the smart card protocol from leading to a full breakdown of the security barrier. It should be noted that although DESFire is seen as secure today, it took over a decade until the vulnerabilities in Mifare Classic were discovered and disclosed publicly. Additionally, 2FA also prevents attackers from simply stealing cards to gain access to secured areas—people are fallible and may not notice its disappearance for a while or not immediately contact security when they realize this.

Introduction

Smartcards are cards containing ICs which can be powered by an electromagnetic field generated by a compatible reader. This can then power a low-power chip which can actively communicate with the reader, transferring data stored on the card and even receive write from the reader. Today, these are used everywhere, including in passports, credit cards, bus passes, and building passes.

ISO14433 is an international standard which defines the physical, radio, and transmission protocols used in contactless proximity cards. One of the most dominant implementations of this is the Mifare Classic system that was first introduced in 1994, with over 200 million cards in circulation as of 2008 [1:3]. This report describes the lab in which we interfaced with these cards in a toy environment and then follows up with a detailed analysis of its security.

Experimental Results

Mifare Classic cards are very simple, being essentially just a kilobyte (or four) of memory alongside some simple logic for authenticating and encrypting communications with a reader. More advanced versions such as Mifare DESFire or Mifare SAM contain a full microprocessor supporting standard ciphers such as DES and AES, although this security comes with a higher unit cost.

This lab interacts with a few Mifare Classic 1K cards using default encryption keys, using a NXP PN53x-based card reader to read and write to the cards. On the software side, we have a Kali Linux VM and a few simple Python scripts wrapping around the libnfc [2:3] library. The Python scripts only support reading and writing the entire card, and all blocks must use the same key.

Table 1: Diagram of Mifare Classic 1K memory layout

Sector No. \ Block No. 0 1 2 3 - Sector Trailer
0 Block 0 - Manufacturer Block Block 1 Block 2 Block 3 – sector 0 trailer
1 <= n <= 14 4n 4n + 1 4n + 2 4n + 3 – sector n trailer
15 60 61 62 Block 63 - sector 15 trailer

The 1K card is divided into 16 64-byte sectors, each of which contains 4 blocks. Block 0 is read-only (at least for officially manufactured cards) and contains a 4-byte NUID or 7-byte UID [3:3], alongside other manufacturer data.

The last block of each sector is the sector trailer block which stores one (or two) 48-bit access keys, as well as access bits. When both keys are used, key B always has greater permissions than key A. Every sector has its own key, and every block in the sector can have different access permissions. Note that the keys do not encrypt the data; rather, the reader must prove to the card that they possess the key before the card will send the block data over an encrypted channel.

Table 2: Diagram showing byte layout of sector trailer blocks on Mifare Classic. Note that when sector trailer sectors are read, the key bytes are zeroed out [3:4]

Bytes 0-5 Bytes 6-8 Byte 9 Bytes 10-15
Key A Access Bits User Data Key B OR User Data

Byte 9 is considered ‘part’ of the access bits area in terms of access permissions. If bytes 9 to 15 are used for data, then this means a total of 16 sectors * (3 blocks * 16 bytes/block + 1 block * 7 bytes/block) - 16 bytes = 864 bytes are available for user data. However, there is no way of giving write access to these bits without also giving the key write access to the rest of the sector [4:5], which may make this unsuitable in many circumstances. If sector trailers are not used for data, the data capacity decreases to 752 bytes.

Each block of the sector has separate access bits. Each has three logical bits, allowing eight configurations with varying access and key combinations. The bits are stored twice—once inverted and once normally. If the card detects an invalid format during a read operation, that sector becomes permanently bricked. As there is no memory protection, this can happen rather easily.

Additionally, under five of the eight bit combinations, neither key can update the access bits, and under four of the eight bit combinations, neither key can update the keys. Although this may be useful in specific circumstances, for the purposes of the lab it was definitely not something we wished to do.

With four blocks each having three bits stored in duplicate, it comes to a total of 24 bits, 3 bytes or 6 hexadecimal characters. Endianness, as well as the interleaving and inversion of bits makes manually generating a valid bit sequence a nightmare. As an incorrect sequence can lead to the sector being bricked, we used a GUI tool to ensure generated the correct string.

Screenshot showing Mifare Access Conditions Calculator app

Figure 1: Screenshot showing Mifare Access Conditions Calculator app

The non-trailer blocks support two types of data—read/write blocks and value blocks. Read/write blocks, as the name suggests, support only read and write operations, but can store a full 16 bytes of data. In this lab, data was formatted as read/write blocks—the Python scripts cannot handle the additional operations available to value blocks, nor can it even support different keys between blocks.

Value blocks support additional operations such as restore, transfer, increment, and decrement. In this case, only a 4-byte signed integer can be stored, with the data being stored in triplicate alongside a 1-byte address stored in quadruplicate.

The additional operations are useful in cases where you want to only allow decrementing. For example, the access bits for a block could be set to 110 which allows key B full permissions but only allows key A to read and decrement the value [17:1]. With this setup, key A could be used, for example, in bus readers to decrease account balance, while key B would be used less frequently in a more secure environment to top up cards. This should, in theory, prevent an attacker from topping up their card even if they gain access to the card reader on the bus.

The lab used a toy scenario in which Ray’s Bullet Trains Ltd. is storing account balance on Mifare Classic cards using default keys. The account balance is stored in two bytes on block 4, with the first byte representing the integer part and the second the fractional part. These bits were set to FF 63, or $255.99. The key was set to one of the default keys, AA B CC DD EE FF, and the access bits were kept as FF 07 80, which gives full read and write access to all blocks for both keys.

Screenshot showing contents of modified dump

Figure 2: Screenshot showing contents of modified dump

Screenshot showing card contents being updated

Figure 3: Screenshot showing card contents being updated

Screenshot showing card balance being read by the 'Ray's Bullet Trains' program

Figure 4: Card balance being read by the ‘Ray’s Bullet Trains’ program

Later in the lab, cards were swapped with another group, and ‘cracked’ using a small list of five standard keys. The crack.py script would try the keys one by one in a tiny dictionary attack for both the A and B keys. With the key determined, we could then go through and update the balance in the card to EF 73, or $239.115, with the 16 cent overflow being ‘transferred’ to Ray’s account.

Screenshot showing process of 'cracking' card from another group

Figure 5: ‘cracking’ card from another group

Screenshot showing card balance after update

Figure 6: Screenshot of balance after update

It should be noted that much larger dictionaries are available which contain default and cracked keys—for example, the Mifare Classic Tool app’s GitHub repository contains a list of over 1,000 keys [5:4]. If the key used in the card was unique, a naïve exhaustive search would take over 40,000 years due to the communication delay between each attempt [1:4]. However, as will be covered below, much, much more efficient attacks are available.

Security

The Mifare cards have a three-pass authentication protocol, in which both the reader and the card must prove that they have knowledge of the key. In broad strokes:

However, there are several major issues with the implementation that make the security useless to any knowledgeable attacker.

ISO14443 is split into four sections, with Mifare Classic only implementing the first three and opting to use custom and flawed secure transmission layer [7:3]. One of the issues is in the parity bytes used for error correction are calculated over the plaintext, but sent encrypted. Another issue is that if the parity bits are correct (which will occur once every 256 times if the message is picked randomly) but the authentication fails, a 4-bit encrypted error code (whose plaintext is known) gets sent [7:4]. One additional issue is that the same keystream bit is used to encrypt the parity bit and the first bit of the next byte of data [7:5].

The PRNG, a linear-feedback shift register that makes up the core of the Crypto-1 cipher, is also an area of weakness. The PRNG state and the nonce that is chosen by the tag is determined by the time the tag has been powered on for. As the reader provides the electromagnetic field that powers the tag, an attacker can control this duration to get the same nonce each time. This allows an attack where the attacker can iteratively determine the keystream. Additionally, the PRNG has a 32-bit length but only a 16-bit state [7:6]. [8:3] makes a scathing analysis of this issue, saying that:

…This simply means that a large number of logical gates during the hardware computation of Crypto-1 are wasted. Identical values are computed several times. This seems to contradict the idea that Crypto-1 is weak because it was designed by amateurs, or that it is weak to make the chip as inexpensive as possible. One can rather get the impression, that this cipher was rather carefully designed to look much more secure than it actually is, maybe hoping that nobody would notice.

If the attacker knows the key for one sector (with [9:3] finding that most cards had at least one sector with a default key), the attacker can authenticate with that sector and then carry out a nested authentication. Unlike in a normal authentication, the nonce is encrypted with the existing keystream. The attacker can control the timing for this second authentication and hence, predict the nonce. This, along with other weaknesses, allows the attacker to determine 32 bits of the 48 bit key [7:7]. The remaining entropy – 65,536 combinations – can be brute forced in less than a second to determine the correct key.

Even if all keys are unknown, there is another attack described in [8:4] which allows an attacker to determine the key for any sector in about 10 seconds using around 300 authentication attempts. Once this is done, the nested attack can be used to crack the other sectors.

Hence, an attacker with physical proximity to any Mifare Classic card can make a full clone of it in 10 seconds or so—for example, an attacker could sit next to the victim on a bus/subway or simply have a quick chat with them with their bag or sleeve near their victim’s card. Although sector 0 – the manufacturer block – is not writable, many unlicenced Mifare clones allow this, and Mifare cards can also be emulated by relatively cheap devices [9:4]. With these clones, attackers can impersonate valid cards, allowing them to get free bus/subway rides and cause financial losses for transport companies, as was feared with London’s Oyster cards when the vulnerabilities were first released.

Additionally and likely more importantly, cloned cards can be used impersonate employees, allowing attackers to get physical access to offices and secured areas to steal intellectual property and gain a foothold into internal systems for further theft.

Hence, Mifare Classic is completely and irreversibly broken, and absolutely no one should be looking to begin using Mifare Classic for anything remotely security or financially sensitive. After the security issues were disclosed in 2008, even NXP said that they “do not recommend the use of Mifare Classic for new installations” [10:5]. Although hardened versions of Mifare Classic are available, these too were broken in 2015 by [11:3].

For any applications requiring security, more costly but much (much) more secure alternatives such as Mifare DESFire, which contain full microprocessors supporting DES and AES, are available. However, organizations with high security requirements should also consider using two factor authentication (2FA), such as PIN codes or biometrics, alongside the cards, protecting against vulnerabilities in the protocol and cards being stolen.

Although DESFire appears to be secure today, it is possible that vulnerabilities exist and may be known by potential threat actors today. The issues described above in Mifare Classic, were discovered and publicly disclosed by researchers more than ten years after release, but it is likely that some actors, such as nation-states, had the resources to find these vulnerabilities years before. Additionally (and entering tinfoil hat territory), it is possible that state actors were even responsible for some of these ‘bugs.’ By relying on 2FA, attackers must have exploits for two dissimilar systems, thereby increasing the difficulty of bypassing security.

Going back to lower-security applications, organizations with existing Mifare Classic setups may be stuck with this setup for a while due to budget concerns—upgrading means not just reissuing all cards, but also upgrading all the readers and the systems interfacing with the cards, which is a significant and expensive undertaking.

Although cards can be put in a read-only or decrement-only state to prevent state restoration attacks (e.g. paying for a subway ride which decrements the balance, then restoring the card to a previous state) and preventing the trailer from being modified, attackers can simply buy blank cards in bulk and make a copy of the card every time they use it, or simply use an emulator. The only way of detecting this is through finding discrepancies with the main database whenever the card reader’s state is synchronized with the database. However, given the recent rise in IoT and ubiquitous networking, it may be possible to make all readers fully online, allowing the card balance to be looked up through a central database.

Unfortunately, this will not prevent attackers from simply cloning other people’s cards. This can be detected, but not fully stopped. For example, [4:6] proposes having a monotonically increasing counter, the reader incrementing the value on every read and synchronizing the state to a central database. If the counter state is repeated, this can be detected and the card (both cards—there is no practical way to tell which one is the ‘real’ one) can be blacklisted. The counter-UID pair should be authenticated with an HMAC, thereby preventing an attacker from guessing how many times the victim has used the card since the cloning and updating the card value accordingly.

Conclusions

This report looked at the implementation and security of Mifare Classic and finds it to be completely broken. Attacks have been publicly disclosed for over a decade allow attackers to crack keys for any and all sectors and extract the full contents of the card after just a few seconds of physical proximity. With this information, attacks can make state restoration attacks, causing financial damage to transport companies, and allow attackers to clone cards and access secured buildings.

There is no way of preventing these attacks; organizations that continue to use Mifare Classic for whatever reason can only mitigate the consequences. For example, backend checks could be used to find and blacklist cards where there are discrepancies between the card state and the database.

Wherever possible, organizations should move to more secure solutions such as Mifare DESFire. This standard currently has no publicly disclosed, practical attacks, giving organizations some confidence in their security. However, this security is useless if an attacker simply steals the cards and hence, security-conscious organizations should look at pairing proximity cards with a second factor such as biometrics or a PIN code (the latter being used by UC for building access during off-hours). The use of a second factor prevents card theft alone from granting access and provides organizations with a security buffer if practical attacks against DESFire are found today or in the future.

  1. G. d. K. Gans, J.-H. Hoepman and F. D. Garcia, “A Practical Attack on the MIFARE Classic,” in CARDIS: International Conference on Smart Card Research and Advanced Applications, London, UK, 2008. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  2. nfc-tools, “nfctools,” [Online]. Available: https://github.com/nfc-tools/libnfc. [Accessed 2022-04-04]. ↩︎ ↩︎ ↩︎ ↩︎

  3. NXP Semiconductors, “MF1S50YYX_V1 Data Sheet Rev. 3.2,” 2018-03-23. [Online]. Available: https://www.nxp.com/docs/en/data-sheet/MF1S50YYX_V1.pdf. [Accessed 2022-04-02]. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  4. W. Teepe, “Making the Best of Mifare Classic,” 2008-10-06. [Online]. Available: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.511.7146&rep=rep1&type=pdf. [Accessed 2022-04-06]. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  5. G. Klostermeier, “extended-std.keys,” 2022-02-17. [Online]. Available: https://github.com/ikarus23/MifareClassicTool/blob/master/Mifare Classic Tool/app/src/main/assets/key-files/extended-std.keys. [Accessed 2022-04-06]. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  6. P. Lupták, “Mifare Classic analysis in Czech Republic / Slovakia,” Nethemba, [Online]. Available: https://nethemba.com/resources/mifare-classic-slides.pdf. [Accessed 2022-04-02]. ↩︎ ↩︎ ↩︎ ↩︎

  7. F. D. Garcia, P. van Rossum, R. Verdult and R. W. Schreur, “Wirelessly Pickpocketing a Mifare Classic Card,” Radboud University Nijmegen, 2009. [Online]. Available: https://www.cs.ru.nl/~flaviog/publications/Pickpocketing.Mifare.pdf. [Accessed 2022-04-06]. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  8. N. Courtois, “THE DARK SIDE OF SECURITY BY OBSCURITY,” University College London, 2009. [Online]. Available: https://eprint.iacr.org/2009/137.pdf. [Accessed 2022-04-03]. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  9. P. Lupták, “Nethemba Public Security Research Projects (2007-2015),” Nethemba, 2016-05-17. [Online]. Available: https://www.nethemba.com/cs/nethemba-public-security-research-projects-2007-2015/. [Accessed 2022-04-05]. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  10. P. Price, “Oyster card hack details revealed,” BBC Click, 2008-10-06. [Online]. Available: http://news.bbc.co.uk/1/hi/programmes/click_online/7655292.stm. [Accessed 2020-04-06]. ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  11. C. Meijer and R. Verdult, “Ciphertext-only Cryptanalysis on Hardened Mifare Classic Cards,” Radboud University, 2008. [Online]. Available: http://cs.ru.nl/~rverdult/Ciphertext-only_Cryptanalysis_on_Hardened_Mifare_Classic_Cards-CCS_2015.pdf. [Accessed 2022-04-07]. ↩︎ ↩︎ ↩︎ ↩︎

  12. W. Teepe, “Making the Best of Mifare Classic Update,” 2008-12-11. [Online]. Available: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.618.6083&rep=rep1&type=pdf. [Accessed 2022-04-04]. ↩︎ ↩︎ ↩︎

  13. WatchGuard, “Configure Phase 2 Settings,” 2022. [Online]. Available: https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/bovpn/manual/phase_2_config_settings_c.html. [Accessed 2022-04-04]. ↩︎ ↩︎

  14. WatchGuard, “WatchGuard XTM 33 Series Next-Generation Firewall,” 2021. [Online]. Available: https://www.guardsite.com/XTM-33.asp. [Accessed 2022-04-06]. ↩︎ ↩︎

  15. WatchGuard, “Firebox Mobile VPN with IKEv2 Integration with AuthPoint for Active Directory Users,” 2022. [Online]. Available: https://www.watchguard.com/help/docs/help-center/en-US/Content/Integration-Guides/AuthPoint/firebox-ikev2-vpn-radius_authpoint.html. [Accessed 2022-04-04]. ↩︎ ↩︎

  16. W. Turton and K. Mehrotra, “Hackers Breached Colonial Pipeline Using Compromised Password,” Bloomberg, 2021-06-05. [Online]. Available: https://www.bloomberg.com/news/articles/2021-06-04/hackers-breached-colonial-pipeline-using-compromised-password. [Accessed 2022-04-03]. ↩︎ ↩︎

  17. Technically, a decrement command saves the result to a temporary register, after which a transfer command can be used to update the block. However, if there are other value blocks in the same sector, the values can be transferred between blocks. This could be detected if each block in the sector has a different address; however, if those blocks have write access using the same key, the address could be modified before doing the transfer, making this undetectable [12:2]. Hence, care must be taken to ensure that the same key cannot be used to restore/transfer from other blocks in the same sector. ↩︎ ↩︎

  18. Some older models [22] do not support SHA-2 hardware cryptographic acceleration ↩︎

  19. Z. Whittaker, “Lapsus$ found a spreadsheet of accounts as they breached Okta, documents show,” TechCrunch, 2022-03-29. [Online]. Available: https://techcrunch.com/2022/03/28/lapsus-passwords-okta-breach/. [Accessed 2022-04-20]. ↩︎

  20. P. Arntz, “500,000 Fortinet VPN credentials exposed: Turn off, patch, reset passwords,” Malwarebytes, 2021-09-09. [Online]. Available: https://blog.malwarebytes.com/exploits-and-vulnerabilities/2021/09/500000-fortinet-vpn-credentials-exposed-turn-off-patch-reset-passwords/. [Accessed 2022-04-03]. ↩︎

  21. P. Paganini, “Lapsus$ Ransomware Group is hiring, it announced recruitment of insiders,” Security Affairs, 2022-03-11. [Online]. Available: https://securityaffairs.co/wordpress/128912/cyber-crime/lapsus-ransomware-is-hiring.html. [Accessed 2022-04-02]. ↩︎

  22. Watchguard, “About IPSec Algorithms and Protocols,” 2022. [Online]. Available: https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/mvpn/general/ipsec_algorithms_protocols_c.html. [Accessed 2022-04-04]. ↩︎