WPA2 bugz - One Man's Quick & Dirty Response

Wed Oct 18 17:27:52 UTC 2017

Hi Ronald,

Le 18/10/2017 à 06:00, Ronald F. Guilmette a écrit :
 >
 > In message <49252eda-3d48-f7bc-95e7-db716db4ed91 at whitewinterwolf.com>,
 > "WhiteWinterWolf (Simon)" <freebsd.lists at whitewinterwolf.com> wrote:
 >
 >> Ideally, you would use a specific protection for each of these layers,
 >> so that an vulnerability affecting one layer would be compensated by
 >> other layers.
 >
 > A good point.
 >
 > Right about now, I wish that I knew one hell of a lot more about both
 > NFS and SMB than I do... and also SSH and TLS.  I suspect that the
 > file sharing protocols I am most concerned about (NFS & SMB) could
 > perhaps be run in a manner such that both initial volume mounts and
 > also data blocks (to & from) the share volumes would be additionally
 > encrypted, so that I could be running everything securely, even if
 > some attacker managed to do maximally evil things to my WiFi/WPA2
 > network.
 >
 > Do NFS and/or SMB have their own built-in encryption?

No, not really.

NFS has no built-in encryption, it may be possible to tunnel it but this 
is out-of-scope here (using a VPN and tunnel everything would be easier 
than nitpicking and tunnel only the NFS data flow).

SMB has no widely compatible encryption:

- Microsoft has built its own, proprietary encryption available and 
compatible only with the latest Windows versions.
- Open source implementations rely on TLS, natively supported by some 
client but requiring (AFAIK) `stunnel` server-side.

 > Please note that I am asking only about what is -easily- possible.

Securing in-transit NFS and SMB communication is not part of this.

 > I don't even really know how SSH works.

I don't know what kind of device / server you are using to store and 
share your files.

If your files repository proposes a web interface, it may be as simple 
as going in the SSH/SFTP tab, check the "enable" box, and access your 
files through an SFTP-capabe client such as FileZilla (AFAIK, FreeNAS, 
since we are on a FreeBSD mailing list, supports SFTP shares natively).

For a basic usage you don't need to dig into the details of how the SSH 
protocol works and the impressive number of features it offers. Simply 
know that one of its features is SFTP, standing for Secure File Transfer 
Protocol, so when you need a protocol to securely transfer files then 
SFTP can do it.

 > The only think I do know is that it is possible to use it to both start
 > up and continue a secure connection, even in the presence of utterly
 > compromised data links.  And I gather than this is also -the- fundamental
 > and inherent feature of TLS also.)

You're right.

 > Please note that I am asking only about what is -easily- possible.  I
 > wish that I had time to learn in depth about all things crypto (starting
 > from my very low starting point) but I don't.  And I'm just running a
 > little home network here, not a network for, say, a huge corporation
 > or for a sprawling factory floor.  So I just doesn't make sense for me
 > to spend, say, 200 man hours to get something working.  I just don't
 > have that kind of time to devote to this.

I understand, that's why I mention SFTP which is usually a widely 
supported, painless and secure way to transfer files over a potentially 
untrusted network.

 > Basically if there is an -easy- crypto-protected way of mounting volumes
 > and then accessing them, either for NFS or for SMB (or both) then I do
 > think I'd like to try that.

This is becoming more-and-more a concern.

NFS, but that's my opinion, is a rather historical protocol so I don't 
think there will be any major evolution there.

As stated above, the SMB protocol is evolving to better protect 
in-transit data, but there are business interests here at play which 
prevents, for now, the users from having any simple and 
widely-compatible solution.

As a reminder SMB is an undocumented proprietary protocol from 
Microsoft. Open-source implementations have been done by individuals 
reverse-engineering Microsoft's own work. Having Microsoft and the 
open-source community stretching in different directions pursuing 
different goals is not the best situation for a quick and sane evolution 
of the protocol.

 >> All sensitive operations should be done using secure channels.
 >> The most versatile secure channel is setting-up a custom VPN within your
 >> LAN...
 >
 > Frankly, I must sheepishly admit that have no idea how to even begin to
 > do that.  Pointers to tutorials would be appreciated.
 >

Hence the following of my sentence: "but there are other alternative".

