As everybody has said and repeated, on April, 1st 2009, the latest variant of the Conficker worm will begin to generate domain names to try to connect to and retrieve a potentially malicious payload.

We saw that the new update mechanism is now based on the generation of 50000 domain names per day, among which 500 will be contacted to try to download an update. Statistically, this corresponds to updating 1% of the infected machines by registering a unique domain name. Would the authors be willing to reduce their botnet to 1% of its size?

Not at all! The obfuscated functions in the worm are used by an impressive Peer-to-peer communication mechanism, allowing Conficker to communicate with its peers to propagate an update. The small percentage of machines that have downloaded an update through the domain names could communicate it to all other machines in (relative) discretion.

This mechanism, previously studied by the SRI, is based on several threads managing communications with other peers, including two threads dealing with UDP communications and two threads for TCP communications. Observation of UDP packets sent through the Internet gives the impression of a pair of randomly generated IP and port, and it would be interesting to find a link between the address and the port, in order to have an effective detection of the P2P traffic of the worm.

Once we have traced the different threads, we always encounter the same function to generate the different ports, based on the IP address of the infected machine and a parameter that we will determine later.

This large cryptographic-looking block is present twice in the function. The first block only takes into account the host's IP address (in the eax register on the previous screenshot), and generate a first pair of TCP / UDP ports in esi and esi+4. They only depends on the IP address. Before entering the second block, we note that the register eax is xored by the first argument of our generation function.

The second block is nearly identical to the first, and results in the generation of a new pair of TCP / UDP ports in esi+8 and esi+C.

The argument passed to our function is the result of the function called just before. Studying it shows that its result is in edx in the following screenshot:

eax contains the timestamp of the current date. We note that the value 0x54600 is subtracted from our timestamp, which is the number of seconds in 4 days. The timestamp is then multiplied by 0x6EF5DE4D then edx is shifted by 12 bits to the right. These two operations are in fact a compiler optimisation to perform a division by the value 604800, which corresponds to the number of seconds in a week. Our parameter is identified, it is the number of weeks since the 1st January 1970!

Now that this information is available, it is possible to create a tool taking an IP address and a date as parameters to determine pairs of TCP and UDP ports used by the peer-to-peer mechanism at that date and for this address.

lexsi:~/conficker$ ./conficker_ports 192.168.111.2 05 02 2009
Used UDP ports : 45804 / 35543
Used TCP ports : 17116 / 62114

lexsi:~/conficker$ nmap 192.168.111.2 -P0 -p 1-65535
Interesting ports on 192.168.111.2:
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
17116/tcp open  unknown
62114/tcp open  unknown

This enables us to determine if unidentified traffic is due to Conficker or not, ensuring that the IP address and port are in accordance with the algorithm. Better yet, it is possible to scan the network, looking for TCP ports opened by the worm, which be very wise one day before the beginning of Conficker's update!

Note that publishers of rogue security software begin to use the buzz around conficker to distribute false removal products.

Tout le monde l'a dit et répété, le 1er Avril 2009, la dernière variante en date du ver Conficker va commencer à générer des noms de domaine pour tenter de s'y connecter et rapatrier une potentielle charge malveillante.

Nous l'avons vu, le nouveau mécanisme de mise à jour repose désormais sur la génération de 50000 noms de domaine par jour, parmi lesquels 500 seront contactés afin d'essayer de télécharger une mise à jour. Statistiquement, cela correspond à la mise à jour d'1% des machines infectées en enregistrant un unique nom de domaine. Les auteurs seraient-ils décidés à réduire leur botnet à 1% de son étendue ?

Que nenni ! Les fonctions obfusquées présentes dans le corps du ver sont celles d'un redoutable mécanisme de communication Peer-to-peer, permettant à Conficker de communiquer avec ses pairs afin de propager une mise à jour. Le faible pourcentage de machines ayant téléchargé une mise à jour par le biais des noms de domaine pourrait ainsi communiquer celle-ci à l'ensemble des autres machines en toute (relative) discrétion.

Ce mécanisme, déjà étudié par le SRI, repose sur plusieurs threads gérant les communications avec les autres pairs, parmi lesquels deux threads s'occupant des communications UDP, et 2 threads pour les communications TCP. Une observation des paquets UDP envoyés donne l'impression d'une génération aléatoire du couple IP/port, et il serait intéressant d'établir un lien entre l'adresse et le port, afin d'avoir un moyen de détecter le trafic P2P du ver.

Une fois que l'on a tracé un peu l'exécution des différents threads, on retombe sur une même fonction chargée de générer les différents ports en fonction de l'adresse IP de la machine infectée et d'un paramètre que nous déterminerons par la suite.

