Zero-Interaction Authentication and Relay Attacks. Cooper Filby Dr. Saxena Babins Shrestha. Course Admin. HW4 Posted Covers IPSec (lecture 8 ) and Wireless Security (lecture 9) Due 11am on Dec 02 (Monday) Lab exercise involves capturing WiFi packets using Wireshark
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
Zero-Interaction Authentication and Relay Attacks
Zero-Interaction Authentication refers to technologies which allow users to gain access to some secure entity without requiring manual interaction after initial setup.
A relay attack is a simple attack in which the attacker gains access to a resource by impersonating each party of communication and facilitating communication between them.
In essence, Party A thinks they’re communicating with party B, while party B thinks it’s communicating with A, even though they’re not actually in proximity with one another.
This attack can be used in a variety wireless protocols, including bluetooth, RFID, NFC, and standard wireless networking.
A relay attack is conceptually similar to the Man-in-the-Middle attack, in which a third party controls a connection between two authentic parties.
However, a man-in-the-middle attack usually entails manipulating the data sent between two parties in order to facilitate unauthorized accessed or connections.
A relay attack is a much simpler attack in which authentic data is forwarded between the two parties in order to gain access to some asset. The attacker doesn’t have to know about the contents of the data it’s forwarding.
BlueProximity is a freely available authentication tool that allows users to unlock their machine when a selected bluetooth enabled device is in proximity.
Open Source, coded in Python
The user pairs a device such as their phone with their desktop/laptop that’s running Blueproximity. Then, the BlueProximity process runs in the background, scanning for nearby devices.
When the phone is outside of range, the desktop locks, and when the phone is within a certain range, the desktop unlocks.
Can work without pairing, but the author recommends your device is paired with your desktop/laptop.
Uses the PyBluez libraries for Bluetooth scanning and detection.
If blueproximity is a freely available software that users can install and use, how secure is it?
- On Debian and Ubuntu, you can install it through apt.
Is device pairing alone safe enough to forego password based user authentication on a desktop?
Does BlueProximity utilize any form of client authentication?
By default, BlueProximity relies primarily on the MAC Address of the bluetooth device for device identification and authentication.
- Extremely unsecure when unpaired
- Because of this choice, unlocking a machine is as simple obtaining the mac address of the client device and spoofing it.
- BlueProximity recommends device pairing, but doesn’t verify that the device is actually paired, it just tries to open a socket to that device if it’s in range.
Using the mac address for identification and authentication is flawed.
- MAC Address of a device isn’t secret, can easily be obtained by scanning
Pairing devices offers theoretically offers more security, but it’s still not ideal, since the application relies on the security of bluetooth and has no further authentication of the client.
These initial flaws of BlueProximity show that it is not particularly secure against even basic attacks.
We improved BlueProximity by requiring pairing in order to function, which should prevent the basic spoof attack.
Simple fix: Use the bluez-tools package to verify the device the user wants to use with BlueProximity is paired with the machine.
Now that BlueProximity requires pairing to function, how do we gain access to the target machine?
Since BlueProximity uses no further authentication at the application layer (based on our analysis of the source code), then we need to analyze the security of the Bluetooth Pairing Protocol
Short range communication protocol that relies on secure Personal Area Networks (PANs) for communication.
-Individual devices identified by MAC addresses, much like ethernet networking
Communication devices hop channels during a session, making it more difficult to eavesdrop on communications without specialized equipment.
- Easy to record communications being sent to and from your device using freely available tools
- Kismet, Wireshark, etc
- Promiscuous scanning more difficult with a standard dongle
- Ubertooth Device
A few important Bluetooth Stack Protocols:
LMP - Link Management Protocol, sets up and control link between two devices
SDP - Service Discovery Protocol, used for finding services provided by other devices (like Printing)
L2CAP - Logical Link and Adaptation Protocol, connection oriented protocol
RFCOMM - Data stream protocol that relies on ports. Similar to TCP, uses ‘sockets’
- BlueProximity relies on opening RFCOMM connections
A method of bonding two devices, such that they can securely resume communication after an initial exchange.
There are a few different pairing methods, most of which rely on basic user interaction, such as providing a PIN or verifying numbers that appear on each device.
During the pairing process, the two devices negotiate a Link Key that they can use for future communication.
- When you unpair a device, it forgets that link key, meaning you need repair the device for secure communication
Encryption can be used, although pairing primarily provides device authentication.
While the above method appears to be secure way of authenticating participants, research conducted by Levi et al. proposed a simple method of doing a both a one and two device relay attack to facilitate unauthorized pairing.
- The attackers don’t need to know the link keys, since the authentic devices do end up communicating with each other.
Levi et al. were able to demonstrate their relay attacks using C++ to simulate the Bluetooth protocol.
However, their proposed methods are not effective if encryption is utilized by the bluetooth protocol.
-Pairing generally used to grant access, not to secure communications
In general, relay attacks are highly effective, although they can be detected if communication is timed.
- In Levi et al.’s simulation, pairing when under the relay attack had a noticeable time delay
- Recommend changes to Bluetooth protocols to detect and prevent relay attacks
Given that the Bluetooth Pairing protocol can be beaten by a relay attack, it stands to reason that our improved BlueProximity is not secure as a means of access control to a desktop/laptop.
- Still could be convenient for the average user, but not practical when high security is a necessity.
- While Bluetooth pairing is vulnerable to a relay attack, not everyone would have the equipment to perform it.
Due to this research and the difficulty of accessing the lower level protocols of the Bluetooth Stack, we opted to design a relay attack using a simple authentication program to give a practical relay attack example.
Our basic bluetooth authentication protocol is written in Python, and relies on PyBluez with RFCOMM socket communication to authenticate the mobile client.
- The Desktop and Phone have a preshared Symmetric Key
- The Desktop generates a random challenge, which it then sends to the client.
- The client receives the challenge, encrypts it with AES256 using the preshared symmetric key and sends it back to the server
- The server then decrypts the key and compares it to the original response. If it matches, the client is authenticated, otherwise the client isn’t considered authentic.
Based on our knowledge of Symmetric and Asymmetric key algorithms, it’s pretty clear that this isn’t a very good authentication algorithm.
However, this is just serving as a demonstration, even if we did use a more improved RSA based authentication approach, it would still be vulnerable to a relay attack.
Based on our knowledge of Relay Attacks, there’s two main hurdles we need to overcome in order to successfully implement our relay attack
- MAC Address spoofing
- Passing messages between impersonating devices
We choose to use two attacking devices for simplicity - one device would be much less practical due to the short range nature of bluetooth. With two devices, the phone and desktop could be miles apart and the attack would still work, as long as attacking devices are in close proximity.
With standard networking devices, MAC Address spoofing is pretty trivial.
- On Linux, it’s as simple as specifying it in your networking configuration, such as /etc/network/interfaces on Ubuntu/Debian.
MAC Address spoofing on Bluetooth devices requires specialized tools and devices by specific manufacturers.
- We can change the mac address using the bdaddr tool
- However, this often proves challenging, since not every bluetooth dongle is reprogrammable.
- Of the six or more dongles we had, only 2 were reprogrammable.
Since SimpleAuth relies on prespecified MAC addresses for the client and desktop, impersonation is as easy as spoofing these addresses on the attack devices.
However, once the desktop tries to communicate with Attackerphone, how to get the challenge to the authentic phone?
- Rely on bluetooth for communication between the attackers and the authentic devices
- Rely on network sockets for communication between the attackers
1. Desktop sends the challenge to AttackerPhone, which spoofs Phone.
2. AttackerPhone sends the challenge to AttackerDesktop, which spoofs Desktop.
3.AttackerDesktop sends the challenge to Phone.
4. Phone sends the encrypted challenge to AttackerDesktop.
5. AttackerDesktop forwards the encrypted challenge to AttackerPhone.
6. AttackerPhone delivers the encrypted challenge to Desktop.
7. Desktop verifies the encrypted challenge, authenticating AttackerPhone as Phone.
As we can see, relay attacks are extremely simple and effective attacks on authentication protocols.
How could we prevent such an attack?
- Timing of authentic versus compromised authentications
- Contextual Security
Contextual security relies on utilizing context tags, which give some information about the environment of a given electronic device.
Potential Context Tags Sources
- Observed wireless traffic
- IDs of nearby devices
- Ambient audio fingerprints (and other sensor data)
The above relay attack could easily be beaten if we used context tags between the client and server.
In SimpleAuth, if we utilized context tags in our handshake, then it would be safe against our simple relay attack.
Possible ContextAuth Design:
1. Server sends challenge to client
2. Client creates a context tag, and appends to to the challenge, encrypting both with the preshared key.
3. Server decrypts the message from the client and verifies the challenge and context tag.
Thus, if the client and server are in different locations, a relay attack would fail, as the context tag sent by the client wouldn’t correspond to that of the server.
Zero-Interaction authentication, while extremely convenient for the end-user, isn’t inherently secure.
Relay attacks are simple and effective attacks that can be used against poorly designed Zero-Interaction authentication protocols.
Utilizing context tags in Zero-Interaction authentication protocols can greatly increase the security of such protocols.
However, even with context tags, Zero-Interaction Authentication still has some flaws:
- Client devices could be stolen.