Topic: [POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com - page 139. (Read 465716 times)

Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...

Now you're just yessing me in order to prevent me from casting any further doubt upon your intentions.  We live in an age where entities such as wireless service providers, cable television providers, financial service companies, hotels, and even internet hosting companies regularly redefine the meaning of 'unlimited' by appending a tiny asterisk next to it, and are continually adding more and more fees below the line over time in an effort make their stated prices look less expensive and more competitive than they really are.  If your offer of free hosting, including internet connectivity and electrical supply for purchased mining hardware is completely genuine, then stand behind your claims by incorporating it into your contracts instead of just 'looking into implementing something like that'.

Malware cannot explain what has happened.

I am running linux on each of my rigs. On those rigs running linux, there are several different distributions of linux. Linux is notoriously difficult to infect with malware. On those rigs, some are running sgminer, some cgminer 3.7.2 (original) and some kalroth's or other version of cgminer. One of my rigs is running cudaminer. Other people are running various versions of windows, or even Mac, with various miners.

I cannot imagine any malware that could possibly be written to affect multiple miners in multiple operating systems.

In my case, my security practices are very reliable.

When this happened to me, it happened simultaneously on all my rigs all running various OS's and all running different miners.

The symptoms are not indicative of client side malware. It is indicative of some kind of DNS or networking hijacking.

Good suggestion, we will look in to implementing something like that with our TOS

And a legally binding contract?  For without one you could simply change your mind at any time without penalty nor recourse for the buyer.  Having such provisions included on the bill of sale would probably be sufficient.

From what I understand, the client.reconnect command was included to seamlessly move miners over to another pool stratum server in preparation for maintenance on the originally active server.  As to whether a backup stratum server could trigger cgminer to suspend all active stratum server connections, I really cannot provide a firm answer.  It would make sense that a client.reconnect command message should only suspend one active stratum connection (the one on which it arrived), but there always exists the possibility of other unforeseen behavior within the implementation of the code.  Either way, the dns hijacking theory is discounted by the tcp port having been changed too, and perhaps the local miner malware possibility is much more likely.  But in order to find out which, we must all stop placing blame on dns hijacking ghosts.

Update:  I misread your question.  Yes a stratum connection must be active in order for a miner to receive a client.reconnect command message, and only the miner side can initiate a stratum connection.  In your case using quotas (as per your description), you would have active connections to a minimum of two stratum servers.  But even without using quotas, cgminer will connect to backup servers IF the active server cannot provide work at a rate fast enough to keep the GPUs fully utilized. (unless the failover-only option is specified on the command line or in the configuration file.)

Another update:  I've realized that technically speaking, a dns hijack could still indeed be in play, followed by a client.reconnect message from a rogue stratum server in order to change the tcp port, but that just seems awfully convoluted.  For if one were to hijack a dns server to redirect a miner to a different server on port 3333, why would they they redirect again to port 3009?  -- unless they are using the technique to load balance stolen hashpower to multiple rogue servers, but then only one rogue ip address and tcp port combination has been reported here.  Has anyone observed any other rogue server ip addresses or tcp ports?

There sorry about that

I was going to say that I also use Google DNS and saw this happen to me, but that's a good point regarding the port change. Do you know if only active pools can trigger this? I had my miner configured for four pools, two of which are disabled, and two were set with a quota. Unfortunately I don't have any logs from the event.

Does anyone else who had this happen connect to multiple pools?

Randomly, a day or two before this started up, I read some old forum posts between slush and another op arguing over how to move forward with stratum and why you would ever need a command to redirect miners to other servers while looking for ways to improve my solo mining tests...

Perhaps I naturally look too deeply, but I happened to notice that while you did promise 'free hosting' in the sentence I marked in bold above, you neglected to include the word 'electricity', except when mentioning your plans, which I assume are always subject to change.  Would you care to clarify, and if I were to purchase equipment from you, then would provisions for hosting services and free electricity in perpetuity be included in a legally binding contract?

Hi,

We wanted to provide some clarity about our hosting.

GAW Inc owns a family of technology companies, including a national ISP. We own collocations all over the country. So power and hosting is a sunk cost to us. Our other technology divisions make up 95% of our revenues.  

So all customers that receive our hosting, bandwidth and electricity will continue to remain free. We enjoy bringing new things to the market. And plan to provide free hosting and power for more products. We even have a free btc hosted/electric solution we are working on

Thanks for your time

Take notice that Meeho captured both the unexpected ip address and TCP PORT to which cgminer was attempting to connect, thereby further ruling out the possibility of a dns hijack, as dns maps host names to ip addresses only, and applications themselves handle port assignments.

The change of tcp port can only occur as a result of having received a client.reconnect command message from the stratum server, or a spoof thereof -- or the existence of other malware present on the affected mining computers themselves.  Dns hijacking can not possibly explain the cause of a miner process attempting to connect to a pool stratum server on a different tcp port.

Furthermore, as wafflepool servers had previously been experiencing a mysterious underreporting of miner hashrates, which was identified mostly by cudaminers hearing their gpu fans spin down as cudaminer was sitting idle waiting for more work to be sent from the wafflepool stratum server, that means cgminer with configured backup servers which by default will leak work to backup servers in the case of an underperforming active server, might even have received a client.reconnect command message from a stratum server other than wafflepool stratum server, as it could possibly have originated from a simultaneously active backup stratum server.  So those possible sources are too in play.


From ckolivas cgminer 3.7.2 readme:

Options for both config file and command line:

--failover-only     Don't leak work to backup pools when primary pool is lagging

Q: Work keeps going to my backup pool even though my primary pool hasn't
failed?

A: Cgminer checks for conditions where the primary pool is lagging and will
pass some work to the backup servers under those conditions. The reason for
doing this is to try its absolute best to keep the GPUs working on something
useful and not risk idle periods. You can disable this behaviour with the
option --failover-only.

@PW found this related to 206.223.224.225

https://github.com/potcoin/potcoin-seeder/blob/master/main.cpp

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Administrator>nslookup uswest.wafflepool.com
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    uswest.wafflepool.com
Address:  192.241.211.125


C:\Users\Administrator>tracert uswest.wafflepool.com

Tracing route to uswest.wafflepool.com [192.241.211.125]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  modem.Home [10.42.0.1]
  2    35 ms    32 ms    24 ms  67.41.239.68
  3    46 ms    42 ms    43 ms  67-41-234-25.slkc.qwest.net [67.41.234.25]
  4   212 ms    67 ms    54 ms  snj-edge-03.inet.qwest.net [67.14.34.54]
  5    41 ms    38 ms    38 ms  65.113.42.118
  6    76 ms    71 ms    48 ms  ae0-110g.cr1.sjc1.us.nlayer.net [69.22.143.117]

  7   105 ms   113 ms     *     ae1-70g.cr1.pao1.us.nlayer.net [69.22.143.166]
  8    68 ms    45 ms    50 ms  ae1-80g.cr1.sfo1.us.nlayer.net [69.22.143.169]
  9     *       74 ms    74 ms  as14061.ae5-401.cr1.sfo1.us.nlayer.net [69.22.13
0.38]
 10    65 ms    63 ms    82 ms  198.199.99.242
 11    44 ms    55 ms    41 ms  192.241.211.125

Trace complete.

C:\Users\Administrator>

how would people check for this?

@PW got this from multipool.us

Mar 22 4:22 PM It appears there is some kind of malware diverting some users' hashpower to 206.223.224.225. This is not a multipool pool server. If you are seeing this, please report it as well as what miner you are using, where you obtained it, and check your computer for malware.

It appears that waffle is not the only multipool under attack!

As I have not tested the "poolname" feature and now the "name" feature in sgminer and kalroth cgminer, I can only make an assumption as to how it would behave in such a case, and I believe that I have already expressed my opinion on basing conclusions upon assumptions.  And as I am not interested in testing it nor examining the code for others who will almost certainly not appreciate my efforts, some one else will have to do it if they want the answer.  So whether the "poolname" display would stick in sgminer or kalroth cgminer after a client.reconnect command is processed is anyone's guess at this point.

I am a student of human nature.  And as such, I notice that you have no relevant point to make, and thus attack in order to maintain an illusion of knowledge and air of superiority.  If you do not share the opinions of others, you seem to dismiss them, rather than consider their merit.  Time will eventually tell all.

Thank you, I'll consider that. So what's the deal, do you get a kick out of this, or are you just bored since you have no friends to edumacate? What's next, are you gonna tell me Earth is more than 6000 years old? Imagine what a scientific breakthrough that would be.

sgminer and cgminer-37.3 (k) display pool names from their config files even when you set url to hard ://ip did someone changed configs during the "thing" to point miners to ://ip instead of name of the server? or may be to other pool and it went ok? what platform did miners who suffered used? bamt(what version and miner) or win cg or sg or cg-k? and what does edumacate mean?
and, considering scrypt asic situation right now, i would invest some $ in this kind of uberswitcherfacetoassbassin (the one, switching dns servers instead of coins)

The client.reconnect command must originate from the pool stratum server itself or a tcp packet must be spoofed in order to make it look like it originated from the pool stratum server.  In addition, the tcp packet sequence number must be within the proper expected range, and there is an additional stratum sequence counter that would need to be within the proper expected range as well.  And as a successfully issued client.reconnect command would cause your miner to immediately disconnect from the active stratum server and initiate a stratum connection to another server specified within the message, wafflepool servers might only see a client disconnecting for no apparent reason.

In any case, even if a wafflepool server were infiltrated only so far as to obtain the list of active network connections containing ip addresses and source ports of miners, then such an attack would be possible.  And barring infiltration of any wafflepool server itself, this information could potentially be collected upstream of wafflepool servers if another different piece of network hardware is compromised instead.

That affected miners were showing the unexpected ip address on their status screens suggests an attack other than dns hijack, as mining software (such as cgminer) that usually displays a server name instead of its resolved address, would continue showing a server name, but the underlying network transport would resolve that server name to a different ip address.