Ce long bloc aux allures cryptographiques est présent deux fois dans la fonction. Le premier bloc ne prend en paramètre que l'adresse IP de la machine (dans le registre eax sur la capture précédente), et génère un premier couple de ports TCP/UDP dans esi et esi+4. Ceux-ci ne dépendent donc que de l'adresse IP. Avant l'entrée dans le second bloc, on note que le registre eax est xoré par le premier argument de notre fonction de génération.

Le second bloc est quasiment identique au premier, et résulte en la génération d'un nouveau couple de ports TCP/UDP dans esi+8 et esi+C.

L'argument passé à notre fonction est le résultat de la fonction appelée juste avant. L'étude de celle-ci nous montre que son résultat correspond à edx dans la capture suivante :

eax contient alors le timestamp de la date actuelle. On note que la valeur 0x54600 est retranchée à notre timestamp, ce qui correspond en secondes à 4 jours. Le timestamp est ensuite multiplié par 0x6EF5DE4D puis edx subit un décalage de ses bits de 12 vers la droite. Ces deux opérations combinées correspondent à une optimisation du compilateur pour effectuer une division par la valeur 604800, qui correspond elle-même au nombre de secondes dans une semaine. Notre paramètre est donc identifié, il s'agit du numéro de semaine depuis le 1er Janvier 1970 !

Une fois ces informations connues, il est possible de créer un outil prenant en paramètre une adresse IP et une date afin de déterminer les couples de ports TCP et UDP utilisés par le mécanisme peer-to-peer à cette date et pour cette adresse.

lexsi:~/conficker$ ./conficker_ports 192.168.111.2 05 02 2009
Used UDP ports : 45804 / 35543
Used TCP ports : 17116 / 62114

lexsi:~/conficker$ nmap 192.168.111.2 -P0 -p 1-65535
Interesting ports on 192.168.111.2:
PORT      STATE SERVICE
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
445/tcp   open  microsoft-ds
17116/tcp open  unknown
62114/tcp open  unknown

Il nous est ainsi possible de déterminer si du trafic non identifié est imputable à Conficker ou non, en vérifiant que l'adresse IP destination et le port correspondant sont conformes à l'algorithme. Mieux encore, il est possible de scanner le réseau à la recherche des ports TCP ouverts par le ver, ce qui, à la veille des tentatives de mise à jour de Conficker, serait fort judicieux !

Notons que les éditeurs de rogue-antivirus commencent à utiliser le buzz autour de conficker pour distribuer de faux produits de désinfection.

Le 24 mars dernier s'est tenu le 3e Forum International sur la Cybercriminalité (FIC) organisé par la Gendarmerie Nationale à Lille.
Lors de la précédente édition à Marcq en Bareuil, le lieu s'était révélé un peu étroit au vu l'intérêt grandissant traduit par un grand nombre de visiteurs. Le FIC a donc été organisé cette année au Zénith de Lille. Cet espace permettait en effet de circuler facilement entre le hall principal, où étaient disposés quelques stands de sociétés de sécurité informatique, de veille, et de lutte contre la cybercriminalité, et les différentes salles de conférences.

Un millier de personnes étaient présentes tout au long de la journée sur le salon et aux conférences. Un tel évènement est d'ailleurs avant tout l'occasion pour beaucoup de renouer le contact avec des collègues de travail habituellement distants et ainsi faire du "social networking".

Déjà présente l'an dernier la Ministre de l'Intérieur Michèle Alliot-Marie a rappelé tout le travail effectué ces dernières années et les dispositions envisagées pour la lutte contre la cybercriminalité.Le Ministre belge de la Justice -visible sur la droite de la photo- était également présent, signe de l'importance des ces problématiques pour les gouvernements des deux pays.



Les intervenants étaient de qualité, mais le programme des conférences se révélait peut être un peu trop riche. Évoquer autant de sujets et chercher à couvrir l'intégralité des problématiques soulevées par la cybercriminalité en une seule journée s'apparente à une mission impossible. Les participants semblent également privilégier une séparation plus claire entre des conférences techniques, et des conférences plus théoriques.

J'ai pour ma part assisté à 2 conférences que j'attendais en particulier :

• N'Tech : les outils informatiques développés par les enquêteurs
  

Cette conférence était modérée par Nicolas Duvinage (Gendarmerie Nationale), les intervenants étant Serge Houtain et Christophe Monniez de la RCCU belge, Mme le procureur Lidija Komlen Nicolic de la République Serbe, Guy Voncken, David Cassel, et Laurent Lesobre.
Nous nous attendions à quelques démonstrations de logiciels, ou au moins à des précisions techniques sur certains outils. Mais cette conférence s'est déroulée sous forme de questions/réponses entre le modérateur et les intervenants. Guy Voncken a évoqué son logiciel open source "Guymager" d'acquisition de données/copies de disque dur, tandis que Christophe Monniez a présenté sa célèbre distribution Live CD "FCCU Live Boot". Finalement, le seul produit présenté par les N-tech a été "Marina", un logiciel destiné à la recherche et à la collecte d'images pédophiles sur disque dur. Ce dernier logiciel, non public et réservé aux forces de l'ordre françaises mais aussi internationales, fonctionne par comparaison de hash MD5 de sa base de donnée avec les fichiers du disque dur du suspect.

