Marianne ANSSI

CERT-FR

Centre gouvernemental de veille, d'alerte et de réponse aux attaques informatiques

logo ANSSI
Informations utiles

Que faire en cas d'intrusion ?

Les systèmes obsolètes

Liens utiles

 

L'ANSSI recrute

 

 

Les documents du CERT-FR

Publications récentes

Les alertes en cours

Les bulletins d'actualité

Les notes d'information

Année en cours Archive

 

Les Flux RSS du CERT-FR

Flux RSS complet

RSS

Flux RSS des alertes

RSS

Flux RSS SCADA

RSS

 

CERTFR-2016-ACT-017

Imprimer ce document

Version PDF

À propos du CERT-FR

Le CERT-FR

Nous contacter

Contact us ( Drapeau anglais )

A propos du site

Communauté CSIRT

Les CSIRT

Le FIRST

L'EGC

 
Archives du CERT-FR

Année 2017 Archive

Année 2016 Archive

Année 2015 Archive

Année 2014 Archive

Année 2013 Archive

Année 2012 Archive

Année 2011 Archive

Année 2010 Archive

Année 2009 Archive

Année 2008 Archive

Année 2007 Archive

Année 2006 Archive

Année 2005 Archive

Année 2004 Archive

Année 2003 Archive

Année 2002 Archive

Année 2001 Archive

Année 2000 Archive

 

S . G . D . S . N
Agence nationale
de la sécurité des
systèmes d'information

République Française Paris, le 25 avril 2016
No CERTFR-2016-ACT-017

Affaire suivie par :

CERT-FR

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

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.


2 - Rappel des avis émis

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

  • CERTFR-2016-AVI-132 : Vulnérabilité dans Xen
  • CERTFR-2016-AVI-133 : Multiples vulnérabilités dans Citrix XenServer
  • CERTFR-2016-AVI-134 : Multiples vulnérabilités dans Oracle Database Server
  • CERTFR-2016-AVI-135 : Multiples vulnérabilités dans Oracle Java SE
  • CERTFR-2016-AVI-136 : Multiples vulnérabilités dans Oracle Sun Systems Products Suite
  • CERTFR-2016-AVI-137 : Multiples vulnérabilités dans Oracle Linux and Virtualization
  • CERTFR-2016-AVI-138 : Multiples vulnérabilités dans Oracle MySQL
  • CERTFR-2016-AVI-139 : Multiples vulnérabilités dans Symantec Messaging Gateway Appliance
  • CERTFR-2016-AVI-140 : Multiples vulnérabilités dans les produits Cisco
  • CERTFR-2016-AVI-141 : Multiples vulnérabilités dans Squid
  • CERTFR-2016-AVI-142 : Vulnérabilité dans Adobe Analytics AppMeasurement for Flash Library

Gestion détaillée du document

25 avril 2016
version initiale.
Dernière version de ce document : http://cert.ssi.gouv.fr/site/CERTFR-2016-ACT-017

CERT-FR
2016-04-25
Premier Ministre / Secrétariat Général de la Défense et de la Sécurité Nationale / Agence nationale de la sécurité des systèmes d'information webmestre Dernière mise à jour : le 2017-03-28