|
| tptacek wrote:
| From the researcher that brought you KRACK:
|
| https://www.krackattacks.com/
| colinbr96 wrote:
| Would using a VPN prevent the malicious DNS packet?
| swiley wrote:
| Authenticating the remote end of the connection (which all
| decent software does because using it on other people's WiFi
| would be very unsafe otherwise) makes it irrelevant.
| throwitaway12 wrote:
| Could you elaborate on this?
|
| I, too, would like to know the definitive answer to this, as
| I feel like a malicious DNS packet was used against a
| computer of mine before connected to the VPN.
|
| Very serious attack...
| transpute wrote:
| Future Wi-Fi devices will be able to see through your home and
| business walls, for activity monitoring and biometric
| identification,
| https://www.theregister.com/2021/03/31/wifi_devices_monitori...
|
| _> In three years or so, the Wi-Fi specification is scheduled to
| get an upgrade that will turn wireless devices into sensors
| capable of gathering data about the people and objects bathed in
| their signals... When 802.11bf will be finalized and introduced
| as an IEEE standard in September 2024, Wi-Fi will cease to be a
| communication-only standard and will legitimately become a full-
| fledged sensing paradigm... tracking can be done surreptitiously
| because Wi-Fi signals can penetrate walls, don 't require light,
| and don't offer any visible indicator of their presence._
|
| IEEE 802.11bf paper: https://arxiv.org/abs/2103.14918
|
| Papers on device-free wireless sensing (DFWS):
| https://dhalperi.github.io/linux-80211n-csitool/
|
| Remote sensing with low-cost ESP32 and 802.11n:
| https://academic.oup.com/jcde/article/7/5/644/5837600
| beermonster wrote:
| And let's not forget also Amazon Sidewalk
|
| Scary times.
| doggodaddo78 wrote:
| Yup.
|
| Even radiuz was probably better.
|
| https://wifinetnews.com/archives/2004/06/radiuz_combines_wpa.
| ..
| swiley wrote:
| Only if you tolerate devices with non-free software.
| ethbr0 wrote:
| Like any TV?
| swiley wrote:
| Yeah or anything else with non-free firmware.
| doggodaddo78 wrote:
| So, everything practical.
| neolog wrote:
| Commercial displays are a solution here, though they're
| expensive.
| danielheath wrote:
| Expensive compared to the advertising-subsidised consumer
| version, maybe.
| ethbr0 wrote:
| Expensive compared to retail- _volume_ models. This is
| also a fight against manufacturing economies of scale.
| FridayoLeary wrote:
| Is that some sort of hatch in the pavement? You order
| something on Prime, and moments later, a slab embossed with
| Amazons' logo opens, a deliveryperson jumps out and deposits
| the package into your outstretched arm.
| doggodaddo78 wrote:
| Almost. It's anyone with Amazon IoTs sharing wifi with each
| other.
| salawat wrote:
| This is one of those things that shouldn't even have a standard
| made for it.
|
| What does everyone think is going to happen with capabilities
| like that?
| quickthrowman wrote:
| Yeah, this tech standard is totally insane, why would I want
| anyone or anything to be able to scan people and objects
| inside my house without my knowledge? I'm aware of microphone
| attacks for keyboard password entry and other methods of
| surreptitious surveillance, but this is way past a microphone
| or webcam. I will pay a massive premium to purchase WiFi
| equipment without this feature.
|
| Unfortunately these will be everywhere, far beyond any
| existing camera surveillance network.
| transpute wrote:
| It's also passive. Someone can stand outside your house
| with their device and "illuminate" your activity inside the
| house. Only EMF shielding in the walls can block them.
| transpute wrote:
| Good news, the paper mentions privacy.
|
| _> We identify a number of critical issues that need to be
| addressed in this space... First, individuals should be
| provided the opportunity to opt out of SENS services - in
| other words, to avoid being monitored and tracked by the Wi-
| Fi devices around them._
|
| Bad news, the paper proposes remote human identification by
| every Wi-Fi device.
|
| _> This would require the widespread introduction of
| reliable SENS algorithm for human or animal identification._
|
| Would opt-in be legally easier than requiring human body scan
| registration for opt-out of Wi-Fi remote sensing?
| brobdingnagians wrote:
| It would be better to have a beacon that simply broadcasts
| that you do not want to be tracked, with no further
| identifying features. There isn't really a good reason for
| identifying you to then look up that you don't want to be
| tracked. Make that legally binding and enforce it.
|
| Or, better yet, make it totally opt in.
| farrelmahaztra wrote:
| How would opt-in work in practice? Say, if this gets
| pushed out on $CAFE public wifi for analytics. Would it
| be something akin to "tick this consent box to use the
| wifi"?
|
| And if $CAFE tracks you regardless of you not ticking the
| box or connecting to the network, how do I detect that as
| a regular customer?
| neolog wrote:
| Is it practical to put a Faraday mesh into the exterior walls
| of a house?
| farrelmahaztra wrote:
| In addition to that, you might want/need to use only wired
| connections to your router and rip out any components that
| enable wireless.
| FridayoLeary wrote:
| With 2 conditions; a) you would have to do it _before_
| closing up the walls and b) give up on radio.
| johnklos wrote:
| I think this will make for an excellent litmus test for companies
| that make wifi products. Is this a critical fix? No. Is it
| important, if not critical? Yes.
|
| Some vendors aren't going to care about this in the least and
| won't offer any updates.
|
| Some will only fix this in new and future devices.
|
| And perhaps some will update all their devices going back several
| years.
|
| Currently I buy used 802.11ac Airport Extremes for wireless for
| people because they're simple, they stay out of the way, and the
| last time there was a major update, Apple updated every Airport
| model all the way back to the Airport Express from 2008.
|
| But I want to be able to buy new wifi devices, and how vendors
| handle this will inform me about which ones I'll buy going
| forward.
| jtchang wrote:
| I wonder if hardcoding your DNS servers will help. I guess
| sometimes this is not possible because in corporate environments
| DNS servers are sent via DHCP.
| beermonster wrote:
| " More technically, the impact of attacks can also be reduced
| by manually configuring your DNS server so that it cannot be
| poisoned. Specific to your Wi-Fi configuration, you can
| mitigate attacks (but not fully prevent them) by disabling
| fragmentation, disabling pairwise rekeys, and disabling dynamic
| fragmentation in Wi-Fi 6 (802.11ax) devices."
|
| So yes, but as you say lots of things can override your
| explicit DNS settings. Even browsers can do it these days.
|
| Run WireGuard. Effectively treat WiFi as untrusted and VPN over
| it. Have WireGuard send over your DNS on the other side, and
| have that DNS use D-o-T or D-o-H depending on your threat
| model.
|
| Use Ethernet on stationary devices, and WiFi on mobile devices.
| Reventlov wrote:
| Mathy strikes again ! This has been fixed in Linux and certain
| firmware / driver already: https://lore.kernel.org/linux-
| wireless/20210511180259.159598...
| beermonster wrote:
| So these patches are for " Linux IEEE 802.11 implementation
| (mac80211)" and ath10k/ath11k.
| DanAtC wrote:
| Only because they agreed to sit on the patches for an
| inordinate amount of time.
|
| Theo de Raadt did the right thing for KRACK. Shame it would be
| his only chance to do so before getting kicked out of Mathy
| Vanhoef's secret club.
| wing-_-nuts wrote:
| I'm out of the loop. Expand?
| spijdar wrote:
| From someone mostly out of the drama loop, here's my brief
| recollection:
|
| Generally in the security sphere we consider it the most
| ethical and responsible to give vendors plenty of time to
| patch vulnerabilities, especially critical ones, before
| publishing details or anything that could lead to a working
| 0-day exploit.
|
| Theo de Raadt was one of the people notified of a previous
| WiFi exploit, and there was a set length of time intended
| for the vulnerability to be made private, in order for the
| (inordinately slow) vendors to create and push/prepare
| patches. If the patches were released early, it'd be easy
| to determine what the original vulnerability was.
|
| So, Theo de Raadt decided, in the interest of keeping
| OpenBSD secure, to push the patch early, effectively
| letting the whole cat out of the bag. I'm not going to get
| into the drama of whether that was right, wrong, foolish,
| wise, whatever, but because of that, he no longer receives
| these ahead-of-time notifications of vulnerabilities.
| anjbe wrote:
| There are at least two things wrong with this comment.
| First, OpenBSD did not push the patch earlier than
| agreed. Second, OpenBSD did not push the patch without
| permission.
|
| Mathy originally reported the vulnerability to OpenBSD on
| July 15 under embargo, and estimated it would be lifted
| by the end of August (1.5 months after disclosure). Theo
| argued that 1.5 months was too long, but didn't push the
| patch. Then on August 14, Mathy said the final public
| disclosure date would be October 16 ( _three_ months
| after initial disclosure), but agreed to allow OpenBSD to
| patch early. Although he didn't like it, and has since
| said he would not give such permission again, he agrees
| that OpenBSD did commit with his permission.
|
| Direct quote from Mathy: "From my point of view, I sent
| one mail on 14 August where I mentioned the new
| disclosure date of 16 Oct. In that same mail I also gave
| the OK to quietly commit a fix."
| https://marc.info/?l=openbsd-tech&m=152909822107104&w=2
|
| People portray OpenBSD as a project that ignores
| embargoes, and point to KRACK as an example. But Theo
| _didn't_ ignore the KRACK embargo. Rather, Theo
| successfully persuaded Mathy to allow OpenBSD to patch
| the vulnerability a full month and a half after all
| vendors had been informed.
|
| I'm commenting on this because I think simply pushing
| back against the length of an embargo should not be
| characterized as breaking an embargo.
|
| There were a lot of vendors in the KRACK embargo. The
| risk of the vulnerability leaking to the black market or
| malicious governments is real. As the length of the
| embargo increases, this risk increases dramatically. Big
| vendors are incentivized to pressure researchers to
| extend the embargo as long as possible. Open source
| projects are forced to hold off on committing bugfixes,
| leaving their users potentially vulnerable. If a project
| pushes back against a long embargo, or through persuasion
| manages to finagle permission to release an unobtrusive
| fix "early," that project is characterized as an
| untrustworthy embargo breaker and left out of future
| embargoes. So open source projects are incentivized to
| sit down, shut up, ignore the threat to their users, and
| let the big vendors dawdle in their bugfixes.
| spijdar wrote:
| Thanks for the clarification/correction.
|
| I have just one more thought on the matter. I'm still
| early in my career, but in the years I've spent so far
| working with small business-types on security, and
| watching my colleagues, a month and a half is practically
| no time at all. I have little love for the big vendors,
| especially for behavior like this, but the reality I've
| seen is they often take months to do anything, and it
| takes further months for customers to actually patch
| their systems.
|
| So I'm a little sympathetic to the desire to have an
| embargo of half a year or even longer, even with the
| downsides mentioned. Still, Theo clearly didn't actually
| breach his trust with Mathy, that's my mistake.
| josephg wrote:
| > a month and a half is practically no time at all
|
| A month and a half is plenty of time, but it requires (1)
| the company decides that fixing security bugs is top
| priority. (2) They need a senior engineer or two on hand
| who are smart enough to understand the issues involved
| and implement a fix. And (3) They need a decent release
| process which allows security fixes to be promptly rolled
| out to users.
|
| I'm not sure where most companies fail here. It's
| certainly easy to downplay and deprioritize security
| fixes from the inside, when you have a big deadline
| coming up, or your customers are yelling at you or a
| refactor is blocking other people from doing their job.
| Security issues from the inside never feel like the "all
| hands on deck" emergency situations that security
| researchers believe them to be. (And I'm not sure if this
| is right or wrong, just, the experience I've always had
| from the ground when security issues potentially affected
| _us_.)
| ygjb wrote:
| https://www.krackattacks.com/
|
| Probably referring to the internet drama related to silent
| patching and disclosure embargo. There are some details
| here, and others on various mailing lists, including an
| airing of differences if you want to look for that sort of
| thing after making a bowl of popcorn.
| SCHiM wrote:
| """ How can the adversary construct unencrypted Wi-Fi frames so
| they are accepted by a vulnerable device? First, certain Wi-Fi
| devices accept any unencrypted frame even when connected to a
| protected Wi-Fi network. """
|
| This actually made me angry. How fucking long are we doing this
| already? This is so. basic. Why is this possible? This should
| incur liability, we know the IT environment is adversarial.
|
| I understand one can make technical mistakes, or shoot oneself in
| the foot in low level languages that are difficult to handle
| correctly. But this is a conceptual mistake, involving crypto!
| How can you possibly have written this code for an issue like
| this to occur? What is the control flow that leads to this? I
| almost cannot imagine how someone could code this up by accident,
| this must be a backdoor. Just imagine: if
| decrypt(encrypted) == false { memcpy(plaintext,
| encrypted); // lets try to use the encrypted data anyway, you
| never know! } handle_packet(plaintext);
| Reventlov wrote:
| WiFi has always been developed on being retro-compatible. The
| good side is you can use something from 2003 with AP from today
| (let's ditch the 5MHz and 10MHz bandwidth), the downside is you
| have a big stack of technical debt in most of the chipset out
| there, which might be why this kind of things happens.
|
| Not having any access to the firmware source (thanks FCC) does
| not help at all.
| thereddaikon wrote:
| Why is it the FCC's fault specifically? The FCC doesn't
| regulate Intellectual Property. They regulate radios. Are you
| implying its within the FCC's power to say radio firmware
| must be open source?
| the8472 wrote:
| They require that users can't use restricted frequency
| ranges or raise the power level. The easiest and cheapest
| way for manufacturers to comply is to lock down firmwares.
| And since they didn't _also_ require open firmwares that 's
| the effective outcome in many cases.
| avidiax wrote:
| Even with encryption turned on, there will be plaintext packets
| you must process (e.g. to start the session). So it requires a
| whitelist to properly enforce, but all your conformance tests
| will pass without it. Easy to miss.
| riobard wrote:
| By now it's probably easier in mind to treat any Wi-Fi as Open
| Network and always use something like WireGuard/Tailscale for
| secure communication between devices.
| doggodaddo78 wrote:
| Yeap. I'm trying to remember if 802.11x would help or it's just
| AAA. Point-to-point tunnels up one layer are the way to go.
| DanAtC wrote:
| If only we knew 6 months earlier after a _reasonable_
| disclosure.
| fmajid wrote:
| It's always been my working assumption that WiFi security
| should be presumed to be broken until it is proven to be
| broken.
| Pick-A-Hill2019 wrote:
| The chained CVE's made for interesting reading. Book-marked for
| future reference when I have my SDR to hand.
| DanAtC wrote:
| A 9 month embargo is disgusting. Linux users have been sitting
| ducks while others may or may not received silent updates.
| _Nat_ wrote:
| I appreciate the distaste for a security-vulnerability being
| sat on for so long. However, the appropriateness of a long-
| embargo would seem like a bigger topic.
|
| That said, about being sitting ducks.. dunno how much the
| situation really changes like that. For example, was this
| really unknown before this particular discovery? And what other
| vulnerabilities aren't currently being reported, whether under
| embargo or not?
|
| Seems like users ought to have reasonable expectations about
| how secure popularly practiced technology is. If someone
| believed that a vulnerability like this wasn't a possibility,
| then they may need to update their expectations.
| haukem wrote:
| Often many companies and organizations from many countries are
| getting informed about such security problems under the
| embargo. I assume that the intelligence agencies form many
| countries are also getting these information. Either they are
| officially informed, because they also protect the government
| networks or they have just good working relationships with
| their local companies.
|
| I assume Microsoft would inform the NSA about such things,
| Huawei would inform the Chinese intelligence agencies and
| Siemens would inform the German BND.
| DanAtC wrote:
| And those nations got a chance to freely exploit it* for way
| longer than a typical reasonable disclosure of 90 days.
|
| *Assuming they didn't already know about it which is why fast
| disclosure is so important.
| Dah00n wrote:
| I can't read from your comment if you think this is A Good
| Thing. In my opinion it is s Very Bad Thing. None of those
| entities are more important than everyone else. If anyone
| should be alerted it should only be those that fix the
| vulnerability in WiFi devices. Anyone else and not only does
| the risk of leaks rise exponentially but some of them will
| rub their fingers with glee and exploit it ASAP.
| haukem wrote:
| I think such long embargoes are bad.
|
| Embargoes prevent that the average cyber criminal knows
| about the problems, but the resourceful organizations
| already get the information before the public knows about
| them. I think even 90 days are pretty long.
|
| For example 253 vendors were informed about the problem in
| dnsmasq about 3 months before it was published:
| https://www.kb.cert.org/vuls/id/434904 (all vendors listed
| here were informed) In each organization probably multiple
| people know about this.
| lwhi wrote:
| I just checked for an update for my TP Link Rouer, nothing yet.
|
| How likely are large manufacturers likely to react to this?
| jeroenhd wrote:
| From my experience with TP-LINK software, you don't need to
| worry about this attack. The attack demonstrated is complex,
| requires physical proximity and a lot of knowledge about the
| target.
|
| Meanwhile, your router will probably give any attacker root if
| they ask it nicely. TP-Link doesn't seem to care about device
| security at all if you're already paid for the device, so don't
| expect any updates and expect a whole range of vulnerabilities
| to be exploitable against your router.
|
| Now, it must be said, TP-Link is no D-Link, a company that
| almost seems to add security problems to their software
| intentionally with their awful software quality, but if you're
| conscious about security, any consumer device will probably
| have a whole bunch of exploits that would work easier and more
| reliably.
|
| EDIT: replaced the word "access" with "proximity" to avoid
| confusion.
| darkarmani wrote:
| > requires physical access
|
| What? You just need a high enough gain antenna and you can
| carry it out much further away than it appears your wifi
| reaches. Isn't physical access, being able to touch the
| computer?
| jeroenhd wrote:
| I suppose I used the term wrong, but you do need to be
| within receiving range _and_ depending on the attack you
| need to win a race condition, so it 's not that far from
| the generally accepted use of "physical access".
|
| Meanwhile, many consumer routers can be hacked by adding
| something similar to  to a page or
| malicious ad. I don't think general consumers should be
| worried about someone aiming a high gain antenna at your
| router unless you work at a company dealing with sensitive
| information or places like embassies. The alternatives are
| much easier and much cheaper to execute.
| Dah00n wrote:
| If the device didn't first appear on the market in the last six
| months? About as likely as Apple opening their hardware.
| beermonster wrote:
| Well you may find you can run (but May understandably not want
| to) OpenWRT on your TP Link Router. And OpenWRT released an
| update following KRACK
| crookshanked wrote:
| From my own experience with TP Link routers I don't expect them
| to update at all.
| inetknght wrote:
| > _certain devices accept plaintext aggregated frames that look
| like handshake messages. An adversary can exploit this by sending
| an aggregated frame whose starts resembles a handshake message
| and whose second subframe contains the packet that the adversary
| wants to inject._
|
| That reminds me of a thread [0] that came up a month ago
| mentioning discussion of packets in packets [1]. That paper was
| from 2011!
|
| [0]: https://news.ycombinator.com/item?id=26778236
|
| [1]:
| https://static.usenix.org/events/woot11/tech/final_files/Goo...
| mdeck_ wrote:
| "Frag" as a portmanteau of FRagmentation and AGgregation is
| hardly a non-ambiguous choice of terminology.
| 1vuio0pswjnm7 wrote:
| Suprised there is nothing in the "Q&A" that refers to wired
| devices. As if there is no choice.
| SavantIdiot wrote:
| Fragmentation is usually disabled in home APs. I've played with
| it on hostapd, but didn't find a performance improvement, and
| investigating withe WireShark found even 64k packets were not
| being fragmented. Is the same true for enterprise AP?
| Dah00n wrote:
| It's enabled with WiFi6 so a forward compatible vulnerability!
| pmlnr wrote:
| > By default devices don't send fragmented frames. This means
| that the mixed key attack and the fragment cache attack, on their
| own, will be hard to exploit in practice, unless Wi-Fi 6 is used.
| When using Wi-Fi 6, which is based on the 802.11ax standard, a
| device may dynamically fragment frames to fill up available
| airtime.
|
| Why does this feel like Spectre? We're trying to speed things up
| in a way that eventually blows back into our face.
| dylan604 wrote:
| Does it have anything to do with the speed of
| development->deployment? If something that is going to be
| standardized is rushed, then these kind of easily-ish found
| flaws will continually haunt us. If things slowed down and
| allowed a serious amount of pentesting before standarization,
| then maybe we can avoid these herpes like flaws where they sit
| dormant and then flare up, but can never be eliminated once
| discovered.
| lupire wrote:
| Doubtful.
|
| > several of the newly discovered design flaws have been part
| of Wi-Fi since its release in 1997!
|
| And spectre is also based on a decades old documented flaw.
|
| It's just not very practical to predict every feasible attack
| until a lot of people have real systems to explore.
| high_byte wrote:
| why do you need complex systems at all? just use a flat memory
| system with no kernel. no stack cookies. in fact, no internet
| is probably better.
| miles wrote:
| From the industry response[1]:
|
| > "It's important to note that there is presently no evidence of
| the vulnerabilities being used against Wi-Fi users maliciously
| and these issues are mitigated through routine device updates
| once updated firmware becomes available.
|
| > "Like many previous vulnerabilities, FragAttacks has been
| academically well-researched and responsibly reported in a manner
| allowing the industry to proactively prepare and begin to roll
| out updates that fully eliminate the vulnerabilities. This set of
| vulnerabilities requires a potential attacker to be physically
| within range of the Wi-Fi network (or user device) in order to
| exploit it. This significantly reduces the likelihood of actual
| exploitation or attack."
|
| [1] https://www.commscope.com/blog/2021/wi-fi-alliance-
| discloses...
| lupire wrote:
| How would a victim know if someone in a coffeeshop used this
| attack?
|
| > these issues are mitigated through routine device updates
| once updated firmware becomes available.
|
| Unless you are one of the millions upon millions of people who
| have an Android device that launched >3 years ago.
| tomaskafka wrote:
| > This set of vulnerabilities requires a potential attacker to
| be physically within range of the Wi-Fi network
|
| I have troubles imagining an attack on wifi protocol where this
| doesn't apply :).
| the8472 wrote:
| Back in the day you could disconnect some modems by sending
| certain strings over any higher level protocol, e.g. ICMP or
| IRC.
| segfaultbuserr wrote:
| I think this vulnerability is one of the most embarrassing
| blunders caused by a software patent.
| doggodaddo78 wrote:
| Back in the day, you could:
|
| - Hijack TCP sessions very easily with IP hijacking,
| especially telnet
|
| - DoS someone with a smurf attack
|
| - Ping of death windoze
|
| - Inject content into unencrypted pages (goatse everyone's
| web page backgrounds)
|
| - Get hacked by running inetd services
|
| - chargen ... nuf said
|
| - Apply a zillion patches to a Solaris box but break 10
| other things
| darkarmani wrote:
| > requires a potential attacker to be physically within range
| of the Wi-Fi network (or user device) in order to exploit it.
|
| So everyone that lives or works in a city? That can't be many
| people can it?
| asclepi wrote:
| I agree with the industry response here. KRACK was the same
| thing. The author finds a vulnerability that is _absolutely
| valid_ (no denying here), easy to exploit in a lab but very
| hard to exploit in practice. Back in the day, we did test our
| equipment for KRACK. We concluded that someone had to
| circumvent all our physical security barriers (challenging, but
| theoretically possible) to get close enough to an AP that would
| see sensitive stuff, had to know WHEN to do that, or at least
| plant a device that could easily be noticed, and they would
| still fail because we didn 't have 802.11r enabled on those
| AP's.
|
| Is it a concern? It depends on what you're doing. It is
| absolutely a concern if your corporation is handling ultra-
| sensitive information. However, you should also question your
| physical barriers in that case and whether you should use Wi-Fi
| at all for some aspects of your operation. Is it a concern for
| the vast majority of office workers or someone at home?
| Probably not; there would be easier ways to find a valid credit
| card number that don't involve the time and effort for a hacker
| to travel to your place where they could be discovered. There's
| no need to replace all your AP's with new hardware, although
| the Wi-Fi Alliance would love for you to do that.
|
| Does this exploit warrant its own fancy name and domain name?
| As was the case for KRACK, I don't believe so. That should be
| reserved for vulnerabilities that have a severe impact AND are
| extremely trivial to exploit with no proximity requirements. If
| not, the fancy-name-vulns risk being deprived of their ability
| to get the attention that is required.
| gipsies wrote:
| Several of the implementation flaws allow an attacker to
| essentially inject plaintext frames in a Wi-Fi network. All
| that's needed is being within range of the network (with an
| extender you can still be far away). I agree that the design
| flaws aren't that serious! But that's also explicitly
| mentioned on the website so...
|
| Edit: injection can be used to punch a hole in the router's
| NAT so someone can directly try to attack your devices. As
| always there world isn't burning down. But I think it's
| interesting research :)
| asclepi wrote:
| I agree, it absolutely is interesting research, and I
| appreciate the detailed explanation that was published.
|
| Although the proximity requirement severely limits the
| possible impact, it does make us think again about the
| security of our Wi-Fi networks, and as a result we may
| identify areas to improve, which is a benefit.
| Dah00n wrote:
| >[KRACK] easy to exploit in a lab but very hard to exploit in
| practice
|
| How so? Even I have done it (on my own AP). Unless you own a
| big property that the WiFi signal cannot reach outside it's
| as easy as pressing GO in one of the hundreds of script
| kiddie tools.
| noja wrote:
| > I agree with the industry response here.
|
| I don't. This sentence serves no purpose other than
| distraction and needs to stop being used: "there is presently
| no evidence of the vulnerabilities being used".
|
| It's a standard sentence that is rolled out for any security
| event or breach usually to misdirect blame. It needs to go
| away.
| zwp wrote:
| I disagree: for defenders trying to establish veracity of
| flaws and prioritizing defense this is useful information.
| "Active exploits seen in wild" is a strong signal.
|
| Picking two potentially high impact announcements from the
| last month or so:
|
| 1. There is a severe flaw in the RSA cryptosystem. 2. There
| is a remote code exec vulnerability in Microsoft Exchange.
|
| One of these was a sketch of an incremental improvement to
| an attack that remains mostly of theoretical interest. The
| other was being actively exploited, was tragically simple
| for 3rd parties to replicate post-announcement and resulted
| in widespread pain.
|
| There is some (non-linear) scale here (theoretical
| flaw/poc/weaponized poc/public poc/public weaponized
| poc/exploited, but limited actors or targets/widely
| exploited/HAVOC). MS for example uses just "less likely to
| be exploited", "more likely to be exploited" "being
| exploited". It's coarse and somewhat subjective but there
| is value even so.
|
| "This flaw is being actively exploited in the wild" is the
| best line I can take upstairs. I don't want to see that go
| away just because some parties might misuse it.
| risedotmoe wrote:
| I've always felt an always listening radio, especially the ones
| in televisions that try to connect to anything it can, in any
| device is a big gaping security hole. We've already seen how
| Bluetooth makes things vulnerable. If you're truly worried about
| security, go with the cable.
___________________________________________________________________
(page generated 2021-05-11 23:00 UTC) |