SAML Attacks
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
SAMLExtractor: Uma ferramenta que pode pegar uma URL ou lista de URLs e imprimir de volta a URL de consumo SAML.
No XML, a parte assinada do XML é salva na memória, então alguma codificação/decodificação é realizada e a assinatura é verificada. Idealmente, essa codificação/decodificação não deveria mudar os dados, mas com base nesse cenário, os dados sendo verificados e os dados originais podem não ser os mesmos.
Por exemplo, verifique o seguinte código:
Executar o programa contra REXML 3.2.4 ou anterior resultaria na seguinte saída em vez disso:
This is how REXML saw the original XML document from the program above:
And this is how it saw it after a round of parsing and serialization:
For more information about the vulnerability and how to abuse it:
Em XML Signature Wrapping attacks (XSW), os adversários exploram uma vulnerabilidade que surge quando documentos XML são processados em duas fases distintas: validação de assinatura e invocação de função. Esses ataques envolvem a alteração da estrutura do documento XML. Especificamente, o atacante injeta elementos forjados que não comprometem a validade da Assinatura XML. Essa manipulação visa criar uma discrepância entre os elementos analisados pela lógica da aplicação e aqueles verificados pelo módulo de verificação de assinatura. Como resultado, enquanto a Assinatura XML permanece tecnicamente válida e passa na verificação, a lógica da aplicação processa os elementos fraudulentos. Consequentemente, o atacante efetivamente contorna a proteção de integridade e a autenticação de origem da Assinatura XML, permitindo a injeção de conteúdo arbitrário sem detecção.
Os seguintes ataques são baseados em este post do blog e este artigo. Então, verifique esses para mais detalhes.
Estratégia: Um novo elemento raiz contendo a assinatura é adicionado.
Implicação: O validador pode ficar confuso entre o legítimo "Response -> Assertion -> Subject" e o "Response -> Assertion -> Subject" malicioso do atacante, levando a problemas de integridade de dados.
Diferença do XSW #1: Utiliza uma assinatura destacada em vez de uma assinatura envolvente.
Implicação: A estrutura "maligna", semelhante ao XSW #1, visa enganar a lógica de negócios após a verificação de integridade.
Estratégia: Uma Assertion maligna é criada no mesmo nível hierárquico que a assertion original.
Implicação: Tem a intenção de confundir a lógica de negócios para usar os dados maliciosos.
Diferença do XSW #3: A Assertion original se torna um filho da Assertion duplicada (maligna).
Implicação: Semelhante ao XSW #3, mas altera a estrutura XML de forma mais agressiva.
Aspecto Único: Nem a Assinatura nem a Assertion original aderem a configurações padrão (envolvidas/envolventes/detalhadas).
Implicação: A Assertion copiada envolve a Assinatura, modificando a estrutura do documento esperada.
Estratégia: Inserção em local semelhante ao XSW #4 e #5, mas com uma reviravolta.
Implicação: A Assertion copiada envolve a Assinatura, que então envolve a Assertion original, criando uma estrutura enganosa aninhada.
Estratégia: Um elemento Extensions é inserido com a Assertion copiada como filho.
Implicação: Isso explora o esquema menos restritivo do elemento Extensions para contornar as contramedidas de validação de esquema, especialmente em bibliotecas como OpenSAML.
Diferença do XSW #7: Utiliza outro elemento XML menos restritivo para uma variante do ataque.
Implicação: A Assertion original se torna um filho do elemento menos restritivo, revertendo a estrutura usada no XSW #7.
Você pode usar a extensão Burp SAML Raider para analisar a solicitação, aplicar qualquer ataque XSW que você escolher e lançá-lo.
Se você não sabe que tipo de ataques são XXE, por favor, leia a página a seguir:
As Respostas SAML são documentos XML descompactados e codificados em base64 e podem ser suscetíveis a ataques de Entidade Externa XML (XXE). Ao manipular a estrutura XML da Resposta SAML, os atacantes podem tentar explorar vulnerabilidades XXE. Aqui está como tal ataque pode ser visualizado:
Você também pode usar a extensão do Burp SAML Raider para gerar o POC a partir de uma solicitação SAML para testar possíveis vulnerabilidades XXE e vulnerabilidades SAML.
Confira também esta palestra: https://www.youtube.com/watch?v=WHn-6xHL7mI
Para mais informações sobre XSLT, vá para:
Transformações de Linguagem de Folha de Estilo Extensível (XSLT) podem ser usadas para transformar documentos XML em vários formatos, como HTML, JSON ou PDF. É crucial notar que as transformações XSLT são realizadas antes da verificação da assinatura digital. Isso significa que um ataque pode ser bem-sucedido mesmo sem uma assinatura válida; uma assinatura autoassinada ou inválida é suficiente para prosseguir.
Aqui você pode encontrar um POC para verificar esse tipo de vulnerabilidades; na página de hacktricks mencionada no início desta seção, você pode encontrar payloads.
Você também pode usar a extensão Burp SAML Raider para gerar o POC a partir de uma solicitação SAML para testar possíveis vulnerabilidades de XSLT.
Confira também esta palestra: https://www.youtube.com/watch?v=WHn-6xHL7mI
A Exclusão de Assinatura XML observa o comportamento das implementações SAML quando o elemento Signature não está presente. Se este elemento estiver ausente, a validação da assinatura pode não ocorrer, tornando-o vulnerável. É possível testar isso alterando os conteúdos que normalmente são verificados pela assinatura.
Você também pode usar a extensão Burp SAML Raider. Intercepte a Resposta SAML e clique em Remove Signatures. Ao fazer isso, todos os elementos Signature são removidos.
Com as assinaturas removidas, permita que a solicitação prossiga para o alvo. Se a assinatura não for necessária pelo Serviço
A Falsificação de Certificado é uma técnica para testar se um Provedor de Serviço (SP) verifica corretamente se uma Mensagem SAML está assinada por um Provedor de Identidade (IdP) confiável. Envolve o uso de um *certificado autoassinado para assinar a Resposta ou Aserção SAML, o que ajuda na avaliação do processo de validação de confiança entre SP e IdP.
Os seguintes passos descrevem o processo usando a extensão Burp SAML Raider:
Intercepte a Resposta SAML.
Se a resposta contiver uma assinatura, envie o certificado para SAML Raider Certs usando o botão Send Certificate to SAML Raider Certs.
Na aba de Certificados do SAML Raider, selecione o certificado importado e clique em Save and Self-Sign para criar um clone autoassinado do certificado original.
Volte para a solicitação interceptada no Proxy do Burp. Selecione o novo certificado autoassinado no menu suspenso de Assinatura XML.
Remova quaisquer assinaturas existentes com o botão Remove Signatures.
Assine a mensagem ou a asserção com o novo certificado usando o botão (Re-)Sign Message ou (Re-)Sign Assertion, conforme apropriado.
Encaminhe a mensagem assinada. A autenticação bem-sucedida indica que o SP aceita mensagens assinadas pelo seu certificado autoassinado, revelando potenciais vulnerabilidades no processo de validação das mensagens SAML.
A Confusão de Destinatário de Token e a Confusão de Alvo de Provedor de Serviço envolvem verificar se o Provedor de Serviço valida corretamente o destinatário pretendido de uma resposta. Em essência, um Provedor de Serviço deve rejeitar uma resposta de autenticação se ela foi destinada a um provedor diferente. O elemento crítico aqui é o campo Recipient, encontrado dentro do elemento SubjectConfirmationData de uma Resposta SAML. Este campo especifica uma URL indicando onde a Aserção deve ser enviada. Se o destinatário real não corresponder ao Provedor de Serviço pretendido, a Aserção deve ser considerada inválida.
Para que um ataque de Confusão de Destinatário de Token SAML (SAML-TRC) seja viável, certas condições devem ser atendidas. Primeiro, deve haver uma conta válida em um Provedor de Serviço (referido como SP-Legit). Em segundo lugar, o Provedor de Serviço alvo (SP-Target) deve aceitar tokens do mesmo Provedor de Identidade que atende o SP-Legit.
O processo de ataque é simples sob essas condições. Uma sessão autêntica é iniciada com o SP-Legit através do Provedor de Identidade compartilhado. A Resposta SAML do Provedor de Identidade para o SP-Legit é interceptada. Esta Resposta SAML interceptada, originalmente destinada ao SP-Legit, é então redirecionada para o SP-Target. O sucesso neste ataque é medido pela aceitação da Aserção pelo SP-Target, concedendo acesso a recursos sob o mesmo nome de conta usado para o SP-Legit.
A pesquisa original pode ser acessada através deste link.
Durante o processo de força bruta de diretório, uma página de logout foi descoberta em:
Ao acessar este link, ocorreu uma redireção para:
Isso revelou que o parâmetro base aceita uma URL. Considerando isso, surgiu a ideia de substituir a URL por javascript:alert(123); na tentativa de iniciar um ataque XSS (Cross-Site Scripting).
A ferramenta SAMLExtractor foi usada para analisar subdomínios de uberinternal.com para domínios que utilizam a mesma biblioteca. Subsequentemente, um script foi desenvolvido para direcionar a página oidauth/prompt. Este script testa para XSS (Cross-Site Scripting) inserindo dados e verificando se eles são refletidos na saída. Nos casos em que a entrada é de fato refletida, o script marca a página como vulnerável.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
