Fixing up KA9Q-unix, or "neck deep in 30 year old codebases.."
> Anyhoo, I’ve finally been mucking around with AX.25 packet radio. I’ve been wanting to do this since I was a teenager and found out about its existence, but back in high school and .. well, until a few years ago really .. I didn’t have my amateur radio licence. But, now I do, and I’ve done a bunch of other stuff with a bunch of other radios. The main stumbling block? All my devices are either Apple products or run FreeBSD - and none of them have useful AX.25 stacks. The main stacks of choice these days run on Linux, Windows or are a full hardware TNC.
The Cold War spy technology which we all use
> We present an attack on the encryption key negotiation protocol of Bluetooth BR/EDR. The attack allows a third party, without knowledge of any secret material (such as link and encryption keys), to make two (or more) victims agree on an encryption key with only 1 byte (8 bits) of entropy. Such low entropy enables the attacker to easily brute force the negotiated encryption keys, decrypt the eavesdropped ciphertext, and inject valid encrypted messages (in real-time). The attack is stealthy because the encryption key negotiation is transparent to the Bluetooth users. The attack is standard-compliant because all Bluetooth BR/EDR versions require to support encryption keys with entropy between 1 and 16 bytes and do not secure the key negotiation protocol. As a result, the attacker completely breaks Bluetooth BR/EDR security without being detected. We call our attack Key Negotiation Of Bluetooth (KNOB) attack.
Dragonblood new results
> August 2019 — During our initial disclosure, the Wi-Fi Alliance privately created security recommendations to mitigate our attacks. In these recommendations, they claim that Brainpool curves are safe to use, at least if products securely implement Dragonfly’s quadratic residue test (i.e. it must be implemented without side-channel leaks). However, we found that using Brainpool curves introduces a second class of side-channel leaks in the Dragonfly handshake of WPA3. In other words, even if the advice of the Wi-Fi Alliance is followed, implementations remain at risk of attacks. This demonstrates that implementing Dragonfly and WPA3 without side-channel leaks is surprisingly hard. It also, once again, shows that privately creating security recommendations and standards is at best irresponsible and at worst inept.
That last line.
g2k19 Hackathon Report: Stefan Sperling on Access Points and Ghosts
> This AP was promptly attacked! But with OpenBSD on both AP and client, I now had a full view of the battle field and made our hackroom’s wifi immune to de-auth attacks. I don’t have enough brain juice to come up with a good heuristic for this, so users need to manually cast a de-auth attack immunity spell by setting the new ‘stayauth’ nwflag with ifconfig(8). Note that this flag needs to be set on clients as well as the AP, because a de-auth army will target them separately.
Security Issue with Bluetooth Low Energy (BLE) Titan Security Keys
> Due to a misconfiguration in the Titan Security Keys’ Bluetooth pairing protocols, it is possible for an attacker who is physically close to you at the moment you use your security key -- within approximately 30 feet -- to (a) communicate with your security key, or (b) communicate with the device to which your key is paired.
Bluetooth security is... challenging.
Reverse-engineering Broadcom wireless chipsets
> In this blogpost I provided an account of various activities during my 6 months as an intern at Quarkslab, my project involved understanding the Linux kernel drivers, analyzing Broadcom firmware, reproducing publicly known vulnerabilities, working on an emulator to run portions of firmware, fuzzing and finding 5 vulnerabilities (CVE-2019-8564, CVE-2019-9500, CVE-2019-9501, CVE-2019-9502, CVE-2019-9503). Two of those vulnerabilities are present both in the Linux kernel and firmware of affected Broadcom chips. The most common exploitation scenario leads to a remote denial of service. Although it is technically challenging to achieve, exploitation for remote code execution should not be discarded as the worst case scenario.
Don’t miss the disclosure timeline at the end.
Dragonblood - Analysing WPA3's Dragonfly Handshake
> One of the main advantages of WPA3 is that, thanks to its underlying Dragonfly handshake, it’s near impossible to crack the password of a network. Unfortunately, we found that even with WPA3, an attacker within range of a victim can still recover the password of the network. This allows the adversary to steal sensitive information such as credit cards, password, emails, and so on, when the victim uses no extra layer of protection such as HTTPS. Fortunately, we expect that our work and coordination with the Wi-Fi Alliance will allow vendors to mitigate our attacks before WPA3 becomes widespread.
A brief history of Wi-Fi security protocols from “oh my, that’s bad” to WPA3
> Enjoy our primer on the ups and downs of Wi-Fi protocols since the mid-1990s.
Remotely compromise devices by using bugs in Marvell Avastar Wi-Fi: from zero knowledge to zero-click RCE
> With this research, I’m going to answer the question that has had to be answered for quite a time: to what extent is Marvell WiFi FullMAC SoC (not) secure. Since the wireless devices with the analyzed chip aren’t fully researched by the community yet, they may contain a tremendous volume of unaudited code, which may result in severe security issues swarming devices equipped with WLAN cards.
Counting All Cars
> Pondering the evolution of electronic tolling, the system that doesn’t slow you down even as it charges you to use it. It has roots in the theremin—sorta.
RFID from the great seal bug to your windshield.
CC3000 Smart Config - transmitting SSID and keyphrase
> So let’s start at the start - we have a problem - we want to send two pieces of information, an SSID and the keyphrase, from one party that is already a member of the wifi network to an external party who can monitor all the encrypted wifi traffic but who cannot decrypt it.
> So the solution to our problem is to encode the information in the size of the packets sent (the actual content is irrelevant). The party on the secured network just sends UDP packets with particular lengths to another party on the network. That the other party is not interested in receiving the packets is not important.
I believe this is possible. I am amazed it’s actually done.
noticed a rogue AP on the network
> tracked it down to this water heater in a utility clpset
What's Happening With RFID Blocking Gear?
> There are dozens and dozens of RFID protection products, which claim they can stop evil doers from stealing your identity and essentially ruining all life as we know it. We bought some of these products at random and tested them to see how effective they really are.
Symbolic Execution of Security Protocol Implementations: Handling Cryptographic Primitives
> Traditional symbolic execution engines cannot handle cryptographic primitives, because analyzing them results in complex symbolic expressions that cannot be handled by the SMT solver. We prevent this by simulating their behaviour under the Dolev-Yao model. This enables efficient symbolic execution of security protocols implementations, making it possible to detect common programming mistakes in them. We also show how to detect misuse of cryptographic primitives. That is, we can detect trivial timing side-channels, and we can identify decryption oracles where unauthenticated decrypted data influences the program’s behaviour. We apply our technique on three client-side implementations of WPA2’s 4-way handshake. This uncovered timing side-channels when verifying authentication tags, a denial-of-service attack, a stack-based buffer overflow, and also revealed a non-trivial decryption oracle. We confirmed all vulnerabilities in practice, and discuss them in detail.
Screaming Channels When Electromagnetic Side Channels Meet Radio Transceivers
> Screaming Channels is a project that investigates long-distance side-channel attacks on radio signals emitted by mixed-signal chips. Up to now, our best result is a full key recovery from 10 m (Bluetooth dongle, TinyAES 128, anechoic room). We make our setup and code public so that others can reproduce and improve our results.
Breaking the Bluetooth Pairing: Fixed Coordinate Invalid Curve Attack
> The pairing protocol is the process of connection establishment in Bluetooth. This process supplies the ground for all of the security and privacy features provided by Bluetooth. Failing to secure this process compromises the entire Bluetooth session.
> Our new attack provides a new technique for attacking the Bluetooth pairing protocol by manipulating specific messages, without being detected by the victim devices. Our attack relies on a newly discovered protocol design flaws.
OpenBSD gains Wi-Fi "auto-join"
> In a change which is bound to be welcomed widely, -current has gained “auto-join” for Wi-Fi networks.
Bluetooth and Personal Protection Device Security Analysis
> Looking at the ROAR, Wearsafe and Revolar personal protection devices - commonly used by women for personal safety but increasingly by other segments of the population including protesters, human rights workers, and the like - we discovered a few flaws or “gotchas” involving Bluetooth for the Wearsafe and Revolar (ROAR looked good):
> While it wasn’t nearly as easy to remotely track a Revolar owner, it is still possible to track the owner of either the Revolar or Wearsafe device from a distance via Bluetooth with inexpensive antennas that extend the scanning range.
Understanding Bluetooth Security
> It should be noted that this entire blog post started because I needed to explain LE Privacy in a forthcoming blog post and the “appendix” kept growing until I simply split it off into its own thing.