By

Another Round of Beladen? Or, The New "Go" Infection

On Wednesday July 22, 2009 we started seeing what looks to be a new round of beladen style website infections by cybercriminals.

The reason we think they’re beladen style is that they appear to infect all the websites on shared servers and they also seem to be remotely controlled with a “on as needed” mode.

This infection resulted in thousands more sites being tagged with Google’s “This site may harm your computer”.

According to Google Diagnostics for certain websites we were asked to help with, this is what was shown:

“Malicious software is hosted on 4 domain(s), including: ventsol.info/, ina6co.com/, goscansoon.com/.”

Other sites we were asked to help with were also showing these domains in their Google Diagnostics:

  • daobrains.info/
  • safetyshareonline.com/
  • goslimscan.com/
  • goscansome.com/
  • globalsecurityscans.com/

Our scanners were detecting suspicious obfuscated javascript on the sites we were helping with, but it appeared to only be setting cookies to expire the following day. The obfuscated javascript was this:

malscript-0-11

Which deobfuscated looks like:

sessionid=39128605A531; path=/; expires=Thu, 23 Jul 2009 18:42:32 GMT

We found similar code with various names for the “var” part (replacing oigmlob) above in the obfuscated code. Other names were:

  • dtxzidl
  • bmno
  • wcdg
  • tpet
  • stqfpbc
  • meuhgor

In addition, we also saw various combinations of the hexidecimal numbers to replace the actual letters. For instance, instead of pa\x74h=/\x3b ex\x70ir\x65s we found these as well:

  • p\x61th=/\x3b exp\x69r\x65s
  • p\x61\x74h=/\x3b \x65x\x70i\x72es
  • p\x61t\x68=/\x3b expi\x72e\x73

All of these deobfuscate to: path=/; expires

One common theme was the hosting providers. Wouldn’t you know that a day after we blog about how wrongly accused many hosting providers are for the gumblar, martuz and iframe infections that they actually become the target.

It appears that these recent infections are a server issue and not just a specific website on a shared server. How the server became infected is purely speculation. Could it have been from one set of compromised FTP credentials that was able to infect the server and then control other sites as well? Could it have been SQL injection for one site that then gave the attackers a method to start a process on the server thereby controlling all the websites on that server?

Who knows. At this point all we do know is that this does affect all the websites on infected servers.

How do we know that?

We created a program for situations like this. It grabs a list of all the websites for a specific IP address and starts checking them. On some IP addresses 91% of the websites were showing the obfuscated cookie code from above. Our thought is that since this is an “on again – off again” type of infection, the other 9% were dormant when our program scanned those sites.

Another interesting observation was that for a specific IP address, each website showed the exact same obfuscated code. While websites on different IP addresses had similar obfuscated code with the slight variations mentioned previously.

The first step in this “drive-by” infection was to set a cookie on the visitor’s PC. Then if that same visitor came back within the expiration period of the cookie (24 hours), this would be delivered to their browser:

malscript-1-1

Which essentially does a Meta tag redirect. The above deobfuscates to:

malscript-2-1

We did see some of the other domains mentioned earlier in place of safetyshareonline.com and the goscansoon.com.

The whole purpose of this attack is to infect the PCs of visitor’s to these websites. This is done with this bit of social engineering code:

malscript-3-1

This code uses some fake graphics (okay the graphics are real, but they’re not the “official” graphics of Microsoft) in an attempt to trick the visitor into believing they have a virus. The code starts by checking to see if the operating system on the visitor’s PC is Microsoft’s Vista. If it is, it displays “Vista” looking graphics. If not Vista, then it assumes Windows XP and shows different graphics.

No matter who you are or what operating system and browser you have, this code shows a window that looks like a “Windows Security Center” window and it informs you that:

 “Virus (I-Worm.Trojan.b) was found on your computer! Click OK to install System Security Antivirus.” If you select “OK” from their screen it will download their “antivirus”.

If you cancel, a new alert is displayed with this message:

 “Windows Security Center recommends you to install System Security Antivirus.”

If you cancel that, it will display again.

One more cancel gets you to this message:

“Your computer remains infected by viruses! They can cause data loss and file damages and need to be cured as soon as possible. Return to System Security and download it to secure your PC”

