Log4jの脆弱性を狙った攻撃が来たので分析してみた

最近話題になっているJavaのロギングライブラリLog4jの脆弱性(CVE-2021-44228)を狙う攻撃が我が家のWebサーバ宛にも送られてきたので、分析してみました。

送られてきたもの

送られてきたリクエストは以下のようなものです。

オレンジ: WebサーバIP

水色：攻撃者グローバルIP

黄緑：base64文字列の一部マスク

jndi:ldapという文字列に加え、base64の文字列が渡されています。

攻撃者IPのロケーションはSt Petersburg, St.-Petersburg, Russia (RU)でした。

base64部がどのようなものか、デコードして確認します。

pyhtonで以下のようなコードを実行しました。

---

import base64

print(base64.b64decode(b'base64文字列').decode())

---

結果は以下のようになっています。

オレンジ: WebサーバグローバルIP

水色：攻撃者グローバルIP

これを見るとcurlかwgetで文字列を取得し、bashに渡していることがわかります。

また、パス内に私のWebサーバのグローバルIPアドレスが入っており、相手を識別しているように見えます。

つまり、攻撃者のサーバに置かれた任意の文字列をbashで実行できてしまうため、何でもやり放題です。Webの書き換え、BotNetに取り込む、踏み台にする etc....

(未対策のJavaで作られた鯖にアクセスしたくなくなりますね...何が置かれてるかわからない...)

GCPに捨てインスタンスを立てて、curlでアクセスしてみました。

が、パスに自身のグローバルIPは使いたくなかったので、0.0.0.0に置き換えています。

結果はこのようになっており、何も帰ってきませんでした。

IPを置き換えたことに起因しているのか、偵察的なアクセスで空なのかはわかりません。

(他の人の情報を見ていると同じ様に何も帰って来ないようだったので、追求しないことにしました。)

今回の検証で、Log4jの脆弱性はかなり簡単にリモートコードを実行できるヤバい奴だということがよくわかりました。みなさんもセキュリティパッチの適応やマメなアップデートの適応、ファイアウォールの設定等を忘れないようにしましょう。

-追伸

2021-12-13の攻撃を確認した所、WAF対策と思われる処理をしたリクエストが飛んできていた。

よって、WAF等で対策したから大丈夫と安心せず、根本的な脆弱性対策や、権限設定、厳格なFW設定等を組み合わせ、複数の階層で攻撃を止められるような設計(スライスチーズモデル)にしていくことが望ましい。

ばいち