octoberfest7/cve-2023-36874_bofBOF CobaltStrike armé pour CVE-2023-36874, élévation de privilèges locale (LPE) de Windows Error Reporting.
Ceci est une implémentation BOF CobaltStrike mature et opérationnelle de l'exploit d'élévation de privilèges locaux Windows Error Reporting CVE-2023-36874 de Filip Dragovic (@filip_dragovic). Il a fait le gros du travail en créant un exploit fonctionnel grâce à la rétro-ingénierie de la DLL vulnérable concernée et à la création des structures COM non documentées qui sont essentielles à cet exploit.
Ce BOF déposera un EXE spécifié par l'utilisateur sur le disque de la machine cible, puis déclenchera la vulnérabilité, ce qui entraînera l'exécution de l'EXE par SYSTEM.
Microsoft crédite le Threat Analysis Group de Google pour la divulgation de cette vulnérabilité ; elle a toutefois été portée à mon attention via les recherches publiées par CrowdStrike.
Cet article de blog répertorie de nombreux artefacts différents liés à cet exploit ; en se basant sur la convention de nommage des artefacts (8.exe, 2016.exe, 2019.exe, 10new+11.exe, etc.) ainsi que sur le fait que Microsoft a publié des correctifs pour cette vulnérabilité en remontant jusqu'à Server 2008, on peut en déduire que cette vulnérabilité affecte un certain nombre de versions différentes de Windows.
Ce BOF n'est fonctionnel que sur Windows 10 et Windows 11 21H1 - 22H2 ; il peut également fonctionner sur 20H1/H2, mais je n'ai pas de machine pour le tester. Sur les versions antérieures de Windows, cet exploit fera planter le processus qui l'exécute. J'ai l'intuition que cela est lié à des différences dans les structures COM de wercplsupport.dll et qu'avec un peu de travail supplémentaire, cela devrait être surmontable, mais il existe de nombreux autres exploits pour les versions précédentes de Windows, je vais donc laisser cette tâche à d'autres pour le moment.
Chargez wer_lpe.cna dans CobaltStrike et la commande wer_lpe apparaîtra.
Fournissez le chemin de l'EXE que vous souhaitez téléverser, et éventuellement un répertoire sur lequel votre utilisateur actuel à faibles privilèges a accès en écriture. Si aucun répertoire n'est spécifié, wer_lpe tentera d'écrire dans le répertoire courant de Beacon.
Quelques fonctionnalités supplémentaires ont été ajoutées au POC d'origine afin de maintenir l'OPSEC et de tenter de brouiller les signatures statiques, ainsi que de nettoyer automatiquement après l'exploitation.
Dans le cadre de l'exploit, un nouveau dossier doit être créé dans le répertoire C:\ProgramData\Microsoft\Windows\WER\ReportArchive. Ce dossier contiendra le fichier Report.wer qui doit être déposé sur le disque dans le cadre de la chaîne d'exploitation. L'exploit original de Filip crée un répertoire nommé « MyFolder ». En observant les vrais dossiers/rapports contenus dans le répertoire ReportArchive, on peut mieux comprendre une convention de nommage qui permettra de mieux passer inaperçu face aux détections basiques.
Le BOF contient des stubs de deux vrais dossiers trouvés dans le répertoire ReportArchive d'une machine (l'un est commenté). À l'exécution, wer_lpe générera aléatoirement un GUID et l'ajoutera au stub sélectionné afin de créer un dossier crédible (et statistiquement unique) dans lequel créer le fichier Report.wer.
Le fichier report.wer est un autre indicateur statique facile permettant de détecter cet exploit. L'exploit original embarque le fichier Report.wer comme ressource dans l'EXE ; ce BOF va localiser et lire 'Report.wer' depuis le répertoire de l'exploit sur la machine d'attaque et l'envoyer au Beacon pour l'écrire sur le disque. Cela ouvre la porte au remplacement du fichier Report.wer pré-embarqué par un fichier arbitraire de leur choix.
Plusieurs des appels COM au sein de l'exploit nécessitent des chaînes arbitraires pour que l'exploit puisse se dérouler ; celles-ci ont également été remplacées par des chaînes aléatoires générées à l'exécution.
Étant donné que cet exploit exécute un EXE arbitraire, le nettoyage peut devenir un problème si vous souhaitez que votre EXE s'exécute en continu (dans le cas où il lance un nouveau Beacon), car l'EXE sera verrouillé sur le disque. Wer_lpe a implémenté l'auto-suppression créée par LloydLabs (dont je continue à tirer un excellent parti) pour contrer ce problème. Wer_lpe tentera de supprimer/nettoyer tous les fichiers et répertoires créés au cours de l'exploitation et fournira un rapport d'état de ses succès/échecs.
Parce que tenter d'exécuter un EXE arbitraire non signé en 2023 sur une machine cible est souvent un exercice futile, j'ai exploré la possibilité de faire exécuter à l'exploit le VRAI wermgr.exe (copié dans un répertoire arbitraire) afin de profiter des opportunités de sideloading de DLL. En raison de la nature de l'exploit, cela n'est pas possible. Voir ce fil Twitter pour plus de détails.
Cet exploit échouera s'il est exécuté par un utilisateur disposant de droits d'administrateur local sur la machine ; cela est dû au fait que le code vulnérable usurpe l'identité de l'utilisateur avec (en paraphrase) « l'intégrité la plus élevée disponible ». Pour un utilisateur administrateur local, cela signifie que son jeton d'administrateur sera usurpé ; ce jeton possède une carte des périphériques DOS distincte de celle de son jeton d'intégrité moyenne, ce dernier implémentant la redirection requise pour déclencher la vulnérabilité. Cet exploit ne remplace pas un contournement d'UAC.
Microsoft a publié un correctif pour cette vulnérabilité le 11 juillet 2023 dans le cadre de la mise à jour de sécurité mensuelle pour presque tous les systèmes d'exploitation imaginables que les gens pourraient encore utiliser ; patchez vos machines, les gens.
Tout d'abord, un immense merci à Filip Dragovic (@filip_dragovic) pour son code fonctionnel ainsi que pour sa disponibilité à discuter avec moi et à m'expliquer son processus de développement pour cet exploit.
CrowdStrike pour leur article.
LloydLabs pour son code d'auto-suppression.
