S.G.D.S.N
Agence nationale
de la sécurité des
systèmes d'information
Paris, le 25 avril 2016
N° CERTFR-2016-ACT-017
Affaire suivie par: CERT-FR
le 25 avril 2016

Bulletin d'actualité du CERT-FR

Objet: Bulletin d’actualité CERTFR-2016-ACT-017

Gestion du document

Référence CERTFR-2016-ACT-017
Titre Bulletin d’actualité CERTFR-2016-ACT-017
Date de la première version 25 avril 2016
Date de la dernière version 25 avril 2016
Source(s)
Pièce(s) jointe(s) Aucune(s)
Tableau 1: Gestion du document

Une gestion de version détaillée se trouve à la fin de ce document.

1 – Utilisation du Bitmap Cache de RDP

Zone tampon graphique du protocole RDP

Le protocole RDP (Remote Desktop Protocol ou protocole de bureau à distance) est un protocole de déport de ressources (affichage, écran, etc.) faisant partie du composant Terminal Services des systèmes d’exploitation Microsoft. Depuis son introduction en version 4 dans Windows NT 4.0, de nombreuses mises à jour ont été effectuées, pour ajouter des fonctionnalités de sécurité et limiter la bande passante.

RDP est notamment connu pour le déport d’affichage à distance. Lorsqu’il y a interaction avec le bureau du serveur distant, toutes les modifications graphiques qui en découlent doivent apparaître à l’écran et donc être transmises par le serveur au client. Ces données peuvent vite être volumineuses. Afin d’optimiser l’envoi de ces données, le serveur va calculer un condensat des éléments graphiques (carrés de 64 pixels de côté) impactés et les communiquer au client. Ce dernier lui indique en retour les condensats qu’il connaît et pour lesquels le renvoi des données n’est pas nécessaire.

Naturellement, cet aspect du protocole s’appuie sur une zone tampon (cache) côté client des différents éléments graphiques reçus. Le cache peut se situer à deux niveaux :

  • un cache volatile en mémoire, qui ne sera jamais réutilisé une fois la session terminée ;
  • un cache persistant sur disque, dont la durée de validité s’étend au-delà de la session.

Fonctionnement de la zone tampon

Au moment d’établir une connexion RDP, il est possible d’activer ou non le stockage persistant des éléments graphiques, via les options avancées de la fenêtre de connexion. Si cette option n’est pas choisie, la session n’utilisera pas les données déjà contenues dans le cache local et ne stockera pas non plus de données additionnelles dans ce cache. Si en revanche l’option est activée, celle-ci exploitera les données contenues dans les fichiers de cache et les complétera éventuellement au cours de la session.

Par défaut, les noms et les emplacements des fichiers de cache sont les suivants :

  • jusqu’à Windows XP, les fichiers se trouvent dans « %USERPROFILE%\Local Settings\Application Data\Microsoft\Terminal Server Client\Cache\ », pèsent chacun jusqu’à 10 Mo et se nomment :
    • « bcache2.bmc » qui contient les éléments graphiques en qualité 8 bpp,
    • « bcache22.bmc » qui contient les éléments graphiques en qualité 16 bpp,
    • « bcache24.bmc » qui contient les éléments graphiques en qualité 32 bpp ;
  • à partir de Windows 7, les fichiers se trouvent dans « %USERPROFILE%\AppData\Local\Microsoft\Terminal Server Client\Cache\ » et se nomment « cache????.bin » (???? étant incrémental en commençant à 0000) et pèsent jusqu’à 100 Mo individuellement.

L’emplacement de stockage des fichiers de cache persistant est configurable via la valeur chaîne « BitmapPersistCacheLocation » de la clef de registre « HKCU\Software\Microsoft\Terminal Server Client ».

Structure des fichiers de cache

Structure des fichiers .bmc

