PSA: Amazon Sidewalk Rolls Out June 8th

May 19, 2021 by Kristina Panos 41 Comments

Whether you own any Amazon surveillance devices or not, we know how much you value your privacy. So consider this your friendly reminder that Amazon Sidewalk is going live in a few weeks, on June 8th. A rather long list of devices have this setting enabled by default, so if you haven’t done so already, here’s how to turn it off.

Don’t know what we’re talking about? Our own Jenny List covered the topic quite concretely a few months back. The idea behind it seems innocent enough on the surface — extend notoriously spotty Wi-Fi connectivity to devices on the outer bounds of the router’s reach, using Bluetooth and LoRa to talk between devices and share bandwidth. Essentially, when Amazon flips the switch in a few weeks, their entire fleet of opt-in-by-default devices will assume a kind of Borg hive-mind in that they’ll be able to share connectivity.

A comprehensive list of Sidewalk devices includes: Ring Floodlight Cam (2019), Ring Spotlight Cam Wired (2019), Ring Spotlight Cam Mount (2019), Echo (3rd Gen), Echo (4th Gen), Echo Dot (3rd Gen), Echo Dot (4th Gen), Echo Dot (3rd Gen) for Kids, Echo Dot (4th Gen) for Kids, Echo Dot with Clock (3rd Gen), Echo Dot with Clock (4th Gen), Echo Plus (1st Gen), Echo Plus (2nd Gen), Echo Show (1st Gen), Echo Show (2nd Gen), Echo Show 5, Echo Show 8, Echo Show 10, Echo Spot, Echo Studio, Echo Input, Echo Flex. — Amazon Sidewalk FAQ

Now this isn’t a private mesh network in your castle, it’s every device in the kingdom. So don’t hesitate, don’t wait, or it will be too late. Grab all your Things and opt-out if you don’t want your doorbell cam or Alexa machine on the party line. If you have the Alexa app, you can allegedly opt out on all your devices at once.

Worried that Alexa is listening to you more often than she lets on? You’re probably right.

This Week In Security: Fragattacks, The Pipeline, Codecov, And IPv6

May 14, 2021 by Jonathan Bennett 26 Comments

Some weeks are slow, and the picking are slim when discussing the latest security news. This was not one of those weeks.

First up is Fragattacks, a set of flaws in wireless security protocols, allowing unauthenticated devices to inject packets into the network, and in some cases, read data back out. The flaws revolve around 802.11’s support for packet aggregation and frame fragmentation. The whitepaper is out, so let’s take a look.

Fragmentation and aggregation are techniques for optimizing wireless connections. Packet aggregation is the inclusion of multiple IP packets in a single wireless frame. When a device is sending many small packets, it’s more efficient to send them all at once, in a single wireless frame. On the other hand, if the wireless signal-to-noise ratio is less than ideal, shorter frames are more likely to arrive intact. To better operate in such an environment, long frames can be split into fragments, and recombined upon receipt.

There are a trio of vulnerabilities that are built-in to the wireless protocols themselves. First up is CVE-2020-24588, the aggregation attack. To put this simply, the aggregation section of a wireless frame header is unauthenticated and unencrypted. How to exploit this weakness isn’t immediately obvious, but the authors have done something clever.

First, for the purposes of explanation, we will assume that there is already a TCP connection established between the victim and an attacker controlled server. This could be as simple as an advertisement being displayed on a visited web page, or an image linked to in an email. We will also assume that the attacker is performing a Man in the Middle attack on the target’s wireless connection. Without the password, this only allows the attacker to pass the wireless frames back and forth unmodified, except for the aggregation header data, as mentioned. The actual attack is to send a special IP packet in the established TCP connection, and then modify the header data on the wireless frame that contains that packet.

When the victim tries to unpack what it believes to be an aggregated frame, the TCP payload is interpreted as a discrete packet, which can be addressed to any IP and port the attacker chooses. To put it more simply, it’s a packet within a packet, and the frame aggregation header is abused to pop the internal packet out onto the protected network. Continue reading “This Week In Security: Fragattacks, The Pipeline, Codecov, And IPv6” →

Apple AirTag Spills Its Secrets

May 10, 2021 by Jenny List 17 Comments

The Apple AirTag is a $29 Bluetooth beacon that sticks onto your stuff and helps you locate it when lost. It’s more than just a beeper though, the idea is that it can be silently spotted by any iDevice — almost like a crowd-sourced mesh network — and its owner alerted of its position wherever they are in the world.

There are so many questions about its privacy implications despite Apple’s reassurances, so naturally it has been of great interest to those who research such things. First among those working on it to gain control of its nRF52832 microcontroller is [Stacksmashing], who used a glitching technique whereby the chip’s internal power supply is interrupted with precise timing, to bypass the internally enabled protection of its debug port. The firmware has been dumped, and of course a tag has been repurposed for the far more worthwhile application of Rickrolling Bluetooth snoopers.

The idea of a global network of every iDevice helping reunite owners with their lost possessions is on the face of it a very interesting one, and Apple are at great pains on the AirTag product page to reassure customers about the system’s security. On one hand this work opens up the AirTag as a slightly expensive way to get an nRF microcontroller for other applications, but the real value will come as the firmware is analysed to see how at the tag itself works.

[Stacksmashing] has appeared on these pages many times before, often in the context of Nintendo hardware. Just one piece of work is the guide to opening up a Nintendo Game and Watch.

A Dutch City Gets A €600,000 Fine For WiFi Tracking

May 8, 2021 by Jenny List 53 Comments

It’s not often that events in our sphere of technology hackers have ramifications for an entire country or even a continent, but there’s a piece of news from the Netherlands (Dutch language, machine translation) that has the potential to do just that.

