Conheça o Silver SAML: Golden SAML na nuvem

Principais conclusões

• O Golden SAML, uma técnica de ataque que explora o protocolo de início de sessão único SAML, foi utilizado como uma exploração pós-violação, agravando o devastador ataque da SolarWinds de 2020 - uma das maiores violações do século XXI.
• O ataque da cadeia de fornecimento da SolarWinds afectou milhares de organizações em todo o mundo, incluindo o Governo dos EUA, através da implementação de código malicioso no software de gestão e monitorização de TI Orion da empresa.
• Na sequência desse ataque, a CISA e os especialistas em segurança cibernética incentivaram as organizações com ambientes de identidade híbrida a mover a autenticação SAML para um sistema de identidade em nuvem, como o Entra ID.
• Os investigadores da Semperis, Tomer Nahum e Eric Woodruff, descobriram uma nova aplicação do Golden SAML, que pode ser explorada mesmo em organizações que seguiram as recomendações de segurança anteriores para se defenderem do Golden SAML.
• A nova técnica de ataque, denominada Silver SAML, permite a exploração do SAML para lançar ataques a partir de um fornecedor de identidade como o Entra ID contra aplicações configuradas para o utilizar para autenticação, como o Salesforce.
• Tanto quanto é do conhecimento da Semperis, não foram registados ataques que utilizem Silver SAML.
• Os pesquisadores da Semperis classificam essa vulnerabilidade como um risco MODERADO para as organizações. Dependendo do sistema comprometido, se o Silver SAML for utilizado para obter acesso não autorizado a aplicações e sistemas críticos para a empresa, o risco é SEVERO.

O Golden SAML é uma técnica de ataque conhecida, descoberta pela CyberArk e publicada por Shaked Reiner. Durante anos, o Golden SAML foi conhecido pela extração de certificados de assinatura dos Serviços de Federação do Active Directory (AD FS) e pela utilização desses certificados para forjar respostas de autenticação SAML. Hoje, apresentamos uma nova aplicação do Golden SAML - no Microsoft Entra ID e sem o uso do AD FS. Conheça o Silver SAML.

O que é o Silver SAML?

Hoje, muitas organizações usam a Entra ID como provedor de identidade (IdP) para aplicativos de software como serviço (SaaS) e linha de negócios (LOB). O SAML é o principal meio de autenticação para esses aplicativos.

No Entra ID, a Microsoft fornece um certificado auto-assinado para assinatura de resposta SAML. Como alternativa, as organizações podem optar por usar um certificado gerado externamente. No entanto, essa opção introduz um risco de segurança.

Qualquer invasor que obtenha a chave privada de um certificado gerado externamente pode forjar qualquer resposta SAML que desejar e assinar essa resposta com a mesma chave privada que a Entra ID possui. Com este tipo de resposta SAML forjada, o atacante pode então aceder à aplicação - como qualquer utilizador.

A prova de conceito discutida neste post se concentra no Entra ID. Mas esse ataque pode tirar proveito de qualquer IdP que permita a importação de certificados de assinatura SAML gerados externamente.

Para esta prova de conceito, a Semperis criou e publicou uma nova ferramenta, chamada SilverSAMLForger, que pode ser usada para forjar respostas SAML assinadas. Pode encontrar o SilverSAMLForger no GitHub.

Antecedentes: SAML, Golden SAML e o ataque da SolarWinds

O SAML é um elemento básico da autenticação moderna. Por exemplo, 63% dos aplicativos Entra ID Gallery dependem do SAML para integração. As integrações de várias nuvens com o Amazon Web Services (AWS), o Google Cloud Platform (GCP) e outros dependem do SAML. E muitas organizações continuam a investir em SAML para aplicativos SaaS e LOB devido à simplicidade de sua implementação.

Golden SAML e Solorigate

Como parte do ataque global à cadeia de fornecimento da SolarWinds (também conhecida como Solorigate), o Golden SAML foi um dos vectores de ataque mais inovadores dos atacantes.

Os atacantes obtiveram acesso inicial à SolarWinds através da inserção de código malicioso na Orion Platform da empresa, utilizada para monitorização de infra-estruturas e gestão de TI. Mais tarde, os atacantes usaram esse ponto de apoio para entrar lateralmente no ambiente do AD FS. A partir daí, eles roubaram o material de chave privada usado para assinar respostas SAML.

