Pour ce nouveau billet, j’étais prêt à me lancer dans un scénario d’attaque sans malware plus complexe se déroulant en plusieurs étapes et persistant. Puis je suis tombé sur cette attaque sans code incroyablement simple (sans macro Word ou Excel !), qui illustre bien plus efficacement l’idée sous-jacente de cette série : franchir le périmètre n’est pas si compliqué.
La première attaque que je vais décrire exploite une vulnérabilité Microsoft Word impliquant le protocole Dynamic Data Exchange (DDE), assez archaïque. Un correctif n’est disponible que depuis très peu de temps. La deuxième attaque s’appuie sur une vulnérabilité plus générale de Microsoft COM et sur ses capacités de transmission d’objet.
Retour vers le futur du DDE
Quelqu’un se souvient-il de DDE ? Probablement pas. C’est un ancien protocole de communication entre processus qui permettait aux applications et appareils de transmettre des données.
Je le connais assez bien car à une époque j’ai étudié et testé des équipements de télécommunication – il fallait bien que quelqu’un s’y colle. En ce temps-là, le protocole DDE autorisait la transmission des identifiants des appelants aux applis de CRM qui affichaient alors aux agents de centre d’appels une fenêtre contextuelle contenant le dossier de contact du client. Oui, il fallait connecter un câble RS-232 entre le téléphone et l’ordinateur. Une époque révolue !
Il s’avère qu’aujourd’hui encore Microsoft Word est compatible avec DDE.
Cette attaque n’utilise aucun code pour la bonne raison qu’il est possible d’accéder au protocole DDE directement depuis les codes de champ Windows. (coup de chapeau à SensePost pour ses recherches et son article sur le sujet.)
Les codes de champ sont une autre ancienne fonctionnalité de MS Word utilisée pour ajouter du texte dynamique et un peu de programmation dans un document. Les numéros de page en sont l’exemple le plus évident, puisqu’ils peuvent être insérés dans un pied de page au moyen du code de champ {PAGE \*MERGEFORMAT}. Il permet de générer les numéros de page comme par magie.
Je me rappelle encore combien j’avais été épaté par cette fonctionnalité Word lorsque j’étais jeunot.
Word a géré une option de champ DDE jusqu’à ce qu’un correctif désactive la fonctionnalité. L’idée était que DDE laisserait Word communiquer avec une application puis imbriquerait le résultat dans le document. Nous étions à l’aube d’un nouveau concept (communiquer avec des applications externes), repris plus tard par COM, dont je parlerai plus bas.
Quoi qu’il en soit, des hackers ont réalisé que l’application DDE pouvait être, tenez-vous bien, un interpréteur de commande tout ce qu’il y a de plus simple ! Bien entendu, l’interpréteur de commande lance PowerShell et à partir de là, le hacker peut faire à peu près tout ce qu’il veut.
Dans la capture d’écran ci-dessous, vous pouvez voir comment j’ai utilisé la technique furtive présentée dans un précédent billet : le minuscule script PowerShell du champ DDE télécharge un autre script PowerShell, qui lance la deuxième phase de l’attaque.
La méthode privilégiée consiste à utiliser une variante, le champ DDEAUTO, qui lance automatiquement le script à l’ouverture du document Word.
Revenons en arrière.
En tant que hacker débutant, vous pouvez envoyer un e-mail de phishing bien menaçant, semblant par exemple émaner du Service des impôts, et imbriquer un champ DDEAUTO contenant un petit script PS de phase 1. Inutile de procéder à un codage réel avec la bibliothèque de macro MS comme je l’ai fait dans le précédent billet.
Le PDG de l’entreprise ouvre le document Word, le script imbriqué s’active et le hacker a accès à l’ordinateur portable. Dans mon cas, le script PS distant se contente d’afficher un message, mais il pourrait tout aussi bien lancer un client PS Empire donnant accès au shell.
Et en moins de temps qu’il n’en faut pour le dire, les hackers sont les ados les plus riches de leur village.
C’est si simple !
DDE et champs
Face à des demandes insistantes, Microsoft a désactivé DDE dans Word, non sans avoir déclaré d’abord que la fonctionnalité était simplement mal utilisée. Leur réticence était assez compréhensible.
De ce que j’ai pu constater (à partir d’un échantillon fourni par une entreprise de sécurité des données), la mise à jour des champs à l’ouverture d’un document est activée et les macros Word sont désactivées (après notification) par les groupes informatiques. Les paramètres correspondants sont accessibles dans le menu Options de Word.
Cependant, lorsque la mise à jour des champs est activée, Microsoft Word affiche une invite supplémentaire lorsqu’un champ accède à des données distantes, comme c’est le cas avec DDE (voir ci-dessus). Microsoft vous avertit en effet.
Comme l’indique le Dr. Zinaida Benenson, les utilisateurs cliquent et activent la mise à jour du champ.
C’est une façon détournée de remercier Microsoft d’avoir désactivé la dangereuse fonctionnalité DDE.
Est-il difficile de trouver un environnement Windows non corrigé ?
Dans le cadre de mes propres tests, j’ai utilisé des Espaces de travail AWS pour accéder à un bureau virtuel. Et j’ai assez facilement obtenu une machine virtuelle non corrigée dotée de MS Office me laissant insérer un champ DDEAUTO.
Il ne fait aucun doute que nombre d’entreprises n’ont pas encore appliqué le correctif de sécurité.
Le mystère des objets
Même si vous avez appliqué le correctif, il existe d’autres failles dans MS Office qui permettent aux hackers de procéder de façon très similaire à ce que nous avons fait dans Word. Dans le scénario qui suit, je vais vous expliquer comment utiliser Excel comme appât dans une attaque sans code.
Pour bien comprendre ce scénario, il n’est pas inutile de faire un petit retour en arrière sur Microsoft Component Object Model, ou COM.
Créé dans les années 90, COM est décrit comme « un modèle de composant orienté objet, indépendant du langage de programmation » basé sur des appels de procédure distants. Lisez ce billet de StackOverflow, pour consulter les définitions et la terminologie de base de COM.
De manière générale, lorsque l’on essaie de comprendre ce qu’est une application COM, on imagine une application de type Excel ou Word, ou un autre exécutable binaire.
Comme c’est souvent le cas avec Microsoft, c’est un peu plus compliqué que cela. Il s’avère qu’une application COM peut aussi être un script — Jscript ou VBScript. D’un point de vue technique, c’est ce que l’on appelle un scriptlet. Vous avez peut-être déjà vu l’extension .sct pour un fichier Windows, qui est le suffixe officiel des scriptlets. Ces scriptlets sont du code de script essentiel imbriqué dans du XML (voir ci-dessous).
<?XML version="1.0"?> <scriptlet> <registration description="test" progid="test" version="1.00" classid="{BBBB4444-0000-0000-0000-0000FAADACDC}" remotable="true"> </registration> <script language="JScript"> <![CDATA[ var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!"); ]]> </script> </scriptlet>
- <?XML version="1.0"?>
- <scriptlet>
- <registration
- description="test"
- progid="test"
- version="1.00"
- classid="{BBBB4444-0000-0000-0000-0000FAADACDC}"
- remotable="true">
- </registration>
- <script language="JScript">
- <![CDATA[
- var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!");
- ]]>
- </script>
- </scriptlet>
<?XML version="1.0"?> <scriptlet> <registration description="test" progid="test" version="1.00" classid="{BBBB4444-0000-0000-0000-0000FAADACDC}" remotable="true"> </registration> <script language="JScript"> <![CDATA[ var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!"); ]]> </script> </scriptlet>
Des hackers et testeurs d’intrusion ont découvert que certains utilitaires et applications Windows acceptent des objets COM et, par extension, ces scriptlets COM fabriqués par les utilisateurs.
C’est terminé pour aujourd’hui !
Comme devoirs, je vous demande de regarder cette vidéo Derbycon de 2016, qui explique comment des hackers et testeurs d’intrusion sont parvenus à exploiter les scriptlets. Lisez également ce billet sur les scriptlets et ce que l’on appelle les monikers.
Pour vous donner une idée, je peux transmettre un scriptlet à un utilitaire Windows, écrit en VBS, appelé pubprn, enfoui dans C:\Windows\system32\Printing_Admin_Scripts.
Pour les besoins de mes propres tests, j’ai créé un scriptlet distant simple qui lance un shell et imprime un message « bouh ». Pubprn instancie l’objet de scriptlet, autorisant ainsi l’affichage d’un shell.
Cette technique présente des avantages évidents pour les hackers qui souhaitent « vivre de la terre » et rester tapis dans votre système à votre insu.
Dans le prochain billet, j’expliquerai comment les hackers parviennent à exploiter des scriptlets COM dans une feuille de calcul Excel.
Que dois-je faire maintenant ?
Vous trouverez ci-dessous trois solutions pour poursuivre vos efforts visant à réduire les risques liés aux données dans votre entreprise:
Planifiez une démonstration avec nous pour voir Varonis en action. Nous personnaliserons la session en fonction des besoins de votre organisation en matière de sécurité des données et répondrons à vos questions.
Consultez un exemple de notre évaluation des risques liés aux données et découvrez les risques qui pourraient subsister dans votre environnement. Cette évaluation est gratuite et vous montre clairement comment procéder à une remédiation automatisée.
Suivez-nous sur LinkedIn, YouTube et X (Twitter) for pour obtenir des informations sur tous les aspects de la sécurité des données, y compris la DSPM, la détection des menaces, la sécurité de l’IA et plus encore.