CVE-2021-43229 Walkthrough

Öffentliche Informationen

Windows NTFS Sicherheitsanfälligkeit für Berechtigungserweiterung

Abweichend von:

• CVE-2021-43230
• CVE-2021-43231

Patch: 14. Dez. 2021

Laut @AravGarg3 auf Twitter scheint CVE-2021-43229 ausnutzbar zu sein und mit einem Integer-Überlauf zusammenzuhängen.

Quelle: https://twitter.com/AravGarg3/status/1479447843458863104

Windows 10 Versionen

Erster Teil - Diffing

Verwenden von BinDiff mit IDA Pro, Patch-Diffing-Ergebnis mit den folgenden Änderungen:

Drei Kandidaten stechen hervor:

• NtfsRenameToPrivateDir
• TxfAllocateAndStoreNameForTxLogging
• TxfAllocateFullFilePathForChangeNotify

Laut dem Security Update Guide von Microsoft vom Dezember beziehen sich vier CVEs auf NTFS:

• CVE-2021-43229: Windows NTFS Elevation of Privilege Vulnerability
• CVE-2021-43230: Windows NTFS Elevation of Privilege Vulnerability
• CVE-2021-43231: Windows NTFS Elevation of Privilege Vulnerability
• CVE-2021-43240: NTFS Set Short Name Elevation of Privilege Vulnerability

CVE-2021-43240 scheint sich auf NtSetShortNameInfo zu beziehen.

NtfsRenameToPrivateDir, TxfAllocateAndStoreNameForTxLogging und TxfAllocateFullFilePathForChangeNotify haben alle drei die gleiche neue Längenprüfung und scheinen mit CVE-2021-43229, CVE-2021-43230 und CVE-2021-43231 zusammenzuhängen, aber nicht unbedingt in dieser Reihenfolge. Derzeit ist es nicht möglich zu wissen, welches welches ist, Microsoft ist bei diesen Informationen etwas geizig.

Analyse

In allen drei CVEs tritt ein Integer-Überlauf während der Berechnung der Allokationsgröße auf (Verzeichnispfadlänge + Dateinamenlänge), was zu einem Pool-basierten Pufferüberlauf mit den folgenden zwei memmove des Verzeichnispfads und des Dateinamens führt.

Zweiter Teil - Der Pfad

Erster Versuch: NtfsRenameToPrivateDir

Der Pfad zu NtfsRenameToPrivateDir wird unten gezeigt:

NtfsCommonSetInformation
       |__________________
       |                  |
       v                  v
NtfsSetLinkInfo   NtfsSetRenameInfo
       |__________________|
       |
       v
NtfsRemoveSupersededTarget
       |
       v
NtfsRenameToPrivateDir

Zunächst, um NtfsCommonSetInformation aufzurufen, rufen Sie einfach NtSetInformationFile auf. Um dann durch NtfsSetLinkInfo und NtfsSetRenameInfo zu gelangen, verwenden Sie jeweils FileLinkInformationEx und FileRenameInformationEx als Dateiinformationsklasse in NtSetInformationFile.

Um NtfsRemoveSupersededTarget über NtfsSetRenameInfo zu erreichen, müssen die Flags FILE_RENAME_REPLACE_IF_EXISTS und FILE_RENAME_POSIX_SEMANTICS gesetzt werden. Benennen Sie eine Datei mit dem Namen einer vorhandenen um, um auf NtfsRemoveSupersededTarget zuzugreifen. Für NtfsRenameToPrivateDir ist es etwas knifflig, da die ersetzte Datei von einem beliebigen Prozess geöffnet sein muss.

Leider wird vor dem Aufruf von NtfsRemoveSupersededTarget eine Längenprüfung durchgeführt.

Die Methode mit NtfsSetLinkInfo ähnelt NtfsSetRenameInfo, nur die Namen der Flags unterscheiden sich, ihre Bedeutungen sind dieselben. Aber ebenso wie bei NtfsSetRenameInfo wird vor dem Aufruf von NtfsRemoveSupersededTarget eine weitere Prüfung durchgeführt.

Zweiter Versuch: TxfAllocateAndStoreNameForTxLogging

Der Pfad zu TxfAllocateAndStoreNameForTxLogging wird unten gezeigt:

NtfsCommonCreate
      |
      v
NtfsCreateNewFile
      |
      v
TxfNewFileCreate
      |
      v
TxfAllocateAndStoreNameForTxfLogging

Zunächst, um NtfsCommonCreate aufzurufen, rufen Sie einfach CreateFile auf.

Die Funktion TxfNewFileCreate ist mit Txf vorangestellt, was "Transaktionales NTFS" bedeutet, und wird aufgerufen, wenn eine transaktionsfähige Datei erstellt wird. TxfAllocateAndStoreNameForTxfLogging wird während des Prozesses aufgerufen, um den Pfad der transaktionsfähigen Datei zu speichern.

Nur zwei Aufrufe sind notwendig:

• CreateTransaction
• CreateFileTransacted

Dritter Teil - PoC It

Der anfällige Code von TxfAllocateAndStoreNameForTxLogging wird unten gezeigt:

...
and     di, 2
add     di, [rsi+UNICODE_STRING.Length]                      ; File name
add     di, [rsp+68h+RelativeNormalizedDirectoryPath.Length] ; OVERFLOW HERE
cmp     [rsp+68h+arg_20], r12b
jnz     loc_16592C

movzx   edx, di
add     rdx, size UNICODE_STRING ; NumberOfBytes
mov     ecx, cs:PoolType
or      ecx, 10h        ; PoolType
mov     r8d, 'afxT'     ; Tag
call    cs:__imp_ExAllocatePooliWthTag
...

Um den Überlauf auszulösen, ist es notwendig, eine Datei mit einer übermäßigen Länge zu erstellen, mehr als 0xFFFF Bytes (32767 Zeichen).

Ein auftretendes Problem ist, dass ein Datei- oder Verzeichnisname nicht größer als 256 Zeichen sein kann - einschließlich des NULL-Zeichens. Um dieses zu lösen, ist die Verwendung von tiefen Unterordnern erforderlich. Seltsamerweise ist es nicht so einfach, selbst wenn Unterordner erfolgreich erstellt werden, kann die Unterdatei nicht erstellt werden, sicherlich aufgrund einiger vorher durchgeführter Prüfungen.

Mit der explorer-Leiste ist es möglich, das Format zu bemerken, das zur Anzeige des Verzeichnispfads verwendet wird. Es ist nicht das, was ich erwartet habe, anstatt einen "klassischen" Pfad zu verwenden, verwendet explorer das altmodische Format von DOS, das 8.3-Kurzformat.

Das Beibehalten der Erstellung von Unterordnern wie zuvor und die Verwendung von Kurznamen für Unterverzeichnisse während der Dateierstellung erledigen die Aufgabe.

Es ist wichtig zu beachten, dass 16 Bytes zur überlaufenen Größe hinzugefügt werden, was der Größe des UNICODE_STRING entspricht, der den endgültigen Pfad darstellen wird. Das liegt daran, dass der angeforderte Speicher den UNICODE_STRING gefolgt vom Puffer dieses UNICODE_STRING enthalten wird.

Methode:

• Erstellen Sie Unterverzeichnisse mit langem Namen
• Erstellen Sie eine Datei mit einem langen Namen und Kurznamen für den Verzeichnispfad

Aktuelle Bedingungen:

• Der Überlauf überschreibt das Äquivalent von 64 KB
• Die allokierte Speichergröße beträgt bis zu 0x20C Bytes
• Der allokierte Speicher befindet sich im Paged Pool

Vierter Teil - Ansätze

Ein interessanter Bericht von Synacktiv auf der SSTIC 2020 könnte eine Idee zum Vertiefen sein, indem man den VS Heap ins Visier nimmt.

Das CVE-2020-17087, ein ähnlicher Fall von Ausnutzung, wurde von PixiePoint Security unter Verwendung der oben genannten Technik vorgestellt.