Pentests と Log4J: 脆弱なシステムを悪用する方法

この記事では、脆弱なシステムを侵入テストし、誰でも利用できる Log4j オープンソース エクスプロイトを使用してリモート シェルを取得する方法を示します。

序章

CVE-2021-44228 とラベル付けされたこの重大な脆弱性は、Apache Log4j コンポーネントが商用ソフトウェアとオープンソース ソフトウェアの両方で広く使用されているため、多数の顧客に影響を与えます。さらに、ランサムウェアの攻撃者は、Log4j エクスプロイトを武器にして、世界中のより多くの被害者に到達できるようにしています。

私たちのデモンストレーションは、このエクスプロイトがどのように機能するかについてより多くの認識を提供することを目的として、より技術的な聴衆への教育目的で提供されています.

Raxis は、エクスプロイトの構成をよりよく理解することが、ユーザーがインターネット上で増大する脅威と戦う方法を学ぶための最良の方法であると考えています。

Log4j エクスプロイト ストーリーボード

Apache Log4j の脆弱性、CVE-2021-44228 ( https://nvd.nist.gov/vuln/detail/CVE-2021-44228 ) は多数のシステムに影響を及ぼし、攻撃者は現在、この脆弱性をインターネットに接続された世界中のシステム。

このような攻撃の構造を示すために、Raxis は実際のエクスプロイトの段階的なデモンストレーションを提供します。デモンストレーションでは、被害者のサーバーに使用されているネットワーク環境が、この攻撃の実行を可能にすることを想定しています。

より安全なファイアウォール構成やその他の高度なネットワーク セキュリティ デバイスを使用するなど、この攻撃の成功を防ぐ方法は確かにたくさんありますが、この攻撃を実証する目的で、一般的な「デフォルト」のセキュリティ構成を選択しました。

被害者サーバー

まず、攻撃対象のサーバーは Tomcat 8 Web サーバーであり、Apache Log4j の脆弱なバージョンを使用し、docker コンテナー内に構成およびインストールされています。

docker コンテナーを使用すると、テスト環境から分離された被害者サーバー用の別の環境を示すことができます。 Tomcat サーバーは、 https://github.com/cyberxml/log4j-pocから取得できるサンプル Web サイトをホストしており、脆弱な Web サーバーのポート 8080 を公開するように構成されています。

この docker コンテナーの他のインバウンド ポートは、8080 以外に公開されていません。多くのサーバー ネットワークのデフォルト構成と同様に、docker コンテナーはアウトバウンド トラフィックを許可します。

この特定の GitHub リポジトリには、組み込みバージョンの Log4j 攻撃コードとペイロードも含まれていましたが、この例ではそれを無効にして、攻撃者が見た画面を表示できるようにしました。以下のスクリーンショットに示すように、Tomcat 8 Web サーバー部分のみを使用しています。

図 1: Log4j エクスプロイトに対して脆弱なコードを実行している被害者の Tomcat 8 デモ Web サーバー

次に、攻撃者のワークステーションをセットアップする必要があります。 Raxis は、 https://github.com/kozmer/log4j-shell-poc のエクスプロイト コードを使用して、以下に示すように、Netcat Listener、Python Web Server、および Exploit と呼ばれる 3 つのターミナル セッションを構成します。

Netcat リスナー、ポート 9001

図 2 に示されている Netcat リスナー セッションは、ポート 9001 で実行されている Netcat リスナーです。このセッションは、エクスプロイトを介して被害者のサーバーから渡されるシェルをキャッチするためのものです。

図 2: ポート 9001 上の攻撃者の Netcat リスナー

Python Web サーバー、ポート 80

図 3 の Python Web サーバー セッションは、被害者のサーバーにペイロードを配布するためにポート 80 で実行されている Python Web サーバーです。

図 3: ペイロードを配布する攻撃者の Python Web サーバー

悪用コード、ポート 1389

図 4 に示すエクスプロイト セッションは、ポート 1389 で動作する概念実証の Log4j エクスプロイト コードであり、兵器化された LDAP サーバーを作成します。

このコードは、被害者のサーバーをリダイレクトして、上記のポート 80 で実行されている Python Web サーバーから取得した Java クラスをダウンロードして実行します。

Java クラスは、図 2 の Netcat リスナーであるポート 9001 にシェルを生成するように構成されています。

図 4: 攻撃者の Log4J エクスプロイト コード

攻撃を実行する

コードがステージングされたので、攻撃を実行します。 Chrome Web ブラウザーを使用して、被害者の Web サーバーに接続します。

図 5 に示す攻撃文字列は、JNDI を悪用して、ポート 1389 で実行されている攻撃者のエクスプロイト セッションに対して LDAP クエリを作成します。

図 5: 被害者の Web サイトと攻撃文字列

攻撃文字列は、Log4j の脆弱性を悪用し、攻撃者の兵器化された LDAP サーバーに対してルックアップを実行するように要求します。

これを行うために、被害者のサーバーからポート 1389 で攻撃者のシステムにアウトバウンド リクエストが行われます。図 6 のエクスプロイト セッションは、インバウンド LDAP 接続の受信と攻撃者の Python Web サーバーへのリダイレクトを示しています。

図 6: インバウンド接続とリダイレクトを示す攻撃者のエクスプロイト セッション

Exploit セッションは、シェルを開くコードを含む武器化された Java クラスを提供している Python Web サーバーにリダイレクトを送信しました。

この Java クラスは、実際には Exploit セッションから構成されたもので、Python Web サーバーによってポート 80 でのみ提供されています。接続ログを下の図 7 に示します。

図 7: Java シェルを送信する攻撃者の Python Web サーバー

攻撃の最後のステップは、Raxis が被害者のサーバーを制御するシェルを取得するところです。被害者に送信された Java クラスには、攻撃者の netcat セッションに対してリモート シェルを開くコードが含まれていました (図 8 参照)。

攻撃者は、Tomcat 8 サーバーを完全に制御できるようになりましたが、このテスト シナリオで構成した docker セッションに限定されています。

図 8: 被害者のサーバーを制御するシェルへの攻撃者のアクセス

結論

これまで説明してきたように、Log4j の脆弱性は複数のステップからなるプロセスであり、適切な部分が整っていれば実行できます。 Raxis は、悪用するシステムをインターネットで検索しているランサムウェア攻撃ボットにこのコードが実装されていることを確認しています。

攻撃者が公開されたシステムに到達するのは時間の問題であるため、これは間違いなく、できるだけ早く対処する必要がある重大な問題です。

こちらにも掲載