年末が近づき、多くの方がお休みを待ち遠しく感じているなか、Log4jの脆弱性が明らかになり、システムを悪用しようとする者から世界中のIT管理者に不要なガラクタが一足早いプレゼントとして贈られているようです。この脆弱性により、数多くのソフトウェアアプリケーションやサービスで広く利用されているコンポーネントに影響が出ています。特定の企業に限ったことではなく、おびただしい数の製品が影響を受ける可能性があります。ベンダーは、ネットワーク機器、サーバ管理ソフトウェア、コンシューマ向け、および企業向けアプリケーションなどさまざまな分野で、今回脆弱性が露呈したソフトウェアにパッチを至急適用し修正する必要があります。
Jamfは本ブログで、この重大な脆弱性、およびこれに伴う影響について基本的なところから解説し、これらの脆弱性を軽減するため、セキュリティ対策のベストプラクティスから導き出された実践的な知識によるガイダンスを提供します。
- Log4jとは何か、そして、Log4jが大問題となっている理由とは
- 脆弱性の影響を受けるJamf製品と、Jamfはいかに脆弱性を緩和するか
- Jamf製品がいかにして、この脅威を軽減するために役立つかについて
1. Log4jとは何か
Log4jは、高いシェアを持つJavaベースのロギングライブラリであり、今回明らかになったのは、ログの偽装によるRCE(リモートコード実行/Remote Code Execution)攻撃を可能にするという深刻な脆弱性です。CVE ID番号にCVE-2021-44228が割り振られたこの脆弱性は、Javaアプリケーション実行中の情報を記録する用途でさまざまなアプリケーションで使用されているApacheソフトウェアのライブラリである、Log4Jの欠陥を指します。Log4jは、オープンソースや商用ソフトウェアの開発者が使用する最も一般的なライブラリの1つで多くのアプリケーションで利用されています。
2. 大問題となっている理由
Log4jはさまざまなデバイスやベンダーで広く使われ実装されているため、この深刻な脅威の影響を正確に定量化することは不可能です。RCEタイプの脆弱性は、その欠陥を悪用する脅威アクターが、影響を受けたシステム上で実行権限をわざわざ取得しなくてもコードを実行できてしまうことから、深刻度のレベルが高いことで知られています。基本的にこの種の攻撃で攻撃者は、デバイスを悪用してそのデバイスが保持するデータを不正入手します。最初に発見された脆弱性は、悪意のある者が攻撃したサーバからlog4jライブラリに任意のコードを巧みにダウンロードさせ、事実上それをアプリケーションの一部であるかのように実行するというものでした。攻撃者はlog4jライブラリを利用するサービスに認証されなくても、事実上このライブラリを使用するあらゆるアプリケーションを乗っ取ることができてしまいます。
なお、更に事態を深刻化させているのは、これだけではなく、複数の脆弱性が確認されているためです。最初に発見された脆弱性が修正された後もデフォルト以外の構成に対しては不十分であることが判明しました。これが2つ目の脆弱性(CVE-2021-45046)です。
このような脆弱性に対しては、脅威に完全に対策をしたパッチを当てるために、複数のレベルのアップデートが必要になることも珍しくありません。ただ、これがサービス乗っ取り型の攻撃ではなく、DoS攻撃なのは不幸中の幸いでした。こちらも深刻ですが、最初に発見された脆弱性よりはましです。悪意のある攻撃者が入力データを操作してDoS攻撃を仕掛けることは可能ですが、「まし」と言ったのは、2番目に確認されたこの脆弱性ではRCE攻撃ができないためです。
3. Log4jのJamf への影響
Apple、Google、Microsoftなど大多数のベンダー同様、残念ながらJamf製品にもLog4jの脆弱性の影響を受けたものがあります。CVE-2021-44228とCVE-2021-45046の脆弱性の性質、深刻度の高さ、およびサービスに影響を与える可能性を鑑み、Jamfは迅速に対応しました。JamfのCISOであるAaron Kiemeleは、Jamf Nation限定記事で、Log4jがJamfのサービスに与える影響についての最新情報と、Jamfのサービスに対するこの脅威を軽減するために現在Jamfが実施している戦略についての情報をJamfユーザに提供しています。
- Jamf Pro(オンプレミス):パッチ適用済みのリリースを提供
- Jamf Pro(クラウドベース):軽減対策済み、パッチ適用済み
- Jamf Connect:影響なし
- Jamf Now:影響なし
- Jamf Protect:影響なし
- Jamf School:影響なし
- Jamf Threat Defense:影響なし
- Jamf Data Policy:影響なし
- Jamf Private Access:影響なし
- Health Care Listener:脆弱性なし
- Jamf Infrastructure Manager:脆弱性なし
Jamfで主にセキュリティ関連のプロダクトマーケティングマネージャを務めるMatthias Wollnikは「Jamf Infrastructure Manager(JIM)は内部の運用データのみを記録し、信頼できない情報やクライアントから提供された情報は一切記録しません。そのため、攻撃者には、最近見つかった脆弱性を悪用するためのメッセージをLog4jに入力する手段がありません」と述べています。
Jamfの緩和策について
オンプレミスまたはお客様の組織でホストするJamf Proについては、log4j 2.16が組み込まれたバージョン10.34.2でこの問題は対策を完了しています。前バージョン(10.34.1)にはlog4j 2.15が組み込まれていました。 最新の情報によると、log4j 2.15でCVE-2021-45046に対する安全性を確保するには追加の設定が必要になりますので、Jamfは、バージョン10.34.2への迅速なアップデートを推奨しています。
もしお客様の組織が現時点でこの最新リリースにアップグレードできない場合は、Jamfの技術文書に記載されているように、影響を受けるシステム上のLog4jインスタンスを手動で更新し、システムに対応する設定を行うことで、回避策を実施する必要があります。この回避策の実行による、今後のアップデートへの影響はありません。
クラウドホスト型のJamf Proインスタンスについては、適切にセキュリティ制御されており、現時点で脆弱性は存在しません。しかし念のため、クラウドホスト型のお客様にもJamf Pro 10.34.2を配布しています。
4. 自衛策について
パッチの適用
Log4jの脆弱性は世界中に大きな影響を与えており、米国ではCISA(米国土安全保障省サイバーセキュリティ・インフラストラクチャセキュリティ庁)が広範にわたるApache Log4jライブラリの悪用を追跡、対応することを目的としたウェブサイトとGitHubリポジトリを作成しました。さらにCISAは、管理者やセキュリティチーム向けにエクスプロイトの検出を支援する検出ルール、Log4Shellハッシュ、さまざまなソフトウェア開発者やベンダー向けの緩和策ガイド、および北米、欧州、アジアなどのグローバル機関向け追加リソースなど、影響を受けるシステムの保護に役立つ最新情報を脆弱性ガイダンスとして随時更新しています。
「パッチは迅速かつ頻繁に」-Jamf
ソフトウェア開発者のウェブサイトから入手したパッチをLog4jの脆弱性に適用することとは別に、少なくとも、影響を受けるアプリや依存しているサービスのコンポーネントに組み込まれている可能性のある脆弱なLog4jライブラリを更新する手段を提供する回避策が必要です。
IT管理者はJamf Proを利用することで、影響を受けるアプリケーションの旧バージョンが存在するシステムを特定できるだけでなく、スマートグループを作成してそれらの情報を動的に集め、ソフトウェアデプロイ機能を使用して影響を受けるアプリケーションを必要に応じて直接アップデートしたり、パッチをリモート配布したりすることができます。
さらに、組織へのセキュリティ脅威の影響範囲を限定して、Log4jの脆弱性に起因する潜在的リスクを軽減するために管理者が実践できる、そして実践すべき、いくつかの基本的なセキュリティ手順があります。
リスクアセスメント
自分たちが所有しているものを把握して初めて、どこが脆弱なのか洗い出すことができます。第一段階は組織のインフラを構成するデバイス、アプリケーション、サービスを評価することです。インベントリを最新に保つことで、組織がどのようなリソースを所有し、そのリソースがどのように、また何のために利用されているかを正確に把握することができます。このような知識があれば管理者は、何がリスクか、および緩和策を展開する前にどの程度のリスクまで許容できるかの判断が容易になります。
ソフトウェア部品表(Software Bill of Materials)
略してSBOMと呼ばれるこの表は、ソフトウェアアプリケーションやサービスを構成する基本的なコンポーネントの構成要素を正確かつ分かりやすく記述し、組織や開発者にソフトウェアコンポーネントのインベントリを提供します。組織にとってSBOMを採用することの利点は、セキュリティチームがインハウスアプリやサードパーティ製アプリ内で特定の脆弱性にさらされている可能性のあるコンポーネントを簡単に洗い出せることです。
多層防御(Defense in depth)
複数のセキュリティ保護を重ね、システム、アプリケーション、サービスの全体的なセキュリティを強化するために、ソリューションの上にソリューションを重ねるように適用することが、リソース保護におけるセキュリティのベストプラクティスとして知られています。多層防御戦略は脆弱性を根本から解決するものではありませんが、影響を受けるアプリケーションの攻撃対象領域を制限してエクスポージャを抑えることで、脆弱性の影響から保護する手段を提供します。
Jamf Protectを利用して脆弱性を悪用する攻撃者を特定するのはこの一例です。お客様のUIに「SuspiciousJavaActivity(Javaの疑わしいアクティビティ)」という名称の新しい検知機能を追加しました。この機能はJavaで動作するcurlまたはbash -iを検出します。このコマンドによって多くの攻撃者がLog4jの脆弱性を悪用しています。これが検出されると、Log4jの悪用が発生したサインである可能性があります。しかし、正規のJavaアプリケーションもこれらの動作を行うことがあります(まれなことと想定していますが)。問題となっているアプリケーションにとって何が正常で、何が正常でないかを判断するのはセキュリティアナリストです。
ただし、個人所有のmacOSシステムには、攻撃者がリモートで操作する可能性のあるLog4jを利用するアクティブなアプリケーションは、あったとしてもそう多くはないはずです。アナリストは、この点を考慮して、アラートを監視する価値があるかどうかを判断することができます。
最小限の権限
最小権限の原則は、管理者がセキュリティプロセスに組み込む基本的な要素として広く認識されており、ユーザからのアクセスを生産性の維持に役立つものだけに制限します。この原則は、ホスト、アプリケーション、およびネットワークレベルに適用されます。Log4jでRCEエクスプロイトの被害を受けたシステムが接続を開始できないように、出力を制御する形でこれらすべてを強化します。このタイプのセキュリティは、脆弱性にパッチが適用されるまで、管理者が危険にさらされたシステムをロックダウンして封じ込めるのに有効です。
Webアプリケーションファイアウォール(WAF)
WAFは、Log4jの脆弱性の影響を受けるサービスやアプリと通信しようとする試みを効果的にブロックする、優れた保護ソフトウェアであることが知られています。つまり、難読化されていない文字列や、単純な回避技術が用いられている文字列は、WAFの能力で容易に阻止できるはずです。しかし、研究者が指摘しているように、脅威となる人物は、より複雑なルックアップを使用して検出を回避するためにエンコードされたキー文字列を含めて重要な文字列を偽装するためにLog4jとの通信方法をどんどん変化させてきています。セキュリティチームは、WAFのルールを進化させて、これらの難読文字列を識別してブロックし、重要なシステムを悪用しようとする試みを防ぐことに注力すべきです。
モニタリングとレポート作成
複数のセキュリティ機関が、Log4jの脆弱なシステムに対するアクティブスキャンが過去最多になっていると報告しています。さらに由々しき事に、攻撃が進化し続けるなか、脅威アクターを支援している複数の国家が存在するという見解もあります。インフラを積極的に監視し、脆弱なシステムやアプリケーションを特定するだけでなく、デバイスの健全性を評価することは、組織のセキュリティポスチャを守る上で非常に重要です。さらに管理者は「Log4Shell」エクスプロイトに関連するハッシュなど、侵害についての主要指標に関するレポートを確認することで、WAFなどの保護機能を調整して継続的なリスクを軽減するために必要な脅威情報の詳細を得ることができます。
Jamfブログの購読
市場トレンドやAppleの最新情報、Jamfのニュースなどをお届けします。
当社がお客様の情報をどのように収集、利用、移転、および保存するかに関しては、プライバシーポリシーをご参照ください。