 |
|
日本マイクロソフト セキュリティ レスポンス チーム セキュリティ プログラム マネージャー |
前回説明した仮想化ベースのセキュリティフレームワークである「Virtualized Based Security (VBS)」は、マルウェアや攻撃者はもちろん、Windows OSであってもアクセスできない、独立したセキュリティ領域を提供することで端末の保護を実現します。
後編では、そのフレームワークを利用して重要な資格情報を守る「Credential Guard」と、改ざんを検知して深刻なコード実行を防ぐ「Device Guard」について解説します。
ローカル管理者さえ見られない資格情報「Credential Guard」
攻撃者によって端末への侵入を許したとしても、絶対に守りたいものの一つに「端末に保存されているパスワードなどの資格情報」が挙げられます。
攻撃者はマルウェアやメモリダンプツールなどを用い、OSが処理しているメモリへ直接アクセスする、あるいはダンプするなどして、端末にログインしているすべてのユーザーの資格情報や認証に必要なトークンなどを盗みます。
組織のIT管理を行うユーザーの端末には、通常端末にログインする資格情報のほかに、ファイルサーバーへログインするために利用している資格情報や、Active Directory(AD)を操作する際に利用している資格情報などが保存されているケースが多いかと思います。攻撃者は、端末へ侵入する際、それらの資格情報を盗んでファイルサーバーやADへログインし、組織への侵入拡大を試みるのです。
Windows OSは、資格情報をハッシュ化やデータ保護API(Data Protection : DPAPI)によって保護しています。しかし、攻撃者が強い権限であるローカル管理者権限を奪ってしまうと、ハッシュ化された資格情報をそのまま利用して不正にログインする「Pass the Hash」と呼ばれる攻撃や、メモリ上に展開されている情報をダンプして解析できてしまいます。
日増しに巧妙化する攻撃に対して、これまでのような「ローカル管理者権限を攻撃者に奪われないようにする」という対策では完璧ではなくなっているのが実情です。
そこで、VBSが提供する「独立したセキュリティ領域」を活用して資格情報を保護する機能が、Credential Guardです。独立したセキュリティOSで資格情報を管理するため、ローカル管理者やWindows OS自身も、内容を見ることができません。例えて言えば、「泥棒が玄関の鍵を破って侵入したとしても、備え付けの金庫にいれておいた金品には触れることができない」といったイメージです。
ただ、「独立したセキュリティOSで資格情報を管理する」と言っても「資格情報をWindows OSの外に出して保護する」というわけではありません。資格情報は、これまでと同じく通常のWindows OS上に配置されており、ローカルのセキュリティ認証サブシステム(Local Security Authority Subsystem Service : LSASS)に保存されています。
Credential Guardが異なる点は、このデータを暗号化し、暗号鍵をセキュリティ領域であるセキュアカーネルに保存することにあります。セキュアOS側のサブシステム(Isolated Local Security Authority : LSAIso)で処理するだけでなく、暗号鍵はTPM(Trusted Platform Module)による保護(TPMがない場合はUEFI[Unified Extensible Firmware Interface]による保護)も行われるため、よりセキュリティ性能が高まります。
攻撃者がローカル管理者権限を奪ってLSASSのメモリをダンプしても、資格情報が暗号化されているので読み取ることはできません。暗号鍵や処理は、Windows OSですらアクセスできない領域やTPMにあるので、解読することは事実上不可能です。
これまでは証明書の秘密鍵といった重要な資格情報を、Windows OS外の専用ハードウェア「ハードウェアセキュリティモジュール (HSM)」で管理し、Windows OSに入りこんだマルウェアから保護することが推奨されていました。Credential GuardはHSMに似たセキュリティ保護を提供する一方で、HSMのようにハードウェアを用意する必要がなく、素早い展開が可能になるメリットがあるのです。
 |
