probablysecure/triage-cve-2021-44228-log4shell-log4j-目的は、既知の攻撃をトリアージし、セキュリティチームがどのように迅速に対応するかを学ぶことです。
このラボの目標は、近年最も広く悪用された実世界の脆弱性の1つであるLog4Shellという、別の有名な脆弱性をトリアージすることでした。影響を受けるライブラリがエンタープライズソフトウェア全体で非常に一般的だったためです。
私はNational Vulnerability Databaseにアクセスし、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が開示された際に緊急かつ広範囲に及ぶ問題として扱われた理由の一部です。
このCVEについて、NVDページのWeakness Enumerationセクションを確認しました。
記載されていたCWEは CWE-917：式言語ステートメントで使用される特殊要素の不適切な無害化 です。平たく言えば、ソフトウェアが入力を適切に検査せずに式の一部として評価することを意味し、そのため攻撃者は通常のログメッセージを通じて悪意のあるJNDIルックアップを忍び込ませることができました。
2つの異なるシナリオで、これを高リスクと見なすか低リスクと見なすかを検討しました。
シナリオ1：脆弱なソフトウェアが稼働中で到達可能な場合。 高リスク。この脆弱性により、攻撃者はEL（式言語）ステートメントにアクセスして変更でき、機密性と完全性に直接影響を与えます。
シナリオ2：脆弱なソフトウェアが電源オフで到達不能なマシンにインストールされている場合。 低リスク。脆弱なソフトウェアにまったく到達できない場合、攻撃者が操作する手段がないため、機密性と完全性は保たれます。
これまでトリアージしてきたCVEの中で、これは攻撃者が悪用するのに必要なものがいかに少ないか（特権なし、ユーザー操作なし、ネットワークアクセスのみ）が際立っていました。さらに、この脆弱性がコンポーネント自体を超えたシステムにも影響を及ぼす可能性があることも際立っていました。これは、Log4Shellが公表された際に業界全体がこれほどまでに慌てて対応した理由を示す良い例です。