Condividi tramite

Protezione dei servizi antimalware

  • Articolo

Windows 8.1 ha introdotto un nuovo concetto di servizi protetti per proteggere i servizi antimalware, che sono un bersaglio frequente di attacchi da malware.

Informazioni sulla protezione dei servizi in modalità utente antimalware (AM) e su come è possibile scegliere di includere questa funzionalità nel servizio antimalware.

Queste informazioni si applicano ai sistemi operativi seguenti e ai relativi successori:

  • Windows 8.1
  • Windows Server 2012 R2

I riferimenti e le risorse illustrati di seguito sono elencati alla fine di questo argomento.

Introduzione

La maggior parte delle soluzioni antimalware include un servizio in modalità utente che esegue operazioni specializzate per rilevare e rimuovere malware dal sistema. Questo servizio in modalità utente è anche spesso responsabile del download delle definizioni e delle firme di virus più recenti. Questo servizio in modalità utente diventa un bersaglio frequente di malware perché è il singolo punto di errore per disabilitare la protezione in un sistema. Per difendersi dagli attacchi al servizio in modalità utente, i fornitori di antimalware devono aggiungere un sacco di funzionalità e euristica al loro software. Tuttavia, tali tecniche non sono completamente infallibili e tendono a essere soggette a errori perché devono identificare le funzionalità eseguite da Windows sul proprio servizio e abilitare in modo selettivo tale funzionalità.

In Windows 8.1 è stato introdotto un nuovo concetto di servizio protetto per consentire l'avvio di servizi in modalità utente antimalware come servizio protetto. Dopo l'avvio del servizio come protetto, Windows usa l'integrità del codice per consentire solo il caricamento del codice attendibile nel servizio protetto. Windows protegge anche questi processi dall'inserimento di codice e da altri attacchi da processi di amministratore.

Questo documento descrive come un fornitore antimalware con un driver antimalware (ELAM) di avvio anticipato può acconsentire esplicitamente a questa funzionalità e avviare il servizio antimalware come servizio protetto.

Processo protetto dal sistema

A partire da Windows 8.1, è stato messo in atto un nuovo modello di sicurezza nel kernel per difendersi meglio da attacchi dannosi su componenti critici del sistema. Questo nuovo modello di sicurezza estende le versioni precedenti dell'infrastruttura di processo protetta di Windows usate per scenari specifici, ad esempio la riproduzione di contenuto DRM, in un modello generico che può essere usato dai fornitori antimalware di terze parti. L'infrastruttura del processo protetto consente solo il caricamento di codice firmato attendibile e include una difesa predefinita contro gli attacchi di inserimento del codice.

Nota

Le DLL di scripting seguenti non sono consentite da CodeIntegrity all'interno di un processo protetto (se caricato direttamente o indirettamente), ad esempio tramite WinVerifyTrust o WinVerifyTrustEx per controllare le firme di script tramite AuthentiCode: scrobj.dll, jscript9.dllscrrun.dlljscript.dll, , e .vbscript.dll

Per altre informazioni sui processi protetti, vedere Processi protetti in Windows Vista .

Il nuovo modello di sicurezza usa una variante leggermente diversa dell'infrastruttura del processo di protezione denominata processo protetto dal sistema, più adatta a questa funzionalità, in quanto mantiene separato il contenuto DRM. Ogni processo protetto dal sistema ha un livello o un attributo associato, che indica i criteri di firma del codice firmato consentito per il caricamento all'interno del processo. Dopo che i servizi antimalware hanno acconsento esplicitamente alla modalità del servizio protetto, solo il codice firmato o il codice firmato con i certificati del fornitore antimalware sono autorizzati a caricarsi in tale processo. Analogamente, altri livelli di processo protetti hanno criteri di codice diversi applicati da Windows.

Requisiti

Affinché un servizio in modalità utente antimalware venga eseguito come servizio protetto, il fornitore antimalware deve avere un driver ELAM installato nel computer Windows. Oltre ai requisiti di certificazione del driver ELAM esistenti, il driver deve avere una sezione di risorse incorporata contenente le informazioni dei certificati usati per firmare i file binari del servizio in modalità utente.

Importante

In Windows 8.1, la catena di certificazione deve essere una radice nota come determinata dalla verifica del driver o deve essere incluso il certificato radice.

Durante il processo di avvio, questa sezione della risorsa verrà estratta dal driver ELAM per convalidare le informazioni sul certificato e registrare il servizio antimalware. Il servizio antimalware può anche essere registrato durante il processo di installazione del software antimalware chiamando un'API speciale, come descritto più avanti in questo documento.

Dopo che la sezione della risorsa è stata estratta correttamente dal driver ELAM e il servizio in modalità utente è registrato, il servizio può essere avviato come servizio protetto. Dopo l'avvio del servizio come protetto, altri processi non protetti nel sistema non saranno in grado di inserire thread e non potranno scrivere nella memoria virtuale del processo protetto.

Inoltre, tutte le DLL non Windows caricate nel processo protetto devono essere firmate con un certificato appropriato.

Per altre informazioni sui driver ELAM, vedere Antimalware di avvio anticipato.

Requisiti di firma del servizio antimalware

Il servizio in modalità utente che deve essere avviato come protetto deve essere firmato con certificati validi. Il file EXE del servizio deve essere con segno hash di pagina e tutte le DLL non Windows caricate nel servizio devono essere firmate anche con gli stessi certificati. L'hash di questi certificati deve essere aggiunto nel file di risorse, che verrà collegato al driver ELAM.

Nota

È necessario usare hash di file/pagine SHA256, anche se i certificati possono continuare a essere SHA1.

È consigliabile che i fornitori antimalware usino il certificato Authenticode esistente per firmare i file binari del servizio antimalware e che l'hash di questo certificato Authenticode sia incluso nella sezione delle risorse per indicare il certificato usato per firmare i file binari del servizio. Se si aggiorna questo certificato, è necessario rilasciare una versione più recente del driver ELAM con gli hash del certificato aggiornati.

Firma secondaria (facoltativa)

I fornitori di antimalware hanno la possibilità di configurare una CA privata e di usare i certificati da questa CA per firmare i file binari del servizio antimalware come firma secondaria. Il vantaggio principale dell'uso della CA privata è che consente ai fornitori di creare certificati con una proprietà EKU specializzata, che può essere usata per distinguere più prodotti dallo stesso fornitore. Riduce inoltre la necessità di aggiornare il driver ELAM a causa della scadenza del certificato, perché i certificati della CA privata in genere hanno date di scadenza più lunghe.

Si noti che se i file binari del servizio sono firmati con i certificati CA privati, i file binari devono essere firmati anche con i certificati Authenticode esistenti. Se i file binari non sono firmati da una CA attendibile nota (ad esempio VeriSign), l'utente del computer non ha fiducia nei file binari perché non può considerare attendibile la CA privata. La doppia firma dei file binari con il certificato Authenticode esistente consente anche l'esecuzione dei file binari nei sistemi operativi di livello inferiore.

Per altre informazioni su come configurare e installare l'autorità di certificazione, vedere Configurazione di un'autorità di certificazione e Installazione dell'autorità di certificazione.

Nota

Per la compatibilità con Windows Vista o Windows XP (o Windows 7 senza la patch SHA2), è possibile usare l'opzione "/as" quando si firmano i file binari con SignTool.exe con gli hash di file/pagina SHA256. Verrà aggiunta la firma come firma secondaria al file. SHA1 firma prima il file, poiché Windows XP, Windows Vista e Windows 7 visualizzeranno solo la prima firma.

Requisiti di firma della DLL

Come accennato in precedenza, tutte le DLL non Windows caricate nel servizio protetto devono essere firmate con lo stesso certificato usato per firmare il servizio antimalware.

Firma del catalogo

I fornitori di antimalware possono includere pacchetti sviluppati da altre aziende senza aggiornare le firme binarie. A tale scopo, è possibile includere i file binari in un catalogo firmato con il certificato Authenticode, seguendo questa procedura:

  1. Generare un catalogo usando MakeCat
  2. Aggiungere tutti i file binari senza una firma appropriata al catalogo
  3. Firmare il catalogo con il certificato Authenticode, come qualsiasi altro file binario
  4. Usare la funzione add catalog per includere il catalogo con l'applicazione.

Quando l'integrità del codice si trova nei pacchetti senza una firma appropriata, cercherà un catalogo con una firma approvata. Il catalogo sarà disponibile finché questi passaggi vengono seguiti e installati con l'applicazione.

Informazioni sul file di risorse

È necessario creare e collegare un file di risorse al driver ELAM. L'hash del certificato, insieme ad altre informazioni sul certificato, deve essere aggiunto nel file di risorse.

