Supporto della protezione estesa per l'autenticazione (EPA) in un servizio

Articolo
10/18/2023

Funzionalità	Si applica a
EPA	tutti i sistemi operativi Windows supportati
Modalità di controllo EPA	Windows Server 2019 Windows Server 2022 Windows Server 23H2

Qual è il problema?

Esiste una classe di attacchi sui servizi autenticati chiamati attacchi di inoltro. Questi attacchi consentono agli avversari di ignorare l'autenticazione e di agire come un altro utente. Poiché si tratta di attacchi sul servizio e non del protocollo di autenticazione stesso, spetta al servizio autenticato contrastare gli attacchi di inoltro.

Come funzionano gli attacchi di inoltro?

Quando un servizio o un'applicazione chiama l'API AcceptSecurityContext per autenticare un client, passa un BLOB di dati ricevuti dalla chiamata del client a InitializeSecurityContext. Il protocollo di autenticazione è responsabile della verifica dell'origine del BLOB fornito dall'utente indicato. AcceptSecurityContext non può eseguire asserzioni sull'autenticità del resto del messaggio dell'applicazione che non è stato visualizzato.

Un errore di sicurezza comune nelle applicazioni consiste nel considerare il traffico dell'applicazione come autenticato dopo un'autenticazione corretta del BLOB del protocollo di autenticazione interna. Questo problema si verifica più comunemente con le applicazioni che usano TLS per il protocollo di collegamento. TLS in genere non usa certificati client; fornisce al server garanzie di integrità e riservatezza, ma non l'autenticazione. L'autenticazione interna fornisce l'autenticazione client, ma solo per il BLOB. Non autentica il canale TLS o il resto del protocollo dell'applicazione contenuto.

Un utente malintenzionato esegue un attacco di inoltro inserendo un BLOB di autenticazione da un'origine con una richiesta creata da un utente malintenzionato. Ad esempio, un utente malintenzionato può osservare il traffico di autenticazione sulla rete e inserirlo nella propria richiesta al server. Ciò consente all'utente malintenzionato di ottenere l'accesso al server come client dal traffico di autenticazione acquisito.

Il concetto chiave è che i messaggi di autenticazione SSPI sono progettati per essere esposti in rete; non dovrebbero essere mantenuti segreti. Ciò differisce da molti schemi di autenticazione basati sul Web che usano token di connessione che vengono sempre mantenuti riservati all'interno dei canali TLS.

In cosa consiste la soluzione?

La soluzione preferita consiste nell'usare la chiave di sessione del protocollo di autenticazione per firmare o crittografare (MakeSignature, EncryptMessage) altro traffico. Poiché la chiave di sessione è derivata crittograficamente durante lo scambio del protocollo di autenticazione, i dati autenticati e il traffico protetto da tale chiave viene garantito che provengano dal client autenticato.

Questa non è sempre un'opzione. In alcuni casi, il formato del messaggio del protocollo dell'applicazione è fisso dagli standard progettati per i token di connessione. In questo caso, la protezione estesa per l'autenticazione (EPA), nota anche come Associazione di canali, può proteggersi dall'inoltro su un canale TLS/SSL.

Che cos'è EPA?

EPA associa crittograficamente la chiave di sessione TLS alla chiave di sessione del protocollo di autenticazione, consentendo a TLS di fornire la stessa autenticazione client della chiave del protocollo di autenticazione. Per altre informazioni, vedere Panoramica della protezione estesa per l'autenticazione.

associazione al servizio

La seconda parte di EPA è denominata Service Binding. A differenza dell'associazione di canali, questo non fornisce al servizio garanzie di crittografia e funge da difesa dell'ultima risorsa in cui l'associazione di canale non è possibile. Questo meccanismo consente al server di chiamare QueryContextAttributes per recuperare l'attributo edizione StandardCPKG_ATTR_CLIENT_SPECIFIED_TARGET che contiene il nome del client autenticato passato a InitializeSecurityContext.

Si supponga, ad esempio, che un servizio che si trovi dietro un servizio tls che termina il servizio di bilanciamento del carico. Non ha accesso alla chiave di sessione TLS e può determinare solo dall'associazione di canale che l'autenticazione del client è stata destinata a un servizio protetto TLS. Il nome fornito dal client deve essere lo stesso nome usato per convalidare il certificato del server TLS. Verificando che il client sia stato autenticato in un nome corrispondente al certificato TLS del server dal servizio di bilanciamento del carico, il servizio ottiene una maggiore attendibilità che l'autenticazione proviene dallo stesso client del canale TLS.

