Un nouveau kit d’exploitation de vulnérabilités a été découvert, et serait utilisé dans la nature pour des attaques massives. Il s’agit d’un kit nommé SPack. Ce kit est commercialisé depuis avril 2009 pour un montant de $250, et vient rejoindre la longue lignée des kits d’exploitation IcePack, FirePack, MPack et autre.

Pour ceux qui ne connaîtraient pas ce type d’outils, il s’agit d’une plateforme web intégrée d’exploitation de failles. Cette plateforme s’installe sur un serveur web, et chaque fois qu’un visiteur s’y connecte, elle identifie la configuration de sa machine et exécute un code d’exploitation spécifique issu de sa base de données. Lorsque l’exploitation est réussie, la victime se voit infectée par un cocktail de malware, adware et faux logiciels anti-virus.

Ce kit possède la particularité d’implémenter des contre-mesures pour empêcher Google de détecter le code malicieux et ainsi apparaître comme un site « sain » dans les résultats du moteur de recherche. Les codes d’exploitation hébergés sont polymorphes, de sorte qu’à chaque tentative d’exploitation, le code malicieux prend une apparence différente pour tromper les anti-virus ; de plus, pour chaque adresse IP consultant une page infectée, la tentative d’infection n’a lieu qu’une seule fois, et les fois suivantes, une erreur 404 est retournée au client. Les mises à jour du logiciel présentent de nouveaux codes d’exploitation et fonctionnalités, et chaque pirate ayant acheté le logiciel se voit attribué une réduction de 75% du prix pour chaque mise à jour. Ironiquement, le logiciel présente une licence d’utilisation, limitant son acheteur à un usage mono-site (installation sur un seul domaine), ainsi qu’un mécanisme d’auto-destruction lorsqu’il détecte que l’utilisateur a installé une copie pirate de la plateforme.

Ces plateformes sont depuis deux ans responsables de la majorité des infections virales sur Internet. Des sites « affiliés » (ou piratés) présentent sur leurs pages une redirection invisible vers ces plateformes, à l’aide d’une balise « iframe ». Leur faible coût, divisé par dix en deux ans, les rend accessibles à tout pirate débutant, et elles sont désormais devenues des briques essentielles de la cybercriminalité.

L’auteur de cette plateforme, H1t3m, n’est pas un inconnu, puisqu’il s’agit de l’administrateur du forum « R00t y0u », forum qui s’est montré particulièrement actif sur la scène underground depuis quelques temps, ses membres se partageant quotidiennement les « bons tuyaux » et dernières failles de sécurité découvertes dans des sites de e-commerce. H1t3m est également l’auteur du tristement célèbre kit ZeuEsta, qui est un package tout-en-un contenant à la fois le malware ZeuS (a.k.a Zbot, PRG, Ntos, …) et une plateforme d’infection automatique. Tous ces kits sont d’ailleurs en vente sur le site de e-commerce du pirate…

Those who had the chance to get a 4 day long week-end will face a difficult comeback with an impressive number of patches to apply. Indeed, besides being the French national day, the 14th of July has been the opportunity for several vendors to publish security bulletins and patches.

First and foremost, Microsoft and its famous "Patch Tuesday" where 6 bulletins have been published, among which 3 are rated critical by Microsoft. They have fixed 9 vulnerabilities, two of which being actively exploited. The first one is CVE-2009-1537 (Ref Lexsi 11760), published at the end of May and exploited since the beginning of June. It is a vulnerability in DirectShow allowing the execution of arbitrary code via a specially formed QuickTime file. It has been fixed by the MS09-028 patch. The second one is CVE-2008-0015 (Ref Lexsi 11939) (we notice that the vulnerability was reported in 2008), a buffer overflow in the MPEG2TuneRequest object of the msvidctl.dll ActiveX control allowing arbitrary code execution via a specially crafted web page. The vulnerability has been exploited since the 6th July. SANS ISC maintains an infected domain list. The MS09-032 patch fixes this vulnerability. Those two patches should be applied immediately.

