Automated Tools For WiFi Cracking

September 30, 2020 by Danie Conradie 8 Comments

Knowing how WiFi networks can be attacked is a big part of properly securing them, and the best way to learn about it is to (legally) run some attacks. [Matt Agius] has been going down the WiFi-cracking rabbit hole, and in the process created Pwnagotchi Tools to automate the actual password cracking part.

The first step in cracking a WiFi network is to record the handshake that gets exchanged when a client connects to an access point. This has been made very simple thanks to Pwnagotchi, which turns a Raspberry Pi into an automated handshake collection tool and Pwnagothi Tools helps to automate the steps that follow. It downloads the handshakes (pcap files) from the pwnagotchi, and converts it to pmkid/hccapx files to use with the hashcat password recovery tool. Hashcat scripts can then be generated for the actual cracking using any of the attacks that [Matt] has compiled. WPA/WPA2 is slow to crack and requires a lot of processing power, so [Matt] also added the option to automatically provision AWS GPU instances to run the cracking task in the cloud. It also keeps track of the status of each of the handshakes being cracked.

As wireless networks and IoT devices become more pervasive, it’s important to know the dangers, and how to protect against them. WiFi and Bluetooth security is probably the easiest to learn about, but other networks are just as vulnerable when an RTL-SDR is used. Another option Flipper Zero, a hacking gadget for Sub-1 GHz networks inspired by Pwnagotchi, which recently hit $4.8 million in its Kickstarter campaign.

Adding WiFi To The Acorn Electron

September 25, 2020 by Maya Posch 9 Comments

In the continuing quest by countless hobbyists to allow every 1980s 8-bit home computer to experience the joys of an online experience that doesn’t involve a 9600 baud modem, [Roland Leurs] has created a cartridge-based module for the Acorn Electron that adds WiFi, which he showed off at the virtual ABug conference in September 2020.

The Acorn Electron is a Synertek 6502-based computer that was released in the UK in August of 1983. It’s a budget version of the well-known BBC Micro educational/home computer, with 32 kB of RAM and featuring BBC BASIC v2 in its ROM. [Roland]’s ElkWiFi card slots into an available cartridge slot, after which the onboard ESP8266 (ESP-1 module) can be enabled and used as a WiFi modem.

Acorn Electron with Plus 1 expansion, ElkWiFi and additional expansion card inserted.

The board features the Exar ST16C2552CJ dual UART chip, one channel of which connects to the ESP-1 module, with the other channel used as an uncommitted UART header. The control logic is implemented in VHDL and flashed to the onboard Xilinx CPLD, and a 128 kB RAM module is used as WiFi data buffer.

Although a definite niche product, reading through the forum thread makes one really appreciate the technical complexity and joy once things are beginning to work reliably. It also shows one of the few cases where an ESP-1 module is used for its original purpose: as an easy way to add WiFi functionality with full WiFi and TCP stack, without burdening the main CPU.

(Thanks, BaldPower)

ESP8266 Turned Secretive WiFi Probe Request Sniffer

September 20, 2020 by Danie Conradie 21 Comments

When a Wi-Fi device is switched on, it starts spewing out probe requests to try and find a familiar access point. These probe requests contain the device’s MAC address and the SSID of the hotspot it’s looking for, which can potentially be used to identify a specific device and where it’s been. After experimenting with these probe requests, [Amine Mehdi Mansouri] has created OpenMAC, a tiny ESP8266 based sniffer that could be hidden anywhere.

The device consists of an ESP-07S module, a regulator circuit for getting power from a USB-C connector, and a button for power cycling. An external antenna is required for the module, which can be selected based on the size or gain requirements for a specific deployment. [Amine] tested the OpenMAC at a local library (with permission), in combination with a number of his own little Wi-Fi repeaters to expand the reach of the network. All the recorded MAC addresses were logged to a server, where the data can be used for traffic analysis in and around the library, or even for tracking and locating specific devices.

This is nothing new, and is relatively common technique used for gathering information in retail locations, and could be also be used for more nefarious purposes. Newer versions of iOS, Android, and Windows 10 feature MAC address randomization which can limit the ability to track devices in this manner, but it isn’t always activated.

We’ve seen a number of projects that exploit probe requests. FIND-LF can be used for locating devices in your home, and Linger fools probe requests sniffers by replaying previously recorded requests.

ESP32 Hash Monster Fills Pockets With Packets

September 8, 2020 by Tom Nardi 4 Comments

Unless you’re reading this from the middle of the ocean or deep in the forest, it’s a pretty safe bet there’s WiFi packets zipping all around you right now. Capturing them is just a matter of having the right hardware and software, and from there, you can get to work on cracking the key used to encrypt them. While such things can obviously have nefarious connotations, there are certainly legitimate reasons for auditing the strength of the wireless networks in the area.

It might not have the computational horsepower to crack any encryption itself, but the ESP32 M5Stack is more than up to the task of capturing WiFi packets if you install the Hash Monster firmware developed by [G4lile0]. Even if you don’t intend on taking things farther, this project makes finding WiFi access points and grabbing their packets a fascinating diversion with the addition of a few graphs and an animated character (the eponymous monster itself) that feeds on all those invisible 1s and 0s in the air.

There’s some excellent documentation floating around that shows you the start to finish process of popping open a WiFi network with the help of Hash Monster, but that’s only the beginning of what’s possible with this gadget. A quick search uncovers a number of software projects that make use of the specific advantages of the M5Stack compared to more traditional ESP32 boards, namely the built-in screen, buttons, and battery. We’ve even seen it used in a few builds here on Hackaday, such as this DIY thermal camera and custom shipboard computer system.

[Thanks to Manuel for the tip.]

RESQ Hunts For Lost Hikers From The Air

August 12, 2020 by Lewin Day 23 Comments

