
We took a hacker to a public WiFi café (2014) - hackerbeat
https://medium.com/matter/heres-why-public-wifi-is-a-public-health-hazard-dd5b8dcb55e6
======
zokier
> Many apps, programs, websites, and types of software make use of encryption
> technologies. These are there to ensure that the information sent and
> received from a device is not accessible to unauthorized eyes. But once the
> user is connected to Slotboom’s WiFi network, these security measures can be
> circumvented relatively easily, with the help of decryption software

> We do the same for Facebook: Slotboom is able to intercept the login name
> and password I entered with relative ease.

That sounds bit too good to be true. Facebook uses HSTS with preloaded
certificates. I certainly am not aware of any "relatively easy" way of
circumventing that.

> Everything, with very few exceptions, can be cracked.

Bit unnecessarily fatalistic attitude imho.

TLS is still pretty solid. Almost any half-decent VPN is non-trivial to crack.
While software has holes, zero-days are typically bit beyond "All you need is
70 Euros, an average IQ" guys, so keeping your systems patched is effective
measure.

Not saying that downgrade attacks etc aren't real threats, or that you don't
need to pay any attention. But you can be relatively safe with fairly basic
precautions and the overall situation is improving, one example being the
increased alerts from browsers.

~~~
ricardobeat
The article is from 2014 as indicated in the title. At the time HSTS was not
as widespread.

HSTS bypass hacks also exist, which let the attacker controlling the DNS man-
in-the-middle you through an insecure subdomain not in the HSTS preloaded
list. I’m sure the guy has kept up to date with new developments to keep his
job going :)

~~~
devinl
Do you have any more details around such an attack?

The only HSTS bypasses I am aware of that were possible with control over DNS
were dependent on browser vulnerabilities that have been long since fixed or
required the domain to not be cached or preloaded (which effectively means
you'd only be able to attack first time visitors on sites that have not
implemented preload who are clicking on an http link)

~~~
superpatosainz
There was once even an easy to use software that shipped with an attack. It
was called Firesheep and it let anyone skillful enough to install a browser
extension get into the Facebook and Twitter sessions of anyone who shares the
same network.

------
cbr
This is why Chrome is going to be marking all HTTP pages as "Not Secure" in
v68+: [https://security.googleblog.com/2018/02/a-secure-web-is-
here...](https://security.googleblog.com/2018/02/a-secure-web-is-here-to-
stay.html)

~~~
gsich
Does not help against sniffing Probe Requests.

~~~
JankySolutions
But sniffing probe requests doesn't get you much. You get a list of SSIDs
they've seen, which could be potentially bad, but not nearly as bad as
insecure sites not being marked as such.

~~~
gsich
Yes, but the article takes a focus on this too. But it's more useful for
tracking people, for example in a large building.

------
korethr
Reading this, it sounds like a collection of different attacks on different
mechanism up and down the stack is at play in this article. It'd be useful to
know which ones, though I acknowledge that the article is probably not
targeted towards an audience that would either want to know about or would
understand the details of say, SSL stripping.

One thing that occurs to me is that the 1st stage of the attack described --
sniffing and spoofing probe requests -- could possibly be defeated, or at
least made more difficult if the mobile wifi station authenticated the
identity of the wifi base station before continuing with the rest of the
auth/association sequence. Reading up on that sequence, I'm getting the
impression that the mobile station doesn't do that, rather, it blindly trusts
any base station with an ESSID and auth mechanism that match the one it's
configured to connect to. If I'm right, that seems like a rather horrible
oversight from a security perspective.

This leads me to another train of thought. The wifi standard is an IEEE one.
The name, IEEE - Institute of Electrical and Electronics Engineers, suggests
its constituents approach things from a perspective of "These are the known
laws of physics. How do we dance within those rules to implement $goal in a
cost-effective manner?" I don't see how the security implications of chosen
implementation details would enter into design normally. This isn't a
condemnation, just some observation and speculation. I similarly wouldn't
expect an building architect to think about the security implications of an
office's plumbing normally either unless I explicitly requested such.

As digital technology continues its seemingly inexorable march towards
continued integration with our lives, I think it's well past time we start
thinking more the security implications of our creations, and asking our peers
to do the same.

------
orblivion
Some apps use encryption, which sounds great, but we have "decryption
software"!

I understand that there are threats to badly implemented sites, and that even
with well implemented sites you can snoop on which domains are being visited,
and that there are 0days that some people are walking around with. But this
seems like a pop tech piece that doesn't have things in proper perspective. I
mean, it's probably good advice but for the wrong reasons.

------
kqr
This extends beyond public wifis -- people put way too much trust in LANs.
When I connect to a foreign LAN, I treat it as if I had connected straight to
the internet.

~~~
subway
People put too much trust in even their _home_ internet connections. A few
weeks ago my home internet connection (Wave-G delivered via ethernet(dhcp) to
my apartment) stopped working. I noticed instead of my router having its
normal public ip, a 10/8 address had been assigned. After poking at the router
address from the dhcp reply, I found myself looking at a Comcast cable modem.

Turned out a neighbor had moved in, and for whatever reason plugged the LAN
side of a cable modem into the ethernet port on their wall, and had begun
fighting the ISP's dhcp service.