たとえOSや署名が改ざんされていたとしても実行させない
多くの企業が導入するマルウェア対策ソフトは、ブラックリストに相当するシグネチャなどを用いて怪しいバイナリを検知・排除します。一方で、信頼されたバイナリのみを実行するホワイトリストを活用して実行する機能が「Device Guard」です。
Device Guard は、バイナリのコードの整合性(Code Integrity)を検証します。あらかじめ設定された信頼できるバイナリのみを実行・許可するだけでなく、「不正なコードを埋め込まれる」といった改ざんを受けていないかも検出できます。
これまでのコードの整合性チェックは、コードに付与されている署名を確認する方法が基本でした。しかし近年の攻撃者は署名の改ざん検知を回避したり、脆弱性のあるドライバーを踏み台にして不正なコードを実行させる手法を編み出しています。
Device Guardの場合、整合性チェックを独立性の高いセキュアカーネルに移すことで、アプリケーションやドライバー、Windows OS自体の整合性チェックを行います。つまり、ドライバーなどのファイル自体が改ざんされているかだけでなく、整合性をチェックするための機能やホワイトリスト自体に改ざんが加えられていないかも、検出できるようになっています。
そのため、カーネルモードで動くバイナリに対する機能「カーネルモードのコードの整合性(Kernel Mode Code Integrity:KMCI)」と、アプリケーションなどのユーザーモードで動くバイナリに対する機能「ユーザーモードのコードの整合性(User Mode Code Integrity:UMCI)」が設けられています。
KMCIは機能を有効にすると、カーネルにバイナリがロードされる際にコード整合性チェックが行われ、「問題なし」と確認されて初めて実行可能となります。一方のUMCIは信頼できるアプリケーションのカタログをあらかじめ作成してから署名し、ポリシーとして展開しておく必要があります。展開後、アプリケーションの実行時にコードの整合性をチェックして検証できない場合は実行不可となり、ログがイベントに記録されます(実行可能にしてログのみ記録する「監査モード」も用意されています)。
Applockerや従来のコードの整合性との違いは?
実行可能なプログラムのホワイトリスト化と聞くと、Windows 7以降に搭載されている「Applocker」を思い浮かべる方も多いのではないでしょうか。
Applockerは「ソフトウェアの制限ポリシー」が進化したもので、「ファイルのパス」や「ハッシュ」「デジタル署名の発行元」などをあらかじめホワイトリスト化して、「ユーザーが実行できるアプリケーションを制限する」という目的があります。わかりやすい例では、IT管理者が組織内のユーザーに対して「業務に関係ないチャットソフトの利用を制限する」「情報漏えいを防ぐためにファイル共有ソフトの起動を禁止する」などの利用法があります。
これらのケースでは、最新のサイバーセキュリティ対策としての機能を持ちあわせておらず、不正なコードが埋め込まれていてもファイルハッシュが変わらない偽装アプリケーションの実行を防ぐことはできません。また、信頼できるアプリケーションの一覧リストは、同じWindows上に保存されているため、管理者や特権ユーザーアカウントがあれば改ざんできてしまいます。
これらの問題に対して登場した機能がDevice Guardとなるわけです。
まとめ
これまでのWindows OSでは「カーネル」「特権」「ローカル管理者」が、システムや重要なデータを保護するための”砦”としての役割を担ってきました。しかし、昨今の巧妙な攻撃はユーザーモードで動くマルウェアだけでなく、ドライバーや脆弱性を悪用して管理者権限を奪い、カーネルへ侵入します。いわば、端末におけるセキュリティは「カーネルを取られたら終わり」「管理者権限取られたら終わり」という状況に変化しているのです。
そこで登場したVBSは、Windows OSやローカル管理者が侵害されることを前提としたセキュリティ対策を実現しています。仮にローカル管理者や特権が侵害されたとしても、重要な資格情報を守るCredential Guardと、より深刻な不正コードの実行を防ぐDevice Guardによって深刻な被害から保護し、端末を踏み台にした組織への侵入を防ぎます。
企業・組織に対する標的型攻撃では、いわゆるゼロデイ脆弱性や未知の手法など、より巧妙な攻撃を仕掛けてきます。また、攻撃者の最終的なゴールは「端末への侵入」ではなく、端末を踏み台にして組織へ侵入し「情報を盗む」ことです。
VBSとCredential Guard、Device Guardは、針の穴に糸を通すような攻撃を防ぐために新しく設計されました。基本となる「セキュリティ更新プログラムの適用」などの対策に加えて、これらの機能を使いこなすことで、多層防御を構築してください。より深い端末への侵入を防ぐことは、「組織全体を守る」というセキュリティ対策にも繋がるのです。