When lost hiking out in the back country, a cell phone might not seem like the most useful tool. Absent a signal from the cellular network, it’s not possible to make outgoing calls for help. However, carrying your phone may just make it a lot easier for rescuers to find you, and [Eric] is making a tool to do the job.

The handheld version of ResQ features a directional Yagi antenna to help pinpoint the location of the signal.

[Eric]’s project is named ResQ, and aims to find lost hikers by detecting the beacon packets from a cellphone’s WiFi adapter. The project comes in two forms; a handheld unit with a directional Yagi antenna, and a drone-mounted unit that can overfly terrain to scan for signals.

ResQ is built around the ESP8266, which is a cheap and accessible way to build a custom WiFI scanner. Currently, the system is able to detect WiFi devices and log MAC addresses along with timestamps and GPS location data to an SD card to help rescuers locate lost individuals. Future plans involve adding a live downlink to the drone such that any pings can be reported live for rescuers to investigate.

Similar systems exist commercially, primarily working with cell signals rather than WiFi. Costs are prohibitively high for many organisations though, so we can see ResQ filling in gaps as a useful tool to have. We’ve featured other radio gear for search and rescue before, too. Video after the break.

Continue reading “RESQ Hunts For Lost Hikers From The Air” →

Separation Between WiFi And Bluetooth Broken By The Spectra Co-Existence Attack

August 7, 2020 by Pedro Umbelino 5 Comments

This year, at ~~DEF CON 28~~ DEF CON Safe Mode, security researchers [Jiska Classen] and [Francesco Gringoli] gave a talk about inter-chip privilege escalation using wireless coexistence mechanisms. The title is catchy, sure, but what exactly is this about?

To understand this security flaw, or group of security flaws, we first need to know what wireless coexistence mechanisms are. Modern devices can support cellular and non-cellular wireless communications standards at the same time (LTE, WiFi, Bluetooth). Given the desired miniaturization of our devices, the different subsystems that support these communication technologies must reside in very close physical proximity within the device (in-device coexistence). The resulting high level of reciprocal leakage can at times cause considerable interference.

There are several scenarios where interference can occur, the main ones are:

Two radio systems occupy neighboring frequencies and carrier leakage occurs
The harmonics of one transmitter fall on frequencies used by another system
Two radio systems share the same frequencies

To tackle these kind of problems, manufacturers had to implement strategies so that the devices wireless chips can coexist (sometimes even sharing the same antenna) and reduce interference to a minimum. They are called coexistence mechanisms and enable high-performance communication on intersecting frequency bands and thus, they are essential to any modern mobile device. Despite open solutions exist, such as the Mobile Wireless Standards, the manufacturers usually implement proprietary solutions.

Spectra

Spectra is a new attack class demonstrated in this DEF CON talk, which is focused on Broadcom and Cypress WiFi/Bluetooth combo chips. On a combo chip, WiFi and Bluetooth run on separate processing cores and coexistence information is directly exchanged between cores using the Serial Enhanced Coexistence Interface (SECI) and does not go through the underlying operating system.

Spectra class attacks exploit flaws in the interfaces between wireless cores in which one core can achieve denial of service (DoS), information disclosure and even code execution on another core. The reasoning here is, from an attacker perspective, to leverage a Bluetooth subsystem remote code execution (RCE) to perform WiFi RCE and maybe even LTE RCE. Keep in mind that this remote code execution is happening in these CPU core subsystems, and so can be completely invisible to the main device CPU and OS.

Join me below where the talk is embedded and where I will also dig into the denial of service, information disclosure, and code execution topics of the Spectra attack.

Continue reading “Separation Between WiFi And Bluetooth Broken By The Spectra Co-Existence Attack” →

Stop Bad Laws Before They Start

July 25, 2020 by Elliot Williams 88 Comments

With everything else going on this summer, you might be forgiven for not keeping abreast of new proposed regulatory frameworks, but if you’re interested in software-defined radio (SDR) or even reflashing your WiFi router, you should. Right now, there’s a proposal to essentially prevent you from flashing your own firmware/software to any product with a radio in it before the European Commission. This obviously matters to Europeans, but because manufacturers often build hardware to the strictest global requirements, it may impact everyone. What counts as radio equipment? Everything from WiFi routers to wearables, SDR dongles to shortwave radios.

The idea is to prevent rogue reconfigurable radios from talking over each other, and prevent consumers from bricking their routers and radios. Before SDR was the norm, and firmware was king, it was easy for regulators to test some hardware and make sure that it’s compliant, but now that anyone can re-flash firmware, how can they be sure that a radio is conformant? Prevent the user from running their own firmware, naturally. It’s pretty hard for Hackaday to get behind that approach.

The impact assessment sounds more like advertising copy for the proposed ruling than an honest assessment, but you should give it a read because it lets you know where the commission is coming from. Reassuring is that they mention open-source software development explicitly as a good to be preserved, but their “likely social impacts” include “increased security and safety” and they conclude that there are no negative environmental impacts. What do you do when the manufacturer no longer wants to support the device? I have plenty of gear that’s no longer supported by firmware updates that is both more secure and simply not in the landfill because of open-source firmware.

Similarly, “the increased capacity of the EU to autonomously secure its products is also likely to help the citizens to better protect their information-related rights” is from a bizarro world where you can trust Xiaomi’s home-automation firmware to not phone home, but can’t trust an open-source replacement.

Public comment is still open, and isn’t limited to European citizens. As mentioned above, it might affect you even if you’re not in the EU, so feel free to make your voice heard. You have until September, and you’ll be in some great company if you register your complaints. Indeed, reading through the public comments is quite heartening: Universities, researchers, and hackers alike have brought up reasons to steer clear of the proposed approach. We hope that the commission hears us.