Como resultado desse ataque Golden SAML pós-quebra, muitas organizações priorizaram a mudança de aplicativos para Entra ID para autenticação SAML. Essa mudança eliminou a necessidade de gerenciar uma infraestrutura complexa de Nível 0, e as chaves de assinatura SAML não podem ser exportadas do Entra ID. Até mesmo a CISA recomenda que as organizações com ambientes de identidade híbrida movam a autenticação SAML para sistemas de identidade em nuvem, como o Entra ID.

O problema com SAML e assinatura de certificados

Infelizmente, muitas organizações gerem mal os certificados de assinatura e enfraquecem a segurança SAML ao utilizarem certificados gerados externamente. De acordo com as nossas observações, as organizações empresariais tendem a:

• Gerar certificados de assinatura auto-assinados num sistema cliente
• Gerar certificados de assinatura através de uma infraestrutura de chave pública (PKI) empresarial, como os Serviços de Certificados do Active Directory (AD CS)
• Obter e utilizar certificados de assinatura de uma autoridade de certificação externa (CA)

Para agravar o problema, vemos organizações que pegam nesses certificados gerados externamente e..:

• Enviar ficheiros PFX de certificados e palavras-passe através de canais inseguros, como o Teams ou o Slack
• Gerar certificados em máquinas clientes, deixando os certificados disponíveis para exportação no armazenamento de certificados local das máquinas
• Gerar certificados em servidores Web, normalmente com o Microsoft Internet Information Services (IIS), deixando os certificados disponíveis para exportação no repositório de certificados local das máquinas

Mesmo para as organizações que utilizam serviços como o Azure Key Vault - um método mais seguro para a gestão de segredos e certificados - podem existir vectores de ataque. (Abordaremos esses vectores na próxima secção).

O uso de um certificado gerado externamente para assinatura de resposta SAML aumenta a superfície de ataque de qualquer IdP, incluindo a Entra ID. Observamos várias lições comuns em organizações que geram e gerenciam certificados de assinatura SAML externamente, em vez de diretamente na Entra ID.

• Falta de uma cadeia de confiança com certificados auto-assinados da Entra ID
• Incapacidade de tirar partido da revogação de certificados com certificados auto-assinados
• Necessidade de aplicar cegamente uma política empresarial definida à gestão de certificados (normalmente com base numa ou em ambas as razões anteriores)
• Um sentimento subjetivo de que os certificados auto-assinados são "menos seguros"

Além disso, algumas organizações desejam manter uma vida útil do certificado de assinatura SAML maior do que o padrão da Entra ID. Essas organizações emitem certificados externos, sem perceber que podem simplesmente emitir novos certificados da Entra ID e configurar esses certificados para ter uma vida útil mais longa.

Muitas organizações não compreendem as nuances da utilização de certificados para a assinatura SAML; os certificados de assinatura são simplesmente integrados nas suas directivas e políticas de gestão de certificados mais amplas. Embora as práticas comuns de gerenciamento e ciclo de vida de certificados sejam importantes para muitos tipos de sistemas, elas não se aplicam e não devem se aplicar a certificados usados para assinatura SAML.

Uma cadeia de confiança não é relevante no SAML. A maioria das aplicações IdPs e Service Provider (SP) ignoram qualquer cadeia de confiança. Ao contrário do cenário servidor/cliente que se vê nos navegadores Web, um administrador é efetivamente uma parte essencial da cadeia de confiança nas configurações SAML. O administrador tem de configurar e especificar qual o certificado de assinatura em que deve confiar, especificamente na aplicação.

A revogação de certificados também não é uma prática relevante com SAML. Se um certificado de assinatura for comprometido, um administrador deve alternar (ou seja, substituir) esse certificado no SP e no IdP. O OASIS SAML 2.0 Metadata Interoperability Profile Version 1.0 indica especificamente que se deve evitar o uso de listas de revogação, Online Certificate Status Protocol (OCSP) ou outros mecanismos para validação de chaves. Em vez disso, deve fazer com que o IdP remova as chaves comprometidas dos metadados SAML.

Importação de certificados externos

