Le bloc d’adresses IP de l’ex-opérateur ConnectCom (AS34596), 193.238.36.0/22, a été réattribué le 29 juin à l’opérateur ukrainien ImperialNet. Ce même opérateur s’était déjà vu précédemment attribuer le bloc 195.149.108.0/24.

ConnectCom est une entité tristement connue pour sa proximité avec le fameux opérateur russe Russian Business Network, hébergeur pare-balles qui fournissait des services d’hébergement de sites frauduleux entre 2005 et 2007 : RBN s’était en effet illustré pour ses activités de pédo-pornographie, de spam, de phishing, de diffusion de malware, etc ; à tel point qu’en deux ans d’existence, aucun site web légitime n’avait jamais pu être repéré sur ses plages d’adresses. A la suite de sa disparition d’Internet, certaines de ses classes avaient été réattribuées à l’opérateur américain ThePlanet.

Tout est bien qui finit bien ? Pas exactement : si le recyclage de ces classes est une bonne chose en soi, en revanche ce qui pose problème est le fait que pendant des années, de nombreux professionnels de la sécurité, nous y compris, ont -à juste titre- appelé les administrateurs de réseaux à mettre sur liste noire tout le trafic en provenance de RBN, de manière préventive, afin de supprimer en amont tout risque de spam ou d’infection en provenance de ces classes d’adresses IP. Conséquence indirecte, aujourd’hui ces blocs d’adresse IP continuent d’avoir « mauvaise réputation », et d’être associés dans les moteurs de recherche à divers rapports d’activité malveillante (lien). Pire, ces blocs se retrouvent parfois dans des listes de filtrage d’IP (lien), des produits de filtrage d’URL ou des outils de détection d’intrusion, comme par exemple les règles Emerging Threats pour Snort (lien).

La conséquence directe est que les sociétés exploitant ces adresses IP voient leurs communications externes perturbées, leurs e-mails sortants rejetés par certains produits anti-spam, et les sites web qu’elles hébergent rendus inaccessibles par des pare-feux applicatifs se basant sur le contrôle de l’adresse IP de destination. Un cauchemar pour tout administrateur réseau. La mésaventure est d’ailleurs arrivée à une société française d'hébergement en février, la société étant d’office mise sur liste noire par la plupart des réseaux avec lesquels elle tentait de communiquer.

Et le problème se répétera lorsque les plages IP de McColo (lien) ou d’Intercage / Atrivo (lien) seront réattribuées. Si les mécanismes de filtrage d’adresse IP semblent aujourd’hui bien rôdés, et si les administrateurs de listes noires n’hésitent désormais plus à recommander le filtrage de blocs d’adresses entiers associés à des activités malveillantes, en revanche la question de la sortie de ces IP des listes noires reste un problème entier. De plus, la réattribution de classes d’adresses IP, par exemple après une faillite de société ou une migration technique, représente un risque en termes de fuites d’informations : la nouvelle organisation administrant le bloc d’adresses pourrait théoriquement se voir adresser des flux réseaux confidentiels (e-mails ou autre), destinés à l’ancien détenteur du bloc.

Merci à "Bad Rabbit" de nous avoir signalé la migration du bloc ConnectCom.

Denial of service encouragement messages have been published on various websites since roughly a week. These messages target Iranian governmental websites; see, for instance, this blog post that was published on June 21st on Twitter.

This call to action was relayed through hundreds of Twitter user accounts (link, link, link). The choice of this specific social networking platform was indeed good, as hundreds of Twitter users read and copied the message on their own feeds; moreover, the call to action was incidentally published on dozens of news websites covering the events in Iran, as these websites automatically syndicate "twits" using search keywords related to Iran. The message could therefore be read directly next to press articles, giving the call to action a comfortable visibility in a short timeframe [link].

The tool enabling this attack was named "Page Reboot". It consists of a PHP script that opens on a single page dozens of redirect frames pointing at Iranian websites, being refreshed at a chosen rate. At the beginning of their attack, the hacktivists were using the PageReboot.com web service ; then they wrote their own script for an easier deployment on several web servers of their choice (such as WhereIsMyVote.info which is now offline). This way, the attackers could migrate the script whenever they want, so as to keep the attack up and running. An example of this is the website http://91.199.0.11/ that was hosted in France; this website was pre-configured to attack the following targets:

