I'm new to this, I don't know if they do or don't, I should read up on stratum to have a better understanding of how it works and sniff the traffic to understand what's being sent over the wire. Can someone can explain how the hijacked work is redirected/attributed to someone else? Please excuse my inexperience/lack of understanding. From what I've read in this thread it sounds like work is hijacked and sent to another pool, is that correct? Is the theory that the stats pages are being attacked to mask what's happening to miners by preventing them from seeing their stats?
I'l try to make a summary of what's happening, to the best of my understanding.
When you connect to a stratum server, the server sends a miner a message saying "Try solving this block, with nonce between X et Y, with difficulty Z". It may thus ensure no miner does duplicate work. When you find a nonce that solves the block for the given difficulty, you send it to the server, that verifies it, and credits you with a share if it's ok. The server may occasionally request you abort your work and work another block instead, such as when a new block is found by another server.
The protocol also allows for the server to request you connect to another server instead. It might be useful for load balancing on the server side.
What is happening now is that a rogue third party sends to your computer a forged packed, with it origin IP address spoofed to appear originating from the server, when it is not. The packed contains a request that you connect to an attacker-controlled server, which will accept any inbound connection regardless of credentials. Once the connection is established, it will then issue you new work, that your miner will happily solve, only, it's the attacker that will keep the profit, until you realise something's going on.
Now, doing such an attact is easy: packets are transmitted somewhat randomly over Internet. An attacker might monitor packets passing trough his node, and detect those who look like stratum packets, and trivially know the IP of the server, the miner and the port number of each.
Using that data to create and send a fake packet is easy. It does not require the attacker to intercept the connection, be in the middle, or anything. The software on both side must be resilient to such attack. There are some mechanisms to ensure that, such as a unique sequence number which is sequentially increased at each message between the two enpoints. A message with the wrong sequence number is discarded.
An attacker may however monitor the packets, and try to send a packet with the next sequence number in order. It's unlikely to succeed if the two endpoints are in active conversation, because odds are they will have moved on to a greater sequence number by the time his packet arrives, however, when the server is slow to respond (such as when it is under DDoS), the attacker might have enough time to slip his packet.
It's not surprising that the problem affect only some persons: The attacker must know you are connected to the pool, which will only happen if the packet goes by him: The packets might wander a bit around Internet, but it does no go to the other side of the world for no reason, so the attacked ones must be "near" a compromised computer. "Near", here, is network-wise, not geograhically-wise; sometimes network routing takes surprising paths.
Now, there are there two proposals to solve such problem:
a) Prevent redirect request across domains. The redirect mechanism of Stratum was designed for load balancing across different server of the same pool. All those servers should be in the same domain, so a redirect request across domains is highly suspicious.
b) Use TLS to encrypt/sign the connection, so that no third party might create a packet that legetimately appears to be coming from the pool, even if he guesses correctly the sequence number.
a is easy, as it only requires a small patch on miner clients. However, it is not torough, and does not address the underling vulnerability.
b is much more torough, but is more complicated, as it requires support from both miners and pool, and adds some overhead, especially to the pool.
However, both solutions are in the works. Patches have been submitted to BFGminer and cgminer to block suspicious redirects, and support TLS connections. Eligius pool server is testing supporting inound TLS connections. (Inbound TLS connections on other pools, though, is up to each pool operator)
