D'abord, on y découvre la source de la compromission : un serveur Web. Surprenant... Après avoir pris le contrôle total de la machine en utilisant une faille noyau[1] récente, l'intrus a tenté de rebondir sur le reste de l'architecture via SSH. D'abord et en vain via quelques logins/passwords, puis avec succès en utilisant la clé du compte de backup, pour finalement se logger en utilisateur restreint sur le serveur qui héberge people.apache.org. C'est apparemment depuis cette machine que le contenu des sites web Apache est copié pour sa mise en production via un rsync automatique. L'attaquant a donc pu placer par ce biais quelques scripts CGI à la racine du site web principal et les utiliser pour obtenir un shells sur la machine qui l'héberge.

On a pas trop de timeline sur la progression de l'intrus. Tout ce qu'on sait, c'est que la mise en place des scripts CGI a eu lieu le 27 août vers 18h UTC. Une fois le rsync effectué, l'intrus a commencé à les utiliser vers 7h UTC le lendemain. 45 minutes plus tard, les admins détectaient la compromission et prenaient les mesures qui s'imposaient, à savoir mise hors-ligne de tous les serveurs, analyse des traces et mise en place d'une plate-forme en mode dégradée sur quelques machines épargnées en Europe principalement à partir des données saines à disposition.


La partie sur les enseignements de cette compromission est on ne peut plus intéressante. On y découvrira l'intérêt d'un bon système de backup, de la redondance des sites et d'un peu de diversité dans ses installations. Parce que si l'intrus n'a manifestement fait qu'une bouchée du CentOS qui tournait sur le premier serveur compromis, le FreeBSD et le Solaris sur lesquels il est tombé ensuite semblent lui avoir posé plus de soucis pour l'élévation de privilège.

On y découvrera également l'importance de la bonne gestion des privilèges, des accès et des fonctionnalités disponibles, ainsi que des logs. J'ai retenu trois des quatre points noirs évoqués :

  • D'abord la mauvaise restriction des accès permis par la clé SSH du compte de backup. Ce type de clé n'est typiquement pas protégée puisqu'utilisée en général par des scripts. Par contre, elle ne devrait permettre que l'accès au serveur de backup et pour lancer le processus de sauvegarde uniquement. Le fait de pouvoir l'utiliser pour obtenir un shell sur d'autres machines est évidemment un problème.
  • Ensuite, le support des scripts CGI sur l'ensemble de l'hébergement, alors que leur utilisation relèverait plus de l'exception que de la règle. C'est ce qui a permis à l'attaquant de voir du code exécuté à partir d'un site qui ne devrait pas offrir ce genre de fonctionnalité.
  • Enfin, l'absence d'export des logs de la première machine compromise qui empêche toute analyse de l'intrusion initiale. En effet, l'attaquant, qui n'a manifestement rien d'un script-kiddy, a pris soin d'effacer tous les journaux de ce serveur. Ce qui veut dire qu'on ne saura probablement jamais comment il l'a initialement compromis : 0day, faille web, login/password faible, rebond sur un hôte tiers ?

On me fait remarquer qu'on pourra également se demander si le backup se faisait dans le bon sens, et s'il n'aurait pas mieux valu que ce soit le serveur de backup qui vienne établir la connexion SSH plutôt que le contraire...


Si on se prend à vouloir regarder cette attaque dans un contexte un peu plus global, on voit bien comment un serveur manifestement moins bien géré que les autres peut être utilisé avec succès pour pénétrer une infrastructure. Ce qui lève la problématique de la détection des incidents au sein même de cette infrastructure, et pas juste à ses frontière avec le monde extérieur. Et là, comme j'aime à le dire, votre meilleur IDS, c'est votre capacité à surveiller vos plate-formes et extraire des logs qui reviennent toutes ces petites choses inhabituelles qui devraient faire tiquer si elles n'étaient pas noyées dans un flot d'évènements plus anodins. Dans le cas présent, ce serait les échecs répétés d'accès SSH en login/password, y compris sur des comptes qui ne sont accessibles qu'avec des clés, l'ajout de fichiers CGI ou encore la création de processus dans un contexte bizarre.

C'est ce dernier évènement qui a levé le lièvre. Et assez rapidement. Même pas une heure. Ce qui confirme bien ce que je vous disais précédemment, à savoir l'importance du monitoring de l'infrastructure dans la détection des incidents. Et évidemment leur analyse. Je sais bien que c'est un travail de titan et qu'il n'y a pas de recette toute faite, pas plus que de produit sur étagère, pour y parvenir. La mise en place d'une plate-forme de monitoring sécurité demande du temps, des moyens, de la patience et de l'expérience, mais c'est bien la seule chose que j'ai vu fonctionner efficacement, même quand ça ne marche qu'à coups de scripts Perl[2] sur des repositories centraux de logs.


Enfin bon. Si je n'ai pas envie de me moquer, c'est que quand je lis tout ça, que je vois la transparence avec laquelle ils communiquent sur l'incident et la maîtrise qu'ils ont de leur infrastructure[3], je me dis qu'ils gèrent très bien leur affaire. Et puis je ne peux pas m'empêcher de faire la comparaison avec certaines histoires de sites bancaires compromis. Certes le secteur d'activité n'est pas du tout le même, mais tout de même... Les moyens ne sont pas les mêmes, les enjeux non plus, je ne parle même pas des obligations réglementaires...

Notes

[1] D'aucuns affirmeraient que des têtes sont mises à prix :)

[2] En fait, les systèmes à base de scripts que j'ai vus marchaient carrément mieux que les autres...

[3] Par leur capacité à dérouler la pelote des évènements.