• http://www.Presstv.ir
• http://www.Leader.ir
• http://www.Kayhannews.ir
• http://www.farsnews.com
• http://www.farsnews.ir
• http://www.Irib.ir
• http://www.Irna.ir
• http://www.mfa.gov.ir/cms/cms/Tehran/fa/index.html
• http://www.Moi.ir
• http://www.Police.ir
• http://www.Justice.ir
• http://www.live.irib.ir
• http://www.iribnews.ir

This tool was set up by an individual identified under the nickname "Zampf". He also published on his Twitter feed technical details about the IT technologies deployed on the targeted Iranian governmental websites.

Dancho Danchev's weblog [link] also presents other rudimentary DoS tools that could be downloaded by cyber-activists. These tools are executable files, which target similar websites. What seems different about this attack from previous "nationwide" DDoS attacks (in Estonia and Georgia for example) is the lower level of technical skills of the attackers: until now, no botnets seems to have been involved in this attack. As a result, the efficiency of the attack is unclear, as some targets appear undisturbed, others being slightly slowed down, and a few of them being taken completely offline.

Interestingly enough, this campaign seems to have started on IRC channels, such as #iran, #iranelection, #hackers, #iran09, #mousavi, #basij, #GR88, #neda (named after the woman who was shot to death, and whose agony was filmed on a cellphone and quickly spread all over the world). Far from being perfectly coordinated, this movement also has its detractors, which can also be read on Twitter: some people are calling to stop the DDoS attack, for various reasons -- one of them being that it would be more efficient to surgical-hack those government websites [link].

Anyway, these attacks clearly illustrate political activist campaigns on the Internet, and the ease even for unstructured activist groups to quickly develop technical tools in order to get itself heard.

Depuis près d'une semaine fleurissent en différents points de la Toile des messages d'encouragement au déni de service contre des sites web iraniens ; en témoigne par exemple ce billet publié le 21 juin sur Twitter.

Cet appel à déni de service a été relayé par plusieurs centaines de profils Twitter (lien, lien, lien). Le choix de ce média par les hacktivistes était particulièrement opportun puisque des centaines d'usagers de Twitter ont relayé le message ; le message a également été diffusé indirectement sur des dizaines de sites d'actualité qui syndiquent automatiquement les "twits" à l'aide de mots-clefs liés à l'Iran, apparaissant ainsi en marge d'articles de fond sur la situation politique du pays. Cet appel au déni de service a obtenu une visibilité confortable en très peu de temps [lien].

L'outil incriminé, baptisé "Page Reboot", est un script PHP qui ouvre sur une même page plusieurs frames à destination des sites iraniens ciblés, ces frames étant rafraichies à un intervalle paramétrable. Les activistes semblaient utiliser en premier lieu le site web PageReboot.com, puis ont conçu leur propre script PHP pour un déploiement plus simple sur de nombreux sites de leur choix, comme WhereIsMyVote.info (maintenant hors ligne), assurant ainsi la persistance de l'attaque. Ainsi, le site http://91.199.0.11/ hébergé en France permettait jusqu'à aujourd'hui d'attaquer les cibles de son choix -- les cibles suivantes étant prédéfinies dans l'outil :

• http://www.Presstv.ir
• http://www.Leader.ir
• http://www.Kayhannews.ir
• http://www.farsnews.com
• http://www.farsnews.ir
• http://www.Irib.ir
• http://www.Irna.ir
• http://www.mfa.gov.ir/cms/cms/Tehran/fa/index.html
• http://www.Moi.ir
• http://www.Police.ir
• http://www.Justice.ir
• http://www.live.irib.ir
• http://www.iribnews.ir

L'outil a été mis en place par un individu identifié sous le pseudonyme Zampf, qui publie également sur son espace Twitter des détails techniques sur les technologies utilisées par les sites gouvernementaux iraniens.

