Hacking WiFi to inject cryptocurrency miner to HTML requests (CoffeeMiner) | Hacker News Reader

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

arnaucode.com

I've thought about adding something like this to my guest wifi to mine some cryptocurrency - but quickly dismissed it as most guests would need to use a charger soon(ish) and thus using my electricity :P

It's also a scummy thing to do and sets a terrible precedent. Do you want friendly customers on your WiFi or do you want angry customers who feel cheated when they learn the truth?

I think it was basically a joke, and I think his "guests" are friends, not customers, and would therefore be likely to appreciate the joke even if he actually did it.

Ah, okay :)

let's submit patches that mine coins, with the recent 30% perf drop thanks to meltdown people won't notice

I wonder how many use ASICs for mining at public power outlets.

In the past, in Bulgaria, gypsies used to illegally connect to the electricity network to avoid paying bills. Nowadays there's a shift in that trend - there are numerous cases of people running mining farms the same way.

I find it funny how, even after publishing this post, the author hasn't configured a http -> https redirect for his own site.

Your sense of humour must be very unique.

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?

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.

Is there any way to mitigate this without limiting abilities of people on the network? It kind of destroys the point of a LAN.

don't take my word for it, but I'd bet you could disallow LAN comms on port 80 and prevent this. Typically a toxic client would flood the arp table until the router believed the toxic client should receive all communications and then the toxic client would mitm and forward traffic on the expected port to other normal clients...if the toxic client can't send stuff on port 80 to a normal client they can't easily mitm them

Yeah, but it would still redirect, since that's a different layer of the IP stack.

You could prevent wifi clients from communicating arp packets, I think that would allow most things to work.

If you have a corporate wifi system, you should be watching for arp poisoning anyway. If it's a public system, most people aren't using it to communicate between wifi devices. Most android devices that communicate via wifi will generate their own wifi network for the duration of the communication.

Did you ever use LAN functionalities in public Wifi (e.g. Starbucks)?

I did once at a hotel. Someone on the LAN kept what appeared to be his entire MP3 collection in his Shared folder. So I downloaded the whole thing.

Turned out he had crap taste in music and I ended up deleting my copy.

CoffeeMiner mixed with a WiFi Pineapple seems like the way to go.

Pineapple is overkill. You can use any open-wrt device or Linux laptop with a card supporting hostap.

Just give it the ssid 'xfinitywifi'.

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.

To the AP, they are both clients. The attacker (MITM) computer can be accessed by the victim. This would mitigate the attack. It's possible that the arp spoofing would prevent the victim from accessing the internet, but that depends on how the AP institutes it's blocks.

I think we will get it everywhere soon.

And no, that's not a solution. Well at least not everywhere. If the clients aren't completely isolated I can for example poison your DNS and redirect example.com to my computer's web server.

>is WPA2 on a public Wifi with a publicly known key a workaround? Should prevent plain MITM?

AFAIK that wouldn't help because at the very least you can MITM the handshake.

Honestly any decent public wifi setup even if it isn't going to limit client to client communication, if that's needed for some reason, should be restricting based on protocol/port/etc. It should be a whitelist, not a blacklist. There's no reason a client should be able to touch HTTP traffic towards anything but the gateway.

This is trivial to set up with for example, even a cheap sonicwall.

> is WPA2 on a public Wifi with a publicly known key a workaround?

You're thinking of packet injection (or data intercept) by any nearby individual, which WPA2 with known PSK would mitigate. However, as an attacker would know the PSK, they could simply join the network to side-step this.

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.

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

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 this specific form of attack". Maybe the premise is flawed. Maybe no box is strong enough. Maybe we should stop running code from websites.

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

This is (one of the reasons) why we need https.

I guess all it takes is one request to a non-https site?

Well, one persistently active tab with a non-https site open.

I suppose you could configure the rogue AP to have one of those registration pages but the registration page tells them the WiFi will only work so long as they keep that tab open.

Interesting method, but yes; wouldn't HTTPS mitigate this script from being injected? Trying to get awareness for my own original miner written from scratch https://www.sparechange.io/ Interesting learning WASM.

Some buildings (hostels and shared accomodations) have shared internet (secured with WPA2). This type of attack might be particularly profitable in such situations.

Wouldn't WPA2 protect users from an attack like this?

Not if the attacker knows the password (which is probably just listed on the wall in the hostel)

Does someone need to have control of the router to do this? Or how could it work otherwise?

It's in the article. He spoofs the MAC address to trick the gateway into thinking the attacker is the victim.

(OT: petteralexander's name shows a different color than other usernames. Why?)

New users are green, iirc 50 or 100 karma points required to get normal grey

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.

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

In English being "green" can mean being "new," like a sapling or new shoots on a plant, which are often bright green.

I don't know for sure if that's why they chose to make new users green but that's how I view it.

Won't modern browsers block this anyway?

Https everywhere extension fix it right?

This is great! Wow!

Reply on news.ycombinator.com