Suporte à Proteção Estendida para Autenticação (EPA) em um serviço

Artigo
10/21/2023

Recurso	Aplica-se a
EPA	todos os sistemas operacionais Windows suportados
Modo de auditoria da EPA	Windows Server 2019 Windows Server 2022 Windows Server 23H2

Qual é o problema?

Há uma classe de ataques a serviços autenticados chamada ataques de encaminhamento. Esses ataques permitem que os adversários ignorem a autenticação e atuem como outro usuário. Como esses são ataques ao serviço e não ao protocolo de autenticação em si, cabe ao serviço autenticado impedir ataques de encaminhamento.

Como funcionam os ataques de encaminhamento?

Quando um serviço ou aplicativo chama a API AcceptSecurityContext para autenticar um cliente, ele passa um blob de dados recebidos da chamada do cliente para InitializeSecurityContext. O protocolo de autenticação é responsável por verificar se o blob fornecido se originou do usuário indicado. AcceptSecurityContext não pode fazer afirmações sobre a autenticidade do restante da mensagem do aplicativo que ele não viu.

Um erro de segurança comum em aplicativos é tratar o tráfego do aplicativo como autenticado após uma autenticação bem-sucedida do blob de protocolo de autenticação interna. Isso geralmente ocorre com aplicativos que usam TLS para o protocolo de transmissão. O TLS geralmente não usa certificados de cliente; Ele fornece ao servidor garantias de integridade e confidencialidade, mas não autenticação. A autenticação interna fornece autenticação de cliente, mas apenas para seu blob. Ele não autentica o canal TLS ou o restante do protocolo de aplicativo contido nele.

Um invasor executa um ataque de encaminhamento inserindo um blob de autenticação de uma fonte com uma solicitação criada pelo invasor. Por exemplo, um invasor pode observar o tráfego de autenticação na rede e inseri-lo em sua própria solicitação ao servidor. Isso permite que o invasor obtenha acesso ao servidor como cliente a partir do tráfego de autenticação capturado.

O conceito-chave aqui é que as mensagens de autenticação SSPI são projetadas para serem expostas no fio; não se espera que sejam mantidos em segredo. Isso difere de muitos esquemas de autenticação baseados na Web que usam tokens de portador que são sempre mantidos confidenciais dentro dos canais TLS.

Qual é a solução?

A solução preferida é usar a chave de sessão do protocolo de autenticação para assinar ou criptografar (MakeSignature, EncryptMessage) outro tráfego. Como a chave de sessão é derivada criptograficamente durante a troca de protocolo de autenticação, seus dados autenticados e qualquer tráfego protegido por essa chave são garantidos como provenientes do cliente autenticado.

Nem sempre é uma opção. Em alguns casos, o formato da mensagem do protocolo de aplicativo é fixado por padrões projetados para tokens ao portador. Nesse caso, a Proteção Estendida para Autenticação (EPA), também conhecida como Associação de Canal, pode proteger contra o encaminhamento por um canal TLS/SSL.

O que é EPA?

O EPA vincula criptograficamente a chave de sessão TLS à chave de sessão do protocolo de autenticação, permitindo que o TLS forneça a mesma autenticação de cliente que a chave do protocolo de autenticação. Consulte Visão geral da proteção estendida para autenticação para obter mais informações.

associação de serviço

A segunda parte da EPA é chamada de Associação de Serviços. Ao contrário da Associação de Canal, isso não fornece ao serviço garantias criptográficas e serve como uma defesa do último recurso em que a associação de canal não é possível. Esse mecanismo permite que o servidor chame QueryContextAttributes para recuperar o atributo SECPKG_ATTR_CLIENT_SPECIFIED_TARGET que contém o nome que o cliente autenticado passou para InitializeSecurityContext.

Por exemplo, imagine um serviço que reside atrás de um balanceador de carga de encerramento do TLS. Ele não tem acesso à chave de sessão TLS e só pode determinar a partir da associação de canal que a autenticação do cliente foi destinada a um serviço protegido por TLS. O nome fornecido pelo cliente deve ser o mesmo usado para validar o certificado do servidor TLS. Ao verificar se o cliente estava autenticando em um nome correspondente ao certificado TLS do servidor do balanceador de carga, o serviço ganha alta confiança de que a autenticação veio do mesmo cliente que o canal TLS.

