Bluetooth is a great protocol. You can listen to music, transfer files, get on the internet, and more. A side effect of those many uses is that the specification is complicated and intended to cover many use cases. A team of researchers took a look at the Bluetooth specification, and discovered a problem they call the KNOB attack, Key Negotiation Of Bluetooth.
This is actually one of the simpler vulnerabilities to understand. Randomly generated keys are only as good as the entropy that goes into the key generation. The Bluetooth specification allows negotiating how many bytes of entropy is used in generating the shared session key. By necessity, this negotiation happens before the communication is encrypted. The real weakness here is that the specification lists a minimum entropy of 1 byte. This means 256 possible initial states, far within the realm of brute-forcing in real time.
The attack, then, is to essentially man-in-the-middle the beginning of a Bluetooth connection, and force that entropy length to a single byte. That’s essentially it. From there, a bit of brute forcing results in the Bluetooth session key, giving the attacker complete access to the encrypted stream.
One last note, this isn’t an implementation vulnerability, it’s a specification vulnerability. If your device properly implements the Bluetooth protocol, it’s vulnerable.
CenturyLink Unlinked
You may not be familiar with CenturyLink, but it maintains one of the backbone fiber networks serving telephone and internet connectivity. On December 2018, CenturyLink had a large outage affecting its fiber network, most notable disrupting 911 services for many across the United States for 37 hours. The incident report was released on Monday, and it’s… interesting.
“In the early morning of December 27, 2018, a switching module in CenturyLink’s Denver, Colorado node spontaneously generated four malformed management packets.”
These packets were addressed to a broadcast destination, had valid headers and checksums, no expiration time, and were larger than 64 bytes. Because the packets appeared to be properly formed, none of the security infrastructure filtered those packets. The term for what happened next is a “packet storm”. Each device on the node rebroadcast each packet as it was received, quickly saturating the whole fiber network.
“CenturyLink and Infinera state that, despite an internal investigation, they do not know how or why the malformed packets were generated.”
In reading this, I can only suspect this was an intentional attack. Even if this particular instance was accidental, this represents an enormous vulnerability in the CenturyLink backbone network.
Siri, Make a Phone Call
The Better Business Bureau issued a warning about a new scam, apparently discovered through their scam tracker service. More accurately, it’s an old scam that people are falling for in a new way.
How do Siri, Cortana, and the like know what number to call in response to a voice command? They use their respective search engine to look it up. And what happens when the top result has been manipulated through SEO, or an ad purchase? Your assistant might just call a tech support scam by mistake. The BBB suggests that you don’t use the automated calling function, and carefully look up numbers manually instead.
Backdoors in Management Interface
The open source Webmin tool shipped three separate releases that contained intentional backdoors, 1.890, 1.900, and 1.920. The backdoor wasn’t included in the official source, but was instead planted on the build machine by an attacker. Because of the specifics of the build process, that code wasn’t overwritten until the compromised source file was legitimately changed in the project. At least once, the attacker re-injected malicious code after such a change and update.
This sort of attack is just a reminder of the importance of reproducible builds, and the constant need to validate everything. All it takes to discover this attack
Steam Fixes 0-days by Banning Researchers
OK, so maybe it’s not that bad, but this still isn’t great. [Vasily Kravets] discovered a pair of problems in the Steam client that an attacker could use to gain system level privileges. It’s not remote code execution, but both vulnerabilities appear to be legitimate. [Vasily] reported the first problem to HackerOne, the service Steam uses to manage vulnerability reporting. They promptly classified his report as out of scope for Valve’s bug bounty program. This isn’t such a terrible problem, except for the implication that Valve didn’t think that the vulnerability in question wasn’t important enough to fix.
The story gets worse before it gets better. [Vasily] informed HackerOne that he would publicly release the vulnerability, and they responded by informing him that he wasn’t allowed to do so. With no indication of intent to fix, he went ahead with the public disclosure, and was banned from reporting Valve related vulnerabilities on HackerOne.
Valve has reached out to ZDNet, saying that the whole debacle was a mistake, and they are taking steps to make it right. The vulnerabilities have been fixed in a beta release of Steam, and Valve is reviewing [Vasily]’s ban.
No comments:
Post a Comment