Como mostra a Figura 1, é possível configurar certificados auto-assinados em um aplicativo corporativo (Okta, neste exemplo) no centro de administração Entra por meio das configurações Gerenciar > Logon único > SAML > Certificados SAML do aplicativo.

No painel Certificado de assinatura SAML, pode importar o seu próprio certificado para assinar a resposta ou as afirmações SAML(Figura 2).

E quanto ao Azure Key Vault?

Precisamos de falar um pouco sobre o Azure Key Vault: um dos locais onde os certificados auto-assinados podem ser armazenados. Queríamos determinar se um atacante poderia extrair chaves do Key Vault. Spoiler: Pode. (Se a sua organização não utiliza o Key Vault, não hesite em saltar para a secção seguinte).

O Azure Key Vault é uma solução popular de gestão de chaves fornecida pela Microsoft. O Key Vault permite-lhe armazenar e gerir de forma segura segredos, chaves de encriptação e certificados.

Tal como a maioria dos serviços em nuvem, o Key Vault tem dois planos que regem o acesso e a gestão: o plano de controlo e o plano de dados.

• Plano de controlo. As funções e permissões atribuídas ao plano de controlo estão associadas a tarefas administrativas e definições de configuração do cofre de chaves. Os utilizadores, grupos ou entidades de serviço aos quais são atribuídas permissões de plano de controlo podem configurar políticas de acesso, criar abóbadas de chaves e executar outras tarefas de gestão. Os direitos podem ser concedidos de forma granular a uma abóbada individual, mas são frequentemente concedidos ao nível do grupo de recursos, subscrição ou grupo de gestão.
• Plano de dados. O plano de dados está relacionado com os dados reais armazenados num cofre de chaves: segredos, chaves e certificados. Os direitos atribuídos no plano de dados controlam quais os utilizadores ou responsáveis de serviço que podem ler e escrever material criptográfico de e para o cofre de chaves. Estes direitos incluem a capacidade de ler chaves privadas de certificados, o que é uma preocupação se essas chaves forem utilizadas para a assinatura de respostas SAML.

As permissões do Key Vault podem ser concedidas através do controlo de acesso baseado em funções (RBAC) ou de políticas de acesso ao Key Vault.

O modelo de permissões RBAC

Com o modelo RBAC(Figura 3), qualquer utilizador que tenha uma das seguintes funções RBAC pode obter o certificado de uma abóbada de chaves.

• Administrador do Key Vault
• Responsável pelos certificados do cofre principal
• Administrador de acesso aos dados do Key Vault. Esta função permite-lhe gerir o acesso adicionando ou removendo atribuições de funções. Por conseguinte, pode atribuir a função Administrador do Key Vault ou Responsável pelos Certificados do Key Vault a qualquer entidade.
• Contribuidor do cofre de chaves. Esta função não concede permissões de plano de dados, mas permite-lhe atualizar a política de acesso do cofre de chaves se o modelo de permissão de políticas de acesso também for utilizado.

A Figura 4 mostra um exemplo de permissões concedidas à função Administrador do Key Vault.

