Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB

[anth0ny]

It is EXTREMELY LIKELY that a pool the person is connected to before it was redirected is the cause.
It is EXTREMELY UNLIKELY that it is a MITM attack unless there is a shoddy network somewhere in the middle.

I can agree with your probabilistic statements here, but in this case, it does indeed seem to be a TCP MITM attack.

Generally when I hear "TCP MITM attack" I think of a TCP connection being intercepted, not a client being tricked into going to the wrong IP address.  kano might have been thinking the same thing, maybe?

[Luke-Jr]

It is EXTREMELY LIKELY that a pool the person is connected to before it was redirected is the cause.
It is EXTREMELY UNLIKELY that it is a MITM attack unless there is a shoddy network somewhere in the middle.

I can agree with your probabilistic statements here, but in this case, it does indeed seem to be a TCP MITM attack.

Generally when I hear "TCP MITM attack" I think of a TCP connection being intercepted, not a client being tricked into going to the wrong IP address.  kano might have been thinking the same thing, maybe?

Yes, the original pool connection (TCP) is being intercepted to inject a stratum mining.reconnect command; the TCP stream gets broken in the process, but the client has already moved on to the new server by then... :/

[organofcorti]

Everyone, please check your miner is actually connected to Eligius.
It seems there are some MITM attacks going on to redirect Eligius miners to another pool

Do you know which pool, or at least an IP address? It'd be interesting to try and tie the pool-in-the-middle to a reused generation address.

Redirected clients show "Connected to 46.28.205.80..." in the miner.
This seems to be a scrypt "Worldcoin" mining server, and it seems likely they are just automatically MITM'ing any stratum connections they can inject into, regardless of the destination pool.

So it's not just you but a number of different pools that all have the same problem? Or is it a stratum problem that is pool agnostic?

[eleuthria]

Everyone, please check your miner is actually connected to Eligius.
It seems there are some MITM attacks going on to redirect Eligius miners to another pool

Do you know which pool, or at least an IP address? It'd be interesting to try and tie the pool-in-the-middle to a reused generation address.

Redirected clients show "Connected to 46.28.205.80..." in the miner.
This seems to be a scrypt "Worldcoin" mining server, and it seems likely they are just automatically MITM'ing any stratum connections they can inject into, regardless of the destination pool.

So it's not just you but a number of different pools that all have the same problem? Or is it a stratum problem that is pool agnostic?

It's definitely a localized problem.  I've yet to see a single report of it on BTC Guild.  It *did* happen to ScryptGuild at the same time as CleverMining a few months back, but the number of users affected was so low I believe it was local malware.  If it's some kind of ARP poisoning to intercept the traffic, that's possible (ScryptGuild is run out of OVH, while BTC Guild is not run in a shitty datacenter like that).

It is not a stratum bug, that much is absolutely certain (there's no way to relay messages to an independent stratum connection).  It is using a stratum method (client.reconnect) to perform the attack though, and make it so once the connection does have the message injected (how that's done I still have no damn clue), the client connects directly to "evilserver.com".

[anth0ny]

It is EXTREMELY LIKELY that a pool the person is connected to before it was redirected is the cause.
It is EXTREMELY UNLIKELY that it is a MITM attack unless there is a shoddy network somewhere in the middle.

I can agree with your probabilistic statements here, but in this case, it does indeed seem to be a TCP MITM attack.

Generally when I hear "TCP MITM attack" I think of a TCP connection being intercepted, not a client being tricked into going to the wrong IP address.  kano might have been thinking the same thing, maybe?

Yes, the original pool connection (TCP) is being intercepted to inject a stratum mining.reconnect command; the TCP stream gets broken in the process, but the client has already moved on to the new server by then... :/

Ah. I see.

Same problem as the one addressed by this patch, then? https://gist.github.com/gevans/9846423

[azdarknet]

Everyone, please check your miner is actually connected to Eligius.
It seems there are some MITM attacks going on to redirect Eligius miners to another pool

Do you know which pool, or at least an IP address? It'd be interesting to try and tie the pool-in-the-middle to a reused generation address.

Redirected clients show "Connected to 46.28.205.80..." in the miner.
This seems to be a scrypt "Worldcoin" mining server, and it seems likely they are just automatically MITM'ing any stratum connections they can inject into, regardless of the destination pool.

So it's not just you but a number of different pools that all have the same problem? Or is it a stratum problem that is pool agnostic?

It's definitely a localized problem.  I've yet to see a single report of it on BTC Guild.  It *did* happen to ScryptGuild at the same time as CleverMining a few months back, but the number of users affected was so low I believe it was local malware.  If it's some kind of ARP poisoning to intercept the traffic, that's possible (ScryptGuild is run out of OVH, while BTC Guild is not run in a shitty datacenter like that).

It is not a stratum bug, that much is absolutely certain (there's no way to relay messages to an independent stratum connection).  It is using a stratum method (client.reconnect) to perform the attack though, and make it so once the connection does have the message injected (how that's done I still have no damn clue), the client connects directly to "evilserver.com".

Geee thanks for letting us know how awesome BTC Guild is!

[HellDiverUK]

