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 Yuema. 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.
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.
Anyone know where I can get the actual Yeuma locks?
I believe it is a misspelling and it’s supposed to be “Yuema” lock
Yeah, typo on my part. Fixed, thanks!
What led you to pick Yeuma? I heard they’re unpickable.
I want one to lock the outhouse, so I can call it “Johnny Yuema”.
one for kirk’s arsenal of destroying intelligent computers and robots.
Re Trickbot: You didn’t mention the step between Krebs’ first report and Microsoft announcement, where reports suggested that US Cyber Command was behind the interference with Trickbot
https://krebsonsecurity.com/2020/10/report-u-s-cyber-command-behind-trickbot-tricks/
Re Qihoo 360: Not defending the backdoor, but the US declaring something a threat to national security is becoming pretty meaningless these days. Ref The Boy Who Cried Wolf
Both good points. I didn’t see the in-between article. That fills in some of the gaps.
I don’t know what to make of the national security lists, but I don know that there are countless stories that are classified, and won’t see the light of day for years. After researching CryptoAG, I have no problem believing a big company like Huawei could be spying for a government. That said, I would love for more evidence to be released to back up a company’s inclusion on a list like that.
Huawei is spying for the chinese government, Microsoft, Apple, Facebook, Google are spying for the US government and so on. The real question is not if anybody get’s your data but who and honestly, i don’t like the NSA more than whatever the chinese guys have. It’s sad. :(
And the American people are “spying” on each other.
Welcome to a nosy world where your business is our business.
I don’t like the NSA having my data, but I do like that they’re not currently running mass internment camps where they torture and sterilise people with views which don’t match the government’s. They are of course monitoring comms to help them find people to re-educate.
Say what you like about Trump, but he’s nowhere near that level of nasty.
Sorry, is this comment supposed to be sarcastic? Are all the problems in US solved and all the people are enjoying a good standard of living and equality in front of economic and the law?
We mostly believe what we are led to believe, mostly from media. I’ve seen the ‘western’ narrative so often at work, that I’ve stopped following any kind of news. Hacks, on the other side, are mostly political-agnostic.
I like reading this column. Its one of the staples in my security news diet. However I want to point out a minor omission with **BIG** implications. The BleedingTeeth bug is not in the Linux kernel, but in the software stack commonly run to enable bluetooth functionality.
This is a “bluez” vulnerability.
While some will write me off as simply defending Linux this distinction is important to me because it makes a difference in remediation. I don’t use bluetooth if at possible, because I’m paranoid. I don’t feel its been pounded on enough. And history seems to be baring me out over the past couple of years. But this means that I don’t have bluez running anywhere and therefor am safe from exploit. Where as if this were a kernel / driver issue just running the Linux kernel would make me potentially vulnerable. And I would need to either recompile my kernel or black list modules so they don’t auto-load. It also means that things that use an alternate bluetooth stack, like Android aren’t affected.
I read more about it here: https://thehackernews.com/2020/10/linux-Bluetooth-hacking.html
I’m glad you enjoy the column!
So, bluez has a bunch of code that’s *inside* the Linux kernel, which is where the vulnerable code is at in this case. It really is a vulnerability in the Linux Kernel, just the part of the kernel that’s also a part of the bluez project.
The good news is that since you don’t have anything Bluetooth enabled, the hardware doesn’t even get turned on, so you shouldn’t have any exposure to this bug. If you really want to, you can blacklist the bluetooth kernel module, as well.
Ah! Thanks! I missed that. “bluetooth” is hereby blacklisted! :-D
That lock is really cool. I’m wondering what’s keeping the others from implementing the same pattern, if it’s costs or patents.
I started picking while watching BosnianBill’s videos and quickly gave up as it would have turned into an expensive hobby. Even the “grade 5+” Abus locks could be rake-picked, and those thing are not exactly cheap.
It may be an impossible or very difficult lock to pick, but if it is breached by drilling out that set screw with a battery operated Dremel…