"Versatile" and "easy-to-use" are often very different things.

 > Note also that whatever I do in this regard, I have to be able to entice
 > or coerce at least one of (a) OpenELEC/LibreELEC and/or (b) Windoze7
 > to follow suit.

For OpenElec, this may become an issue if you are using it to access 
sensitive files. But usually this is not the case.

For "Windoze7", according to this post:

https://security.stackexchange.com/q/171542/32746#171546

It seems that updating the client might be enough to thwart most of the 
attack. Windows 7 is still supported for security updates, so I don't 
doubt that Microsoft will release a fix for this system if this is not 
already done.

Other than that, there are various solutions to protect browsing data:

- You can use a paid VPN service. Again, you don't need to learn how to 
setup a VPN: all the work is done by the VPN provider services and they 
provide straightforward assistants to automatically configure your system.

- You can use EFF's HTTPS Everywhere add-on and configure it to access 
only HTTPS websites, but this will most likely block a lot of websites.

- Some browsers include proxy capability natively to protect your data 
from untrusted network, such as the Opera with its "VPN" feature and the 
TOR browser.

The advantage is that such solution would work everywhere, so you can 
take your Windows 7 laptop at a cyber-cafe or access an airport WiFi and 
still benefit from the level of safety in your browsing than at your home.

 > Well, as I mentioned earlier, my Amazon Fire TV box doesn't need to
 > access anything from my local file server, but it *does* somehow
 > (and mostly automagically) access protected content off the Internet,
 > via my local WiFi network.  At the moment, I don't even know if
 > whatever credentials of mine that are stored in, and transmitted from
 > that box are at risk, and I have even less of an idea of how to
 > secure them if they are indeed at risk.

Amazon seems to be currently working on this:

https://www.aivanet.com/2017/10/amazon-says-a-patch-for-wpa2-exploit-krack-is-in-the-works/

As always, with proprietary devices and software you are not in control 
on what the device is doing, don't even have any reliable understanding 
of it and rely on the upstream vendor for any change.

 >> 2) An attacker may use your Internet access for his own purposes.
 >
 > Yea, I've gathered at least that much.  It is a worrying possibility,

Not so worrying actually.

Now that I've better checked this new attack, it doesn't sound as 
devastating as the previously mentioned WEP issues, at least not in its 
current stage (and WPA2 being better engineered than WEP, chances are 
that the story will not repeat).

An attacker is able to join the WiFi network only if you use Wireless 
Gigabit (WiGig) which is quite uncommon. Common WiFi access (WPA2 CCMP, 
WPA TKIP) only allow an attacker to intercept and manipulate users data, 
not to join the network or obtain the network's password.

 > but as I have pretty crappy (low) bandwidth, I think that if bad guys
 > show up in my neighborhood, they will easily find much better pickings
 > from some of my neighbors.  So for the moment, I'm not going to worry
 > about this, but of course, I'm going keep my ear to the ground, and will
 > patch my router and my WiFi clients the minute patches or these things
 > are available.

Patches for computer-based devices should come very soon (if not already 
available).

Depending on the providers and involved parties, it may take more time 
for mobile devices and router firmwares (the worst case being 
carrier-provided previous-generation Android smartphones: I wouldn't be 
surprised that a large portion of them will never be fixed).

 > I feel sure that I am probably speaking for a few hundred million people,
 > all over the world, when I say that this whole WPA2 debacle is really
 > rather entirely annoying.  But with helpful folks like you around, even
 > the dunderheads like me will probably manage to make it through this mess
 > without too much pain.

Thank you for your kind words.

At least, the mediatisation of this flaw puts pressure on software and 
devices providers to fix this flaw and not ignore it. Maybe, the most 
useful thing that this "hundred million people" can do is keep an eye on 
these providers and push to get it fixed.

Manufacturers often neglect security for end-users devices (it costs 
money while not being a selling-point). Such "debacle" may be have its 
advantages from time-to-time to make people think on how they use their 
devices. As a security engineer, I obviously campaign for safer devices 
and tools which provide security without even the user noticing it. But 
there are other interests in the field, so it may not be completely bad 
that people are reminded that technology may not be blindly relied upon.

Regards,
Simon.

-- 
WhiteWinterWolf
https://www.whitewinterwolf.com