Security Hacks

1550 Articles

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” →

This Week In Security: Pwn2own, Zoom Zero Day, Clubhouse Data, And An FBI Hacking Spree

April 16, 2021 by 11 Comments

Our first story this week comes courtesy of the Pwn2own contest. For anyone not familiar with it, this event is held twice a year, and features live demonstrations of exploits against up-to-date software. The one exception to this is when a researcher does a coordinated release with the vendor, and the update containing the fix drops just before the event. This time, the event was held virtually, and the attempts are all available on Youtube. There were 23 attacks attempted, and only two were outright failures. There were 5 partial successes and 16 full successes.

One of the interesting demonstrations was a zero-click RCE against Zoom. This was a trio of vulnerabilities chained into a single attack. The only caveat is that the attack must come from an accepted contact. Pwn2Own gives each exploit attempt twenty minutes total, and up to three attempts, each of which can last up to five minutes. Most complex exploits have an element of randomness, and exploits known to work sometimes don’t work every time. The Zoom demonstration didn’t work the first time, and the demonstration team took enough time to reset, they only had enough time for one more try.

BleedingTooth

We first covered BleedingTooth almost exactly six months ago. The details were sparse then, but enough time has gone by to get the full report. BleedingTooth is actually a trio of vulnerabilities, discovered by [Andy Nguyen]. The first is BadVibes, CVE-2020-24490. It’s a lack of a length check in the handling of incoming Bluetooth advertisement packets. This leads to a buffer overflow. The catch here is that the vulnerability is only possible over Bluetooth 5. Continue reading “This Week In Security: Pwn2own, Zoom Zero Day, Clubhouse Data, And An FBI Hacking Spree” →

Portrait Of A Digital Weapon

April 15, 2021 by 3 Comments

Over the years, artists have been creating art depicting weapons of mass destruction, war and human conflict. But the weapons of war, and the theatres of operation are changing in the 21st century. The outcome of many future conflicts will surely depend on digital warriors, huddled over their computer screens, punching on their keyboards and maneuvering joysticks, or using devious methods to infect computers to disable or destroy infrastructure. How does an artist give physical form to an unseen, virtual digital weapon? That is the question which inspired [Mac Pierce] to create his latest Portrait of a Digital Weapon.

[Mac]’s art piece is a physical depiction of a virtual digital weapon, a nation-state cyber attack. When activated, this piece displays the full code of the Stuxnet virus, a worm that partially disabled Iran’s nuclear fuel production facility at Natanz around 2008. Continue reading “Portrait Of A Digital Weapon” →