Unfortunately for Microsoft, a new 0-day vulnerability (Ref Lexsi 11968) has been published the day before the monthly release of their patches, affecting an ActiveX control used by Office Web Components, a component installed by default with some Microsoft Office suite versions (XP and 2003 notably) and allowing arbitrary code execution via a specially formed Office file or a malicious web page. There is only a workaround at the moment, using the now classic "kill-bits" to prevent the vulnerable ActiveX from being launched, which is strongly recommended since more and more exploitations of the vulnerability have been recorded.

One may think it's not a good time for those who use Microsoft's browser. It wouldn't be totally wrong, but that is without taking into account the 0-day vulnerability (Ref Lexsi 11975) affecting Mozilla Firefox 3.5 and for which an exploitation code has been released on the 13th. It is located in the Just-In-Time Javascript engine used by the latest version of the browser, released only two weeks ago. This proves the popularity of this alternative browser, which gains interest of security researchers... benevolent or not. The only solution at the moment is to manually disable the JIT engine by setting the "javascript.options.jit.content" variable to "false" (note : a patch has been issued today).

It was also the Oracle patch day, which happens quaterly. No less than 29 vulnerabilities (Ref Lexsi 11970) have been fixed, some of which are exploitable remotely and without authentication (CVE-2009-1019 and CVE-2009-1977).

Finally, vulnerabilities (Ref Lexsi 11977) have been found in the ISC reference code for several DHCP clients, as well as in the w3c XML signature specification (Ref Lexsi 11982), affecting several vendors and Linux distributions.

Between 0-day (where fortunately workarounds exists) and massive exploitations of fixed but recent flaws, patch application turns out to be essential, whether it is by automatic updates for home users or via a suited patch deployment solution for companies.

Une série de sites gouvernementaux américains et sud-coréens ont quasi-simultanément été ciblés par une attaque de déni de service lors du week-end du 4 juillet. Cette attaque massive visait à les rendre inaccessibles ; et de fait, les sites des départements du Trésor, des Transports, de la Commission fédérale des Echanges (FTC), du Secret Service et de plusieurs autres départements fédéraux étaient inaccessibles pendant une partie du week-end. D’autres sites non gouvernementaux étaient également visés, tels que le Nasdaq, le New York Stock Exchange (NYSE), le Washington Post, Voice of America, ou encore le site d’enchères US Auctions Live.

En Corée du Sud, des cibles similaires ont été attaquées, telles que les sites de la Présidence sud-coréenne, des ministères de la Défense et des Affaires Etrangères, et de l’Assemblée Nationale.

Cette attaque semble avoir été perpétrée à l’aide d’un cheval de Troie de type « MyDoom » modifié pour l’occasion, la souche originale étant tristement connue depuis des années pour avoir infecté des centaines de milliers de machines sur Internet. Le malware se propage par spam, chaque machine nouvellement infectée envoyant massivement des messages contenant le code du cheval de Troie ; cependant, nous pensons que l'infection initiale a pu avoir lieu par "drive-by-download", par infection de sites web légitimes. Les machines contaminées sont automatiquement enrôlées dans l’attaque. Jusqu'à 200.000 machines infectées (source) auraient pris part à cette attaque, totalisant une bande passante de 20 à 40 gigabits/seconde au plus fort de l’attaque. Le cheval de Troie était également conçu pour masquer son identité en se faisant passer pour différents navigateurs Web, de manière à compliquer le travail de filtrage des administrateurs des sites ciblés. Enfin, le malware comportait une fonction "suicide" : le 10 juillet à minuit précise, il était programmé pour effacer un certain nombre de fichiers systèmes Windows de manière à rendre inutilisable la machine contaminée (source).

L’hypothèse d’une attaque par la Corée du Nord a été évoquée. La piste coréenne provient de la forme des requêtes générées par le cheval de Troie : dans le bombardement de requêtes qu’il assène à ses cibles, les données envoyées contiennent un en-tête bien spécifique : « Accept-Language: ko » (les initiales "ko" signifiant "korean", ou "coréen"). Il s’agit d’un en-tête HTTP insérée par le client, qui permet de spécifier la langue dans laquelle le navigateur attend une réponse, certains sites web en profitant donc pour personnaliser le contenu en fonction de la langue parlée par les internautes. Autre élément qui étaye la piste coréenne : les spams envoyés par le cheval de Troie contiennent l'en-tête : « .charset="euc-kr" », indiquant un encodage coréen des caractères du message. Ces deux en-têtes semblent indiquer une conception coréenne du cheval de Troie.

