Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Security researcher found Wi-Fi vulnerabilities that existed since the beginning (theverge.com)
199 points by teleforce on May 13, 2021 | hide | past | favorite | 38 comments


95% of the internet traffic is now TLS according to Google:

https://transparencyreport.google.com/https/overview?hl=en

Most of the most severe attacks require HTTP and physical proximity. So we’re fortunate of the huge drive towards HTTPS since Snowden’s 2013 releases when it was around ~55% (I’ve seen the rise in numbers correlated before).

But it also recommends upgrading your router. I wonder how many routers and IoT device companies are actually releasing firmware updates. And quality ones at that…


Those figures are for Google's services, so all those services can do TLS, but some of the clients don't.

However the step change for HTTPS over the wider web is mostly a bunch of related mutually enabling changes:

* Let's Encrypt launches

* Google slightly penalizes plaintext HTTP in search

* Browsers (Chrome, Safari, Firefox at least) stop offering new features outside Secure Context (so HTTPS for public sites) and begin deprecating or reducing scope of some older features outside that context.

On smaller sites also don't underestimate

* Prevalence of browsers/ devices without SNI falls a lot so...

* Many bulk hosting sites begin offering cheap or free HTTPS virtual hosting, with SNI, where previously they only offered IP hosting for HTTPS at higher prices.

In 2005 if I wanted my new one-joke web site to have HTTPS that's a bunch of extra money, for one corny joke, it's not worth it. Today, it's zero extra effort, if I make a new site it has HTTPS by default of course. If I see somebody whose host is trying to charge them money for this, these days it's rarely worth chipping in "You are being ripped off" because somebody else will be typing that already.


TLS is useful and should be the default for everything; However, it is not the protection everyone seems to assume it is for several reasons:

1. Users generally still click "Accept & Continue" when they see certificate warnings.

2. A given app can easily disable certificate validation and blindly trust the other end. For web browsers, great they do it well. Other applications often disable certificate validation altogether. Plenty of mobile apps I've seen fail to do proper certificate validation, though thankfully it is becoming less common thanks to vendor platforms removing the option to be horribly insecure.

3. An attacker can still see which domain names and/or hostnames you're accessing.

The simplest useful thing I could think of with this might be is finding a given WiFi network's IP on the Internet, in those circumstances where the hardware permits you to create your own frames.


> Users generally still click "Accept & Continue" when they see certificate warnings.

I am one of these users. However, that doesn't mean the warning isn't useful—it puts me on high alert! I enter these websites knowing that I shouldn't trust any information I see, and that I shouldn't enter anything important.

I am of course more technically inclined than the average user, so I don't know that my behavior is broadly applicable. Even so, I wonder if this metric necessarily means what it seems to mean.


> 1. Users generally still click "Accept & Continue" when they see certificate warnings.

In Firefox HSTS blocks this entirely. There is no "Accept" option at all. In Chrome HSTS means the only way to "accept and continue" is to type whatever the current magic bypass phrase is, the ordinary "accept and continue" option isn't there.


And even without HSTS, most web browsers bury the option to continue deep enough that for most users it could as well not exist. In Chrome you have to click "details" and there will be a tiny link to "continue anyway".


This is a vulnerability more than a benefit. If you need to access a website and can't because of ominous errors, most users will simply try a different device. If the user always browses a specific site on their desktop, and the desktop hits an HSTS warning, the user will immediately try it on their phone, which has never visited the site, and thus has no HSTS record, and will then click through any certificate warning. As far as the user is concerned, the website or their internet connection (or both) are just screwed up.

Web browsers have never taken any of this seriously. Their hilariously poor UX around errors and warnings, their half-baked mitigation schemes, their reluctance to figure out new industry solutions for extremely common problems like setting up a wireless access point, etc.


If you (as a site owner) care about HSTS, you'll likely get your site included in the preload list, which closes the other device loophole for the most part. (There certainly are some devices with browsers that don't get updates and/or don't do HSTS preload, but can't fix everyone).


The preload list is another crap web browser mitigation.

"Hey, we have this problem with our browsers where the security is trivially defeated a number of ways. What are we gonna do about it? ......... I got it! We'll make extra security optional!"

As a regular web user, I should be able to know if the site I'm using is secure from MITM. But that's basically unknowable, because for any given site you're on, there may be a half dozen different kinds of duct tape implemented in different ways. I just have to hope nobody wants to hack me. All the mitigations might as well not exist.