Les fichiers « .bmc » ne disposent d’aucun entête fixe permettant de les identifier immédiatement, mais chaque élément graphique à l’intérieur dispose d’un entête structuré comme suit :
  • un condensat de l’élément graphique stocké sur huit octets ;
  • la largeur de l’élément graphique stockée sur deux octets ;
  • la hauteur de l’élément graphique stockée sur deux octets ;
  • la taille en octets des données qui suivent l’entête et correspondant à l’image stockée sur quatre octets ;
  • les paramètres spécifiques quant à l’élément graphique stockés sur quatre octets.

Cela représente un entête d’image de vingt octets.

Les paramètres spécifiques incluent notamment un bit définissant si le contenu de l’image est compressé ou non.

Les entêtes d’image ne suivent pas nécessairement les données de l’image précédente : ceux-ci sont positionnés à des emplacements fixes de telle sorte qu’on puisse stocker une image de taille 64 par 64 non compressée entre deux entêtes, sans avoir à réagencer la structure du ficher de cache.

Une propriété intéressante découle directement de cette pré-allocation : en effet, lorsqu’un emplacement de stockage dans un fichier BMC contient un élément graphique dont la hauteur est plus petite que 64, les octets suivants sont susceptibles de contenir des données de précédents éléments graphiques, et donc la fin d’une image précédente.

Structure des fichiers .bin

Les fichiers « .bin » disposent d’un entête fixe bien identifiable : la chaîne de caractère « RDP8bmp » terminée par un caractère nul suivi de quatre octets correspondant à une version, soit douze octets d’entête de fichier.

Chaque élément graphique dispose quant à lui d’un entête de taille réduite par rapport aux fichiers « .bmc » :

  • un condensat de l’élément graphique stocké sur huit octets ;
  • la largeur de l’élément graphique stockée sur deux octets ;
  • la hauteur de l’élément graphique stockée sur deux octets.

Les données sous-jacentes à chaque élément graphique sont au format 32 bpp (ARGB).

Exploitation des données du cache BMC

Tout d’abord, concernant les données compressées, l’algorithme de compression utilisé n’est pas connu. Il n’est par conséquent pas possible en l’état de décompresser ces données pour obtenir l’image d’origine.

Lorsque les données ne sont pas compressées, elles sont en revanche parfaitement exploitables. Notamment, lorsque nous devons traiter un fichier « bcache22.bmc », l’encodage des données correspond à l’encodage RGB565, tel que décrit par Microsoft au sein de MSDN. La conversion du format RGB565 vers le format RGB classique s’opère avec les transformations suivantes :

rouge = (pixel\&0xF800)>>11;
vert = (pixel\&0x07E0)>>5;
bleu = (pixel\&0x001F);

Les données de l’image sont stockées suivant un ordre « naturel », c’est-à-dire de gauche à droite et de haut en bas. Une réorganisation par ligne est nécessaire pour l’intégrer dans un fichier .BMP.

Dans le cas du fichier « bcache24.bmc » ou des fichiers « cache????.bin », aucune transformation n’est nécessaire et les données peuvent être directement copiées dans le corps d’un fichier .BMP au format 32 bpp. Dans le cas présent, l’image est stockée suivant la logique des fichiers .BMP : de bas en haut et de gauche à droite.

Concernant le fichier « bcache2.bmc », celui-ci correspond aux index des couleurs dans la palette standard des images Bitmap 8bpp sous Windows : les données peuvent être copiées dans le corps d’un fichier .BMP au format 8bpp avec la palette par défaut.

Exploitabilité

Il est possible d’avoir une première idée de l’activation ou non par défaut du cache via le fichier « Default.rdp » situé dans le dossier « %USERPROFILE%\Documents\ » et qui contient les paramètres par défaut lors d’une nouvelle connexion RDP.

L’exploitation réussie des fichiers du cache RDP va permettre de récupérer des fragments de ce que voyait l’utilisateur lors de la session RDP et, en recollant les morceaux, de potentiellement découvrir de nouveaux éléments dans le cadre d’une investigation : rebond sur une autre machine, connexion à un site Internet spécifique, etc.

Rappel des avis émis

Dans la période du 18 au 24 avril 2016, le CERT-FR a émis les publications suivantes :


Gestion détaillée du document

    le 25 avril 2016
    version initiale.