はじめに
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2020年12月13日、IT管理ソフトやリモート監視ツールの開発を行うSolarWindsは同社が開発するOrion Platformにバックドアが含まれていたことを公表しました。同社の製品は米国の多数の政府機関、企業で導入されていたため影響範囲が広く、またFireEyeが12月8日に発表した不正アクセス事案との関連があったことから米国を中心に大きな注目を浴びる事案となりました。また、2021年5月7日、ランサムウェアと恐喝を使用して被害者から身代金を奪うハッカー集団である犯罪者グループDarkSideからのランサムウェア攻撃を受け、アメリカ東海岸の燃料供給の約半分となる45%を担う民間企業コロニアル・パイプライン社は、1週間にわたって操業停止に追い込まれました。このようにサーバー攻撃やランサムウェアによる攻撃を受け、社会インフラに重大な影響を与える事案が発生しています。
『Log4Shell』とは
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
2021年12月には、Javaのログ収集ツールApache log4jにリモートコード実行の脆弱性『Log4Shell』が発見されました。深刻度は「緊急(Critical)」と評価され、悪用が簡単でかつリモートから任意のコードが実行可能、そして影響範囲が世界中のかなりの範囲に及ぶことから、この脆弱性について、セキュリティベンダーおよび各国のセキュリティ機関が繰り返し注意喚起を行いました。この脆弱性はHeartbleedやShellshockに並ぶ最悪の脆弱性となる可能性が高いとし、「Log4Shell」という名称で呼ばれています。
脆弱性の内容をもう少し詳しく説明すると
① 攻撃者が攻撃用文字列を含むHTTPリクエストを送信
② アクセスしたユーザーの情報をLog4jがログに出力
③ JNDI Lookup機能によりLDAPサーバーにアクセス
④ 攻撃用Javaプログラムを返送する
⑤ 攻撃用Javaプログラムの実行
また、警察庁の「＠police」によると、脆弱性が発見された当初は、多くの攻撃が観測されましたが、その後、徐々に攻撃は減少しているのが見て取れます。このグラフは、全国の警察施設のインターネット接続点に設置されたセンサーで観測したアクセス（件数）の１センサー当たりの平均の推移を示したものになります。(*1)
まだまだ対策されていない『Log4Shell』
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
では、本当にこの脆弱性に対する対策は、終了したと考えてよいのでしょうか？興味深い調査結果が公開されましたので、ご紹介したいと思います。
GoogleのサービスであるOpen Source Insights(https://deps.dev)を使って現在の状況を調べてみると下記のような結果を得ることができます。このサービスは、何百万ものオープンソースパッケージをスキャンし、依存関係グラフを構築し、所有者、ライセンス、人気、その他のメタデータに関する情報で注釈を付けるもので、Log4Shell 脆弱性の影響を受けるコンポーネント、つまり org.apache.logging.log4j:log4j-core を使用しているコンポーネントを調査すると、影響を受ける合計 17.95K パッケージのうち Log4Shell に対してパッチを適用しているのは 7.49K だけであることがわかります。つまり、脆弱性のあるパッケージの60%近くがまだパッチを適用されていないことになります。
Sonatype(https://www.sonatype.com/)はLog4jの脆弱性リソースセンターを運営しており、Log4jのダウンロード量を追跡し、バージョンや地域などに基づいた統計情報を提供しています。
下の画像は2022年4月20日時点のものですが、Maven Centralから活発にダウンロードされたLog4jのバージョンの36%は、まだLog4Shellに対して脆弱性があります。
赤い部分は、Log4Shellに対して脆弱なLog4jのダウンロードの割合を示しており、2月初旬からほぼ横ばいになっています。今もダウンロードされている理由で考えられるのはThe Wall Street Journal(*2)によると以下の２点です。
・脆弱性を分析しようとするセキュリティ研究者によるダウンロード
・インターネットからアクセスできないアプリケーションやネットワークにLog4jが展開されているため、修正の優先順位が低いケース
しかし、研究者はこのように継続してダウンロードする必要がないことを考えると無意識のうちに脆弱性が含まれているバージョンを使用していると考えるのが妥当だと言えます。
一般的に実稼働環境では、log4jのようなJavaファイルは、何層にもネストされているため、検出するのが難しいです。また、Javaアプリケーションはさまざまな方法でパッケージ化されることがあるので、分析するツールはさまざまな形式をサポートする必要があり、すべてをカバーできているとは言えないでしょう。
また、自社のアプリケーションでLog4jを検出して、パッチを当てただけでは終わりません。商用、オープンソースを問わず、サードパーティーソフトウェアにも対応しなければいけません。脆弱性のあるサードパーティーソフトを検出できたとしても、アップデート版をリリースするのを待つ必要があります。
まとめ
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
このように、ソフトウェアパッケージにどのようなファイルが含まれているかを手作業で正確に調べることは大変困難です。無償や商用の各種ツールを活用して、依存関係を明らかにして、リスクを最小限にする必要が今後ますます求められることになります。
今後も新たな脆弱性が発見されたときに困らないように日頃からSBOMと呼ばれるソフトウェアの部品表でソフトウェアを管理することが必要になってきます。
(*1)https://www.npa.go.jp/cyberpolice/important/2021/202112141.html
※本文中記載の会社名、商品名、ロゴは各社の商標、または登録商標です。
Tips集のご案内
テクマトリックスでは、開発企業としてOSSと上手につきあうための「OSS活用Tips集 – シーズン2」を提供しています。
「資料ダウンロードはこちら」から、ホワイトペーパーを一括でダウンロードできます。
1.「OSS最新動向-コロナに負けないオープンソース」
2.「オープンソースSBOMが必要な理由とは！」
3.「ソフトウェアイノベーションはOSSから、コンテナ・AI技術がイノベーションを牽引」
4.「OSSと上手に付き合う方法～攻めは最大の防御なり～」
5.「OSSと上手に付き合う方法～サプライチェーンを安全に～」
6.「ISO/IEC 5230で変わる？OSSコンプライアンス対策」
7.「著作権トロールとは？」
