# SAML Attacks
## Ataques SAML
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e para o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).
## Informações Básicas
{% content-ref url="saml-basics.md" %}
[saml-basics.md](saml-basics.md)
{% endcontent-ref %}
## Gráfico de Ataques
 (1) (1) (2) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (10).png>)
## Ferramenta
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Uma ferramenta que pode receber uma URL ou lista de URLs e retorna a URL de consumo SAML.
## Round-trip XML
No XML, a parte assinada do XML é salva na memória, em seguida, alguma codificação/decodificação é realizada e a assinatura é verificada. Idealmente, essa codificação/decodificação não deve alterar os dados, mas com base nesse cenário, **os dados verificados e os dados originais podem não ser os mesmos**.
Por exemplo, verifique o seguinte código:
```ruby
require 'rexml/document'
doc = REXML::Document.new <]>
XML
puts "First child in original doc: " + doc.root.elements[1].name
doc = REXML::Document.new doc.to_s
puts "First child after round-trip: " + doc.root.elements[1].name
```
Executar o programa contra o REXML 3.2.4 ou anterior resultaria na seguinte saída:
```
First child in original doc: Y
First child after round-trip: Z
```
Assim é como o REXML viu o documento XML original do programa acima:
.png>)
E assim é como ele o viu após uma rodada de análise e serialização:
.png>)
Para obter mais informações sobre a vulnerabilidade e como abusá-la:
* [https://mattermost.com/blog/securing-xml-implementations-across-the-web/](https://mattermost.com/blog/securing-xml-implementations-across-the-web/)
* [https://joonas.fi/2021/08/saml-is-insecure-by-design/](https://joonas.fi/2021/08/saml-is-insecure-by-design/)
## Ataques de Envoltório de Assinatura XML
Documentos XML contendo Assinaturas XML são normalmente **processados em dois passos independentes**: **validação de 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, existe uma nova classe de vulnerabilidades chamada ataques de envoltório de assinatura XML (XSW).\
Nesses ataques, o **adversário modifica** a **estrutura da mensagem** **injetando** elementos **forjados que não invalidam a Assinatura XML**. O objetivo dessa alteração é mudar a mensagem de tal forma que a **lógica de aplicativo e o módulo de verificação de assinatura usem partes diferentes da mensagem**. Consequentemente, o receptor verifica a Assinatura XML com sucesso, mas a lógica de aplicativo 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.
Do pedido SAML:
.png>)
### XSW #1
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 **verificou** a **integridade** do **Response -> Assertion -> Subject**, e pode ficar confuso com o caminho **novo Response -> Assertion -> Subject** em vermelho e usar seus dados.
.png>)
### XSW #2
A diferença com #1 é que o tipo de Assinatura usado é uma **assinatura destacada** onde XSW #1 usou uma assinatura de envoltório.\
Observe como a nova estrutura maliciosa é a mesma de antes, tentando confundir a lógica de negócios após a verificação de integridade ter sido realizada.
.png>)
### XSW #3
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.
.png>)
### XSW #4
XSW #4 é semelhante ao #3, exceto que, neste caso, a **Assertion original se torna uma filha** da Assertion copiada.
.png>)
### XSW #5
No XSW #5, a Assinatura e a Assertion original não estão em uma das três configurações padrão (envolvente/envelopado/destacado). Neste caso, a Assertion copiada envolve a Assinatura.
.png>)
### XSW #6
XSW #6 insere sua Assertion copiada na mesma localização que as #4 e #5. A peça interessante aqui é que a Assertion copiada envolve a Assinatura, que por sua vez envolve a Assertion original.
.png>)
### XSW #7
XSW #7 insere um elemento **Extensions** e adiciona a Assertion copiada como **filha**. Extensions é um elemento XML válido com uma **definição de esquema menos restritiva**. Os autores deste [artigo](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf) desenvolveram este método em resposta à biblioteca OpenSAML. O OpenSAML usava validação de esquema para comparar corretamente o ID usado durante a validação de assinatura com o ID da Assertion processada. Os autores descobriram que, nos casos em que as Assertions copiadas com o mesmo ID da Assertion original eram filhas de um elemento com uma definição de esquema menos restritiva, eles conseguiam contornar essa contramedida específica.
.png>)
### XSW #8
XSW #8 usa outro elemento XML **menos restritivo** para executar uma variação do padrão de ataque usado em XSW #7. Desta vez, a Assertion original é a filha do elemento menos restritivo em vez da Assertion copiada.
.png>)
### Ferramenta
Você pode usar a extensão Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) para analisar o pedido, aplicar qualquer ataque XSW que escolher e lançá-lo.
.png>)
### Artigo Original
Para obter 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)
## XXE
Se você não sabe quais tipos de ataques são XXE, leia a seguinte página:
{% content-ref url="../xxe-xee-xml-external-entity.md" %}
[xxe-xee-xml-external-entity.md](../xxe-xee-xml-external-entity.md)
{% endcontent-ref %}
Devido ao fato de que as Respostas SAML são documentos XML **deflacionados e codificados em base64**, podemos testar o **XXE** manipulando o documento XML enviado como a Resposta SAML. Exemplo:
```markup
]>
...
...
...
[...]
```
### Ferramenta
Você também pode usar a extensão 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.
Confira também esta palestra: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
## XSLT via SAML
Para obter mais informações sobre XSLT, acesse:
{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md" %}
[xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md](../xslt-server-side-injection-extensible-stylesheet-languaje-transformations.md)
{% endcontent-ref %}
A Transformação de Linguagem de Folha de Estilo Extensível (XSLT) é uma linguagem Turing completa para transformar documentos XML em outros tipos de documentos, como HTML, JSON ou PDF. Um aspecto importante a ser observado 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 esse tipo de vulnerabilidade, na página hacktricks mencionada no início desta seção, você pode encontrar payloads.
```markup
...
...
```
### Ferramenta
Você também pode usar a extensão 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.
Confira também esta palestra: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)
## Exclusão de Assinatura XML
A exclusão de assinatura é usada para testar como a implementação SAML se comporta quando não há **elemento de assinatura**. Quando um elemento de assinatura está **ausente**, a etapa de **validação de assinatura pode ser completamente ignorada**. Se a assinatura não for validada, qualquer um dos conteúdos que normalmente seriam assinados podem ser adulterados por um atacante.
.png>)
### Ferramenta
A exclusão de assinatura começa interceptando a resposta SAML e clicando em `Remover Assinaturas`. Ao fazer isso, **todos** os elementos de assinatura são removidos.
Com as assinaturas removidas, permita que a solicitação prossiga para o destino. Se a assinatura não for necessária pelo serviço
## Falsificação de Certificado
A falsificação de certificado é o processo de testar se o Provedor de Serviços **verifica se um Provedor de Identidade confiável assinou a Mensagem SAML**. O relacionamento de confiança entre SP e IdP é estabelecido e **deve ser verificado** cada vez que uma Mensagem SAML é recebida. O que isso significa é usar um certificado **autoassinado** para assinar a Resposta ou Declaração SAML.
### Ferramenta
A extensão Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) será usada.\
Para falsificar um certificado, comece interceptando a Resposta SAML.\
Se houver uma assinatura incluída na Resposta, use o botão `Enviar Certificado para Certificados SAML Raider`.
Depois de enviar o certificado, devemos ver um certificado importado na guia Certificados SAML Raider. Uma vez lá, destacamos o certificado importado e pressionamos o botão `Salvar e Autoassinado`.
Ao fazer isso, é gerado um clone autoassinado do certificado original. Agora é hora de voltar para a 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 `Remover Assinaturas` para remover quaisquer assinaturas existentes. Finalmente, use o **botão** **`(Re-)Assinar Mensagem`** ou `(`**`Re-)Assinar Declaração`** (**qualquer um** é **mais** **apropriado** em sua situação específica).
Depois de assinar a mensagem com o certificado autoassinado, envie-a em seu caminho. Se autenticarmos, sabemos que podemos assinar nossas Mensagens SAML. A capacidade de assinar nossas Mensagens SAML significa que podemos alterar valores na Declaração e eles serão aceitos pelo Provedor de Serviços.
## Confusão do Destinatário do Token / Confusão do Alvo do Provedor de Serviços
A Confusão do Destinatário do Token / Confusão do Alvo do Provedor de Serviços **testa se o Provedor de Serviços valida o Destinatário**. Isso significa que **se a resposta fosse destinada a um Provedor de Serviços diferente**, o **Provedor de Serviços atual deve notar e rejeitar a autenticação**.\
O campo **Destinatário** é um atributo do elemento **SubjectConfirmationData**, que é um filho do elemento Subject em uma Resposta SAML.
> O elemento SubjectConfirmationData especifica dados adicionais que permitem confirmar o assunto ou restringir as circunstâncias em que o ato de confirmação do assunto pode ocorrer. A confirmação do assunto ocorre quando um partido confiante procura verificar a relação entre uma entidade que apresenta a declaração (ou seja, a entidade que atesta) e o assunto das reivindicações da declaração.
O atributo Destinatário encontrado no **elemento SubjectConfirmationData é um URL que especifica o local para o qual a Declaração deve ser entregue**. Se o Destinatário for um Provedor de Serviços diferente daquele que o recebe, a Declaração não deve ser aceita.
### Como fazer
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ços**. Em segundo lugar, **SP-Alvo deve aceitar tokens emitidos pelo mesmo Provedor de Identidade que atende ao SP-Legit**.
O ataque é relativamente simples se as condições forem verdadeiras. Nós **autenticamos** no **SP-Legit** via o Provedor de Identidade compartilhado. Então **interceptamos a Resposta SAML em seu caminho do IdP para o SP-Legit**. Uma vez interceptada, enviamos a **Resposta SAML que foi destinada ao SP-Legit para o SP-Alvo em vez disso**. Se o **SP-Alvo aceitar a Declaração**; nos encontraremos conectados com o mesmo nome de conta que temos para o SP-Legit e teremos acesso aos recursos correspondentes do SP-Alvo.
## XSS na funcionalidade de logout
(Acesse a [pesquisa original aqui](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/))
Depois de realizar a força bruta de diretórios, encontrei a seguinte página:
```
https://carbon-prototype.uberinternal.com:443/oidauth/logout
```
É uma página de logout, eu abri o link acima e ele me redirecionou para a seguinte página.
```
https://carbon-prototype.uberinternal.com/oidauth/prompt?base=https%3A%2F%2Fcarbon-prototype.uberinternal.com%3A443%2Foidauth&return_to=%2F%3Fopenid_c%3D1542156766.5%2FSnNQg%3D%3D&splash_disabled=1
```
O parâmetro base está recebendo uma URL, então que tal substituí-lo pelo clássico `javascript:alert(123);` para acionar um XSS.
### Exploração em massa
Usando o [**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor), que pode receber uma lista de URLs e, em seguida, fornecer a URL de retorno (SAML consume), 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 vulnerável agradável.
```python
import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
from colorama import init ,Fore, Back, Style
init()
with open("/home/fady/uberSAMLOIDAUTH") as urlList:
for url in urlList:
url2 = url.strip().split("oidauth")[0] + "oidauth/prompt?base=javascript%3Aalert(123)%3B%2F%2FFady&return_to=%2F%3Fopenid_c%3D1520758585.42StPDwQ%3D%3D&splash_disabled=1"
request = requests.get(url2, allow_redirects=True,verify=False)
doesit = Fore.RED + "no"
if ("Fady" in request.content):
doesit = Fore.GREEN + "yes"
print(Fore.WHITE + url2)
print(Fore.WHITE + "Len : " + str(len(request.content)) + " Vulnerable : " + doesit)
```
## Referências
Os ataques foram obtidos em [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/)
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
* Você trabalha em uma **empresa de segurança cibernética**? Você quer ver sua **empresa anunciada no HackTricks**? ou você quer ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com)
* **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe seus truques de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).