Skip to content

公表から1年、Log4Shellのこれまでと今後

2021年12月10日、Javaベースのログ出力ライブラリ「Apache Log4j」の2.x系バージョン(以降Log4j2)において、深刻な脆弱性(CVE-2021-44228)があることが公表されました。この脆弱性は影響を受ける機器が多く存在することと攻撃が容易であることからLog4Shellと呼ばれ世界中の組織が対応に追われました。また、「 10年以上にわたってセキュリティ・リスクをもたらす風土病のようなものになる」という見解もあります。公表から1年、改めて整理してみたいと思います。

Log4jとは

Apache Log4jは、Apache Software Foundation が提供するJavaアプリケーションにおける部品(ライブラリと呼ばれています)の一つです。オープンソースの為、無償で使用できます。提供元のApache Software Foundationは、オープンソースのソフトウェアプロジェクトを支援する団体で、WebサーバソフトウェアであるApache HTTP Server (Apache httpdや単にApacheと呼ばれることも多い) が有名です。
コンピュータは、利用状況やエラー、データ通信の内容などを時系列に記録しており、この記録や記録したデータをログ(Log)と呼んでいます。Log4jは、ログを記録したり表示したりするために必要な機能が詰まっており、無償ということもあり、世界中のJavaアプリケーションで使われるようになりました。

Log4Shellとは

ログを入出力する部品ですから、外部と通信を行うことは普通ありません。ましてや外部から任意の命令を実行されるなどということは起こり得ないように思えます。
ところが、Log4j2 には特定の文字列がログに含まれた場合、変数として置換する JNDI Lookupと呼ばれる機能が実装されていました。この機能を使って日付や環境情報などを動的にログに出力することができます。分かりやすく例えると、todayという文字列を今日の日付に置き換えたり、thiscpuという文字列をこの機器のCPU名称に置き換えたりできるということです。便利な機能ですが、この機能には悪用すると指定したサーバからプログラムを読み込ませ実行することができてしまう欠陥があり、この欠陥(=脆弱性)がLog4Shellなのです。

 

   <Log4Shellの仕組み>


通常、このような脆弱性は、インターネットからアクセスできる機器が主に影響を受けますが(※)、Log4Shellについては、インターネットからアクセスできない機器でも、他の機器からログを引き渡されている場合、影響を受ける可能性があるのです。

※ インターネットからアクセスできなくとも攻撃者がネットワークの内部に侵入すれば攻撃は可能ですが、攻撃を受ける可能性はかなり下がるため、「主に影響を受ける」と記述。

 

   <Log4Shellの仕組み(ログの引き渡し先で影響が出る場合)> 

 

Log4Shellが危険な理由はその攻撃の容易さにもあります。特殊な文字列がログに記録されるようにすればよいのですが、方法の一つにその特殊な文字列をhttpヘッダに埋め込んだhttpリクエストを送信する方法があります。httpヘッダは多くのWebサーバでログに記録されています。


一筋縄ではいかない影響調査

Log4Shellは影響範囲があまりにも広いと述べましたが、広いだけでなく使用有無の調査が一筋縄ではいかないことが、この問題をさらに大きくしました。
「影響範囲が広いと言ったって資産台帳やソフトウェア台帳を調べればどの機器で使っているのか調査できるのでは?」と思われるかもしれませんが、Log4jのような部品レベルまで台帳に載せている組織はほとんどありません。例えばWebサーバの場合、OSであるLinuxやWebサーバソフトウェアであるApache HTTP Server、データベースであるMySQLなどの基本的なサービスを構成するソフトウェアは台帳に記載されていますが、ライブラリとなると百の単位で存在するため、OpenSSLやOpenSSHなど通信に関連するライブラリなどいくつかをピックアップして記載するのが精一杯です。さらには、このような部品は各ベンダーの製品に同梱される形で販売されており、意識されずに使われていることも多いのです。
Log4Shellの公表後、各ベンダーが五月雨式に自社製品におけるLog4Shellの影響有無の公表を始めました。例えばOracle社のWebLogic ServerやVMware社のHorizonが影響を受けることが公表されています(既に修正済)。このような各ベンダーの情報を収集しLog4j2の使用有無やLog4Shellの影響有無を調査していく必要があります。幸にも、オランダのサイバーセキュリティセンター (NCSC-NL)が1,900近くの製品に対し、Log4Shellの影響有無や、修正済未済等を一覧形式で整理したものを公表してくれました。しかしながら、影響範囲の特定には地道な作業が必要ですし、抜け漏れなく特定するのは至難の技と言えるかもしれません。

悪用が続いたLog4Shell

