Barracuda Threat Spotlight（バラクーダが注目する脅威）：ログインジェクション攻撃

2021.12.28

2021年12月22日、Jonathan Tanner

インジェクション攻撃は、OWASPの「Webアプリケーションの脆弱性トップ10」に恒常的にランクインしています。SQLインジェクション、コマンドインジェクション、クロスサイトスクリプティング（XSS）攻撃は、一般的に最初に思い浮かぶインジェクション攻撃の形態ですが、ログインジェクションにもリスクがあり、見過ごされている場合があります。

ログインジェクションとは、ユーザが操作した入力内容が無害化されずに記録された場合に発生するもので、リモートコード実行（RCE）など、さまざまな影響を及ぼす可能性があります。これは、最近公開されたCVE-2021-44228（別名「log4shell」）log4jに対する攻撃のように、2.15.0より前のバージョンのlog4jや、2.16.0以上で機能が完全に削除される前の2.15.xバージョンでデフォルトのformatMsgNoLookupsプロパティを無視した攻撃がそうでした。

脅威のハイライト

Log4j ログインジェクション RCE – 攻撃者がログインジェクション攻撃に成功したと仮定すると、JNDIを使ってLDAP検索を行う特別に細工された文字列置換を使って、攻撃者が制御するリモートLDAPサーバから読み込まれたコードを実行することができます。Javaアプリケーションにおけるlog4jの人気の高さと、任意のコードを実行できる能力を考慮して、Apacheはこの脆弱性が公開された際に可能な限り高い深刻度の評価を与えました。この脆弱性により、多くの著名な企業が影響を受けました。

詳細

開発者やシステム管理者は、ソフトウェアが正常に動作しているかどうかを確認したり、動作していない場合にはより具体的な内容を特定するために、ログの記録はほとんどのアプリケーションやシステムにとって重要な要素です。しかし、ログインジェクションは、アプリケーションやシステム自体のリスクだけではありません。なぜなら、ログが他のソフトウェアによって処理されることはよくあることで、そのソフトウェアもログインジェクションの試みに対して脆弱である可能性があるからです。基本的に、ログファイルに書き込んだり、ログファイルから読み取ったりするものはすべて、ログインジェクション攻撃の標的になる可能性があります。また、ログを読んでいる人も、ログインジェクション攻撃の標的になる可能性があります。ログインジェクション攻撃としては、ログの偽造、サービス拒否、悪意のある文字列のインジェクションなどが考えられますが、これらの攻撃自体にもいくつかの可能性があります。

ログの偽造とは、ログに記録されるペイロードを細工して、見た目は正当だが偽のログ行を追加することです。これは、ログ分析システムや、手動でログを読む人（またはイベントシステムを通じてログを読む人）を騙して、実際には起こっていないイベントが起こったと思わせたり、特定のイベントの発生頻度の分析を歪めたりするために使用されます。サービス拒否攻撃では、攻撃者が大量のデータでログファイルを圧倒します。これにより、メモリの枯渇、ディスクスペースの肥大化、あるいは、サイズに基づいてロールバックされ、ファイルのサブセットのみが保持されるログの場合には、ログシステムによってログエントリが早期に削除されることになります。これらのログインジェクション攻撃は、特定のプログラミング言語やテンプレートエンジンを利用する必要はありません。

悪意のある文字列インジェクションは、最近公開されたlog4jの脆弱性の場合、リモートコード実行を含め、様々な形態やペイロードを取ることができます。これらの悪意のある文字列は、ロガーやログを読み取るソフトウェアの組み込み機能を悪用することができます。log4shellの場合、文字列置換の側面が悪用されます。具体的には、log4jの式言語を使用して変数を検索し、ログ出力に置換することができる機能です。ログを表示または処理するソフトウェアでテンプレートエンジンが使用されている場合、使用されているテンプレートエンジンの構文を使用してテンプレートインジェクションが可能な場合があります。ログがWebブラウザに表示される場合、テンプレートインジェクションに加えて、Webサービスで使用されているプログラミング言語でコードを注入することが可能な場合があります。例えば、ログが必ずしも攻撃者でなくてもよいユーザに表示されるときに実行されるPHPコードをログに注入することができます。また、ログにJavaScriptを書き込んで、ユーザがWebアプリケーションを介してログエントリを閲覧したときにレンダリングされて実行されるようにする、つまりストアドクロスサイトスクリプティング攻撃も可能です。

