Overblog
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:
http://www.domaincrawler.com/domains/view/bannerdriven.ru
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:
http://bannert.ru/ad/index.php

Then, the victim is being redirected to:
-
http://bannert.ru/ad/js.php?id=1
- 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:
http://bannert.ru/ad/spl/files/8628468724.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:
http://www.domaincrawler.com/domains/view/bannert.ru


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:
http://www.virustotal.com/fr/analisis/f247397f83e61b5ef7e1b05343ea46bc6af8fe526f8fb0ec6e8ab61993082083-1254781195
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/ 
(see:
http://garwarner.blogspot.com/2009/10/cyber-security-awareness-month-day-one.html)
I'd like to congratulate the author for his great job.

Further on, we even have IIS logs as an evidence of what happened:
http://www.sqlservercentral.com/Forums/Topic793970-357-1.aspx
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:
http://txtb.in/4Wz


Then, if that helps, some guys published automated tools (scripts) to clean up compromised MS SQL databases:
http://blog.strictly-software.com/2008/09/latest-sql-injection-urls.html
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

Repost0
18 juillet 2009 6 18 /07 /juillet /2009 23:55
As my blog title says, I'm a security watcher. And obviously, I keep an eye on one of the very last full disclosure list: Bugtraq.

Recently, a post drew my attention. It was about AV scanning evasion, using PDF files. And one of the engines that was said to be vulnerable was: Kaspersky... 

But, what was surprising to me was both the tone of the author and the word "forced disclosure" at the top of the advisory.

I understood immediately that again, an independent security searcher had to fight against a vendor, to allow his discovery to be counter analysed (at least!), published if necessary, and then, lead to a patch or update release.

But Kaspersky did not seem to listen to him, and they did not even reply to his numerous emails.

Even when F-Secure sent the PoC to K Labs, and asked them to reply, still no answer.


So Thierry Zoller had to use one of the extreme sides of full disclosure: "forced disclosure". Thus, the vendor could not ignore anymore that alert, since it was publicly announced thnaks to Bugtraq (after they had been notified in due schedule).

And indeed, the day after the Bugtraq publication (to me, a kindda security information broadcast), K Labs promised him a reply with updates...!



Here is the whole story:
http://blog.zoller.lu/2009/05/advisory-kaspersky-generic-pdf-evasion.html


This is one of the reasons why I sincerely uphold the full disclosure idea.
Among other risks (e.g. 0days publications leading to exploitations), this is sometimes the only mean to get a reply from vendors, and then, hope to see a patch/update being created.

There is already another world of information security disclosure, which is silent and filtered. It leads to an underground economy (cf. Symantec report), where you can buy 0days and malwares (not detected by the AV you choose)...

This is again a reason why we need security search and full disclosure, to find and announce security holes, and then try counter-measures before there is a vendor solution (or during the deployment delay).

What if tomorrow, there is no more full disclosure at all? a remote 0day exploit being discovered in a virtualization solution could bring the chaos to a lot of infrastructures (sounds familiar hmmm?). With no information, no remediation (at first)... What if the vendor does not react quite quickly, and does not offer technical support needed?

In that world, we would all have to pay for the information security, else we could only watch what's going on, incident after incident, and see the victims count increasing...

Partager cet article

Repost0
13 mai 2009 3 13 /05 /mai /2009 01:59
Voici (encore) un petit exemple de ce qui pollue quotidiennement nos B.A.L... avec en prime une charge virale.
Il s'agit bien évidemment d'une contrefaçon d'une communication WesternUnion sur un transfert d'argent qui n'aurait pas abouti !

Commençons par ce qu'un utilisateur "standard" voit :
"Western Union Transfer MTCN: 3251452526"
On pourra noter que, bien qu'il soit rédigé en anglais ce qui va déjà exclure des victimes potentielles toute une population non anglophone, ce courriel est plutôt bien rédigé, sobre, sans faute qui saute aux yeux...

Bref, on dirait presque un vrai (malheureusement).
Les mauvaises langues diront que les traducteurs automatiques ont fait des progrès, peut être...


Puis, voici les entêtes de ce courriel :
(ce qu'un utilisateur non averti ne voit donc pas)


On se rend toute de suite compte que la vraie adresse émettrice n'est pas sur la zone DNS westernunion.fr (ou.com). C'est pourtant la vraie zone DNS pour le service de transfert d'argent international qu'est Western Union !

On pourrait donc parler d'une sorte d'usurpation d'identité, pourquoi pas.
Il s'agit en fait techniquement d'une utilisation détournée (et contraire aux bonnes pratiques) du champ "Data From", qui est en fait à valeur informative (et  dont le contenu est par conséquent arbitraire !).

En fait, la vraie adresse d'émission SMTP est la suivante : help@clickability.com

Cette adresse apparaît dans le champ "Envelope-From", que le MTA Exim a pris soin de conserver dans les entêtes du courriel. Ce champ est tronqué dans la capture que j'ai réalisé, car la ligne est trop longue :.
from [122.164.212.138] (helo=abts-tn-dynamic-138.212.164.122.airtelbroadband.in)    by smtp.%serveur%.%TLD% with esmtp (Exim 4.69)    (envelope-from <help@clickability.com>)    id 1M3qrQ-0005Ca-So; Tue, 12 May 2009 14:15:06 +0200


Petit rappel, ces 2 champs FROM sont spécifiés dans les RFC 2822 et 2821.
Seul le champ "Envelope From" est obligatoire dans la transaction SMTP permettant le transit du courriel entre serveurs SMTP.
Ce champ est fourni lorsque l'on initie une session SMTP, dont je vous donne un petit mémento basé sur une démo pratique : https://helpdesk.islandnet.com/pep/smtp.php


Revenons aux entêtes du courriel, afin d'un peu mieux cerner son transit.
Le serveur SMTP émetteur initial a pour adresse IP : 122.164.212.138
Une simple recherche Google montre immédiatement que cette adresse est en liste noire chez :
Lashback.com (www.unsubscore.com/blacklist.txt)

En poussant un cran plus loin, sur dnsbl.info par exemple, on s'aperçoit que d'autres listes "DSNBL" signalent cette adresse Ip (voir http://www.dnsbl.info/dnsbl-database-check.php). Dans le lot, on reconnait SpamCop (qui n'est pas des moindres) et Barracuda.

Concernant le nom FQDN du serveur SMTP de départ, on le retrouve sur divers sites Internet, notamment ici : http://rss.uribl.com/reports/14d/dns_mx.html
Rank      dns_mx                                    Total          Not Listed        Black
#168    server500.appriver.com:10    19              14    73.7%        2 10.5%

Et là où cela devient tout de suite très concret, c'est qu'on se rend compte que
ce serveur est utilisé en pointeur MX de la zone DNS scoot.co.uk !
Information confirmée ici : http://www.domaincrawler.com/domains/view/scoot.co.uk/

Mais ce n'est pas tout... s'agissant d'un pointeur vers une zone tierce, on pourrait supposer qu'il s'agit d'un service de messagerie (externalisée certainement...) utilisé aussi par d'autres sites Internet.
Et là bingo, merci Google (ou malheureusement, selon le point de vue) : une requête de ce type permet de trouver plus d'une centaine de domaines Internet dont l'un des pointeurs MX est le server500.appriver.com !
http://www.google.fr/search?q=site%3Adomaincrawler.com+server500.appriver.com&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:fr:unofficial&client=firefox-a

Il est certainement superflu de rappeler que les éléments détaillés dans cet article tendent à démontrer que ce service de messagerie appriver.com a été compromis au niveau sécurité !


Au sujet de la charge virale :

Le courriel contient une archive au format ZIP.
Voici une analyse virale multi-moteur du fichier EXE (nommé "MTCN_INVOICE.exe") que contient cette archive :
lien sur jotti.org.
On a donc affaire à un Zlob ! qui n'est d'ailleurs pas nouveau dans le monde VX.

Dommage d'ailleurs pour Barracuda qui implémente normalement ClamScan comme couche antivirale, le test sur Jotti.org révèle que Clam ne voit rien pour cette variante de Zlob.


Bref, il ne fait pas forcément bon faire du business avec scoot.co.uk, ni passer par le service de messagerie de Appriver.com !

Partager cet article

Repost0
23 novembre 2008 7 23 /11 /novembre /2008 18:13

Cette fois-ci je n'étais même pas en mode "grandes oreilles" quand une fenêtre intempestive a surgit sur mon bureau.

 

Précisons, la configuration est un Vista SP1, avec KIS 2009 et Pidgin pour la messagerie instantannée.

 

Voici à quoi ressemblait la fenêtre publicitaire (lien )

 

 

Un contact en mode "hors ligne" qui m'envoie un lien... étrange... (comme on dirait en anglais "sounds familiar, doesn't it?").

 

Le site en question demandait des identifiants MSN et ... les mots de passe pour se connecter à une partie à accès restreint...

 

Or le lendemain de l'affaire (23/11/08), si l'on va sur le site en question, voici ce qui apparaît :

 

Tiens donc, ces chers amis de SearchPortal... !

 

Cependant on dirait qu'il y a bien anguille sous roche puisque le domaine hopto.org est référencé comme malveillant, par exemple ici : http://www.malwaredomains.com/files/domains.txt  et parfois depuis 2005 ! (raison indiquée : "botnet")...

 

 

Affaire à suivre, j'espère avoir des captures d'écran du fameux site diffusé via MSN.

 

 

Mise à jour du 29/11/08 (20h50) :

 

Nouvelle campagne de diffusion via MSN (autre contact que précédemment). . Cette fois-ci le site est : http://tinyurl.com/578kt2

 

Voici une capture du message (lien externe) :

 

 

 

En fait, cette URL diffusée sur MSN redirige de manière transparente sur un autre domaine : http://8685858.getenjoyment.net

Il s'agit d'un site porno !  

 

Je ne ferai pas de capture d'écran ;)


Il est drôle de noter le contenu hébergé sur leur sous-domaine "www" : http://www.getenjoyment.net/
Ecrit en bon français...  S'agit-il réellement du début d'une encyclopédie technique sur Internet...?

Le lendemain, ce site n'est déjà plus accessible...
- Google Chrome renvoie sur http://host.atwebpages.com/web_hosting_needs.html
- Firefox, via OpenDNS, renvoie sur une page d'erreur : http://guide.opendns.com/?url=8685858.getenjoyment.net


A quand la suivante...

 

Partager cet article

Repost0
2 septembre 2008 2 02 /09 /septembre /2008 19:24
Suite à mes précédents messages concernant des alertes virales générées par le traffic réseau de T.O.R, j'ai décidé de regrouper ici les URL signalées par Kaspersky 2009.

J'ose espérer que cela servira à d'autres personnes, peut-être même des éditeurs...


- http://root.51113.com/root.gif : Troj-Dwnlder.Win32.Murlo.nn

- http://esearchall.com : Troj-Dwnlder.JS.IFrame.JL,
Attention, ce site semble revenir assez souvent.

- http://foto-e-mia.info/beta.com : Win32.Runner.x

- http://avwav.com/2359.htm : packed.JS.Agent.i

 - http://xzjmjd.cn/book : Troj-Dwnlder.JS.IFrame.a

- http://xsenhalol.xpg.com.br  Backdoor.php.PBot.a

- http://gzkangyuan.com/gb/ok.asp            ?


09/09/08
- http://surftillyoudrop.org/index.php?REQ=womens+health  : Troj-downloader.JS.Frame.jl

- http://oa81.com/fksave.asp  :  Trojan-Clicker.HTML.IFrame.kr

- ...


------
Détections heuristiques :

http://89.188.16.29/database : Trojan.Generic




Je posterai d'autres URL au fur et à mesure.

Partager cet article

Repost0
29 juillet 2008 2 29 /07 /juillet /2008 00:27

Je m'intéresse au système TOR depuis quelques temps déjà.
Non seulement par curiosité, mais aussi pour les risques qu'il peut amener au sein d'un SI avec des données sensibles et/ou des systèmes de filtrage de navigation...

Ne recherchant pas l'état de l'art pour TOR, j'ai simplement récupéré Vidalia, une mini-suite logicielle incluant le nécessaire pour faire fonctionner un client/serveur TOR, avec web proxy local. Le tout dans une interface assez simple et francisée !

J'ai donc laissé tourner la bête de nuit, pour observer ses stats le lendemain (l'outil de génération de stats est fourni aussi avec Vidalia...).

Cependant, il m'a semblé entendre quelques bruits étranges durant la nuit. Et au petit matin, j'ai pu apercevoir des messages d'alerte de Kaspersky sur mon PC...
Mince alors ! on aurait tenté de m'infecter de nuit, en traître, et alors que je ne faisais rien de spécial sur le PC ?




En fait, après quelques vérifications, la réponse est non...
Je n'ai jamais visité les URL que KAV m'indique dans le rapport (cf. capture ci-dessus).

Explication ?
J'ai laissé tourner Vidalia, mais cette fois-ci en étant devant le PC.
Et par chance, j'ai pu voir une alerte en temps réel. L'information qui me manquait était fournie par KAV lorsqu'il hurle pour signaler un objet dangereux :
- > le nom du résident accédant au fichier infecté est : tor.exe !!

Ainsi, K.I.S 2009 est capable d'analyser le flux véhiculé au sein du réseau TOR et transitant par le "noeud" que mon PC constitue... (infos de version : Kaspersky Internet Security 2008, v8.0.0.357).

De là à dire que TOR sert à propager des codes viraux et/ou à dissimuler des transferts de codes viraux, il n'y a qu'un petit pas...


Devrait-on généraliser des scanners antivirus sur http pour assainir le réseau TOR ? la question peut se poser...


Dans tous les cas, je pense qu'il est déjà important d'avoir à l'esprit que le fait de participer au réseau TOR (dès qu'on a installé tor, devenant un "routeur" TOR), la machine peut faire transiter des codes viraux, de façon complètement transparente...

Moi qui croyais assez peu aux scanners AV analysant les flux type HTTP en local, je dois dire que K Labs a développé une technologie qui me semble pertinente, dans le contexte viral actuel. C'est d'ailleurs pour ça que j'ai K.I.S 2009 , "en test"...




Partager cet article

Repost0