This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked

As conspiracy theories go, one of the more plausible is that a cell phone could be running malicious firmware on its baseband processor, and be listening and transmitting data even when powered off. Nowadays, this sort of behavior is called a feature, at least if your phone is made by Apple, with their Find My functionality. Even with the phone off, the Bluetooth chip runs happily in a low-power state, making these features work. The problem is that this chip doesn’t do signed firmware. All it takes is root-level access to the phone’s primary OS to load a potentially malicious firmware image to the Bluetooth chip.

Researchers at TU Darmstadt in Germany demonstrated the approach, writing up a great paper on their work (PDF). There are a few really interesting possibilities this research suggests. The simplest is hijacking Apple’s Find My system to track someone with a powered down phone. The greater danger is that this could be used to keep surveillance malware on a device even through power cycles. Devices tend to be secured reasonably well against attacks from the outside network, and hardly at all from attacks originating on the chips themselves. Unfortunately, since unsigned firmware is a hardware limitation, a security update can’t do much to mitigate this, other than the normal efforts to prevent attackers compromising the OS.
Continue reading “This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked”

This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned

F5’s BIG-IP platform has a Remote Code Execution (RCE) vulnerability: CVE-2022-1388. This one is interesting, because a Proof of Concept (PoC) was quickly reverse engineered from the patch and released on Twitter, among other places.

HORIZON3.ai researcher [James Horseman] wrote an explainer that sums up the issue nicely. User authentication is handled by multiple layers, one being a Pluggable Authentication Modules (PAM) module, and the other internally in a Java class. In practice this means that if the PAM module sees an X-F5-Auth-Token, it passes the request on to the Java code, which then validates the token to confirm it as authentic. If a request arrives at the Java service without this header, and instead the X-Forwarded-Host header is set to localhost, the request is accepted without authentication. The F5 authentication scheme isn’t naive, and a request without the X-F5-Auth-Token header gets checked by PAM, and dropped if the authentication doesn’t check out.

So where is the wiggle room that allows for a bypass? Yet another HTTP header, the Connection header. Normally this one only comes in two varieties, Connection: close and Connection: keep-alive. Really, this header is a hint describing the connection between the client and the edge proxy, and the contents of the Connection header is the list of other headers to be removed by a proxy. It’s essentially the list of headers that only apply to the connection over the internet. Continue reading “This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned”

This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat

DNS spoofing/poisoning is the attack discovered by [Dan Kaminski] back in 2008 that simply refuses to go away. This week a vulnerability was announced in the uClibc and uClibc-ng standard libraries, making a DNS poisoning attack practical once again.

So for a quick refresher, DNS lookups generally happen over unencrypted UDP connections, and UDP is a stateless connection, making it easier to spoof. DNS originally just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that wasn’t sufficient when combined with a technique that generated massive amounts of DNS traffic. That attack could poison the DNS records cached by public DNS servers, greatly amplifying the effect. The solution was to randomize the UDP source port used when sending UDP requests, making it much harder to “win the lottery” with a spoofed packet, because both the TXID and source port would have to match for the spoof to work.

uClibc and uClibc-ng are miniature implementations of the C standard library, intended for embedded systems. One of the things this standard library provides is a DNS lookup function, and this function has some odd behavior. When generating DNS requests, the TXID is incremental — it’s predictable and not randomized. Additionally, the TXID will periodically reset back to it’s initial value, so not even the entire 16-bit key space is exercised. Not great. Continue reading “This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat”

Audio Eavesdropping Exploit Might Make That Clicky Keyboard Less Cool

Despite their claims of innocence, we all know that the big tech firms are listening to us. How else to explain the sudden appearance of ads related to something we’ve only ever spoken about, seemingly in private but always in range of a phone or smart speaker? And don’t give us any of that fancy “confirmation bias” talk — we all know what’s really going on.

And now, to make matters worse, it turns out that just listening to your keyboard clicks could be enough to decode what’s being typed. To be clear, [Georgi Gerganov]’s “KeyTap3” exploit does not use any of the usual RF-based methods we’ve seen for exfiltrating data from keyboards on air-gapped machines. Rather, it uses just a standard microphone to capture audio while typing, building a cluster map of the clicks with similar sounds. By analyzing the clusters against the statistical likelihood of certain sequences of characters appearing together — the algorithm currently assumes standard English, and works best on clicky mechanical keyboards — a reasonable approximation of the original keypresses can be reconstructed.

