Multiple YiiMP pools hacked, this is what we know so far..

[bluebox]

Hoo boy. You all have your work cut out for you, good luck!

[Decker]

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:

Code:

https://<pool_domain>/?address[]= 

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.

[crombiecrunch]

After running a security scan this is what came up

XSS vulnerability found via injection in the parameter address

Code:

GET /?address=String.fromCharCode%280%2Cw6w7atn4rh%2C1%29 HTTP/1.1

Host: xxx.com

[Nillecram]

Add :

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 26

Should do the job for this vulnerability.

Could you point me to other i'll try to correct them.

[minlot]

As it seems YiiMP has old YAAMP code (https://github.com/tpruvot/yiimp)

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/

[Decker]

http://www.yiiframework.com/news/78/yii-1-1-15-is-released-security-fix/

Latest Yiimp uses 1.1.18 version of Yii framework ... seems problem is not here.

[phm87]

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:

Code:

https://<pool_domain>/?address[]= 

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.

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.

[AltMiner.net]

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.

[minlot]

http://www.yiiframework.com/news/78/yii-1-1-15-is-released-security-fix/

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?

[ex_mac]

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:

Code:

https://<pool_domain>/?address[]= 

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.

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 ... ?

[doktor83]

vulnearability scanners should be run before hacking, not after
Anyways, noone uses apache ? Everybody is on lighttpd and nginx?

[AltMiner.net]

vulnearability scanners should be run before hacking, not after
Anyways, noone uses apache ? Everybody is on lighttpd and nginx?

We are running both - nginx for load balancing and static content.

[Bobby_Atlas]

Any new eyes on problem or how to fix it?

[ms5]

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

[MTopia]

Hi,
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,

[crombiecrunch]

Ive went ahead and cloned the yiimp github to

Code:

https://github.com/crombiecrunch/yiimp

so that issues are once again turned on.

[egyptianbman]

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

Code:

git status

, 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.

[oxothuk]

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.

[mintminty59]

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.

[Decker]

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:

Code:

$recents = isset($_COOKIE['wallets'])? unserialize($_COOKIE['wallets']): array();

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:

Code:

O%3A9%3A%22KrakenAPI%22%3A0%3A%7B%7D

That corresponds:

Code:

object(KrakenAPI)#1 (0) {
}                        

And do get request ?address= with this cookies. Answer of web server will be 500:

Code:

Internal Server Error
curl_close() expects parameter 1 to be resource, null given

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.