vendredi 27 septembre 2013

Réagir à l'attaque informatique : quelle complexité ?

Source : carnal0wnage.attackresearch.com
L'inspiration de cet article est venu ailleurs alors que l'on m'interrogeait sur la signification du terme "APT" pour "Advanced Persistant Threat" et sa portée. L'acronyme, un peu comme "cyber", a fini par devenir un terme usuel dont le sens n'est pas très clair. On entend parfois n'importe quoi à son sujet comme l'individu qui s'exclame : "ah, j'ai reçu un pdf ...j'ai une APT"...

En premier lieu, il ne s'agit pas d'une maladie mais d'une tentative de synthèse pour un phénomène complexe. L'idée est de représenter les caractéristiques des attaques informatiques "modernes" en insistant sur leurs facettes :

- "Avancées" comme relativement complexes parfois dans leurs aspects techniques, fréquemment dans l'orchestration des actions et la malignité des techniques. On peut également y entendre la prise de contrôle "avancée" d'un réseau avec le gain de privilèges très élevés.

- "Persistantes" car bien souvent, il s'agit, une fois entrée, de durer et de persister en dépit des efforts des responsables légitimes pour vous déloger. La notion de persistance illustre aussi bien gagner le contrôle durablement et en profondeur d'une machine que de l'ensemble d'un réseau.

Pour ma part, c'est ainsi que je le comprends. Effectivement, bien souvent, et comme le rappelle les éléments publics de certaines affaires célèbres, "Bercy" ou "Areva", tout cela commence bien souvent par un acte individuel et anonyme qu'est l'ouverture d'un fichier délibérément piégé et rendu attractif.

Toutefois, pour le profane, le praticien SSI apparaît parfois un peu austère voire légèrement autiste. En bref, il n'est pas illogique de ne pas comprendre ce qu'il en est. En revanche, il est toujours intéressant de savoir quels en sont les enjeux et les solutions trouvées.

Il existe de nombreux soucis dans la gestion de telles attaques. Aujourd'hui, nous en retiendrons principalement un : la détection. Nous pourrons évoquer plus tard, l'assainissement ou la reconstruction ou encore l'amélioration post-incident.

La détection recouvre en réalité deux actions bien distinctes. La première serait l'alerte, c'est à dire la découverte d'une infection initiale ou encore le sentiment que "ça colle plus" ou que "Houston, on a un problème"...La seconde consiste à mesurer le profondeur du problème et à détecter l'ampleur de celui-ci.

L'alerte dépend de nombreux facteurs. Une bonne équipe SSI peut disposer de moyens de recueil d'infos et d'analyse permettant de matérialiser de tels problèmes. Avec de la chance, l'outil de l'attaque pourra faire réagir un ou plusieurs des outils de sécurité que vous pourriez avoir (proxy, IDS, firewall, antivirus). 

Par exemple, si le composant malveillant contacte une adresse connue à l'extérieur, celle-ci peut être repérée grâce à l'usage de liste noire dans un proxy. Ou encore si le motif des flux est repérable, il pourra être détecté par une sonde de détection d'intrusion. Parfois, c'est le comportement de vos équipements qui sera détecté par un autre acteur : "Allo, M. RSSI ? Oui... ? Je suis administrateur sécurité dans la société machin et l'un de vos serveurs est décidément très motivé pour scanner mes ports et trouver des failles !".

Mesurer l'ampleur de l'attaque dépend de plusieurs facteurs. Mais l'idée principale est les acteurs en présence ne disposent pas toujours d'une représentation des systèmes à l'état "sain". Autrement dit, c'est un peu chercher la fameuse aiguille dans la non moins fameuse botte de foin ! Prenons un exemple courant : vous rencontrez un homme très pâle : est-il malade ? est-il doté d'une telle constitution ? A-t-il mangé quelque chose de périmé ? Ou bien ressort-il d'une longue maladie ?

