Security problem with filemng

[MartinSIT]

add:
there are some more questions... even if they dumped the database, i would imagen that the passwords are stored encrypted and not clean?

first: at least one of the hacked customers had a password 12 characters long, with numbers and alpha.. you can't brute force them in that short time!

second: another customer don't have plesk panel access! it is switched off in the controls. so even they have this password, it should not work because the control panel access is turned off!


in my opinion, it is to easy to say they used the database they dumped a few month ago!!

 

[DaveW_IRE]

The oringinal exploit was a php file used by Plesk to provide a remote control API called agent.php, I think this is how an Expand server would remotely control satellite Plesk servers. Unfortunately it was vulnerable to SQL injection before the patch was released.

What seems to have happened is that they pulled the data off the servers using this exploit to harvest logins and passwords before the patch was released. ( I would really like to know what exactly was taken, so that we can prepare for what ever happens next)

There were some traces left behind by them and we audited our servers for these traces and changed all the passwords on those effected servers, what we should have done was change them on ALL servers.

@MartinSIT, the passwords in the PSA database are not hashed, the client you had with a 12 char password was hacked because they simply read his password from your database some time ago. If Plesk is turned off for a customer, the agent can still access his files through the file manager, this would be all part of the Plesk API.

Do as the guys here say;

1>Clear all sessions
2>Checked that your Plesk is patched and up to date
3>Reset PWs

We still need to find out exactly was was harvested in the first attack.

 

[MartinSIT]

thanks Dave. well, that the passwords are stored clear in the database is like breaking a law
i'm shocked about that!

Dave, could you give me a hit, how can I go to "filemanager" if control access is disabled?

thanks

 

[DaveW_IRE]

@MartinSIT, Im assuming that you can still access the filemanager through the API even if it is disabled from the clients perspective. This would be used by the Expand server to access files on that domain.

 

[MartinSIT]

allrigt, so same port plesk is using? I renamed the "filemng" link, is that enough?

 

[DaveW_IRE]

@MartinSIT, just make sure Plesk is up to date and is patched correctly, you should be fine.

 

[Dreiy83]

You can rename it to stop the abusers from changing your files, but remember that these abusers get administrator privileges in the Plesk panel, so they can do more than just change files through the file manager.

This is based on this article though:
http://www.thewhir.com/web-hosting-...nerability-revealed-by-hacker-selling-exploit

Let's hope Parallels has 8000 dollars to spare to buy this exploit to research it
I'm still hoping it's all a hoax... Like many of you, I don't want to upgrade my Plesk9 servers.

 

[Blankster]

Thanks for the link to http://krebsonsecurity.com/2012/07/plesk-0day-for-sale-as-thousands-of-sites-hacked/ in your newsletter and the additions related removal. What is never mentioned is that the attackers not only stole the DB's, they've allready installed rootkits in the cgi-folders of the domains. This isn't only happend to me. I know other admis which had the same experience.

You say on your site that it would be the most secure way if we update to Plesk 11. The problem is that updating plesk isn't always a pleasure (to say it nicely). What I would like to know because I can't update due various circumstances. So what I wanted to know are the following things:

1. Whats the best way to change the default port safety to another (on a normal Plesk 9.5.4 latest patched installation)? In your knowlege base you mention that there can be some errors. Give us people the chance to protect us...

2. Would it perhaps a simple (but efficient) security measure to put up a .htaccess passwort protection in front of the pannel and tell only the customers the password before they even can login?

3. What additional security functions can/should we use to block all risky traffic on the panel itself?

(such additional information would be really really interesting and hardly needed)

I'm sure it's also not a nice situation for you (SW Soft) and it's not nice to get into a **** storm.. But I think this can be your chance to proove that you are really the best CP out there if you help us admins as much as possible.

 

[DaveW_IRE]

Hi Blankster,

Can you tell us more about these rootkits? What do we look for?

 

[Blankster]

You can find them when you do a:

ps aux | grep 'vhosts'

Then you can see perl scripts running in the cgi-folders of the domains. But there are also a lot not running. In my case it were perl scripts and you can get instantly that they are root kits when you edit them. They have different names. A friend of mine told me that there were also .cgi scripts (not perl based on his server).

In my case it was easy, no of my customers is using perl or cgi scripts. So I could delete the whole content of their cgi-bin folders.

The rootkit processes respawned if they aren't deleted all and if it's still possible for the attackers to use filemng. I've renamed it and replace the passwords step by step. I know that's not the best solution, but I've to need a real-life solution and can't instantly change all passwords. Of course admin was changed after the basic counter-measures where taken.

But again, I ask SW Soft how to protect the pannel additionaly? I think perhaps there can be very simple modifications which work. Of course all passwords need to be change, but real life is much more complicated than in theorey.

 

[DaveW_IRE]

Hi Blankster,

No evidence here of pearl scripts uploaded to the servers and no rootkits running, and no further intrusions once we reset all the passwords.

Will keep monitoring though.

 

[Dreiy83]

@Blankster:
Edit this file:
/etc/sw-cp-server/applications.d/plesk.conf

And change the port number.
Restart sw-cp-server and it's fixed:

/etc/rc.d/init.d/sw-cp-server restart

I guess this will block the automated attacks for now.

 

[Mennox]

solution

Hello everybody,

this morning, at 6:00 (GMT+2), about 400 of my domains hosted on various plesk server were infected.
We can try to fix this problem, for me there are two solution:

First semi-fix

/etc/init.d/psa stop

Second semi-fix

find /var/www/vhosts \( -name "*.js" -o -name "*.php" -o -name "index.*" -o -name "default.*" \) -ctime -1 -exec sed -i 's/km0ae9gr6m[^>]*qhk6sa6g1c//g' {} \;
find /var/www/vhosts \( -name "*.js" -o -name "*.php" -o -name "index.*" -o -name "default.*" \) -ctime -1 -exec chattr +i {} \;

Thirs FIX

http://kb.parallels.com/en/113321

 

[Dreiy83]

Hi Mennox,
For the records, did you apply the security fixes on the 10th of Februari and did you change all passwords?

 

[Blankster]

Thanks for this information. Does the port change not imply other problems with Plesk? Tought I read in the KB that there can happen problems when the default port is changed.

What do you think about protecting the CP additionally with a .htaccess Password?

 

[MartinSIT]

I also changed the default port. i hope it will work

otherwise we could install a port forwarding with iptables so plesk stays on 8443 (local) ..

 

[Blankster]

I think the port forwarding would be a good idea (localy). How do you set up this in detail?

Thanks a lot for your help. This would be the information which I expect to get from SW Soft.

 

[MartinSIT]

well, i haven't test it jet. but theoretical it should be something like this:

iptables -t nat -A PREROUTING -p tcp -d <YOUR_SERVER_IP> --dport 10000
-j REDIRECT --to-ports 8443

(untested)

 

[Dreiy83]

We have been running Plesk on a different port for years and there are no problems.
About the htaccess:
I'm not sure if the Plesk https server picks up htaccess, but you could try.

 

[MartinSIT]

ok, thanks for sharing your experience..

i wished I had changed the default port of plesk, too