Hacker News new | comments | show | ask | jobs | submit login
We took a hacker to a public WiFi café (2014) (medium.com)
60 points by hackerbeat 8 months ago | hide | past | web | favorite | 48 comments



> 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.


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 :)


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)


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.


> That sounds bit too good to be true. Facebook uses HSTS with preloaded certificates.

The '2014' might explain that bit.


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...


Does not help against sniffing Probe Requests.


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.


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


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.


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.


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.


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.


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.


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.


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


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.


Yes, if by "connected to a VPN" you mean two things:

1. You are connected to a trusted network via a VPN protocol. A trusted network might be your home network, a network you operate at a data center, or a network you operate at a cloud provider such as AWS or Azure.

2. You are not using split-tunneling, which is surprisingly common with some VPN clients. Split-tunneling will only send traffic destined for the remote network's address space to the VPN endpoint, sending all other traffic to the local network's gateway (in this case, the rogue router). You will want to disable split-tunneling in order to send all traffic to the VPN endpoint.

It has become popular to refer to connecting to a third-party proxy service that uses VPN protocols as "connecting to a VPN," but if you do that, you are putting your trust in a third-party vendor of proxy services. IMO it's superior to just operate your own private network using a more trustworthy data center or cloud provider.


This is my method of mitigating these attacks. However, more and more websites and services are blocking VPN providers and it’s becoming increasingly problematic to use a well-known commercial VPN for all day, regular use.


Doesn't VPN make things WORSE for you ? When you start using it you create a single log of all your internet activity that is outside of your control. What if your VPN provider gets hacked (and they make much more valuable target for hacking than any single internet user)? Or if it's run by hackers in the first place? :)


If you trust the VPN provider and the website you are visiting (with HTTPS), yes.


It depends on what the other end of the VPN is connected to.


2014. WiFi connection snooping, MITM.


Thanks—year added to title above.


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.


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.


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.


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


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


He could tell that they submitted the website to Delicious, which would be an HTTP(S?) request, not a bookmark to their own browser.


I'd assume by looking for a favicon request without any other requests.


How so?


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


Do you have any more details?


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.


> 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?


Browsers don't hash the password field, it's just text.

As for how he got around the HTTPS redirect on Live.com, I'm guessing it was a DNS poisoning attack to serve up a fake Live.com on HTTP. Presumably the journalist didn't have SSL Everywhere installed, because he's a tech journalist.


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.


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.


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.


> 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.


There is a technology for doing something like that

https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

but it's not what's commonly used in website authentication.


Usually no.


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


Just not one provided by say, facebook https://9to5mac.com/2018/02/13/facebook-protect-spyware-ios/


/facepalm

/flipdesk

/startdrinking


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


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: