Processi IUM (Isolated User Mode)
Windows 10 ha introdotto una nuova funzionalità di sicurezza denominata Modalità di sicurezza virtuale (VSM). VSM sfrutta hypervisor Hyper-V e SLAT (Second Level Address Translation) per creare un set di modalità denominate VV (Virtual Trust Levels). Questa nuova architettura software crea un limite di sicurezza per impedire che i processi in esecuzione in una VTL accedano alla memoria di un'altra VTL. Il vantaggio di questo isolamento include una mitigazione aggiuntiva dagli exploit del kernel, proteggendo al tempo stesso asset come hash delle password e chiavi Kerberos.
Il diagramma 1 illustra il modello tradizionale della modalità kernel e il codice modalità utente in esecuzione rispettivamente nell'anello 0 della CPU e nell'anello 3. In questo nuovo modello, il codice in esecuzione nel modello tradizionale viene eseguito in VTL0 e non può accedere alla VTL1 con privilegi più elevati, in cui il kernel protetto e la modalità utente isolato (IUM) eseguono il codice. I vtls sono gerarchicamente significa che qualsiasi codice in esecuzione in VTL1 è più privilegiato del codice in esecuzione in VTL0.
L'isolamento VTL viene creato dall'Hypervisor Hyper-V che assegna memoria al momento dell'avvio usando SLAT (Second Level Address Translation). Continua in modo dinamico durante l'esecuzione del sistema, proteggendo la memoria del kernel sicuro che specifica la necessità di protezione da VTL0 perché verrà usata per contenere segreti. Poiché per i due VTL vengono allocati blocchi di memoria separati, viene creato un ambiente di runtime sicuro per VTL1 assegnando blocchi di memoria esclusivi a VTL1 e VTL0 con le autorizzazioni di accesso appropriate.
Diagramma 1 - Architettura di IUM
Trustlet
I trustlet (noti anche come processi attendibili, processi sicuri o processi IUM) sono programmi in esecuzione come processi IUM in VSM. Completano le chiamate di sistema eseguendo il marshalling al kernel Windows in esecuzione nel circuito VTL0 0. VSM crea un ambiente di esecuzione di piccole dimensioni che include il piccolo kernel protetto in esecuzione in VTL1 (isolato dal kernel e dai driver in esecuzione in VTL0). Il vantaggio di sicurezza chiaro è l'isolamento delle pagine in modalità utente trustlet in VTL1 dai driver in esecuzione nel kernel VTL0. Anche se la modalità kernel di VTL0 è compromessa da malware, non avrà accesso alle pagine del processo di IUM.
Con VSM abilitato, l'ambiente LSASS (Local Security Authority) viene eseguito come trustlet. LSASS gestisce i criteri di sistema locali, l'autenticazione utente e il controllo durante la gestione dei dati di sicurezza sensibili, ad esempio hash delle password e chiavi Kerberos. Per sfruttare i vantaggi di sicurezza di VSM, un trustlet denominato LSAISO.exe (LSA Isolated) viene eseguito in VTL1 e comunica con LSASS.exe in esecuzione in VTL0 tramite un canale RPC. I segreti LSAISO vengono crittografati prima di inviarli a LSASS in esecuzione in modalità normale VSM e le pagine di LSAISO sono protette da codice dannoso in esecuzione in VTL0.
Diagramma 2 - Progettazione trustlet LSASS
Implicazioni della modalità utente isolata
Non è possibile connettersi a un processo di IUM, impedendo la possibilità di eseguire il debug del codice VTL1. Sono inclusi il debug post mortem dei dump di memoria e il collegamento degli strumenti di debug per il debug in tempo reale. Include anche tentativi da parte di account con privilegi o driver kernel di caricare una DLL in un processo di IUM, di inserire un thread o di recapitare un APC in modalità utente. Tali tentativi possono comportare la destabilizzazione dell'intero sistema. Le API di Windows che comprometterebbero la sicurezza di un trustlet potrebbero non riuscire in modi imprevisti. Ad esempio, il caricamento di una DLL in un trustlet lo renderà disponibile in VTL0 ma non in VTL1. QueueUserApc può avere esito negativo in modo invisibile all'utente se il thread di destinazione si trova in un trustlet. Altre API, ad esempio CreateRemoteThread, VirtualAllocEx e Read/WriteProcessMemory, non funzioneranno come previsto quando vengono usate in Trustlet.
Usare il codice di esempio seguente per impedire di chiamare qualsiasi funzione che tenta di collegare o inserire codice in un processo di IUM. Sono inclusi i driver del kernel che accodano i controller di accesso per l'esecuzione del codice in un trustlet.
Commenti
Se lo stato restituito di IsSecureProcess ha esito positivo, esaminare il parametro SecureProcess _Out_ per determinare se il processo è un processo di IUM. I processi di IUM sono contrassegnati dal sistema come "Processi sicuri". Un risultato booleano true indica che il processo di destinazione è di tipo IUM.
NTSTATUS
IsSecureProcess(
_In_ HANDLE ProcessHandle,
_Out_ BOOLEAN *SecureProcess
)
{
NTSTATUS status;
// definition included in ntddk.h
PROCESS_EXTENDED_BASIC_INFORMATION extendedInfo = {0};
PAGED_CODE();
extendedInfo.Size = sizeof(extendedInfo);
// Query for the process information
status = ZwQueryInformationProcess(
ProcessHandle, ProcessBasicInformation, &extendedInfo,
sizeof(extendedInfo), NULL);
if (NT_SUCCESS(status)) {
*SecureProcess = (BOOLEAN)(extendedInfo.IsSecureProcess != 0);
}
return status;
}
WdK per Windows 10, "Windows Driver Kit - Windows 10.0.15063.0", contiene la definizione richiesta della struttura PROCESS_EXTENDED_BASIC_INFORMATION. La versione aggiornata della struttura è definita in ntddk.h con il nuovo campo IsSecureProcess.
typedef struct _PROCESS_EXTENDED_BASIC_INFORMATION {
SIZE_T Size; // Ignored as input, written with structure size on output
PROCESS_BASIC_INFORMATION BasicInfo;
union {
ULONG Flags;
struct {
ULONG IsProtectedProcess : 1;
ULONG IsWow64Process : 1;
ULONG IsProcessDeleting : 1;
ULONG IsCrossSessionCreate : 1;
ULONG IsFrozen : 1;
ULONG IsBackground : 1;
ULONG IsStronglyNamed : 1;
ULONG IsSecureProcess : 1;
ULONG IsSubsystemProcess : 1;
ULONG SpareBits : 23;
} DUMMYSTRUCTNAME;
} DUMMYUNIONNAME;
} PROCESS_EXTENDED_BASIC_INFORMATION, *PPROCESS_EXTENDED_BASIC_INFORMATION;