Quote from: LuckyKey on March 25, 2014, 11:29:57 PM

I am confused as to how this could happen? How could my mining be hijacked? On my end? From mining sfw (i.e.; cgminer) I poll the mining pool host by dns name (which is not going to be hacked by my isp)? So, that would leave someone doing something on the pool hosting server to hijack my work? Sorry, little confused how this could happen. Can you explain your thoughts further?

If I understood the problem, a yet to be hijacked miner got a valid message - to redirect its hashing power to another IP & destination port.

Basically, this happened on different miner versions and different operating systems.

Injecting TCP packets into sessions is not an easy task - but it is possible. For a starter, one must know the IP address of the miner and source & destination ports (and some other details regarding specific TCP session).

Now, Waffle claims, nobody broke into the wafflepool. Please note, it's good enough to sniff (read) the packets - not modify them. Injection of packages can be done separately on the other part of the world. To be fair to waffle, hijacking happened also to people mining to other pools also - albeit it is not clear if packets were sniffed on one pool only. For example, you hash at pool #2 (not waffle), hacker sniffed up the session, sent a redirect package, redirecting your mine to someplace else.

What should be considered is that data is leaking at some of the pools, but the redirect happens to miners, currently mining at some other pool. Technicaly speaking cgminer connects to EVERY pool stated in the config - even to reserve pools. I think that this is very possible explanation, how on earth hacker managed to inject packages to miners. Besides ignoring the redirect message, two other security measures comes to my mind (kalroth - r u reading this???):

a) is it possible that a redirect message comes from a session /w pool A and redirects the pool B? I think a check should be done, to honor only redirects from the session limited to a pool to which the session belongs - it would also mean that if a message tries to redirect other session's pool - it is probably hacker's redirect. Please note that in that case one would clearly know which pool is sniffed up. Of course - perhaps packages are not sniffed at pool's side - but perhaps someone broke into some router and it is sniffing interesting packages. But in this case, a trace route can be compared and perhaps some common point crops up. So - knowing from which session pool the redirect message came, would be very useful.

b) injection is possible if session is open; is it possible that a sesion to a pool is established only after for example primary pool is down - this way, this would radicaly lower the exposure to hijacking

Somebody else even suggested that a communication can be intercepted and redirected. That's also true.

So what can be done?

Either use kalroth latest version of cgminer, where there is a new option, to ignore the redirection command.

Other option is to strictly limit where the miner can connect to -- basically, even if mining is redirected, cgminer will not be able to communicate - thus no hash power is stolen.

A long term solution would be that the miner would be able to verify a true identity of the pool.