La sezione della risorsa deve essere nel layout seguente per consentire al sistema di estrarre correttamente le risorse dall'immagine binaria e convalidare le informazioni sul certificato incorporato.

MicrosoftElamCertificateInfo  MSElamCertInfoID
{
      3, // count of entries
      L”CertHash1\0”,
      Algorithm,
      L”EKU1\0”,
      L”CertHash2\0”,
      Algorithm,
      L”\0”, //No EKU for cert hash 2
      L”CertHash3\0”,
      Algorithm,
      L”EKU3a;EKU3b;EKU3c\0”,  //multiple EKU entries supported (max: 3)
}

Per altre informazioni sul file di risorse definito dall'utente, vedi Risorsa definita dall'utente.

CertHash

Hash del certificato usato per firmare il servizio antimalware. Lo strumento CertUtil.exe fornito in Windows SDK può essere usato per ottenere l'hash.

certutil.exe –v <path to the signed file>

Ad esempio:

anti-malware protected service certificate hash (certhash)

Algoritmo

Il valore dell'algoritmo rappresenta l'algoritmo del certificato. Questi valori dell'algoritmo sono supportati:

0x8004 – SHA1 0x800c – SHA256 0X800d – SHA384 0x800e – SHA512

Ricordarsi di includere il valore dell'algoritmo (come illustrato in precedenza) e non il nome effettivo dell'algoritmo. Ad esempio, se il certificato è basato sull'algoritmo SHA256, includere 0x800c nella sezione della risorsa.

EKU

L'oggetto EKU rappresenta una singola proprietà EKU (Extended Key Usage) di un certificato. Questa opzione è facoltativa e è necessario specificare "\0" se al certificato non sono associate unità EKU. In un caso in cui siano presenti più prodotti e servizi di un singolo fornitore antimalware in esecuzione nello stesso sistema, il fornitore antimalware può usare la proprietà EKU del certificato CA privato per differenziare un servizio da un altro. Ad esempio, se nel sistema sono in esecuzione due servizi dello stesso fornitore antimalware e firmati dalla stessa CA, il servizio che deve essere avviato come protetto può essere firmato con un certificato rilasciato dalla CA che contiene un EKU speciale. Questo EKU deve essere aggiunto alla sezione della risorsa. L'EKU viene quindi registrato dal sistema e associato all'hash del certificato per la convalida e l'avvio del servizio come protetto.

Si noti che la catena di certificati deve includere l'EKU per la firma del codice (1.3.6.1.5.5.7.3.3), ma questo EKU non deve essere incluso nella sezione della risorsa del driver ELAM.

Nota

Se le informazioni EKU sono incluse nelle informazioni sul certificato per il driver ELAM, è necessario usare lo stesso EKU durante la firma dei file binari.

Nota

La rappresentazione di stringa dell'integrità del codice di Windows di un OID in un EKU ha una lunghezza massima di 64 caratteri, incluso il carattere di terminazione zero.  

Nota

Se si specificano più EKU, questi vengono valutati con AND la logica. Il certificato dell'entità finale deve soddisfare tutte le EKU specificate nella sezione della risorsa ELAM per la voce specificata.

Conteggio

Se il file binario del servizio antimalware è firmato con il certificato Authenticode e il certificato CA privato, nella sezione della risorsa devono essere aggiunte solo le informazioni sul certificato ca privato.

Avvio di servizi antimalware come protetti

Registrazione del servizio

Il servizio antimalware deve essere registrato con il sistema prima di poter essere avviato come protetto. Durante l'installazione del software antimalware, il programma di installazione può installare il driver ELAM e riavviare il sistema per registrare automaticamente il servizio. Il sistema registrerà il servizio in fase di avvio estraendo le informazioni sul certificato dal file di risorse menzionato in precedenza collegato al driver ELAM.

Durante la fase di installazione, è consigliabile riavviare il sistema affinché il driver ELAM venga caricato e convalidato lo stato del sistema. Tuttavia, nei casi in cui è necessario evitare un riavvio, Windows espone anche un meccanismo per il programma di installazione antimalware per registrare il servizio come protetto tramite un'API.

Registrazione del servizio senza riavviare il sistema

Durante l'installazione, un programma di installazione software antimalware può chiamare l'API InstallELAMCertificateInfo e fornire un handle al file del driver ELAM. Il sistema apre il driver ELAM, chiama routine interne per assicurarsi che il driver ELAM sia firmato correttamente ed estrae le informazioni sul certificato dalla sezione della risorsa associata al driver ELAM. Per la sintassi della funzione, vedere InstallELAMCertificateInfo.

