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

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 offre l'autenticazione del client, ma solo per il suo blob. Non autentica il canale TLS o il resto del protocollo dell'applicazione contenuto.

Un attaccante esegue un attacco di inoltro inserendo un blob di autenticazione proveniente da una fonte con una richiesta creativa da parte dell'attaccante. 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.

Qual è 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), anche nota come Binding di canale, può proteggere 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 ulteriori informazioni, vedere la Panoramica della Protezione Estesa per l'autenticazione.

Collegamento di servizi

La seconda parte di EPA è denominata Service Binding. A differenza del binding del canale, questo non fornisce al servizio garanzie crittografiche e funge da difesa di ultima istanza quando il binding del canale non è possibile. Questo meccanismo consente al server di chiamare QueryContextAttributes per recuperare l'attributo SECPKG_ATTR_CLIENT_SPECIFIED_TARGET, che contiene il nome che il client autenticato ha passato a InitializeSecurityContext.

Si supponga, ad esempio, che un servizio risieda dietro un bilanciatore di carico che termina la connessione TLS. 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 si stia autenticando con un nome che corrisponde al certificato TLS del server verificato tramite il bilanciatore di carico, il servizio ottiene un'elevata affidabilità che l'autenticazione proviene dallo stesso client del canale TLS.

Questo articolo non illustra come supportare il binding dei servizi. Per ulteriori informazioni, consultare Come specificare un binding di servizio nella configurazione.

Come supporti 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.

I servizi Microsoft che supportano la modalità di controllo includono:

• LDAP

Cliente

1. Usare QueryContextAttributes(TLS) per ottenere le associazioni di canale (specificare se unico o endpoint)
2. Chiamare initializeSecurityContexte passare le associazioni di canale in SECBUFFER_CHANNEL_BINDINGS

Server

1. Usare QueryContextAttributes(TLS), come nel client
2. Opzionalmente, configura in modalità solo monitoraggio chiamando SspiSetChannelBindingFlags
3. (Facoltativamente) Aggiungere il buffer del risultato dell'associazione del canale ai buffer di output per ASC.
4. Specificare il livello EPA e altre configurazioni chiamando AcceptSecurityContext con SECBUFFER_CHANNEL_BINDINGS
5. Usare facoltativamente i flag per controllare il comportamento nei casi limite.
   • 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 informati che non hanno ricevuto SECBUFFER_CHANNEL_BINDINGS invieranno un binding vuoto invece che niente.
   • ASC_REQ_PROXY_BINDINGS: un caso raro per i bilanciatori di carico che terminano connessioni TLS. Non abbiamo un SECBUFFER_CHANNEL_BINDINGS da passare, ma vogliamo 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 anche utilizzando un canale TLS in cui il certificato del server sia conforme al nostro nome.

Come si applica l'EPA?

Una volta che un servizio supporta l'EPA, gli amministratori possono controllare lo stato dell'EPA dal monitoraggio all'applicazione completa. 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:

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 in 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 insieme di segnalatori di bit.

Esistono anche definizioni per i set di bit:

Flusso di controllo

Tutti i sistemi operativi che supportano i risultati impostano sempre almeno un bit di SEC_CHANNEL_BINDINGS_RESULT_VALID e SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.

associazione del canale non riuscita: Test per tutti i bit di SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. Per le associazioni che non sono solo di controllo, questo corrisponde al fallimento di Azure Security Center con STATUS_BAD_BINDINGS o SEC_E_BAD_BINDINGS.

• SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: Il client e il server conoscono entrambi le associazioni di canale, ma non concordano 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 che il client e il server non siano d'accordo sulla distinzione tra associazioni univoche e di endpoint.
• SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING si suddivide in due casi:
  • Con SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, significa che il client attesta che conosce le associazioni di canale e ha detto che non esiste alcun canale. Può trattarsi di un attacco di inoltro da un servizio non TLS, ma è probabile che si tratti di un'applicazione obsoleta in esecuzione sul client che esegue TLS, ma che non comunica all'autenticazione interna di farlo.
  • Senza SEC_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 viene trasformato in SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING se si passa ASC_REQ_ALLOW_MISSING_BINDINGS.

L'associazione di canale ha avuto esito positivo: Questo è l'inverso del controllo dell'esito negativo o della verifica del SEC_CHANNEL_BINDINGS_RESULT_VALID.

• SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED è il caso di esito positivo. La protezione della sicurezza funziona (o funzionerebbe se l'EPA fosse abilitato solo come controllo).
• SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING significa che ASC_REQ_ALLOW_MISSING_BINDINGS è stato passato come opzione, quindi abbiamo accettato un client che non ha dichiarato il supporto per l'associazione di canali. I clienti che si trovano in questa situazione non sono protetti e devono essere esaminati per individuare il problema. 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.
• SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY è un caso speciale associato al flag ASC_REQ_PROXY_BINDINGS usato quando la connessione TLS viene terminata presso un bilanciatore di 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 SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.

Vedere anche

AcceptSecurityContext

InitializeSecurityContext

MakeSignature

CrittografaMessaggio

QueryContextAttributes

Panoramica della Protezione Estesa per l'Autenticazione

Procedura: Specificare un'associazione del servizio nel file di configurazione