Wi-Fi Chip Vulnerability

There’s a vulnerability in Wi-Fi hardware that breaks the encryption:

The vulnerability exists in Wi-Fi chips made by Cypress Semiconductor and Broadcom, the latter a chipmaker Cypress acquired in 2016. The affected devices include iPhones, iPads, Macs, Amazon Echos and Kindles, Android devices, and Wi-Fi routers from Asus and Huawei, as well as the Raspberry Pi 3. Eset, the security company that discovered the vulnerability, said the flaw primarily affects Cypress’ and Broadcom’s FullMAC WLAN chips, which are used in billions of devices. Eset has named the vulnerability Kr00k, and it is tracked as CVE-2019-15126.

Manufacturers have made patches available for most or all of the affected devices, but it’s not clear how many devices have installed the patches. Of greatest concern are vulnerable wireless routers, which often go unpatched indefinitely.

That’s the real problem. Many of these devices won’t get patched—ever.

Tags: , , , , ,

Posted on March 3, 2020 at 6:43 AM • 20 Comments

Comments

Bobby • March 3, 2020 8:45 AM

CVE-2019-15126 still has CVSS base score 3.1 at NVD. It will hopefully be updated soon

jdgalt • March 3, 2020 9:59 AM

Is there a way I can test if my device has one of these and should be replaced? Or should I simply assume that all routers and all phones are backdoored and not bother?

Clive Robinson • March 3, 2020 10:11 AM

@ Bruce, All,

From the article we have,

    The vulnerability exists in Wi-Fi chips made by Cypress Semiconductor

From Wikipedia on Cypress Seniconductor,

    Cypress Semiconductor Corporation is an American semiconductor design and manufacturing company.

So the chips are of “American origin”, yet from the article we also see,

    The affected devices include iPhones, iPads, Macs, Amazon Echos and Kindles, Android devices, and Wi-Fi routers from Asus and Huawei, as well as the Raspberry Pi 3.

You will note “Asus and Huawei”, neither of which are US companies, one being in “The Republic of China” the other in China it’s self.

Which just goes to add a little more proof if required that Huawei and the Chinese are as vulnerable to US tech as US Politicians are claiming the US is to Huawei and to a lesser extent Asus.

As I’ve pointed out in the past nearly all Telco manufactures and certainly most PC manufactures get their IC’s that they can not check for security flaws –accidental or intentional– in any realistic manner.

It’s why this US Gov anti-5G –because that’s what it realy is,– is being focused on China.

The US is going to be a big looser with 5G because much of the technology is in no way of US origin, thus the US economic slice of the 5G pie will be realistically a sliver to what it might have been if US tech had been selected. The simple fact is that in certain respects in technology development, the US has and is still falling behind. The reason is for the last couple of decades US Corporate focus, has been based in the very short term and total lack of investment not just in R&D but in US jobs, training and education…

Has the US crossed a “tipping point” I’ll let others decided that whilst they do their work on Far Eastern Tech, or designed by people in or from the Far East.

@ All,

A thought for you, we kbow the NSA trys to get around Crypto in products, now this vulnerability is a real classic type of attack (known key in this case all zeros). Thus the question of “accidental or deliberate” arises.

Let’s assume it was deliberate for argument’s sake, just how much use could this be in products sold into just about every country in the world?

Well there are arguments of “not much” based on a series of assumptions that may or may not be valid.

In the past I’ve pointed out that if I was going to put backdoors in equipment, I would not use one vulnarability but two or three that had to be “chained” to be an effective attack. The reason being if only one of the attacks are found people will “trot out the usual platitudes” of “difficult to impossible to exploit”… This in turn makes people consider it a low priority to fix, as well as making the vulnerability look “accidentaly done” rather than “deliberately done”. This “reset to zero” is also a classic “looks accidental” because hardware gets reset at hard / cold / warm resets / reboots, so it’s exactly the sort of vulnarability I would look to use in a chain of vulnarabilities, because it looks so “innocent”, which is all part of the “finessing” game.

Have a think about it, it’s also exactly the reason why various people started getting twitchy about the inside of IC’s quite some years ago. Not the least of them were DARPA and the DoD…

Clive Robinson • March 3, 2020 10:18 AM

@ jdgault,

Or should I simply assume that all routers and all phones are backdoored and not bother?

I would make that assumption as a defacto start point.