Le billet blog de Dancho Danchev [lien] présente également d'autres outils pouvant être téléchargés par les activistes sour la forme d'exécutables, réalisant un déni de service sur des cibles similaires. On remarque en particulier le caractère rudimentaire de tous ces outils, assez éloignés de ceux ayant été mis en oeuvre dans les dénis de service ayant affecté l'Estonie et la Géorgie : dans le cas de l'Iran, jusqu'ici aucun botnet ne semble avoir été utilisé. Le résultat de l'attaque est d'ailleurs plutôt mitigé, certains sites restant parfaitement accessibles, d'autres accusant un temps de latence important, et enfin quelques uns affichant un message d'erreur.

De manière assez intéressante, cette campagne a débuté sur IRC, les messages mentionnés faisant référence à des canaux tels que #iran, #iranelection, #hackers, #iran09, #mousavi, #basij, #GR88, #neda (du nom de la jeune femme blessée par balle pendant une manifestation, et dont l'agonie, filmée sur un téléphone portable, a fait le tour du monde). Loin d'être parfaitement coordonnée, cette campagne connait ses contre-courants, également sur Twitter : des internautes appellent à cesser le DDoS sous différents prétextes, notamment celui qu'il serait préférable de pirater de manière ciblée les sites gouvernementaux [lien].

Quoi qu'il en soit, ces attaques illustrent assez précisément les mouvements d'opinion sur Internet, et la rapidité avec laquelle un mouvement non structuré parvient à mettre en place des outils pour se faire entendre.

This is the terrible conclusion after this three-day symposium: unfortunately, it's over ... This year, we're not going to make a report summarizing the various conferences, many blogs already do it, sometimes even in live.

It was an opportunity to reconnect with old colleagues and friends, meet new people, and assist once more to really exciting conferences. The subjects were very varied, ranging from abuse of BIOS features to implement a backdoor, to a talk on the real value of ISO 27001, through the now traditional legal intervention of Marie Barel, the failure of security in companies by Nicolas Ruff, or a reflection on the human being as a strong piece in the security. Although some subjects did not seem very exciting, the authors have often succeeded in generating interest for their work.

This year, our colleague Florent Marceau presented his work on automated malware analysis:

His approach implements a modified QEmu virtual machine to follow malicious code and the data it manipulates (Data tainting), in order to recover in clear-text ciphered bankers configuration files. Technical details of the implementation are available in the related paper.

The conference also provided an opportunity for Raphaël Rigo and Simon Marechal to present the resolution of the reverse-engineering challenge organized by Stéphane Duverger. The prizes were distributed to the winners, Florent won an iPod Touch, and I enjoyed a wonderful toothbrush that belonged to the creator of the challenge:

Rump sessions were more numerous than ever this year, with 23 interventions of 4 minutes each. As usual, the subjects covered were varied. I enjoyed the rump of Jean-Baptiste Bédrune who has discovered a weakness in the algorithm to generate WPA/WPA2 keys used in two french ISP "boxes". Special mention for the EthyloSSTIC rump, with a USB breathalyzer and its application which controls alcohol level prior to login on a system

Last but not least, the Social Event, which is the opportunity to meet and interact with participants and speakers, has been a real success. Organized this year in Coq Gadby, it brings together all participants in a large and pleasant place.

I now have to thank the whole Organizing Committee for the 7th edition of SSTIC, waiting impatiently for the 2010 opus.

C'est le terrible constat au bout de ces trois jours de symposium : malheureusement, c'est déjà fini ... Cette année, nous n'allons pas nous lancer dans un compte-rendu résumant les différentes conférences, de nombreux blogs le faisant déjà, parfois même en direct.

Cette édition a été l'occasion de retrouver d'anciens collègues et amis, de rencontrer de nouvelles têtes, et d'assister une fois de plus à des conférences vraiment passionnantes. Les sujets étaient très variés, allant du détournement de fonctionnalités du BIOS afin d'implémenter une porte dérobée, à un talk sur la véritable utilité de l'ISO 27001, en passant par la désormais traditionnelle intervention juridique de Marie Barel, le constat d'échec de la sécurité en entreprise de Nicolas Ruff, ou encore une réflexion sur l'Humain en tant que maillon fort de la sécurité. Même si certains sujets ne me paraissaient pas passionnants, les auteurs ont la plupart du temps su susciter l'intérêt du public pour leurs travaux.

Cette année, notre collègue Florent Marceau présentait ses travaux sur l'analyse automatisée de logiciels malveillants :

