Editer l'article Suivre ce blog Administration + Créer mon blog
30 septembre 2009 3 30 /09 /septembre /2009 02:39
Let's act just for once as a Computer Security Incident Response Team member. What a great pleasure...

An user called the helpdesk because the antivirus was yelling about a supposed malicious PDF file.
The only problem was: this alert was happening while surfing on a professional website, a supposed 'trustworthy' one...

At first, I have to say I did not believe the AV detection was reliable, since I personaly worked on AV issues in PDF detection...

But... a quick check of the source code of the webpage proved that a strange link had been added. This link was pointing to a russian website, and more especially to a JS file (ECMA script). This obviously drew my attention.

First of all, about the domain itself:
www.bannerdriven.ru. The suspect script is: www.bannerdriven.ru/ads.js.

If you search for it using Google, you just find out that hundreds of websites have been compromised (their source code has been indexed by Google, and it shows to you the malicious link). Here is a screenshot of what I got on the 26th of september:

It appears that most (if not all of them) of those websites run IIS 5, 5.1, and 6.

It also seems that the attack is an automaticated one, targeting:
- the "TITLE" part of the webpage
- any link pointing to an ASP page hosted on a targeted website.

Thus, it is only needed to access a compromised website to see the attack being tried on the user's computer!

Then, about the internet domain. I find the DomainCrawler results quite interesting:
See NS servers, WhoIs, and even IP-addresses.

If you look at the malicious server itself, there is a surprise about the DNS. Here is a screenshot of requests through OpenDNS: differents IP, different machines... This is an evidence of the use of the fast flux system.

Running the suspect link on a hardened computer, Firebug helped me discovering the obfuscated JS file was just redirecting the user to:

Then, the victim is being redirected to:
- http://bannert.ru/ad/js.php?id=2&PHPSESSID=o0akmam1j3ida51vv4qltqlse5
- http://bannert.ru/ad/js.php?id=3&PHPSESSID=o0akmam1j3ida51vv4qltqlse5

A bit of reverse engineering made me understand the malicous website uses:
- cookie and PHP session ID, to make sure the attack is tried only once on a same computer
- autodefense system: wget download blocked!  (UserAgent detection, I guess)
- visitor's IP addresses recording, to make sure the attack is tried only once on a same computer

After that, two attacks are launched on the victim's computer:
- a malicious SWF:
- the PDF, apparenlty downloaded from http://bannert.ru/ad/spl/files/info.php

At the end of it, a fake error page is being displayed to the user, not to warn him about something suspicious.

If the attack succeeds, then the malicious software AntivirusPro2010 is downloaded and directly installed on the computer. Compromised computers even went to crash (BSOD, on WinXP SP2).
Clearly, this is again about financial fraud...

What about the Internet domain bannert.ru? well yeah, the DomainCrawler results are again quite interesting:

Here is a VirusTotal comparative analysis of the malicious PDF: https://www.virustotal.com/fr/analisis/1fc413651af1fe6901581888f53b5bf53669067d270b3e2a291929fc4c4aab52-1254273671

Here is what I could say at the time of the discover (09/27):
- McAfee: detection OK (Exploit.gen PDF, updated 16th of September)
- Sophos: no detection (I sent them a sample on the 09/29)
- ESET: no detection (still true on the 30th of September)
- PC-Tools Antispyware: no detection (still true on the 30th of September)
- MalwareByte: no detection (still true on the 30th of September)

At the time of writing (09/29), we still don't know for sure the exact attack being used to compromise the IIS servers. I believe it is one of the last IIS vulns (IIS FTP?), other people think it is about ASP / SQL injection... 
I'll post further details as I find out.


Update 10/05:

Here is a VT analysis of the SWF file:
Still very few AV detection huh...  5 AV out of 41...

More about the IIS attack method:

Well yeah, I think I've lost my bet.
Apparently, it is a real SQL injection, like a classical one...  supposedly coming from an ancient BotNet (The ASProx one). A simple Google search,
http://www.google.fr/search?q=sql+injection+bannerdriven.ru&hl=fr&sa=2 led me last night to: http://garwarner.blogspot.com/ 
I'd like to congratulate the author for his great job.