However rather than “not bother” I would work out how to compleatly mitigate the issue.

One way might be to consider a Private VPN from all WiFi using kit in the organisation to a VPN gateway into a DMZ in the organisation wired network. That way most if not all trafic will be encrypted across the “Air Interface”.

lurker • March 3, 2020 1:04 PM

@Clive

now this vulnerability is a real classic type of attack (known key in this case all zeros).

But there’s more iniquity here: the chip is dumb enough (or designed?) to keep on sending after the key has changed. You can tell I’m not a chip system designer, because I would have required, in case where a reset occurrs midstream, to dump buffer to /dev/null and do a new handshake with the known other party. Oh, the inefficiency!

These “management frames” come with the same love as the management system in Intel cpus. I’m with Dick the Butcher: First we kill all the managers.

Clive Robinson • March 3, 2020 2:12 PM

@ lurker,

First we kill all the managers.

As the old joke has it,

    Tsk tsk, you’ve no imagination…

No, first we sell all the marketing dept to arabic slave traders for use as eunuchs and cesspit cleaners perferably both 😉

Depositor • March 3, 2020 3:22 PM

Of greatest concern are vulnerable wireless routers, which often go unpatched indefinitely.

That’s the real problem. Many of these devices won’t get patched — ever.

And the wireless on my laptop won’t even work with the standard Linux kernel. I have to disable MSFT+INTC+AMD secure boot and install a driver from https://github.com/tomaspinho/rtl8821ce …

It’s https://www.fcc.gov/ concerned from a governmental/parental point of view about “public impressions” of things and potential mass panic caused by transmissions of expressions of opinions or news over the public airwaves without official government approval.

From the FCC’s point of view, the internet is a mass media service for the delivery of government-approved information and paid content to consumers, certainly not a “common carrier” of data for general communications as many technically inclined persons are wont to think.

Our devices are not our own in their view, but borrowed from the government and large corporations, subject to the terms and conditions of proprietary copywritten software and other so-called “intellectual property.”

“Vulnerabilities” are the raison d’étre of FCC and other 9/11 “professional lifesavers” such as police, fire, medical, and that SWAT team that gets called out to a “hacker’s” house on a falsified warrant. If we weren’t so “vulnerable,” then we wouldn’t be in such need of the solicitous “services” of an overprotective parentalist government that refuses to allow us to defend ourselves against enemy attack, or to do other acts and things normally permitted to adults.

EvilKiru • March 3, 2020 4:15 PM

@ J.Peterson: Try searching for: Cypress vs. Broadcom

For me, that yielded a page full of references to the Cypress takeover of Breoadcom, including articles claiming to know why Broadcom got out of the IOT business.

SpaceLifeForm • March 3, 2020 4:50 PM

@ Clive

I’m not sure this is really a new problem.

Obviously, getting WIFI APs updated is a problem. It does not happen.

One way might be to consider a Private VPN from all WiFi using kit in the organisation to a VPN gateway into a DMZ in the organisation wired network. That way most if not all trafic will be encrypted across the “Air Interface”.

Not, if badguy inside.

Chicken-egg problem.

The initial VPN connection (even if totally internal), can be attacked.

hxxps://www.krackattacks.com/

hxcps://www.krackattacks.com/followup.html

Clive Robinson • March 3, 2020 6:25 PM

@ SpaceLifeForm,

I’m not sure this is really a *new* problem.

It depends on how you look at it. Best to call it “a new instance in a known class” of attack.

It’s why I’m dam suspicious of it, it’sto “pat” almost “trite” as I said a known password attack is not exactly new, and it’s one of the things the NSA aim for when they fritz with DRBG’s and characterize those in “network appliances” and such.

It’s why “something in my bones” or “hinky sixth sense” is telling me there is more to be found if people look for it.

The first thing I’d look for is something like a time based side channel that leaks information in a way that would alow synchronising the reset command, which would then leak info that would alow another attack to give better if not full access.

I’would expect all of the vulnarabilities to look like simple mistakes that got overlooked. That also are realy of little use on their own but when used together give the keys to the kingdom.

As for insider attacks, they are not something that realistically can be mitigated against, that’s why people are walking out of the NSA with terrabytes of data and nobody is noticing.

In theory you could set a system up that raises alarms, but then ultimately someone in the organisation needs to be an exception to the rules so certain tasks can be performed. The idea of “two key operation” is laughable as well Ed Snowden showed how easily that could be got around, when he got into other peoples accounts simply because they needed help…

