Live data from Hacker News

Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

arnaucode.com

41–50 of 56 posts

Re: Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

#42

Earlier quoted context omitted.

Feels like they are more superior than us based on his color.

That's probably a cultural thing. In some cultures, red is superior to green. Really, it's not about them being better or worse than a user with more Karna. It's just a signal to everyone that this person might be advertising or AstroTurfing.

What?! I didn't know it indicates that the user is "untrusted", I'm from Sweden and my impression has been that the green users are super users of some kind.

Re: Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

#43
post #29

Given the recently disclosed vulnerabilities, instead of a cryptocurrency miner, it could be a Spectre exploit trying to scan and exfiltrate data from the computer's memory. We might be now at the point where disabling all Javascript for non-HTTPS pages is a good default.

Why do HTTPS pages get a pass? Between CDNs and ad networks, there's a ton of code out there. At some point, we decided that a magical protective box could make it okay for random people on the internet to run code on our machines. We keep finding this premise to be flawed, with Applets, and with Flash, and now with Javascript, and we always say "oh, if only we had a better protective box, it would have prevented thi…

> Maybe we should stop running code from websites.

Which would mean that even something as simple as an up-vote on a comment would require a full page refresh from the server. The lag would probably kill most social media.

You could be on to something there.

Re: Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

#44
post #43

Earlier quoted context omitted.

Why do HTTPS pages get a pass? Between CDNs and ad networks, there's a ton of code out there. At some point, we decided that a magical protective box could make it okay for random people on the internet to run code on our machines. We keep finding this premise to be flawed, with Applets, and with Flash, and now with Javascript, and we always say "oh, if only we had a better protective box, it would have prevented thi…

> Maybe we should stop running code from websites. Which would mean that even something as simple as an up-vote on a comment would require a full page refresh from the server. The lag would probably kill most social media. You could be on to something there.

> as simple as an up-vote on a comment would require a full page refresh

There are certainly ways to solve this declaratively.

Re: Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

#45
post #13
post #7

Earlier quoted context omitted.

Since we won't get https everywhere soon, is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM?

If you control the AP, you should disallow client to client communication. Most AP's and routers allow this and it would mitigate this risk.

But... this doesn't use client to client communication. As far as the AP is concerned there is one client (the attacked). The victim is connected to the attacked believing the attacker is the AP.

Re: Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

#46
post #7

Excellent write up. That’s why we need SSL/TLS with HSTS. Pure HTTP, specially in public WiFi, is dead.

Since we won't get https everywhere soon, is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM?

I've heard of, although never implemented, using WPA2 Enterprise authentication for public access points, and then just have your RADIUS server reply with a success regardless of username and password combination.

At first I thought this was a terrific idea, but never tried it since I figured having a non-standard workflow for users to connect may cause too much confusion in the end.

Re: Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

#47
post #43

Earlier quoted context omitted.

> Maybe we should stop running code from websites. Which would mean that even something as simple as an up-vote on a comment would require a full page refresh from the server. The lag would probably kill most social media. You could be on to something there.

> as simple as an up-vote on a comment would require a full page refresh There are certainly ways to solve this declaratively.

One of them being making all form submits asynchronous and not reload the entire page. Or the server sends only the bytes that it changes back.

Re: Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

#49

Earlier quoted context omitted.

That's probably a cultural thing. In some cultures, red is superior to green. Really, it's not about them being better or worse than a user with more Karna. It's just a signal to everyone that this person might be advertising or AstroTurfing.

What?! I didn't know it indicates that the user is "untrusted", I'm from Sweden and my impression has been that the green users are super users of some kind.

That was my impression as well. I never knew that. Guess it's good to know though.

Re: Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner)

#50
post #39

This is why it's important to always use a VPN when connecting to an untrusted wifi, such as a coffee shop or airport wifi. Either pay $3 /month to a provider or setup your own with something like pivpn.

One problem I have with that is: by the time I’m conected to WiFi, I don’t know how much traffic has already passed through before I could active the VPN. How many background tabs suddenly realized that they had internet again and started sending information (and how many of those used insecure, third party scripts?). Many apps/programs also seem to happily start phoning home as soon as they got WiFi.

I used to have little snitch[1] set up custom rules depending on where I’m connected (allow only local network on unknown WiFi’s until connected to a VPN) but that never really worked well because some WiFi’s allowed third party IP addresses (to tracking scripts or their home page) which meant I got to tracking down this IP and adding a temporary rule for that. Suddenly quickly connecting to hotspots often became a tedious 10 minute process. This also had the positive side effect that I could prevent A LOT of apps from phoning home but at the end it was not worth all the hassle (because almost nothing just worked) and I decided not to install little snitch for my current installation. The only thing I really miss it is when I connect to my phone hotspots because I’m always afraid application XYZ decides to download an update and eat my (very limited) mobile bandwidth.

Furthermore there is no way to do that on my mobile phone where I have even less control over. My current solution is to never connect to free WiFi networks in the first play and in the few cases I need to, just hope that the provider is not evil. This sucks when I’m on vacation, though, because I’m at their mercy.

[1]: a very flexible application based firewall which allows you to set which app is allowed to connect to with ip/dnsName:port https://www.obdev.at/products/littlesnitch/index-en.html

Post reply on HN