En termes de méthodologies d'enquête, le guide "Cybercriminalité : Réflexes et bonnes pratiques" a été longuement évoqué. Il s'agit d'un livre de 250 pages résultat du travail collaboratif entre la RCCU de Tournai et la Gendarmerie Nationale, destiné à aider les enquêteurs judiciaires lors des premières investigations et du recueil de plaintes. Une volonté de partage d'informations et de communication s'établit de plus en plus entre différents services judiciaires à l'international.
Reste à espérer que d'autres initiatives du même type se créent à l'avenir.

• Outils de veille : Recherche, traitement, exploitation des informations en toute sécurité
  

Cette conférence s'est révélée très décevante, de par son caractère très généraliste. Les notions de web visible et invisible, les faiblesses des moteurs de recherche, les nécessités de mise en place de systèmes de veille en entreprise et d'exploitation des informations ont été évoquées. Les intervenants ont malheureusement survolé le sujet, parfois même en fournissant des informations erronées (telles que: "les CAPTCHAs ne sont pas vulnérables"). Le public averti n'a pas manqué de relever ces incohérences en fin de présentation.



Le FIC demeure néanmoins un évènement annuel indispensable, de par sa dynamique fédératrice et sa volonté de faire évoluer les législations et pratiques en matière de lutte contre la cybercriminalité.
Nous tenons particulièrement à remercier Le Lt Col Régis Fohrer ainsi que l'Adjudant Chef David Cassel pour l'organisation de cet évènement, et à saluer tous nos amis que nous avons toujours le plaisir de rencontrer lors de cette réunion.

Poursuivons nos aventures "Confickeresques" avec une technique bien connue, quoiqu'assez peu utilisée par les malware : la désactivation du mode sans échec de Windows.

La configuration du mode sans échec se réalise via la clé HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot (aucun rapport avec la solution de chiffrement de disque...). Cette clé liste les pilotes et services minimaux à charger en mode standard (sous-clé Minimal) ou avec support réseau (sous-clé Network) :

Pour rendre impossible le démarrage en mode sans échec (accessible via la touche F8 au démarrage du système), le ver n'y va pas par quatre chemins : il supprime purement et simplement la clé SafeBoot avec la fonction SHDeleteKey :

Au prochain redémarrage, si l'utilisateur appuie sur F8, l'option du mode sans échec lui sera toujours proposée mais échouera en STOP: 0x0000007B indiquant dans ce cas une erreur lors de la lecture de la base de registre :

Pour remédier à cela, la solution la plus simple consiste à exporter la clé SafeBoot depuis une ruche SYSTEM saine (la sauvegarde effectuée à l'installation dans C:\Windows\repair ou celle issue d'un autre poste sain par exemple), puis à l'importer sur le poste après l'avoir désinfecté.

Remarque : si le poste n'a pas été redémarré depuis l'infection, la clé SafeBoot la plus récente a été enregistrée lors du démarrage dans le ControlSet correspondant à la "dernière bonne configuration connue" (Last Known Good).

En Biologie, utiliser un vaccin consiste à inoculer une version rendue inoffensive d'un agent infectieux, de sorte qu'au moment de l'infection réelle, le corps soit déjà prêt à réagir de manière efficace et ne tombe ainsi pas malade. Nous allons appliquer ce principe au virus, cette fois-ci informatique, Conficker.C et à ses mutexes. Après avoir précédemment montré qu'il était possible de désinfecter un système sans autre outil qu'un simple script VBS, nous allons ainsi présenter une méthode pour bloquer les effets néfastes du ver sur un système pourtant non patché, sans antivirus, et ayant les partages administratifs activés.

Pour observer les mutexes créés par Conficker.C, nous allons utiliser notre plugin winobj.py pour le framework Volatility. Dans une sandbox, dumpons la RAM, exécutons le ver, et dumpons la RAM à nouveau. Winobj.py nous permet de parcourir l'Object Manager de Windows, et en particulier les objets de type Mutant (équivalent des mutexes au niveau noyau) présents dans \BaseNamedObjects :

$ ./volatility winobj -f ramdump_avant -d \\BaseNamedObjects -o Mutant > mutex_avant
$ ./volatility winobj -f ramdump_apres -d \\BaseNamedObjects -o Mutant > mutex_apres

