We took a hacker to a public WiFi café (2014)
medium.com
medium.com
> 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.
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 :)
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)
The '2014' might explain that bit.
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.
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.
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.
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.
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.
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 was interesting - how? Shouldn't only the hash of the PW be sent over the network?
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.
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.
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.
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.
https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
but it's not what's commonly used in website authentication.
/flipdesk
/startdrinking