Son approche met en oeuvre une machine virtuelle QEmu modifiée pour suivre du code malveillant et les données qu'il manipule (technique du Data Tainting), dans le but de récupérer en clair des fichiers de configuration chiffrés de malware bancaires. Des détails techniques de l'implémentation sont disponibles dans l'article associé à la conférence.

La conférence a aussi été l'occasion pour Raphaël Rigo et Simon Marechal de présenter la résolution du challenge de reverse ingénieux organisé par Stéphane Duverger. Les lots ont pu être remis aux vainqueurs, Florent est donc reparti avec un iPod Touch, et j'ai eu droit à une splendide brosse à dent ayant appartenu au créateur du challenge :

Les rumps sessions ont été plus nombreuses que jamais cette année, avec 23 interventions de 4 minutes chacune. Comme d'habitude, les sujets traités étaient variés. J'ai beaucoup apprécié la rump de Jean-Baptiste Bédrune ayant découvert une faiblesse dans l'algorithme de génération des clés WPA/WPA2 de deux "box" de FAI français. Mention spéciale pour la rump EthyloSSTIC, présentant un éthylomètre USB et son application directe : le contrôle d'alcoolémie avant le login sur un système

Dernière pierre de cet édifice, le Social Event, qui est l'occasion de rencontrer et d'échanger avec les participants et orateurs, a été une véritable réussite. Organisé cette année au Coq Gadby, il a cette fois-ci réunit l'ensemble des participants dans un lieu spacieux et agréable.

Il ne me reste qu'à remercier l'ensemble du comité d'organisation pour cette 7e édition du SSTIC, en attendant avec impatience le cru 2010.

Among viruses that have made the headlines since the beginning of the year, we can find a new variant of Virut/Virux/Scribble. This is a polymorphic PE file (.exe and .scr) infector, connecting to an IRC server waiting for commands. This latest version also infects HTML, PHP and ASP files on the system with an iframe pointing to a malicious page trying to exploit known vulnerabilities in Internet Explorer and Adobe Reader/Acrobat. Since analysis of the old and new versions have already been done, let's concentrate on the efficiency of some removal tools against this threat.

Such tools are quite useful during incident response missions. They make it available to scan a system without installing software on the system, and in some cases may detect viruses that were not spotted by the corporate antivirus.

In this post, we are going to work on a particular sample of Virut, which is currently detected by almost every AV vendor:

However, the few removal tools we tested were disappointing. Some of them didn't detect anything, some detected the virus in memory but not the infected files, and some detected the infected files but were not able to disinfect them. One of the tools requires that the system be rebooted in Safe Mode, which may not be feasible, especially if servers are infected. One of the tools even have a default mode which deletes infected files instead of disinfecting them, which is quite a funny behaviour when dealing with a PE infector...

These results are a bit surprising considering that, as shown above, antivirus products from the same vendors detected the sample correctly.

Dr.Web's CureIt! is the tool that worked best on our sample. It didn't detect the virus in memory, but detected the infected file and disinfected it:

The file was given back its original size of 70 656 bytes. Now, let's check that the file has correctly been disinfected. Here are the main modifications induced by the infection:

• a marker was added in the Reserved field of the MZ header, to prevent reinfection

• in the PE header, SizeOfImage was increased and Checksum zeroed

• the .rsrc section was enlarged and its characteristics were modified to allow writing and execution, needed for in place depacking

• the payload was added at the end of the file in the .rsrc section, from offset 0x11400 to 0x15dff (virtual addresses 0x1014000 to 0x10189ff)

Only 4 bytes of code were modified at offset 0x68e5 (virtual address 0x10074e5):

They correspond to the overwrite of a call to GetStartupInfoA by a jump to 0x1014369:

This virtual address corresponds to the offset 0x11769 in the file and points in the middle of the payload.

Now, let's have a look at how Dr.Web disinfected our file. It deleted the payload from offset 0x11400 and patches 5 bytes:

• 1 byte to decrease the size of the .rsrc section from 0xda00 to 0x9000 (RawSize field)
• 4 bytes from offset 0x68e5 to replace the jump to the payload by the original call to GetStartupInfoA

