datntsec/cve-2020-1206Technische Analyse von CVE-2020-1206 (SMBleed), einer Kernel-Informationsoffenlegungsschwachstelle in Windows SMBv3, einschließlich eines nicht authentifizierten Speicherleck-Orakels und Ausnutzungstechniken in Kombination mit SMBGhost für RCE.
Bei der SMBGhost-Schwachstelle (CVE-2020-0796) habe ich über eine Write-What-Where-Primitive-Technik gesprochen, die durch die Ausnutzung eines Integer-Overflow-Bugs den Zeiger Alloc.Userbuffer so ändert, dass er auf eine von uns gewünschte Adresse zeigt und wir dort beliebige Daten schreiben können. Ähnlich wie SMBGhost existiert diese Schwachstelle auch in der Funktion Srv2DecompressData in srv2.sys. Schauen wir uns noch einmal die Funktion Srv2DecompressData an, die mit der SMBGhost-Schwachstelle (CVE-2020-0796) zusammenhängt und von Zecops vereinfacht wurde.``` c typedef struct _COMPRESSION_TRANSFORM_HEADER { ULONG ProtocolId; ULONG OriginalCompressedSegmentSize; USHORT CompressionAlgorithm; USHORT Flags; ULONG Offset; } COMPRESSION_TRANSFORM_HEADER, *PCOMPRESSION_TRANSFORM_HEADER;
typedef struct _ALLOCATION_HEADER { // ... PVOID UserBuffer; // ... } ALLOCATION_HEADER, *PALLOCATION_HEADER;
NTSTATUS Srv2DecompressData(PCOMPRESSION_TRANSFORM_HEADER Header, SIZE_T TotalSize) { PALLOCATION_HEADER Alloc = SrvNetAllocateBuffer( (ULONG)(Header->OriginalCompressedSegmentSize + Header->Offset), NULL); If (!Alloc) { return STATUS_INSUFFICIENT_RESOURCES; }
ULONG FinalCompressedSize = 0;
NTSTATUS Status = SmbCompressionDecompress(
Header->CompressionAlgorithm,
(PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER) + Header->Offset,
(ULONG)(TotalSize - sizeof(COMPRESSION_TRANSFORM_HEADER) - Header->Offset),
(PUCHAR)Alloc->UserBuffer + Header->Offset,
Header->OriginalCompressedSegmentSize,
&FinalCompressedSize);
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
SrvNetFreeBuffer(Alloc);
return STATUS_BAD_DATA;
}
if (Header->Offset > 0) {
memcpy(
Alloc->UserBuffer,
(PUCHAR)Header + sizeof(COMPRESSION_TRANSFORM_HEADER),
Header->Offset);
}
Srv2ReplaceReceiveBuffer(some_session_handle, Alloc);
return STATUS_SUCCESS;
}
Die Funktion Srv2DecompressData empfängt eine vom Client gesendete komprimierte Nachricht und reserviert einen benötigten Speicherbereich, um die Nachricht darin zu dekomprimieren. Anschließend, wenn das Offset-Feld ungleich Null ist, kopiert sie die Daten (RawData) vor den komprimierten Daten in den Anfang des reservierten Speicherbereichs.
Der SMBGhost-Fehler liegt darin, dass die Funktion keinen Integer-Überlauf prüft, was zu einer falschen Speicherzuweisung und einem Pufferüberlauf führt. Drei Monate nachdem Microsoft SMBGhost gepatcht hatte, wurde der Fehler CVE-2020-1206 (SMBleed – laut [Zecops Blog](https://blog.zecops.com/)) entdeckt. Dieser Fehler ermöglicht es uns, die Adresse eines anderen Rechners zu leaken, und in Kombination mit SMBGhost könnten wir RCE erlangen. Um einen einfacheren Blick auf die Funktion Srv2DecompressData zu werfen, werden wir diese Funktion in ihrem ungepatchten Zustand vor dem SMBGhost-Patch verwenden und annehmen, dass sie bereits gepatcht ist.
# Manipulation von OriginalCompressedSegmentSize
Wie bei SMBGhost werden wir auch diesmal das OriginalCompressedSegmentSize mit einer etwas größeren Zahl als die von uns gesendeten dekomprimierten Daten fälschen. Wenn wir beispielsweise Daten der Größe x Byte komprimieren, setzen wir anstelle von x in das Feld OriginalCompressedSegmentSize den Wert x + 0x1000, wie das folgende Bild verdeutlicht:
Nicht initialisierte Kernel-Daten werden als Teil der Nachricht betrachtet.
Wie ich in der Analyse von [CVE-2020-0796](https://github.com/datntsec/CVE-2020-0796) erwähnt habe, wird Srv2DecompressData die Prüfphase nach der Funktion SmbCompressionDecompress überspringen, wenn die Dekomprimierung erfolgreich ist:``` c
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
SrvNetFreeBuffer(Alloc);
return STATUS_BAD_DATA;
}
Obwohl das Feld OriginalCompressedSegmentSize auf x + 0x1000 statt auf x gesetzt ist, enthält die Variable FinalCompressedSize nach erfolgreicher Dekomprimierung nicht den Wert x, sondern den Wert x + 0x1000:```c NTSTATUS SmbCompressionDecompress( USHORT CompressionAlgorithm, PUCHAR UncompressedBuffer, ULONG UncompressedBufferSize, PUCHAR CompressedBuffer, ULONG CompressedBufferSize, PULONG FinalCompressedSize) { // ...
NTSTATUS Status = RtlDecompressBufferEx2(
...,
FinalUncompressedSize,
...);
if (status >= 0) {
*FinalCompressedSize = CompressedBufferSize;
}
// ...
return Status;
}
Bởi vì sau khi giải nén thành công, FinalCompressedSize được cập nhật để giữ giá trị CompressedBufferSize (tương ứng với OriginalCompressedSegmentSize được truyền vào hàm SmbCompressionDecompress). Việc cập nhật và kiểm tra sau đó là gần như không cần thiết, có thể dẫn đến một số lỗi không mong muốn.
# Grundlegende Exploitation
Die von Zecops zum Nachweis des Fehlers verwendete Nachrichtenstruktur ist die [SMB2 WRITE-Nachricht](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e7046961-3318-4350-be2a-a8d69bb59ce8). Diese Struktur enthält Felder wie die Anzahl der beschreibbaren Bytes, Flags usw., gefolgt von einem Puffer mit beliebiger Länge. Dies ist ziemlich perfekt für die Ausnutzung des Fehlers, da wir eine Nachricht erstellen und einen Header mit einem Puffer angeben können, der nicht initialisierte Daten enthält.
Basierend auf dem POC von [Zecops](https://blog.zecops.com/) im Repository der WindowsProtocolTestSuites von Microsoft werden wir diesen kleinen Zusatz zur Kompressionsfunktion hinzufügen, um einen klareren Einblick zu erhalten:``` c
// HACK: fake size
if (((Smb2SinglePacket)packet).Header.Command == Smb2Command.WRITE)
{
((Smb2WriteRequestPacket)packet).PayLoad.Length += 0x1000;
compressedPacket.Header.OriginalCompressedSegmentSize += 0x1000;
}
Beachten Sie, dass dieser POC Authentifizierungsinformationen und Schreibberechtigungen erfordert, die in vielen Fällen verfügbar sind. Der zurückgegebene Fehler gilt jedoch für jede Nachricht (einschließlich Nachrichten mit oder ohne Authentifizierungsinformationen), sodass wir möglicherweise ohne Authentifizierung ausnutzen können.
Ein weiterer Punkt ist, dass der Speicher, den wir leaken werden, von vorherigen Zuweisungen im NonPagedPoolNx stammt, und da wir die Zuweisungsgröße kontrollieren können, werden wir die Daten, die wir leaken, bis zu einem gewissen Grad kontrollieren können.
Wenn also keine Authentifizierungsinformationen vorliegen, kann die Kernel-Adresse dann geleakt werden? Um diese Frage zu beantworten, lassen Sie uns tiefer in SMB eintauchen.
Bei der Authentifizierung sendet der Client die folgenden Nachrichten:
SMB2 NEGOTIATE → SMB2 SESSION_SETUP → SMB2 SESSION_SETUP
Wenn die Authentifizierungsinformationen falsch sind, wird die Verbindung nach dem zweiten SMB2 SESSION_SETUP-Paket abgebrochen:
Angenommen, wir haben keine Authentifizierungsinformationen, werden wir prüfen, ob es einen Befehl gibt, der ohne Authentifizierung gesendet werden kann. Durch die Suche stellen wir fest:
SMB2 NEGOTIATE und es ist auch der einzige SMB2 NEGOTIATE-Befehl während einer Sitzung.SMB2 SESSION_SETUP sein.