This is some very elaborate scheming by hackers and cybercriminals just to get visitors to download their “mother lode of infectious code”, but it will probably work on many people.

We decided to show the code here, although the code is inserted graphic files, so that if your website starts being tagged as suspicious by Google with some of the domains listed here, and you get the “This site may harm your computer” moniker, you can compare this code to some of the code you might see in your site and have a better understanding of what is going on.

What To Do

First you need to contact your hosting provider. Have them read this blog post so they can also better understand what’s going on.

Have them check at the server level for unusual processes running on the server. If you’d like, have them contact us and we can help them diagnose this further. We can show them the other websites on your server that are also infected with the exact same code.

At this point we still don’t know how the server gets infected. Be prudent and scan your PCs with a different anti-virus than what you’re currently using. Why? Because if you are infected and you have anti-virus already installed, then it’s obvious that the virus knows how to evade detection of your current security.

We’ve had good success with AVG, Avast or Avira. If you already have one of those installed, then use one of the others. You need to use something different. Scan and clean all PCs with FTP access to your site.

Then change FTP passwords on all of your accounts.

This will have to be done as soon as you start seeing these infections as it may take some time to fully investigate and remediate – so don’t be late (sorry, it’s been a long few days).

Post comments below if you’ve been infected by this or know someone who has.

Thank you.

Friday July 24, 2009 update: We worked with a couple different hosting providers who had servers infected with this and it appears the way these malscripts are injected into the the webpages is through a process on the server. The cybercriminals have cleverly named this process “crontab” however this process runs under the user name “nobody” typically the same user name that Apache (or httpd) runs as.

The file that executes this process is remotely deleted by the cybercriminals controlling it so it just runs in memory. Once the server is rebooted, the process disappears and doesn’t appear to return. The hosting providers also mentioned implementing suPHP as an aid to blocking this from happening again.

This is quite clever as how many times does a shared server really get rebooted? Probably not very often unless there’s a reason to shut-down numerous (hundreds?) websites all at once.

Keep posted, we’ll be adding more information as we get it.