Cependant, la localisation des serveurs de contrôle du malware brouille les pistes. La société vietnamienne AhnLab est parvenue à localiser un serveur de contrôle au Royaume-Uni ; de plus, le malware tente de contacter plusieurs autres machines de contrôle en Autriche, aux Etats-Unis et en Allemagne, en leur soumettant une mystérieuse requête HTTP « GET /china/dns? ».

Ainsi, nous voilà bien peu avancés : origine coréenne, chinoise, ou autre ? Corée du Nord ou du Sud ? Même si une origine de l’attaque en Corée du Sud semble peu probable – connaissant les liens qui unissent la Corée du Sud aux Etats-Unis, et compte tenu du fait que des sites du pays ont été également pris pour cible – ce serait l’alibi parfait, quoique plutôt usé : « regardez, moi aussi j’ai été attaqué, donc ça ne peut pas être moi ». C’est notamment l’alibi qu’avait utilisé la Chine en 2007 lorsque le monde entier l’avait pointée du doigt pour ses tentatives d’intrusion de réseaux sensibles.

Origine gouvernementale ou cybercriminelle ? Connaître la nature du commanditaire changerait beaucoup de choses, et renseignerait sur les motivations réelles de l’attaquant. Les déclarations au lendemain de l’attaque des officiels US et sud-coréens doivent être comprises pour ce qu’elles sont : rien d’autre que des déclarations officielles, sans valeur technique puisque l’enquête n’a pas encore abouti. Les accusations portées à mi-mot contre un commanditaire gouvernemental nord-coréen sont donc purement gratuites jusqu’ici, et relèvent davantage de la propagande et de la recherche d’un effet psychologique. Il a été dit ça et là que les attaques étaient trop sophistiquées pour avoir été commises par de simples hackers : c’est tout le contraire ! A ce jour, les cybercriminels sont bien plus matures que la plupart des gouvernements sur les attaques informatiques. En témoignent par exemple les attaques massives récurrentes qui frappent différents endroits de la Toile de manière bien plus sophistiquée que le déni de service du 4 juillet ; ou encore les déclarations délirantes d’un colonel de l’US Air Force en mai 2008 (l’US Air Force passant pourtant pour héberger l’une des meilleures unités américaines en matière de guerre informatique) qui voulait créer un botnet au sein même des réseaux informatiques de l’Air Force, à partir de machines de récupération. Soulignons également que tous les éléments dont on dispose à l’heure actuelle et qui alimentent l’analyse géographique sont aisément falsifiables par l’auteur de l’attaque, qui chercherait justement à faire porter le chapeau à la Corée du Nord. Enfin, ajoutons que si l’attaque émanait bien de Corée du Nord, cela constituerait une rupture dans sa politique étrangère, orientée sur le racket de la communauté internationale par l’intimidation et la démonstration de force, plutôt que par l'agression directe, bien plus risquée.

Donc à moins d’une revendication, comme ce fut le cas pour l’attaque menée contre les réseaux géorgiens, ou d’éléments de preuve saisis sur les serveurs de contrôle du malware et démontrant formellement l’implication d’une puissance étatique, nous restons ici dans la guerre de l’information...

Ceux qui ont eu la chance d'avoir un week-end prolongé vont connaitre un retour difficile avec un nombre impressionnant de correctifs à appliquer. En effet, le 14 juillet, en plus d'être la fête nationale française, a été l'occasion pour de nombreux éditeurs de sortir des bulletins et des correctifs de sécurité.

