Winter is raging throughout Europe, but russian fraudsters find it rather "cool".

Indeed, the "coolwinter.ru" domain name has been recently registered to serve as a command and control server for a ZeuS trojan horse variant. The pirate, nicknamed "Foxtrot", advertises its services (bulletproof hosting and domain registration, XRumer reselling, etc.) on various well-known russian underground forums and through websites such as www.foxtrot1.biz. A rather small prey for law enforcement. Its ZeuS malware is not very interesting either: standard banks targeted, medium AV detection, and a few hundred infected machines at the most.

But this domain's name servers (ns1 and ns2.bestofthehost.com) host almost 100% illicit content (rogue AV software, fake pharmacies, HYIP, malware propagation and C&C, etc.) using Baltconn's IP addresses. Baltconn is a recent Internet provider, based in Latvia, that gets its connectivity through few upstream network providers such as GBLX (Global Crossing). This name sounded familiar to my ears, as it indeed provided connectivity to Atrivo/Intercage or McColo in the past. Last year they pulled the plug of these bulletproof hosting providers, when reports of their fraudulent behavior became public.

Facts are yet insufficients to determine if Baltconn is a laxist or just heavily abused provider. But the abuse reports sent by email to baltconn.lv obviously won't go very far, as their domain name expired last October.

We might be able to ask CERT NIC Latvia their opinion on this company when we meet them during the next joint FIRST and TERENA TF-CSIRT meeting they host in Riga in a few days.

Ce premier Patch Day Microsoft de l'année s'est révélé particulièrement calme puisqu'un unique bulletin a été publié, corrigeant trois failles dont une déjà connue :

MS09-001 : dans le pilote "srv.sys", une vulnérabilité pouvant entrainer un déni de service (Réf Lexsi 10651), ainsi que deux vulnérabilités permettant potentiellement l'exécution de code arbitraire (Réf Lexsi 11153). La version beta du tout nouveau Windows 7 est affectée par l'une de ces vulnérabilités.

A noter qu'une exploitation réussie des deux dernières vulnérabilités pour exécuter du code arbitraire semble a priori plutôt difficile.

Une journée calme, donc ? Pas si sûr... Ce serait compter sans Oracle et son lot de 41 vulnérabilités corrigées par le Oracle January 2009 Critical Patch (Réf Lexsi 11155). On notera en particulier la présence de 5 failles possédant un CVSS de 10...

Depuis le mois de décembre et la première variante de Conficker, nous avons eu l'occasion de conseiller et d'assister certains de nos clients sur la méthodologie à adopter pour faire face à ce nouveau ver. Ce billet reprend certaines informations pratiques, en particulier sur une variante plus récente (Conficker.B, alias Downadup.B).

Comment se sortir de ce type d'infection généralisée sur tout un réseau d'entreprise, filiale à l'étranger y compris ? Dans le cas présent, la première chose à faire consiste à bloquer en sortie les résolutions DNS ou les flux vers les domaines utilisés pour les mises à jour du ver ; celui-ci ne pourra plus se mettre à jour et on pourra effectuer la désinfection sans que la cible ne soit "mouvante". F-Secure en fournit une liste régulièrement mise à jour. Simple à dire, ce point peut se révéler plus problématique que prévu (cas typique où le DNS est externalisé vers un prestataire pas toujours très réactif, ou dans le cas où un simple filtrage IP sur le pare-feu de l'entreprise ne servirait à rien, à cause des techniques de fast-flux notamment).

Pour la suite, la méthodologie est simple : on détermine les modes de propagation et on les supprime les uns après les autres.

Exploitation de la vulnérabilité MS08-067