Log4Shellの公表から程なくして悪用が始まりました。特に、多くの組織のリモートアクセスに利用されているVMware Horizon への攻撃が頻発しました。
2022年1月に、英国の国民保健サービス (NHS:National Health Service) が、Log4Shellを含むHorizonを標的とした攻撃について、警告を発しました。
2022年3月には、あるセキュリティベンダーが、2022年1月からHorizonに対する攻撃が観測されていると発表しました。この発表によると、攻撃の多くは、暗号資産を不正にマイニングする不正プログラムのインストールを試みるものとのこと。また、いくつかの事例では、侵害したシステムで永続的なアクセスを維持するためのバックドアのインストールを試みるものとのことで、このようなバックドアはランサムウェアの攻撃グループ等に販売される可能性が高いとのことです。
2022年6月には、米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)がVMware HorizonにおけるLog4Shellを悪用したサイバー攻撃の発生について注意喚起をリリースし、7月18日にも内容を更新し再度リリースしました。
このように、2022年の8月ぐらいまでは、注意喚起やレポートの公表が継続していましたが、9月以降は組織側の対応が進んできたのか、新たな注意喚起のリリースもなく、状況は落ち着いて来たようです。

Log4Shellの対応状況

あるセキュリティベンダーの調査によると、2022年10月の時点で、30%近くの組織が Log4Shell を完全に是正しているとのことです。このことから急速にLog4Shellの対応が進められたことが推測できます。ただし、70%の組織は未対応の機器が残存しているということであり、あまりにも影響範囲が広いため、優先度の高いものを対応するのが精一杯だった組織も少なくないと思われます。
もう一つ気になるデータがあります。同じセキュリティベンダーの調査ですが、Log4Shellの脆弱性のある機器の30%近くにおいて、一旦対応した後にLog4Shell が再検出されたとのことです。恐らくLog4Shellの対応を行った後に新たにインストールやアップデートを行った製品に古いLog4j2 が含まれていたということなのでしょう。どうやら今後数年間は、新たな製品のインストールや製品のアップテートの際にLog4j2の使用有無やバージョンを確認する必要がありそうです。

Log4Shellの今後

Log4Shellの影響のある機器については、インターネットとの送受信の有無や他の機器からのログの受け取り有無で以下の6つに分類できます。
インターネットからの受信可否 インターネットへの送信可否 他の機器からのログの受け取り有無で以下の6つに分類できます。

 

インターネットからの
受信可否

インターネットへの
送信可否

他の機器からのログの
受け取り有無

Yes

No

Yes

No

Yes

No

A

 

 

B

 

 

C

 

 

 

D

 

 

 

E

 

 

 

F

 

 

 


Log4Shellの対応の優先度が高い順にA、BとC、D、E、Fとなりますが、この記事の執筆時点(2022年12月下旬)では、多くの組織で、優先度の高い幾つかのカテゴリの対応は終わったものの、それ以外は対応中もしくは対応計画すらない状況だと思われます。攻撃者がネットワークの内部に侵入すればEやFについても攻撃可能ですので、全てを対応することが望ましいのですが、完全に対応するには相当なモチベーションとリソースが必要であり、優先度の低いカテゴリの対応率は100%には至らずある程度のところで止まってしまう組織は少なくないと思われます。そしてシステムの更改等によってソフトウェアが入れ替わるまでLog4Shellが存続する、つまり「完全に対応するには10年以上かかる」ということになるかも知れません。しかしながら「延々と悪用され続ける」のかというと筆者はそうは思いません。それは、Log4Shellが延々と残存する組織には他の(より攻撃が容易な)脆弱性も残存していることが少なくないと思われるからです。
それよりも、対応が完了した機器に古いLog4j2がインストールされることによってサイバー攻撃を受けてしまうリスクの方が看過できず、このリスクは今後数年、私たちを悩ませることになるかも知れません。

 

 

<参考URL>
List of software (un)affected by the log4shell CVEs(NCSC-NL)
https://github.com/NCSC-NL/log4shell/blob/main/software/software_list_o.md

Log4Shell の発見から1年:残存率は 2.5% にまで減ったが 再発率は 29%
https://iototsecnews.jp/2022/11/30/a-year-later-log4shell-still-lingers/


コンサルタント、フリーライター。
三菱UFJ銀行で12年間サイバーセキュリティに従事し、その後、Transmit Security 日本支社共同代表を経て独立。現在はサイバーセキュリティに関するコンサルティングやアドバイザー業務を行うとともに、国土交通省最高セキュリティアドバイザーや日本シーサート協議会専門委員、⾦融ISAC個⼈賛助会員として活動している。