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 :
- des listes, stockées à l'extérieur, de sommes MD5 accumulées sur les dernières semaines sur des machines non compromises
- des fichiers .changes signés numériquement des archives externes de debian-devel-changes sur des machines non compromises
- des fichiers .changes signés numériquement sur les serveurs respectifs des archives
- des fichiers de journaux miroir stockés à l'extérieur
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.
- 18 sept. 01:33 Linus Torvalds diffuse le noyau 2.6.0-test6 avec le correctif do_brk()
- 02 oct. 05:18 Marcelo Tosatti applique la vérification de limite do_brk()
- 19 nov. 17:00 L'intrus se connecte à klecker avec un mot de passe reniflé
- 19 nov. 17:08 Rootkit installé sur klecker
- 19 nov. 17:20 L'intrus se connecte à master avec le même mot de passe reniflé
- 19 nov. 17:47 Rootkit installé sur master
- 19 nov. 18:30 L'intrus se connecte sur murphy avec le compte de service de master
- 19 nov. 18:35 Rootkit installé sur murphy
- 19 nov. 19:25 Des oopses commencent à se produire sur murphy
- 20 nov. 05:38 Des oopses commencent à se produire sur master
- 20 nov. 20:00 Découverte des oopses sur master et murphy
- 20 nov. 20:54 Rootkit installé sur gluck
- 20 nov. 22:00 Confirmation que debian.org est compromis
- 21 nov. 00:00 Désactivation de tous les comptes
- 21 nov. 00:34 Arrêt de security.debian.org
- 21 nov. 04:00 Arrêt de gluck (www, cvs, people, ddtp)
- 21 nov. 08:30 Renvoi de www.debian.org vers www.de.debian.org
- 21 nov. 10:45 Annonce publique
- 21 nov. 16:47 Informations pour les développeurs mises à jour
- 21 nov. 17:10 Arrêt de murphy (listes) et de master
- 22 nov. 02:41 security.debian.org est de retour en ligne
- 25 nov. 07:40 lists.debian.org est de retour en ligne
- 28 nov. 22:39 Diffusion de Linux 2.4.23
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 :
- deb http://lackof.org/taggart/debian woody/chkrootkit main
- deb-src http://lackof.org/taggart/debian woody/chkrootkit main
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
- James Troup et Ryan Murray pour leur travail général sur tous les hôtes
- Adam Heath et Brian Wolfe pour leur travail sur master et murphy
- Wichert Akkerman pour son travail sur klecker
- Dann Frazier et Matt Taggart pour leur travail sur gluck
- Michael Stone et Robert van der Meulen pour leur travail post-mortem
- Marcus Meissner pour le désassemblage de l'exploit utilisé
- Jaakko Niemi pour son travail de vérification et de réactivation de lists.debian.org
- Colin Watson pour son travail sur la vérification et la réactivation de bugs.debian.org
- Josip Rodin pour son travail sur la vérification et la réactivation des archives web des listes
Réactions de la presse
- Slashdot, 21 novembre 2003
- eWeek, 21 novembre 2003
- InternetNews, 21 novembre 2003
- Heise Newsticker, 21 novembre 2003 (en allemand)
- Pro-Linux, 21 novembre 2003 (en allemand)
- Linux-Community, 21 novembre 2003 (en allemand)
- BarraPunti, 21 novembre 2003 (en espagnol)
- Newsforge, 21 novembre 2003
- SearchEnterpriseLinux.com, 22 novembre 2003
- Debian Planet, 22 novembre 2003
- PC World, 24 novembre 2003
- ZDNet UK, 24 novembre 2003
- Enterprise Linux IT, 24 novembre 2003
- The Age, 24 novembre 2003
- Sydney Morning Herald, 24 novembre 2003
- Windows & .NET Magazine, 24 novembre 2003
- Infoworld, 24 novembre 2003
- Linux Insider, 24 novembre 2003
- eCommerce Times, 24 novembre 2003
- TechNewsWorld, 24 novembre 2003
- The Register, 28 novembre 2003
- Newsforge, 28 novembre 2003
- Slashdot, 28 novembre 2003
- Slashdot, 1 décembre 2003
- The Age, 1 décembre 2003
- Sydney Morning Herald, 1 décembre 2003
- Pro-Linux, 2 décembre 2003 (en allemand)
- Heise Newsticker, 2 décembre 2003 (en allemand)
- Golem, 2 décembre 2003 (en allemand)
- LWN, 2 décembre 2003
- The Register, 2 décembre 2003
- ZDnet DE, 2 décembre 2003 (en allemand)
- Linux-Community, 2 décembre 2003 (en allemand)
- Heise, 2 décembre 2003 (en allemand)
- Heise Newsticker, 2 décembre 2003 (en allemand)
- Symlink, 2 décembre 2003
- Pro-Linux, 3 décembre 2003 (en allemand)
- Heise Newsticker, 4 décembre 2003 (en allemand)
- Symlink, 4 décembre 2003 (en allemand)
- Symlink, 4 décembre 2003
- Newsforge, 4 décembre 2003
- Newsforge, 5 décembre 2003
- OSnews, 10 décembre 2003
- Cnet, 10 décembre 2003
- Newsforge, 30 décembre 2003
Informations de contact
Pour plus d'informations, veuillez visiter les pages web de Debian ou envoyer un courriel à press@debian.org.