Arrêtez de grogner avec GRR Rapid Response !

Au milieu des systèmes actifs de protection comme les firewalls, IDS ou antivirus et des outils de forensiques « passifs » tel que dd, IDA ou les journaux systèmes, nous trouvons les agents de réponse à incident dits de type « Mandiant ». Dans cet article, nous allons nous intéresser plus particulièrement au logiciel open source de Live-Forensics : GRR Rapid Response [1], après l’introduction nous verrons l’installation, le déploiement sur quelques clients et la manière d’utiliser les principales fonctions proposées grâce à quelques exemples typiques.

Et pour information, « GRR » dans le nom du logiciel n’est pas un acronyme, mais bien l’onomatopée « Grrr ».

1. Présentation

Il y a quelques années, le projet a été initié par Google et a rapidement eu des contributeurs dans d’autres grandes entreprises. GRR est un framework, pas une solution ou un produit sur étagère : il a pour vocation de fournir des briques à assembler pour répondre à votre besoin, pas d’y répondre directement. Et il est entré dans une phase de maturité, ou au moins de popularité.

Il fonctionne en mode client-serveur avec un agent actif sur les machines surveillées, mais cet agent n’a pas de rôle de protection comme un antivirus. Il sert plutôt à piloter des actions sur les machines, par exemple, à la recherche d’indicateurs de compromission. Il permet d’étendre les capacités de surveillance des équipes de sécurité qui sont souvent cantonnées à la surveillance du réseau et des logs centralisés du SI, ces derniers étant intégrés dans des systèmes de collecte de logs comme Splunk [2], StackELK [3], Graylog [4] ou bien LogRhythm [5].

Ces systèmes d’analyse de logs fonctionnent très bien, mais sont souvent inadaptés pour certaines recherches. Par exemple, la recherche d’un fichier sur toutes les machines du parc (nom, chemin, hash) ou le test de présence d’une clé de registre particulière sont des actions délicates à réaliser depuis une plateforme centralisée. Et pourtant, c’est typiquement ce que nous voudrions faire après l’analyse d’un malware et la déduction des marqueurs dont la présence est à contrôler l’ensemble du parc. Voilà un cas parmi d’autres auxquels GRR répond, car la présence de l’agent sur le poste permet de piloter ce dernier pour qu’il fasse automatiquement la recherche sur les postes et renvoie les résultats vers le serveur.

1.1 Fonctionnalités

Pour commencer, voici un résumé des principales fonctionnalités de GRR :

• compatible Linux, Mac OS X et Windows pour les agents ;
• analyse et collecte de la mémoire RAM à distance ;
• recherche et téléchargement de fichier et de clés de registre à distance ;
• recherche sur l’ensemble des machines d’un parc ;
• infrastructure évolutive capable de gérer des parcs de machines importants ;
• fonctionnement en mode asynchrone, planifié ou synchronisé ;
• distribution open source sous licence Apache.

Toutes les fonctionnalités sont disponibles dans le Readme [6] du projet. Pour ceux qui veulent aller plus loin, il y a quelques publications [7] sur le projet référencées sur le site.

1.2 Architecture

Une architecture GRR est composée de différents services :

• Clients : machines ayant l’agent GRR installé, ils communiquent avec le ou les serveurs FrontEnd via des requêtes HTTP-POST chiffrées.
• Serveur FrontEnd : serveurs qui gèrent les communications avec les clients, en particulier le chiffrement et le prétraitement des données (dépaquetage) ainsi que l’envoi d’instructions demandées par un administrateur.
• Data-store : service fournissant le stockage central nécessaire à l’ensemble des composants de GRR. Il utilise le modèle de données AFF4 [8], un format de données dédié à la forensique.
• Workers : réalisent le traitement des données reçues par les serveurs FrontEnd. Ce qui permet de limiter la charge de ces derniers. Les workers s’occupent également de la gestion des files de tâches demandées et de leur routage. Enfin, le traitement de certains résultats peut être confié à des workers spécialisés (par exemple pour certaines tâches : logiciel d’analyse spécifique, présence d’une puce cryptographique, connectivité réseau plus importante).
• Console GUI et CLI : C’est l’interface d’administration qui permet de réaliser les analyses forensiques. Il est possible d’utiliser la console web, mais un ensemble de commandes Shell « grr_ » est également fourni.

