Sysdig et sécurité locale

La détection et la prévention d’intrusion sont revenues à la mode avec les solutions EDR (End-point Detection and Response) des éditeurs, mais quand est-il des solutions libres ? Nous vous proposons de tenter de commencer à faire soi-même sa détection d’intrusion sur une machine GNU/Linux.

Pour cela, il nous faudrait un outil capable de décortiquer les actions menées au niveau du système d’exploitation. Un administrateur système pourrait penser à des logiciels en userland, mais il arrive parfois que ces outils soient limités en termes de détection. Alors que faire ? Écrire un nouveau wrapper ? Modifier la libc ? Et pourquoi ne pas réaliser cette surveillance au niveau du noyau lui-même ? Une idée moins saugrenue qu’il n’y paraît.

1. Surveiller oui, mais depuis le noyau

En surveillant depuis l’espace utilisateur, nous nous heurtons à des limitations. La première est que si le processus de surveillance est lancé avec un compte non privilégié, alors une élévation de privilège de la part d’un utilisateur malveillant permet de contourner le mécanisme. Qu’à cela ne tienne me direz-vous, exécutons notre système de surveillance avec les privilèges root, de cette manière il est possible de surveiller en plus la totalité du système. Certes, mais il reste un grain de sable qui peut gripper cette mécanique bien huilée : un attaquant qui réussit à élever ses privilèges pour devenir root et dépose un rootkit sous forme de module noyau peut alors contourner notre sécurité et se rendre invisible.

Vous l’aurez compris, déplacer la surveillance au niveau du noyau n’est pas une panacée, mais demande à l’attaquant encore plus d’effort pour contourner notre système. Pour mener à bien notre tâche, c’est sysdig que nous avons choisi, d’une part parce qu’il vient sous la forme d’un module noyau, mais ce n’est pas non plus le seul avantage qu’il propose, il est en effet capable de surveiller des sous-systèmes lancés dans des conteneurs.

1.1 Installation et premiers pas

Sur un système Debian, l’installation est très simple grâce aux packages mis à disposition dans la distribution elle-même :

Le package falcosecurity-scap-dkms est utilisé pour la détection en temps réel, il contient le code source des modules noyau nécessaires pour la collecte des données.

Pour vérifier que sysdig est bien installé, en tapant la commande suivante, vous devriez avoir l’ensemble des événements que l’outil peut surveiller. Certains ont une valeur ajoutée pour de la détection de malwares :

Faisons un premier test pour vérifier que tout fonctionne :

Comme vous vous en doutez fortement, nous allons ici capturer les événements liés aux processus dont le nom est « id » et les enregistrer dans le fichier id.scap avec une limite de buffer de 2000 octets.

Une fois la commande id tapée dans un autre terminal, on peut mettre fin au processus sysdig d’un simple ^C et observer le résultat à l’aide de la commande :

Vous noterez que la sortie est très verbeuse, les utilisateurs de strace ne seront pas dépaysés. Voici un extrait de ce que l’on peut voir :

On obtient le PID du processus id lancé, ainsi que le PID du parent et son nom (bash ici), les variables d’environnement liées, mais aussi les différentes bibliothèques chargées et enfin les fichiers ouverts par la commande pour obtenir le résultat escompté, à savoir l’UID de l’utilisateur ainsi que les différents groupes locaux dont il est membre. La sortie compte 411 lignes parmi lesquelles il nous faut trier pour trouver l’information pertinente. Heureusement, sysdig dispose de filtres, essayons donc de nous débarrasser des informations superflues en ne gardant, par exemple, que les fichiers ouverts dans /etc :

La sortie de la commande ne fait alors plus que 122 lignes. C’est mieux, mais il est encore possible de réduire le bruit en sortie de commande, car les informations affichées ne sont pas toutes nécessaires, en particulier nous avons les fermetures de fichiers qui ne nous intéressent pas :

Il est possible d’utiliser une forme plus courte encore, qui sera préférée si jamais les arguments evt.type deviennent plus nombreux :

Cette fois-ci, l’objectif est atteint, nous n’avons plus que 54 lignes dans la sortie de notre commande et l’information utile est lisible.

