Security Hacks

1552 Articles

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

May 14, 2021 by 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 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 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 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 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 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” →

This Week In Security: NAME:WRECK, Signal Hacks Back, Updates, And More

April 23, 2021 by 9 Comments

NAME:WRECK is a collection of vulnerabilities in DNS implementations, discovered by Forescout and JSOF Research. This body of research can be seen as a continuation of Ripple20 and AMNESIA:33, as it builds on a class of vulnerability discovered in other network stacks, problems with DNS message compression.

Their PDF Whitepaper contains a brief primer on the DNS message format, which is useful for understanding the class of problem. In such a message, a DNS name is encoded with a length-value scheme, with each full name ending in a null byte. So in a DNS Request, Hackaday.com would get represented as [0x08]Hackaday[0x03]com[0x00]. The dots get replaced by these length values, and it makes for an easily parsable format.

Very early on, it was decided that continually repeating the same host names in a DNS message was wasteful of space, so a compression scheme was devised. DNS compression takes advantage of the maximum host/domain length of 63 characters. This max size means that the binary representation of that length value will never contain “1”s in the first two digits. Since it can never be used, length values starting with a binary “11” are used to point to a previously occurring domain name. The 14 bits that follow this two bit flag are known as a compression pointer, and represent a byte offset from the beginning of the message. The DNS message parser pulls the intended value from that location, and then continues parsing.

The problems found were generally based around improper validation. For example, the NetX stack doesn’t check whether the compression pointer points at itself. This scenario leads to a tight infinite loop, a classic DoS attack. Other systems don’t properly validate the location being referenced, leading to data copy past the allocated buffer, leading to remote code execution (RCE). FreeBSD has this issue, but because it’s tied to DHCP packets, the vulnerability can only be exploited by a device on the local network. While looking for message compression issues, they also found a handful of vulnerabilities in DNS response parsing that aren’t directly related to compression. The most notable here being an RCE in Seimens’ Nucleus Net stack. Continue reading “This Week In Security: NAME:WRECK, Signal Hacks Back, Updates, And More” →