14 Responses to Another Round of Beladen? Or, The New "Go" Infection

  1. NetPanther says:

    I can confirm your findings, we are having similar problems in Germany. In our case the var is called “tpet” and the script is setting a session id of 39128605A531, too.

    However our visitors are being redirected to landshaft[dot]info. The page is providing some type of scareware, but itself serves a FakeAlert.KJ (AVG calls it that).

    Hitherto analysis showed the server is appending malicious code to literally all PHP scripts at runtime. Maybe through auto_append_file/auto_prepend_file in php.ini oder using php_value in .htaccess at global scope!? I cannot verify that, as I’m just a shared hoster’s customer though.

  2. NetPanther says:

    By the way the faked virus warning is written in German in our case, so obviously this is a global threat.

    • admin says:

      Yes. We’ve experienced the same thing with hosting providers from other countries. If the majority of websites on a shared server are based on a specific language, the fake virus warning is also in that language.

  3. NeedHelp says:

    I need serious help. I am having major troubles with this exploit. I have been hit and cannot find out how they are getting on the system. My server is older but is up to date as it can get. Running Red Hat 9. I can find no erroneous running processes and no corrupt files on the system. Whatever is running only runs strictly in memory without showing up in the process list.

    Unfortunately at this point the short term answer is not upgrading to the latest fedora. But that will definitely happen before too long. Any help would be greatly appreciated.

  4. Helvetica says:

    Our forum (Switzerland) has been hit by these swine. Very annoying and I hope that our programmer can fix it, as I have no more access to our server.

  5. NetPanther says:

    Just now I detected another attack here in Germany, which seems similar to those noticed before. When calling a php file, a fake virus warning shows up randomly (x out of 100 times).

    The scripts sets a cookie called “n_sess_id” and redirects to a page called “best[minus]virus[minus]scanner5[dot]com”. Maybe a new round?

    • admin says:

      Yes. The latest attack is creating the cookies with n_sess_id and from what we’ve seen, quite often it’s a server side compromise. We don’t have any real details on it as far as what to look for. But it does seem like it’s a process running as the same user as Apache is. So it’s very similar to previous server side infections.

      Do you have access to any servers that have been hit by this?

  6. Csaba says:

    Hi,

    I also found a server with this new “n_sess_id” infection. I couldn’t find any suspicious process or even modified binary (of course, this check is not 100% correct on a running server). The interesting thing is the apache sometimes gives this infected content instead of a static page even! So, there is no PHP or anything else is used…

  7. admin says:

    @Csaba,

    You probably won’t see any suspicious process or even a modified binary, what we’ve found is that there is an infectious .php file that contains some base64 code. The code is the binary (ELF) that takes advantage of an Apache APR bug of some sort. Whenever the .php file is POSTed to with the correct parameters, the infection is live for some period of time. There is no binary to find because it’s obfuscated in the base64 code.

    If you have access to the root of the server, you can search all websites for a .php file with base64_decode in it as a start. However, we’ve been seeing where the .php file has hidden the base64_decode like this:

    ?php $PyIqJDl=’#####e##############################v###a####l(b########a####s###e###########6##4##########_##d###eco###d####e#######(#\’ZXJ

    Then there’s a piece of code at the end that looks like this:

    $PyIqJDl=str_replace(‘#’, ”, $PyIqJDl);

    Which removes all of the #’s and reveals the eval(base64_decode(… string.

    Do you have root access to this server? If so, please let me know as I would like to gather as much information as possible and let the world know, what to look for.

    Have you seen any POST requests in the access.log? It might look like this:

    2xx.2xx.2xx.14 – – [30/Sep/2009:18:24:51 +0100] “POST /test/php/test.php HTTP/1.1” 200 281 “http://www.google.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)”
    7x.x2.1xx.1xx – – [30/Sep/2009:18:24:52 +0100] “POST /test/php/test.php HTTP/1.1” 200 8976 “http://www.google.com” “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Alexa Toolbar)”

    Let me know…

  8. an ISP Admin says:

    Hi,

    Admin is right. He has hit the nail right on the head. I spent 6 days chasing this problem down myself and found the problem was initiated by PHP scripts that were taking over apache children and serving malicious redirect requests.

    I made a write-up about this with all the gory details, including a couple of different detection methods.

    http://smaert.com/apache_mischief/writeup.txt

    Hope it helps.
    -an isp admin

  9. Dilip Kumar says:

    My Website http://dilipkumar.in hosted on a shared webhosting service is also having the same problem from pretty long time. I many times contacted The Hosting providers – but they are unable to understand the problem fully…. and are opining that the problem is with mallicious code on my website.
    The treat is such a thing it appears very randomly initially I used to think the problem is only with homepage.. but the problem is with every file.. Once it happened that My robots.txt as cached by the Google (as seen in webmaster tools) also shown that obfuscated javascript cookie code.. huff….
    If some one found out the problem.. please let the people know…..
    All my hard earned meager traffic will be lost .. if not addressed soon..
    Thanks for the Post

  10. Kepi says:

    Thank you very much an ISP Admin! With small tweaks in you perl script, we successfully manage to detect this problem

  11. SEO-Bliss says:

    Some questions:
    -Is there any other way that hackers “activate” this script, other than the POST method?
    -About the perl script: has anyone gotten this to work on Centos5?
    -Has anyone seen child processes stay alive after a re-boot?
    Thanks.

  12. admin says:

    Yes. They also include it in legitimate .php files. That way, whenever that file is accessed or included in another file, their process runs and re-infects the site.

    What kind of errors on your getting with the perl script? I haven’t tested it on Centos5 but I can try and help you debug it.

    I have seen where the child processes will re-activate after a re-boot. Like mentioned above, sometimes the code will be in a legitimate file so as soon as that .php file is called, either by a browser or as an included file, it will fire off the child process and re-activate.

    If you have root access to the server, you can scan all .php files for eval(base64_decode and examine those files. If it’s a shared server you’re scanning, the website you find those files on, is probably the one that infected the server. I would suggest contacting the website owner and making them aware of the infection so they can scan all their PCs for viruses that may compromised their FTP credentials.

Leave a Reply

Your email address will not be published. Required fields are marked *