Incursion dans le piratage sans malware, Partie V : scriplets COM et DDE

Dans cette série de billets, nous avons exploré les techniques d’attaque qui demandent des efforts minimes de la part des hackers. En utilisant l’approche sans code pour paresseux que j’ai présentée le précédent article, il est même possible de glisser une charge minuscule dans un champ d’échange dynamique de données (DDE) de Microsoft Word. Et en ouvrant la pièce jointe d’un e-mail de phishing, l’utilisateur crédule permet au hacker de mettre un pied dans son ordinateur portable. En fin d’année dernière, Microsoft a fini par fermer la porte aux attaques DDE en publiant un correctif de sécurité.

Ce correctif ajoute une entrée de registre qui désactive par défaut la Fonctionnalité DDE dans Word. Si vous ne pouvez pas vous passer de cette fonctionnalité, libre à vous de modifier le paramètre pour rétablir les anciennes capacités DDE.

Toutefois, le correctif d’origine concernait seulement Microsoft Word. D’autres produits Microsoft Office contiennent-ils des capacités DDE qui pourraient être exploitées sans code ?

La réponse est oui. On en trouve aussi dans Excel.

La nuit des DDE-vivants

Avant que vous ne commenciez à crier sur votre navigateur, j’ai bien conscience de vous avoir laissé dans un terrible suspens dans mon précédent billet, dans ma description des scriptlets COM. Je reviendrai dessus un peu plus loin.

Poursuivons sur le côté maléfique du DDE, sa version Excel.

Comme pour Word, les capacités DDE d’Excel, difficiles à déceler au premier abord, vous permettent d’exécuter un peu de code shell sans transpirer une seule goutte. En tant qu’utilisateur martyr de Word, je connaissais les champs et possédais quelques notions sur les fonctions DDE.

Dans Excel, quelle n’a pas été ma surprise de constater qu’il est possible d’exécuter une commande shell dans une cellule en procédant comme suit :

Cette possibilité d’exécuter un shell Windows nous est gracieusement offerte par le DDE. (Et oui, les fonctionnalités DDE intégrées à Excel permettent de se connecter à d’autres applications.)

Vous pensez ce que je pense ?

Faites en sorte que la commande shell de la cellule lance une session PowerShell, laquelle télécharge et exécute ensuite une chaîne distante — l’astuce que nous utilisons depuis le début. Comme je l’ai fait ci-dessous :

Vous devez, bien entendu, entrer la cellule de manière explicite pour exécuter cette formule Excel.

Comment un hacker pourrait-il forcer l’exécution de cette commande DDE ?

À l’ouverture de la feuille de calcul, et s’il n’a pas été configuré autrement, Excel tente de rafraîchir ces liens DDE. Il existe depuis longtemps des options (enfouies dans le Centre de gestion de la confidentialité) permettant de désactiver ou actualiser des liens vers des sources de données externes ou d’autres classeurs.

L’an dernier, Microsoft a commencé par conseiller aux entreprises de désactiver les mises à jour automatiques pour éviter que ce piratage basé sur DDE ne soit trop facilement exploité dans Excel.

Des mesures de limitation ont été adoptées, bien sûr, mais Microsoft hésitait à suivre la même voie que pour Word, c’est-à-dire fournir une entrée de registre qui désactiverait totalement le DDE.

Mais en janvier ils ont sauté le pas et fourni des correctifs pour Excel 2007, 2010 et 2013 qui désactivent aussi le DDE par défaut. Cet article (merci à Computerworld) explique bien le correctif dans le détail.

Passons aux journaux des événements

Pour résumer, Microsoft a tiré la prise du DDE dans MS Word et Excel (si vous avez installé les correctifs), décidant au final que le DDE est plus un bug que (hum hum) une fonctionnalité.

Si, pour une raison ou pour une autre, vous n’avez pas appliqué les correctifs dans votre environnement, vous pouvez quand même réduire le risque d’attaque basée sur le DDE en désactivant les mises à jour automatiques ou en activant les options qui invitent les utilisateurs à actualiser les liens à l’ouverture du document ou de la feuille de calcul.

Et maintenant, question importante : si vous êtes victime d’une attaque de ce type, les sessions PowerShell lancées par des champs dans Word ou une commande shell dans une cellule Excel apparaîtraient-elles dans le journal ?

Dans ma série sur l’obfuscation, j’ai évoqué les améliorations majeures apportées à la journalisation PowerShell dans les versions récentes de Windows. J’ai donc jeté un œil au journal (voir ci-dessus) et je peux confirmer que même lorsque vous lancez des sessions PowerShell directement depuis une fonction d’une cellule (plutôt que sous forme de macro), Windows consigne l’événement dans le journal.

Je ne suis pas en train de dire que l’équipe informatique pourrait facilement s’y retrouver et remonter la piste à partir de la session PowerShell jusqu’à un document Excel ou un e-mail de phishing, pour arriver à la conclusion qu’il s’agit effectivement du début de l’attaque. J’aborderai les conséquences des techniques de piratage sans malware dans mon dernier billet de cette série sans fin.

Venons-en au scriptlet COM

Dans le précédent billet, j’ai parlé des scriptlets COM. En essence, je suppose que les scriptlets offrent un chouette moyen de transmettre du code, par exemple JScript, comme un autre objet COM.

Mais les hackers ont découvert les scriptlets, qui leur permettent au minimum de rester extrêmement discrets sur l’ordinateur de la victime et de « vivre de la terre ». Cette vidéo Derbycon fait la démonstration de quelques outils Windows résidents qui utilisent des scriptlets distants comme arguments (regsrv32, rundll32) et permettent aux hackers de mener à bien leurs attaques sans malware. Comme je l’ai montré la dernière fois, vous pouvez facilement lancer des commandes PowerShell en utilisant un scriptlet basé sur JScript.

Il se trouve qu’un chercheur en sécurité très malin a découvert un moyen d’exécuter un scriptlet COM dans un document Excel. Il s’est aperçu qu’un élément portant le nom de Package est inséré dans une formule de cellule Excel lorsque vous tentez d’insérer un lien vers un document ou un graphique. Et ce Package acceptera un scriptlet distant (voir ci-dessous).

En examinant le code de plus près, il s’est rendu compte qu’il s’agit en fait d’un bug du logiciel Package. Il n’était pas censé instancier un scriptlet COM, seulement des objets de fichier.

Je ne suis pas sûr qu’il existe déjà un correctif pour cela. Au cours de la propre exploration d’un bureau virtuel Amazon WorkSpaces doté d’Office 2010, je suis parvenu à reproduire ses résultats. Lorsque j’ai réessayé l’autre jour, je n’ai pas réussi.

Alors que nous concluons cette série d’articles, j’espère avoir réussi à vous faire toucher du doigt la forte incertitude qui entoure ce que les hackers sont capables de faire dans votre environnement. Même si vous acceptez tous les correctifs Microsoft Office récents, les hackers ont toujours la possibilité de recourir à une des techniques relativement simples basées sur les macros VBA que j’ai présentées, pour intégrer une charge de malware à Word ou Excel.

Et si vous avez négligé d’appliquer les correctifs, vous leur avez encore facilité la tâche : ils n’auront aucun mal à mettre un pied dans votre machine sans utiliser de code, pour l’exploiter par la suite à votre insu.

Je parlerai de ce que cela implique en termes de mise en place d’une protection raisonnable dans le dernier épisode (c’est promis) de cette saga.