En tête de file, Microsoft et son fameux “Patch Tuesday” où 6 bulletins ont été publiés, dont 3 jugés critiques par Microsoft. Ils corrigent 9 vulnérabilités dont deux sont activement exploitées. La première est la vulnérabilité CVE-2009-1537 (Ref Lexsi 11760), publiée fin mai et exploitée activement depuis début juin. Il s'agit d'une vulnérabilité dans DirectShow permettant l'exécution de code arbitraire via un fichier QuickTime spécialement formé. Elle est corrigée par le patch MS09-028. La deuxième est la vulnérabilité CVE-2008-0015 (Ref Lexsi 11939) (on constate au passage que la vulnérabilité a été signalée à Microsoft en 2008), un débordement de tampon dans l'objet MPEG2TuneRequest du contrôle ActiveX msvidctl.dll permettant l'exécution de code arbitraire via une page web spécialement formée. La vulnérabilité est exploitée depuis le 6 juillet. L'ISC maintient d'ailleurs une liste de domaines infectés. Le patch MS09-032 corrige cette vulnérabilité. Ces deux correctifs sont donc à appliquer sans attendre.

Malheureusement pour Microsoft, une nouvelle vulnérabilité 0-day (Ref Lexsi 11968) a été publiée la veille de la sortie de ses correctifs, impactant cette fois un contrôle ActiveX utilisé par Office Web Components, un composant installé par défaut dans certaines versions de la suite Microsoft Office (XP et 2003 notamment) et permettant l'exécution de code arbitraire via un fichier Office spécialement formé ou une page web malveillante. Pour l'instant il n'y a qu'une solution de contournement par l'application des désormais classiques « kill-bits », permettant d'interdire l'instanciation de l'ActiveX vulnérable, ce qui est fortement recommandé puisque de plus en plus d'exploitations de la vulnérabilité sont constatées.

On pourrait dire qu'il ne fait pas bon utiliser le navigateur de Microsoft ces temps-ci. Ce n'est pas complètement faux, mais c'est sans compter sur la vulnérabilité 0-day (Ref Lexsi 11975) concernant Mozilla Firefox 3.5 dont un code d'exploitation a été publié le 13. Elle se situe dans le moteur Javascript Just-In-Time présent dans la dernière version du navigateur, sortie il y a à peine 2 semaines. Cela montre bien la bonne visibilité du navigateur alternatif, qui attire l'attention des chercheurs en sécurité... bienveillants ou non. La seule solution pour le moment reste de désactiver manuellement celui-ci en positionnant la variable de configuration « javascript.options.jit.content » à « false ».

Il s'agissait également du patch day pour Oracle, dont le cycle de sortie est trimestriel. Pas moins de 29 vulnérabilités (Ref Lexsi 11970) ont été corrigées, dont certaines critiques car accessibles à distance et sans authentification (CVE-2009-1019 et CVE-2009-1977).

Pour clore la fête, des vulnérabilités ont été trouvées dans le code de référence du client DHCP (Ref Lexsi 11977) publié par l'ISC ainsi que dans la spécification des signatures XML (Ref Lexsi 11982) du w3c, impactant plusieurs éditeurs et distributions Linux.

Entre les failles 0-day (où heureusement des solutions de contournement existent) et les exploitations massives de failles corrigées mais récentes, l'application des correctifs s'avère indispensable, que ce soit par les mises à jour automatiques chez le particulier ou via une solution adaptée de déploiement des patchs en entreprise.

A 0-day vulnerability was publicly announced yesterday (Ref. Lexsi 11939), in a Microsoft DirectX DirectShow ActiveX control. It can be instantiated in the browser, and by passing specially crafted parameters, a buffer overflow can occur. You know what happens next: shellcode execution, malware downloading, information theft...

The impacted control has a CLSID of {0955AC62-BF2E-4CBA-A2B9-A63F772D46CF}, you just have to set a traditional "kill-bit" to forbid its instantiation to avoid exploitation.

This is not the first time an unpatched vulnerability is exploited in the wild to distribute trojans and other malicious worms.
However, the bulletin issued by Microsoft today is a bit surprising. The CVE identifier affected to this vulnerability is CVE-2008-0015. You said 2008, didn't you? The vulnerability seems to have been discovered in late 2007 by the ISS X-Force team, and certainly reported to Microsoft soon after. We have good reason to wonder why there has been no fix -or at least a workaround to block the vulnerable ActiveX, as Microsoft regularly do with its "Update Rollup for ActiveX Kill Bits"- for almost one year and a half ...
What had to happen happened, and researchers with less noble intentions have discovered the vulnerability on their own side.

