Three ZigBee radios in ESD bags, marked "Zigbee Sniffer", "Router" and "Coordinator".

Crash IoT Devices Through Protocol Fuzzing

April 2, 2024 by 1 Comment

IoT protocols are a relatively unexplored field compared to most PC-exposed protocols – it’s bothersome to need a whole radio setup before you can tinker on something, and often, for low-level experiments, just any radio won’t do. This means there’s quite a bit of security ground to cover. Now, the U-Fuzz toolkit from [asset-group] helps us make up for it.

Unlike fuzzers you might imagine, U-Fuzz doesn’t go in blindly. This toolkit has provisions to parse protocols and fuzz fields meaningfully, which helps because many of devices will discard packets they deem too malformed. With U-Fuzz, you feed it a couple packet captures, help it make some conclusions about packet and protocol structure, and get suggestions on how to crash your devices in ways not yet foreseen.

This allows for basically arbitrary protocol fuzzing, and to demonstrate, we get examples on 5G, CoAP and ZigBee probing alike, with a list of found CVEs to wrap the README up. As Wikipedia often states, this list is incomplete, and you can help by expanding it. Fuzzing is an underestimated tool – it will help you hack ubiquitous wireless protocols, proprietary standards, and smart home hubs alike.

This Week In Security: 11,000 Gas Stations, TrustZone Hacks Kernel, And Unexpected Fuzzing Finds

September 16, 2022 by 6 Comments

Automated Tank Gauges (ATGs) are nifty bits of tech, sitting unseen in just about every gas station. They keep track of fuel levels, temperature, and other bits of information, and sometimes get tied into the automated systems at the station. The problem, is that a bunch of these devices are listening to port 10001 on the Internet, and some of them appear to be misconfigured. How many? Let’s start with the easier question, how many IPs have port 10001 open? Masscan is one of the best tools for this, and [RoseSecurity] found over 85,000 listening devices. An open port is just the start. How many of those respond to connections with the string In-Tank Inventory Reports? Shodan reports 11,113 IPs as of August of this year. [RoseSecurity] wrote a simple Python script that checked each of those listening IPs came up with a matching number of devices. The scary bit is that this check was done by sending a Get In-Tank Inventory Report command, and checking for a good response. It seems like that’s 11K systems, connected to the internet, with no authentication. What could possibly go wrong? Continue reading “This Week In Security: 11,000 Gas Stations, TrustZone Hacks Kernel, And Unexpected Fuzzing Finds” →

This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More

December 11, 2020 by 9 Comments

There’s a VMWare problem that’s being exploited in the wild, according to the NSA (PDF). The vulnerability is a command injection on an administrative console. The web host backing this console is apparently running as root, as the vulnerability allows executing “commands with unrestricted privileges on the underlying operating system.”

The wrinkle that makes this interesting is that VMWare learned about this vuln from the NSA, which seems to indicate that it was a zero-day being used by a foreign state. The compromise chain they list is also oddly specific, making me suspect that it is a sanitized account of observed attacks.

Microsoft Teams, And the Non-CVE

[Oskars Vegeris] found a pair of interesting problems in the Microsoft Teams client, which together allows an interactionless, wormable RCE. The first vuln is an XSS problem, where a message containing a “mention” can be modified in transit to include arbitrary Javascript. To get that JS past the XSS protection filter, a unicode NULL byte is included in the payload. The second vuln is using the built-in file download code in the Teams app to download and auto-run a binary. Put together, anyone who simply loads the message in their Teams app runs the code.

Vegeris points out that since so many users have a presence in multiple rooms, it would be trivial to use this exploit to build a worm that could infect the majority of Teams users worldwide. The bug was reported privately to Microsoft and fixed back in October. A wormable RCE in a widely used tool seems like a big deal, and should net a high CVE score, right? Microsoft gave two ratings for this attack chain, for the two versions of Teams that it can affect. For the Office365 client, it’s “Important, Spoofing”, which is about as unimportant as a bug can be. The desktop app, at least, was rated “critical” for an RCE. The reason for that seems to be that the sandbox escape only works on the standalone desktop app.

But no CVE was issued for the exploit chain. In the security community, collecting CVEs is an important proof of work for your resume. Microsoft replied that they don’t issue CVEs for products that get updated automatically without user interaction. Kerfuffle ensued. Continue reading “This Week In Security: VMWare, Microsoft Teams, Python Fuzzing, And More” →

This Week In Security: Fuzzing Fixes, Foul Fonts, TPM Timing Attacks, And More!

November 15, 2019 by 11 Comments

An issue was discovered in libarchive through Google’s ClusterFuzz project. Libarchive is a compression and decompression library, widely used in utilities. The issue here is how the library recovers from a malformed archive. Hitting an invalid header causes the memory in use to be freed. The problem is that it’s possible for file processing to continue even after that working memory has been freed, leading to all kinds of problems. So far an actual exploit hasn’t been revealed, but it’s likely that one is possible. The problem was fixed back in May, but the issue was just announced to give time for that update to percolate down to users.