Enschede is an unremarkable but pleasant city in the east of the country, probably best known to international Hackaday readers as the home of the UTwente webSDR and for British readers as being the first major motorway junction we pass in the Netherlands when returning home from events in Germany. Not the type of place you’d expect to rock a continent, but the news concerns the city’s municipality. They’ve been caught tracking their citizens using WiFi, and since this contravenes Dutch privacy law they’ve been fined €600,000 (about $723,000) by the Netherlands data protection authorities.

The full story of how this came to pass comes from Dave Borghuis (Dutch language, machine translation) of the TkkrLab hackerspace, who first brought the issue to the attention of the municipality in 2017. On his website he has a complete timeline (Dutch, machine translation), and in the article he delves into some of the mechanics of WiFi tracking. He’s at pains to make the point that the objective was always only to cause the WiFi tracking to end, and that the fine comes only as a result of the municipality’s continued intransigence even after being alerted multiple times to their being on the wrong side of privacy law. The city’s response (Dutch, machine translation) is a masterpiece of the PR writer’s art which boils down to their stating that they were only using it to count the density of people across the city.

The events in Enschede are already having a knock-on effect in the rest of the Netherlands as other municipalities race to ensure compliance and turn off any offending trackers, but perhaps more importantly they have the potential to reverberate throughout the entire European Union as well.

This Week In Security: BYOVD, Spectre Vx, More Octal Headaches, And ExifTool

May 7, 2021 by Jonathan Bennett 16 Comments

I learned a new acronym while reading about a set of flaws in the Dell BIOS update system. Because Dell has patched their driver, but hasn’t yet revoked the signing keys from the previous driver version, it is open to a BYOVD attack.

BYOVD, Bring Your Own Vulnerable Driver, is an interesting approach to Windows privilege escalation. 64-bit versions of Windows have a security feature that blocks unsigned kernel drivers from the kernel. The exploit is to load an older, known-vulnerable driver that still has valid signatures into the kernel, and use the old vulnerabilities to exploit the system. The caveat is that even when a driver is signed, it still takes an admin account to load a driver. So what use is the BYOVD attack, when it takes administrative access to pull off?

SentinelLabs is witholding their proof-of-concept, but we can speculate. The particular vulnerable driver module lives in the filesystem at C:\Windows\Temp, a location that is writable by any process. The likely attack is to overwrite the driver on the filesystem, then trigger a reboot to load the older vulnerable version. If you’re still running Windows on your Dell machines, then make sure to go tend to this issue. Continue reading “This Week In Security: BYOVD, Spectre Vx, More Octal Headaches, And ExifTool” →

Putting An Ultra-Tiny Linux Board In A Phone Charger…Eventually

May 6, 2021 by Tom Nardi 67 Comments

Among security professionals, a “drop box” is a device that can be covertly installed at a target location and phone home over the Internet, providing a back door into what might be an otherwise secure network. We’ve seen both commercial and DIY versions of this concept, and as you might expect, one of the main goals is to make the device look as inconspicuous as possible. Which is why [Walker] is hoping to build one into a standard USB wall charger.

This project is still in the early stages, but we like what we see so far. [Walker] aims to make this a 100% free and open source device, starting from the tools he’s using to produce the CAD files all the way up to the firmware the final hardware will run. With none of the currently available single-board computers (SBCs) meeting his list of requirements, the first step is to build a miniature Linux machine that’s got enough processing power to run useful security tools locally. Obviously such a board would be of great interest to the larger hacker and maker community.

The RTL8188CUS is likely to get integrated later on.

So far, [Walker] has decided on his primary components and is working on a larger development board before really going all-in on the miniaturization process. As of right now he’s planning on using the Allwinner A33 to power the board, a sub-$10 USD chipset most commonly seen in low-cost Android tablets.

The A33 boasts a quad-core Cortex-A7 clocked at 1.2 GHz, and offers USB, I2C, and SPI interfaces for expansion. It will be paired with 1 GB of DDR3 RAM, and an SD card to hold the operating system. Naturally a device like this will need WiFi, but until [Walker] can decide on which chip to use, the plan is to just use a USB wireless adapter. The Realtek RTL8188CUS is a strong contender, as the fact that it comes in both USB and module versions should make its eventual integration seamless.

Even if you’re not interested in the idea of hiding security appliances inside of everyday objects, this project is a fascinating glimpse into the process of creating your own custom Linux board. Whether you’re looking to put into a wall wart or a drone, it’s pretty incredible to think we’ve reached the point where an individual can spin up their own miniature SBC.

This Week In Security: Dan Kaminsky, Banned From Kernel Development, Ransomware, And The Pentagon’s IPv4 Addresses

April 30, 2021 by Jonathan Bennett 22 Comments

This week we’re starting off with a somber note, as Dan Kaminsky passed at only 42, of diabetic ketoacidosis. Dan made a name for himself by noticing a weakness in DNS response verification that could allow attackers to poison a target DNS resolver’s cache. A theoretical attack was known, where spoofed DNS responses could collide with requests, but Time-To-Live values meant that DNS requests only go out once per eight hours or so. The breakthrough was realizing that the TTL limitation could be bypassed by requesting bogus subdomains, and aiming the spoofed responses at those requests. This simple technique transformed a theoretical attack that would take 87 years to a very real 10 second attack. Check out the period video after the break, where Dan talked about his efforts in getting the problem fixed.
Continue reading “This Week In Security: Dan Kaminsky, Banned From Kernel Development, Ransomware, And The Pentagon’s IPv4 Addresses” →