~~~
lsaferite
Wait... your neighbor had an ethernet port in their apartment that was shared
in your apartment? That's not a home network, that's more like a MAN (or Metro
Ethernet or something). That ethernet port in your apartment should 100% be
treated as hostile if that's the case.

~~~
subway
The building has a shared ethernet fabric with a wireless uplink. With this
configuration (and it isn't an uncommon configuration), anyone on the ethernet
fabric can throw up a dhcp server and assign addresses/rutes to anyone else
(or a number of other attacks).

DOCSIS has had similar issues in the past -- folks on the same node could
directly pass frames between each other, and in some situations you could
sniff your neighbors traffic.

My point was that whether you're at home or out and about, you shouldn't trust
the "quality" of your internet connection, and should focus on having end to
end encryption with whatever service you're attempting to communicate with.

------
justadudeama
Is always connected to a VPN a reasonable way to be secure?

~~~
subway
An always connected VPN to _where_ exactly?

I struggle to find any "VPN Services" I trust not to sell every scrap of data
they can harvest, let alone to actually secure their systems. They become
relatively high value targets to anyone looking to collect data.

A VPN to your home only punts the issue to your ISP (see my other post on this
topic for issues with that).

Connections across the internet desperately need to be secured end-to-end,
whether they're coming from your home, cafe, or pub, and they need to be
secured yesterday.

------
pasbesoin
2014\. WiFi connection snooping, MITM.

~~~
dang
Thanks—year added to title above.

~~~
pasbesoin
Originally posted HN title also read something along the lines of "wifi is bad
for your health". Which is what made me look, at all. But no, it's not about
(direct) physiological impact. Instead, your "data security" health. And from
2014; we've had 3 - 4 years for this to become much more mainstream knowledge.

------
donarb
Would be nice to have this articled updated for 2018. The new title could read
"We took a hacker to the same public WiFi Café" and see what has changed in
the last 4 years. I'll bet not much.

------
schoen
This has gotten a bit better since then with HSTS (and I didn't understand
whether the attacker was doing SSL stripping, but it's also gotten a lot
better against a passive attacker with much greater HTTPS adoption). But a
significant fraction of these attacks would certainly still reveal sensitive
information.

~~~
jandrese
Some of the stuff in the article seemed a bit magical. He could tell that
someone bookmarked a website?

~~~
doctoboggan
He could tell she was browsing [https://del.icio.us/](https://del.icio.us/)
and was able to find her account and see what she "bookmarked" there.

------
paulclark
Google is already trying to address this with the Android Wi-Fi Assistant.
Wish Apple had something similar for iOS.

~~~
mnw21cam
Do you have any more details?

~~~
paulclark
[https://support.google.com/nexus/answer/6327199?hl=en](https://support.google.com/nexus/answer/6327199?hl=en)
is the best Google-hosted link I could find after a quick search. The
assistant establishes a VPN upon connecting to a public wifi network.

------
scrumper
> He asks me to go to Live.com (the Microsoft email site) and enter a random
> username and password. A few seconds later, the information I just typed
> appears on his screen.

This was interesting - how? Shouldn't only the hash of the PW be sent over the
network?

~~~
schoen
Web applications normally receive the real password on each login, but only
_store_ the hash in their long-term databases.

In this case the attacker might have also been doing SSL stripping, which (1)
would typically work even if it were an HTTPS site, but not if it had HSTS or
an HSTS preload; (2) would also allow him to change the site's user interface
so that it asked for or received information in a different way from usual. So
even if a site didn't normally solicit or transmit some specific kind of
information, the tampered-with version might do so, assuming the attacker had
thought to prepare a modified version of that particular site.

~~~
scrumper
Thanks, I figured some MITM for the SSL piece but genuinely thought that
client side JS hashed the PW. So this was educational and I am uncomfortably
naive.

~~~
kqr
Once you start thinking in terms of using JS to hash the password it's very
easy to end up reimplementing HTTPS in your own client code. Just a hash isn't
going to do much because replay attacks, so you need additional measures in
place.

Just running HTTPS is way preferable to implementing your own HTTPS in
JavaScript.

But, of course, the larger problem is the password itself. No matter how you
spin it with hashing or whatnot, a password is still a shared secret. You need
to communicate a secret to the other party so they can verify it. You can
almost hear how flawed a technology it is from the description, and I'm
honestly surprised it has been allowed to exist for so long.

~~~
schoen
> No matter how you spin it with hashing or whatnot, a password is still a
> shared secret. You need to communicate a secret to the other party so they
> can verify it.

There are lots of challenge-response protocols that prove knowledge of a
secret without communicating it. A simple example would be that the verifier
could ask for the HMAC of the shared secret under a randomly-generated HMAC
key. The prover can reply with the correct HMAC, but neither the verifier nor
an eavesdropper would be able to reconstruct the shared secret from this reply
without previously knowing the secret.

------
incomplete
old news, but Yet Another Reason To Always Use A VPN[tm].

~~~
dawnerd
Just not one provided by say, facebook
[https://9to5mac.com/2018/02/13/facebook-protect-spyware-
ios/](https://9to5mac.com/2018/02/13/facebook-protect-spyware-ios/)

~~~
incomplete
/facepalm

/flipdesk

/startdrinking

------
onychomys
They have a slightly different definition of public health hazard than I'm
used to.

~~~
dang
That title probably counts as both misleading and linkbait, so in accordance
with
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)
we changed it to language from the subtitle.

