09-16 = La compromission des serveurs de la fondation Apache

Le rapport d'incident publié dernièrement par les administrateurs de l'infrastructure de la fondation 'Apache' est fort instructif. Il détaille la chronologie des événements qui ont conduit l'équipe à devoir arrêter en urgence leurs principaux serveurs le 28 août dernier à la suite de la découverte de la compromission d'un serveur tiers. L'analyse a été quelque peu complexifiée par l'effacement de tous les journaux sur cette machine, mais cela n'a pas empêché les enquêteurs de reconstituer la succession d'événements.

Pour faire court, l'attaquant a tiré profit d'une vulnérabilité connue mais non encore corrigée sur un serveur secondaire pour acquérir les privilèges du compte 'root'. Il a pu ainsi détruire les fichiers de journalisation mais aussi accéder à la clef SSH du compte non privilégié utilisé pour effectuer les sauvegardes. Il lui a alors été possible de se connecter sur l'un des serveurs de production puis d'utiliser l'infrastructure d'administration en place pour automatiser le déploiement de ses propres scripts CGI sur les serveurs WEB accessibles de l'Internet. Ces scripts lui ont alors permis d'obtenir un accès interactif - Remote Shell dans le jargon - sur ces serveurs.

En pratique, l'utilisation d'un parc hétérogène de systèmes d'exploitation (CentOS, FreeBSD et Solaris 10) a quelque peu complexifié la tâche de l'attaquant. Ne pouvant attaquer les systèmes FreeBSD et Solaris de front, n'ayant ni à sa disposition les codes d'exploitation ad’ hoc ni probablement la connaissance requise de ces systèmes, l'attaquant s'est vu obligé de contourner l'obstacle. Il a fort astucieusement résolu le problème en utilisant le mécanisme de réplication 'rsync', mis en place par les administrateurs, pour transférer sur les systèmes cibles des scripts pouvant être exécutés depuis un accès public, un serveur WEB.

Le rapport commis par l'équipe d'administration met en lumière les points forts et les points faibles de l'infrastructure actuelle. Les enseignements qu’ils ont tiré de cette ‘aventure’ ont été immédiatement mis à profit pour corriger les défauts et améliorer le niveau de sécurité.

Je reste pour ma part admiratif devant le travail accompli pour remettre en ligne une infrastructure intègre en jonglant avec des exigences contradictoires: réduire au minimum le temps d’indisponibilité et préserver les éléments nécessaires à la reconstitution des événements. Ainsi, le rechargement d’une configuration antérieure à la compromission permet de remettre en ligne avec un minimum de temps de latence un système tout en détruisant irrémédiablement les éléments de preuve qui pourraient s’avérer utiles une fois le calme revenu.

Dans le cas présent, l’équipe d’administration a eu de la chance: l’un des serveurs WEB n’était pas accessible lors de l’attaque. Bien que les scripts aient été transférés, ceux-ci n’ont jamais pu être exécutés. N’ayant pas été compromis, ce système a été rapidement restauré dans une configuration valide à partir d’une sauvegarde de la veille puis remis en ligne pour minimiser le temps d’indisponibilité et informer le public. L’équipe a alors pu se consacrer à plein temps à l’investigation des autres systèmes.

Et au cas où vous vous poseriez la question de savoir quel système d'exploitation j'utilise personnellement, je vous propose ci-contre un indice trivial: