patois/winmagic_sdAnalyse technique et exploit PoC pour CVE-2020-11519 et CVE-2020-11520
Date : juin 2020
Auteur : Dennis Elser (code : github)
En référence à sa présentation web, Winmagic SecureDoc « permet aux entreprises de gérer la sécurité de leur environnement informatique de manière efficace en tirant parti de fonctionnalités telles que : le chiffrement complet du disque (FDE), l’authentification multi-facteurs, le chiffrement des conteneurs de supports amovibles (RMCE) et le chiffrement des fichiers et dossiers (FFE). Ces fonctionnalités aident les entreprises à renforcer la sécurité, à réduire les risques métier et à satisfaire aux exigences gouvernementales et réglementaires en matière de chiffrement des disques durs. »
Le produit Winmagic SecureDoc, disponible en éditions autonome et entreprise, est affecté par deux vulnérabilités locales d’élévation de privilèges (CVE-2020-11519 et CVE-2020-11520) dans les versions 8.3 et 8.5. Après le signalement des vulnérabilités à Winmagic fin mars, l’éditeur a publié un correctif (version 8.5SR2) à la mi-juin 2020. Toutefois, ce correctif s’est avéré insuffisant pour traiter les vulnérabilités, ce qui a également rendu la version 8.5SR2 vulnérable aux failles signalées. Bien que les détails techniques concernant les vulnérabilités aient été retenus pour cette raison, les failles doivent être considérées comme publiques depuis lors. Selon l’éditeur, un autre correctif était encore en préparation, environ 106 jours après le signalement initial de la vulnérabilité à Winmagic. Le 15 juillet, 111 jours après le signalement initial de la vulnérabilité à l’éditeur, Winmagic a publié SecureDoc v8.5 SR2 HF1 pour ses clients, qui corrige apparemment CVE-2020-11519 et CVE-2020-11520. Les versions de SecureDoc antérieures à 8.3 n’ont pas été testées, mais on peut supposer qu’elles sont également affectées, en fonction du code du composant concerné.
L’exploitation réussie de l’une de ces vulnérabilités conduit à une élévation de privilèges jusqu’au compte SYSTEM pour des attaquants authentifiés localement.
Les deux vulnérabilités affectent le composant « SDDisk2k.sys », un pilote noyau fourni avec le produit Winmagic SecureDoc. Les failles de sécurité ont été identifiées par analyse statique manuelle à l’aide du désassembleur et décompilateur Hex-Rays IDA Pro. Rétrospectivement, ces faiblesses auraient pu être découvertes avec beaucoup moins d’efforts si des approches de test dynamique telles que le fuzzing avaient été utilisées à la place. En effet, le pilote peut être interfacé à partir d’applications limitées en mode utilisateur et suppose par défaut que leurs entrées sont bien formées.
En raison de la création non sécurisée d’un objet de périphérique « SecureDocDevice » par le pilote « SDDisk2k.sys » et de l’absence de code permettant de mettre en place un descripteur de sécurité approprié, même les comptes d’utilisateurs limités ont la capacité d’obtenir un handle sur le périphérique à l’aide de la fonction API CreateFile(). En accordant à une application en mode utilisateur un handle vers son objet de périphérique, le pilote ouvre ainsi un chemin direct vers sa surface d’attaque dans le noyau.``` c RtlInitUnicodeString(&DestinationString, L"\Device\SecureDocDevice"); RtlInitUnicodeString(&SymbolicLinkName, L"\DosDevices\SecureDocDevice"); if ( IoCreateDevice(v1, 0xDD8u, &DestinationString, 0x8D1Fu, 0, 0, &DeviceObject) >= 0 ) // <--- unsafe { memset(DeviceObject->DeviceExtension, 0, 0xDD8ui64); DeviceObject->Flags |= 4u; DeviceObject->AlignmentRequirement = 0; if ( IoCreateSymbolicLink(&SymbolicLinkName, &DestinationString) < 0 ) IoDeleteDevice(DeviceObject); IoObject = DeviceObject; }
Après avoir rétroconçu un certain nombre de gestionnaires de services [IOCTL](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/introduction-to-i-o-control-codes) du pilote « SDDisk2k.sys », il a été découvert qu'un d'entre eux expose des fonctionnalités critiques en mode utilisateur, en ce sens qu'il autorise des opérations de lecture et d'écriture sur les secteurs bruts d'un disque arbitraire - par conception. De plus, en s'interfaçant avec ce code même, il a été remarqué que le pilote ignore tout verrou exclusif qui aurait pu être défini précédemment sur un disque. Par conséquent, des opérations concurrentes de lecture/écriture deviennent possibles, ce qui facilite les conditions de concurrence et risque une perte de données.