If you’d like to see it in action, check out the video below, which shows the algorithm doing a pretty good job decoding text typed on an unplugged keyboard. Or, try it yourself — the link above implements KeyTap3 in-browser. We gave it a shot, but as a member of the non-mechanical keyboard underclass, it couldn’t make sense of the mushy sounds it heard. Then again, our keyboard inferiority affords us some level of protection from the exploit, so there’s that.

Editors Note: Just tried it on a mechanical keyboard with Cherry MX Blue switches and it couldn’t make heads or tails of what was typed, so your mileage may vary. Let us know if it worked for you in the comments.

What strikes us about this is that it would be super simple to deploy an exploit like this. Most side-channel attacks require such a contrived scenario for installing the exploit that just breaking in and stealing the computer would be easier. All KeyTap needs is a covert audio recording, and the deed is done.

Continue reading “Audio Eavesdropping Exploit Might Make That Clicky Keyboard Less Cool”

The TPM module that Viktor designed, inserted into the motherboard

TPM Module Too Expensive? DIY Your Own Easily!

Since Windows 11 has announced its TPM module requirement, the prices for previously abundant and underappreciated TPM add-on boards for PC motherboards have skyrocketed. We’ve been getting chips and soldering them onto boards of our own design, instead – and [viktor]’s project is one more example of that. [Viktor] has checked online marketplace listings for a TPM module for his Gigabyte AORUS GAMING 3 motherboard, and found out they started at around 150EUR – which is almost as much as the motherboard itself costs. So, as any self-respecting hacker, he went the DIY way, and it went with hardly a hitch.

Following the schematic from the datasheet, he quickly made a simple KiCad layout, matching it to the pinout from his motherboard’s user manual, then ordered the boards from PCBWay and SLB9665 chips from eBay. After both arrived, [viktor] assembled the boards, and found one small mistake – he designed a module for 2.54mm pin headers, but his motherboard had 2.0mm headers. He wired up a small adapter to make his assembled V1.0 boards work, and Windows 11 installed without any TPM complaints. He shows that he’s designed a new, V1.1 version with an updated connector, too, and published its (untested but should work) design files for us on GitHub. These modules can vary, by manufacturer and motherboard series, but with each module published, a bunch of hackers can save money – and get a weekend project virtually guaranteed to work out.

Regardless of whether the goal of running Windows 11 is ultimately worthwhile, it has been achieved. With scalpers preying on people who just want to use their hardware with a new OS, rolling your own TPM PCB is a very attractive solution! Last time we covered a DIY TPM module for ASrock server motherboards, we had a vivid discussion in the comments, and if you’re looking to create your own TPM board, you could do worse than checking them out for advice and insights!

The microcontroller described in the article, on the PCB taken out of the kettle

Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle

[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn’t be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough — where’s the catch?

This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You’d think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they’re decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.

Continue reading “Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle”

For Once, The Long Arm Of John Deere Presses The Right Button

Over many years now we’ve covered right-to-repair stories, and among them has been a constant bĂȘte noire. The American farm machinery manufacturer John Deere whose instantly recognisable green and yellow tractors have reliably tilled the soil for over a century, have become the poster child for inappropriate use of DRM. It’s enough to make any farmer see red, but there’s a story from CNN which shows another side to manufacturer control. A Deere dealership in Melitopol, Ukraine, was looted by invading Russian forces, who took away an estimated $5m worth of farm machinery. The perfect crime perhaps, save for the Deere computer system being used to remotely disable them leaving the crooks with combine harvesters they can’t even start.

It makes for a good news story showing the Ukranians getting one over on the looters, and since on-farm thefts are a hot topic anywhere in the world it’s not entirely unexpected that Deere would have incorporated a kill-switch in their products. Recently we covered a look at how the relationship between motor vehicle owner and manufacturer is changing from one of product ownership to software licence, and this is evidently an example of the same thing in the world of machinery. It’s reported that the looters are seeking the help of tractor hackers, which may be unfortunate for them since the world’s go-to source for hacked Deere software is Ukraine. Perhaps they would be better remembering that Russia has legendary tractors of its own.

Thanks [Robert Piston] for the tip.