freebsd security - Oct 2017 - WPA2 bugz - One Man's Quick & Dirty Response

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?  I have to ask,
because I honestly don't know.  If not, is it easily possible to add
or attach some additional encryption layer to those?  And if I did so,
would it even help any?  (I'm guessing that it might, just on the basis
of what little I know about SSH.  I don't even really know how SSH works.
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.)

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.

Basically if there is an -eay- 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.
>What you did is secure only the lowest layers and put no security on the 
>higher ones, the security of the complete stack relying on the lowest 
>layer security.
Yea, I think that I sort of got that.
>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.

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.
>At last remains Internet access. There are two threats there:
>
>1) An attacker may intercept your connection. He will not be in measure 
>to bypass HTTPS security though, so assertion such a "hacker can now 
>steal your passwords and credit card numbers" as heard this morning in 
>the news is bullshit as long as you ensure that your connection is 
>indeed secure through HTTPS thanks to the little padlock.
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.
>There are paid VPN services available on the Internet, some of them even 
>proposing smartphone apps. They are commonly and effectively used on 
>public WiFi network which are by definition untrusted, and would be an 
>easy way to secure your Internet access through an untrusted WiFi 
>without having to learn to setup a VPN server yourself.
Right, but how do I entice the Fire TV box to use such a thing?  That's
the enigma, I think... at least for me.
>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,
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.
>Your WiFi access point firewall may offer the possibility to restrict 
>outgoing connections to only the VPN server. This would effectively 
>restrict Internet access to hosts and devices able to authenticate 
>against the VPN server.
It doesn't. :-(
>I hope these few elements help you to see things a bit clearer and, 
>maybe, give you some useful ideas.
Yes, thanks.

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.

Thanks for your thoughts.


Regards,
rfg

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