Hu KeとNir Avrahamによる研究結果
Jamf Threat Labsは、ポストエクスプロイト（侵入後）の改ざんによりロックダウンモードが機能しているように見せかけながら、このモード本来の保護機能をすべて無効化する手法を発見しました。注意すべきは、これがロックダウンモードの欠陥でも、iOSの脆弱性でもないことです。マルウェアによってユーザにiPhoneがロックダウンモードになっていると誤認させる、ポストエクスプロイトの改ざん手法です。この手法が実際に使用された事例は報告されておらず、侵害されていないデバイスは影響を受けません。
本研究の目的は、たとえユーザがロックダウンモードを使用していても、その仕組みおよび限界を把握していなければ被害を受ける可能性があると示すことです。ロックダウンモードはiOSデバイス上の攻撃対象領域を効果的に削減できますが、デバイスが侵害されてしまった場合、もはやこのモードではマルウェアの動作を阻止できないと覚えておくことが重要です。ロックダウンモードはウィルス対策ソフトウェアではなく、既存の感染を検出することも、侵害済みのデバイス上でのスパイ行為を制止することもできません。このモードが効果を発揮するのは、攻撃を受ける前に、攻撃者に悪用されかねない侵入口を減らすことだけです。
以下に、Apple Newsroomの投稿で紹介された画像を示します。
本研究で扱うシナリオは、脆弱性のあるデバイスが攻撃者により侵害され、偽装ロックダウンモードを実装するコードが埋め込まれたというものです。重要ユーザ（ジャーナリスト、官僚、役員など）が侵害されたデバイスでロックダウンモードを開始すると、攻撃者のコードが実行され、見た目上はロックダウンモードになりますがデバイスの構成は一切変更されません。
ロックダウンモードの改ざんの有無
AppleがiOS 16で導入したロックダウンモードは、特定の状況では役立ちますが、スマートフォンが侵害されてしまうと保護効果が失われます。このブログ記事では、Jamfが偽装ロックダウンモードについて研究した結果として、攻撃者がデバイスの侵害に成功した場合、ロックダウンモードを起動しても「バイパス」されてしまう可能性があることを説明します。
ロックダウンモードの概要
ロックダウンモードは2022年9月、世界的なサイバー攻撃の急増を受けてAppleにより導入されました。GoogleのThreat Analysis Group（TAG）によれば、2021年および2022年に検出されたゼロデイ攻撃の件数は、2014年の統計開始以来最も多くなりました（下図参照）。中でも、特に知名度の高いスパイウェアであるPegasusは、ユーザが操作を行わなくても最新のiPhoneを侵害可能です（通称「ゼロクリック攻撃」）。ここ数年にわたってAppleはセキュリティアーキテクチャの強化に努めているものの、Pegasusを利用する攻撃者はその強化を上回り、新たな脆弱性を見つけてゼロクリック攻撃を実行できることが確認されています。こうした状況の中でユーザの懸念が高まったことを受け、増加傾向にある脅威への対策手段として、iPhoneユーザに安心を提供する手段としてロックダウンモードが開発されました。
ロックダウンモードの仕組みは、攻撃者のリモートアクセスを受けかねない機能を最小限に抑えるというものです。公開するコードを減らすほど、攻撃者に脆弱性を利用されるコードを減らせるので、この手法は簡単なようで堅牢性に優れています。Appleによるロックダウンモードの説明は以下のとおりです。
ロックダウンモードは、その立場や活動内容から、きわめて先鋭化されたデジタル脅威の標的になる可能性のあるごく一部の個人を対象に考案された、任意で使える究極のセキュリティ対策です。ほとんどの人は、この類の攻撃の標的になる心配はありません。
ロックダウンモードになると、デバイスが通常通りには機能しなくなります。金銭目的の高度な標的型スパイウェアに悪用されるおそれのある攻撃対象領域を極力減らすため、一部のアプリ、Web サイト、機能はセキュリティ面から厳しく制限され、場合によってはまったく使用できなくなります。
ロックダウンモードは、iOS 16以降、iPadOS 16以降、watchOS 10以降、macOS Ventura以降で利用できます。iOS 17、iPadOS 17、watchOS 10、macOS Sonoma以降では、対策が追加されています。すべての対策を講じられるように、ロックダウンモードを有効にする前に、デバイスを最新のソフトウェアにアップデートしておいてください。
例えば、ロックダウンモードでは、キャプティブポータル用に制限付きのWeb ブラウザを採用しています。キャプティブポータルとは、公共のWi-Fi ネットワークへの接続時によくポップアップ表示されるWeb ページで、主に広告や認証目的で使用されています。キャプティブポータルのWebエンジンには通常よりも多くの制限が導入されており、特に有名なものとしては、セキュリティ上の問題からJavaScriptのJIT（Just-In-Time）コンパイルを無効化するものがあります。この制限は、ロックダウンモード自体にも及びます。その結果、ロックダウンモードを使用すると、JavaScriptエンジンを採用しているWebアプリケーションのパフォーマンスおよび応答性が最大で95％低下することがわかっています。
また、ロックダウンモードをオンにすると、主としてこれまでに悪用されているかどうかに基づいて、特定のファイル形式のサポートが削除されます。さらに、便利な機能も無効化されます。例えば、メッセージアプリで送信されたリンクのプレビューを表示できなくなり、共有アルバムを使用できなくなり、構成プロファイルをインストールできなくなり、モバイルデバイス管理（MDM）ソフトウェアへの登録も行えなくなります。
下図に、ロックダウンモードで無効化される機能の一覧を示します（出典：GitHubのblacktop）。
時を進めて2023年。この頃には、ロックダウンモードの有効性は明白なものとなっていました。しかし同年9月、CitizenLabの調査により、BLASTPASSというゼロクリックエクスプロイトが活発に利用され、当時の最新バージョンであるiOS 16が標的とされていることが判明しました。CitizenLabおよびAppleはどちらも、ロックダウンモードをオンにすることでこの攻撃を阻止できると断言しました。悪用防止のために詳細は公開されなかったものの、ロックダウンモードがオンになっている間にこのエクスプロイトを実行する場合、ユーザにある程度の操作が求められるものと考えられます。これにより、ゼロクリック攻撃を無効化し、ユーザが対処する機会を確保するわけです。
ロックダウンモードの限界
ロックダウンモードは特定のシナリオで効果を発揮することが確認されているものの、Jamfがこのモードを評価した結果、デバイス上で既に開始されている攻撃は阻止できないとわかりました。そのためiPhoneユーザは、マルウェアに侵害されていないか注意する必要があります。システムがトロイの木馬に侵害されている場合、ロックダウンモードをオンにしても効果がないからです。ロックダウンモードの主目的は潜在的な攻撃ベクトルを制限することであり、セキュリティ対策を強化し悪意あるペイロードの実行を防ぐことではありません。
以降は、iPhoneが侵害されたという想定で、ロックダウンモードの改ざんによりユーザにセキュリティ状態を誤認させる手法について解説します。
スイッチ
研究では、まず設定アプリの［ロックダウンモード］トグルを調査しました（下図）。設定変更後にバックグラウンドで行われる処理は、再起動を除き、ほとんどユーザに示されません。dyldcacheで「lockdownMode」という文字列を検索した結果、PrivacySettingsUIというフレームワーク内に以下の2つのC言語関数が実装されていることがわかりました。
bool isLockdownModeEnabled()
void setLockdownModeEnabled(bool)
void setLockdownModeEnabled(bool)関数では、NSUserDefaults API経由でLDMGlobalEnabledキーのブーリアン値が「Yes」に設定されます。ファイルイベントを監視し、このファイルのパスが「/var/mobile/Library/Preferences/.GlobalPreferences.plist」であると突き止めました。
ロックダウンモードがオンかどうかをシステムで判定する際には、この1つの値だけが主要インジケータとなっていました。そこで、以下のようなコマンドを使用し、ユーザのデフォルト値のデータベースを手動で上書きし、この値を「Yes」に設定しました。
[[NSUserDefaults standardUserDefaults] setObject: [NSNumber numberWithBool: 1] forKey:@"LDMGlobalEnabled" inDomain: @"NSGlobalDomain"]
このコマンドは、サンドボックス外のほぼあらゆるプロセスで実行可能です。変更結果は膨大な関数の返り値の中に示されており、dyldcacheで「grep -i lockdownMode」を実行して目的の関数を検索できます。
PUILockdownModeControllerなどの一部関数では、初期化メソッド中にファイル読み取りが行われるため、新規インスタンスの初期化が必要です。それにもかかわらず、これらプロセスを再起動すると正常な結果が返され、デバイス全体でロックダウンモードがオンになります。さらに、この調整はデバイス全体を再起動しなくても反映されます。
Jamfは、iOS 16.5の時点においてロックダウンモードがユーザ空間のアーチファクトとして機能している（カーネルには認識されていない）と推測していましたが、この結果はこれを裏付けるものでした。また、iOS 16.5カーネル内にロックダウンモードに関連するコード実装は確認されませんでした。この段階において、ロックダウンモードのオン/オフを切り替えるためにシステムを再起動する必要はまったくありません。
しかし、この仕様は当面だけのものです。blacktopの「Anatomy of Lockdown Mode」で判明した情報によれば、AppleはiOS 17よりロックダウンモードをカーネルレベルに昇格させています。また、専用のバックグラウンドデーモンが「/System/Library/PrivateFrameworks/LockdownMode.framework/lockdownmoded」に導入され、com.apple.driver.AppleLockdownModeというKEXTも追加されています。既存のセキュリティ軽減策の効果で、カーネル内のロックダウンモードにより実行された変更はシステムを再起動しない限り取り消すことができないため、この変更はセキュリティ強化に向けた大きな一歩と言えます。
再起動の偽装
ロックダウンモードの改ざんに話を戻しましょう。この研究での設定アプリに関する目的は、ロックダウンモードを無効化し、システムの再起動をユーザ空間の再起動に置き換えることです。このデモは、マルウェアがユーザを騙す方法を示すことを目的としています。スマートフォンが侵害された場合、ユーザがロックダウンモードをオンにしているかどうかによらず、バックグラウンドでのマルウェアの実行を止める安全策はありません。
ユーザが設定アプリでロックダウンモードをオンにすると、-[PUILockdownModeController setLockdownModeGloballyEnabled:]メソッドが実行されます。この内部を見ると、一連のイベントを通じて、ロックダウンモードの動作の概要がはっきりとわかります。まず、共有アルバムとリンクのプレビューが無効化され、次に開発者モードが無効化されて、その後USB制限モードが有効化されます。さらにプロファイルのインストールが無効化され、ユーザのデフォルト値データベースのLDMGlobalEnabledキーが「YES」に設定されて、変更が同期されます。_DaemonReady関数の中で、CFNotificationCenterPostNotification()が呼び出され、構成の変更がWebKitプロセスに通知されます。最後に、デバイスが再起動されます。
-[PUILockdownModeController setLockdownModeGloballyEnabled:]がObjective-Cのメソッドであれば、method_exchangeImplementationsによるメソッドフッキングで中身を変更できます。そこで、研究では単純な手法を試しました。ロックダウンモードがユーザによりオンにされたら、/fakelockdownmode_onファイルをインジケータとして作成し、ユーザ空間の再起動を開始させるのです。また、-[PUILockdownModeController lockdownModeEnabled]などの他の関数もフッキングで改ざんし、このファイルの有無に応じて返される結果が変わるようにしました。
これにより、デバイスが再起動されなくなり、注入したコードでロックダウンモードを柔軟に制御できるようになりました。これは同時に、常駐機能のないマルウェアであっても実行を維持し、ユーザを監視できるということです。
Safariでの偽装ロックダウンモード
ロックダウンモードの改ざん結果の実例をさらに示すため、特に使用頻度の高いアプリケーションであるSafariを標的に選びました。ユーザがSafariでWeb サイトを閲覧すると、「Lockdown Enabled（ロックダウンが有効）」というラベルがはっきりと表示されます。このラベルは、現在のWeb ページがキャプティブポータルバージョンのWeb エンジンでレンダリングされていることを示すインジケータです。なんらかの理由で通常のWeb エンジンを使用する場合、Safariでは赤く目立つフォントではっきりと「Lockdown Off（ロックダウンが無効）」と表示されます。このようなシナリオとしては、Web サイトの設定でWeb サイトを信頼するように設定してから、そのサイトを閲覧する場合が該当します。
Safariでのロックダウンモード状態の判別は、+[WBSUIFeatureAvailability isLockdownModeEnabledForSafari]という関数のみで行われています。この関数をフッキングすると、別のシナリオで返される結果を改ざんできました。例えば、キャプティブポータルのWeb エンジンを使用するか判断するときには関数に「No」と返させ、表面レベルの要素（ユーザインターフェイスの「Lockdown Ready（ロックダウン準備完了）」ラベルなど）の外観を決定するときには「Yes」と返させることができました。
これにより、SafariはすべてのWeb サイトが信頼済みとして動作するようになりました。残る作業は、「Lockdown Off（ロックダウンが無効）」ラベルの改ざんです。この目的のため、まず「Lockdown Off」という文字列を検索して、WBSAnnotationStringForLockdownModeStatusという関数を特定しました。この関数のバックトレースを監視した結果、-[SFLockdownStatusBar _updateLabelWithLockdownStatus:]というObjective-Cメソッドで呼び出されており、このメソッドは都合よくフッキングできることがわかりました。そして、この関数を変更し、通常であれば「Lockdown Off」と表示すべきときに「Lockdown Enabled」と表示させるように改ざんできました。
デモ動画
以下に示すデモ動画では、まずユーザが設定でロックダウンモードをオンにします。デバイスの見た目はロックダウンモードになりますが、実際にところこのモードはオンになっておらず、SafariでPDFファイルを閲覧できます。このデモでは、crypt.eeにより開発されたサイトを利用し、技術的手段でロックダウンモードのステータスを検証できることも示しています。
Jamfブログの購読
市場トレンドやAppleの最新情報、Jamfのニュースなどをお届けします。
当社がお客様の情報をどのように収集、利用、移転、および保存するかに関しては、プライバシーポリシーをご参照ください。