Further on, we even have IIS logs as an evidence of what happened:
Some of the first bursts have certainly been launched of the 25th of September...

For those who wanna see the whole SQL injection command line, I think there it is:

Then, if that helps, some guys published automated tools (scripts) to clean up compromised MS SQL databases:
Use with care, in case of you don't know what you're doing exactly...

One last point should be emphasized, IMHO.
Compromised websites were indexed by Google, okay. But, if you search Google for the different malicious URL, you may discover that the compromised websites were indexed with a malicious JS file link, which is no longer the one you could see in their source code! (well, we assume here those websites are still compromised when you look at their source code...).
That means... that the BotNet has got a kindda update feature, which is able to change/update the URL being injected within vulnerable pages!
It also could mean that the attack is being tried repeatedly on IIS servers that were already compromised, but with a different malicious URL, and until the SQL injection weakness has been corrected.

Thus, the guys who try to clean up the SQL databases and webpages have to keep in mind that if they don't correct the security weakness which had permitted the SQL injection, their IIS will be compromised again sooner or later...

Update 10/20:

New domain being inserted within the webpages source code: doublebanner.ru.
There is a new file: counter.js.

Are the bad guys trying to count their victims?


To conclude with, once again folks:
1- use NIPS (Network Intrusion Prevention System)
2- use WAF (Web Application Firewall) to protect your applications! Classical firewalls are not suitable to do that...
3- don't forget to sanitize the user data inputs... (a bit complex to do if the application is already deployed... I know)
4- update all your applications on the stations and servers, not only MS products!
5- if you website has been compromised, don't forget to tell your external customers (provide an AV procedure link...) and keep an eye on the services that could give a "bad security reputation" to your website
6- whether your website has been compromised or not, make sure your traceability is operational and protected!

Partager cet article



Uch - Issue with Site 31/07/2014 14:00

Phishing, malicious websites and files, website hacking all seem to be big aspects of the internet world today, simply because the internet has become increasingly more popular. I can't even count the amount of times I've had to deal with hacking incidences.

sports dissertation 25/11/2009 11:21

Blogs are so informative where we get lots of information on any topic. Nice job keep it up!!

ANONYMOUS 07/10/2009 21:13

Thanks a lot to works free for google...
All over the world we can find information about google security failures in many blogs, website.
It is a real pleasure to use WWW work to improve our tools.
Continue working like this, You will be never paid for this but it will maybe usefull for you to have references but do not forget that google is not the WWW headquaters!

Thomas 06/10/2009 18:50

Thank you for you very helpfull work. My company get hacked using this technique. The reason why you do not see malcious code on the websites is because they come to remove all their crap. I think
this is a way for them to avoid beeing detected and to allow them to come back later.
I made a post with details here : http://www.sqlservercentral.com/Forums/FindPost798664.aspx

SophosLabs 05/10/2009 07:11

Sophos would have detected this if HIPS was engaged and Alert Only was cleared. The .pdf file would have to buffer overflow Adobe Acrobat to execute, and HIPS will most likely catch it.

Failing that, it WILL catch the FakeAV variant when it modifies the registry Run, Service keys, or modifies any other processes in system32

Philippe Vialle 06/10/2009 00:26

I'm very pleased to see you guys at SophosLabs reading my blog! you know I value your work.
Nonetheless, as you guys know me, if I say "SAV up to date did not detect the PDF", it's because I had proof of it. ;)
To be more accurate, I was talking about SAV (Sophos AV) when it's being embedded on gateways. And in this case, SAV was the AV filtering layer of MTAs and proxies (perimeter defense).
So yeah, I was not talking about SAV on stations and servers... anyway. AFAIK, the Behaviour Genotype techcnology did not detect the malicious PDF. But I can tell it has detected a lot of other
0days and samples I had to deal with.
My problem in that particular case was that the perimeter defenses were breached. If the AV protecting stations and server was not fully up to date (signature, engine, and so on), the infection
could spread (well, I won't talk about updating Adobe's products on a large park...).
This is why I strongly recommend no to have the same AV engines on perimeter and in deep defenses.

I hope hearing from you soon guys. BTW, I have a new sample for you: the SWF file of the same attack, that SAV does not detect. I'll send it tonight to the Lab.