Este artigo não discutirá como oferecer suporte à associação de serviço. Consulte Como especificar uma ligação de serviço na configuração para obter mais informações.

Como você apoia a EPA?

Ao aplicar o EPA, os serviços podem notar que os clientes não conseguem se autenticar devido a problemas de compatibilidade. Portanto, criamos um modo de auditoria EPA onde os serviços podem habilitar a auditoria, dando aos administradores controles para observar como os clientes respondem antes de aplicar a EPA.

Os serviços da Microsoft que oferecem suporte ao modo de auditoria incluem:

LDAP

Observação

Abaixo você encontrará etapas opcionais para habilitar a funcionalidade de auditoria EPA. Observe que habilitar a funcionalidade de auditoria EPA sem aplicar a EPA não protege contra ataques de retransmissão. Recomendamos que os serviços que optarem por habilitar primeiro o EPA apenas no modo de auditoria, depois tomem medidas para corrigir clientes incompatíveis e, eventualmente, apliquem rigorosamente o EPA para evitar possíveis ataques de retransmissão.

Observação

As ligações de canal passadas para AcceptSecurityContext não precisam ser vinculações somente de auditoria para obter os resultados da auditoria. Os serviços podem executar o modo de auditoria enquanto ainda aplicam o EPA.

Cliente

Use QueryContextAttributes(TLS) para obter ligações de canal (preencher ponto de extremidade exclusivo vs ponto de extremidade)
Chame InitializeSecurityContext e passe associação de canal no SECBUFFER_CHANNEL_BINDINGS

Servidor

Use QueryContextAttributes(TLS), como no cliente
(Opcionalmente) Transforma em somente auditoria chamando SspiSetChannelBindingFlags
(Opcionalmente) Adicione buffer de resultado de associação de canal aos buffers de saída para ASC.
Especifique o nível EPA e outras configurações chamando AcceptSecurityContext com SECBUFFER_CHANNEL_BINDINGS
(Opcionalmente) Use sinalizadores para controlar o comportamento em casos de canto:
- ASC_REQ_ALLOW_MISSING_BINDINGS - Não falhe clientes que não disseram nada, como dispositivos antigos de terceiros. Os clientes esclarecidos que não receberam SECBUFFER_CHANNEL_BINDINGS enviarão uma associação vazia em vez de nada.
- ASC_REQ_PROXY_BINDINGS - Um caso raro para balanceadores de carga de terminação TLS. Não temos um SECBUFFER_CHANNEL_BINDINGS para passar, mas ainda queremos impor que os clientes coloquem a solicitação em um canal TLS. Isso é mais útil com ligações de serviço para garantir que o cliente também estava colocando em um canal TLS para o qual o certificado do servidor correspondia ao nosso nome.

Como aplicar a EPA?

Uma vez que um serviço oferece suporte ao EPA, os administradores podem controlar o estado do EPA desde a auditoria até a aplicação total. Isso dá aos serviços as ferramentas para avaliar a prontidão de seu ecossistema para a EPA, corrigir dispositivos incompatíveis e aplicar progressivamente a EPA para proteger seu meio ambiente.

Os seguintes atributos e valores podem ser usados para impor vários níveis de EPA em seu ambiente:

Nome	Descrição
Nenhuma	Nenhuma validação de associação de canal é executada. Esse é o comportamento de todos os servidores que não foram atualizados.
Permitir	Todos os clientes que foram atualizados devem fornecer informações de associação de canal ao servidor. Os clientes que não foram atualizados não precisam fazer isso. Essa é uma opção intermediária que permite a compatibilidade do aplicativo.
Requer	Todos os clientes devem fornecer informações de associação de canal. O servidor rejeita solicitações de autenticação de clientes que não o fazem.

Esses atributos podem ser combinados com a funcionalidade de auditoria para coletar informações sobre a compatibilidade do dispositivo em vários níveis de imposição da EPA. Você passará a configuração desejada para SspiSetChannelBindingFlags.

Auditoria - O modo de auditoria pode ser usado em conjunto com qualquer um dos níveis de aplicação da EPA acima.

Como interpreta os resultados da auditoria da EPA?