Tous ces services sont indépendants et peuvent donc être installés sur une même machine ou répartis sur différentes machines. Cette évolutivité permet à GRR d’être utilisé à très grande échelle, ou en mode test avec tous les composants sur un seul serveur comme dans cet article.

2. Installation de GRR Rapid Response

Pour l’installation, un simple « montez donc un docker ! » est suffisant, mais un « build from source », plus complexe à réaliser, est aussi possible. Pour cet article, par souci de simplicité, nous avons préféré utiliser le script d’installation fourni par le projet et qui permet d’avoir une installation « en dur » simplement. Tout cela est bien documenté dans le Quickstart [9] avec quelques compléments dans le manuel d’administration [10].

2.1 Prérequis

Il faut être root sur le serveur et les postes clients. La procédure d’installation ci-dessous est valable pour la version 3.1.0.2 de GRR Rapid Response sur un serveur Ubuntu « Xenial Xerus » 16.04 - 64bits.

2.2 Déploiement du serveur

Pour installer un serveur GRR, il faut récupérer, puis exécuter le script d’installation du projet et répondre aux questions ou saisir les informations demandées (mail de l’administrateur, mot de passe, etc.) pour terminer l’installation :

Il est aussi possible de lier votre installation issue du script avec la dernière version disponible dans GitHub pour bénéficier des dernières mises à jour, pour cela suivre Installing GRR server for dev, i.e. tracking HEAD [11] dans la documentation.

Si vous avez lu la FAQ [12] vous avez noté que le seul OS officiellement supporté pour le serveur GRR est Ubuntu 16.04. Il est tout à fait possible d’installer GRR sous d’autres distributions comme Debian ou CentOS, au prix de quelques patchs dans le script d’installation, et surtout en renonçant à l’aide de l’équipe du projet en cas de difficultés.

2.3 Démarrer le serveur GRR

Le serveur GRR démarre automatiquement à la fin de l’installation, et se gère comme un service classique :

Pour obtenir plus d’informations sur l’exécution, il est possible de lancerchaque composant de GRR en mode verbeux, par exemple en tâche de fond avec la commande screen :

Vous n’avez plus qu’à ouvrir un navigateur vers http://<serveur-grr>.<domain.tld>:8000/ pour avoir accès à l’interface de GRR (après avoir saisile mot de passe).

2.4 Déployer les agents

Pour que GRR fasse son travail, il faut que des agents lui envoient des informations à analyser. Il faut télécharger ces agents dans l’interface : Manage Binaries > Executables > Windows > Installers. Il suffit de cliquer pour télécharger l’exécutable, puis d’installer l’agent sur les systèmes souhaités. Et voici comment l’installer sous Linux et Windows.

2.4.1 Linux Debian

Pour déployer l’agent sur une machine Debian, placez le paquet (.deb) sur le client et exécutez simplement :

Ensuite, il suffit de vérifier que l’agent est actif à l’aide de la commande suivante :

Par défaut, vous trouverez les fichiers de configuration de l’agent dans :

Les logs de l’installation se trouvent dans :

2.4.2 Windows

Sous Windows, installez l’agent (.exe) en tant qu’administrateur local sur les postes à intégrer dans votre infrastructure Grr. L’installation se fait de manière silencieuse, vous pouvez vérifier le bon fonctionnement de l’agent à l’aide des commandes PowerShell :

Par défaut, l’agent Grr s’installe dans le dossier suivant :

Dossier où se trouve le fichier de configuration de l’agent : GRR.exe.yaml.

Il y a aussi quelques données dans le registre :

