Les contre-mesures offensive en pratique Jerome Saiz le 6 juillet 2012 à 9h08, dans la rubrique Menaces Commentaires fermés sur Les contre-mesures offensive en pratique exploithackintrusionjavametasploitPHPrsa 2012rsa conference Le concept de légitime défense numérique n’est pas nouveau. Mais à moins d’être les Etats-Unis (qui n’excluent pas de répondre à une attaque cyber par un assaut militaire conventionnel), la mise en oeuvre d’une riposte pirate se heurte généralement à des considérations juridiques épineuses. C’est pourquoi John Strand, instructeur senior au SANS Institute, prêche plutôt pour une approche « passive-agressive » destinée à rendre la vie de l’attaquant misérable sans pour autant tomber dans l’illégalité. Strand propose pour cela trois axes : compliquer à l’extrême l’action du pirate, tenter de l’identifier de manière active et l’attaquer après l’avoir soigneusement prévenu (ce qui ne n’offre cependant aucune garantie légale !). Première approche : compliquer l’action du pirate. Pour cela John Strand propose de déployer des pots de miel conçus pour répondre aux scans de port et disparaître une fois que l’attaquant a initié une connexion complète. « C’est terriblement frustrant de voir le réseau s’écrouler à peine connecté sans savoir d’où vient le problème« , explique John Strand. Autre méthode, plus vicieuse encore : le répertoire récursif à l’infini. Une fois une vulnérabilité exploitée à l’aide de Metasploit, par exemple, le meterpreter tournera en boucle à l’infini et les outils automatiques renverront un time out après avoir fait perdre son temps à l’attaquant. Dans le même esprit, un outil tel WebLabyrinth (en PHP) permet de créer une (fausse) structure de site web infinie afin de perdre les scanners offensifs et permettre à l’équipe sécurité d’observer l’attaque. Seconde approche : tenter d’identifier le pirate. L’objectif ici n’est pas de contre-attaquer mais de découvrir l’identité de l’attaquant, ou du moins assez d’informations à son sujet, pour faciliter la tâche des autorités si l’entreprise décide de porter plainte. Par ailleurs cette information peut permettre de déceler un attaquant unique qui ciblerait spécifiquement l’entreprise, même s’il apparaît comme venant d’adresses IP multiples. La chose est bien entendue compliquée par le fait que les attaquants n’hésitent pas à utiliser plusieurs relais anonymes ou passer par des service d’anomysation des connexions tels TOR. Pour cela deux techniques peuvent être mises en oeuvre. La première consiste à exploiter la capacité des documents Microsoft Office (Word et Excel notamment) à embarquer du HTML. En plaçant par exemple dans un document-piège destiné à être dérobé une référence à un document CSS dont le nom (unique) permettra de l’identifier, il est possible de « marquer » ce document. Une fois ouvert par le pirate l’entreprise disposera alors dans ses journaux de connexions de l’adresse IP du système du voleur de document (et dont la connexion ne passera pas forcément par une série de proxies anonymisants comme lors de l’attaque) L’autre approche consiste à exploiter le projet decloak.net de Metasploit. Celui-ci utilise différentes approches locales (Word, Java, Flash, Quicktime, iTunes…) afin d’essayer de découvrir l’adresse IP originale. Bien que le service insiste sur le fait qu’il ne pourra percer une bonne configuration de TOR, il reste un atout précieux pour tenter de voir à travers les nombreux autres proxies anonymes utilisés par les attaquants. Troisième approche : attaquer ! Nous entrons ici dans les eaux troubles du vide juridique. Selon John Strand la clé est de documenter toutes les mesures mises en place et de prévenir les attaquants, notamment via une bannière de connexion très explicite approuvée par le service juridique. Celle-ci devrait indiquer, en substance, que l’entreprise se réserve le droit d’inspecter l’ordinateur client lors de l’accès à tel ou tel répertoire spécifique (attention : Strand est américain et n’est pas juriste, ce qui fait deux bonnes raisons de demander l’avis d’un juriste français avant de l’imiter !). La stratégie ici est d’attirer l’attaquant vers une partie privée du système et le forcer à exécuter un code particulier. Afin de ne pas pénaliser les utilisateurs légitimes cette zone du site web doit bien entendu être clairement définie comme interdite d’accès (par exemple en excluant un répertoire nommé « Admin » dans le fichier robots.txt). Une fois dans ce répertoire interdit il suffit alors de présenter à l’attaquant un outil prometteur, tel par exemple une interface de configuration ou de contrôle à distance. Seulement voilà : celle-ci nécessite pour s’exécuter d’accepter le téléchargement d’une applet Java spécifique. Et en installant cette applet signée par l’entreprise (100$) l’attaquant lui ouvre bien entendu son système… A partir de là, il n’est pas nécessaire de mener une attaque à proprement parler, mais l’entreprise pourra collecter beaucoup d’informations sur l’identité de l’attaquant : quels réseaux wifi sont à portée, quels noms d’utilisateurs sont définis sur le système, par où exactement transite sa connexion, où se trouve-t-il précisément, etc… Vous avez aimé cet article? Cliquez sur le bouton J'AIME ou partagez le avec vos amis! Notez L'article Participez ou lancez la discussion!