Snyk で Log4Shell 攻撃を速やかに発見・修正する
Ariel Ornstein
2021年12月13日
0 分で読めます編集者のメモ:(2021 年 12 月 28 日 7:35pm GMT):2.17.0 が CVE-2021-44832 で特定されたリモートコード実行に対して脆弱であることがわかったことに基づいて、Log4j チームが新しいセキュリティアップデートをリリースしました。現時点では最新バージョン 2.17.1 にアップグレードすることをおすすめします。詳細については、こちらをご確認ください。
編集者のメモ:(2021 年 12 月 28 日 6:55pm GMT):Log4j の状況は刻一刻と変化しているため、最新情報を入手でき次第、ブログを更新します。2.17.1
以降のバージョンにアップグレードすることをおすすめします。このバージョンには、2.15.0
(CVE-2021-44228) および 2.16.0
(CVE-2021-45046) で修正されたリモートコード実行の 2 つの脆弱性と、2.17.1 (CVE-2021-45105) で修正された最新の DoS 脆弱性に対するセキュリティ修正が含まれています。詳細については、こちらをご確認ください。
たとえ皆さんが静かな週末を楽しもうと用意周到に計画していたとしても、金曜日(2021 年 12 月 10 日)に新しい Log4Shell のゼロデイ脆弱性が公開されたことで、少なくとも 1 回は邪魔が入ったことでしょう。
この新たな脆弱性は、最も普及している Java ロギングフレームワークの 1 つである Log4J のコンポーネントのオープンソース Java ライブラリ log4j-core
で発見されました。この脆弱性には CVE-2021-44228 が割り当てられ、CVSS スコア 10 で重大と分類され、現実に悪用されている明白な根拠があるため、悪用レベルは成熟段階にあります。
2.0-beta9 から 2.14.1 までのすべてのバージョンがこの新しい脆弱性の影響を受けますが、この脆弱性は、開示と同じ日にリリースされた最新バージョン (2.16.0) で修正されています。
Snyk はこの新しい脆弱性を Snyk Intel 脆弱性データベースに速やかに追加することで、顧客、パートナー、コミュニティ全体が JVM アプリケーションとコンテナをスキャンし、Snyk Open Source と Snyk Container を使用してこの脆弱性に緊急修正を適用できるようにしました。
Snyk を Log4Shell の発見・修正に役立てるには
多くの人はまず、この脆弱性に対する自分のエクスポージャのレベルはどの程度かを考えます。
それは Snyk を使い、パッケージの脆弱なバージョンを使用しているかどうか、またそれらがどこで使用しているかを確認することで、明らかにできます。Snyk は、SDLC 全体にわたって問題を修正する場合にも役立ちます。
ここでは、コーディング時、SCM 統合、または継続的な監視サービスによる警告などにより、Snyk を使って Log4Shell に対して脆弱であるかどうかを確認する方法を紹介します。また、レポートサービスと API を使用してこれを大規模に実行する方法も紹介します。
アンマネージドで宣言されていないコードに対する Snyk CLI コマンド: snyk log4shell
Snyk CLI には、Log4Shell 脆弱性の影響を受ける Log4j ライブラリの軌跡を検索するという目的のためだけに設計された新しいコマンドがあります。snyk log4shell
は、ビルドされた Java プロジェクトをテストし、マニフェストファイルで宣言されていない場合でも、脆弱なライブラリの軌跡を検索します。snyk log4shell
とそれをプロジェクトで使用する方法についてご覧ください。
Log4Shell の脆弱性をコーディング時に発見する
脆弱性をできるだけ早く見つけるために、開発者は無料で始められる IDE プラグインと CLI を使用できます。スキャンの結果には、Snyk が発見したすべての脆弱性と、各脆弱性がアプリケーションにどのように導入されたか (直接的または間接的な依存関係として)、および修正方法に関する明確な指示が含まれます。
Snyk CLI (最新バージョンの v1.792.0 を使用していることを確認してください) は、脆弱性が見つかった場合、ひときわ目立つ特別な警告メッセージを表示します (Snyk CLI のインストールと更新の手順については、ドキュメントを参照してください)。
jar として追加された log4j-core をスキャンする
パッケージマネージャー (Maven など) を使っていなくても、Snyk は jar ファイルの脆弱性を検出できます。これを検出するには、現在のフォルダー内のすべての jar をスキャンするため、snyk test --scan-all-unmanaged
コマンドを実行するだけです (プロジェクトを継続的に監視する sn
yk monitor
コマンドも使用できます)。
Snyk の SCM 統合でプロジェクトの Log4j 脆弱性をテストする
ほんの数回のクリックだけで、Snyk がサポートするすべてのプロジェクトをインポートし、オープンソースの脆弱性をテストして、どのような脆弱性があり、どのように導入され、どのように修正できるかなど、脆弱性に関する即時の洞察を得ることができます。
Snyk は、特定された脆弱性に関する豊富な情報を提供します。こうした情報は、脆弱性を修正する方法や、他の脆弱性よりも先に対応する必要がある脆弱性の優先順位を理解する上で重要です。
Snyk の優先度スコアは、脆弱性が悪用されているか、修正プログラムがあるか、X (旧 Twitter) でトレンドになっているかなど、さまざまなシグナルのリストに基づいて計算されます。このスコアを使用して、脆弱性のリストを速やかに選別し、それに応じて修正の優先順位を決定できます。Log4Shell の場合、スコアの上にマウスを置くと表示される説明にあるように、優先度スコアはかなり高くなります。
プロジェクトの依存関係ツリーは、直接的か間接的かを問わず、脆弱性がアプリケーションにどのように導入されたかを正確に理解するのに役立ちます。
Log4j の脆弱性の将来的な発生を防ぐ継続的な監視
新しい脆弱性の開示前にプロジェクトをインポートしていた場合、プロジェクトは毎日のテストサイクルの一環として自動的にテストされていたことを意味します (デフォルトの設定を変更していない限り)。通知を有効にしている場合は、プロジェクトの 1 つに脆弱性が見つかったかどうかを知らせる通知が届いているはずです。
log4shell の自動修正 PR/MR
新しい脆弱性の開示前にリポジトリが Snyk によってすでに監視されていた場合、Snyk は log4j-core
を脆弱性のないバージョンにアップグレードする修正 pull/merge リクエストを自動的にトリガーしています。
新しいインポートの場合や、自動修正 PR を有効にしていない場合は、プロジェクトページから手動で修正 PR を作成できます。
すべてのビジネスサービスにおける Log4Shell の検出・修正
Snyk の API やレポートサービスにアクセスできるお客様には、監視対象のすべてのオープンソースプロジェクトで log4j-core
の依存関係が使用されている場所を把握する便利な方法があります。
log4j-core
を使用しているプロジェクトを Snyk のレポーティング機能で見つける
Snyk の部品表 (グループおよび組織レベルのレポートの「依存関係」タブにあります) を使用して、log4j-core
を使用している場所を検索できます。「依存関係」フィルターを開き、依存関係名 (log4j-core
) を入力し、それを選択して結果をこのパッケージだけに絞り込みます。結果が表示されない場合は、Snyk で監視しているプロジェクトにこの依存関係がないことを意味します。
依存関係が見つかれば、それがどこで使われているかを正確に知ることができます。「プロジェクト」リンクをクリックすると、依存関係として log4j-core
を使用するすべてのプロジェクトのリストが表示されます。プロジェクト自体をクリックすると修正手順が表示され、アップグレードパスがある場合は修正 pull/merge リクエストを開くことができます。
log4j-core
を使用しているプロジェクトを Snyk の API で見つける
API を使用して、log4j-core
の依存関係を使用している場所を見つけることもできます。組織別の依存関係エンドポイントでは、使用されているすべての依存関係をリストに表示し、使用されている場所の結果を取得できます。言語 (ここで該当するのは Java) や重大度などのフィルターがいくつかあるので、結果を絞り込むことができます。複数の組織を含むグループがあり、すべてをループ処理したいときは、グループ内のすべての組織をリスト表示するエンドポイントを使用します。
応答の一部として、該当するパッケージを含むすべてのプロジェクトのリストが表示されます。ここから UI を使用してプロジェクトを確認し、脆弱性を修正するか、その他の API を使用して修正手順を入手できます。
Snyk をご活用ください
Snyk の利用開始は無料、しかも手軽で簡単です。今すぐ参加して、脆弱な log4j-core パッケージ (およびその他のパッケージ) を使用している場所を特定して簡単に修正しましょう。皆さんが週末をゆっくり過ごせるよう、私たちがお手伝いします。