datntsec/cve-2020-1206Analisi tecnica della vulnerabilità di divulgazione di informazioni del kernel CVE-2020-1206 (SMBleed) in Windows SMBv3, inclusi l'oracolo di perdita di memoria non autenticato e le tecniche di sfruttamento in combinazione con SMBGhost per RCE.
Nella vulnerabilità SMBGhost (CVE-2020-0796) ho parlato di una tecnica di primitiva write-what-where attraverso l'uso di un bug di overflow integer per modificare il puntatore Alloc.Userbuffer in modo che punti a un indirizzo desiderato e scrivere dati arbitrari al suo interno. Similmente a SMB Ghost, questa vulnerabilità esiste anche nella funzione Srv2DecompressData in srv2.sys. Rivediamo la funzione Srv2DecompressData relativa alla vulnerabilità SMBGhost (CVE-2020-0796) semplificata da Zecops``` 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;
}
La funzione Srv2DecompressData riceve un messaggio compresso inviato dal client e procede ad allocare la memoria necessaria, decomprimendo il messaggio al suo interno. Successivamente, se il campo Offset è diverso da zero, copia i dati (RawData) che precedono i dati compressi all'inizio della memoria allocata.
Il bug SMBGhost risiede nel fatto che la funzione non verifica un integer overflow, portando ad un'allocazione di dimensione errata che causa un buffer overflow. Tre mesi dopo che Microsoft ha corretto SMBGhost, è stata scoperta la vulnerabilità CVE-2020-1206 (SMBleed - secondo la denominazione di [Zecops Blog](https://blog.zecops.com/)). Questa falla ci permette di leakare l'indirizzo di un'altra macchina e, se combinata con SMBGhost, possiamo ottenere RCE. Per avere una visione più semplice della funzione Srv2DecompressData, riutilizzeremo questa funzione quando non era ancora stata corretta la vulnerabilità SMBGhost e supporremo che sia stata corretta.
# Falsificazione di OriginalCompressedSegmentSize
Come per SMBGhost, anche questa volta falsificheremo OriginalCompressedSegmentSize con un numero leggermente maggiore rispetto ai dati decompressi che inviamo. Ad esempio, se comprimiamo dati di dimensione x byte, invece di impostare il campo OriginalCompressedSegmentSize a x, lo imposteremo a x + 0x1000, come mostrato nella figura seguente:
I dati del kernel non inizializzati verranno considerati come parte del messaggio.
Come ho detto nell'analisi di [CVE-2020-0796](https://github.com/datntsec/CVE-2020-0796), Srv2DecompressData salterà comunque la fase di controllo dopo la funzione SmbCompressionDecompress se la decompressione avviene con successo:``` c
if (Status < 0 || FinalCompressedSize != Header->OriginalCompressedSegmentSize) {
SrvNetFreeBuffer(Alloc);
return STATUS_BAD_DATA;
}
Sebbene il campo OriginalCompressedSegmentSize sia impostato a x + 0x1000 invece di x, dopo una decompressione riuscita, la variabile FinalCompressedSize non contiene il valore x, ma conterrà il valore 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.
# Sfruttamento di base
La struttura del messaggio utilizzata da Zecops per dimostrare la vulnerabilità è il [SMB2 WRITE message](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/e7046961-3318-4350-be2a-a8d69bb59ce8). Questa struttura contiene campi come il numero di byte scrivibili, flag, ..., seguiti da un buffer di lunghezza arbitraria. Ciò è abbastanza perfetto per sfruttare il bug, poiché possiamo creare un messaggio e specificare l'intestazione, con un buffer contenente dati non inizializzati.
Sulla base del POC di [Zecops](https://blog.zecops.com/) nel repository WindowsProtocolTestSuites di Microsoft, per avere un quadro più chiaro di ciò, aggiungeremo questa piccola integrazione alla funzione di compressione:``` c
// HACK: fake size
if (((Smb2SinglePacket)packet).Header.Command == Smb2Command.WRITE)
{
((Smb2WriteRequestPacket)packet).PayLoad.Length += 0x1000;
compressedPacket.Header.OriginalCompressedSegmentSize += 0x1000;
}
Notare che questo POC richiede credenziali e l'autorizzazione di scrittura condivisa, spesso disponibile in molti casi. Tuttavia, l'errore restituito si applica a ogni messaggio (inclusi messaggi con o senza credenziali), quindi è possibile sfruttare la vulnerabilità senza autenticazione. Un'altra cosa: la memoria che analizzeremo proviene da allocazioni precedenti in NonPagedPoolNx e, poiché possiamo controllare la dimensione dell'allocazione, avremo un certo controllo sui dati che verranno esposti.
Quindi, senza credenziali, è possibile esporre un indirizzo del kernel? Per rispondere a questa domanda, analizziamo SMB più a fondo.
Quando si autenticano le informazioni, il client invia i seguenti messaggi:
SMB2 NEGOTIATE → SMB2 SESSION_SETUP → SMB2 SESSION_SETUP
Se le credenziali sono errate, la connessione viene terminata dopo il secondo pacchetto SMB2 SESSION_SETUP:
Supponendo di non avere credenziali, controlliamo se esiste un comando che può essere inviato senza autenticazione. Cercando, notiamo:
SMB2 NEGOTIATE, ed è anche l'unico comando SMB2 NEGOTIATE durante l'intera sessione.SMB2 SESSION_SETUP.Il messaggio SMB2 NEGOTIATE non viene compresso. Il bug si trova nella funzione di decompressione, quindi non lo esamineremo, ma considereremo solo i messaggi SMB2 SESSION_SETUP.