Esempio di codice:

HANDLE FileHandle = NULL;

FileHandle = CreateFile(<Insert Elam driver file name>,
                        FILE_READ_DATA,
                        FILE_SHARE_READ,
                        NULL,
                        OPEN_EXISTING,
                        FILE_ATTRIBUTE_NORMAL,
                        NULL
                        );

if (InstallElamCertificateInfo(FileHandle) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

Avvio del servizio come protetto

Il programma di installazione può seguire questa procedura per creare, configurare e avviare il servizio come protetto:

  1. Chiamare l'API CreateService per creare un oggetto servizio e aggiungerlo al database SCM (Service Control Manager).

  2. Chiamare l'API SetServiceObjectSecurity per impostare il descrittore di sicurezza dell'oggetto servizio creato nel passaggio 1.

  3. Chiamare l'API ChangeServiceConfig2 per contrassegnare il servizio come protetto, specificando il nuovo valore di enumerazione edizione StandardRVICE_CONFIG_LAUNCH_PROTECTED aggiunto in Winsvc.h (a partire da Windows 8.1).

    Esempio di codice:

    SERVICE_LAUNCH_PROTECTED_INFO Info;
SC_HANDLE hService;

Info.dwLaunchProtected = SERVICE_LAUNCH_PROTECTED_ANTIMALWARE_LIGHT;

hService = CreateService (/* ... */);

if (ChangeServiceConfig2(hService,
                         SERVICE_CONFIG_LAUNCH_PROTECTED,
                         &Info) == FALSE)
{
    Result = GetLastError();
}

  4. Chiamare l'API StartService per avviare il servizio. Quando si avvia il servizio come protetto, SCM controlla con il sottosistema di integrità del codice (CI) per convalidare le informazioni sul certificato. Dopo aver convalidato le informazioni sul certificato da CI, SCM avvia il servizio come protetto.

    1. Si noti che questo passaggio ha esito negativo se il servizio non è stato registrato chiamando l'API InstallELAMCertificateInfo .
    2. Se il servizio è stato configurato per l'avvio automatico durante la fase di avvio del sistema, è possibile evitare questo passaggio e riavviare semplicemente il sistema. Durante un riavvio, il sistema registra automaticamente il servizio (se il driver ELAM viene avviato correttamente) e avvia il servizio in modalità protetta.
    3. Se l'avvio del servizio non riesce, vedere le informazioni in Registrazione eventi di integrità del codice e controllo del sistema e gli argomenti seguenti. Sono disponibili messaggi di errore più dettagliati che spiegano perché il sistema di integrità del codice ha impedito l'avvio del servizio. Questi log consentono anche di identificare le DLL che il servizio ha tentato di caricare ma che non è stato possibile.

Avvio di un processo figlio come protetto

Il nuovo modello di sicurezza consente anche ai servizi protetti antimalware di avviare processi figlio come protetti. Questi processi figlio verranno eseguiti allo stesso livello di protezione del servizio padre e i relativi file binari devono essere firmati con lo stesso certificato registrato tramite la sezione della risorsa ELAM.

Per consentire al servizio protetto da antimalware di avviare il processo figlio come protetto, è stata esposta una nuova chiave dell'attributo estesa, PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL, e deve essere usata con l'API UpdateProcThreadAttribute. Un puntatore al valore dell'attributo di PROTECTION_LEVEL_SAME deve essere passato all'API UpdateProcThreadAttribute .

Note:

  • Per usare questo nuovo attributo, il servizio deve anche specificare CREATE_PROTECTED_PROCESS nel parametro flag di creazione del processo della chiamata CreateProcess.
  • È necessario che i file binari del servizio siano firmati usando l'opzione /ac per includere il certificato incrociato per concatenarlo a una CA nota. Il certificato autofirmato senza il concatenamento corretto a una CA radice nota non funzionerà.

Esempio di codice:

DWORD ProtectionLevel = PROTECTION_LEVEL_SAME;
SIZE_T AttributeListSize;

STARTUPINFOEXW StartupInfoEx = { 0 };

StartupInfoEx.StartupInfo.cb = sizeof(StartupInfoEx);

if (InitializeProcThreadAttributeList(NULL,
                                      1,
                                      0,
                                      &AttributeListSize) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

StartupInfoEx.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST) HeapAlloc(
    GetProcessHeap(),
    0,
    AttributeListSize
    );

if (InitializeProcThreadAttributeList(StartupInfoEx.lpAttributeList,
                                      1,
                                      0,
                                      &AttributeListSize) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

if (UpdateProcThreadAttribute(StartupInfoEx.lpAttributeList,
                              0,
                              PROC_THREAD_ATTRIBUTE_PROTECTION_LEVEL,
                              &ProtectionLevel,
                              sizeof(ProtectionLevel),
                              NULL,
                              NULL) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

PROCESS_INFORMATION ProcessInformation = { 0 };

if (CreateProcessW(ApplicationName,
                   CommandLine,
                   ProcessAttributes,
                   ThreadAttributes,
                   InheritHandles,
                   EXTENDED_STARTUPINFO_PRESENT | CREATE_PROTECTED_PROCESS,
                   Environment,
                   CurrentDirectory,
                   (LPSTARTUPINFOW)&StartupInfoEx,
                   &ProcessInformation) == FALSE)
{
    Result = GetLastError();
    goto exitFunc;
}

Aggiornamenti e manutenzione

Dopo l'avvio del servizio antimalware come protetto, altri processi non protetti (e persino amministratori) non sono in grado di arrestare il servizio. Nel caso di aggiornamenti ai file binari del servizio, il servizio antimalware deve ricevere un callback dal programma di installazione per arrestarsi in modo che possa essere risolto. Dopo l'arresto del servizio, il programma di installazione antimalware può eseguire gli aggiornamenti e quindi seguire i passaggi descritti in precedenza nelle sezioni Registrazione del servizio e Avvio del servizio come protetto per registrare il certificato e avviare il servizio come protetto.

Si noti che il servizio deve garantire che solo i chiamanti attendibili possano arrestare il servizio. Consentire ai chiamanti non attendibili di farlo sconfigge lo scopo di proteggere il servizio.

Annullamento della registrazione del servizio

Quando si disinstalla un servizio protetto, il servizio deve contrassegnarsi come non protetto chiamando l'API ChangeServiceConfig2 . Si noti che poiché il sistema non consente a alcun processo non protetto di modificare la configurazione di un servizio protetto, la chiamata a ChangeServiceConfig2 deve essere effettuata dal servizio protetto stesso. Dopo che il servizio è stato riconfigurato per l'esecuzione come non protetto, il programma di disinstallazione può semplicemente eseguire i passaggi appropriati per rimuovere il software antimalware dal sistema.

Debug di un servizio protetto da antimalware

Come parte del modello di sicurezza del processo protetto, altri processi non protetti non sono in grado di inserire thread o scrivere nella memoria virtuale del processo protetto. Tuttavia, un debugger del kernel (KD) è consentito per il debug di qualsiasi processo protetto da antimalware. Il KD può essere usato anche per verificare se il servizio antimalware è in esecuzione come protetto o meno:

dt –r1 nt!_EPROCESS <Process Address>
+0x67a Protection       : _PS_PROTECTION
      +0x000 Level            : 0x31 '1'
      +0x000 Type             : 0y0001
      +0x000 Signer           : 0y0011

Se il valore del membro Type è 0y0001, il servizio viene eseguito come protetto.

Inoltre, solo i comandi SC seguenti sono consentiti nel servizio protetto da antimalware:

  • sc config start=Auto
  • sc qc
  • sc start
  • sc interrogate
  • sc sdshow

Se il debugger è collegato, usare il flag seguente nel Registro di sistema per interrompere il debugger quando i file binari non firmati (o firmati in modo non appropriato) vengono caricati nel servizio protetto da antimalware.

Key:   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI
Value: DebugFlags      REG_DWORD

Impostare il valore su 00000400 per interrompere il debugger quando la convalida della firma non riesce.

Nota

Limitazioni del processo protetto:

  1. I processi con interfaccia utente o GUI non possono essere protetti a causa del modo in cui il kernel blocca un processo in memoria e non consente scritture in esso.
  2. Prima di Windows 10 versione 1703 (Creators Update), i processi protetti non possono usare i protocolli di comunicazione TLS o SSL a causa delle limitazioni della condivisione dei certificati tra l'Autorità di sicurezza locale (LSA) e un processo protetto.

Risorse

Per altre info, vedi:

In questo articolo viene fatto riferimento a queste funzioni API di Windows: