Presentation on theme: "Zero-Interaction Authentication and Relay Attacks Cooper Filby Dr. Saxena Babins Shrestha."— Presentation transcript:
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 Labs active this Friday and next
Zero-Interaction Authentication Zero-Interaction Authentication refers to technologies which allow users to gain access to some secure entity without requiring manual interaction after initial setup. Examples: -Key FOBs -BlueProximity
Relay Attack Overview 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 theyre communicating with party B, while party B thinks its communicating with A, even though theyre 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.
NFC Relay Attack
Man-in-the-Middle Attack Comparison 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 doesnt have to know about the contents of the data its forwarding.
BlueProximity BlueProximity is a freely available authentication tool that allows users to unlock their machine when a selected bluetooth enabled device is in proximity. Linux Based Open Source, coded in Python https://lh5.googleusercontent.com/_1QSDkzYY2vc/Tdt_QSOAO6I/AAAA AAAAEj4/_VZ_kitzSDs/blueproximity.jpeg
How BlueProximity Functions The user pairs a device such as their phone with their desktop/laptop thats 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.
How secure is BlueProximity? 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?
Initial Flaws of BlueProximity 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 doesnt verify that the device is actually paired, it just tries to open a socket to that device if its in range.
Initial Flaws of BlueProximity Using the mac address for identification and authentication is flawed. - MAC Address of a device isnt secret, can easily be obtained by scanning Pairing devices offers theoretically offers more security, but its still not ideal, since the application relies on the security of bluetooth and has no further authentication of the client.
Improving BlueProximity 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.
The Intended Attack Now that BlueProximity requires pairing to function, how do we gain access to the target machine? -Relay Attack? 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
Bluetooth 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
Bluetooth Stack 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 oth_protokoly.svg
Bluetooth Pairing 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.
How Secure is Pairing? 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 dont need to know the link keys, since the authentic devices do end up communicating with each other.
How Secure is Pairing? 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
Security of BlueProximity 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.
SimpleAuth 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 isnt considered authentic.
SimpleAuth Based on our knowledge of Symmetric and Asymmetric key algorithms, its pretty clear that this isnt 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. DesktopPhone Challenge Enc k Challenge Dec k (Enc k Challenge) Verify
Cracking SimpleAuth Based on our knowledge of Relay Attacks, theres 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.
MAC Address Spoofing With standard networking devices, MAC Address spoofing is pretty trivial. - On Linux, its 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.
Communicating between attackers 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 Attacker phone, 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
The Relay Attack 1. Desktop sends the challenge to Attacker Phone, which spoofs Phone. 2. Attacker Phone sends the challenge to Attacker Desktop, which spoofs Desktop. 3.Attacker Desktop sends the challenge to Phone. 4. Phone sends the encrypted challenge to Attacker Desktop. 5. Attacker Desktop forwards the encrypted challenge to Attacker Phone. 6. Attacker Phone delivers the encrypted challenge to Desktop. 7. Desktop verifies the encrypted challenge, authenticating Attacker Phone as Phone. Attacker Phone Attacker Desktop Challenge Enc k Challenge DesktopPhone Challenge Enc k Challenge Challenge Enc k Challenge Bluetooth Network Socket
Results 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 Contextual security relies on utilizing context tags, which give some information about the environment of a given electronic device. Potential Context Tags Sources - GPS - Observed wireless traffic - IDs of nearby devices - Ambient audio fingerprints (and other sensor data)
Contextual Security 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 wouldnt correspond to that of the server.
Conclusions Zero-Interaction authentication, while extremely convenient for the end-user, isnt 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.
Conclusions However, even with context tags, Zero-Interaction Authentication still has some flaws: - Client devices could be stolen.