1.2 Aller plus loin avec les chisels

Vous l’aurez compris, il est possible de jouer sur les conditions pour surveiller des événements bien précis et sortir des informations pertinentes. Bien entendu, écrire des lignes de commandes avec des conditions à rallonge n’est pas viable, sysdig propose donc de charger des scripts prêts à l’emploi. Pour avoir la liste des scripts à votre disposition, tapez :

Vous obtiendrez une liste de scripts utilisables. En ouvrant ces scripts, vous vous rendrez compte que le nom de fichier contient l’extension Lua, ce n’est pas un hasard, les chisels de sysdig sont écrits dans ce langage. Commençons par regarder le fonctionnement d’un chisel simple, celui appelé netstat :

La sortie de la commande vous montrera non seulement les quadruplets IP de destination, port de destination, IP source, port source, mais aussi le processus local qui a initié ou reçu la connexion. Lisons le script en diagonale pour essayer de comprendre ce que fait le chisel et comment :

Nous sommes ici face à des fonctions appelées chacune à leur tour. Par défaut, le chisel netstat va afficher la totalité des connexions, il est possible de passer des arguments sous la forme d’une expression compréhensible par sysdig, comme ce que nous avons vu précédemment. La fonction on_set_arg() est appelée pour permettre cette précision :

La fonction on_init() est la première appelée lors du lancement du chisel, puis vient la fonction on_capture_start() lorsqu’une capture live est demandée. Le traitement et l’affichage des résultats se font dans la fonction on_capture_end(). Quant à la fonction on_event(), elle est utilisée pour filtrer les événements au fur et à mesure qu’ils passent le filtre appliqué dans la fonction on_init(). Dans le cas de netstat, le seul événement qui sera traité est la fin de la capture.

Essayons maintenant un chisel plus orienté sécurité et détection. La CVE-2014-6271, aussi connue sous le nom de shellshock, affecte le logiciel Bash jusqu’à sa version 4.3 et rend possible l’exécution de code en utilisant une vulnérabilité dans le traitement des variables d’environnement. Cette vulnérabilité a été exploitée principalement via des CGI utilisant des scripts shell. Un chisel existe pour détecter une exploitation de shellshock, essayons-le :

Il semblerait qu’une erreur se soit glissée dans le script. Mais nous connaissons le fonctionnement des filtres sysdig ainsi que la structure d’un chisel, cela va donc faciliter la recherche de l’erreur et sa correction. En relisant le filtre écrit dans la fonction on_init() du script, l’erreur saute aux yeux :

Il manque les parenthèses, nous corrigeons donc et cette fois-ci, notre chisel se lance et reste en attente d’un événement qui va le déclencher :

Pour simuler l’attaque, nous allons utiliser un conteneur Docker écrit spécialement pour émuler cette faille :

Une fois notre conteneur construit, nous le lançons et exécutons une commande pour tester et obtenons le résultat escompté  :

Mais rien du côté de la détection, le terminal depuis lequel est lancé le chisel reste muet. C’est donc le moment de lancer sysdig pour déboguer ! Heureusement, nos connaissances fraîchement acquises vont nous permettre de comprendre pourquoi. En faisant tourner sysdig en précisant le conteneur inspecté, l’erreur est compréhensible :

Le filtre sur proc.name n’est pas bon et il faut donc le modifier, ici la nouvelle valeur du filtre dans la fonction d’initialisation sera la suivante :

Ce filtre peut paraître large au premier abord, mais un second niveau de filtrage est réalisé dans la fonction on_event() qui permet d’écarter les faux positifs. Une fois notre chisel mis à jour, nous relançons notre commande de test contre notre conteneur vulnérable et cette fois-ci, nous détectons correctement l’attaque :

Notre test est détecté, mais qu’en est-il d’une « vraie attaque » shellshock, me direz-vous ? Pour le savoir, lançons l’outil Metasploit :

L’attaque est réussie, comme prévu, mais la remontée par sysdig l’est aussi, ce qui nous rassure sur les capacités de détection de notre chisel :

Le lecteur attentif notera au passage que les attaquants ont agi juste avant la pause déjeuner, ne laissant aucun répit aux analystes qui travailleront sur cet incident.

