Hi, I'm running Plesk 11.0.9 on a Centos 5.5. A website on that box got hacked last week and malicious code got inserted into some html/php files. So I went to find out what happened... I found no back doors by using rkhunter or manually searching for suspicious files in /tmp, etc. No activity at all in the php logs at the time of the attack. I also analysed of course the system logs (messages, secure, ...) - nothing that I could see either - except for an entry of an successful login to that domain via FTP just before the the modified dates of the infected files. I found one of the oldest infected files were in the folder of a hopelessly outdated version of a WYSIWYG editor and decided to blame that due to probability. So in order to recover I did in this order... * delete httpdocs from the website * change the FTP password * upgrade and update Plesk from 10.0.4 to 11.0.9 * upgrade php to php53 via plesk - this also updates mysql and phpmyadmin * yum update everything, also made sure I have the latest version of proftp * restore the entire website from a clean backup * delete the WYSIWYG folder that I believed had caused the vulnerability The next days I slept ok hoping I removed the attacker's entry point(s). ...so I thought! Today the website got hacked again - the same exploit on the pages, meaning same attacker. And again I can see nothing suspicious except for the successful FTP logon just before the modification time of the infected html/php: 2013-05-18T15:01:25.195559-07:00 MyServer proftpd: Deprecated pam_stack module called from service "proftpd" 2013-05-18T15:01:25.204731-07:00 MyServer proftpd: Deprecated pam_stack module called from service "proftpd" 2013-05-18T15:01:25.204831-07:00 MyServer proftpd: Deprecated pam_stack module called from service "proftpd" 2013-05-18T15:01:25.205183-07:00 MyServer proftpd: pam_unix(proftpd:session): session opened for user WEBSITEUSER by (uid=0) 2013-05-18T15:01:25.205244-07:00 MyServer proftpd: Deprecated pam_stack module called from service "proftpd" 2013-05-18T15:01:25.231034-07:00 MyServer proftpd[20243]: 127.0.0.1 (188.190.126.105[188.190.126.105]) - USER WEBSITEUSER: Login successful. 2013-05-18T15:04:08.095351-07:00 MyServer proftpd: Deprecated pam_stack module called from service "proftpd" 2013-05-18T15:04:08.095379-07:00 MyServer proftpd: pam_env(proftpd:setcred): Unable to open config file: /etc/security/pam_env.conf: No such file or directory 2013-05-18T15:04:08.095445-07:00 MyServer proftpd: Deprecated pam_stack module called from service "proftpd" 2013-05-18T15:04:08.095455-07:00 MyServer proftpd: pam_succeed_if(proftpd:session): error retrieving information about user 0 2013-05-18T15:04:08.095463-07:00 MyServer proftpd: pam_unix(proftpd:session): session closed for user WEBSITEUSER I know for a fact it couldn't have been the website owner because I didn't give him the new FTP password yet. # yum list | grep proftp psa-proftpd.i386 1.3.4a-cos5.build110121114.13 installed proftpd.i386 1.3.3g-2.el5 epel proftpd-ldap.i386 1.3.3g-2.el5 epel proftpd-mysql.i386 1.3.3g-2.el5 epel proftpd-postgresql.i386 1.3.3g-2.el5 epel I think I really hit a snag with this one - I have no idea where to go forward from here. I'd appreciate any ideas. Thanks. Philipp
On 5/19/2013 11:59 AM, Philipp Duffner wrote:> Hi, > > I'm running Plesk 11.0.9 on a Centos 5.5. > A website on that box got hacked last week and malicious code got inserted > into some html/php files. So I went to find out what happened... > > I found no back doors by using rkhunter or manually searching for > suspicious files in /tmp, etc. No activity at all in the php logs at the > time of the attack. I also analysed of course the system logs (messages, > secure, ...) - nothing that I could see either - except for an entry of an > successful login to that domain via FTP just before the the modified dates > of the infected files. > I found one of the oldest infected files were in the folder of a hopelessly > outdated version of a WYSIWYG editor and decided to blame that due to > probability. > > So in order to recover I did in this order... > * delete httpdocs from the website > * change the FTP password > * upgrade and update Plesk from 10.0.4 to 11.0.9 > * upgrade php to php53 via plesk - this also updates mysql and phpmyadmin > * yum update everything, also made sure I have the latest version of proftp > * restore the entire website from a clean backup > * delete the WYSIWYG folder that I believed had caused the vulnerability > > The next days I slept ok hoping I removed the attacker's entry point(s). > > ...so I thought! Today the website got hacked again - the same exploit on > the pages, meaning same attacker. > And again I can see nothing suspicious except for the successful FTP logon > just before the modification time of the infected html/php: > > 2013-05-18T15:01:25.195559-07:00 MyServer proftpd: Deprecated pam_stack > module called from service "proftpd" > 2013-05-18T15:01:25.204731-07:00 MyServer proftpd: Deprecated pam_stack > module called from service "proftpd" > 2013-05-18T15:01:25.204831-07:00 MyServer proftpd: Deprecated pam_stack > module called from service "proftpd" > 2013-05-18T15:01:25.205183-07:00 MyServer proftpd: > pam_unix(proftpd:session): session opened for user WEBSITEUSER by (uid=0) > 2013-05-18T15:01:25.205244-07:00 MyServer proftpd: Deprecated pam_stack > module called from service "proftpd" > 2013-05-18T15:01:25.231034-07:00 MyServer proftpd[20243]: 127.0.0.1 > (188.190.126.105[188.190.126.105]) - USER WEBSITEUSER: Login successful. > 2013-05-18T15:04:08.095351-07:00 MyServer proftpd: Deprecated pam_stack > module called from service "proftpd" > 2013-05-18T15:04:08.095379-07:00 MyServer proftpd: > pam_env(proftpd:setcred): Unable to open config file: > /etc/security/pam_env.conf: No such file or directory > 2013-05-18T15:04:08.095445-07:00 MyServer proftpd: Deprecated pam_stack > module called from service "proftpd" > 2013-05-18T15:04:08.095455-07:00 MyServer proftpd: > pam_succeed_if(proftpd:session): error retrieving information about user 0 > 2013-05-18T15:04:08.095463-07:00 MyServer proftpd: > pam_unix(proftpd:session): session closed for user WEBSITEUSER > > I know for a fact it couldn't have been the website owner because I didn't > give him the new FTP password yet. > > # yum list | grep proftp > psa-proftpd.i386 1.3.4a-cos5.build110121114.13 > installed > proftpd.i386 1.3.3g-2.el5 epel > proftpd-ldap.i386 1.3.3g-2.el5 epel > proftpd-mysql.i386 1.3.3g-2.el5 epel > proftpd-postgresql.i386 1.3.3g-2.el5 epel > > I think I really hit a snag with this one - I have no idea where to go > forward from here. > I'd appreciate any ideas. > > Thanks. > > Philipp > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos1. Did you create a really strong password? 2. Does the new password you created still function or has it been reset by the intruder? 3. Are any files/directories/or the root directory on that website set world writable? (many of those CMS systems required this) 4. Is it possible that the system you used to change the password has a keystroke recorder/virus on it? (How did the intruder get the new password?) 5. Are there any new unexplained users on the system? 6. Is there more than one place where logins via Plesk might use the old password which have not been updated? Otherwise, I think it might be a good idea to hit the Plesk list as that overlay does at times have security issues. It also has many other functions not CentOS related adding too many other variables for good troubleshooting here, unless you get help from another Plesk/CentOS user. 188.190.126.105 is your intruder from the Ukraine... You might want to grep for that through most of your system logs. For instance, could they be accessing an email account that used that old pass where maybe new passwords are automatically sent? You might consider firewalling out that Class C 188.190.126.0/24 while you do the repairs again. What is commonly known as the WordPress attacks are hitting just about every possible login mechanism available to the public. Are your passwords really strong? Do you have in place something to pause attempts, such as Fail2Ban, to everything from Webmail to CMS systems to FTP, SMTP, IMAP/POP, PHPMyAdmin and I mean everything. We have over 10,000 longterm bans in place at the moment. Something we have never needed before these attacks. John
On 05/19/13 11:59, Philipp Duffner wrote:> Hi, > > I'm running Plesk 11.0.9 on a Centos 5.5. > A website on that box got hacked last week and malicious code got inserted > into some html/php files. So I went to find out what happened... ><snip>> * yum update everything, also made sure I have the latest version of proftp > * restore the entire website from a clean backup > * delete the WYSIWYG folder that I believed had caused the vulnerability > > The next days I slept ok hoping I removed the attacker's entry point(s). > > ...so I thought! Today the website got hacked again - the same exploit on > the pages, meaning same attacker. > And again I can see nothing suspicious except for the successful FTP logon > just before the modification time of the infected html/php: > > 2013-05-18T15:01:25.195559-07:00 MyServer proftpd: Deprecated pam_stack > module called from service "proftpd"<snip> The bunch of these messages, above, make me wonder if the reason that the pam stack module is deprecated is vulnerability. Consider checking the proftpd configuration, and /etc/pam.d/proftp? whatever it's called, and see if you can change what it's calling. mark -- "The group mentality of the United States is fundamentally that of a teenager." -British Immigrant
On Sun, May 19, 2013 at 9:29 PM, Philipp Duffner <philipp at phphaus.com> wrote:> > I think I really hit a snag with this one - I have no idea where to go > forward from here. > I'd appreciate any ideas. >I use aide (akin to tripwire) to keep file signature db. The online db file is immutable but I also keep a copy of it offline (along with sha1sum) Run aide (the static binary) against the db file to detect changes (if any). Also rpm -qa --verify will list files whose MD5 sums have changed, not a full proof method. You may also look at fail2ban, mod_evasive, mod_security (EPEL repo). -- Arun Khan Sent from my non-iphone/non-android device (???? ????/???? ???)
From: Philipp Duffner <philipp at phphaus.com>> ...so I thought! Today the website got hacked again - the same exploit on > the pages, meaning same attacker. > And again I can see nothing suspicious except for the successful FTP logon > just before the modification time of the infected html/php: > ... > I know for a fact it couldn't have been the website owner because I > didn't give him the new FTP password yet.How did you change the password?? Remotely? Did you check your own PC? JD