Imprimer la page - Thread Local Storage : une arme redoutable

0. Sommaire

1. Pré-requis
2. Qu'est qu'une TLS
2.1 Comment ça marche ?
3. L'intérêt
4. Exemple !
4.1 Mise en Oeuvre
5. Connaître son ennemi
6. Quelques Liens

1. Pré-Requis

Pour comprendre ce papier vous aurez besoin des éléments suivants :

Une bonne connaissance de programmation générale (structure, pointeur, etc)
Un langage de programmation
Comprendre un peu l'ASM pour le poc mais ça reste vraiment basique
Une compétence approfondie sur les systèmes d'exploitation Microsoft
Une base sur le format d'exécutable Microsoft (PE / COFF)
Savoir se servir un minimum des outils d'éditions des headers PE (LordPE, StudPE, etc)

2. Qu'est qu'une TLS

TLS est une abréviation de Thread Local Storage. C'est une fonctionnalité système (quelque soit l'OS) permettant de

Stocker des données uniques à chaque thread d'un programme. C'est le gros avantage de la technologie, permettant ainsi de s'affranchir des éléments de synchronisation lors de cross-threading sans utilisation intempestive d'allocation sur la pile, notamment du point de vue du traitement de variable statique dont l'espace mémoire est partagé par l'ensemble d'un processus donné.
Exécuter des routines d'initialisation / nettoyage pour chaque thread d'un programme.

2.1 Comment ça marche ?

Ce mécanisme peut être utilisé volontairement dans le developpement d'un programme via un ensemble d'API Windows documentée, le TLS est à ce moment la appelé à volonté par les codeurs via les fonctions TlsGetValue, TlsSetValue, etc, un lien est présent en fin de doc pour les détails :).
Les compilateurs Borland (sauf erreur), quant à eux, vont systématiquement créer une section de TLS pour le fonctionnement des binaires qu'ils compilent en mettant les headers PE à contribution. Ce mode de fonctionnement représente une alternative à la première solution, gérée par le système d'exploitation "itself" via NTDLL.DLL lors du chargement des threads.

Cette dernière option, c'est bien celle qui nous intéresse (vous verrez pourquoi un peu plus bas), nous détournerons bien sur son usage initial et vous comprendrez rapidement que c'est une arme redoutable, notamment sur le sujet du developpement de code malveillant. Le TLS est essentiellement composé de deux éléments :

Une structure IMAGE_TLS_DIRECTORY généralement isolé dans une section dédiée (lorsqu'elle est gérée par le compilateur)
Une entrée dans les IMAGE_DATA_DIRECTORY des headers PE, à l'index 9, appelée TLSTable où seront spécifiées l'adresse et la taille de l'IMAGE_TLS_DIRECTORY

Voyons la composition de la structure IMAGE_TLS_DIRECTORY, ainsi qu'une brève explication sur l'utilité de chacune des entrées :

Code:

struct IMAGE_TLS_DIRECTORY
{
   DWORD StartAddressOfRawData ;adresse de départ pour le stockage des données TLS pour chaque thread
   DWORD EndAddressOfRawData ;adresse de fin pour le stockage des données TLS pour chaque thread
   DWORD AddressOfIndex ;Pointeur vers le handle du TLS
   DWORD AddressOfCallBacks ;Le plus interessant, pointeur vers un tableau d'addresse de callback (PIMAGE_TLS_CALLBACK), ces fonctions seront appelées à la création/destruction de chaque thread
   DWORD SizeOfZeroFill ;pas utilisé (spec PE/COFF)
   DWORD Characteristics ;pas utilisé (spec PE/COFF)
}

Notre objectif, vous l'avez bien compris, est de créer un TLS artisanal, une IMAGE_TLS_DIRECTORY dont l'entrée AddressOfCallBacks pointera sur une (des) fonction(s) destinée(s) à servir notre sombre dessein. En modifiant les headers pour sa prise en charge, nous allons donc pouvoir exécuter du code d'initialisation de thread. Une question subsiste, pourquoi ?

3. L'intérêt

Un fait, et une entrée de la structure IMAGE_TLS_DIRECTORY; A savoir que l'ensemble des fonctions pointées par l'entrée AddressOfCallBacks seront exécutées pour initialisation de CHAQUE thread, et qui dit chaque thread dit AUSSI la thread principale du programme. Qu'est ce que cela signifie ? Et bien que le code contenu sera exécuté AVANT que le programme en lui même ne soit lancé.
Pour donner un exemple concret, imaginez un virus dont la charge de reproduction serait démarrée via une TLS ? Quelle serait les conséquences ? Un antivirus qui tenterait d'émuler le code commencerait par gerer le tout à partir de l'EntryPoint ... Et la c'est dramatique. L'entryPoint n'est pas modifé, le corps du virus s'est éxécuté avant, l'émulateur ne voit RIEN.
Une autre conséquence, c'est le reverse engineering, et la vous y reflechirez deux fois avant d'ouvrir un crackme :-) le code sera exécuté AVANT le chargement du debugger. Vous verrez dans l'exemple que nous exécuterons du code avant que Ollydbg n'ai desassemblé le contenu. Si c'est un virus, vous êtes DEJA infecté. J'ajoute également une intéressante possibilité du point de vue anti-debug. Finalement rien ne nous empecherait de corrompre le code si on detecte un debugger (et pour ça il y a vraiment une multitude de techniques).

