log4jの脆弱性とは何だったのか調べてみた

セキュリティ
2021.12.17
最近話題になっている、log4jの脆弱性って何？

みなさま、こんばんはエンロックです。

今回は本ブログにおいて、記念すべき第１投目の調査ネタになります。

テーマとして、最近IT業界でものすごくホットな話題となっているlog4jの2.x系のバージョン（以降、必要な場合のみバージョンを記載）脆弱性(CVE-2021-44228)について記事にしようと思いました。

前述の「CVE」とは、世界中の脆弱性情報を管理するID・識別子。。。と思っていただければと思います
世の中で話題になっているlog4jの脆弱性が何か、その対策は何か以降でまとめました。

まず「log4j」って何？

本題に入る前に「log4j」とは何か、やはり本家から来た方を考えるとここから説明しないとつらくて・・・。

これはJavaというメジャーなプログラム言語で作られたアプリケーションの動作ログを出力するライブラリです。本ライブラリの提供している公式サイトはこちらです。

ログを残すことは何かアプリケーションのトラブルが起きたときの原因を追及するのに重要なため、それに特化した有名ライブラリでもあるlog4jの今回の脆弱性は、世の中のWebサーバの3分の１に影響するのではといわれているぐらいです。

では、どんな脆弱性なのか、本記事の本題でもある脆弱性の内容について、次章で述べます。

ログに出力させたいもの細工して不正プログラムを強制実行

さて本章では記事のかなめである、、、どんな脆弱性かを述べます。

前章でも述べたように、log4jはログ出力のライブラリです。ログに出力する内容といったら、時刻とかユーザの他に、ユーザが入力した内容もログ出力することがあります。

その入力した内容をうまい具合につくりあげて、出したくないデータを出したり、つなぎたくないサイトに接続したりとできる場合があります（今回は後者ですね・・・）。

 

今回log4jで見つかった脆弱性は、ユーザが悪意のあるLDAPサーバにアクセスする文字列をlog4jの出力部分に入れることによるものです。

具体的なイメージはこんな感じです（絵が幼稚すぎる・・・）

①　まず、ある攻撃者が{jndi:ldap～}などの細工した文字列を脆弱性のあるサーバに攻撃することから始まります

②　脆弱性のあるサーバ（要するにlog4j）が①で送られてきた文字列のうち、「ldap：～」の文字列を利用してLDAPサーバに接続します

LDAPサーバはディレクトリサービス（ネットワークに接続されたサーバ、プリンタ、アプリケーションなどのリソース情報を管理するサービス）への通信プロトコル

③　LDAPサーバでは、②で送られてきた文字列のうちJavaプログラムのクラス名を利用して、脆弱性のあるサーバ内の当クラス名の実行命令を含めたレスポンスを返します

脆弱性のあるサーバに、攻撃用のクラスを当サーバにダウンロードさせるやり方もあるのだとか

④　脆弱性のあるサーバで、③のレスポンスに含まれる実行命令を基に（意図せず）Javaプログラムのクラスを実行します

以上がlog4jの脆弱性により、起こりうる流れのようです。

 

この脆弱性の影響として、いろいろなサイトではサービス妨害につながると定義しています。

私が1番疑問に感じ、調べたいと思った理由がまさにこれで、この脆弱性がサービス妨害。。。「じゃあ具体的になんなの？」ってなりました。

要するに無駄にサーバでプログラムを実行する攻撃だから負荷がかかる。だからサービス妨害につながるんですよ、、、と理解しています。

 

今回の脆弱性のデモとして、YouTubeにも動画が挙がっています。

脆弱性の原因は2つの機能がセット！？

本節では脆弱性の原因を述べていきます。

log4jの2.14までJDNIとMessageLookUpという2つの機能が入っていました。

前述では「2.14」と書いてますが、2021/12/14にはlog4jの2.15でも同様の脆弱性があるそうです。

まずJDNIはJavaプログラムから外部のサービス（LDAP、DNS、NISなど）と接続するAPIの機能です。これがlog4jのデフォルトの設定で有効になっているため、LDAPへの接続が可能になっていたようです。

そしてもう１つの機能であるMessage Lookupはメッセージを解析する。。。はちょっと拡大解釈ですね・・・ログの一部の文字列を変数に置き換える機能のようです。log4jの1.x系には存在しなかった機能とのこと。

 

つまりlog4jの2系からはログ出力する場合に、外部サービスに接続する変数文字列を含むと、当サービスに接続できてしまうということですね。。。

脆弱性に対する対策はどうなっているか

本章では脆弱性の対策について示します。

前章でも述べたように原因となるMessage Lookup機能は1.x系にはなかったため、今回の脆弱性の影響は受けないとなっています(ただバージョンが古いので、それ以外の脆弱性などは注意したほうがよいかと・・・)。

log4jの2.0～2.15までを利用しているサービスについて、以下の対応が回避策あります(piyologさんを参考・・・)

  • 恒久策としては最新バージョンであるlog4j 2.16を利用(JDNI機能をデフォルトで無効、MessageLoopup機能を削除)
  • すぐに対応できない場合は今回の脆弱性の原因を引き起こすクラス(Jndi.class)をlog4jから取り除くこと
    (コマンド例：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class)

世の中には対策用ツールが開発されたり、起動するためのオプションをいじればよいとかいう意見もありますが、長期的にな目で見ると一時的な対策に過ぎないようです。またツールはいろいろな方の独自によるものなので注意されたし・・・

まとめ

今回は本ブログの初投稿としてlog4jの脆弱性について載せました。

ログに出力する文字列を細工することで、結果的に攻撃先のサーバに負荷をかけてしまう脆弱性が存在したということです。

そしてlog4jに搭載されている2機能が使えるようになってたこと原因だったということで、最新版では一方がデフォルトで無効、もう一方は削除という対策が取られています。

世の中は便利なソフトウェアが大量に出ていますが、それによる脆弱性のリスクが見込む必要があるということで、以上、今回ホットな話題でもあるlog4jについて記事にしました。

参考情報

コメント

タイトルとURLをコピーしました