Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 07:55:50 AM |
|
Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...
My rigs don't have wallets running on them. Infected source code in all sgminer, cgmniner, bfgminer, and even Cudaminer? Code I've downloaded from github and compiled myself in each case? Seems highly unlikely. Possible, but very unlikely. You seem to have a good sampling of configurations, so it seems like agood place to start. Do you they all run on the same local area network? If so, are they using private ip addresses with your router running network address transalation? Are they dynamically assigned or manually entered into the configuration of each mining computer? Yes, all running on the same local network. Some are using static IP's and some dynamically assigned IP's via DHCP from the router, which is running proprietary software from the router manufacturer, though some of the rigs are bridged to the router via another router running open source dd-wrt. Quite a few different variables here. All are using Google's DNS, 8.8.8.8 and 8.8.4.4. When the problem occurred, it happened on all rigs simultaneously, regardless of OS, miner software, static or dynamic IP, router connection, etc.
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
comeonalready
|
|
March 23, 2014, 07:57:22 AM |
|
Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...
My rigs don't have wallets running on them. Infected source code in all sgminer, cgmniner, bfgminer, and even Cudaminer? Code I've downloaded from github and compiled myself in each case? Seems highly unlikely. Possible, but very unlikely. You seem to have a good sampling of configurations, so it seems like agood place to start. Do you they all run on the same local area network? If so, are they using private ip addresses with your router running network address transalation? Are they dynamically assigned or manually entered into the configuration of each mining computer? Yes, all running on the same local network. Some are using static IP's and some dynamically assigned IP's via DHCP from the router, which is running proprietary software from the router manufacturer, though some of the rigs are bridged to the router via another router running open source dd-wrt. Quite a few different variables here. All are using Google's DNS, 8.8.8.8 and 8.8.4.4. Many nat routers run a dns forwarding service on them. If your internet service provider assigns your public ip address via dhcp, and you assign private ip address internally via dhcp, some routers will configure the dns server for those computers to the internal ip address of the router which will forward requests onto the router's configured dns server. If you check your ip configuration on one or more of the mining computers receiving its address via dhcp, does it/they point to the internal router ip address in the dns server field, or directly to an external dns server? (I ask this as many nat routers running dns forwarding service are more vulnerable to attacks than internet dns servers are.) This is a real long shot, but as it only takes a minute or so to check, worth a look.
|
|
|
|
Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 08:03:30 AM |
|
Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...
My rigs don't have wallets running on them. Infected source code in all sgminer, cgmniner, bfgminer, and even Cudaminer? Code I've downloaded from github and compiled myself in each case? Seems highly unlikely. Possible, but very unlikely. You seem to have a good sampling of configurations, so it seems like agood place to start. Do you they all run on the same local area network? If so, are they using private ip addresses with your router running network address transalation? Are they dynamically assigned or manually entered into the configuration of each mining computer? Yes, all running on the same local network. Some are using static IP's and some dynamically assigned IP's via DHCP from the router, which is running proprietary software from the router manufacturer, though some of the rigs are bridged to the router via another router running open source dd-wrt. Quite a few different variables here. All are using Google's DNS, 8.8.8.8 and 8.8.4.4. Many nat routers run a dns forwarding service on them. If your internet service provider assigns your public ip address via dhcp, and you assign private ip address internally via dhcp, some routers will configure the dns server for those computers to the internal ip address of the router which will forward requests onto the router's configured dns server. If you check your ip configuration on one or more of the mining computers, does it/they point to the internal router ip address in the dns server field, or directly to an external dns server? (I ask this an many nat routers running dns forwarding service are more vulnerable to attacks than internet dns servers are.) This is a real long shot, but as it only takes a minute or to check, worth a look. This is a good question. Most of the rigs are configured to use 8.8.8.8 and 8.8.4.4 directly in /etc/resolv.conf. Two of them I obviously didn't change when I set them up and they are pointing to the router, which is configured to use 8.8.8.8 and 8.8.4.4. All were affected equally.
|
|
|
|
comeonalready
|
|
March 23, 2014, 08:05:46 AM |
|
Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...
My rigs don't have wallets running on them. Infected source code in all sgminer, cgmniner, bfgminer, and even Cudaminer? Code I've downloaded from github and compiled myself in each case? Seems highly unlikely. Possible, but very unlikely. You seem to have a good sampling of configurations, so it seems like agood place to start. Do you they all run on the same local area network? If so, are they using private ip addresses with your router running network address transalation? Are they dynamically assigned or manually entered into the configuration of each mining computer? Yes, all running on the same local network. Some are using static IP's and some dynamically assigned IP's via DHCP from the router, which is running proprietary software from the router manufacturer, though some of the rigs are bridged to the router via another router running open source dd-wrt. Quite a few different variables here. All are using Google's DNS, 8.8.8.8 and 8.8.4.4. Many nat routers run a dns forwarding service on them. If your internet service provider assigns your public ip address via dhcp, and you assign private ip address internally via dhcp, some routers will configure the dns server for those computers to the internal ip address of the router which will forward requests onto the router's configured dns server. If you check your ip configuration on one or more of the mining computers, does it/they point to the internal router ip address in the dns server field, or directly to an external dns server? (I ask this an many nat routers running dns forwarding service are more vulnerable to attacks than internet dns servers are.) This is a real long shot, but as it only takes a minute or to check, worth a look. This is a good question. Most of the rigs are configured to use 8.8.8.8 and 8.8.4.4. Two of them I obviously didn't change when I set them up and they are pointing to the router, which is configured to use 8.8.8.8 and 8.8.4.4. All were affected equally. If all your miners were affected equally, and not just the miners using the internal router ip address for dns servers, then I think we can rule out the dns forwarding/masquerading service on your router from having been compromised. Thanks for checking. I hate to have to ask, but are you absolutely 100% certain?
|
|
|
|
Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 08:11:04 AM |
|
Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...
My rigs don't have wallets running on them. Infected source code in all sgminer, cgmniner, bfgminer, and even Cudaminer? Code I've downloaded from github and compiled myself in each case? Seems highly unlikely. Possible, but very unlikely. You seem to have a good sampling of configurations, so it seems like agood place to start. Do you they all run on the same local area network? If so, are they using private ip addresses with your router running network address transalation? Are they dynamically assigned or manually entered into the configuration of each mining computer? Yes, all running on the same local network. Some are using static IP's and some dynamically assigned IP's via DHCP from the router, which is running proprietary software from the router manufacturer, though some of the rigs are bridged to the router via another router running open source dd-wrt. Quite a few different variables here. All are using Google's DNS, 8.8.8.8 and 8.8.4.4. Many nat routers run a dns forwarding service on them. If your internet service provider assigns your public ip address via dhcp, and you assign private ip address internally via dhcp, some routers will configure the dns server for those computers to the internal ip address of the router which will forward requests onto the router's configured dns server. If you check your ip configuration on one or more of the mining computers, does it/they point to the internal router ip address in the dns server field, or directly to an external dns server? (I ask this an many nat routers running dns forwarding service are more vulnerable to attacks than internet dns servers are.) This is a real long shot, but as it only takes a minute or to check, worth a look. This is a good question. Most of the rigs are configured to use 8.8.8.8 and 8.8.4.4. Two of them I obviously didn't change when I set them up and they are pointing to the router, which is configured to use 8.8.8.8 and 8.8.4.4. All were affected equally. If all were miners affected equally, and not just the miners using the router ip address for dns servers, then I think we can rule out the dns forwarding/masquerading service on your router from having been compromised. Thanks for checking. I hate to have to ask, but are you absolutely 100% certain? I am certain of some using direct DNS and some pointing to the router. I am certain some are using DHCP and some are static IP's. I am certain one router (connected to the external internet) is running proprietary Dlink software and the other bridged router is running dd-wrt. I set all of this up myself. This does not entirely rule out some very clever hack on the router side of things, or injected in multiple miner's source codes. It just seems rather unlikely to me at this point.
|
|
|
|
|
Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 08:13:57 AM |
|
Yes, this is the weakest link in my setup for sure.
|
|
|
|
comeonalready
|
|
March 23, 2014, 08:19:05 AM |
|
Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...
My rigs don't have wallets running on them. Infected source code in all sgminer, cgmniner, bfgminer, and even Cudaminer? Code I've downloaded from github and compiled myself in each case? Seems highly unlikely. Possible, but very unlikely. You seem to have a good sampling of configurations, so it seems like agood place to start. Do you they all run on the same local area network? If so, are they using private ip addresses with your router running network address transalation? Are they dynamically assigned or manually entered into the configuration of each mining computer? Yes, all running on the same local network. Some are using static IP's and some dynamically assigned IP's via DHCP from the router, which is running proprietary software from the router manufacturer, though some of the rigs are bridged to the router via another router running open source dd-wrt. Quite a few different variables here. All are using Google's DNS, 8.8.8.8 and 8.8.4.4. Many nat routers run a dns forwarding service on them. If your internet service provider assigns your public ip address via dhcp, and you assign private ip address internally via dhcp, some routers will configure the dns server for those computers to the internal ip address of the router which will forward requests onto the router's configured dns server. If you check your ip configuration on one or more of the mining computers, does it/they point to the internal router ip address in the dns server field, or directly to an external dns server? (I ask this an many nat routers running dns forwarding service are more vulnerable to attacks than internet dns servers are.) This is a real long shot, but as it only takes a minute or to check, worth a look. This is a good question. Most of the rigs are configured to use 8.8.8.8 and 8.8.4.4. Two of them I obviously didn't change when I set them up and they are pointing to the router, which is configured to use 8.8.8.8 and 8.8.4.4. All were affected equally. If all were miners affected equally, and not just the miners using the router ip address for dns servers, then I think we can rule out the dns forwarding/masquerading service on your router from having been compromised. Thanks for checking. I hate to have to ask, but are you absolutely 100% certain? I am certain of some using direct DNS and some pointing to the router. I am certain some are using DHCP and some are static IP's. I am certain one router (connected to the external internet) is running proprietary Dlink software and the other bridged router is running dd-wrt. I set all of this up myself. This does not entirely rule out some very clever hack on the router side of things, or injected in multiple miner's source codes. It just seems rather unlikely to me at this point. As many of us as possible need to enable verbose logging to file for when this happens again. And it will almost certainly happen again, as there is money to be made by attackers exploiting whatever weakness allowed them to do so this time around. I have had logging enabled since the very beginning, but none of my equipment was affected by this problem. I did notice a few atypical incoming packets logged on my firewall making me suspect that a local router attack could be part of the redirect to a rogue server, which is why I asked you about yours, as you actually witnessed the redirection of your hashpower.
|
|
|
|
comeonalready
|
|
March 23, 2014, 08:22:38 AM |
|
Yes, this is the weakest link in my setup for sure. My configuration does not utilize any of the vulnerable equipment included in that list. (Not that someone somewhere probably doesn't know how to hack it!)
|
|
|
|
Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 08:23:29 AM |
|
Could be an infected source code for a miner or wallet which is compiled on each platform (windows, linux etc) ...
My rigs don't have wallets running on them. Infected source code in all sgminer, cgmniner, bfgminer, and even Cudaminer? Code I've downloaded from github and compiled myself in each case? Seems highly unlikely. Possible, but very unlikely. You seem to have a good sampling of configurations, so it seems like agood place to start. Do you they all run on the same local area network? If so, are they using private ip addresses with your router running network address transalation? Are they dynamically assigned or manually entered into the configuration of each mining computer? Yes, all running on the same local network. Some are using static IP's and some dynamically assigned IP's via DHCP from the router, which is running proprietary software from the router manufacturer, though some of the rigs are bridged to the router via another router running open source dd-wrt. Quite a few different variables here. All are using Google's DNS, 8.8.8.8 and 8.8.4.4. Many nat routers run a dns forwarding service on them. If your internet service provider assigns your public ip address via dhcp, and you assign private ip address internally via dhcp, some routers will configure the dns server for those computers to the internal ip address of the router which will forward requests onto the router's configured dns server. If you check your ip configuration on one or more of the mining computers, does it/they point to the internal router ip address in the dns server field, or directly to an external dns server? (I ask this an many nat routers running dns forwarding service are more vulnerable to attacks than internet dns servers are.) This is a real long shot, but as it only takes a minute or to check, worth a look. This is a good question. Most of the rigs are configured to use 8.8.8.8 and 8.8.4.4. Two of them I obviously didn't change when I set them up and they are pointing to the router, which is configured to use 8.8.8.8 and 8.8.4.4. All were affected equally. If all were miners affected equally, and not just the miners using the router ip address for dns servers, then I think we can rule out the dns forwarding/masquerading service on your router from having been compromised. Thanks for checking. I hate to have to ask, but are you absolutely 100% certain? I am certain of some using direct DNS and some pointing to the router. I am certain some are using DHCP and some are static IP's. I am certain one router (connected to the external internet) is running proprietary Dlink software and the other bridged router is running dd-wrt. I set all of this up myself. This does not entirely rule out some very clever hack on the router side of things, or injected in multiple miner's source codes. It just seems rather unlikely to me at this point. As many of us as possible need to enable verbose logging to file for when this happens again. And it will almost certainly happen again, as there is money to be made by attackers exploiting whatever weakness allowed them to do so this time around. I have had logging enabled since the very beginning, but none of my equipment was affected by this problem. I did notice a few atypical packets logged on my firewall making me suspect that a local router attack could be part of the redirect to a rogue server, which is why I asked you about yours, as you actually witnessed the redirection of your hashpower. Agreed. I've been awaiting a reoccurence all day. Nothing so far, at all. If it's local I'm betting it's the d-link router software, as it's connected to the external internet. But my money is leaning a bit towards not local. Not enough though for me to be completely convinced. Too many unknowns at this point.
|
|
|
|
Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 08:25:31 AM |
|
Yes, this is the weakest link in my setup for sure. My configuration does not utilize any of the vulnerable equipment included in that list. (Not that someone somewhere probably doesn't know how to hack it!) Hmm, just checked through that list as well. My particular router is not included. Though, as you say, that certainly doesn't mean a lot.
|
|
|
|
utahjohn
|
|
March 23, 2014, 08:29:36 AM |
|
So by gaining access to a remote router is it possible to perform an attack of this sort? I am sure there are other resources such as the one I listed ...
|
|
|
|
Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 08:33:31 AM |
|
So by gaining access to a remote router is it possible to perform an attack of this sort? I am sure there are other resources such as the one I listed ...
Possible, yes. My router does not use default credentials though. Of course, backdoors are rife with these things.
|
|
|
|
utahjohn
|
|
March 23, 2014, 08:37:01 AM |
|
1 Gain ownership of router 2 determine OS 3 find miner process running 4 Alter pool info
|
|
|
|
Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 08:37:33 AM |
|
Okay, just checking information from last night.
It may not have happened quite simultaneously. I don't have enough information (didn't have verbose logging on) to be sure. I'm not even certain it affected every single one of my rigs, as when I noticed it on most of them I immediately began a slash and burn campaign on everything.
Unfortunately this muddies the waters a bit.
|
|
|
|
comeonalready
|
|
March 23, 2014, 08:37:52 AM |
|
So by gaining access to a remote router is it possible to perform an attack of this sort? I am sure there are other resources such as the one I listed ...
Possible yes, likely no. The simultaneous timing of the redirection attack would be very difficult to carry out without 'the short list' of miners' ip addresses which would only be obtained from the server, or the network on which the server resides.
|
|
|
|
utahjohn
|
|
March 23, 2014, 08:44:02 AM |
|
Considering that 'short list' ... only pools I have heard of being affected are multipool.us and wafflepool.com ... both hacked?
|
|
|
|
Zamboniman
Newbie
Offline
Activity: 56
Merit: 0
|
|
March 23, 2014, 08:44:32 AM |
|
For what it's worth...
When I first noticed the problem (maybe an hour or more after it likely occured) the first step I took is that I logged into each of my rigs and disabled the useast server (which each was pointing to). This had the effect of each rig going to the uswest backup server.
This immediately caused shares to once again be registered on wafflepool.
I didn't leave it at that, though. Worried, half an hour later, I power cycled routers and rigs, restarted miners, and monitored them, once again on useast, to see if shares were being registered.
They were.
Then I went to sleep, thinking I'd solve it in the morning.
|
|
|
|
comeonalready
|
|
March 23, 2014, 08:45:58 AM Last edit: March 23, 2014, 09:15:37 AM by comeonalready |
|
Considering that 'short list' ... only pools I have heard of being affected are multipool.us and wafflepool.com ... both hacked?
Only poolwaffle and whoever runs multipool.us can answer that. Perhaps by chance two of their servers are located in the same data center? We are working with maybe only half of the available information.
|
|
|
|
utahjohn
|
|
March 23, 2014, 08:51:07 AM |
|
More from multipool.us ... perhaps related ...
Mar 23 1:34 AM It's taking longer than expected to redownload blockchains. We are making DOGE, LTC and AUR a priority over the other coins and hope to have payouts processing for those coins within the hour.
Mar 22 9:59 PM The payout server has experienced a hard drive failure. We are currently restoring from backups. No user funds were lost. Your patience is appreciated.
|
|
|
|
|