J'insiste bien sur ce point, cette méthode est térrifiante puisque tout code présent dans une TLS et pointé par PIMAGE_TLS_CALLBACK sera exécuté AVANT même la toute première instruction du code du processus cible.

4. Exemple !

Notre POC est codé en ASM (FASM). C'est un simple Hello World dont le corps à été modifié par un vilain hacker via une TLS. J'ai sévèrement commenté le code pour que tout le monde puisse être à même de comprendre l'exemple.

Code:

format PE GUI 4.0
entry start

include 'win32a.inc'

;section code
section '.text' code readable executable writeable

;affiche un simple MessageBox et on quitte le programme
start:
   push 0
   push szCaption
   push szOriginalMessage ;on voit bien ici que le message est Hello World !
   push 0
   call [MessageBox]
   ret


;ici c'est le code que nous allons exécuter en TLS
TLS_Function:
   pushad ;sauvegarde du contexte initial, on sait jamais
   mov edi, start + 8  ;on pointe sur l'addresse de l'argument message dans l'appel de MessageBox
   mov esi, szBetterMessage ;on pointe sur notre mod
   mov dword[edi], esi ;on modifie !
   popad  ;on a sauvegarder tout le contexte d'exécution initial, on rétablit
   ret ;on quitte proprement


IMAGE_TLS_DIRECTORY:
   StartAddressOfRawData dd TLS_RawData ;adresse de départ pour le stockage des données TLS pour chaque thread
   EndAddressOfRawData   dd TLS_RawData ;adresse de fin pour le stockage des données TLS pour chaque thread
   ;on en a pas besoin dans notre POC

   AddressOfIndex        dd TLS_Handle ;Pointeur vers le handle du TLS
   AddressOfCallBacks    dd p1 ;Le plus interessant, pointeur vers un tableau d'addresse de callback,
                               ;ces fonctions seront appelées à la création de chaque thread
   SizeOfZeroFill        dd 0  ;pas utilisé (spec PE/COFF)
   Characteristics       dd 0  ;pas utilisé (spec PE/COFF)


PIMAGE_TLS_CALLBACK:
   p1 dd TLS_Function ;pointeur sur l'adresse de la fonction à utiliser
   p2 dd ? ;on fini le tableau par une entrée vide


   TLS_RawData dd ? ;voir plus haut
   TLS_Handle dd ?  ;voir plus haut



;section data
section '.data' data readable writeable
   szCaption db "Hello !",0
   szOriginalMessage db "Hello World",0
   szBetterMessage db "Hello Newbie Contest World",0

