Compte-rendu d'investigation Debian après les compromissions de serveurs

2 décembre 2003

L'équipe d'administration Debian et des experts de sécurité ont finalement réussi à indiquer exactement la méthode utilisée pour s'introduire sur quatre machines du projet. Cependant, la personne ayant fait cela n'a pas encore été découverte.

Les archives de paquets n'ont pas été modifiée par l'intrus.

Les équipes d'administration et de sécurité Debian ont vérifié ces archives (security, us, non-US) assez tôt dans le processus d'investigation et de réinstallation. C'est pourquoi le projet a pu réouvrir l'archive de sécurité et confirmer que la mise à jour de stable (3.0r2) n'a pas été compromise.

Si le projet avait anticipé d'être compromis au moment même de la publication de la mise à jour de stable, les personnes impliquées l'auraient différée. Cependant, les paquets mis à jour étaient déjà installées dans l'archive stable et sur les miroirs au moment où les intrusions ont été découvertes, il n'était donc plus possible de la retarder.

Plusieurs méthodes basées sur différentes données de contrôle ont été utilisées pour vérifier les paquets et garantir que les archives n'avaient pas été touchées par l'intrus :

Chronologie

Voici ci-dessous la chronologie de la découverte et de la récupération des machines compromises. Tous les horaires sont relatifs à UTC. Certains horaires ne sont que des estimations car notre conversation ne contenait pas les horodatages exacts.

Découverte

Dans la soirée (GMT) du jeudi 20 novembre, l'équipe d'administration a remarqué plusieurs oopses noyau sur master. Comme le système fonctionnait sans problème depuis une longue période de temps, le système allait être placé en maintenance pour investigations plus poussées pour des problèmes potentiels de matériel. Cependant, au même moment, une deuxième machine, murphy, a subi exactement le même problème, ce qui a paru suspect aux administrateurs.

Klecker, murphy et gluck ont également un « environnement avancé de détection d'intrusions » (paquet aide) installé pour surveiller les modifications au système de fichiers et à peu près au même moment, il a commencé à avertir que /sbin/init avait été remplacé et que les valeurs d'heures de modification (mtime) et de création (ctime) pour /usr/lib/locale/en_US avaient changé.

Des investigations plus poussées ont révélé que la cause de ces deux problèmes étaient le rootkit SucKIT (1.3b). Il inclut un renifleur de mots de passe et des capacités d'évasion de détection (i.e. des outils pour cacher des processus et des fichiers) installés directement dans le noyau, ce qui a, à son tour, causé les oopses remarqués.

Analyse détaillée de l'attaque

Le mercredi 19 novembre, vers approximativement 17 h GMT, un mot de passe reniflé a été utilisé pour se connecter sur un compte de développeur non privilégié sur l'hôte klecker (.debian.org). L'attaquant a ensuite récupéré le code source par HTTP pour un exploit de noyau local inconnu (à ce moment) et il a obtenu les permissions root par cet exploit. Ensuite, le rootkit SucKIT a été installé.

Les même compte et mot de passe ont été utilisés pour se connecter sur la machine master, pour obtenir les permissions root avec le même exploit et pour y installer également le rootkit SucKIT.

L'attaquant a ensuite essayé d'accéder à l'hôte murphy avec le même compte. Cela a échoué car murphy est une machine d'accès restreint et son seul but est d'agir comme serveur de listes auquel seul un petit groupe de développeurs peuvent se connecter. Comme la tentative initiale de connexion n'a pas fonctionné, la personne a utilisé son accès root sur master pour accéder à un compte administratif utilisé à des fins de sauvegarde et il a également obtenu l'accès à murphy. Le rootkit SucKIT a également été installé sur cet hôte.

Le jour suivant, l'attaquant a utilisé un mot de passe reniflé sur master pour se connecter à gluck, y obtenir l'accès root et installer le rootkit SucKIT.

L'analyse post-mortem a révélé les dates et heures exactes où le programme /sbin/init a été réécrit et le rootkit installé. Les analystes ont également découvert le fichier exécutable utilisé pour obtenir l'accès root sur les machines, fichier qui était protégé et assombri avec Burneye. Après dépliage et désassemblage de l'exploit, les experts de sécurité ont découvert quel bogue du noyau avait été utilisé.

Un dépassement d'entier dans l'appel système brk a été utilisé pour réécrire de la mémoire du noyau (octets de protection de changement de page). En agissant ainsi, l'attaquant a obtenu le contrôle total de l'espace de mémoire du noyau et il a pu modifier n'importe quelle valeur en mémoire.

Bien que ce code du noyau ait été amélioré en septembre par Andrew Morton et copié dans des préversions récentes du noyau depuis octobre, l'implication de sécurité de l'amélioration n'avait pas été considérée. C'est pourquoi aucune alerte de sécurité n'avait été émise par les distributions. Cependant, après la découverte de son utilisation comme exploitation locale de root, le projet Common Vulnerabilities and Exposures a assigné la référence CAN-2003-0961 à ce problème. Il est corrigé dans le noyau Linux 2.4.23 qui a été publié le week-end dernier et dans l'alerte de sécurité Debian DSA 403.

Le noyau Linux 2.2.x n'est pas vulnérable à cet exploit car la vérification de limite est effectuée auparavant. Nous croyons également que les noyaux Sparc et PA-RISC ne sont pas vulnérables car les adresses utilisateur et noyau sont stockées dans des espaces d'adresse différents pour ces architectures.

