Your WiFi Signals Are Revealing Your Location

November 28, 2019 by Sharon Lin 43 Comments

The home may be the hearth, but it’s not going to be a place of safety for too long.

With the abundance of connected devices making their ways into our homes, increasing levels of data may allow for more accurate methods for remote surveillance. By measuring the strength of ambient signals emitted from devices, a site can be remotely monitored for movement. That is to say, WiFi signals may soon pose a physical security vulnerability.

In a study from the University of Chicago and the University of California, Santa Barbara, researchers built on earlier studies where they could use similar techniques to “see through walls” to demonstrate a proof-of-concept for passive listening. Attackers don’t need to transmit signals or break encryptions to gain access to a victim’s location – they just need to listen to the ambient signals coming from connected devices, making it more difficult to track bad actors down.

Typically, connected devices communicate to an access point such as a router rather than directly with the Internet. A person walking near a device can subtly change the signal propagated to the access point, which is picked up by a receiver sniffing the signal. Most building materials do not block WiFi signals from propagating, allowing receivers to be placed inconspicuously in different rooms from the access point.

WiFi sniffers are relatively inexpensive, with models running for less than $20. They’re also small enough to hide in unsuspecting locations – inside backpacks, inside a box – and emit no signal that could be detected by a target. The researchers proposed some methods for safeguarding against the vulnerability: insulating buildings against WiFi leakage (while ensuring that desirable signals, i.e. signals from cell tower are still able to enter) or having access points emit a “cover signal” that mixes signals from connected devices to make it harder to sniff for motion.

While we may not be seeing buildings surrounded by Faraday cages anytime soon, there’s only going to be more attack surfaces to worry about as our devices continue to become connected.

[Thanks to Qes for the tip!]

Raspberry Pi 4 HDMI Is Jamming Its Own WiFi

November 28, 2019 by Bryan Cockfield 87 Comments

Making upgrades to a popular product line might sound like a good idea, but adding bigger/better/faster parts to an existing product can cause unforeseen problems. For example, dropping a more powerful engine in an existing car platform might seem to work at first until people start reporting that the increased torque is bending the frame. In the Raspberry Pi world, it seems that the “upgraded engine” in the Pi 4 is causing the WiFi to stop working under specific circumstances.

[Enrico Zini] noticed this issue and attempted to reproduce exactly what was causing the WiFi to drop out, and after testing various Pi 4 boards, power supplies, operating system version, and a plethora of other variables, the cause was isolated to the screen resolution. Apparently at the 2560×1440 setting using HDMI, the WiFi drops out. While you could think that an SoC might not be able to handle a high resolution, WiFi, and everything else this tiny computer has to do at once. But the actual cause seems to be a little more interesting than a simple system resources issue.

[Mike Walters] on a Twitter post about this issue probed around with a HackRF and discovered a radio frequency issue. It turns out that at this screen resolution, the Pi 4 emits some RF noise which is exactly in the range of WiFi channel 1. It seems that the Pi 4 is acting as a WiFi jammer on itself.

This story is pretty new, so hopefully the Raspberry Pi Foundation is aware of the issue and working on a correction. For now, though, it might be best to run a slightly lower resolution if you’re encountering this problem.

Date Clock Requires (Almost) No Interaction

November 19, 2019 by Bryan Cockfield 8 Comments

A lot of commercial offerings of technology aimed at helping the elderly seem to do a good job on the surface, but anything other than superficial interaction with them tends to be next to impossible for its intended users. Complicated user interfaces and poor design consideration reign in this space. [7402] noticed this and was able to design a better solution for an elderly relative’s digital day planner after a commercial offering he tried couldn’t automatically adjust for Daylight Savings.

Of course, the clock/day planner has a lot going on under the surface that the elderly relative may not be able to use, but the solution to all of that was to make it update over the network. This task [7402] plans to do remotely since the relative does not live anywhere nearby. It is based on a Raspberry Pi connected to a Uniroi screen which automatically dims but can be switched off by means of a large button in the front. The UI shows the date, time, and a number of messages or reminders in large font in order to improve [7402]’s relative’s life.

This is a great idea for anyone with their own elderly relative which might need something like this but won’t want to interact with the technology other than the cursory glance, but the project is also a great illustration of proper design for the intended users. Commercial offerings often had hidden buttons and complicated menus, but this has none of that, much like this well-designed walker for an elderly Swede.

A Tamagotchi For WiFi Cracking

October 16, 2019 by Bryan Cockfield 8 Comments

OK, let’s start this one by saying that it’s useful to know how to break security measures in order to understand how to better defend yourself, and that you shouldn’t break into any network you don’t have access to. That being said, if you want to learn about security and the weaknesses within the WPA standard, there’s no better way to do it than with a tool that mimics the behavior of a Tamagotchi.

Called the pwnagotchi, this package of artificial intelligence looks for information in local WiFi packets that can be used to crack WPA encryption. It’s able to modify itself in order to maximize the amount of useful information it’s able to obtain from whatever environment you happen to place it in. As an interesting design choice, the pwnagotchi behaves like an old Tamagotchi pet would, acting happy when it gets the inputs it needs.