About the mitigations, Snort rules have been released against the exploitation code used in the wild, as well as a list of domains known to host the exploitation code, maintained by the ISC.

Une vulnérabilité 0-day a été publiquement annoncée hier (Réf. Lexsi 11939), concernant un contrôle ActiveX de Microsoft DirectX DirectShow. Celui-ci peut être instancié dans le navigateur, et en lui passant certains paramètres spécialement formés, un débordement de tampon se produit. Vous connaissez la suite : exécution d'un shellcode, téléchargement d'un malware, vol d'informations en tout genres...

Le contrôle impacté a pour CLSID {0955AC62-BF2E-4CBA-A2B9-A63F772D46CF}, il suffit donc de positionner un traditionnel "kill-bit" pour interdire son instanciation afin d'éviter toute exploitation.

Ce n'est pas la première fois qu'une vulnérabilité non corrigée est exploitée dans la nature pour distribuer chevaux de troie et autres vers malveillants.
Toutefois, la lecture du bulletin publié par Microsoft aujourd'hui laisse songeur. L'identifiant CVE affecté à la vulnérabilité est le CVE-2008-0015. Vous avez dit 2008 ? La vulnérabilité semble en effet avoir été découverte fin 2007 par l'équipe ISS X-Force, et certainement remontée à Microsoft peu après. On est en droit de se demander ce qui justifie l'absence de correction -ou de solution de contournement par blocage du contrôle ActiveX vulnérable, comme Microsoft le fait maintenant régulièrement par le biais de ses "Update Rollup for ActiveX Kill Bits"- depuis près d'un an et demi ...
Ce qui devait arriver arriva, et des chercheurs aux intentions moins nobles ont découvert la vulnérabilité de leur côté.

Du côté des protections, on note l'apparition de règles Snort contre le code d'exploitation actuellement utilisé, ainsi qu'une liste des domaines connus pour héberger le code d'exploitation maintenue par l'ISC.

The IP address block from ex-hosting company ConnectCom (AS34596), 193.238.36.0/22, has been transferred to Ukrainian operator ImperialNet on 29th June. The IP address block 195.149.108.0/24 was previously attributed to this operator.

ConnectCom is an entity which until recently was well-known for its proximity with the infamous Russian Business Network. From 2005 to late 2007, this bulletproof hosting provider used to host activities such as child porn, phishing scams, malware propagation websites, etc. In a two years’ lifespan, no single legitimate website could ever be spotted on RBN’s IP ranges, which is quite remarkable. Following its disappearance from the Internet, some of its IP ranges had been transferred to the US hosting company ThePlanet.

So, all's well that ends well! Unfortunately, there’s a bit more to this story: the recycling of freed IP space is a good principle; however, it may pose a threat to the new owners of these IP blocks. We security professionals have for years recommended network administrators to blacklist and null-route IP blocks belonging to RBN to prevent its malicious activity from spreading. As a consequence, these blocks still have today a “bad reputation”, and are associated to hundreds of fraud reports in search engines (link). Worse yet, these netblocks may still be listed by IP blacklists (link), URL-filtering products, or even intrusion detection system rules such as the “Emerging Threats” Snort ruleset (link).

As a result, the new legitimate owners of these netblocks may experience network communication failures, because their outgoing e-mails could be filtered out by their recipients’ networks, and their websites may not be accessed due to HTTP firewalls blocking outgoing traffic to bad IP blocks. This is not a pure theoretical case: in February, a /24 block of RBN's former IP ranges was assigned to a small French hosting company that was therefore immediately blacklisted by most of the networks that still relied on old IDS rules.

This story will repeat itself as soon as McColo and Intercage / Atrivo’s IP ranges are reassigned to other customers. IP blacklisting mechanisms now seem up to date and reactive enough, so network administrators do not hesitate anymore to block entire IP ranges; but the problem remains with the de-listing process. Moreover, the reassignment of an IP range formerly belonging to a bankrupt company, or following a network-wide migration, may lead to a data breach. The new owner of the netblock might indeed receive sensitive network traffic (such as e-mails) originally sent to the block’s previous owner.

Many thanks to “Bad Rabbit” for bringing the ConnectCom’s netblock migration to our attention.