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:
XXE - XEE - XML External EntityAs 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:
XSLT Server Side Injection (Extensible Stylesheet Language Transformations)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)
