'habitude, quand je vous parle de quelque organisation qui vient de se faire compromettre, c'est avec une légère pointe de moquerie. Mais là non. J'aurais certes pu me moquer d'un London council qui s'est récemment fait déchirer par Conficker avec des pertes approchant les cinq cent mille livres. Mais non. Je vais juste vous parler de la compromission des serveurs de la Fondation Apache.
Le 28 août dernier dans la matinée, le site apache.org est devenu inaccessible. On apprendra plus tard dans la journée que c'était dû à une compromission de certains de leurs serveurs. La semaine dernière, un rapport précis, mais relativement succint, a été mis en ligne pour expliquer les tenants et aboutissants de cette incident. Et c'est une lecture diablement intéressante...
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 essayé de rebondir sur le reste de l'architecture via SSH. D'abord et en vain via quelques login/password, puis avec succès en utilisant la clé du compte de backup, pour finalement se logger en utilisateur restreint sur people.apache.org. C'est depuis ce serveur 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 dans 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 cet incident. 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 et mise en place d'une plate-forme en mode dégradée sur quelques machines saines en Europe principalement.
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 lui ont posé plus de soucis.
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 sert qu'à se loguer sur le serveur de backup pour lancer les sauvegardes. Le fait de pouvoir l'utiliser pour se loguer ailleurs est évidemment un problème.
- Ensuite, le support des scripts CGI sur l'ensemble des 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 ?
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 disait 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, 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 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 non plus, 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.