2. Et en production, ça sert à quoi ?

2.1 Choisir la menace contre laquelle se prémunir

De plus en plus, les attaquants compromettent un système pour avoir un pied sur un système d’information, la finalité pouvant être l’exfiltration de données pour ensuite faire du chantage à la divulgation, l’installation de logiciels de minage de cryptomonnaies ou encore le chiffrement des données pour du rançonnage. Nous couvrirons dans le cadre de cet article la détection des logiciels de minage.

Nous avons pour cela à disposition dans sysdig plusieurs armes : la détection de connexions réseau pour le téléchargement du logiciel, mais aussi pour les connexions aux serveurs de pool de cryptominages. Ensuite, nous pouvons mesurer la consommation CPU ou bien l’exécution de certaines commandes.

Depuis déjà quelque temps, la conteneurisation a pris le pas en production et nombreuses sont les infrastructures mises en place à grands coups de docker pull. Mais que se passe-t-il si un dépôt Docker est compromis et que l’attaquant y ajoute une porte dérobée, ou juste un simple cryptominer ? Comment savoir si notre infrastructure est saine ?

Prenons un exemple et téléchargeons volontairement un conteneur exécutant un cryptominer, pour cela nous nous référons à un exemple donné dans l’article de Bleeping Computer [1] :

Le conteneur téléchargé, il est ensuite exécuté :

Maintenant, à nous de trouver comment détecter son exécution !

2.2 Analyser et trouver les bons artefacts

En parallèle dans un terminal, sysdig est lancé avec l’option -w pour enregistrer l’activité du conteneur. Comme indiqué sur la sortie standard de l’outil, des bibliothèques sont utilisées : libuv, libssl, libhwloc. C’est un bon début pour avoir des éléments de détection. En analysant plus en détail, on s’aperçoit qu’un autre point intéressant est l’utilisation par XMRig de la bibliothèque musl. Cette dernière remplace la libc générique et propose une version plus légère qui a été choisie par l’auteur de l’outil. Ce détail a son importance, car il nous permet de trier un peu plus finement encore.

Nous en arrivons à la très élégante (ou pas) commande suivante :

Dès que notre conteneur vérolé est lancé et que xmrig démarre, nous avons alors notre détection des bibliothèques utilisées par xmrig :

Ces éléments pourront ensuite être envoyés vers un SIEM pour être corrélés et créer un incident traité par nos chers analystes. Il est aisé de détecter un logiciel, dès lors que l’on connaît son comportement et sa constitution.

2.3 D’autres méthodes d’analyse ?

Nous ne l’avons pas vu dans notre exemple, mais il est possible de détecter un cryptominer d’autres façons, notamment les connexions aux serveurs de pool. L’outil Falco [2] qui est une surcouche à sysdig permet d’élaborer des règles en utilisant des fichiers de configuration en YAML, et notamment des listes. Vous vous en doutez, avoir des listes d’adresses IP ou de noms de domaines désignant des pools de cryptominage serait un avantage considérable dans la détection de logiciels comme XMRig. De même que des listes d’adresses IP de serveurs de botnet permettront de détecter un comportement suspect sur une machine.

L’article sur le blog du projet sysdig [3] est un bon résumé des capacités de Falco sur ce terrain de jeu. Les listes sont certes déjà à disposition, cela dit il ne faut pas oublier que des attaquants mettront probablement en place des proxys (parfois éphémères) qui eux ne seront pas forcément répertoriés.

Conclusion

Le logiciel sysdig est un outil efficace et qui aidera bien des analystes sécurité à trouver des traces de compromission sur une machine GNU/Linux. À noter qu’il existe sysdig-inspect, application web permettant de surveiller aisément tout un parc, à vous de l’essayer maintenant :).

Références

[1] Article sur les conteneurs Docker infectés Bleeping Computer : 
https://www.bleepingcomputer.com/news/security/docker-hub-repositories-hide-over-1-650-malicious-containers/

[2] Logiciel Falco : http://www.falco.org

[3] Détection de cryptomineurs : https://sysdig.com/blog/detecting-cryptomining-attacks-in-the-wild/