This Week in Security: BleedingTooth, Bad Neighbors, and Unpickable Locks

This week, the first details of BleedingTooth leaked onto Twitter, setting off a bit of a frenzy. The full details have yet to be released, but what we know is concerning enough. First off, BleedingTooth isn’t a single vulnerability, but is a set of at least 3 different CVEs (Shouldn’t that make it BleedingTeeth?). The worst vulnerability so far is CVE-2020-12351, which appears to be shown off in the video embedded after the break.

We do have some insight into this, in the form of a Google Security Advisory. A Proof of Concept is included, which triggers a kernel panic on a target machine. It’s unclear whether the target machine needs to be paired first, or if it is enough to have Bluetooth powered on. The core problem is that a malicious Bluetooth packet can follow an unintended code path, resulting in data type confusion. Until it’s resolved, it might be wise to keep Bluetooth turned off on your laptop.

RFC6106 and Bad Neighbors

Patch Tuesday was this week, and there was one bug in particular that caught my eye. CVE-2020-16898 is a problem in how RFC6106 IPv6 route advertisements are handled. A properly formatted packet contains a length field, and that field is defined as always having an odd value. When the packet is malformed as having an even value, a buffer overflow is triggered.

Proof of Concept code is available. Running the PoC results in a BSoD on an unpatched machine. Microsoft has concluded that it will be very difficult to turn this flaw into a true code execution vulnerability, due to existing hardening in the Windows kernel. Additionally, RFC6106 packets are only for local networks, and are blocked by gateways and ISP equipment. It’s very unlikely that this vulnerability could be used for attacks across the internet.

An Unpickable Padlock?

Lock picking is a fascinating practice. By applying tension to the core of a lock, the individual pins can be lifted to the sheer line, and once they’re all in place, the lock is picked. Manufacturers have been trying to make locks more resilient to picking and other bypass methods, but this lock really takes that effort to the next level. The video below is BosnianBill‘s teardown and analysis of this unpickable lock.

There are several weird elements to this. First, rather than being a major security or lockmaker brand, this is a “Gangsheng” lock. It’s likely that this is a knockoff of a series of locks designed by Yeuma. That aside, the design is very clever, with a series of “airgaps” built into the locking mechanism. There is no way to tension the lock directly, and the only tension force is provided by internal springs. It remains to be seen if this lock design will truly be unpickable, or if a weakness will eventually be found. Regardless, the design is impressive, and the future of high security locks appears to be interesting.

Spying on Smartwatches

If you have an Xplora 4 children’s smartwatch, you might want to retire it, as researchers from Mnemonic Labs have discovered what appears to be an intentional backdoor in the device. Upon receiving a cryptographically signed text message, this Android-based device can record audio, take a picture, and report back its position. When a piece of tech hardware ships with odd functions like this, it’s usually debugging functions that were never removed. This case is slightly different, as the smartwatch was developed by Qihoo 360, who has already been placed on the US list of national security threats. Not to mention, when the function to collect audio is literally labeled wiretap, it becomes hard to assume no ill intent.

Via The Register.

Playing Tricks on Trickbot

[Brian Krebs] first noticed something unusual going one with the Trickbot botnet at the beginning of the month. He reported on a new set of instructions being sent to some Trickbot instances, setting the command and control server to localhost. While this doesn’t remove the infection, it does prevent the infected machine from taking further directed actions. A few other tricks were in play at the time, like sending fake infection data to the controlling servers. It looked like a complex attack on the malware network.

A few days later, Microsoft released a statement detailing their actions to cripple the Trickbot network. The timing immediately suggests that [Krebs] was reporting on Microsoft’s actions. While this is possible, the specifics in Microsoft’s report don’t quite line up. Microsoft claims to have taken the actions on October 12, while [Krebs] had been observing odd behavior for several days, as of October 2nd. The mitigation steps sound quite different as well. It’s unclear whether these were two separate actions against Trickbot. Either way, it’s always good to see concrete actions taken against botnets.

Hacking Apple

We’ve covered lots of news about vulnerabilities in Apple devices, but this story is about the guys who hacked Apple’s infrastructure. The whole story is detailed, and a useful guide to doing a security audit like this. They identified infrastructure, and started with looking for known vulnerabilities that hadn’t been updated yet. All told, they found 54 separate vulnerabilities in Apple’s infrastructure. They ranged from a fun email worm in iCloud, powered by a cross-site scripting attack, to a clever security bypass allowing them admin access to one of Apple’s official forums. It’s not light reading, but if you really want the details on how a red-team goes about a test against public infrastructure, this is a good place to start.