[ANN][AUTO-SWITCH] Profit-switch auto-exchange pool: CleverMining.com

[Terk]

TERK,

run a script on your mining database and tell us how many miners were/are point to that 190.xxx ip 

Also, did you run that script and get the info on how many were affected?  That is pretty easy to do and would be helpful to understand how many were affected.

What exactly do you suggest me to run because I don't understand? Redirects to 190.xxx were not coming from our pool so I have no way to check how many users got this.

[Terk]

are you guys all using teamviewer? it disconnects and goes to this 190.x server

Can you write more about it?

[cloudrck]

In my opinion it varies too greatly to be malware. Various OS's, software and routers. It's possible that if they use similar software for it to be exploited, but I'm unaware of whether they use custom or off-the shelf solutions. But MITM attacks have been very popular lately.

DNS hijacking seems unlikely, as that's a pretty massive thing to implement, and if you have that ability you're probably going after bigger fish.

As far as I know, CM and WP are the two largest profit switching pools. So who are bigger fish that I'm unaware of?

But since it can be any network connected device that was infected and remotely controlled the mining machines, there could be a common OS between all infected networks.  I agree that it seems unlikely, but occam's razor here.  The rest of the options seem more unlikely.

In regards to DNS hijacking - if you can do that, you're probably going to go after email systems, banking or credit card, or actual websites including hosted wallets.  It's like being given a space based laser and using it to open your can of tuna :-)

Right, but going after banks would be much harder with higher chances and consequences for being caught. Hijacking mining services are unique, they are very new and a lot less tried and tested than banking systems. With mining services, they can reap large monetary gain with little chance of federal law enforcement. BTW, you also assume the ones responsible aren't also attacking the other services.

As far as the common factor in all the scenarios would be the routers, as all of them out of the box suck security wise. Usually running an old outdated Linux kernel. But how would the attacker pick random IP addresses for such an attack?

BTW this quoting system sucks

[minedout]

Terk,

Any clue what this is? The page was deleted today, but Google has a cache'd version of it currently... for the time-being.