Questo articolo non illustra come supportare l'associazione al servizio. Per altre informazioni, vedere Procedura: Specificare un'associazione di servizi in Configurazione .

Come si supporta EPA?

Quando si applica EPA, i servizi potrebbero notare che i client non riescono a eseguire l'autenticazione a causa di problemi di compatibilità. Pertanto, è stata creata una modalità di controllo EPA in cui i servizi possono abilitare il controllo, fornendo agli amministratori controlli per osservare come i client rispondono prima di applicare EPA.

servizi Microsoft modalità di controllo di supporto includono:

LDAP

Nota

Di seguito sono riportati i passaggi facoltativi per abilitare la funzionalità di controllo EPA. Si noti che l'abilitazione della funzionalità di controllo EPA senza applicare EPA non protegge dagli attacchi di inoltro. È consigliabile che i servizi che scelgono di abilitare prima EPA solo in modalità di controllo, in seguito eseguano i passaggi per correggere i client incompatibili e infine imporre rigorosamente EPA per evitare potenziali attacchi di inoltro.

Nota

Le associazioni di canale passate in AcceptSecurityContext non devono essere associazioni di sola controllo per ottenere i risultati del controllo. I servizi possono eseguire la modalità di controllo durante l'applicazione dell'EPA.

Client

Usare QueryContextAttributes(TLS) per ottenere le associazioni di canale (compilare un endpoint univoco o finale)
Chiamare InitializeSecurityContext e passare associazioni di canale in edizione StandardCBUFFER_CHANNEL_BINDINGS

Server

Usare QueryContextAttributes(TLS), come nel client
(Facoltativamente) Esegue il controllo solo chiamando SspiSetChannelBindingFlags
(Facoltativamente) Aggiungere il buffer dei risultati dell'associazione del canale ai buffer di output per il Centro sicurezza di Azure.
Specificare il livello EPA e altre configurazioni chiamando AcceptSecurityContext con edizione StandardCBUFFER_CHANNEL_BINDINGS
(Facoltativamente) Usare i flag per controllare il comportamento nei casi di angolo:
- ASC_REQ_ALLOW_MISSING_BINDINGS: non eseguire errori nei client che non hanno detto nulla, come i dispositivi di terze parti meno vecchi. I client con riconoscimento dei dati che non hanno avuto edizione StandardCBUFFER_CHANNEL_BINDINGS invieranno un'associazione vuota anziché nulla.
- ASC_REQ_PROXY_BINDINGS: caso raro per i servizi di bilanciamento del carico di terminazione TLS. Non è disponibile un edizione StandardCBUFFER_CHANNEL_BINDINGS da passare, ma si vuole comunque imporre che i client inseriscano la richiesta in un canale TLS. Ciò è più utile con le associazioni di servizio per assicurarsi che il client stia inserendo anche in un canale TLS per il quale il certificato del server corrisponde al nome.

Come si applica L'EPA?

Una volta che un servizio supporta EPA, gli amministratori possono controllare lo stato EPA fino all'intero controllo. Ciò offre ai servizi gli strumenti per valutare l'idoneità dell'ecosistema per EPA, correggere i dispositivi incompatibili e applicare progressivamente EPA per proteggere il proprio ambiente.

Gli attributi e i valori seguenti possono essere usati per applicare vari livelli di EPA nell'ambiente:

Nome	Descrizione
Nessuna	Non viene eseguita alcuna convalida dell'associazione di canale. Questo comportamento è tipico di tutti i server che non sono stati aggiornati.
Consenti	Tutti i client che sono stati aggiornati devono inviare informazioni di associazione del canale al server, a differenza di quelli che non sono stati aggiornati. Questa è un'opzione di protezione intermedia che consente la compatibilità tra le applicazioni.
Richiedi	Tutti i client devono inviare informazioni di associazione del canale al server, Il server rifiuterà le richiese di autenticazione ai client che non eseguono questa operazione.

Questi attributi possono essere associati alla funzionalità di controllo per raccogliere informazioni sulla compatibilità dei dispositivi a vari livelli di imposizione dell'EPA. La configurazione desiderata verrà passata a SspiSetChannelBindingFlags.