Of note is the fact that this issue was found through Google’s fuzzing efforts. Google runs the oss-fuzz project, which automatically ingests nightly builds from around 200 open source projects and runs ClusterFuzz against them. This process of throwing random data at programs and functions has revealed over 14,000 bugs.
Continue reading “This Week In Security: Fuzzing Fixes, Foul Fonts, TPM Timing Attacks, And More!” →

DEF CON: HDMI CEC Fuzzing

August 9, 2015 by 10 Comments

HDMI is implemented on just about every piece of sufficiently advanced consumer electronics. You can find it in low-end cellphones, and a single board Linux computer without HDMI is considered crippled. There’s some interesting stuff lurking around in the HDMI spec, and at DEF CON, [Joshua Smith] laid the Consumer Electronics Control (CEC) part of HDMI out on the line, and exposed a few vulnerabilities in this protocol that’s in everything with an HDMI port.

CEC is designed to control multiple devices over an HDMI connection; it allows your TV to be controlled from your set top box, your DVD player from your TV, and passing text from one device to another for an On Screen Display. It’s a 1-wire bidirectional bus with 500bits/second of bandwidth. There are a few open source implementations like libCEC, Android HDMI-CEC, and even an Arduino implementation. The circuit to interface a microcontroller with the single CEC pin is very simple – just a handful of jellybean parts.

[Joshua]’s work is based off a talk by [Andy Davis] from Blackhat 2012 (PDF), but greatly expands on this work. After looking at a ton of devices, [Joshua] was able to find some very cool vulnerabilities in a specific Panasonic TV and a Samsung Blu-ray player.

A certain CEC command directed towards the Panasonic TV sent a command to upload new firmware from an SD card. This is somewhat odd, as you would think firmware would be automagically downloaded from an SD card, just like thousands of other consumer electronics devices. For the Samsung Blu-Ray player, a few memcpy() calls were found to be accessed by CEC commands, but they’re not easily exploitable yet.

As far as vulnerabilities go, [Joshua] has a few ideas. Game consoles and BluRay players are ubiquitous, and the holy grail – setting up a network connection over HDMI Ethernet Channel (HEC) – are the keys to the castle in a device no one  would ever think of taking a close look at.

Future work includes a refactor of the current code, and digging into more devices. There are millions of CEC-capable devices out on the market right now, and the CEC commands themselves are not standardized. The only way for HDMI CEC to be a reliable tool is to figure out commands for these devices. It’s a lot of work, but makes for a great call to action to get more people investigating this very interesting and versatile protocol.

ToorCon 9: Real World Fuzzing

October 20, 2007 by 5 Comments


We dropped in on [Charlie Miller]’s fuzzing seminar at the end of the day yesterday. Fuzzing become a fairly popular topic in the last year and essentially involves giving a program garbage input, hoping that it will break. If it can’t handle the fake data and fails in a non-graceful fashion, you could have found a potentially exploitable bug. Fuzzing is a fairly simple idea, but as Charlie points out, without some thinking while you’re doing it it’s unlikely to be very productive.

Continue reading “ToorCon 9: Real World Fuzzing” →

This Week In Security: Loop DOS, Flipper Responds, And More!

March 22, 2024 by 8 Comments

Here’s a fun thought experiment. UDP packets can be sent with an arbitrary source IP and port, so you can send a packet to one server, and could aim the response at another server. What happens if that response triggers another response? What if you could craft a packet that continues that cycle endlessly? That is essentially the idea behind Loop DoS (Denial of Service).

This unique avalanche of packets has been managed using specific implementations of several different network services, like TFTP, DNS, and NTP. There are several CVEs being used to track the issue, but CVE-2024-2169 is particularly odd, with the description that “Implementations of UDP application protocol are vulnerable to network loops.” This seems to be a blanket CVE for UDP, which is particularly inappropriate given that the first DoS of this sort was first reported in 2009 at the latest.

More details are available in a Google Doc. There some interesting tidbits there, like the existence of cross-protocol loops, and several legacy protocols that are vulnerable by design. The important thing to remember here is you have to have an accessible UDP port for this sort of attack to take place, so if you’re not using it, firewall it.

Flipper Flips Back

We’ve covered the saga of the Flipper Zero vs the Canadian government, in the context of car theft. The short version is that Canada has seen an uptick of car thefts from organized crime. Rather than meaningfully dealing with this problem, the Canadian government went looking for scapegoats, and found the Flipper Zero.

Well now, Flipper has responded, and put simply, the message is “stop the madness”. There has never been a confirmed case of using a flipper to steal a car, and it’s very unlikely it’s ever happened. On a modern car with proper rolling-code security, it’s not meaningfully possible to use the Flipper Zero for the theft. The two primary ways criminals actually steal cars are with dedicated keyfob repeaters and CAN bus hackers.

There is a petition to sign, and for Canadians, Flipper suggests contacting your local member of parliament. Continue reading “This Week In Security: Loop DOS, Flipper Responds, And More!” →