10-29-17 06:55 AM
30 12
tools
  1. tubularbell's Avatar
    How will this be adressed by BlackBerry? And will the Android 6.0 now be upgraded on Priv and DTEK'S to at least Nougat? Because 6.0 seems to be most vulnerable...
    10-16-17 06:16 AM
  2. Erik_1991's Avatar
    security patches should adres this issue.. more concerned about routers, don't think they'll get a patch any time soon
    10-16-17 06:26 AM
  3. howarmat's Avatar
    priv wont be updated to android 7 but still can be patched if google patches android 6.
    10-16-17 06:29 AM
  4. Bla1ze's Avatar
    10-16-17 04:31 PM
  5. BerrySpawn's Avatar
    Don't forget to keep checking for an update to your home routers too. However, anyone's guess how conscientious businesses offering hotspots will be in updating their routers.
    10-16-17 05:29 PM
  6. Ment's Avatar
    It will be fixed in the Nov Android security patch. Since its a handshake issue, as long as one side: client or router is fixed it will be okay. Avoiding public wifi for a month is prudent.
    10-16-17 05:34 PM
  7. thurask's Avatar
    How will this be adressed by BlackBerry? And will the Android 6.0 now be upgraded on Priv and DTEK'S to at least Nougat? Because 6.0 seems to be most vulnerable...
    It's 6.0 and up that are especially vulnerable, Nougat and Oreo included. Once the November patch rolls around then devices will be fixed.
    10-16-17 05:39 PM
  8. tickerguy's Avatar
    It will be fixed in the Nov Android security patch. Since its a handshake issue, as long as one side: client or router is fixed it will be okay.
    That's NOT necessarily true..... unfortunately.

    Note that PUBLIC wifi (unsecured) isn't the problem. It's WPA2 "protected" WiFi, which is (probably) in your office, your house, feeding the nice "pay in your booth" tablet/card terminal in the restaurant or bar you're sitting in, etc.

    I haven't (yet) figured out if WPA2 / machine certificate secured networks are vulnerable to this attack. If they are then it gets VERY interesting even in places that have centralized and allegedly "done right" (e.g. PKI, etc) management -- think hospitals, etc. due to the myriad vendors and software versions involved in such an installation.
    10-16-17 05:45 PM
  9. Ment's Avatar
    That's NOT necessarily true..... unfortunately.
    Under what circumstance would a patched device using an unpatched router be vulnerable.
    10-16-17 05:46 PM
  10. tickerguy's Avatar
    Under what circumstance would a patched device using an unpatched router be vulnerable.
    If I can get into the traffic stream on either end I can cause trouble. The specific issue of effectively forcing a trivial key (e.g. all zeros) and thus being able to pick off all the traffic or worse, INSERT traffic, is a Linux bogism and not exclusive to Android (ALL SORTS of wireless "appliances", from the obvious such as an IP security camera on down have Linux OSs under them) but the underlying issue is in the actual definition for how the handshake is SUPPOSED to work, which opens all sorts of questions (like "who was in the room when that was being written and debated", for openers.)

    The OS folks are fixing this FAST but getting it out into the wild, given the amount of embedded-firmware gear out there that NEVER gets updated is another matter entirely.

    I'm still digging through code here myself; just saw the CVEs this morning. My assumption at present is that ANY WiFi network on which BOTH ends have not been patched must be regarded as "Open" and treated accordingly. I have some "stuff" out in the wild that's potentially subject to this in terms of OS exposure, but fortunately all communications with those devices are SSL protected on top of the WiFi and in the case of critical communications they're machine-certificate protected (rather than using a password), so even on an open network they're "safe" in that you can't get through the protocol. It'll be interesting to see if I start logging more attempts to break into them however. I've also got a StrongSwan gateway on my network and thus I can mitigate this when using my phone until patches start to show up..... at the cost of some battery power of course.
    10-16-17 05:58 PM
  11. Ment's Avatar
    If I can get into the traffic stream on either end I can cause trouble. The specific issue of effectively forcing a trivial key (e.g. all zeros) and thus being able to pick off all the traffic or worse, INSERT traffic, is a Linux bogism and not exclusive to Android (ALL SORTS of wireless "appliances", from the obvious such as an IP security camera on down have Linux OSs under them) but the underlying issue is in the actual definition for how the handshake is SUPPOSED to work, which opens all sorts of questions (like "who was in the room when that was being written and debated", for openers.)

    The OS folks are fixing this FAST but getting it out into the wild, given the amount of embedded-firmware gear out there that NEVER gets updated is another matter entirely.

    I'm still digging through code here myself; just saw the CVEs this morning. My assumption at present is that ANY WiFi network on which BOTH ends have not been patched must be regarded as "Open" and treated accordingly. I have some "stuff" out in the wild that's potentially subject to this in terms of OS exposure, but fortunately all communications with those devices are SSL protected on top of the WiFi and in the case of critical communications they're machine-certificate protected (rather than using a password), so even on an open network they're "safe" in that you can't get through the protocol. It'll be interesting to see if I start logging more attempts to break into them however. I've also got a StrongSwan gateway on my network and thus I can mitigate this when using my phone until patches start to show up..... at the cost of some battery power of course.
    It really needs an unpatched client to work as its a client based attack. From the web site.

    Our main attack is against the 4-way handshake, and does not exploit access points, but instead targets clients. So it might be that your router does not require security updates. We strongly advise you to contact your vendor for more details. In general though, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.
    I take this to mean it may be possible to find another way to compromise an unpatched client via a patched AP but not the other way around. Otherwise, all these MS,Apple,Google missives saying their devices aren't vulnerable or are/will be patched doesn't mean anything.

    In your example the patched client would not accept a zero key because its a Key Reinstallation - AP to client.

    There will probably be cases in the following days where workarounds for the AP patch are found to attack unpatched clients since the researchers themselves say patching the AP is a crutch.
    10-16-17 08:34 PM
  12. tickerguy's Avatar
    You are making a terrible mistake here -- you're assuming the attacker doesn't have an intentionally-vulnerable or hacked-up client he intends to attach to your network and then go after everything on it. This is why the APs have to be fixed as well as the clients. The issue is not just a MITM attack on an individual client, it is the potential to attach an unauthorized and actively hostile device to the network.

    I make no such assumptions on networks I'm responsible for; in fact my base assumption unless I have evidence otherwise is that every potential "drive-by" client is hostile and will actively seek to exploit whatever it can get into.

    There are a LOT of WiFi networks out there which are password-protected and thus "nominally secure" yet have hosts on them with little or no effort made to secure the services they run, or (much worse) are intentionally left insecure because they rely on WiFi security to keep unauthorized people out. The classic examples are NFS and SMB servers that have no security set up on them whatsoever. If you can get into that network you can literally steal, alter or erase anything exported by that host.
    10-16-17 09:24 PM
  13. Ment's Avatar
    You are making a terrible mistake here -- you're assuming the attacker doesn't have an intentionally-vulnerable or hacked-up client he intends to attach to your network and then go after everything on it. This is why the APs have to be fixed as well as the clients. The issue is not just a MITM attack on an individual client, it is the potential to attach an unauthorized and actively hostile device to the network.

    I make no such assumptions on networks I'm responsible for; in fact my base assumption unless I have evidence otherwise is that every potential "drive-by" client is hostile and will actively seek to exploit whatever it can get into.

    There are a LOT of WiFi networks out there which are password-protected and thus "nominally secure" yet have hosts on them with little or no effort made to secure the services they run, or (much worse) are intentionally left insecure because they rely on WiFi security to keep unauthorized people out. The classic examples are NFS and SMB servers that have no security set up on them whatsoever. If you can get into that network you can literally steal, alter or erase anything exported by that host.
    you're conflating other vulnerabilities in wifi. How does a patched client get compromised via the method(s) outlined in KRACK. Of course wifi will have future security holes, thats the nature of things and why having devices and companies that support timely updates is so important.
    app_Developer likes this.
    10-16-17 09:31 PM
  14. tickerguy's Avatar
    I am most-certainly NOT conflating vulnerabilities!

    If your AP can be tricked by a bad client into sending it a 0'd AES key then you're screwed as now the client is attached to your network, and you thought that network was secured and not able to be connected to.

    Once connected that node is a full member of said network. If you don't have AP isolation on he can see other wireless nodes. Even if you do, he can see all the WIRED nodes. If said network has access to other things (like the Internet, but not necessarily ONLY the Internet) said bad guy now has access to that those things too!

    No, patching the client is NOT enough. You also must close the hole so that an intentionally bad actor cannot use an intentionally weak client to break in to your so-called "secured" WiFi network. In fact in terms of being able to screw you blind it's far more likely in a business environment that the "common" (e.g. server, etc) resources are far more valuable than whatever might be on a random client machine.

    IF this can be exploited on a WPA2/AES network using machine certificates then it's even worse. In fact in that case it's catastrophically worse, which is why I've been spending a lot of time on this today and will keep doing so until I'm convinced that either (1) said networks are NOT impacted or (2) if I determine they potentially are, well, then I hope people are ready for a shizstorm of literally unprecedented severity. In fact in that case until ALL the APs involved are fixed all I can reasonably recommend to clients is that they turn them ALL OFF immediately, and yes, I realize that in many environments that's a completely "unreasonable" ask, and will be ignored, including in places where it might be catastrophically bad either financially or even in terms of safety if exploited.
    10-16-17 10:16 PM
  15. Dunt Dunt Dunt's Avatar
    I am most-certainly NOT conflating vulnerabilities!

    If your AP can be tricked by a bad client into sending it a 0'd AES key then you're screwed as now the client is attached to your network, and you thought that network was secured and not able to be connected to.

    Once connected that node is a full member of said network. If you don't have AP isolation on he can see other wireless nodes. Even if you do, he can see all the WIRED nodes. If said network has access to other things (like the Internet, but not necessarily ONLY the Internet) said bad guy now has access to that those things too!

    No, patching the client is NOT enough. You also must close the hole so that an intentionally bad actor cannot use an intentionally weak client to break in to your so-called "secured" WiFi network. In fact in terms of being able to screw you blind it's far more likely in a business environment that the "common" (e.g. server, etc) resources are far more valuable than whatever might be on a random client machine.

    IF this can be exploited on a WPA2/AES network using machine certificates then it's even worse. In fact in that case it's catastrophically worse, which is why I've been spending a lot of time on this today and will keep doing so until I'm convinced that either (1) said networks are NOT impacted or (2) if I determine they potentially are, well, then I hope people are ready for a shizstorm of literally unprecedented severity. In fact in that case until ALL the APs involved are fixed all I can reasonably recommend to clients is that they turn them ALL OFF immediately, and yes, I realize that in many environments that's a completely "unreasonable" ask, and will be ignored, including in places where it might be catastrophically bad either financially or even in terms of safety if exploited.
    I've seen a few articles that basically say turning of your clients Wi-Fi is the best solution right now.
    10-17-17 11:30 AM
  16. tickerguy's Avatar
    This is far worse than people think it is; it now appears to be confirmed that it will bite you with machine-certificate keys as well (which I suspected from looking at the code, but there are now people confirming the same thing.)

    This makes things really ugly..... the good news is that "force to zeros" key problem at the AP level only impacts a modest number of APs, or so they say. But is that true? You're literally playing "bet your network" if you believe it.

    BTW dd-wrt has patched code out, but in some cases (specifically the router I use) it failed to boot, so they've still got work to do (it IS marked "beta", so.... yeah.)
    10-17-17 01:37 PM
  17. bartman2468's Avatar
    The most vulnerable clients (victims devices) are Android and Linux due to their susceptibility to the key re-installation attack.
    "This is because Android and Linux can be tricked into (re)installing an all-zero encryption key. When attacking other devices, it is harder to decrypt all packets, although a large number of packets can nevertheless be decrypted.

    This WPA2 attack is a man in the middle, where the attacker creates a rogue AP that the victims device actually connects to (which they force), which obviously allows the attacker to then manipulate things - like the key reinstallation.

    The largest threats are improperly configured sites that can be lowered to HTTP with SSLstrip. Then the attacker can view the HTTP traffic and see username/password in plaintext - very quick/easy, so therefore most dangerous.
    10-17-17 03:36 PM
  18. tickerguy's Avatar
    Actually the biggest risk isn't in the conventional user space at all -- it's in the commercial space, where machine certificates are often used and internally there's no SSL or other encapsulation used because the network is allegedly "secure", or in "light commercial" (think restaurants with WiFi terminals at the table, bars, etc) where WPA2/PSK is used but again the comms to the back end are frequently not bothered to have SSL on them (it's a cost for the certificate or you must set up your own PKI, plus it slows things down) under the premise that the link is "secure."

    Well, not any more it isn't - and in fact it never was.

    This is going to hose people for literal years.

    BTW the Asus AC68R/U routers now have a DD-WRT (kong) build with the patch in it. I just loaded it here about two hours ago, so my AP is now fixed (and I've been kinda busy with people I work with in this regard most of the day, as you might imagine.)

    A few router/AP manufacturers have fixed it (Ubiquity, of note) as well but many more have it "in process", so who knows when..... You really need to fix BOTH ENDS lest someone with an unpatched client show up.....
    10-17-17 06:27 PM
  19. Ment's Avatar
    I am most-certainly NOT conflating vulnerabilities!

    If your AP can be tricked by a bad client into sending it a 0'd AES key then you're screwed as now the client is attached to your network, and you thought that network was secured and not able to be connected to.

    Once connected that node is a full member of said network. If you don't have AP isolation on he can see other wireless nodes. Even if you do, he can see all the WIRED nodes. If said network has access to other things (like the Internet, but not necessarily ONLY the Internet) said bad guy now has access to that those things too!

    No, patching the client is NOT enough. You also must close the hole so that an intentionally bad actor cannot use an intentionally weak client to break in to your so-called "secured" WiFi network. In fact in terms of being able to screw you blind it's far more likely in a business environment that the "common" (e.g. server, etc) resources are far more valuable than whatever might be on a random client machine.

    IF this can be exploited on a WPA2/AES network using machine certificates then it's even worse. In fact in that case it's catastrophically worse, which is why I've been spending a lot of time on this today and will keep doing so until I'm convinced that either (1) said networks are NOT impacted or (2) if I determine they potentially are, well, then I hope people are ready for a shizstorm of literally unprecedented severity. In fact in that case until ALL the APs involved are fixed all I can reasonably recommend to clients is that they turn them ALL OFF immediately, and yes, I realize that in many environments that's a completely "unreasonable" ask, and will be ignored, including in places where it might be catastrophically bad either financially or even in terms of safety if exploited.
    I haven't seen any advisory that patched clients need to avoid unpatched AP for the KRACK vulnerability; how would the end user know anyway. Thats why I say you're conflating. There may be other issues with keys but its not KRACK thats the problem or the fix.
    app_Developer likes this.
    10-17-17 07:51 PM
  20. tickerguy's Avatar
    I haven't seen any advisory that patched clients need to avoid unpatched AP for the KRACK vulnerability; how would the end user know anyway. Thats why I say you're conflating. There may be other issues with keys but its not KRACK thats the problem or the fix.
    That's not the issue.

    If I can get a 0'd key issued to me then I'm on the network (unauthorized!) Is everything on that network secure or isn't it -- like, for instance, your patched client?

    The number of networks that rely on physical security + Wifi WPA2 (to be equivalent to physical security) is rather high even in the corporate space. In the personal space (e.g. homes) it's ridiculously high.
    10-17-17 08:53 PM
  21. panopticon's Avatar
    This may seem like a naive question, so forgive me for my ignorance...is KRACK able to exploit the wireless traffic only (ie only the devices that are interconnected to each other wirelessly, via the AP's WIFI), or can it also be used access all traffic that is connected to the AP including hardwired connections?

    The reason I ask is if you keep your hardwired and wireless networks segregated (ie only a physical cable connecting the AP to the rest of the wired network) then is it not possible to protect your hardwired network (and all the hardwired devices connected to it) from KRACK?
    10-17-17 09:56 PM
  22. CrackPriv's Avatar
    It's 6.0 and up that are especially vulnerable, Nougat and Oreo included. Once the November patch rolls around then devices will be fixed.
    I am still waiting for the october update... It is hard to believe in BlackBerry and it is becoming harder every month.
    10-18-17 01:35 PM
  23. Dunt Dunt Dunt's Avatar
    I am still waiting for the october update... It is hard to believe in BlackBerry and it is becoming harder every month.
    Well if they were notified about KRACK back in July with other major suppliers.... possible they had to pull a few Android folks back over to BB10 in order to push out a security patch. Or maybe the release of the Motion has them a little swamped.

    I expect with the revenues that they are getting on Aurora and KEYone sales... they can only do so much.
    10-19-17 12:48 PM
  24. slam5's Avatar
    security patches should adres this issue.. more concerned about routers, don't think they'll get a patch any time soon
    Router has very little to do with it. It is a client (Windows, Mac, iOS, Android) issue mostly. Unless you are running your router in a mesh network, it should not affect you.
    10-19-17 06:31 PM
  25. Erik_1991's Avatar
    a okay.. i thought linux was also affected. and since plenty routers run a version with a Linux Base layer, i thought it was also affected. (Not IT so i might use rookie wording haha)
    10-19-17 06:34 PM
30 12

Similar Threads

  1. Replies: 41
    Last Post: 10-19-17, 02:16 AM
  2. Anyone have the wallet case for the passport?
    By Silverpassport4life in forum BlackBerry Passport
    Replies: 3
    Last Post: 10-16-17, 03:25 PM
  3. virtual keyboard for passport
    By wingnut666 in forum BlackBerry 10 OS
    Replies: 1
    Last Post: 10-15-17, 07:16 PM
LINK TO POST COPIED TO CLIPBOARD