;imports
section '.idata' import data readable writeable

   library user32, "user32.dll"
   import user32, MessageBox, 'MessageBoxA'

   4.1 Mise en oeuvre

Alors la c'est un peu spécial, en effet modifier les headers à la volée m'aurait obligé à coder un POC plus conséquent ou à carrément coder le PE dans le source, ça aurait été plus complexe à comprendre et beaucoup plus long à developper. L'impact ? vous allez mettre un peu les main dans le camboui. Pour cela vous devrez modifider les headers de l'exécutable pour spécifier la TLS dans le IMAGE_TLS_DIRECTORY. Pour la réalisation avec LordPE:
   a. Click sur "PE Editor" => aller chercher le code compilé)
   b. Click sur le bouton "Directory"
   c. Dans la fenêtre présentée, chercher l'entrée "TlsTable".
   d. Dans le champs "RVA" entrez : 00001024 (vous pouvez determinez vous même la RVA avec Ollydbg, c'est après le RET qui suit le POPAD :) - N' oubliez pas de soustraire l'image base.)
   e. Dans le chaps "Size" 00000018, c'est la taille de IMAGE_TLS_DIRECTORY

Note : vous pouvez tester l'exécutable avant et après la modification pour bien vous rendre compte de la nature perverse de cette technologie !

Note, le retour : Propriété intéressante, vous constaterez si vous en avez la possibilité technique que le lancement d'un programme implémentant la technologie présentée n'exécutera PAS le code présent dans la TLS s'il est lancé à partir du réseau (d'un partage donc). Finalement vous vous retrouvez avec un exécutable dont le traitement est modifié selon le contexte (en tout cas sous Windows 7).

L'exemple fourni est très simple, c'est vrai. Mais d'autres implémentation permette entre autre de carrément modifier les AddressOfCallBacks à la volée pour traiter des conditions ! Vous pouvez donc "choisir" ce que vous exécuterez, tout ça ... avant que le programme ne démarre lui même. C'est très violent.

5. Connaître son ennemi

De nombreux worms et autres codes malveillants utilisent cette technologie (le début des implémentations massives démarre en 2004, elle est connue depuis les années 2000...). Ce qui donne, en 2011, une chance pour un antivirus de qualité de facilement detecter ce trick.
Pour ce qui est du repérage manuel (en dehors de la "fécondation in-compilo"), il faut configurer son debugger. Les plus anciens ne feront pas l'affaire. Toutefois, pour le plus connu d'entre eux, Ollydbg il reste une oasis : il faut regarder du coté des options de debugging. Par défaut l'outil est configuré pour "breaker" sur l'entrypoint du programme, matérialisé par l'option "WinMain (if location is known)". Comme dit précédemment, c'est bien le loader de Windows (au travers d'NTDLL) qui gère l'exploitation de la TLS pour l'implémentation au travers des headers, ce n'est donc pas l'exécutable en lui même, mais votre système. Remplacer cette option par "System breakpoint" suffira donc faire en sorte de s'affranchir du risque tout de mêe conséquent de s'infecter en debuggant un programme, sans même s'en rendre compte !

6. Quelques liens

Initialisation TLS : http://msdn.microsoft.com/en-us/magazine/cc301808.aspx (http://msdn.microsoft.com/en-us/magazine/cc301808.aspx)
Détail de la structure : http://msdn.microsoft.com/en-us/magazine/bb985996.aspx (http://msdn.microsoft.com/en-us/magazine/bb985996.aspx)
API Windows : http://msdn.microsoft.com/en-us/library/ms686991(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/ms686991(v=vs.85).aspx)
Pour aller plus loin (attention ça pique) : http://www.nynaeve.net/?p=180 (http://www.nynaeve.net/?p=180)
Thread Environment Block : http://en.wikipedia.org/wiki/Win32_Thread_Information_Block (http://en.wikipedia.org/wiki/Win32_Thread_Information_Block)

NewbieContest

Général => Proposition de tutoriaux => Discussion démarrée par: Lord357 le 04 Septembre 2011 à 18:13:12