1 Cycbot : description et contre-mesures

1.1 Description

Des fichiers exécutables codés et embarqués dans des images téléchargées sur l’Internet ont révélé la présence d’un cheval de Troie. Ce programme, dénommé Cycbot, envoie des données binaires à un serveur et pourrait recevoir des commandes de celui-ci fournissant ainsi un contrôle total de la machine.

Au moins une trentaine de noms de domaine différents sont contactés par les postes infectés. Un certain nombre de points communs dans les requêtes HTTP envoyées au serveur de contrôle et de commande sont caractéristiques de ce logiciel malveillant. Toutes les URL contiennent le paramètre tq dont la valeur est un flux binaire codé en base64. Une partie des requêtes utilisent également le paramètre vNUM1=NUM2NUM1 et NUM2 sont des nombres composés de 1 à 3 chiffres décimaux. Certaines requêtes utilisent aussi le User-Agent mozilla/2.0. Habituellement, cet en-tête HTTP comprend aussi la version du navigateur et du système d’exploitation, par exemple :
Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1.

L’URI envoyée dans la requête HTTP correspond parfois au chemin d’une image, par exemple /images/im134.jpg. Enfin, des requêtes utilisant la méthode HTTP POST comportant aussi le paramètre tq sont envoyées vers zonedg.com/index.html.

1.2 Mesures de protection envisageables

La détection et l’identification des machines compromises par ce cheval de Troie peuvent être réalisées par une analyse des journaux HTTP de la passerelle Web. Le User-Agent mozilla/2.0 et les requêtes POST envoyées vers le domaine zonedg.com identifient en effet de manière quasi-certaine des machines infectées par le virus Cycbot. La recherche des requêtes HTTP contenant un paramètre dans l’URL nommé tq, notamment grâce à l’expression rationnelle [&?]tq=[%[:alnum:]]+ permettra d’obtenir une liste plus complète des postes compromis. Toutefois, il est possible que cette recherche fasse apparaître quelques requêtes légitimes.

Il est plus hasardeux de considérer la machine comme infectée si elle effectue des requêtes vers une URL correspondant au chemin d’une image. En effet, la recherche de ce type de requêtes fournira de nombreux faux positifs car elles sont très courantes.

De manière générale, les bonnes pratiques suivantes permettent de prévenir l’infection d’une machine ou d’en limiter l’impact :

  • contrôler les User-Agents au niveau du serveur Web mandataire grâce à une liste blanche adaptée ;
  • interdire le téléchargement d’exécutables au niveau des serveurs Web mandataires, sauf exceptions paramétrables, par exemple, sous la forme d’une liste blanche ;
  • tenir à jour les logiciels et restreindre les droits des comptes des utilisateurs au strict minimum afin d’éviter toute installation non légitime ;
  • éduquer les utilisateurs pour limiter les conduites à risques.

Documentation

2 Reconnaissance faciale sur Facebook

Depuis quelque temps déjà, le réseau social Facebook a mis en place une nouvelle fonctionalité : la reconnaissance faciale.

Lors du téléchargement sur le site de photos par un utilisateur, un logiciel de reconnaissance faciale est utilisé. Il compare les photos nouvellement ajoutées aux photos où l’utilisateur est déjà marqué afin de trouver d’éventuelles correspondances entre les visages des personnes présentes. Si des visages connus sont trouvés, alors le site propose automatiquement à l’utilisateur de marquer ces personnes.

Cette fonctionnalité pose des problèmes évidents de contrôle d’image sur l’Internet en favorisant le marquage des photos. D’autant plus qu’elle est activée par défaut. Il est cependant possible de la désactiver dans les options de configuration d’un compte : paramètres de confidentialité -> personnaliser les paramètres -> « Ce que d’autres partagent » -> « Suggérer à mes amis les photos où j’apparais » -> modifier les paramètres -> désactiver. Attention, ce paramètrage n’empêche pas le marquage manuel des photos.

Documentation

3 Incident de la semaine

Cette semaine, un correspondant du CERTA lui a confié l’analyse d’un serveur au comportement suspect.

Les exploitants analysant les journaux de connexion sur le mandataire (proxy) ont constaté des flux IRC anormaux pour ce serveur. L’analyse des journaux et du disque a permis de retracer la chronologie et de trouver la cause decette anomalie.

Des attaquants ont tenté diverses attaques contre le serveur, sur lequel un Apache, phpMyAdmin, Plone, Zope et un serveur pour le protocole de partage de données OPeNDAP s’exécutaient. Certaines attaques étaient des recherches de mots de passe par dictionnaire. Elles ont échoué.

Par contre, une attaque contre un script du serveur OPeNDAP a réussi et a donné aux agresseurs la possibilité d’exécuter des actions avec les droits de l’utilisateur www-data. Cela a suffi à installer un serveur IRC et, bien entendu, à l’utiliser.

Le succès de l’attaque a été permis par l’abscence de mise à jour des logiciels, et dans ce cas précis, de ce serveur OPeNDAP. Les attaquants ont probablement recherché des proies de manière méthodique. Le champ referrer dans la requête HTTP du début de l’attaque est une recherche Google sur le nom du script vulnérable.



La morale de l’incident est double ;

  • maintenir les logiciels à jour est indispensable ;
  • analyser les journaux sortants permet de déceler des intrusions et les entrants d’en comprendre la cause et de réagir en conséquence.

Ceci illustre un des concepts de la défense en profondeur :

  • face à l’agresseur, il faut multiplier les obstacles et en varier la nature ;
  • et, comme dans le cas présent, associer à chaque obstacle, qui ne doit être perçu que comme un retardateur, un système de détection du franchissement ou de l’imperfection de l’obstacle (ici par l’analyse des journaux) et une procédure de réaction appropriée (par exemple, l’isolement de l’ordinateur).

Rappel des avis émis

Dans la période du 30 mai au 05 juin 2011, le CERT-FR a émis les publications suivantes :