S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 23 novembre 2012
N° CERTA-2012-ACT-047
Affaire suivie par: CERT-FR
le 23 novembre 2012

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité CERTA-2012-ACT-047

Gestion du document

Référence CERTA-2012-ACT-047
Titre Bulletin d’actualité CERTA-2012-ACT-047
Date de la première version 23 novembre 2012
Date de la dernière version 23 novembre 2012
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 Compromission de serveurs de FreeBSD

Le week-end dernier, le site freebsd.org a annoncé avoir détecté une intrusion sur son infrastructure. L’attaque aurait eu lieu le 19 septembre 2012, mais n’aurait été détectée que le 11 novembre 2012. Elle serait due à la fuite de la clef SSH d’un développeur.
La base du projet FreeBSD, c’est-à-dire le noyau, les bibliothèques système, le compilateur, les outils en ligne de commande et les démons tels que ssh et sshd, n’aurait pas été touchée. En revanche, le service distribuant les logiciels tiers aurait été ciblé par cette attaque. Il y a donc un risque significatif que ceux-ci aient été modifiés durant la compromission.

Par conséquent, tout système FreeBSD contenant des applications tiers, mises à jour entre le 19 septembre 2012 et le 11 novembre 2012, doit être considéré comme potentiellement compromis. Le CERTA recommande donc de réinstaller complètement le système d’exploitation des machines se trouvant dans ce cas de figure. Suite à cet incident, le système de mise à jour csup/CVSup a été rendu obsolète. Il est donc fortement conseillé de migrer vers portsnap ou subversion.

Documentation

Annonce officielle de FreeBSD :

http://www.freebsd.org/news/2012-compromise.html

2 Rootkit noyau injecteur d’iframes

La semaine dernière, un administrateur de serveur Web sous Linux, qui enquêtait sur la présence d’iframes malveillantes injectées dans les pages a découvert que cette injection était réalisée par un module noyau intégrant des fonctionnalités de rootkit.

Ce module est capable en effet d’intercepter les communications réseau au niveau du noyau linux pour modifier les pages HTML renvoyées aux clients. Le code malveillant ajouté peut être reconfiguré par un serveur de contrôle et de commande distant. Les fonctionnalités de rootkit du malware permettent au module de camoufler au système utilisateur certains de ses processus et fichiers de travail. Enfin, la pérennité du malware est assurée par un mécanisme qui force le rechargement du module malveillant à chaque redémarrage du système. La particularité de cette méthode, originale pour ce type d’attaque, est qu’aucun fichier n’est modifié dans le site Web. Seuls quelques fichiers aux noms « anodins » sont présents dans l’arborescence, et sont masqués aux administrateurs par les fonctions de rootkit. Bien que ce malware ne révolutionne aucune technique de compromission, il montre qu’il est nécessaire de mettre en place des mesures de sécurité particulières aux serveurs de production sous Linux. Par exemple le blocage de chargement de modules noyau à chaud aurait empêché l’attaquant d’ajouter son module malveillant. Il suffit pour cela d’écrire 1 dans /proc/sys/kernel/modules_disabled. Cette mesure est décrite dans le document Recommandations de sécurité relatives à un système GNU/Linux disponible sur le site de l’ANSSI.

Documentation

3 Le cloisonnement se démocratise sous Linux

Cette semaine, le cloisonnement (sandboxing) sous Linux s’est renforcé avec la sortie d’une nouvelle version du navigateur Chrome. La particularité de cette version, est l’intégration de nouveaux mécanismes de cloisonnement basés sur une fonctionnalité du noyau Linux appelée « seccomp-bpf » (Secure Computing Berkeley Packet Filter).

Pour rappel, le cloisonnement (sandboxing) limite les possibilités d’action et restreint les privilèges d’un processus. Le but de cette fonctionnalité est de limiter les dégâts d’une éventuelle exploitation de vulnérabilité dans un processus utilisateur.

La fonctionnalité « seccomp-bpf » est apparue dans le noyau Linux le 11 Janvier 2012. Le langage BPF (Berkeley Packet Filter) initialement conçu pour mettre en place des filtres sur les paquets réseau a été adapté au cloisonnement de processus avec « seccomp ». Au lieu de faire des vérifications et des opérations sur les paquets réseau, le langage BPF pour « seccomp » permet de les faire sur les registres processeur. Cela permet de faire des traitements fins au niveau des appels système. Un exemple concret est par exemple de limiter l’appel système « __NR__read » seulement sur le descripteur de fichier « stdin ».

Cette fonctionnalité n’est disponible qu’à partir des noyaux Linux version 3.5, mais a été intégrée dans la version 12.04 LTS de Ubuntu.

De plus en plus de programmes sous Linux commencent à utiliser cette fonctionnalité, on peut citer des logiciels comme vsftpd, OpenSSH. En ce qui concerne Mozilla Firefox, une équipe travaille sur ce sujet, on peut donc s’attendre dans une prochaine version à une évolution vers cette technologie.

Le CERTA recommande l’utilisation de programmes stables utilisant des concepts de cloisonnement et encourage les développeurs à cloisonner leurs applications en espace utilisateur.

Documentation

Rappel des avis émis

Dans la période du 12 au 18 novembre 2012, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 23 novembre 2012
    version initiale.