Observons les différences :

$ diff mutex_avant mutex_apres
11a11
>     \BaseNamedObjects\612924626-99\ Mutant 80d1c658
18a18
>     \BaseNamedObjects\612924626-7\ Mutant 80d7d6a8
19a20
>     \BaseNamedObjects\lmgdvhkzvzqxej\ Mutant 80d52390
21a23
>     \BaseNamedObjects\xafjljtmlfuwo\ Mutant 80d06700

Conficker.C crée donc 4 mutexes :

• deux mutexes ne contenant que des lettres
• deux mutexes de la forme chiffres-99 et chiffres-7 respectivement

Analysons maintenant la logique du ver pour mieux comprendre le rôle de ces mutexes. Le nom des deux premiers est généré à partir du PID courant récupéré via GetCurrentProcessId ; inutile donc de creuser dans cette voie, ces mutexes ne peuvent pas nous être utiles :

En observant la suite du déroulement de l'exécution, on remarque la présence d'un ExitProcess situé peu après la création du mutex 612924626-99 (NB : le mutex 612924626-7 est créé juste avant) ; cette fois-ci, il s'agit probablement d'une bonne piste :

Juste après la demande de création de ce mutex, la fonction RtlGetLastWin32Error est appelée pour récupérer le code d'erreur, stocké dans une variable. Un peu plus bas, cette variable est comparée à 0xb7, correspondant au code d'erreur ERROR_ALREADY_EXISTS. En cas d'égalité (en clair si le mutex existe déjà), le ver se termine immédiatement :

Reste maintenant à comprendre comment le nom du mutex est généré. Un peu plus haut dans le code, il récupère le nom de la machine avec la fonction GetComputerName :

La fonction sub_929fae est tout de suite appelée. A partir du nom de la machine, et après un certain nombre d'opérations arithmétiques simples dans deux boucles imbriquées, elle génère un entier :

Le ver utilise ensuite cet entier (dans notre cas 612924626) afin de générer les noms des mutexes via snprintf (NB : les suffixes -7 et -99 sont constants). Cet algorithme s'implémente en quelques lignes de C.

Au final, nous pouvons donc créer un petit exécutable qui va récupérer le nom de la machine, en déduire la valeur de l'entier, puis créer le mutex de la forme chiffres-99. Il peut par exemple être placé dans une clé Run pour assurer son exécution à chaque démarrage du système.

Une fois le système "vacciné" de la sorte, l'exécution de Conficker.C n'aura aucun impact néfaste sur le système.