Enfin, les logs du client sont dans :

Tous ces éléments (noms des exécutables, chemins, registre) sont modifiables, mais cela exige de reconstruire ou repackager le binaire du client.

2.4.3 Dans la console

Pour les tests, nous avons installé l’agent sur une machine virtuelle Debian 8 et quatre postes Windows : 7, 10, 2008R2 et 2012R2. Si nous lançons une recherche dans la console, les machines apparaissent bien dans l’interface :

2.4.4 Désinstaller un client

Et donc, pour ceux qui seraient inquiets… Sous Windows, c’est un peu délicat de supprimer un client, il faut :

• stopper puis supprimer le service "GRR Monitor ;
• supprimer les clés de registre dans :

• détruire le dossier d’installation de l’agent :

• supprimer les logs de GRR dans :

Voir aussi la documentation officielle de désinstallation [13]à ce sujet.

Concernant Linux, c’est plus simple, il suffit de retirer le paquet à l’aide du même utilitaire que pour l’installation :

Ces deux actions ne suffisent pas pour faire disparaître la machine de l’interface, car elle est encore référencée dans le Data-store de GRR. Il pourrait s’agir d’un attaquant qui a réussi à arrêter l’agent, par exemple. Il faut donc encore exécuter les commandes suivantes sur le serveur et plus précisément dans la console GRR :

2.4.5 Personnalisation et obfuscation des agents

Il est tout à fait possible de personnaliser le client pour le dissimuler (obfuscation) vis-à-vis de malwares qui détecteraient le service pour le désactiver ou masquer leur présence à Grr. Rien de spécifique à GRR sur ce point, il suffit d’utiliser les méthodes de configuration des paquets et d’obfuscation de code utilisées par ces mêmes malwares pour masquer la présence de vos clients GRR. Il semble que ce soit indispensable avant de déployer à grande échelle des agents, vous trouverez un peu de documentation dans le manuel d’administration du projet [14].

Pour conclure, si vous voulez une méthode d’administration simple de Grr : ce n’est pas la philosophie de l’outil en l’état actuel. Avant de mettre GRR en production sur un parc de plusieurs milliers de machines, il y a un peu de travail pour préparer le tout… Comme annoncé, GRR est un framework et pas une solution clé en main.

3. Forensiques avec GRR Rapid Response

Nous voilà, enfin, dans le vif du sujet : « qu’est-ce qu’on peut faire avec GRR ? ». Il est conseillé de lire le manuel utilisateur [15] pour une réponse plus exhaustive. Pour l’instant, nous avons la version de base de l’agent GRR, aucun driver mémoire installé, pas de script arbitraire intégré ou de configurations spécifiques. Voyons déjà ce qu’il est possible de faire avec l’outil.

3.1 Parcours et collecte du File-System

GRR permet de parcourir et collecter le système de fichiers des OS avec l’agent installé. Pour cela, il faut procéder en deux étapes :

• demander à l’agent de lister récursivement le système de fichiers ;
• télécharger un fichier particulier.

Dans la pratique, il suffit de cliquer sur une des machines dans la fenêtre de recherche précédente, puis dans la barre de menu à gauche : BrowseVirtualFilesystem.

Pour ceux qui feront le test, à ce moment : seules les racines des partitions (type C:\, /home ou /var) sont visibles et pas tout le système de fichiers, pourquoi ? Simplement parce que l’agent ne fonctionne pas en direct, mais avec un cache local sur le serveur, il faut donc lui faire rafraîchir les informations sur cette machine.

Pour cela, utilisez les boutons Refresh en haut à droite dans l’interface. Il suffit ensuite de naviguer et de rafraîchir au besoin. Soyez patient, car lister et analyser récursivement sur plusieurs niveaux les fichiers d’une machine peut prendre du temps !

Ensuite, pour récupérer un fichier sur la machine, il faut se déplacer dans l’arborescence jusqu’au fichier choisi et cliquer sur Get a new Version dans l’onglet Download. Cela va demander à l’agent d’envoyer au serveur une version du document qui sera conservée en cache. Une fois cette action effectuée, un nouveau bouton Download apparaît pour vous permettre de télécharger le fichier depuis le serveur.

C’est une fonctionnalité pratique pour récupérer rapidement les fichiers suspicieux sur le parc et par exemple les injecter dans un logiciel d’analyse dynamique de malwares comme Cuckoo [16].

Pour terminer, nous vous conseillons d’aller regarder l’onglet Stats qui va donner beaucoup d’informations, en particulier les valeurs des différents hashs (MD5, SHA1, SHA2) des fichiers. Cette fonctionnalité permet de faire des recherches d’indicateurs de compromission basées sur des hash de fichiers. C’est assez compliqué à mettre en œuvre sans des solutions comme GRR. Nous vous conseillons au préalable de lire l’article Hashing : The Maslow's Hammer of Forensics [17] sur le sujet des recherches de hash avec GRR.

3.2 Flux et dump mémoire

Vous avez peut-être noté que toutes les actions réalisées dans l’interface jusqu’ici lancent des « flows ». En fait, l’interface nous a permis de simplifier la création d’un flow pour la collecte des fichiers. Nous pouvons lancer des flows pour des recherches plus ciblées à l’aide de Startnew flows. Les flows sont triés par catégories et il suffit ensuite d’exécuter celui qui nous intéresse. Il est possible par exemple de faire des recherchesspécifiques : sur des critères de taille, date, ou extensions. Il y en a un pour récupérer l’historique de navigation Chrome (exemple ci-dessous), cela peut être utile si le trafic web chiffré ne fait pas l’objet d’une interception SSL.

Autre exemple, MemoryCollector fait collecter à l’agent une image de la mémoire du client à l’aide du driver Rekall [18], toujours pratique pour vérifier qu’un Malware ne s’est pas niché dans la RAM et, encore une fois, pas évident à faire rapidement sans un agent GRR installé sur le poste. Vous trouverez tous ces résultats dans Manage launched flows.

3.3 Artefacts

La définition d’artefacts en forensique, pourrait être ramenée à celle de Wikipédia : « Un artéfact ou artefact est un effet (lat. factum) artificiel (lat. ars, artis). Le terme désigne à l’origine un phénomène créé de toutes pièces par les conditions expérimentales, un effet indésirable, un parasite. Le mot désigne aussi de manière générale un produit ayant subi une transformation, même minime, par l’homme et qui se distingue ainsi d’un autre provoqué par un phénomène naturel. ». Plus exactement en forensique informatique ce sont les éléments qu’il faut collecter (fichiers, clés de registre, crontab, éléments mémoire, journaux de logs) pour la recherche d’indices de compromission dans le cadre d’un incident de sécurité.

GRR permet de charger des définitions de ces artefacts dans l’interface via des fichiers « yaml » pour les utiliser ensuite comme base pour les flots de recherche. Cela permet d’avoir un modèle de définition complètement industrialisé pour les données à chercher et collecter, et de gagner un temps précieux dans l’analyse des informations, en cas d’incidents.

ArtifactRepository fourni par le projet ForensicArtifacts [19] est une base open source compatible avec GRR. Il est donc possible de charger directement les fichiers « yaml » fournis dans Configuration > Artifact Manager et utiliser ces derniers comme des templates pour les collectes.

3.4 Hunt : La chasse est ouverte

La dernière fonctionnalité du logiciel abordée dans cet article est la chasse aux marqueurs. Jusqu’à présent nous nous sommes concentrés sur des recherches ou analyses particulières sur un poste. Mais GRR permet surtout d’industrialiser ces recherches sur tout un parc informatique. À titre d’exemple, la documentation du projet donne des spécifications pour des infrastructures gérant jusqu’à 32 000 clients.

