このラボの目標は、近年最も広く悪用された既知の実世界の脆弱性であるLog4Shellをトリアージすることでした。影響を受けるライブラリがエンタープライズソフトウェア全体で非常に一般的だったためです。
National Vulnerability Database (NVD) にアクセスして、CVEを調べました。
https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records
CVE-2021-44228 を検索し、結果ページを開きました。
説明を読んだ後、実際に何がリスクにさらされているのかを理解するために、いくつかの基本的な質問に答えました。
ページに記載されているCVSSスコアとベクター文字列を確認しました。
ベクター文字列を一つずつ確認して、各部分が実際に何を意味するのかを見ていきました。
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
これはベクター文字列としては最悪に近い状態です。特権が不要で、ユーザー操作も不要、ネットワーク経由で到達可能、さらに脆弱なコンポーネント自体の外部にも影響を及ぼす可能性があります（影響範囲: 変更あり）。この組み合わせが、Log4Shellが公開された際に非常に緊急かつ広範な問題として扱われた理由の一部です。
NVDページのこのCVEに関するWeakness Enumerationセクションを確認しました。
記載されていたCWEは CWE-917: 式言語ステートメントで使用される特殊要素の不適切な無力化 です。平たく言えば、ソフトウェアが入力を適切にチェックせずに式の一部として評価してしまう、つまり、攻撃者が通常のログメッセージを通じて悪意のあるJNDIルックアップを忍び込ませることができた、という意味です。
2つの異なるシナリオで、これを高リスクと見なすか低リスクと見なすかを検討しました。
シナリオ1: 脆弱なソフトウェアが稼働中で到達可能である。 高リスク。この脆弱性により、攻撃者はEL（式言語）ステートメントにアクセスして変更でき、機密性と完全性に直接影響を与えます。
シナリオ2: 脆弱なソフトウェアが電源オフで到達不能なマシンにインストールされている。 低リスク。脆弱なソフトウェアにまったく到達できない場合、攻撃者が操作する手段がないため、機密性と完全性は維持されます。
これまでトリアージしてきたCVEの中で、このCVEは、攻撃者が悪用するために必要なものが特権もユーザー操作も不要でネットワークアクセスだけであったこと、そして脆弱性がコンポーネント自体を超えたシステムに影響を及ぼす可能性があったことが際立っていました。Log4Shellが公開された際に業界全体で広範な混乱を引き起こした理由を示す良い例です。