Uma pessoa com a função Contribuidor do Cofre de Chaves, que não tem permissões de plano de dados para aceder aos segredos e certificados do cofre de chaves, pode ainda assim extraí-los se forem utilizadas políticas de acesso. Esta função tem a permissão de plano de controlo Microsoft.KeyVault/*. Esta permissão pode ser traduzida para Microsoft.KeyVault/vaults/accessPolicies/write, permitindo ao titular escrever políticas de acesso ao Key Vault e extrair segredos do Key Vault.

Se conseguir adicionar permissões RBAC ao nível do grupo de recursos ou da subscrição, obtendo o controlo de uma conta de proprietário de grupo de recursos ou de uma conta de utilizador que tenha a permissão RBAC de Administrador de Controlo de Acesso Baseado em Funções ou de qualquer utilizador com a permissão Microsoft.Authorization/roleAssignments/write, pode adicionar permissões de Cofre de Chaves. O cofre de chaves herdará então essas permissões. Como mencionado anteriormente, algumas funções RBAC também podem modificar diretamente as políticas de acesso ao Key Vault.

Os cofres de chaves também podem ser acedidos através de contas de automatização e identidades geridas que tenham as permissões necessárias.

O modelo de permissões das políticas de acesso do Key Vault

Neste modelo, também é possível conceder permissões de acesso ao Key Vault a um utilizador, serviço ou grupo. Pode escolher entre permissões de chave, permissões de segredo e permissões de certificado(Figura 5).

Pode adicionar políticas de acesso no painel Políticas de acesso ao Key Vault(Figura 6).

Qualquer atacante que obtenha o controlo de qualquer utilizador, diretor de serviço ou grupo que tenha permissão para obter o ficheiro PFX que é utilizado para assinar as asserções ou respostas SAML para o SP atacado - através de políticas de acesso RBAC ou Key Vault - pode efetuar um ataque SAML Prata a esse SP.

SAML e Entra ID

O SAML, na sua atual versão 2.0, tem quase 20 anos. A OASIS publicou o protocolo em março de 2005. Desde então, muitas empresas adotaram o SAML para autenticação federada e soluções SSO baseadas na Web. A principal implementação do protocolo - e o caso de uso na Entra ID - está aproveitando o perfil SSO do navegador da Web.

Um fluxo de perfil SAML típico tem três componentes principais:

• O fornecedor de serviços (SP), ou aplicação; também vulgarmente referido como a parte confiável (RP) no ecossistema Microsoft
• O fornecedor de identidade (IdP), que na nossa prova de conceito é a Entra ID
• O agente do utilizador, normalmente o navegador Web de um cliente (utilizador final)

Os utilizadores interagem com as aplicações para autenticação de várias formas, dependendo de a aplicação estar configurada ou suportar fluxos iniciados pelo SP ou pelo IdP.
Num fluxo iniciado pelo SP(Figura 7), ocorre a seguinte sequência:

1. O utilizador navega para um URL da aplicação (SP).
2. O SP gera um pedido SAML(Figura 8) e redirecciona o utilizador para o Entra ID (IdP).
3. A Entra ID consome o pedido SAML.
4. Se o utilizador ainda não se tiver autenticado no Entra ID, é-lhe solicitada a autenticação.
5. O utilizador autentica-se com sucesso na Entra ID.
6. A Entra ID gera uma resposta SAML(Figura 9) e redirecciona o utilizador para o SP.
7. O SP verifica a resposta SAML.
8. O utilizador recebe acesso à aplicação.

Num fluxo iniciado por um IdP(Figura 10), ocorre a seguinte sequência:

1. O utilizador navega para myapps.microsoft.com.
2. Se o utilizador ainda não se tiver autenticado no Entra ID, é-lhe solicitada a autenticação.
3. O utilizador autentica-se com sucesso na Entra ID.
4. A Entra ID fornece uma lista de aplicações disponíveis para o utilizador em myapps.microsoft.com.
5. O utilizador selecciona a aplicação de destino.
6. A Entra ID gera uma resposta SAML e redireciona o usuário para o SP.
7. O SP verifica a resposta SAML.
8. O utilizador recebe acesso à aplicação.

O conteúdo de uma afirmação SAML inclui vários bits de informação sobre o utilizador final, ou sujeito, numa série de pares chave-valor. Estas informações são frequentemente designadas por declarações SAML e incluem informações como:

• O assunto. A aplicação utiliza este componente obrigatório como identificador único do utilizador. Em muitas implementações, o assunto é o Nome Principal de Utilizador (UPN) ou o endereço de correio eletrónico do utilizador.
• Informações de atributo. Estas informações podem incluir o nome próprio, apelido, endereço de correio eletrónico e nome de apresentação do utilizador. Os membros do grupo ou as funções são frequentemente fornecidos para que a aplicação possa tomar decisões de autorização sobre os direitos que o utilizador deve ter.
• Outras informações contextuais de autenticação. Estas informações podem incluir o tipo de autenticação utilizado, o emissor e o público, bem como informações de carimbo de data/hora que indicam a janela de validade da resposta SAML.

Como é que garante que a resposta SAML, que é tratada pelo utilizador, não foi adulterada? É aqui que a assinatura entra em ação.

A Entra ID suporta a assinatura de resposta SAML e de asserção SAML. Em um nível elevado, o objetivo da assinatura de resposta e de asserção é verificar se o conteúdo da resposta não foi adulterado e se o aplicativo pode confiar nas informações contidas na resposta. A aplicação utiliza a assinatura para validar que a resposta foi gerada pelo IdP, que detém a chave privada utilizada para assinar a resposta.

É por isso que o roubo da chave privada de assinatura é um problema crítico. Com a chave de assinatura na mão, um agente de ameaça pode forjar uma cópia de uma resposta SAML, efectuando um ataque Silver SAML.

Realização de um ataque SAML de prata

Para testar a teoria de que a técnica de ataque SAML dourado pode ser usada contra o Entra ID - no que chamamos de ataque SAML prateado - criamos a ferramenta SilverSAMLForger. Essa ferramenta gera uma resposta SAML que duplica uma resposta da Entra ID, assinando essa resposta com um certificado fornecido.

A nossa prova de conceito do Silver SAML baseia-se na premissa de que uma organização está a utilizar um certificado de assinatura gerado externamente, que um atacante obteve através de um dos métodos discutidos anteriormente. Analisamos a aplicação do Silver SAML tanto em fluxos iniciados por SP quanto em fluxos iniciados por IDP, pois ambos são suscetíveis a ataques.

Silver SAML num fluxo iniciado por um SP

Ataque SAML prateado usando o Entra ID como IdP e o Okta como SP. Para lançar o ataque em um fluxo iniciado pelo SP, precisávamos intercetar a solicitação SAML e substituir o conteúdo da resposta SAML pela resposta SAML forjada que criamos(Figura 11). Conseguimos realizar essas tarefas facilmente usando o Burp Suite.

Para este exemplo, tentámos forjar uma resposta SAML para o utilizador oktaAdministrator@xd6z7.onmicrosoft.com. Esse usuário é um Superadministrador no Okta. Não temos a senha do usuário ou o dispositivo conectado ao MFA do usuário (se configurado).

Primeiro, precisávamos de alguns atributos nas informações das declarações SAML de acordo com o que foi configurado quando a aplicação foi registada no IdP. Por exemplo, precisamos do UPN, sobrenome, nome, displayName e objectID. Um invasor pode encontrar facilmente esses atributos no centro de administração do Entra ou usando a API do Microsoft Graph.

Também precisávamos saber o destinatário e o público. Essa informação estava disponível no centro de administração do Entra, no painel Single sign-on da aplicação(Figura 12).

A execução do SilverSAMLForger.exe com os parâmetros necessários produz uma string codificada em base64 e URL(Figura 13). Agora podemos copiar essa resposta SAML forjada.

Copiámos a resposta SAML gerada para o pedido HTTPS intercetado(Figura 14) e modificámos a resposta para a resposta forjada(Figura 15).

Depois de enviar a resposta forjada, podemos parar de intercetar, uma vez que estamos agora ligados como o utilizador visado(Figura 16).

Ataque SAML de prata num fluxo iniciado por um IdP

Os fluxos iniciados por IdP apresentam um risco muito maior para a organização, pois não é necessária nenhuma interação com a Entra ID. Se o aplicativo suportar fluxos iniciados por IdP, é possível postar diretamente uma resposta SAML no aplicativo(Figura 17).

Para esta parte da prova de conceito, tentámos efetuar um ataque iniciado por um IdP contra o Salesforce.

Visamos o usuário Patti Fernandez, forjando uma resposta com seu UPN como assunto. A resposta(Figura 18) foi assinada usando o mesmo certificado de assinatura SAML que foi configurado para o Salesforce no Entra ID.

Descodificando esta resposta, pode ver-se que se trata de uma resposta forjada para Patti(Figura 19).

No Burp Suite, utilizámos o Repeater para publicar diretamente a resposta SAML forjada na nossa instância do Salesforce(Figura 20).

Abrindo a resposta em um navegador, verificamos que estamos logados no Salesforce como Patti, sem qualquer interação com o Entra ID(Figura 21).

Defesa contra ataques Silver SAML

Para se proteger eficazmente contra ataques SAML Silver no Entra ID, sua organização deve usar apenas certificados auto-assinados Entra ID para fins de assinatura SAML.

Os certificados de assinatura SAML são armazenados na entidade de serviço para um aplicativo SAML no Entra ID. É possível utilizar a API Graph para visualizar as informações que são expostas sobre a chave de assinatura. Basta chamar uma solicitação GET para o seguinte URI:

https://graph.microsoft.com/beta/servicePrincipals/{serviceprincipalobjectid}

A Figura 22 mostra um exemplo das informações expostas. Note-se que o material da chave privada não é exportável, impedindo que os atacantes recolham as informações necessárias para lançar um ataque Silver SAML.

Os administradores globais, administradores de aplicativos, administradores de aplicativos em nuvem e qualquer usuário a quem seja delegada a propriedade do aplicativo podem modificar quais chaves de assinatura estão disponíveis e podem importar uma chave de assinatura externa. Embora o aplicativo associado precise ser atualizado, as organizações devem limitar quem tem propriedade sobre os aplicativos no Entra ID. No mínimo, monitore as alterações nas chaves de assinatura SAML, especialmente se a chave não estiver perto da expiração.

As organizações podem auditar as entidades de serviço existentes que estão configuradas para SAML e verificar o displayName. Se o certificado utilizado for gerado pela Microsoft, o certificado conterá o valor CN=Microsoft Azure Federated SSO Certificate. No entanto, nada impede que um atacante importe um certificado externo que tenha o mesmo nome de assunto.

As organizações também podem monitorar os logs de auditoria do Entra ID em busca de alterações no PreferredTokenSigningKeyThumbprint em ApplicationManagement. Será necessário correlacionar esses eventos com Adicionar eventos de credenciais da entidade de serviço que se relacionam com a entidade de serviço. A rotação de certificados expirados é um processo comum, pelo que terá de determinar se os eventos de auditoria são legítimos. A implementação de processos de controlo de alterações para documentar a rotação pode ajudar a minimizar a confusão durante os eventos de rotação.
Se uma aplicação suportar SAML e OpenID Connect (OIDC) para autenticação, pode considerar alterar a integração com a Entra ID para utilizar OIDC, mitigando este ataque. A complexidade de mudar de SAML para OIDC depende em grande parte de como o desenvolvedor do aplicativo implementou os padrões.

Do lado da aplicação, os programadores de aplicações podem proteger-se contra ataques de algumas formas. (As suas opções dependerão dos métodos e bibliotecas utilizados na sua implementação SAML).

• Exigir fluxos iniciados por SP, que protegem contra fluxos iniciados por IdP - os tipos mais perigosos de ataques.
• Para fluxos iniciados por SP, siga a especificação SAML e garanta que as respostas contêm um valor InResponseTo que se correlaciona com um pedido SAML associado.
• Observe o tempo em que a aplicação recebe uma resposta SAML. O IdP indica uma janela de validade na resposta, mas os programadores de aplicações podem introduzir outras limitações lógicas à janela aceitável para receber uma resposta em fluxos iniciados pelo SP.
• Oferecer a opção de utilizar OIDC, em vez de SAML, para integração.

Não deixe que o Silver SAML o apanhe de surpresa

Assim como o ataque Golden SAML, os ataques Silver SAML têm o potencial de serem leves - ou devastadores. À medida que a adoção de ambientes de identidade híbridos e em nuvem continua a crescer, esperamos ver mais ameaças direcionadas a IdPs como o Entra ID. Esta postagem mostra como o Silver SAML é possível com o Entra ID, mas qualquer IdP que permita o uso de certificados auto-assinados é suscetível. Incentivamos as organizações a tomar medidas decisivas agora para fechar lacunas e vulnerabilidades nesses ambientes.

Divulgação

Este problema foi comunicado através do Centro de Resposta de Segurança da Microsoft (MSRC) em 2 de janeiro de 2024. A Microsoft respondeu a 26 de fevereiro de 2024: "Após uma investigação cuidadosa, este caso foi avaliado como tendo sido concebido e não cumpre os requisitos do MSRC para assistência imediata. No entanto, partilhámos o relatório com a equipa responsável pela manutenção do produto ou serviço. Eles tomarão as medidas adequadas conforme necessário para ajudar a manter os clientes protegidos."

Linha do tempo

• 2 de janeiro de 2024: Caso MSRC criado
• 3 de janeiro de 2024: Estado do processo alterado para Revisão/Reprodução
• 17 de fevereiro de 2024: Revisão do artigo de investigação pelo MSRC
• 26 de fevereiro de 2024: Resposta da MSRC recebida
• 29 de fevereiro de 2024: Divulgação pública