This project is beyond a novelty though and goes deep in the weeds of network security. If you’re at all interested in the ways in which your own networks might be at risk, this might be a tool you can use to learn a little more about the ways of encryption, general security, and AI to boot. Of course, if you’re new to the network security world, make sure the networks you’re using are secured at least a little bit first.

Thanks to [Itay] for the tip!

Ask Hackaday: Does Your Car Need An Internet Killswitch?

October 1, 2019 by Lewin Day 103 Comments

Back in the good old days of carburetors and distributors, the game was all about busting door locks and hotwiring the ignition to boost a car. Technology rose up to combat this, you may remember the immobilizer systems that added a chip to the ignition key without which the vehicle could not be started. But alongside antitheft security advances, modern vehicles gained an array of electronic controls covering everything from the entertainment system to steering and brakes. Combine this with Bluetooth, WiFi, and cellular connectivity — it’s unlikely you can purchase a vehicle today without at least one of these built in — and the attack surface has grown far beyond the physical bounds of bumpers and crumple zones surrounding the driver.

Cyberattackers can now compromise vehicles from the comfort of their own homes. This can range from the mundane, like reading location data from the navigation system to more nefarious exploits capable of putting motorists at risk. It raises the question — what can be done to protect these vehicles from unscrupulous types? How can we give the user ultimate control over who has access to the data network that snakes throughout their vehicle? One possible solution I’m looking at today is the addition of internet killswitches.

Continue reading “Ask Hackaday: Does Your Car Need An Internet Killswitch?” →

Tiny ESP32 Fits Inside USB-A Connector

September 28, 2019 by Bryan Cockfield 24 Comments

The ESP32 was introduced a few years ago as an inexpensive way to outfit various microcontrollers with WiFi or Bluetooth. Since then it has been experimented with and developed on, thanks to its similarities to the ESP8266 and the ability to easily program it. Watching the development of this small chip has truly been fascinating as it continues to grow. Or, in this case, shrink.

The latest development in the ESP32 world comes from [femtoduino] who, as the name suggests, makes very small things. This one is a complete ESP32 which fits inside a USB-A connector. The brains of the projects is the ESP32-D2WD which is a dual core chip with 2 Mb of memory, making it more than capable. In fact, a big part of this project was [femtoduino]’s modifications to MicroPython in order to allow it to run on this chipset. For that alone, it’s cool.

This project is impressive for both reasons, both the size and the addition to the MicroPython libraries. If you need something really really tiny, for whatever reason, you might want to look into picking up one of these. Be careful though, and be sure to get the latest version of the SDK.

ESP8266 And ESP32 WiFi Hacked!

September 5, 2019 by Elliot Williams 48 Comments

[Matheus Garbelini] just came out with three (3!) different WiFi attacks on the popular ESP32/8266 family of chips. He notified Espressif first (thanks!) and they’ve patched around most of the vulnerabilities already, but if you’re running software on any of these chips that’s in a critical environment, you’d better push up new firmware pretty quick.

The first flaw is the simplest, and only effects ESP8266s. While connecting to an access point, the access point sends the ESP8266 an “AKM suite count” field that contains the number of authentication methods that are available for the connection. Because the ESP doesn’t do bounds-checking on this value, a malicious fake access point can send a large number here, probably overflowing a buffer, but definitely crashing the ESP. If you can send an ESP8266 a bogus beacon frame or probe response, you can crash it.

What’s most fun about the beacon frame crasher is that it can be implemented on an ESP8266 as well. Crash-ception! This takes advantage of the ESP’s packet injection mode, which we’ve covered before.

The second and third vulnerabilities exploit bugs in the way the ESP libraries handle the extensible authentication protocol (EAP) which is mostly used in enterprise and higher-security environments. One hack makes the ESP32 or ESP8266 on the EAP-enabled network crash, but the other hack allows for a complete hijacking of the encrypted session.

These EAP hacks are more troubling, and not just because session hijacking is more dangerous than a crash-DOS scenario. The ESP32 codebase has already been patched against them, but the older ESP8266 SDK has not yet. So as of now, if you’re running an ESP8266 on EAP, you’re vulnerable. We have no idea how many ESP8266 devices are out there in EAP networks, but we’d really like to see Espressif patch up this hole anyway.

[Matheus] points out the irony that if you’re using WPA2, you’re actually safer than if you’re unpatched and using the nominally more secure EAP. He also wrote us that if you’re stuck with a bunch of ESP8266s in an EAP environment, you should at least encrypt and sign your data to prevent eavesdropping and/or replay attacks.

Again, because [Matheus] informed Espressif first, most of the bugs are already fixed. It’s even percolated downstream into the Arduino-for-ESP, where it’s just been worked into the latest release a few hours ago. Time for an update. But those crusty old NodeMCU builds that we’ve got running everything in our house? Time for a full recompile.

We’ve always wondered when we’d see the first ESP8266 attacks in the wild, and that day has finally come. Thanks, [Matheus]!