Comme vu dans le précédent billet, le MSRT ne détecte pas la variante C du ver Conficker. Existe-t-il une solution simple pour détecter et éradiquer la menace, sans disposer d'autre outil qu'un interprète VBScript (pas d'antivirus, pas de removal tool, etc) ? La réponse est oui.

Comme les variantes précédentes, Conficker.C crée une nouvelle clé dans HKLM\SYSTEM\CurrentControlSet\Services. Or, il la crée avec des permissions très restrictives : seul SYSTEM y a accès (il s'agit ici du service wcsSrv) :

Il s'agit d'une protection rendant un peu moins facile la suppression du ver. Pour la contourner, il suffirait d'éditer les ACLs de la clé à la main ou d'utiliser un outil en ligne de commande comme subinacl.

De fait, cette "protection" a pour effet de rendre facile la détection du ver puisqu'il suffit d'énumérer les clés de Services jusqu'à tomber sur une dont la lecture retourne une erreur...

On sait aussi que ce service malveillant est en réalité un sous-service de Svchost, dont le lancement est effectué par un ajout dans la liste HKLM\SOFTWARE\Microsoft\Windows NT\Svchost\netsvcs :

Pour les variantes A et B, l'ajout du sous-service malveillant s'effectuait toujours en fin de liste ; ce n'est plus le cas pour Conficker.C mais il suffit de parcourir cette valeur et d'en supprimer les entrées précédemment identifiées lors du parcours de Services.

Attention : cette simple manipulation va simplement empêcher le chargement de la DLL malveillante au prochain redémarrage du système. Ce n'est PAS suffisant pour revenir dans l'état pré-infection. En particulier, le fichier .dll est toujours présent sur le disque, l'entrée dans Services est toujours présente et les effets de bord du ver (désactivation du service Windows Update, tâches planifiées, etc) ne sont pas traités. Sans oublier que le ver peut toujours réinfecter la machine si tous les vecteurs de propagation n'ont pas été supprimés.

La réponse des créateurs de Conficker suite à l'action coordonnée de Microsoft et de nombreux acteurs internationaux de la sécurité s'est faite attendre, mais a finalement vu le jour sous la forme d'une nouvelle variante : Conficker.C.

Les auteurs ne pouvaient en effet laisser à l'abandon leur fantastique botnet, privé de tout mécanisme de mise à jour, les domaines utilisés par les variantes A et B ayant été pré-enregistrés. Une variante B++ avait vu le jour fin Février, afin d'ajouter un mécanisme de mise à jour "peer-to-peer", lors de la tentative d'exploitation de la vulnérabilité MS08-067 par l'un de ses congénères.

Début mars a vu la naissance de la variante C, implémentant les mécanismes suivants pour se rendre encore plus coriace :

• Terminaison des programmes contenant l'une des chaînes suivantes dans leur nom de fichier :

• Le ver vérifie maintenant la date du jour en envoyant des requêtes aléatoires vers l'un des noms de domaines suivants codés en dur :

• Génération de 50000 noms de domaines par jour, au lieu des 250 pour les variantes A et B. Parmi ces 50000, 500 sont choisis pour être utilisés. Et contrairement aux anciennes versions, chacun d'entre eux n'est testé qu'une fois dans la journée, à intervalle aléatoire pour plus de furtivité
• Pour chacun des 500 noms de domaines utilisés, le ver vérifie que ceux-ci ne sont pas résolus vers une adresse locale (10.x.x.x, 172.16-31.x.x, 192.168.x.x), ni vers une adresse appartenant aux plages d'adresses IP que possèdent les acteurs ayant contribué à l'action coordonnée de Microsoft.
• De nouvelles fonctions particulièrement obfusquées ont fait leur apparition dans le code du ver, et celles-ci sont toujours en cours d'étude

Que faut-il retenir de cette nouvelle menace ?

• Il ne sera plus possible de rediriger les noms de domaine vers une adresse interne pour identifier les machines infectées
• Le pré-enregistrement de 50000 domaines par jour va devenir problématique, et on peut s'attendre à voir apparaître les premières payloads téléchargées par Conficker dans les jours à venir (la tentative de mise à jour ne commencera que le 1er Avril 2009)
• L'application du MSRT nécessitera de renommer celui-ci afin qu'il ne soit pas bêtement terminé par le ver avant d'avoir pu effectuer son nettoyage. A noter qu'à l'heure actuelle, le MSRT ne détecte pas cette nouvelle variante

Trois bulletins ont été publiés ce mois-ci par Microsoft. Un bulletin est qualifié de critique :

MS09-006 : trois vulnérabilités dans le noyau de Windows, dont une permettant l'exécution de code arbitraire à distance lors de la visualisation d'une image EMF ou WMF malicieuse (effectivement, depuis NT 4.0, la GDI s'exécute en mode noyau). Les deux autres permettent l'élévation locale de privilèges (Réf Lexsi 11410).

Les bulletins suivants sont qualifiés d'importants :

MS09-007 : une vulnérabilité dans SChannel, pouvant permettre l'usurpation d'identité (Réf Lexsi 11411).

MS09-008 : quatre vulnérabilités dans les serveurs WINS et DNS, pouvant permettre l'usurpation d'identité (Réf Lexsi 11412).

Côté MSRT, c'est Koobface qui passe à la trappe. Il s'agit d'un ver se propageant via les réseaux sociaux comme Facebook.com ou MySpace.com : lors de l'infection, il va chercher les cookies correspondant à ces domaines et tenter de récupérer la liste des contacts. La propagation se fait alors via l'envoi de messages ou l'ajout de commentaires contenant un lien vers un copie du ver sous la forme d'une fausse mise à jour ou codec.

The Council of Europe hosted this week its 4th annual Octopus Conference against Cybercrime in Strasbourg. Nearly 300 experts, government and law enforcement officers from 70 countries gathered to exchange views, advices and good practices to help mitigate the growing threat of cybercrime.
Council of Europe has been deeply involved in this battle for years. It managed to reach a broad consensus to implement the only international legally-binding text on these issues: the Convention on Cybercrime (also called the Budapest Convention) that was established in 2001 and entered into force in 2004. It has been ratified by 24 countries today, the last one being Germany. One of the biggest achievement of this convention is to reduce the legal loopholes that use cybercriminals to escape arrest and prosecution.

The second phase of an ambitious Project on Cybercrime running until mid-2011, has been announced during the Conference. The Council of Europe received so far funding from Romania, Microsoft and McAfee for example. But it noted that more resources will be needed in the near future.

The program of this event was indeed very dense, with nearly 70 distinct presentations. Even if this conference was restricted to public and private individuals working on this field, some of the presentations and a draft summary are available to the public on the Octopus website.

Oktapodi is one example of a friendly, harmless Octopus.


But the Deputy Secretary General of the Council rather compared these smart animals to cybercriminals :

Ladies and Gentlemen, according to marine biologists, the common octopus, or octopus vulgaris, can distinguish the brightness, size, shape, and horizontal or vertical orientation of objects. It is intelligent enough to learn how to unscrew a jar and is known to raid lobster traps. The kind of octopuses that operate in the murky waters of cybercrime are common criminals, so they are both vulgar and vulgaris. They are also intelligent, but they raid more than simply lobster traps. They prey on our children, they attack our communication systems, our vital infrastructure, they represent a threat to our economy, to our security. This is why we need to be smarter and faster than they are. This is why we are here today.

Here are the key points that have been discussed to try to address this situation:

Money laundering

The need to "follow the money" (and difficulties to do so for law enforcement) have been reassessed and initiatives in this area have been presented (for example in Ireland and South Africa). FATF also encouraged countries to apply their recommendations on the topic. Examples of mobile payments, prepaid phone cards, online gaming or virtual worlds money laundering issues have been presented.
A new definition of Financial Institutions was promoted, to help reduce the problem of the jurisdiction-free online payment systems such as WebMoney.

Reporting cyber crimes

A closed session was dedicated to present the process in place for the national G8/Council of Europe Points of Contact cybercrime units. Cyber crimes are vastly under-reported and causes and solutions to improve this fact were discussed. Europol mentioned that a platform to report cyber crimes would be opened for the public early next year.
The Child porn issue seems to reach the broadest consensus, but also the most advanced initiatives and tools (Child Exploitation Tracking System, i-DASH, INHOPE, etc.).
APWG invited the assistance to adopt an universal format to share information on cyber crimes through the XML protocol.

Public Private Partnerships

This topic has indeed been one of the key issues raised, particularly by Microsoft. It expressed views that contacts between law enforcement and private companies (particularly to the financial sector and ISP community) should be facilitated. The example of the MAAWG or London Action Plan on the spam issue was provided.
This event is indeed an unique occasion for participants to establish partnerships of all kind either person-to-person or in more "public" fashion (Microsoft and 2CENTRE, AFF Coalition, etc.).

Social Networks

Everybody agreed that social networks introduce new risks and opportunities of exploitation for cybercriminals. Their massive adoption and recurrent lack of security measures in these online communities represent big challenges for the anti-cybercrime community.
VOIP

The (il)legality of VOIP protocols was the subject of a strong stance by a company called Bitek. The presenter advised the audience to enforce regulation at the national telecom authority level to ban P2P protocols (and use their software to do so).

Cloud computing

A workshop discussed the way cloud computing will bring new challenges in the near future. One of the presenter urged law enforcement agencies to use documented case of such jurisdiction problems to illustrate the need for regulation. (It is funny to notice that the AV industry tries to fight the threat of cloud computing with more... cloud computing).

Legal issues

A lot of countries expressed their interest in joining the CoE Convention and presented the next steps of their application process.
The ISP industry expressed its difficulty to comply with the various laws related to cyber crimes. A need for clarification is needed, as conflicts sometimes occur between data retention and privacy rights (particularly with transnational cloud computing). But disharmonious laws could also hinder the fight against cybercrime. A broad "Internet Regulation" was lobbyed by the Internet Governance Forum, and Kaspersky for example.
Growing collision between cyber crimes and real-life crimes was also mentioned. The examples of debit cards provided by Entropia and linked to accounts from virtual worlds or the www.liveshot.com ("remote hunting") experiment show the challenges ahead (for the regulator and the law enforcement agents).

International cooperation

This was the other big topic covered by the conference. Guidelines from the European Commission in 2008 represent the best recommendations to date to establish such partnerships. The whole audience also agreed that the process of Mutual Legal Assistance agreements need to be fasten. Joint Investigation Teams (between French or US and Romanian investigators and prosecutors) are and will continue to be set up.


Personal comments :

I really enjoyed Eugene Kaspersky's presentations. He first warned the audience to distinguish terrorism using Internet as a communication mean to cyber-attacks conducted by terrorists through online networks (such as utilities). He also predicted that only professional cybercriminals would survive in the mid-term, as a "war" between cybercriminals starts (I recalled such "competition" by the recent Tigger/Syzor trojan, that removes 20 other malware families installed on the infected host).
He also express the possibility that these criminals could collect massive amount of money that could enable them to lobby against Internet Regulation.
But on my side, I see territorial sovereignty and national interests more likely to resist international regulation of Internet. I thus noted that a few countries expressed fears about ingerence from foreign states in cybercrime investigations.

Recent example on banking secrecy

The example of the recent crackdown on banking secrecy shows that political and media pressure may be more efficient than legislation in some cases. Indeed the G-20 threatens to set up a blacklist of tax heavens in order to push these countries to relax their banking secrecy laws. This list might be set up at the next April 2nd meeting. Switzerland, Austria, Luxemburg, Liechstenstein, Monaco, etc. already announced easing international cooperation and transfer of information on fears to be included on the list.

Don't forget the CERTs !

I finally wanted to reassess that CERTs and CSIRTS' community represent an important "on-the-ground" stakeholder dealing daily with cybercrime incidents. The CSIRT community is a rather solid information exchange hub. As such I regret they had this time so little involvment in these discussions.

"Voilà, c'est fini..." disait la chanson de Jean-Louis Aubert. Aujourd'hui marque en effet la date limite de remise des offres de candidature à la gestion de l'extension de domaines ".fr".
L'examen des dossiers devrait prendre 3 mois et la décision (confiée au Ministre de l'économie) pourrait donc être annoncée avant l'été.

Par ailleurs, les règles et procédures d'enregistrement actuelles évolueront à partir du 30 mars prochain.
Les modifications portent notamment sur:

• l'augmentation de la durée de rédemption d'un domaine arrivé à échéance (de 7 à 30 jours)
• le raccourcissement des délais de transfert de domaine (de 42 à 21 jours)
• l'impossibilité de déposer à l'avenir certains domaines de second niveau (.prd.fr, .nom.fr, etc.)

L'implémentation d'une zone DNS en bonne et due forme (via le fameux ZoneCheck) n'est par ailleurs plus indispensable pour qu'un domaine soit déposé/transféré (entre 2 titulaires ou 2 bureaux d'enregistrement), car cette étape peut se faire désormais a posteriori.

Le framework Volatility permet d'analyser un dump de mémoire vive et contient déjà un certain nombre de plugins pour Windows (liste des processus, DLLs, connexions réseau, etc). Pour présenter les possibilités de cet outil, nous allons prendre l'exemple simple de la réalisation d'un clone de l'outil WinObj de Sysinternals permettant de parcourir l'Object Manager.

NB : l'Object Manager est le composant de Windows chargé de la création, du maintien et de la suppresion des objets manipulés par le système. Ces objets possèdent un type (driver, mutex, etc) et sont stockés de manière hiérarchique (cf chapitre 3 du Windows Internals pour plus de détails).

Parcours manuel avec WinDBG

La première étape consiste à vérifier "à la main" avec WinDBG ce qui sera fait plus tard de manière automatique par le script Volatility. On utilise tout d'abord le KPCR trick afin de récupérer l'adresse de ObpRootDirectory, pointeur vers la racine de l'Object Manager (NB : on travaille ici sur Windows XP) :

lkd> dt _KPCR ffdff000
   +0x034 KdVersionBlock   : 0x8054c038

lkd> dt _DBGKD_GET_VERSION64 0x8054c038 
   +0x020 DebuggerDataList : 0xffffffff`80691b74

lkd> dt _LIST_ENTRY 80691b74
   +0x000 Flink            : 0x8054c060 _LIST_ENTRY [ 0x80691b74 - 0x80691b74 ]

Nous avons donc notre structure _KDDEBUGGER_DATA64 en 0x8054c060. A l'offset 0x98 (cf windbgexts.h), on y trouve le pointeur ObpRootDirectoryObject :

lkd> dd 0x8054c060+0x98 l 1
8054c0f8  8055fb58

lkd> dd 8055fb58 l 1
8055fb58  e1004ec8

ObpRootDirectoryObject pointe donc vers 0xe1004ec8, adresse à laquelle on trouvera la structure _OBJECT_DIRECTORY correspondant à la racine de l'Object Manager :

lkd> dt _OBJECT_DIRECTORY e1004ec8
   +0x000 HashBuckets      : [37] 0xe1007b70 _OBJECT_DIRECTORY_ENTRY

Il faut ensuite parcourir cet _OBJECT_DIRECTORY afin de récupérer son contenu. Cela a déjà été documenté et ne pose donc pas de problème ; on va simplement refaire ici le parcours du premier répertoire pour "mémoire" (hem) :

lkd> dt 0xe1007b70 _OBJECT_DIRECTORY_ENTRY
   +0x000 ChainLink        : 0xe1279008 _OBJECT_DIRECTORY_ENTRY
   +0x004 Object           : 0xe1007188

NB : le champ ChainLink pointe vers la structure suivante.

lkd> dt _object_header 0xe1007188-0x18
   +0x008 Type             : 0x80ebc3c0 _OBJECT_TYPE
   +0x00c NameInfoOffset   : 0x10

Le champ NameInfoOffset nous donne l'offset vers la structure _OBJECT_HEADER_NAME_INFO :

lkd> dt _object_header_name_info 0xe1007188-0x18-0x10
   +0x000 Directory        : 0xe1004ec8 _OBJECT_DIRECTORY
   +0x004 Name             : _UNICODE_STRING "ArcName"

lkd> dt 0x80ebc3c0 _OBJECT_TYPE
   +0x040 Name             : _UNICODE_STRING "Directory"

On vient donc de trouver le premier objet, nommé "ArcName", de type "Directory". Pour lister son contenu, on lit l'objet en tant que _OBJECT_DIRECTORY :

lkd> dt _object_directory 0xe1007188
   +0x000 HashBuckets      : [37] 0xe12793e8 _OBJECT_DIRECTORY_ENTRY

On récupére ses éléments comme précédemment, ici une chaîne de caractères :

lkd> dt _object_header_name_info e129a658-0x18-0x10
   +0x004 Name             : _UNICODE_STRING "multi(0)disk(0)rdisk(0)"

Application à Volatility

La version 1.3 de Volatility a introduit deux avancées majeures :

• la possibilité de développer des plugins indépendants, utilisables en les copiant simplement dans le répertoire memory_plugins ;
• la possibilité d'instancier une adresse en tant qu'objet et d'avoir un accès direct à ses différents champs avec la syntaxe Python (ex : "monobjet.monchamp").

L'accès à la structure _OBJECT_HEADER_NAME_INFO pourra ainsi se faire via (noter de même l'accès direct à la valeur NameInfoOffset) :

header_info = Object('_OBJECT_HEADER_NAME_INFO', myobj-offset-header.NameInfoOffset,
addr_space, None, profile=Profile())

Reste maintenant à automatiser le parcours des structures ci-dessus sous la forme d'un plugin. Pour le KPCR trick, inutile de tout recoder : la technique est déjà implémentée dans forensics/win32/info.py. Il manque cependant plusieurs choses pour notre winobj.py :

• dans vtypes.py, il manque la description des objets _OBJECT_DIRECTORY, _OBJECT_DIRECTORY_ENTRY et _OBJECT_HEADER_NAME_INFO. Leur implémentation se réalise un peu à la manière de dissecteurs Scapy à partir des informations issues de WinDBG ;
• dans vtypes.py, la description de _OBJECT_HEADER existe mais elle est incomplète : il manque par exemple le champ NameInfoOffset ;
• dans vtypes.py, la description de _KDDEBUGGER_DATA{32,64} ne contient pas l'offset vers le champ ObpRootDirectoryObject ;
• pour le KPCR trick, il faut implémenter les fonctions find_obprootdirectoryobject() et info_obprootdirectoryobject{32,64}(), retournant la valeur de ObpRootDirectory, à la manière de ce qui est déjà implémenté pour les autres champs de _KDDEBUGGER_DATA{32,64}.

Une fois l'adresse de la racine de l'Object Manager déterminée, on la parcourt récursivement pour en extraire les informations voules. Voici par exemple un extrait de la sortie du plugin sur l'image de référence xp-laptop-2005-07-04-1430.img du NIST :

Évidemment, comme toute liste chaînée qui se respecte, les structures _OBJECT_DIRECTORY_ENTRY peuvent être sujettes à du DKOM utilisable par une rootkit afin de cacher tout ou partie de ses éléments... C'est par exemple ce que faisait la preuve de concept Unreal.A.

Pour quoi faire ?

Le forensics en mémoire vive est une discipline en plein essor et complète le forensics "classique" réalisé sur des disques durs lors des missions de réponse à incident. Dans l'exemple ci-dessus, on l'utilise pour lister les objets manipulés par le système, ce qui inclut par exemple les pilotes (\Driver), les mutexes (\BaseNamedObjects) ou encore les sessions (\Sessions). Avantage de Volatility : la possibilité de scripter facilement, ouvrant ainsi la voie à l'analyse automatisée de malware via l'application de techniques forensics.

Les listes des noms de domaine utilisés par le ver Conficker que nous avions publiées s'arrêtent au 28 Février 2009.

Grâce à l'action coordonnée de Microsoft et de nombreux autres acteurs internationaux de la sécurité, l'intégralité des noms de domaines utilisés ont été pré-enregistrés afin de prévenir tout déploiement d'une charge malveillante. Il n'est donc plus utile de bloquer ces noms de domaine aujourd'hui. Toutefois, leur surveillance reste une méthode sûre afin d'identifier les machines infectées d'un réseau, celles-ci tentant continuellement de se connecter à leur canal de contrôle.

Microsoft a donc publié la liste des domaines utilisés par les variantes A et B de Conficker jusqu'en Juin 2009. Celle-ci est accessible ici.

Notons que la communication de Microsoft concernant l'enregistrement des noms de domaine était accompagnée d'une coquette récompense pour l'arrestation de l'auteur du ver : pas moins de 250 000 $ !