C'est un peu la même idée en fait car la comparaison avec un état sain nécessite de d'abord connaitre cet état : la préparation, et c'est évident, à subir de telles attaques est donc indispensable. Par exemple, lorsque l'analyse détient la liste des comptes dans un annuaire d'entreprise ou encore la liste des utilisateurs d'un serveur, comment pourra-t-il savoir si certains comptes sont illégitimes ? 

Ou bien encore, tel programme est-il légitime ? Tel exécutable est-il bien celui qu'il parait être ?

Les professionnels de la SSI ont bien fini par comprendre le problème car l'alerte et la détection de l'ampleur ont un point commun : il faut savoir ce que l'on cherche. Une des réponses a donc été les indicateurs de compromission (IoC) qui se traduit bien en anglais : Indicators of Compromise.

L'objectif est de fournir tant un moyen d'alertes que de mesure de l'ampleur en définissant, par référence à un cas connu, les modalités ou les "symptômes" de l'infection. Le rapport Mandiant et la société du même nom ont d'ailleurs développé un outil comprenant un format (un langage commun) permettant de lire et de créer de tels indicateurs.

Dans l'exemple cité en source, il est possible de télécharger la liste des IOCs de l'attaque en question et de les parcourir afin de définir des modalités adaptées de recherche de ces caractéristiques. Notez aussi l'outil Yara qui a plusieurs  modules dont l'objet est d'intégrer plusieurs types d'IOC (des séquences de caractères par exemple) pour les recherchez de manière systématique sur des fichiers et des arborescences. On peut même y ajouter des règles en demandant de rechercher telle règle OU telle autre ou bien celle-ci ET celle-là.

L'originalité et l'utilité des IOC est la multiplicité des informations et la combinaison de celles-ci que l'on peut faire. Par exemple, dans le cas cité ci-dessous, on trouve aussi bien : des empreintes de fichiers, des adresses IP en destination (utilisées peut-être pour l'exfiltration de données ou l'envoi de commandes) ou encore des chaines de caractères spécifiques. 

Celles-ci sont combinées pour tenir compte des versions et évolutions du malware. C'est typiquement l'usage du "OU" : la diversité des empreintes uniques (hash) de fichiers ne limite par la possibilité de détecter telle ou telle version.

Les IOCs ne sont pas la solution parfaite mais adossées à la réactivité de la communauté, elles constituent une réponse intéressante à ces problématiques d'APT que nous venons d'évoquer. Nul doute que d'autres idées viendront afin de progresser dans le traitement de ces sujets complexe mais au coeur de l'actualité en sécurité !

Source :



9 commentaires:

  1. Salut,
    en complément, voici un rapport de Lieberman Software ("Defending Against State-Sponsored Attackscand Other Advanced Persistent Threats"). Il rend compte d'un sondage effectué auprès d'environ 200 participants de la Black Hat 2013 sur les "APT" en général.
    Compte tenu de la population présente à cet événement et des réponses effectuées, cela pourra peut-être vous donner des idées pour un prochain article ;)

    luc3

    RépondreSupprimer
    Réponses
    1. Lien : http://www.liebsoft.com/uploadedFiles/wwwliebsoftcom/MARCOM/Press/Content/2013-IT-Security-Survey.pdf

      Supprimer
  2. Une autre lecture que j'avais trouvé intéressante sur les APT:

    http://bl0g.cedricpernet.net/post/2013/02/14/APT

    RépondreSupprimer
    Réponses
    1. Tout à fait ! Cédric est un maître ! Je ne faisais que vulgariser :)

      Supprimer
  3. Puisqu'on en est dans les liens, celui-ci est intéressant aussi.
    http://exploitability.blogspot.fr/2013/06/bloquer-les-apt-mission-impossible.html

    RépondreSupprimer
  4. Voilà un article clair et compréhensible, sur un sujet ardu et complexe...
    Bravo !

    RépondreSupprimer
  5. Ce commentaire a été supprimé par l'auteur.

    RépondreSupprimer