hi....I was mining on both Zpool and Yiimp...... it appears that Zpool also possibly hacked as they have been offline round about the same time as yiimp.
Yes, both zpool and yiimp run on yiimp's mining software. Any pool running on yiimp is at-risk, if not already hacked. 
Topic: Multiple YiiMP pools hacked, this is what we know so far.. - page 4. (Read 15717 times)
hi....I was mining on both Zpool and Yiimp...... it appears that Zpool also possibly hacked as they have been offline round about the same time as yiimp.
Seems i found a way (not sure at all) how attackers could upload something on server. Let's see in yaamp/modules/site/wallet.php , it uses unserialize for cookie variable wallets:
In cookies on client side we could put everything, including PHP Objects. Just read this - https://www.owasp.org/index.php/PHP_Object_Injection .
Ok. Let's try do something. I found KrakenAPI class in yaamp/core/exchange/kraken.php that has a destructor. Ok, let's pass in $_COOKIE['wallets'] serialized object of that class. For example, we set cookie wallets to this:
That corresponds:
And do get request ?address= with this cookies. Answer of web server will be 500:
Because on unserialize("O%3A9%3A%22KrakenAPI%22%3A0%3A%7B%7D") it calls __destruct() of KrakenAPI class. Seems attackers can use this or another class to upload lds.php.
Code:
$recents = isset($_COOKIE['wallets'])? unserialize($_COOKIE['wallets']): array();
Ok. Let's try do something. I found KrakenAPI class in yaamp/core/exchange/kraken.php that has a destructor. Ok, let's pass in $_COOKIE['wallets'] serialized object of that class. For example, we set cookie wallets to this:
Code:
O%3A9%3A%22KrakenAPI%22%3A0%3A%7B%7D
Code:
object(KrakenAPI)#1 (0) {
} Code:
Internal Server Error
curl_close() expects parameter 1 to be resource, null given
That is exactly what I did, and have no issues with someone trying to get in.
I run multiple VM ware machines that house each component, 1 for web , 1 for yiimp , 1 for database , and the others for wallets. With strict firewalls inbetween. One weakness I found was having the console control in wallets tab where you can send commands to the wallets via RPC, has anyone ever considered the hackers just manages to get the admin screens up and sent the pay commands via the console?
I always have my wallets encrypted with a HEX pass key which are running on a windows machine. I only ever open the wallet when I need to make payments. That was one of the only secure ways I could think of to make sure my coins remained safe.
Having things automated is where you can introduce weak points all over the system.
I run multiple VM ware machines that house each component, 1 for web , 1 for yiimp , 1 for database , and the others for wallets. With strict firewalls inbetween. One weakness I found was having the console control in wallets tab where you can send commands to the wallets via RPC, has anyone ever considered the hackers just manages to get the admin screens up and sent the pay commands via the console?
I always have my wallets encrypted with a HEX pass key which are running on a windows machine. I only ever open the wallet when I need to make payments. That was one of the only secure ways I could think of to make sure my coins remained safe.
Having things automated is where you can introduce weak points all over the system.
Is anyone catch this php? Maybe add folder where hackers put file to some synch software, like dropbox , who have file history.
Or just try to restore deleted file.
Or just try to restore deleted file.
I've been working on setting up a pool using yiimp and have done various things to harden the infrastructure. Without having to comb through the code which would be daunting, a list of items I've done to quickly harden the pool:
1. Run in docker -- this one is huge. My current setup is to run the web interface via one container, the stratum listeners on another container, each wallet on its own container, etc. Everything is as though it's on its own "server".
2. Make everything read-only. The only hiccup is the assets directory whose vulnerability can be mitigated by nginx. I modified the path of the yaamp/runtime directory to be outside of the webroot.
3. Set up cloudflare.
4. Since I'm using docker, I mount the directories into their various places. This has the benefit of allowing me to keep the repo as one whole piece, so I can go into it and run, and see what files have been modified.
I've been working on this on and off over the last week so there's probably a few other things I've done that I can't think of off the top of my head. -- Just wanted to share some ideas I've had on how to harden without having to rewrite the whole site.
I should clarify that I only mount directories relevant to each thing. I.E. The web container only has access to the web directory, not the whole repo. This helps keep credentials hidden from potential hackers of the web ui.
1. Run in docker -- this one is huge. My current setup is to run the web interface via one container, the stratum listeners on another container, each wallet on its own container, etc. Everything is as though it's on its own "server".
2. Make everything read-only. The only hiccup is the assets directory whose vulnerability can be mitigated by nginx. I modified the path of the yaamp/runtime directory to be outside of the webroot.
3. Set up cloudflare.
4. Since I'm using docker, I mount the directories into their various places. This has the benefit of allowing me to keep the repo as one whole piece, so I can go into it and run
Code:
git status
I've been working on this on and off over the last week so there's probably a few other things I've done that I can't think of off the top of my head. -- Just wanted to share some ideas I've had on how to harden without having to rewrite the whole site.
I should clarify that I only mount directories relevant to each thing. I.E. The web container only has access to the web directory, not the whole repo. This helps keep credentials hidden from potential hackers of the web ui.
Ive went ahead and cloned the yiimp github to so that issues are once again turned on.
Code:
https://github.com/crombiecrunch/yiimp
Hi,
timestamps show hijacked coins txs correspond with :
we're digging and monitoring.. will keep you posted if we stumble on more info or reach solutions
regards,
timestamps show hijacked coins txs correspond with :
Code:
"GET /api/walletEx?address=YOU_COIN_WALLET%20or%20TAG%20for%20Wallets%20substitution HTTP/1.1" 200 5 "-" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36"
we're digging and monitoring.. will keep you posted if we stumble on more info or reach solutions
regards,
i wonder if it had anything to do with miners, or spoofing as one
riding on someone like u can prove they did this like u had government backing would be stupid ... if you want to know who did it you have to trace through that tor node that left a mark ... and know whereabouts on the darknet it may have been shared meaning your target is more than one... the first thing to figure out is where the breach is took place, how they got in and what they did... address the side effects of the breach then patch or migrate your host and relaunch with better security.
sucks when things like this happen
sounds to be like a problem similar to mongo-db default installs being insecure
riding on someone like u can prove they did this like u had government backing would be stupid ... if you want to know who did it you have to trace through that tor node that left a mark ... and know whereabouts on the darknet it may have been shared meaning your target is more than one... the first thing to figure out is where the breach is took place, how they got in and what they did... address the side effects of the breach then patch or migrate your host and relaunch with better security.
sucks when things like this happen
sounds to be like a problem similar to mongo-db default installs being insecure
Any new eyes on problem or how to fix it?
vulnearability scanners should be run before hacking, not after 
Anyways, noone uses apache ? Everybody is on lighttpd and nginx?
Anyways, noone uses apache ? Everybody is on lighttpd and nginx?
We are running both - nginx for load balancing and static content.
vulnearability scanners should be run before hacking, not after
Anyways, noone uses apache ? Everybody is on lighttpd and nginx?
Anyways, noone uses apache ? Everybody is on lighttpd and nginx?
May be i'm totally wrong, but i think first we should check filtration of input parameters in yaamp/modules/site/wallet.php and other places where address parameter and $_COOKIE['wallets'] exists. For example, there is no checks of type of this parameter. Small example, if we pass an array in address argument:
We get Internal Server Error with message substr() expects parameter 1 to be string, array given. This is because getuserparam in libUtil.php doesn't check type of argument. Also this happens if we pass serialized array as address in wallets's cookie.
Code:
https:///?address[]=
Based on discussions on IRC, we've disabled the front end (new folder, html page, change in vhost, restart apache) to avoid any acces to wallet pages, explorers and so on, we've block port 6667 on ufw and another firewall (suggestion of Espylon3 on his pool website). I don't know if this can prevent the issue.
Don't help,
all other port is disabled on my pool.
for access from web was open one directory /assets , and his write file to this directory.
so problem on php code, but on what part ... ?
Latest Yiimp uses 1.1.18 version of Yii framework ... seems problem is not here.
Yep it uses, but if there's old obsolete code from old "other projects" as Github page says, it might be possible to exploit those as well?
We will only start Pool once we have identified the issue. Also all private keys may have been compromised, so all pool owners need to recreate wallets to be totally sure.
May be i'm totally wrong, but i think first we should check filtration of input parameters in yaamp/modules/site/wallet.php and other places where address parameter and $_COOKIE['wallets'] exists. For example, there is no checks of type of this parameter. Small example, if we pass an array in address argument:
We get Internal Server Error with message substr() expects parameter 1 to be string, array given. This is because getuserparam in libUtil.php doesn't check type of argument. Also this happens if we pass serialized array as address in wallets's cookie.
Code:
https:///?address[]=
Based on discussions on IRC, we've disabled the front end (new folder, html page, change in vhost, restart apache) to avoid any acces to wallet pages, explorers and so on, we've block port 6667 on ufw and another firewall (suggestion of Espylon3 on his pool website). I don't know if this can prevent the issue.
Latest Yiimp uses 1.1.18 version of Yii framework ... seems problem is not here.
As it seems YiiMP has old YAAMP code (https://github.com/tpruvot/yiimp)
Someone who knows stuff, should check that the code is not from YAAMP 1.1.14
https://www.cvedetails.com/cve/CVE-2014-4672/
http://www.yiiframework.com/news/78/yii-1-1-15-is-released-security-fix/
Quote
There a lot of unused code in the php branch. Lot come from other projects I worked on and I've been lazy to clean it up before to integrate it to yaamp. It's mostly based on the Yii framework which implements a lightweight MVC.
Someone who knows stuff, should check that the code is not from YAAMP 1.1.14
https://www.cvedetails.com/cve/CVE-2014-4672/
http://www.yiiframework.com/news/78/yii-1-1-15-is-released-security-fix/
Add :
Should do the job for this vulnerability.
Could you point me to other i'll try to correct them.
Quote from: yaamp/modules/site/wallet.php
if (!is_string($address)) {
throw new Exception("Do not try to hack !!");
}
if (mb_strlen($address) > 0 && !ctype_alnum($address)) {
throw new Exception("You are a bad boy !!");
}
in yaamp/modules/site/wallet.php line 26throw new Exception("Do not try to hack !!");
}
if (mb_strlen($address) > 0 && !ctype_alnum($address)) {
throw new Exception("You are a bad boy !!");
}
Should do the job for this vulnerability.
Could you point me to other i'll try to correct them.
After running a security scan this is what came up
XSS vulnerability found via injection in the parameter address
Host: xxx.com
XSS vulnerability found via injection in the parameter address
Code:
GET /?address=String.fromCharCode%280%2Cw6w7atn4rh%2C1%29 HTTP/1.1
Jump to: