This Week In Security: KNOB, Old Scams Are New Again, 0-days, Backdoors, And More

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 is for one user to run a reproducible build and compare the output binaries.

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.

Update, [Vasily] has updated his blog post on the matter, and it seems that the fixes have been applied to the stable release of Steam, [Vasily] has been unbanned, and he even received a bounty for the original bug that he disclosed.

12 thoughts on “This Week In Security: KNOB, Old Scams Are New Again, 0-days, Backdoors, And More

  1. Responsible disclosure is a joke.

    It’s primary purpose is to reduce competition in software.

    Just disclose the vulnerability openly unless you are competitor software vendor.

      1. When you read about easily prevented, old vulnerabilities appearing in software over and over and over and over again, you also have “responsible disclosure” to thank for it.

      2. Really isn’t that important.

        There are plenty of exploits in the hands of the wrong people (many of which people pretend are the right people).

        There’s always another 0day to use.

        The only people who have anyone to that for responsible disclosure is the purveyors of poorly written code who don’t have to deal users being put off yet another bug.

  2. “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.”

    And maybe that’s why it’s so hard to consistently get working. WiFi is less problematic.

  3. “Bluetooth is a great protocol.”… and then you go on to explain what it is actually a bad protocol. I think your you actually meant to say was “bluetooth is a great idea but the protocol is complicated making it vulnerable to hacking”

    A great protocol is one that is simple, robust and hard to hack!

  4. Lol on what grounds were the people at Valve saying this guy wasn’t allowed to share the exploit he found? I can’t believe companies still act this way. Just don’t do this if you have a bug bounty program. The Venn diagram for “out of scope” and “can’t be allowed to ever be disclosed to the public” should be two separate circles. It’s either one or the other.

    And what nitwit decided the minimum entropy for bluetooth was one byte?? Get outta here. That could have been cracked by a processor from the seventies.

  5. ” Valve is reviewing [Vasily]’s ban.”

    Valve says they’re doing something to make it look like they’re doing something while they’re under the public glare, and once this is out of the news cycle, the matter will be forgotten about and the researcher will still be banned.”

    Fixed that for you.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.