There is also the old military saying of,

    Two is one, and one is none.

Which points out that when things fail as they do then you loose protection.

I used to design and build “Intrinsically safe” systems, they always insisted that you “double up” on volatage limiting and current limiting. With power supplies it was an absolute night mare because the regulation loop had four active parts. So if you got the opamps in the wrong order the control loop would oscillate in the 50kHz range or higher which caused other issues.

So yes “Two is one…” got burned into my gnarly engineers soul in ways few others could imagine.

ali • March 3, 2020 6:47 PM

The stories and the paper clearly say that the flaw is in the chips, but then they go on to describe a protocol flaw and talk about patching. Can anyone explain this? Are the patches disabling certain hardware components? If so, at what cost? Or is the flaw really in software that happens to run on the chip, but is not permanently stored on it?

SpaceLifeForm • March 3, 2020 8:05 PM

@ Clive

“hinky sixth sense”

s/badguy inside/intel based computers that have 802.11 chip running under windows/

Drone • March 4, 2020 12:02 AM

Below is a link to the original article on Ars Technica. The link in the O.P. is to a WiReD copycat page. At least the Ars article will have better comments. IMO stay away from WiReD, they’re politically and ideologically biased. Yes I know, Ars is tied to the hip with WiReD these days, it’s really dragging Ars down the drain. Actually it’s the Condé Nast affect that’s dragging both of them down the drain. Condé Nast now owns both WiReD and Ars.

https://arstechnica.com/information-technology/2020/02/flaw-in-billions-of-wi-fi-devices-left-communications-open-to-eavesdroppng/

Unnamed • March 4, 2020 2:17 AM

This is negligence – level:INTEL

According to the paper, device clears temporary key as expected, but data in buffer is unintentionally sent, using cleared key. It remind me some CPU manufacturing company incapable of clearing the pipeline, or at least checking validity of calculation before sending results all over the CPU.

Clive Robinson • March 4, 2020 7:02 AM

@ SpaceLifeForm,

s/badguy inside/intel based computers that have 802.11 chip running under windows/

Also this is the first known hardware “nasty” against a very popular Single Board Computer (SBC) capable of giving a person a well supported Non-Windows, Non-IAx86/64 PC level machine used by millions… That is the Raspberry Pi, which can be used with a comparatively expensive screen and keyboard but also “headless”. Which enables you to use a,low cost Mobile Phones –unfortunately using the same chip– that can be used as the “head” to a Pi via WiFi and provide Internet etc for the Pi.

People had hopes that the Pi was going to bring “computing to third world children”, businesses and even governments…

But on the old fassioned “Spy Stuff” front the Pi is also used by lots of Radio Amatures to do certain digital modes that use next to no RF bandwidth and less RF power than a flash-light to talk around the World on HF. Also it’s used as well in passively bouncing signals off of the moon (EME) a satellite you can’t “kinetic kill” and is controled by no one. Which is why the NSA Ships like the ill fated “USS Liberty” used EME during the late 1960’s.

You can download “ready to run recipes” to do these things off of dozens of Ham Radio and other Amateur Radio websites and you can be sure that some of the “Prepper Sites” as well. Have a think back to about a year ago when people were talking about “JT8Call”[1] using Crypto-Curencies over Amature Radio in case SHTF was a regional not global event. It was a bit of a pipe dream at that point but it probably shook a few people in Federal agencies who would have had nightmares about Columbian’s etc setting up their own independent international bank clearing system that neither they nor the CIA could drain the funds from…

So yes I suspect there are lots of unhappy people with lots of Money be it Seattle North, Silicon Valley, or Tax, wanting ways in to such systems.

As they say I could give you a long list of “theys” and a hundred reasons for “why they” might, but I can’t answer the important question of “have they”. All we have is history to tell us what “they have” done before and none of them have clean hands in that respect.

[1] JT8Call / FT8Call was built off of the back of Nobel Winning Prof Joe Taylor’s (K1JT” “weak signal modes” (WSJT-X) JT8. Since renamed JS8Call the FOSS software written by another Amature Jordan Sherer (KN4CRD) added not just easy messaging but mesh networking as well. The important thing is that if you look at the software source puting in crypto is easy, as is changing the inbuilt SDR radio modems and time sync methods…

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.