<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs exclusivos**](https://opensea.io/collection/the-peass-family)
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Uma ferramenta que pode pegar uma URL ou lista de URLs e retorna a URL de consumo SAML.
No XML, a parte assinada do XML é salva na memória, depois algumas codificações/de-codificações são realizadas e a assinatura é verificada. Idealmente, essa codificação/de-codificação não deveria alterar os dados, mas baseado nesse cenário, **os dados sendo verificados e os dados originais podem não ser os mesmos**.
Documentos XML contendo Assinaturas XML são tipicamente **processados em dois passos independentes**: **validação da assinatura** e **invocação de função** (lógica de negócios). Se ambos os módulos têm visões diferentes sobre os dados, uma nova classe de vulnerabilidades chamada ataques de Envolvimento de Assinatura XML (XSW) existe.\
Nesses ataques, o **adversário****modifica** a **estrutura da mensagem****injetando** elementos **falsificados que não invalidam a Assinatura XML**. O objetivo dessa alteração é mudar a mensagem de tal forma que a **lógica da aplicação e o módulo de verificação da assinatura usem partes diferentes da mensagem**. Consequentemente, o receptor verifica a Assinatura XML com sucesso, mas a lógica da aplicação processa o elemento falso. O **atacante assim contorna a proteção de integridade** e a autenticação de origem da Assinatura XML e pode injetar conteúdo arbitrário.
Um atacante pode **adicionar um novo elemento raiz onde a assinatura** é encontrada. Portanto, quando o validador verifica a integridade da assinatura, ele pode notar que tem **verificar** a **integridade** do **Response -> Assertion -> Subject**, e pode se confundir com o caminho **malicioso novo Response -> Assertion -> Subject** em vermelho e usar seus dados.
Neste ataque, uma **Assertion maliciosa é criada no mesmo nível** que a assertion original para tentar confundir a lógica de negócios e usar os dados maliciosos.
No XSW #5, a Assinatura e a Assertion original não estão em uma das três configurações padrão (envolvida/envolvente/desacoplada). Neste caso, a Assertion copiada envolve a Assinatura.
XSW #6 insere sua Assertion copiada na mesma localização que os números 4 e 5. A parte interessante aqui é que a Assertion copiada envolve a Assinatura, que por sua vez envolve a Assertion original.
XSW #7 insere um elemento **Extensions** e adiciona a Assertion copiada como **filho**. Extensions é um elemento XML válido com uma **definição de esquema menos restritiva**. Os autores deste [white paper](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf) desenvolveram este método em resposta à biblioteca OpenSAML. OpenSAML usou validação de esquema para comparar corretamente o ID usado durante a validação da assinatura com o ID da Assertion processada. Os autores descobriram que em casos onde Assertions copiadas com o mesmo ID da Assertion original eram filhos de um elemento com uma definição de esquema menos restritiva, eles conseguiram contornar essa contramedida específica.
XSW #8 usa outro elemento XML **menos restritivo** para realizar uma variação do padrão de ataque usado no XSW #7. Desta vez, a Assertion original é o filho do elemento menos restritivo em vez da Assertion copiada.
Você pode usar a extensão do Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) para analisar a solicitação, aplicar qualquer ataque XSW que escolher e lançá-lo.
Para mais informações sobre este ataque, leia o artigo original em [https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf)
Devido ao fato de que as Respostas SAML são documentos XML deflacionados e codificados em base64, podemos testar para **XXE** manipulando o documento XML enviado como a Resposta SAML. Exemplo:
Você também pode usar a extensão do Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) para gerar o POC a partir de uma solicitação SAML para testar possíveis vulnerabilidades XXE.
Extensible Stylesheet Language Transformation (XSLT) é uma linguagem Turing-completa para transformar documentos XML em outros tipos de documentos, como HTML, JSON ou PDF. Um aspecto importante a ser notado aqui é que **o ataque não requer uma assinatura válida para ter sucesso**. A razão para isso é que **a transformação XSLT ocorre antes que a assinatura digital seja processada para verificação**. Basicamente, precisamos de uma Resposta SAML assinada para realizar o ataque, mas a assinatura pode ser autoassinada ou inválida.
Aqui você pode encontrar um **POC** para verificar este tipo de vulnerabilidades, na página hacktricks mencionada no início desta seção você pode encontrar payloads.
Você também pode usar a extensão do Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) para gerar o POC a partir de uma solicitação SAML para testar possíveis vulnerabilidades XSLT.
A Exclusão de Assinatura é usada para testar como a implementação do SAML se comporta quando **não há elemento de Assinatura**. Quando um elemento de Assinatura está **ausente**, a **etapa de validação da assinatura pode ser completamente ignorada**. Se a Assinatura não for validada, então qualquer conteúdo que normalmente seria assinado pode ser adulterado por um atacante.
A exclusão de assinatura começa interceptando a Resposta SAML e clicando em `Remove Signatures`. Ao fazer isso, **todos** os elementos de Assinatura são removidos.
A falsificação de certificado é o processo de testar se o Provedor de Serviço **verifica se um Provedor de Identidade confiável assinou a Mensagem SAML.** A relação de confiança entre SP e IdP é estabelecida e **deve ser verificada** cada vez que uma Mensagem SAML é recebida. Isso se resume a usar um certificado **autoassinado** para assinar a Resposta SAML ou Afirmação.
Após enviar o certificado, devemos ver um certificado importado na aba Certificados do SAML Raider. Uma vez lá, destacamos o certificado importado e pressionamos o botão `Save and Self-Sign`.
Ao fazer isso, um clone autoassinado do certificado original é gerado. Agora é hora de voltar à solicitação interceptada ainda retida no Proxy do burp. Primeiro, selecione o novo certificado autoassinado no menu suspenso de Assinatura XML. Em seguida, use o botão `Remove Signatures` para remover quaisquer assinaturas existentes. Finalmente, use o botão **`(Re-)Sign Message`** ou `(`**`Re-)Sign Assertion`** (**qualquer** que seja **mais****apropriado** para a sua situação).
Após assinar a mensagem com o certificado autoassinado, envie-a. Se nos autenticarmos, sabemos que podemos assinar nossas Mensagens SAML. A capacidade de assinar nossas Mensagens SAML significa que podemos alterar valores na Afirmação e eles serão aceitos pelo Provedor de Serviço.
## Confusão do Destinatário do Token / Confusão do Alvo do Provedor de Serviço <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
Confusão do Destinatário do Token / Confusão do Alvo do Provedor de Serviço **testa se o Provedor de Serviço valida o Destinatário**. Isso significa que, **se a resposta foi destinada a um Provedor de Serviço diferente**, o Provedor de Serviço **atual** deve perceber isso e **rejeitar a autenticação**.\
O campo **Destinatário** é um atributo do elemento **SubjectConfirmationData**, que é filho do elemento Subject em uma Resposta SAML.
> O elemento SubjectConfirmationData especifica dados adicionais que permitem confirmar o sujeito ou restringir as circunstâncias sob as quais o ato de confirmação do sujeito pode ocorrer. A confirmação do sujeito ocorre quando uma parte confiável procura verificar a relação entre uma entidade que apresenta a afirmação (ou seja, a entidade atestante) e o sujeito das reivindicações da afirmação.
O atributo Destinatário encontrado no elemento **SubjectConfirmationData é uma URL que especifica o local para o qual a Afirmação deve ser entregue**. Se o Destinatário for um Provedor de Serviço diferente daquele que o recebe, a Afirmação não deve ser aceita.
A Confusão do Destinatário do Token SAML (SAML-TRC) tem algumas condições prévias para que possamos tentar a exploração. Primeiro, **precisamos** ter uma **conta legítima em um Provedor de Serviço**. Segundo, **SP-Target deve aceitar tokens emitidos pelo mesmo Provedor de Identidade que atende SP-Legit**.
O ataque é relativamente simples se as condições forem verdadeiras. Nós **nos autenticamos** no **SP-Legit** através do Provedor de Identidade compartilhado. Em seguida, **interceptamos a Resposta SAML a caminho do IdP para SP-Legit**. Uma vez interceptada, enviamos a **Resposta SAML que foi destinada para SP-Legit para SP-Target em vez disso.** Se **SP-Target aceitar a Afirmação**; nos encontraremos logados com o mesmo nome de conta que temos para SP-Legit e teremos acesso aos recursos correspondentes de SP-Target.
Usando [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor) que pode receber uma lista de URLs e depois devolver a URL de callback (consumo SAML), decidi alimentar a ferramenta com todos os subdomínios de `uberinternal.com` para ver se há outros domínios que usam a mesma biblioteca, e havia.
O que fiz em seguida foi criar um script que chama a página vulnerável `oidauth/prompt` e tenta o XSS e, se minha entrada for refletida, ele me dá uma mensagem de vulnerável agradável.
Os ataques foram obtidos de [https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/)\
Você pode encontrar recursos adicionais e write-ups em [https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/)
<summary><strong>Aprenda AWS hacking do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF** Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**merchandising oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga**-me no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