We can therefore conclude that our sample has successfully been disinfected (beware that this is only a specific case, several infection methods can be used by the virus). However, the tool was not able to detect the malicious iframe in HTML, PHP and ASP pages, which may be a real problem if a web server has been infected.

Parmi les virus ayant marqué le début d'année, on trouve une nouvelle variante de Virut/Virux/Scribble. Il s'agit d'un infecteur de PE (dans ce cas précis .exe et .scr) polymorphe se connectant à un serveur IRC afin de recevoir ses commandes. Cette dernière variante infecte aussi les fichiers HTML, PHP et ASP présents sur la machine afin d'y ajouter une iframe. Celle-ci pointe vers une page hébergée sur un domaine malveillant tentant d'exploiter des vulnérabilités connues dans Internet Explorer et Adobe Reader/Acrobat. Des analyses de l'ancienne et de la nouvelle version ayant déjà été faites, nous allons nous concentrer sur l'efficacité de quelques removal tools face à cette menace.

De tels outils sont utiles lors des missions de réponse à incident. Ils permettent de mener un scan sans installer de programme sur le système et dans certains cas, détecter des virus qui n'auraient pas été repérés par l'antivirus de l'entreprise.

Dans le cas présent, nous allons travailler sur un échantillon de la nouvelle variante de Virut, aujourd'hui détectée par quasiment tous les éditeurs :

Pourtant, les removal tools des différents éditeurs antivirus se sont révélés décevants. Certains ne détectent rien du tout, d'autres l'instance du virus en mémoire mais pas les fichiers infectés, d'autres encore détectent les fichiers infectés mais sont incapables de les désinfecter. Un des outils nécessite aussi un redémarrage en mode sans échec, ce qui peut se révéler problématique sur le terrain, en particulier si des serveurs sont infectés. La palme revient à un outil dont le mode de fonctionnement par défaut supprime les fichiers infectés au lieu de les nettoyer, ce qui est un comportement pour le moins cocasse quand on veut faire face à un infecteur de PE... Ces résultats sont d'autant plus étonnants que, comme montré sur la capture précédente, les antivirus de ces mêmes éditeurs détectent correctement l'échantillon.

CureIt! de Dr.Web est l'outil qui s'en sort le mieux sur l'échantillon soumis. Il ne détecte pas l'instance en mémoire mais il détecte bien que le fichier est infecté, puis il le nettoie :

Après nettoyage, le fichier a repris sa taille d'origine de 70 656 octets. Vérifions maintenant si le fichier a été correctement désinfecté. Pour cela, commençons par observer les principales modifications induites par l'infection :

• ajout d'un marqueur dans le champ Reserved de l'en-tête MZ, afin d'éviter la surinfection

• dans l'en-tête PE, agrandissement du champ SizeOfImage et annulation du Checksum

• agrandissement de la section .rsrc et modification de ses caractéristiques pour permettre la modification et l'exécution, indispensable pour le dépacking sur place

• ajout de la charge virale en fin de fichier dans la section .rsrc à partir de l'offset 0x11400 jusqu'à 0x15dff (adresses virtuelles de 0x1014000 à 0x10189ff)

Côté code, seuls 4 octets sont modifiés à l'offset 0x68e5 (adresse virtuelle 0x10074e5) :

Ils correspondent à l'écrasement d'un appel à GetStartupInfoA par un saut vers 0x1014369 :

Cette adresse virtuelle correspond à l'offset 0x11769 dans le fichier et pointe donc au milieu de la charge virale.

Observons maintenant la désinfection du fichier réalisée par Dr.Web. En plus de supprimer la charge virale à partir de l'octet 0x11400, l'outil patche 5 octets :

• 1 octet pour diminuer la taille de la section .rsrc de 0xda00 en 0x9000 (champ RawSize)
• 4 octets à partir de l'offset 0x68e5 pour remplacer le saut vers la charge virale en l'appel original vers GetStartupInfoA

On peut donc conclure que l'outil a correctement désinfecté cet échantillon (attention au fait qu'il ne s'agit que d'un cas particulier, plusieurs méthodes d'infection pouvant être utilisées par le virus). En revanche, l'outil ne détecte pas les iframes malveillantes dans les pages HTML, PHP et ASP, ce qui peut demeurer problématique si un serveur web a été infecté.