My guess would actually be that the Eligius server itself has been hacked
(or it's connected to a shoddy network)

lol, you really are a boob, aren't you?  <- opinion of a EC-CEH

[TechByPC]

My guess would actually be that the Eligius server itself has been hacked
(or it's connected to a shoddy network)

lol, you really are a boob, aren't you?  <- opinion of a EC-CEH

When all else fails, call people names and throw around credentials. It's much more enlightening than anything technical.

[norgan]

yup my miners went offline a few hours ago and when I logged on all showed 0MH/s. switched over to Emc and they are humming along nicely. Any ideas on when any fix may be applied and how best to stop it?

[HellDiverUK]

So, what's an EC-CEH anyway and why should I care if they can't help

http://bit.ly/1lSKDCY

 

[anth0ny]

Well then let me put it in clearer terms for you then since you are unable to understand or explain it or even suggest a solution

Anyone still mining here is at risk and there is no way to mitigate it with the current setup.

Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.

It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.

Whether or not you want to call the former a MITM attack is another matter. Really the attacker in that case isn't (necessarily) in the middle, she just pretends to be.

Not only that, but it would be important for Eligius to let us know what the data centre is that is doing or allowing one of their employees to do this MITM attack, so that we all know to not use that data centre.

By the way, neither requires being in the data centre of the server.  The latter (which I'd call a true MITM attack) just requires being somewhere in the middle (hence the name).

The former (which is probably more likely) doesn't even require that. It just requires correctly guessing TCP sequence numbers and spoofing of the source address. See, e.g., http://www.thegeekstuff.com/2012/01/tcp-sequence-number-attacks/

In any case, I think we have our answer to the question as to why the DOS is/was going on (*). Be careful what you wish for...

(*) Step 2: "[The attacker] floods Host B with new requests causing a Denial of service attack to stop Host B from communicating with A."

[Luke-Jr]

Well then let me put it in clearer terms for you then since you are unable to understand or explain it or even suggest a solution

Anyone still mining here is at risk and there is no way to mitigate it with the current setup.

Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.

It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.

Whether or not you want to call that a MITM attack is another matter.

It's the reply when you first connect ...

No, it isn't.

[anth0ny]

Well then let me put it in clearer terms for you then since you are unable to understand or explain it or even suggest a solution

Anyone still mining here is at risk and there is no way to mitigate it with the current setup.

Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.

It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.

Whether or not you want to call that a MITM attack is another matter.

It's the reply when you first connect ...

I guess TechByPC was wrong about explaining things technically being more enlightening than calling people names...

[Luke-Jr]

Well then let me put it in clearer terms for you then since you are unable to understand or explain it or even suggest a solution

Anyone still mining here is at risk and there is no way to mitigate it with the current setup.

Disabling client.redirect doesn't solve the initial connect redirect issue (since that's not stratum)
So if it really is as bad as a MITM then you are screwed anyway until you can stop the MITM or move your pool somewhere else.

It's a lot easier to insert a single TCP packet (containing a client.redirect command) in one direction than it is to intercept an entire TCP connection in both directions.

Whether or not you want to call that a MITM attack is another matter.

It's the reply when you first connect ...

No, it isn't.

You have removed this option from Eligius?

Go away, clueless troll.

[MrTeal]

I should probably mention again that I say something like this with a machine that was pointed to Slush. As I speak I just noticed that two rigs in physically separate locations and with different ISPs that were connected to Slush haven't submitted a share in 10 minutes.
The miners show them still connected to pool 0, but 46.28.205.80 instead of Slush.
One was running cgminer 4.0.0 on windows, the other is running cgminer 4.2.2

[DaveF]

I should probably mention again that I say something like this with a machine that was pointed to Slush. As I speak I just noticed that two rigs in physically separate locations and with different ISPs that were connected to Slush haven't submitted a share in 10 minutes.
The miners show them still connected to pool 0, but 46.28.205.80 instead of Slush.
One was running cgminer 4.0.0 on windows, the other is running cgminer 4.2.2

My test boxes which were pointing to ghash just did this too.

What DNS server (s) are you using public or private?
What kind of firewall were they behind?

One was an ANT S1 the other was an generic avalon clone.

Both are running the openwrt / cgminer that came with it.

-Dave

[DaveF]

And I just noticed the share difficulty on the ant was set to 1K.

Has anyone else noticed this?

-Dave

[Luke-Jr]

And I just noticed the share difficulty on the ant was set to 1K.

Has anyone else noticed this?

-Dave

Sounds like you're MITM'd...

[RealMalatesta]

As you see, I'm a newby. However, the IP points to Solar Communications in Zurich, Switzerland. This company is run by two Russians and maintains a really weird and crappy homepage, offering colocation and other stuff.

Remarkable is that they accept payments in Litecoin and Nxt Cryptocurrency.

The whole site looks as if it was set up quickly, translated poorly and then put into the wilderness of the WWW.

On their Twitter-account, they refer to their partner coinshost.com.

Solar Communications as well as Coinshost have their data center at the same address in Zurich, Switzerland, an address, btw, which was used in the past by some Russians who were involved in extortion via ddos.

Another one in this group is incloudibly.net. And what do they all offer? Right: ddos-protected bitcoin-hosting.

I'm cautious with suspicions, but in the past, similar companies with the same address were used by the Russians. If contacted by possible clients who asked for their services and turned them down because of the prices, the possible clients soon became victims of ddos-attacks - until they went down or hired the services of the "specialised" companies.

So if anybody ever was contacted by them and has since then experienced a ddos-attack: This would explain a lot.

[DaveF]

And I just noticed the share difficulty on the ant was set to 1K.

Has anyone else noticed this?

-Dave

Sounds like you're MITM'd...

I *knew* that, just trying to post more info. If it's a 1K share difficulty it's not like they are getting any work out of it. AND also that it was on ghash not just yours as Mr.Teal (slush) mentioned so it's a few more data points.

-Dave