I'm already disagreeing with your main point 1)

My parents don't know how to do this and would call me and stop trying to 'solve it'

Chrome and Firefox are quite visual in this regard.


thisisunsafe...


> huge drive towards HTTPS since Snowden’s 2013 releases

Note that HTTPS everywhere in conjunction with HR 4681[1] means there are no limits on how long US government can retain captured communications of US citizens:

> Covered communication.–The term ``covered communication’’ means any nonpublic telephone or electronic communication acquired without the consent of a person who is a party to the communication, including communications in electronic storage.

> …

> Limitation on retention.–A covered communication shall not be retained in excess of 5 years, unless–

> …

> the communication is enciphered or reasonably believed to have a secret meaning;

[1]: https://www.nu42.com/2014/12/https-everywhere-and-hr4681.htm...


> the most severe attacks require HTTP

Well, for the services that use HTTP, anyway - there's still a lot of non-HTTP traffic out there like SMTP and DNS. Devices still use SNMP, too, and often connect over wifi.


That's why TLS for internal network/IoT devices is important. Browser industry must seriously consider this uncovered usage.


Once someone is on your LAN, HTTPS isn't the end-all-be-all protection. If, for example, a website hasn't enabled HSTS, or they have but they don't have HSTS preload and the user hasn't visited them before.


Like with every old phone: they will not patch it. Then they will tell you to buy a new one or a similar but new model.


And the drive to HTTPS was initiated by "evil" Google (like free email with >2GB which was unheard of at the time).


Companies always act in their best interests. Occasionally those interests will align with those of the end users.


More usage of HTTPS helps Google's business.

1.) ISPs can not change the content of websites their users are watching to modify or add additional advertisements. Companies have to buy advertisements at Google.

2.) It is harder for ISP to analyze the web traffic of their customers to build profiles which they can sell. Only Google has these information.

3.) When people feel safer in the Internet they buy more stuff on the Internet. Business will buy more advertisements on the Internet, probably at Google.


>2.) It is harder for ISP to analyze the web traffic of their customers to build profiles which they can sell. Only Google has these information.

Using DPI to view the SNI (which is still in plaintext... for now, anyway) of all connections is very easy.

Even once that's patched, most users still use the DNS servers provided by their ISP, which can easily log queries. Even if you created junk queries to add noise, it's child's play to correlate DNS query with the TCP SYN (or UDP datagram for QUIC etc) to the IP returned by the query.


> like free email with >2GB which was unheard of at the time

If its free, you're the product. Yet people don't know. Call me old fashioned but I rather pay for my e-mail services.


> Yet people don’t know.

I’m not sure that’s true. Many people know and simply don’t care.

Using hypothetical me as an example, why does it matter to me that Google can read my emails? Why does it matter to me that Google is improving their searches by tracking my activity? I’ve got nothing to hide.

And before you say “I’ve got nothing to hide” isn’t a good reason to give up privacy and freedom... well that fight isn’t here on HN. It’s a fight with the hundreds of millions of privacy apathetic people who are winning the fight by a landslide.

We can hate on FANG as much as we want, but if 2/3 of the population can validate their business model, does it even matter?


I think that most people implicitly assume that their communications are private.

Mass surveillance is an open secret that is easier on the senses to ignore.

Ignorance can be combatted with information. But now there's a "war on information" with companies like facebook (in true comedic fashion) being the arbiter of "truth". Facebook, one of the biggest players in the mass surveillance game.

The business model is validated because of ignorance. Most people have no idea what pixel tags are, for instance, yet the web is oozing with them. When given the option, people prefer not to be surveilled. It is more or less inhuman to want to be watched surrepticiously. We call that stalking.


> If its free, you're the product.

I'm not sure this is even useful as a rule of thumb, let alone generally true.

Let's Encrypt certificates and Debian are both "free" in the sense you mean, are you somehow "the product" for those?

Everywhere I'm aware of in the world, COVID-19 vaccines are free, are you "the product" when immunised against a deadly disease? How so?

Air is free, am I the product for like... trees? How does this work?

And in contrast it's pretty clear that many expensive things Americans buy treat them as the product anyway, because it's free revenue. So the rule of thumb doesn't even help you to avoid being scammed, it just means you're more willing to pay for the chance.


>I'm not sure this is even useful as a rule of thumb, let alone generally true.

Because free is a limited word. Which is why we have free as in beer / free as in freedom / libre vs free, the list goes on and on.