Audit : la modalità di controllo può essere usata insieme a uno dei livelli di imposizione EPA precedenti.

Come si interpretano i risultati del controllo EPA?

I risultati del controllo sono un set di flag di bit:

Flag	Descrizione
edizione StandardC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT	Il client ha indicato che è in grado di eseguire associazioni di canale.
edizione StandardC_CHANNEL_BINDINGS_RESULT_ABedizione Standard NT	Il client non ha fornito l'associazione a un canale esterno.
edizione StandardC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH	Le associazioni client indicano un canale diverso rispetto al server.
edizione StandardC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING	L'associazione del canale non è riuscita a causa di edizione StandardC_CHANNEL_BINDINGS_RESULT_ABedizione Standard NT.
edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED	I canali sono stati associati correttamente.
edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	Il client ha indicato l'associazione a un canale esterno, che è passato a causa di ASC_REQ_PROXY_BINDINGS.
edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID_MISSING	Associazione di canale passata a causa di ASC_REQ_ALLOW_MISSING_BINDINGS.

Esistono anche definizioni per i set di bit:

Flag	Descrizione
edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID	Usato per testare tutti i casi edizione StandardC_CHANNEL_BINDINGS_VALID_*.
edizione StandardC_CHANNEL_BINDINGS_RESULT_NOTVALID	Usato per testare tutti i casi edizione StandardC_CHANNEL_BINDINGS_NOTVALID_*.

Flusso di controllo

Qualsiasi sistema operativo che supporta i risultati imposta sempre almeno un bit di edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID e edizione StandardC_CHANNEL_BINDINGS_RESULT_NOTVALID.

Associazione di canale non riuscita: eseguire il test per eventuali bit di edizione StandardC_CHANNEL_BINDINGS_RESULT_NOTVALID. Per le associazioni che non sono solo di controllo, corrisponde all'errore del Centro sicurezza di Azure con STATUS_BAD_BINDINGS o edizione StandardC_E_BAD_BINDINGS.

edizione StandardC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: Il client e il server conoscono entrambe le associazioni di canale, ma non sono d'accordo sul canale. Questo è il caso di attacco o una configurazione di sicurezza non corretta che è indistinguibile da un attacco perché la configurazione ha compromesso HTTPS per controllare il traffico (ad esempio Fiddler). Potrebbe anche essere il client e il server in disaccordo rispetto alle associazioni di endpoint univoche.
edizione StandardC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING suddivide in due casi:
- Con edizione StandardC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, significa che il client attesta che conosce le associazioni di canale e ha detto che non c'era alcun canale. Può trattarsi di un attacco di inoltro da un servizio non TLS, ma è probabile che si tratti di un'applicazione non illuminata in esecuzione sul client che esegue TLS, ma che non indica l'autenticazione interna.
- Senza edizione StandardC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, si tratta di un client che non è in grado di eseguire associazioni di canale. Tutte le versioni di Windows supportate sono in grado di eseguire l'associazione di canali, quindi si tratta di terze parti o di un sistema con il valore del Registro di sistema SuppressExtendedProtection impostato. Questo è il caso che si trasforma in edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID_MISSING se si passa ASC_REQ_ALLOW_MISSING_BINDINGS.

Associazione di canale riuscita: si tratta dell'inversa del controllo dell'esito negativo o del test per edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID.

edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED è il caso di esito positivo. La protezione della sicurezza funziona (o funziona se EPA è abilitato come solo controllo).
edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID_MISSING significa che ASC_REQ_ALLOW_MISSING_BINDINGS è stato passato, quindi è stato consentito a un client che non ha richiesto il supporto per l'associazione di canali. I client che colpiscono questo caso non sono protetti e devono essere esaminati per vedere cosa c'è di sbagliato. Devono essere aggiornati per supportare l'associazione di canali oppure il valore del Registro di sistema SuppressExtendedProtection deve essere cancellato dopo l'aggiornamento delle applicazioni interrotte.
edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID_PROXY è un caso speciale associato al flag ASC_REQ_PROXY_BINDINGS usato quando TLS viene terminato in un servizio di bilanciamento del carico anziché raggiungere il server. Non è possibile che il server verifichi che il client usi la stessa connessione TLS terminata nel servizio di bilanciamento del carico. Ai fini del controllo, questo viene considerato uguale a edizione StandardC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.