Pour ce genre de configuration, il faut pouvoir définir des recherches que tous les clients (ou un sous-ensemble) vont faire. La partie « Hunt » répond à ce besoin. Au niveau du fonctionnement dans l’interface, c’est exactement la même chose que de définir un flow, sauf qu’il faut rajouter le périmètre des machines concernées, faire la recherche (filtré par OS, label, expression régulière, etc.) et une période de validité pour la recherche.

En revanche, les hunts diffèrent des flows par leur mode de fonctionnement. Pour les flows, le serveur contacte le client pour lui signifier une tâche. Dans le cas des hunts, ce sont les clients qui, en se connectant régulièrement au serveur, récupèrent les informations sur les tâches qu’ils doivent réaliser.

Conclusion : usages, maturité et pour aller plus loin

Pour conclure cet article sur GRR Rapid Response, nous espérons vous avoir montré l’intérêt et les nombreuses capacités de ce type de solution. GRR ne réinvente rien en forensique, il existe en effet des solutions individuelles pour réaliser à la main chaque fonction isolée que GRR permet de faire. Mais pouvoir industrialiser et automatiser l’ensemble de ces mécanismes, en direct, sur un parc hétérogène de milliers de machines (géographiquement dispersées) est un énorme avantage dans les outils de sécurité qui permet aux équipes de réagir rapidement en cas d’incident.

Ceux qui auront poussé l’exercice jusqu’à installer un serveur auront constaté qu’il existe quelques défauts, bugs et fonctionnalités absentes dans le logiciel, mais les fonctionnalités s’ajoutent de mois en mois via le modèle open source du projet. Le service se stabilise et si vous êtes prêt à y investir un peu de temps GRR pourra répondre exactement à vos besoins de « Live-Forensics ».

Enfin, pour ceux qui veulent aller plus loin, Nous vous invitons à vous pencher sur l’utilisation en ligne de commandes qui n’a pas été abordée, et qui permet d’étendre les capacités de l’outil, comme demander aux agents d’exécuter un programme python par exemple.

Remerciements

Un grand merci à mon laboratoire pour leurs relectures attentives et également à Catherine pour son implication.

Références

[1] Page GitHub du projet GRR : https://github.com/google/grr

[2] Site officiel de Splunk : http://www.splunk.com/

[3] Site officiel de Stack ELK : https://www.elastic.co/webinars/introduction-elk-stack

[4] Site officiel de Graylog : https://www.graylog.org/

[5] Site officiel de logrhythm : https://logrhythm.com/fr/

[6] README du projet : https://github.com/google/grr/blob/master/README.md

[7] Diverses publications référencées par le projet :
https://github.com/google/grr-doc/blob/master/publications.adoc

[8] Documentation Advanced Forensic Framework 4 : http://forensicswiki.org/wiki/AFF4

[9] Guide démarrage rapide GRR : https://github.com/google/grr-doc/blob/master/quickstart.adoc

[10] Manuel de l’administrateur GRR : https://github.com/google/grr-doc/blob/master/admin.adoc

[11] Installation avec GIT : https://github.com/google/grr-doc/blob/master/installfrompip.adoc#installing-grr-server-for-dev-ie-tracking-head

[12] Foire aux Questions GRR : https://github.com/google/grr-doc/blob/master/faq.adoc

[13] Désinstallation de l'agent :
https://github.com/google/grr-doc/blob/master/user_manual.adoc#uninstalling-the-agent

[14] Customiser le client :
https://github.com/google/grr-doc/blob/master/admin.adoc#customizing-the-client

[15] Manuel de l’utilisateur GRR : https://github.com/google/grr-doc/blob/master/user_manual.adoc

[16] Projet Cuckoo SandBox : https://www.cuckoosandbox.org/

[17] Hashing : The Maslow's Hammer of Forensics :
https://grr-response.blogspot.fr/2015/05/hashing-maslows-hammer-of-forensics.html

[18] Projet Rekall : http://www.rekall-forensic.com/

[19] GitHub du projet ForensicArtifacts : https://github.com/ForensicArtifacts/artifacts