"If its free, you're the product" is a perfectly fine statement to help average folks navigate the modern tech consumer world outside of opensource efforts.

>Everywhere I'm aware of in the world, COVID-19 vaccines are free, are you "the product" when immunised against a deadly disease? How so?

For this you do actually provide data back to the providers of the vaccine (depending on country and agreements signed of course). Most of the free vaccine sites near me (USA) have a lot of obvious data collection along with the provided vaccine which I'm fine with.


> Everywhere I'm aware of in the world, COVID-19 vaccines are free, are you "the product" when immunised against a deadly disease? How so?

The people making the vaccines are getting paid, although the vaccine is the product. The people sticking the vaccine in my arm are getting paid, my arm is the product. (Sort of)

The US government is compelling insurance companies to pay for it, and paying for it in absence of insurance, because excess death is a drag on the economy.


LE and Debian, two projects I use and appreciate, are free as in beer, but you're allowed to donate [1] [2]. Mirrors run for example on a university. In the end, it is all paid somehow. Perhaps by altruistic people, perhaps by public funding, perhaps by government funding, perhaps by donations (with a nice mention, aka advertising), perhaps by private money... but its paid for somehow.

You mention air and trees. If we don't pump money into the quality of our air and in trees (to offset Co2 production) we are doomed. You mention COVID-19 vaccines. Who do you think pays for it if its free? All of us who pay our taxes do ie. society.

If you pay for something, you have in some circumstances a stronger legal ground than when its free. I have all too often witnessed free products where, when I give feedback/criticism, I get the reply "..its free /care don't moan". If I pay for it, this argument doesn't hold, and you can hold them legally accountable in some situations. Its also not as if e-mail is expensive. I pay my ISP for it, and I get to pick a domain (all included with my sub, but guess what it isn't free...). I can move from that domain if I desire. There's also something like Posteo which costs 1 EUR a month or so, and then there's Protonmail (which I personally don't like cause of JavaScript webmail but YMMV).

The reference "if its free, you're the product" is a great rule of thumb on the WWW, as it raises awareness on an important issue. I wish more people realize it because all too many people have no idea what exactly is being harvested about them. Which is a shame. It also makes it more difficult for commercial products to compete. And, if I take for example two local research news sources which I like (De Correspondent and Follow The Money) then these are paid for; not free as in beer. Yet, they compete with free as in beer. Which isn't free as in beer. Every time you use YouTube or Facebook you pay, with your privacy. What I foresaw long before it got the standard quo was that we get a divide in world-wide society: those who pay with money, and those who pay with privacy. You can already see it very clearly in the mobile world of iOS and Android.

[1] https://www.debian.org/donations

[2] https://letsencrypt.org/donate/


If you have an idea to communicate, try to make it without burying it in sarcasm.


This particular attack seems difficult in practice. Reassembled fragments still need to yield a checksum-valid frame. With TLS becoming the norm most laptop/mobile/server communication channels will not be affected.

As mentioned in the paper, the problem is indeed that MCUs have become so cheap that every $7 light bulb is equipped with WiFi. The firmware on these devices is almost never updated after production. And even on devices that are being updated, like philips hue, it's often found that WiFi chipsets run their own firmware.


>Reassembled fragments still need to yield a checksum-valid frame.

For a 32bit checksum changing data will give you a 1 in 4,294,967,296 chance of being correct. So just keep bit twiddling some unimportant portion of the frame until you obtain a valid checksum. 4,294,967,296 is not a large number for a modern computer.

These frame checksums are only intended for accidental bit flips. They aren't protection against someone creating fake frames with valid checksums.


What is an MCU?




This is the website with the actual vulnerabilities:

https://www.fragattacks.com


> the design flaws are hard to abuse because…

This is good.

> in practice the biggest concern are the programming mistakes in Wi-Fi products since several of them are trivial to exploit.

Any indication which devices are known to be affected? None of the pages I've read so far give that information. Though it could be that this information is subject to "responsible disclosure" and won't be released until manufacturers have had a reasonable amount of time to release patches.


All devices are affected, that's why there was a 9-month embargo for Linux. Some vendor devices were silently patched during that period.


All devices are affected by the base flaw as that is part of the protocol as set out from the start.

But if you read the article and others, particularly around the bit I quoted, it essentially states that there are extra, avoidable, flaws in specific devices (or families of devices).


Is this caused by me building my own auth system?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: