JFrog OSS
ユビキタスなApache Log4jパッケージにLog4Shellが発見されたことは,その【中文】★★★★★★★★★★Log4Shellへの攻撃は,脆弱性が公表されてから数日のうちに100年万回以上検出されており,その影響が完全に把握できるまでは数年かかると思われます。
このような極端な状況から一般的な教訓を得ることは困難ですが,既存のソフトウェア開発,テスト,リリースの方法論を評価し,同じような状況を防ぐために今後何をすべきかを検討する機会を与えてくれています。
また,Log4jの脆弱性は,こうした大きな脆弱性が公表されたときに開発者が直面する課題を熟慮し,どのようなツールを使えばより迅速かつ容易に状況に対処できるかを検討する機会にもなります。状況を改善するために必要な適切なツールを選択するには,実際の問題をしっかりと理解することが重要です。場合によっては,複雑な汎用ツールよりも,タスクに特化したシンプルなツールの方が効果的なこともあります。
cve - 2021 - 44228が公表された後,JFrogのセキュリティリサーチチームは,開発者コミュニティをどのようにサポートすべきかを適切に判断するために,この脆弱性を徹底的に調査する作業にすぐに取り掛かりました。Log4Shellの発表に加えて,開発者がソースコードとバイナリの両方でLog4jの使用状況とリスクを検出するために,専用のLog4j★★★★★★★★★このツールは様々なオプションがあり,開発者がそれぞれのタスクに合わせて容易に使用することができます。
このブログでは,Log4jスキャンツールを作成する際に必要であった思考プロセスと考慮事項を紹介します。
。。つまり,実行中のサービスに脆弱性が存在するかどうかをテストしようとしたり,なかにはLog4Shellを利用してパッチを当てようとするものもありました。私たちは2つの理由から,パッシブな方法によるソース及びバイナリのスキャンツールがベストであると判断しました。
- 稼働中のシステム上でエクスプロイトを実施することは,少なからずリスクを伴うアクションであり,ほとんどの開発者やセキュリティ実務者は望まないでしょう
- アクティブなLog4jスキャンツールは,ユーザアクセス可能なインターフェースと潜在的に脆弱なロギングAPI間のデータパスを分析することなく,インターフェースから入力を行い,その結果を見ることで,Log4Shellのトリガー有無を判断します。したがって,脆弱性を誘発すると予測したすべての試みが失敗した場合には,たとえ他の入力に対して脆弱であったとしても,アプリケーションは安全であるという誤った結論に達する可能性があります
次に決定したことは,パッケージのスキャン方法は,ビルドの依存関係に頼るべきではないということでした。ビルド依存関係を調査するというアプローチは確かに有効なのですが,Log4jの脆弱性の含まれ方からすると,依存関係調査では脆弱性を包括的に検出できないと考えたからです。パッケージマネージャーを経由していないか,あるいはそれ以外の理由で,脆弱なコードが直接含まれ,ビルド依存性定義が十分でないケースがあるからです。
最終的には2つの主要なタスクに焦点を当てました。
- 特定のファイル名やメタデータではなく,log4j-core由来の脆弱なコードが含まれているかどうかを判断するためにコードクラスを使用する。このツールは,ファイル名,ビルド情報や脆弱性パッケージ・データベースの完全性について何も想定していないので,”実行中のコードにLog4jが含まれているか”という問いに対する無条件の答えを出すのに役立ちます。
- 。こうしたツールは開発者が自分のアプリケーションでLog4jがどのように使用されているかを把握するのに役立ちます。これはソフトウェアに積極的にパッチを適用することを犠牲にしてまで最初にすべきことではないでしょう。しかし,スキャンツールによって,フィルタリングされていないユーザ制御の入力がLog4jのAPIコールに到達しうるかどうかを開発者が迅速に評価し,パッチの前にソフトウェアが実際に脆弱であったかどうかを結論付けることが可能になりますし,検証の追加レイヤーとしても使用できます。
。これで,絶えず開発者が設定や緩和策を検証してLog4Shellエクスプロイトに対してどこが脆弱かを素早く理解できるようになります。
推特@jfrog。!
:
Log4shellゼロデイ:知っておくべきことーブログ
Log4j Log4Shell漏洞解释ーウェビナー
Log4j Log4Shellーブログ
