accueilSécuritéIncidents de sécuritéChronique d’incidents
 

La clé était sous le paillasson


Un laboratoire a été averti par Google que son site web hébergeait du code malfaisant. Évidemment les résultats du moteur de recherche de Google qui pointent sur le site compromis indiquent très clairement qu’il est vivement déconseillé de s’y connecter. Ce n’est évidemment pas bon pour l’image de marque. L’analyse a montré très rapidement que du code javascript offusqué[1] avait été introduit dans certaines pages. La lecture des journaux a montré que ces pages avaient été modifiées à l’aide d’une connexion FTP avec l’identité du gestionnaire du site web mais à partir d’une adresse IP provenant d’un pays étranger. Il s’est avéré que le poste de travail du gestionnaire du site web avait été compromis par un code malveillant. Sans que l’on en ait la totale certitude, il semblerait bien qu’en la circonstance une vulnérabilité d’une machine virtuelle java non mise à jour ait été exploitée. Ce code malveillant a exfiltré vers le pirate les noms, identifiants, mots de passe utilisés pour se connecter sur différents serveur. A partir de ce moment, l’attaque est imparable car le pirate possède tous les éléments pour se connecter. Il faut noter que très souvent pour en faciliter l’usage, les clients servant à se connecter sur un serveur stockent dans un fichier de configuration, les identifiant et mots de passe utilisés pour la connexion. Dans bien des cas le mot de passe se trouve en clair dans le fichier de configuration, lorsqu’il est chiffré il peut être déchiffré car le client doit pouvoir le faire[2]. Quels enseignements peut-on tirer de cet incident ? · Maintenir à jour les postes de travail (aurait évité l’utilisation de la vulnérabilité de la machine virtuelle java). · Mettre des contrôles d’accès sur les adresses IP. Le monde entier n’a pas besoin de se connecter pour la mise à jour du site web. · Utiliser des protocoles sécurisés tel que SSH plutôt que FTP où le mot de passe transite en clair. En l’occurrence cela n’aurait pas évité l’attaque puisque l’attaquant a eu accès au mot de passe sur le poste de travail mais c’est néanmoins une bonne mesure de sécurité. · Privilégier une authentification à l’aide de clé publique et clé privée. Pourvue que la clé privée eut été protégée par un mot de passe cela aurait compliqué singulièrement la tâche du pirate qui aurait dû attendre que l’utilisateur fournisse son mot de passe pour alors récupérer ce mot de passe ou directement la clé privée déchiffrée. · Utiliser un coffre-fort comme keepass[3] pour stocker ses mots de passe. · Surveiller les journaux. Des connexions anormales devraient lever des alertes. · Utiliser intelligemment les services de Google pour s’assurer que son site n’a pas été compromis. La requête suivante (supprimer les espaces) :

http: // www . google . com/safebrowsing/diagnostic ?site=http: // www . cnrs . fr

permet de voir l’état du site www.cnrs.fr (remplacer par le nom de votre propre site). Une procédure décrite sur le site de Google[4] permet lorsque le site a été nettoyé de se faire retirer de la liste noire.

[1] L’offuscation consiste à chiffrer le code et à le faire exécuter par une procédure qui au préalable va le déchiffrer. Si l’offuscation ne résiste pas à l’analyse (il suffit de faite exécuter la procédure de déchiffrement), elle complique singulièrement la lecture du code et l’action des outils de détection comme les antivirus.

[2] Nous l’avons vérifié avec FileZilla.

[3] http://www.projet-plume.org/fiche/k...

[4] http://support.google.com/webmaster...


ARESU
Direction des Systèmes d'Information du CNRS

358 rue P.-G. de Gennes
31676 LABEGE Cedex

Bâtiment 1,
1 Place Aristide Briand
92195 MEUDON Cedex



 

 

Direction des Systèmes d'Information

Pôle ARESU

Accueil Imprimer Plan du site Credits