Os resultados da auditoria são um conjunto de sinalizadores de bits:

Sinalizador	Descrição
SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT	O cliente indicou que é capaz de ligações de canal.
SEC_CHANNEL_BINDINGS_RESULT_ABSENT	O cliente não forneceu associação a um canal externo.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH	As ligações do cliente indicam um canal diferente do servidor.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING	Falha na associação de canal devido a SEC_CHANNEL_BINDINGS_RESULT_ABSENT.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED	Os canais foram ligados com sucesso.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY	O cliente indicou a ligação a um canal externo, que passou devido a ASC_REQ_PROXY_BINDINGS.
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING	Associação de canal passada devido a ASC_REQ_ALLOW_MISSING_BINDINGS.

Há também definições para conjuntos de bits:

Sinalizador	Descrição
SEC_CHANNEL_BINDINGS_RESULT_VALID	Usado para testar todos os casos SEC_CHANNEL_BINDINGS_VALID_*.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID	Usado para testar todos os casos SEC_CHANNEL_BINDINGS_NOTVALID_*.

Fluxo de auditoria

Qualquer sistema operacional que suporte os resultados sempre definirá pelo menos um bit fora de SEC_CHANNEL_BINDINGS_RESULT_VALID e SEC_CHANNEL_BINDINGS_RESULT_NOTVALID.

Falha na associação de canal: teste para quaisquer bits do SEC_CHANNEL_BINDINGS_RESULT_NOTVALID. Para ligações que não são somente auditoria, isso corresponde à falha do ASC com STATUS_BAD_BINDINGS ou SEC_E_BAD_BINDINGS.

SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISMATCH: O cliente e o servidor sabem sobre ligações de canal, mas não concordam sobre o canal. Este é o caso de ataque ou uma configuração de segurança inadequada que é indistinguível de um ataque porque a configuração comprometeu HTTPS para inspecionar o tráfego (por exemplo, Fiddler). Também pode ser o cliente e o servidor discordando sobre ligações exclusivas versus de ponto de extremidade.
SEC_CHANNEL_BINDINGS_RESULT_NOTVALID_MISSING se divide em dois casos:
- Com SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, significa que o cliente atesta que sabe sobre ligações de canal e disse que não havia canal. Isso pode ser um ataque de encaminhamento de um serviço não-TLS, mas é provável que seja um aplicativo não habilitado em execução no cliente que está fazendo TLS, mas não informando à autenticação interna sobre isso.
- Sem SEC_CHANNEL_BINDINGS_RESULT_CLIENT_SUPPORT, é um cliente que não é capaz de ligações de canal. Todas as versões suportadas do Windows são capazes de ligação de canal, pelo que se trata de terceiros ou de um sistema que tenha o valor de registo SuppressExtendedProtection definido. Este é o caso que se transforma em SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING se você passar ASC_REQ_ALLOW_MISSING_BINDINGS.

Associação de canal bem-sucedida: este é o inverso da verificação de falha ou teste de SEC_CHANNEL_BINDINGS_RESULT_VALID.

SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED é o caso de sucesso. A proteção de segurança está funcionando (ou funcionaria se o EPA estivesse habilitado como somente auditoria).
SEC_CHANNEL_BINDINGS_RESULT_VALID_MISSING significa que ASC_REQ_ALLOW_MISSING_BINDINGS foi aprovada, então permitimos um cliente que não reivindicasse suporte para associação de canal. Os clientes que estão batendo neste caso não estão protegidos e devem ser investigados para ver o que está errado. Eles precisam ser atualizados para oferecer suporte à associação de canal ou o valor do registro SuppressExtendedProtection deve ser limpo assim que os aplicativos quebrados forem atualizados.
SEC_CHANNEL_BINDINGS_RESULT_VALID_PROXY é um caso especial associado ao sinalizador ASC_REQ_PROXY_BINDINGS que é usado quando o TLS é encerrado em um balanceador de carga em vez de chegar ao servidor. Não é possível para o servidor verificar se o cliente está usando a mesma conexão TLS que é encerrada no balanceador de carga. Para fins de auditoria, isso é tratado da mesma forma que SEC_CHANNEL_BINDINGS_RESULT_VALID_MATCHED.