Varonis debuts trailblazing features for securing Salesforce. Learn More

Introduction de l'automatisation du moindre privilège pour Microsoft 365, Google Drive et Box

En savoir plus

Incursion dans le piratage sans malware, Partie IV : DDE

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...
Michael Buckbee
5 minute de lecture
Publié 22 juin 2018
Dernière mise à jour 3 novembre 2021

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.

DDE
Astuce de pro : il est possible d’accéder aux codes de champs depuis la section texte du ruban Word.

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.

DDE
Merci à Windows d’avoir signalé le fait qu’un champ DDEAUTO imbriqué lance un shell à l’insu de tous.

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.

DDE
Un shell a été lancé sans véritable codage. Même un enfant macédonien pourrait le faire !

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).

  1. <?XML version="1.0"?>
  2. <scriptlet>
  3. <registration
  4. description="test"
  5. progid="test"
  6. version="1.00"
  7. classid="{BBBB4444-0000-0000-0000-0000FAADACDC}"
  8. remotable="true">
  9. </registration>
  10. <script language="JScript">
  11. <![CDATA[
  12. var r = new ActiveXObject("WScript.Shell").Run("cmd /k powershell -c Write-Host You have been scripted!");
  13. ]]>
  14. </script>
  15. </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.

DDE
Rien de plus naturel que de lancer un shell depuis un script d’impression. Allez Microsoft !

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.

What you should do now

Below are three ways we can help you begin your journey to reducing data risk at your company:

  1. Schedule a demo session with us, where we can show you around, answer your questions, and help you see if Varonis is right for you.
  2. Download our free report and learn the risks associated with SaaS data exposure.
  3. Share this blog post with someone you know who'd enjoy reading it. Share it with them via email, LinkedIn, Reddit, or Facebook.
Testez Varonis gratuitement.
Un résumé détaillé des risques liés à la sécurité de vos données.
Stratégie claire vers une remédiation automatisée.
Déploiement rapide.
Keep reading
guide-de-l’acheteur-de-dspm
Guide de l’acheteur de DSPM
Comprenez les différents types de solutions DSPM, évitez les pièges les plus courants et posez les bonnes questions pour vous assurer que vous achetez une solution de sécurité des données qui répond à vos besoins spécifiques.
derrière-la-refonte-de-la-marque-varonis
Derrière la refonte de la marque Varonis
Découvrez la stratégie derrière la refonte de Varonis qui impliquait une transition complète vers un archétype de héros et l'introduction de Protector 22814.
varonis-étend-sa-couverture-pour-aider-à-sécuriser-les-données-critiques-de-snowflake
Varonis étend sa couverture pour aider à sécuriser les données critiques de Snowflake
Varonis étend la couverture DSPM à Snowflake, améliorant ainsi la visibilité et la sécurité des données critiques de Snowflake.
tendances-en-matière-de-cybersécurité-pour 2024 :-ce-que-vous-devez-savoir
Tendances en matière de cybersécurité pour 2024 : ce que vous devez savoir
Apprenez-en davantage sur la gestion de la posture en matière de sécurité des données, les risques liés à la sécurité de l’IA, les changements en termes de conformité et bien plus encore pour préparer votre stratégie en matière de cybersécurité pour 2024.