La capture suivante montre une infection typique par ce biais (noter l'appel à NetPathCanonicalize) :

On remarque ici que l'exploitation se fait via l'interface \browser, l'accès à \srvsvc étant refusé. Dans le code d'exploitation, on remarque bien le motif "\..\..\" typique de MS08-067 :

Regardons plus précisément ce que l'exploit fait. On a pas mal de code de déchiffrement au début, comme celui-ci par exemple :

Un peu plus loin, la bibliothèque URLMON est chargée avec LoadLibraryA() :

Tout ceci afin de télécharger, via la fonction URLDownloadToFileA(), un fichier depuis la machine attaquante, donc infectée, sur un port que celle-ci avait choisi au hasard et préalablement ouvert (URL du type http://ip_attaquante:port_random/ chaine_random) :

On imagine que c'est une copie du ver qui est téléchargée pour être ensuite exécutée. Bien évidemment, le ver ajoute des exceptions au pare-feu Windows de la machine attaquante pour que les nouvelles machines infectées puissent accéder en toute tranquillité à ce fichier :

Pour se protéger contre ce biais d'exploitation, il n'y a pas 36 solutions : appliquer le correctif MS08-067 (KB958644) sur l'ensemble du parc (cela suppose bien sûr que le parc soit déjà migré au moins en Windows 2000 SP4, XP SP2 ou Vista), ou à défaut, une des solutions de contournement. Aucune régression fonctionnelle n'a été remontée suite à l'application de ce correctif, donc aucune raison a priori de ne pas le faire.

Propagation via ADMIN$

A ce moment du jeu, on arrive à désinfecter les quelques postes qui nous servent de témoin, avec éventuellement un petit coup de main manuel (et avec les signatures en version "beta" fournies par l'éditeur anti-virus). Mais au bout de quelques minutes, l'antivirus affiche malgré tout une alerte indiquant qu'une nouvelle instance à été trouvée sur le poste, et qu'elle a pu être supprimée (ou pas...). Nous avions heureusement pris soin de laisser tourner quelques Wireshark en arrière-plan et les différents PCAP obtenus sont riches en enseignements.

Une première capture montre que le ver se connecte via DCERPC à l'interface \samr :

Il utilise en particulier la fonction EnumDomainUsers afin de lister les comptes (si la machine attaquée est un contrôleur de domaine, cela retourne les utilisateurs du domaine ; sinon, cela retourne les utilisateurs locaux comme sur la capture ci-dessous) :

Pour chaque utilisateur ainsi trouvé, d'autres fonctions sont appelées :

Elles permettent au ver de récupérer diverses informations supplémentaires comme par exemple les dernières dates de connexion avec QueryUserInfo :

Une fois les utilisateurs énumérés, le bruteforce des mots de passe peut commencer :

Evidemment, si vous aviez appliqué la GPO de verrouillage automatique de comptes, cela entrainera le verrouillage de tout ou partie de vos comptes utilisateurs.

Tout ceci dans quel but ? Utiliser le partage administratif ADMIN$ afin d'y déposer une copie du ver :

Ceci explique pourquoi, sur une machine pourtant patchée, le ver revenait au bout de quelques minutes. Dans le détail, cela donne :

1. connexion au partage ADMIN$
2. requête Trans2 de type QUERY_PATH_INFO sur \System32 (dates, attributs, etc, peut-être pour vérifier que la connexion est bien établie)
3. requête Trans2 de type FIND_FIRST2 sur \System32\ftahxx.dll (nom choisi au hasard). Réponse de la machine attaquée : STATUS_NO_SUCH_FILE
4. requête NT Create AndX Request pour créer le fichier \System32\ftahxx.rc. Petite remarque : le ver demande à créer un fichier "super caché" (attributs caché et système) :

Le ver ne s'arrête pas là puisqu'il en profite aussi pour se connecter via DCERPC à l'interface \atsvc pour ajouter une nouvelle tâche planifiée via la fonction JobAdd :

Cette tâche démarrera le ver tous les jours à heure fixe et consiste à exécuter une fonction, ici nzyfqo(), de la bibliothèque préalablement déposée via ADMIN$ (cette tâche apparaitra comme AT1, AT2, AT3, etc, dans l'écran des Tâches planifiées) :

La détection de cette DLL est la suivante :

Pour endiguer la propagation du ver par ce moyen, il suffit de désactiver le partage administratif ADMIN$, par exemple via les valeurs AutoShareWks et AutoShareServer de la clé de registre HKLM\System\CurrentControlSet\Services\LanmanServer\ Parameters (attention, cela AURA des conséquences sur le parc).

Clés USB

Comme le ver se propage aussi via les clés USB, il est recommandé de désactiver Autorun et Autoplay. Idéalement, on formatera toutes les clés USB utilisées pendant la période d'infection.

Epilogue

Une fois que le ver ne se réplique plus sur le réseau, on peut estimer que le gros du travail a été fait. Le travail n'est cependant pas tout à fait fini puisque celui-ci, lors de son exécution, affecte la sécurité du système. Par exemple, il désactive le service BITS et Windows Update, en plus d'ajouter des exceptions au pare-feu Windows comme vu précédemment. La remise du parc dans son état pré-infection pourra donc prendre plus de temps que prévu.

On ne rappellera donc jamais assez l'urgence d'appliquer la mise à jour MS08-067 (KB958644), et de s'assurer de la robustesse de ses mots de passe, le risque n'étant pas seulement théorique.

Après les constats de fin d'année 2008 arrivent les pronoSSTICs (:-)) pour l'année 2009. La cybercriminalité étant en constante évolution, nous ne pouvons qu'émettre des hypothèses, que voici :

• Toujours plus de malware. Il n'y a vraiment pas de raison que l'augmentation du nombre de malware cesse. D'autant plus que le nombre croissant de développeurs au chômage dans certains pays risque d'amplifier encore cette tendance. Parmi ces malware, de plus en plus de chevaux de Troie. Sachant que les éditeurs AV se penchent depuis un certain temps sur des solutions de détection par white listing et autres analyses comportementales, nous pensons que les malware vont évoluer vers encore plus de chiffrement des communications, méthodes d'offuscation et techniques de dissimulation par rootkit.

• Evolution des recherches en matière de vulnérabilités : Les vulnérabilités utilisées pour infecter les postes des victimes de malware vont évoluer de façon significative : impacter de plus en plus les navigateurs alternatifs tels que Firefox, mais aussi tous ses plug-ins, sur lesquels (pour la plupart en tout cas) aucun audit sérieux n'est effectué...

• Poursuite et augmentation des infections de sites légitimes. Là encore, pourquoi changer une méthode qui fonctionne très bien ? Et d'ailleurs, pourquoi ne pas aller plus loin encore et contaminer directement les sites de mises à jour d'applications largement déployées par le grand public ? Après tout, presque personne ne vérifie l'intégrité des données téléchargées sur Internet... D'autant plus que ce type de compromission a déjà été constatée par le passé.

• Poursuite de la professionnalisation en matière de cybercriminalité : de plus en plus de phishing seront hébergés dans des paradis législatifs. Etant donné les délais de fermeture des sites frauduleux dans certaines parties du globe, les fraudeurs risque d'opérer de plus en plus depuis ce genre de pays...

• Hébergement des sites de phishing directement sur des machines de particuliers, via des botnets, avec dissimulation de serveurs web sur les machines infectées.

• Plus d'attaques DDoS, aux motifs variés : cyberwar (dois-je rappeler ce qui s'est passé en Estonie, en Georgie, ou ce qui se passe en ce moment avec Israel ?), vengeance/nuisance (Rappelez-vous Castlecops, Bobbear, etc.), chantage, concurrence déloyale...

• Augmentation des attaques ciblées. Les réseaux sociaux, en plein boom, fournissent suffisamment d'informations pour pouvoir attaquer les personnages clef de diverses entreprises dont certains concurrents aimeraient connaitre les secrets...

• Plus de pots de vin. Quand on génère autant de bénéfices que certains fraudeurs (non non je n'ai pas le regard tourné vers certains pays de l'Est...), pourquoi compromettre un système pour obtenir de l'information alors qu'on peut acheter un employé ou un stagiaire parfois payé une misère ?

• Beaucoup plus de chiffrement utilisé par "M. Tout le monde". Cela semble inévitable. Il devient tellement facile de chiffrer les données, avec des outils tels que Truecrypt, que c'est maintenant à la portée du premier venu. Y compris des pédophiles, pirates, ou autre personne à l'activité illicite souhaitant la dissimuler.

Malgré ce constat sombre, des améliorations devraient se poursuivre dans la lutte anti-cybercriminalité en 2009. L'ensemble de la communauté de lutte contre la cybercriminalité (surtout au niveau des CERT, des éditeurs de solutions antivirales, et autres professionnels de la sécurité informatique) a prouvé qu'elle communiquait mieux, comme le démontre les affaires Atrivo et McColo par exemple. De grands efforts sont actuellement déployés en ce sens. Nous espérons que ce phénomène s'amplifiera encore en 2009.

Le Cert-Lexsi vous souhaite une très bonne année 2009 ! The Cert-Lexsi Team wishes you a happy new year 2009 !