Une nouvelle solution tout en mémoire d'injection de librairies par réflexion

Par Xavier Poli, secuobs.com
Le 14/11/2008

---

Résumé : La technique "Reflective Injection DLL" permet d'injecter des librairies dans un processus, via son espace d'adressage mémoire, sur un système d'exploitation Microsoft Windows sans avoir à patcher le chargeur natif de librairies de ce système via ntdll. - Lire l'article



En ce qui concerne le domaine des injections de librairies (DLL) dans un processus hôte d’un système d’exploitation de type Microsoft Windows, il existe une technique majeure utilisée depuis son introduction en 2004 par Skape et JT ( lien ).

Cette technique consiste en l’utilisation d’un shellcode ( voir notre dossier - lien ) permettant de patcher la librairie ntdll. Cette librairie contient une partie du chargeur natif de DLL qui est utilisé par les systèmes Microsoft Windows ; ces systèmes étant ensuite forcés à charger la DLL injectée depuis la mémoire vers l’espace d’adressage mémoire du processus hôte visé par l’injection.

Stephen Fewer, de la société Harmony Security ( lien ) présente aujourd’hui une solution alternative à travers une nouvelle technique détaillée dans un papier qu’il vient de publier sous l’intitulé « Reflective DLL Injection » ; le concept de cette technique peut se résumer au fait que c’est la DLL injectée qui est responsable de son propre chargement dans un processus hôte contrairement à la technique de Skape et JT.

Ce chargement est ici effectué via la mise en place d’un chargeur léger au format PE ( Portable Executable - lien ) nécessitant un minimum d’interaction avec le système ciblé et le processus hôte ; ce qui permet d’assurer à l’injection de la DLL une discrétion maximale aussi bien vis-à-vis du système en lui-même que des systèmes de détection et de prévention d’intrusions (I[D|P]S) en présence.

Pour rappel, l’injection à distance d’une DLL dans un processus hôte doit être réalisée en deux étapes : la première consistant à placer le code de cette DLL dans l’espace d’adressage mémoire du processus hôte qui est censé la recevoir tandis que la seconde vise à la charger dans celui-ci ; ces deux étapes nécessitant cependant l’exploitation d’une vulnérabilité tierce pour être effectuées.

A noter qu’une preuve de concept offrant un modèle de DLL compatible avec la technique de « Reflective Injection DLL » est disponible (lien ) sous licence BSD et que la plateforme d’exploitation Metasploit ( voir notre dossier sur Metasploit 2.x - lien et notre article sur Metasploit 3.x - lien ) de HD Moore, intègre maintenant cette technique via la mise à disposition d'une DLL VNC modifiée et d’une charge utile ( voir les payloads Metasploit 2.x - lien ) relative dans la branche de développement du projet.

La détection de DLL injectée avec cette méthode pourrait s’avérer extrêmement difficile pour les systèmes de sécurité puisque les méthodes employées actuellement par ceux-ci sont obsolètes face à ce genre d’attaques qui présentent une interactivité réduite avec le système ciblé et le processus hôte ; cet aspect minimal pouvant être à l’origine de nombreux faux positifs pour les futures solutions à ce problème.

Par ailleurs l’aspect tout en mémoire écarte dès à présent l’ensemble des solutions de sécurité qui opèrent au niveau des systèmes de fichier, à comprendre la plupart des solutions antivirales actuelles ainsi que les FI[D|P]S. La détection au niveau réseau NI[D|P]S pouvant quant à elle être contournée par de nombreuses solutions d’évasions déjà connues et efficaces ( lien ) avec par exemple l’utilisation de shellcodes de type polymorphiques ( voir notre article sur les cryptovirus - lien ).