インジェクション攻撃では、情報漏えいなど様々な結果やリスクが考えられますが、リモートコード実行（RCE）は、脆弱性のより深刻な結果の一つです。RCEは、攻撃者がアプリケーション内のコードを、あたかもアプリケーションの一部であるかのように実行し、アプリケーション自身が利用可能なあらゆるアクセス権や特権を得ることを可能にします。これにより、アプリケーションが利用可能なファイルや、アプリケーションが通信するデータベースへのアクセス、さらにはリバースシェルを介したホストシステム自体へのアクセスが可能になります。ファイルやデータベースへのアクセスは情報漏えいの原因となりますが、シェルは、攻撃者がネットワークにさらに侵入し、アプリケーションがアクセスできる範囲外のシステムやリソースを侵害するための出発点となります。このように、log4shell攻撃が悪用された場合、データとネットワークの両方のセキュリティに深刻な影響を与える可能性があります。

ロギングソフトウェアを構築・保守しているグループにとっては、今回の脆弱性により、データサニタイズ機能を組み込む必要性と、セキュリティリスクを考慮してどの程度の機能が有用であるかを検討する必要性が浮き彫りになりました。ほとんどのデータベースクライアントライブラリは、SQLライブラリの「プリペアドステートメント」のようなインジェクション攻撃から保護するために、データサニタイズ機能を提供しています。独自の式言語やテンプレートを持つロギングライブラリの場合、安全ではない可能性のある文字列をロギングする際、ライブラリのユーザに同様の機能を提供することは大変役立ちます。log4shellのような深刻な脆弱性につながる可能性のある機能を数多く利用している場合、保守管理者が検討すべき課題かもしれません。このRCEを可能にする機能が2.16.0で削除されたことを考えると、log4jの保守管理者はすでにこの点に気づいているかもしれません。

log4shellからの保護方法

log4shellから保護するための最善の方法は、少なくともlog4jのバージョン 2.15.0、理想的には2.16.0以上にアップグレードして、この特定のRCEを軽減することです。log4jは直接の依存関係の外でアプリケーションに含まれているかもしれないので、ビルドシステムを使用して依存関係ツリーを入手し、間接的な依存関係としてのlog4jの脆弱なバージョンを確認することができます。「Maven」と「Gradle」は、プロジェクトの依存関係ツリーを印刷するコマンドラインツールを含んでいます。log4jのバージョンが2.10.0以上、2.15.0未満の場合、2.15.0でデフォルトで無効化された機能は、javaコマンドを使用してアプリケーションを実行する際「-Dlog4j2.formatMsgNoLookups=true」フラグを追加することで手動で無効化できます。バージョン2.15.xを使用している場合は、アプリケーションやコマンドのどこかでこのフラグがfalseに上書きされていないかどうかを確認する必要があります。

ファイアウォール（ネットワーク、Webアプリケーションを問わず）は、アップグレードの計画と実行に時間がかかる場合の暫定的な対策として、LDAPトラフィックの送信をブロックできる可能性があります。しかし、これらの対策は、この特定の脅威を保護するだけで、ログインジェクション全般を保護するものではありません。Barracuda Web Application FirewallとWAF-as-a-Serviceは、log4shellに関連するものを含むログインジェクションの試みを保護します。

ログを使用するすべてのアプリケーションは、たとえそれがlog4jやJavaを使用していなくても、外部からユーザが提供した入力がログに記録されるときに、ログインジェクション攻撃の可能性と、ログの特定の用途に関連する適切なデータサニタイズの実践を確認すべきです。これにより、ログインジェクションに関連して存在する可能性のある他のまたは将来の脆弱性を軽減することができます。サニタイズは、アプリケーションやログシステムの機能を考慮するだけではなく、ログから読み取るものがさらに別の可能性のある脆弱性を引き起こす可能性があるため、単純ではありません。同様に、そもそも何がログに記録されているかということも考慮しなければなりません。例えば、ユーザ名やメールは、インジェクション攻撃を可能にするような特殊文字を許可するケースとしてはリクエストヘッダに比べて妥当性が低いと言えますが、これらの文字を必要とするケースもあります。

ログが実際にどのようなシステムで処理されているのか、そのシステムにはどのような脆弱性が存在するのかを考慮することで、ログがもたらすリスクを適切に評価することができます。これは、ログインジェクション攻撃が発生する場所をすべて把握しなくても、その潜在的な影響を理解するのに役立ちます。ログインジェクションは、ログを読み取るすべてのシステムに影響を与える可能性があるため、ログを読み取ったり処理したりしているシステムを追跡することは、ログの記録に関連する特定のリスクを理解するのに役立ちます。また、セキュリティチームや開発チームにとっては、攻撃者がコントロールできるログの内容に関して、どのようなプログラミング、テンプレート、式言語を考慮する必要があるのか絞り込むことができます。