La troisième réunion toulousaine de l'OSSIR se tenait à l'ONERA le 27 mai dernier. Beaucoup de monde à cette réunion (une cinquantaine de personnes) certainement grâce au thème très fédérateur de la détection d'attaques et d'intrusions.
Au menu, supervision des intrusions réseaux (IDS et analyse de log, par Y FOURASTIER - XP conseil) et Analyse de compromission sur UNIX (P Bourgeois CERT-IST). Avant cela, une courte présentation permettant de faire un tour d'horizon sur l'actualité sécurité nous a été présentée par Fabrice Prigent.
Le nombre de compromissions sur RENATER, depuis le début de l'année est en diminution, les scans sont à plus de 70% sur les services HTTP, avec une augmentation des scans lents (4 machines par jour). Inversement, on constate une augmentation des tentatives d'intrusion via MS SQL (7%, puis 15% semaine suivante). Dans tout les cas, la première motivation reste la recherche d'espace de stockage pour WAREZ (21% de ftp).
Au niveau des virus : 84% KLEZ, 11% SIRCAM, 2% HYBRIS
Ce tour d'horizon a continué avec quelques détails sur certaines failles ou virus. En premier lieu, MS SQL, qui par défaut ne place pas de mot de passe sur le compte SA (patch disponible). On tente l'authentification par le port 1433. Parade : bloquer le port 1433, et mettre un mot de passe sur le compte SA.
Virus KLEZ, qui se propage par fichier et par réseau (VER), découvert le 17 avril 2002 (dernier variant KLEZ-i), où le nom de l'expéditeur des messages SMTP est choisi dans le carnet d'adresse de la personne infectée. Il utilise comme beaucoup un serveur SMTP embarqué, et il désactive l'antivirus. Enfin, il détruit certains documents (change en fonction de la version ).
Deux programmes ont attiré l'attention, avec en premier un nouveau rootKit, découvert en janvier de cette année, nommé Optic kt (tux), ainsi qu'un programme de simulation de réseaux, simulant plusieurs réseaux avec des serveurs de plusieurs OS.
On trouvera la dernière version sur www.citi.umich.edu/uprovos/honeyd; L'auteur PROVOS, n'en est pas à sa première tentative puisqu'il avait déjà travaillé sur Dsniff (sniffeur de mot de passe). Enfin, on trouvera également une base de données de scan en ligne www.dshied.org qui indique si un site a été ou non scanné récemment (il semble qu'il ait cependant quelques petits problèmes de base de données ces temps-ci).
XP Conseil a fait une présentation générale concernant la détection d'attaques et d'intrusions et c'est plus particulièrement attaché a présenter les grandes fonctionnalités de IDS et SNORT.
Les aspects à prendre en compte pour les traces sont : la centralisation, la consolidation, agrégation, corrélation (maturité faible, peu d'outils) des logs, ainsi que l'usage des consoles de supervision.
IDS (système de détection d'intrusion) se scindent en deux familles qui sont : les NIDS (Network IDS) et les HIDS (pour host). La tendance va à la fusion des deux familles. Les systèmes IDS permettent de reconnaître les tentatives d'intrusions mais également dans certains cas de les bloquer dynamiquement.
Les seules actions indiquées sur l'implantation de ces outils, consistent à mener au préalable une étude de sécurité de manière à définir et hiérarchiser les zones de sécurité, ainsi que de faire attention aux dégradations de performances des serveurs hébergeant les HIDS.
La problématique des environnements switchés a également été posée pour les NIDS (en environnement micro segmenté, une sonde ne vois rien) sans pour autant y apporter de solution concrète (on aurait pu parler également de la charge CPU sur les switchs, de la recopie de port, des problèmes liés aux VLAN, ou encore des solutions liées à SMON).
C'est un produit mature avec plus de cinq ans d'existence, qui serait à classer dans la catégorie des NIDS tendant à fusionner fonctionnellement avec le HIDS (prévu pour la fin de l'année).
Basé sur un jeu de règles composés d'un header qui correspond à l'instanciation de filtrage, et d'options qui correspondent à l'action, il n'est pas limité à la simple gestion de génération de log, car il permet d'utiliser des plug-in. Ces derniers permettent d'enrichir les actions possibles, mais également les critères déclenchant ces actions.
Même si le produit est mature en terme de fonctionnalité, il est important de ne pas le considérer comme un produit sur étagère, car il reste délicat à implanter et à paramétrer.
Monsieur Bourgeois a traité dans cette présentation la problématique de l'audit d'une machine compromise, et a eu l'excellente idée d'étayer son discours par plusieurs manipulations en direct depuis son portable.
La démarche n'est pas ici de gérer l'incident au moment de la compromission, mais bel et bien de réaliser un travail à posteriori devant permettre éventuellement d'aboutir à des poursuites judiciaires.
L'objectif du CERT-IST pour ce type de travail peut se scinder en trois points :
Il faut cependant garder en mémoire que la machine peut être piégée, et qu'il est important de ne pas altérer les données du système (un ls change la date du dernier accès au fichier du dossier courant). C'est pour cela que l'étape préliminaire consistant à capturer l'état du système en analysant les données depuis une autre machine est indispensable.
Pour cela, le CERT utilise son propre kit binaire d'investigation pour les machines piégées (sur CDROM, ou dans des cas moins sensibles téléchargé sur la machine compromise). Il consiste en un jeu de commandes Unix saines, qui seront les seules à être utilisées sur la machine compromise. Dans la panoplie, on trouve également un portable depuis lequel, à travers le réseau, on accèdera à la machine à investiguer.
Enfin, il est intéressant d'avoir une machine de référence proche de la machine à investiguer (même version d'OS, de patch, d'architecture), surtout utile si on n'a pas mis en place d'outils de vérification d'intégrité du type de trip wire (permettant de stocker une signature pour chacun des binaires systèmes de la machine, en vue d'en valider l'intégrité, et de découvrir, après compromission quels binaires ont été modifiés).
Le piège le plus classique consiste à installer un ensemble de binaires et/ou librairies dynamiques qui empêche l'administrateur de la machine de connaître l'état réel de la machine. Le plus simple d'entre eux correspond à la modification de la commande ls pour que les fichiers du pirate n'apparaissent pas. Il existe des ensembles de binaires pirates entièrement packagés, entièrement paramétrables pour chaque système, sur Internet, ce sont les rootkits.
Les rootkits les plus évolués n'usurpent pas seulement des commandes, mais également des modules dynamiquement chargés (LKMM lodable kernel module malicieux). Il sont plus difficiles à détecter et surtout à contourner sans changer l'état de la machine compromise.
Enfin, il faut également faire attention au mécanisme d'autodestruction permettant au pirate d'effacer le maximum d'indices en cas de découverte. Le cas le plus courant consiste à rajouter un process qui vérifie la connexion au réseau de la machine. Si le réseau vient à être coupé, alors le mécanisme d'effacement est lancé.
Il faut toujours cependant garder à l'esprit que les données collectées peuvent être incomplètes ou fausses. Un recoupement par plusieurs méthodes doit donc être systématisé pour ne pas tomber dans un piège non encore connu.
La deuxième partie de cette présentation nous a permis de mettre en application les éléments précédemment énoncés, ainsi que de voir certaines méthodes de plus près.
On commence par noter l'écart entre la date et l'heure du poste corrompu et celle du portable d'investigation (qui doit lui, être à l'heure). Cela est nécessaire afin de permettre de ne pas se tromper dans la détermination de l'heure de compromission.
Ensuite, on va récupérer les trois dates associées à chaque fichier de la machine compromise (en prenant bien soin d'utiliser un outil ne modifiant pas la date de dernier accès comme l'outil graverobber -m)
Suivent la récupération des informations volatiles (Informations que l'on perd si on éteint la machine), comme les process en cours d'exécution ou les connexions réseau en cours, etc . (ps, netstat, ifconfig, isof).
On en profite pour capturer également le résultat des commandes natives (détection de rootkit) avec un diff entre ces commandes et les commandes venant du CDROM, ce qui permet de détecter les données que le pirate ne souhaite pas divulguer.
Enfin, on cherche à faire une copie physique des partitions des disques (ce qui n'est pas toujours possible pour des raisons de taille. Dans ce cas, on copiera en priorité les répertoires / et /var /swap /etc . , soit en fait les zones système).
A partir de là, plusieurs démarche sont possibles . La plus rigoureuse (ce qui ne veux pas dire la plus sûre) consiste à procéder à une analyse systématique, soit à base d'outils de contrôle d'intégrité, soit à l'aide d'une machine de référence saine.
Une autre approche également utilisée consiste à trouver des anomalies système. Un examen minutieux des logs est alors indispensable, dans la mesure ou ils n'ont pas été effacés ou altérés (en changeant la date de manière à avoir des saut de date par exemple). Les outils de supervision, utiles pour détecter l'attaque ne sont par contre, plus d'une grande utilité dans ce type d'analyse.
Une des méthodes donnant de bon résultat correspond à l'analyse fine des date associées aux fichiers et répertoires. Ces dates sont au nombre de trois pour chaque fichier sous Unix :
A partir de cette information, il est possible d'aller chercher les fichiers temporaires ou directement le fichier d'échange en cherchant par exemple une entête telnet avec la date et l'heure d'utilisation ainsi trouvées.
Il est également possible d'envisager de récupérer certain fichiers effacés sous certaines conditions. S'il est assez simple sous Linux (avant la version 2.4.2) de le faire , cela reste beaucoup plus complexe dans tout autre environnement Unix. Il existe cependant des outils permettant d'obtenir une aide précieuse dans cette recherche souvent laborieuse.
Enfin, la prochaine génération de rootkit s'annonce déjà beaucoup plus complexe à analyser. Il ne s'agit plus de programme exécutable corrompu, mais bel et bien de fichier spéciaux voire de portion de noyau qui pourrait être modifiée au profit de pirates . Ainsi, une gestion du système de fichier corrompu masquerait certains fichiers même en utilisant des commandes ls saines .
Une autre tendance correspond à la démocratisation de rootkit 'pour les nuls ', ou l'installation et le paramétrage sont complètement guidés , ce qui maximise le nombre de personnes pouvant utiliser ce type d'outils.
Enfin quelques liens utiles :