http://webcache.googleusercontent.com/search?q=cache:wM5KnG5iVR0J:pastebin.com/zsWnEAsN+&cd=11&hl=en&ct=clnk&gl=us&client=firefox-a

   {"id": 292, "method": "mining.subscribe", "params": ["cgminer/3.7.2", "deadbeefcafebabe4152000000000000"]}
    {"error": null, "id": 292, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800476e", 4]}
    {"params": [1024], "id": null, "method": "mining.set_difficulty"}
    {"params": ["89b", "74842cdbfb648490f4cf5371a383a48504755768167e9b6dd920dc24b666219f", "01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff2703f25402062f503253482f0407292f5308", "0d2f7374726174756d506f6f6c2f000000000100c7354dbd1600001976a9148d6906222b82cd2b4 b99d14bee6182084cab17fe88ac00000000", ["89d439d4c71e06c4f7632d4c5ab208022c23c51df58f29f4a5eb6d55c5065f57", "42d4ef5e17054a08298bb72c317262ea257df4472a13606c0c8e5207babe9b6e", "5d3ebf66acdc4cea8b8c6a7bf12ac46430de2fdb6d6300ea804e2bacca83851f", "bd3f92311678c4f72f69da3a786caa85f94fbb7ef0525c14f9be9e11ae6cff24", "259bf6b3c95bc7bd568dce6b8766b7ac63efc9ecdd4dff5f77dd351548cff654"], "00000002", "1b3326cb", "532f2907", true], "id": null, "method": "mining.notify"}
    {"id": 293, "method": "mining.authorize", "params": ["removed", "d=1024"]}
    {"error": null, "id": 1, "result": true}
    {"error": null, "id": null, "method": "client.reconnect", "params": ["190.97.165.179","3333"]}

deadbeefcafebabe seems to related to some Apache or Adobe stuff... a bit odd.

[hi]

Terk,

Any clue what this is? The page was deleted today, but Google has a cache'd version of it currently... for the time-being.

http://webcache.googleusercontent.com/search?q=cache:wM5KnG5iVR0J:pastebin.com/zsWnEAsN+&cd=11&hl=en&ct=clnk&gl=us&client=firefox-a

    {"id": 292, "method": "mining.subscribe", "params": ["cgminer/3.7.2", "deadbeefcafebabe4152000000000000"]}
    {"error": null, "id": 292, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800476e", 4]}
    {"params": [1024], "id": null, "method": "mining.set_difficulty"}
    {"params": ["89b", "74842cdbfb648490f4cf5371a383a48504755768167e9b6dd920dc24b666219f", "01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff2703f25402062f503253482f0407292f5308", "0d2f7374726174756d506f6f6c2f000000000100c7354dbd1600001976a9148d6906222b82cd2b4 b99d14bee6182084cab17fe88ac00000000", ["89d439d4c71e06c4f7632d4c5ab208022c23c51df58f29f4a5eb6d55c5065f57", "42d4ef5e17054a08298bb72c317262ea257df4472a13606c0c8e5207babe9b6e", "5d3ebf66acdc4cea8b8c6a7bf12ac46430de2fdb6d6300ea804e2bacca83851f", "bd3f92311678c4f72f69da3a786caa85f94fbb7ef0525c14f9be9e11ae6cff24", "259bf6b3c95bc7bd568dce6b8766b7ac63efc9ecdd4dff5f77dd351548cff654"], "00000002", "1b3326cb", "532f2907", true], "id": null, "method": "mining.notify"}
    {"id": 293, "method": "mining.authorize", "params": ["17GCyswwLYT8egprZHpPFH3zo5MrS1hXUo", "d=1024"]}
    {"error": null, "id": 1, "result": true}
    {"error": null, "id": null, "method": "client.reconnect", "params": ["190.97.165.179","3333"]}

deadbeefcafebabe seems to related to some Apache or Adobe stuff... a bit odd.

its your routers...lmao...

[superman3486]

well it seems the servers are down for CM?

everytime cm switches servers it seams as if teamviewer disconnects and then reconnects

[jedimstr]

Terk,

Any clue what this is? The page was deleted today, but Google has a cache'd version of it currently... for the time-being.

http://webcache.googleusercontent.com/search?q=cache:wM5KnG5iVR0J:pastebin.com/zsWnEAsN+&cd=11&hl=en&ct=clnk&gl=us&client=firefox-a

   {"id": 292, "method": "mining.subscribe", "params": ["cgminer/3.7.2", "deadbeefcafebabe4152000000000000"]}
    {"error": null, "id": 292, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800476e", 4]}
    {"params": [1024], "id": null, "method": "mining.set_difficulty"}
    {"params": ["89b", "74842cdbfb648490f4cf5371a383a48504755768167e9b6dd920dc24b666219f", "01000000010000000000000000000000000000000000000000000000000000000000000000fffff fff2703f25402062f503253482f0407292f5308", "0d2f7374726174756d506f6f6c2f000000000100c7354dbd1600001976a9148d6906222b82cd2b4 b99d14bee6182084cab17fe88ac00000000", ["89d439d4c71e06c4f7632d4c5ab208022c23c51df58f29f4a5eb6d55c5065f57", "42d4ef5e17054a08298bb72c317262ea257df4472a13606c0c8e5207babe9b6e", "5d3ebf66acdc4cea8b8c6a7bf12ac46430de2fdb6d6300ea804e2bacca83851f", "bd3f92311678c4f72f69da3a786caa85f94fbb7ef0525c14f9be9e11ae6cff24", "259bf6b3c95bc7bd568dce6b8766b7ac63efc9ecdd4dff5f77dd351548cff654"], "00000002", "1b3326cb", "532f2907", true], "id": null, "method": "mining.notify"}
    {"id": 293, "method": "mining.authorize", "params": ["17GCyswwLYT8egprZHpPFH3zo5MrS1hXUo", "d=1024"]}
    {"error": null, "id": 1, "result": true}
    {"error": null, "id": null, "method": "client.reconnect", "params": ["190.97.165.179","3333"]}

deadbeefcafebabe seems to related to some Apache or Adobe stuff... a bit odd.

The deadbeefcafebabe thing is related to Apache Jackrabbit content repository. The MITM vector may have been using it for the redirect injection.

[minedout]

its your routers...lmao...

Stop flooding the forum with retarded responses.

Obviously it seems like it could be important.

Has a BTC address, the offending IP and port, and the correct and offending mining difficulty.

[Terk]

This is a log of how this redirect looked like. This is not from CleverMining but from an user connecting to another coin-switching pool, but it shows how the redirect is done:

Code:

1: {"id": 292, "method": "mining.subscribe", "params": ["cgminer/3.7.2", "deadbeefcafebabe4152000000000000"]}
2: {"error": null, "id": 292, "result": [["mining.notify", "ae6812eb4cd7735a302a8a9dd95cf71f"], "f800476e", 4]}
3: {"params": [1024], "id": null, "method": "mining.set_difficulty"}
4: {"params": ["89b", "74842cdbfb648490f4cf5371a383a48504755768167e9b6dd920dc24b666219f", "01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff2703f25402062f503253482f0407292f5308", "0d2f7374726174756d506f6f6c2f000000000100c7354dbd1600001976a9148d6906222b82cd2b4b99d14bee6182084cab17fe88ac00000000", ["89d439d4c71e06c4f7632d4c5ab208022c23c51df58f29f4a5eb6d55c5065f57", "42d4ef5e17054a08298bb72c317262ea257df4472a13606c0c8e5207babe9b6e", "5d3ebf66acdc4cea8b8c6a7bf12ac46430de2fdb6d6300ea804e2bacca83851f", "bd3f92311678c4f72f69da3a786caa85f94fbb7ef0525c14f9be9e11ae6cff24", "259bf6b3c95bc7bd568dce6b8766b7ac63efc9ecdd4dff5f77dd351548cff654"], "00000002", "1b3326cb", "532f2907", true], "id": null, "method": "mining.notify"}
5: {"id": 293, "method": "mining.authorize", "params": ["removed", "d=1024"]}
6: {"error": null, "id": 1, "result": true}
7: {"error": null, "id": null, "method": "client.reconnect", "params": ["190.97.165.179",3333"]}

I numbered lines to be able to refer to them. What you see above is miner initiating its dialogue with the pool, so these are commands sent just after connecting to the pool. In this case miner must have been disconnected and then reconnected (trying to reconnect either to the same pool or to backup pool) - and this reconnected connection was hijacked somehow.

Messages coming from the pool (lines 2, 3, 4, 6, 7) are definitely NOT from CleverMining. They are also not from the pool which the above user was connected to, because:

Line 2: both CleverMining and the other pool use different subscription id format than sent by pool in line 2.
Line 3: both CleverMining and the other pool use 512 default difficulty and this pool sent 1024.
Line 2 & 3: both CleverMining and the other pool send lines in reverse order - send difficulty first, then send initial notify with subscription id
Line 4: both CleverMining and the other pool use different order of arguments when sending commands to miners (first id, then method, then params; here is first params, then method, then id).
Line 7: this is actual redirect request send by the fake pool.

The whole above communication is not a communication between miner and the pool which it intended to connect to. This fake pool clearly uses a different stratum software because its output is very different from what are using both CleverMining and the pool which the log should suppose to come from. (everything in the above log is consistent with how python stratum-mining server works, which we don't use).

So what happened here is:

1. Miner got disconnected from its legitimate pool.
2. It tried to reconnect, but was connected to a fake pool instead.
3. This fake pool immediately ordered it to reconnect to a different IP, effectively redirecting it to another pool.
4. The miner connected to 190.x address and started mining on a malicious pool.

The mystery is why user was connected to a fake pool after being disconnected from legitimate pool.

This is probably some kind of MITM attack as the user was connected to a fake pool after disconnection. The question is where this MITM attack was performed.

[Terk]

The deadbeefcafebabe thing is related to Apache Jackrabbit content repository. The MITM vector may have been using it for the redirect injection.

DEADBEEF and CAFEBABE are both popular hexspeak magic numbers used in hundreds of different pieces of software (http://en.wikipedia.org/wiki/Hexspeak). This is totally irrelevant and totally valid here. It's used as padding for subscription ID in the stratum server used by this pool.

[jedimstr]

The deadbeefcafebabe thing is related to Apache Jackrabbit content repository. The MITM vector may have been using it for the redirect injection.

DEADBEEF and CAFEBABE are both popular hexspeak magic numbers used in hundreds of different pieces of software (http://en.wikipedia.org/wiki/Hexspeak). This is totally irrelevant and totally valid here. It's used as padding for subscription ID in the stratum server used by this pool.

My bad then... Just relating where I've seen it before.

[Telek]

The mystery is why user was connected to a fake pool after being disconnected from legitimate pool.

This is probably some kind of MITM attack as the user was connected to a fake pool after disconnection. The question is where this MITM attack was performed.

Thanks Terk for all your help thus far!

Just to clarify, what sort of MITM attack are you thinking of?  It would essentially have to be router based, no?

[hi]

there is no man in the middle attack going on and this is quite obvious.

[Terk]

For anyone using karolth version of cgminer (or willing to switch): he just released a new version with --no-client-reconnect option which disables redirect command used to hijack miners. If you're not using this version but had your miners hijacked, you might want to think about switching to it, at least until this issue is explained/solved.

However i'm not sure how much it will be helpful, as core of the problem is that miner is reconnecting to a fake pool instead of legitimate pool. Even if it won't respond to reconnect/redirect command received from the fake pool, it will still be connected to this fake pool.

But it's possible that this fake pool isn't actually a full pool software but only tries to look like a pool - and in that case it won't send any actual work to solve besides this initial first mining.notify which is immediately followed by reconnect request (which will be ignored by your miner). In that case your miner should disconnect from this fake pool very soon because of not receiving any work and hopefully reconnect to legitimate pool.

[Telek]

Is it just cgminer?

Anyone on BAMT affected?

Has anyone been affected that has api mode disabled?

I'm sorry, I'm sure these answers are out there already, but I don't have time to read through all the threads (hence why I asked if there's a consolidated page somewhere).

If it was MITM couldn't this be completely transparent, as it could pretend and report that it's on pool X when it's actually funnelling requests to pool Z.  Hell, if it was smart and only redirected 5% of the hash nobody would probably notice.  Rounded pennies on bank interest payments anyone? 

What if it is malware, the malware itself hosts a stripped down pool, the reconnect goes there then the redirect goes to the malicious pool?  Could be done with local DNS spoofing.

I wonder if we can just ask the NSA to forward us a copy of our network traffic so we can analyze what happened 

[lsvpa]

Just a question to everyone who was affected: what backup mining pool(s) do you have configured in your miners?

Middlecoin
HashCows

[Telek]

I just had a thought.

Let's say that this is only rarely occurring not by choice, but by necessity.

When you lose connectivity there will be likely be a small window during which the server isn't responding.

What if you were monitoring the network, and when you see a loss of connectivity you spring into action, responding to the reconnection request pretending to be the other server?  Spoofing/monitoring is a pain, and besides once they reply again then things are going to get messy.  So the very first thing that you do is redirect to your own (local) server (which also stops attempting to reconnect to the primary), then once the connected to you then you can redirect to the proper server without having to spoof or monitor the network.

If this isn't triggered, and only happens during a natural disconnect then it would explain why it happens to so few people.

Perhaps people can try to intentionally cause a disconnect from their primary server, momentary firewall rule or just rebooting your gateway could do it.  See if anything attempts a redirect?

[MegaKill]

ok, all these mumbo jumbo you guys are talking about, hacking or phishing or whatever, let's say its solved tomorrow. will it increase the pool profitability or gpu scrypt mining? its going lower and lower these days. if the profit keep diminishing, what's the point in all these talks? gpu scrypt is still dying slowly, or its already are. peace.

[CoinBuzz]

My CGminer is old (3.1) so does not support client.reconnect command. just got a dead pool and switched to my backup pool (coinshift i think).

maybe you guys can use older version

[Cryptos2go]

Back in the day we called it a juke.