Merci de comprendre que nous ne pouvons pas fournir l'exploit utilisé à toute personne que nous ne connaissons pas. Merci donc de ne pas nous en demander plus.

Récupération

Après que les machines ont été arrêtées, des images des disques durs compromis ont été créées et stockées sur une machine séparée. Elles ont été distribuées aux personnes effectuant l'analyse post-mortem. Les trois machines aux États-Unis (master, murphy, gluck) ont été réinstallées ensuite et les services réinstaurés un à un après investigation par l'administrateur du service concerné.

Cependant, sur klecker, cela a été retardé à cause d'une maintenance prévue afin que l'archive de sécurité puisse être remise en ligne plus tôt que les autres services. À ce moment, nous n'avions également pas d'accès console à klecker, la récupération a donc dû se dérouler à distance. Après qu'une image disque a été faite par connexion en console série vers une machine locale sur une connexion réseau protégée par un pare-feu, le rootkit a été supprimé, le noyau échangé et renforcé, les binaires vérifiés deux fois et l'archive de sécurité vérifiée par rapport à plusieurs sources externes différentes. Cette machine sera réinstallée dans les prochaines semaines.

Comme précaution de sécurité, tous les comptes des développeurs ont été désactivés dans LDAP et les clés SSH supprimés sur les machines les plus importantes pour qu'aucune nouvelle machine ne puisse être compromise. Cela a cependant totalement désactivé tous les travaux publics Debian impliquant des envois de fichiers et des accès aux dépôts CVS.

Tous les mots de passe utilisés sur quantz (i.e. tous les mots de passe Alioth, arch et subversion) ont également été invalidés. Toutes les clés SSH autorisés ont également été supprimés. Veuillez utiliser le système de récupération des mots de passe perdus pour recevoir un nouveau mot de passe.

Quand tous les services fonctionneront à nouveau et que les machines seront suffisamment sécurisées, LDAP sera réinitialisé pour que les développeurs puissent créer un nouveau mot de passe. Il n'est cependant pas possible actuellement de prédire quand cela se déroulera.

Après la récupération, SSH a été réinstallé sur les machines compromises. C'est pour cela qu'il y a de nouvelles clés d'hôtes RSA et d'empreintes de clé pour ces hôtes. Les clés seront inclues dans LDAP dès qu'elles seront créées et pourront être récupérées à partir d'ici.

Conséquences

Renouvelez vos mots de passe !

Comme des mots de passe ont été reniflés sur les hôtes compromis, toute connexion sortante qui impliquait un mot de passe doit être considérée comme compromise également, i.e. le mot de passe devrait être considéré comme connu de l'attaquant. Il devrait donc être immédiatement changé.

De plus, si quelqu'un avait accès à une machine Debian et utilisait le même mot de passe ou phrase d'accès (passphrase) sur d'autres machines ou clés, nous vous invitons fortement à changer le mot de passe ou la phrase d'accès respectivement dès que possible.

Si une clé SSH a été générée ou stockée sur l'une de ces machines et a été utilisée pour se connecter sur d'autres machine (i.e. en l'installant dans .ssh/authorized_keys), elle devrait également être supprimée.

Les clés secrètes GnuPG/PGP qui étaient trouvées sur les machines debian.org ont également été supprimées des trousseaux de clés Debian et donc désactivées.

Les développeurs inquiets pour leurs propres machines devraient au moins exécuter chkrootkit et observer sa sortie. Matt Taggart maintient un rétroportage de la version actuelle pour Woody à l'adresse suivante :

De plus, une liste détaillée des problèmes de précaution est fournie par Wichert Akkerman et Matt Taggart.

Rootkit SucKIT-Kit

SucKIT est un rootkit présenté dans l'édition 58 de Phrack, article 0x07 (« modifier le noyau Linux à la volée sans LKM » par sd & devik). C'est un rootkit complètement fonctionnel qui est chargé par /dev/kmem, i.e. il n'a pas besoin d'un noyau avec la gestion des modules de noyau chargeables. Il fournit un shell de connexion à rebours d'accès à distance protégé par mot de passe initié par un paquet frauduleux (outrepassant la plupart des configurations de pare-feu) et il peut dissimuler des processus, des fichiers et des connexions.

Habituellement, SucKIT est lancé par /sbin/init lors du démarrage du système, se duplique pour s'installer dans le noyau, installe une porte dérobée et exécute une copie du binaire « init » d'origine à partir du parent (avec le pid 1). Toutes les exécutions suivantes de /sbin/init sont redirigées vers l'init d'origine.

Protection Burneye de TESO

Burneye est un moyen d'assombrir (« obfuscate ») des binaires ELF sur la plate-forme UNIX présenté dans l'édition 58 de Phrack, article 0x05 (« Renforcer le format ELF : cryptage de binaire sur la plate-forme UNIX », par grugq & scut). En utilisant des outils comme Burneye de TESO, un attaquant peut modifier un programme exécutable pour crypter son but réel, le cachant des filtres de pare-feu, des systèmes de détection d'intrusion, des logiciels antivirus et des yeux curieux des investigateurs.

Remerciements

Réactions de la presse

Informations de contact

Pour plus d'informations, veuillez visiter les pages web de Debian ou envoyer un courriel à press@debian.org.