Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARMFFRI, Inc.
In 2017, Microsoft announced the ARM version of Windows. The number of devices with ARM version of Windows is increasing, such as Surface Pro X series and HP ENVY x2, and it is gradually becoming popular.
When using these ARM devices, there is a compatibility issue that existing x86/x64 applications cannot be used.
However, this problem has been addressed by providing x86/x64 emulation capabilities. In recent years, ARM64EC has been announced, allowing for the gradual migration of x64 applications to ARM. The aggressive introduction of these compatibility technologies is a sign of Microsoft's strong will to promote the ARM version of Windows.
On the other hand, doesn't the introduction of new compatibility technologies provide a new avenue of attack for attackers? As far as we know, this point has not even been discussed much at this point. Therefore, we reverse engineered the compatibility technology that exists in Windows on ARM and examined its exploitability.
We found that various techniques are available, such as code injection by modifying XTA cache files, and obfuscation by exploiting newly introduced relocation entries. All of these techniques have in common the characteristic that the binary "appearance" and runtime behavior are different, making them difficult to detect and track. In addition, some of the techniques can be widely exploited to interfere with static analysis or sandbox analysis. Therefore, there is a high possibility that they will become a threat to the ARM version of Windows in the future.
In this presentation, we will explain the details of our new method and its features with demonstrations. We hope that this presentation will be a good opportunity to develop and promote the security research of Windows on ARM.
The PoC code and detailed reverse engineering results will be available on GitHub.
ZynqMPのブートとパワーマネージメント : (ZynqMP Boot and Power Management)Mr. Vengineer
2016年2月20日(金)のZynq Ultrasclae+ MPSoC 勉強会で使った資料です。
追記) 2016.05.08
公式ARM Trusted Firmwareのサイトに、Zynq UltraScale+ MPSoCの実装が追加されていていることを明記した
This is the material I used at Zynq Ultrasclae + MPSoC SIG on 20th February (Friday).
Addendum) 2016.05.08
We stated that the implementation of Zynq UltraScale + MPSoC was added to the official ARM Trusted Firmware site.
sosp2011 socc2011 plos2011 Report
23rd ACM Symposium on Operating Systems Principles (SOSP)October 23-26, 2011, Cascais, Portugal
http://sosp2011.gsd.inesc-id.pt/
2nd ACM Symposium on Cloud Computing October 26-28, 2011, Cascais, Portugal
http://socc2011.gsd.inesc-id.pt/
6th Workshop on Programming Languages and Operating Systems, October 23, 2011, Cascais, Portugal
http://plosworkshop.org/2011/
Appearances are deceiving: Novel offensive techniques in Windows 10/11 on ARMFFRI, Inc.
In 2017, Microsoft announced the ARM version of Windows. The number of devices with ARM version of Windows is increasing, such as Surface Pro X series and HP ENVY x2, and it is gradually becoming popular.
When using these ARM devices, there is a compatibility issue that existing x86/x64 applications cannot be used.
However, this problem has been addressed by providing x86/x64 emulation capabilities. In recent years, ARM64EC has been announced, allowing for the gradual migration of x64 applications to ARM. The aggressive introduction of these compatibility technologies is a sign of Microsoft's strong will to promote the ARM version of Windows.
On the other hand, doesn't the introduction of new compatibility technologies provide a new avenue of attack for attackers? As far as we know, this point has not even been discussed much at this point. Therefore, we reverse engineered the compatibility technology that exists in Windows on ARM and examined its exploitability.
We found that various techniques are available, such as code injection by modifying XTA cache files, and obfuscation by exploiting newly introduced relocation entries. All of these techniques have in common the characteristic that the binary "appearance" and runtime behavior are different, making them difficult to detect and track. In addition, some of the techniques can be widely exploited to interfere with static analysis or sandbox analysis. Therefore, there is a high possibility that they will become a threat to the ARM version of Windows in the future.
In this presentation, we will explain the details of our new method and its features with demonstrations. We hope that this presentation will be a good opportunity to develop and promote the security research of Windows on ARM.
The PoC code and detailed reverse engineering results will be available on GitHub.
ZynqMPのブートとパワーマネージメント : (ZynqMP Boot and Power Management)Mr. Vengineer
2016年2月20日(金)のZynq Ultrasclae+ MPSoC 勉強会で使った資料です。
追記) 2016.05.08
公式ARM Trusted Firmwareのサイトに、Zynq UltraScale+ MPSoCの実装が追加されていていることを明記した
This is the material I used at Zynq Ultrasclae + MPSoC SIG on 20th February (Friday).
Addendum) 2016.05.08
We stated that the implementation of Zynq UltraScale + MPSoC was added to the official ARM Trusted Firmware site.
sosp2011 socc2011 plos2011 Report
23rd ACM Symposium on Operating Systems Principles (SOSP)October 23-26, 2011, Cascais, Portugal
http://sosp2011.gsd.inesc-id.pt/
2nd ACM Symposium on Cloud Computing October 26-28, 2011, Cascais, Portugal
http://socc2011.gsd.inesc-id.pt/
6th Workshop on Programming Languages and Operating Systems, October 23, 2011, Cascais, Portugal
http://plosworkshop.org/2011/
Titie: Rethink Package Components on De-Duplication: From Logical Sharing to Physical Sharing
URL: http://events.linuxfoundation.org/2010/linuxcon-japan/suzaki
Abstract: inux distributions include many logical sharing techniques (shared library, symbolic link, etc) on memory and storage. Unfortunately they cause security and management problems, such as GOT (Global Offset Table) overwrite attack, TOCTTOU (Time Of Check To Time Of Use) attack, Dependency hell, etc. In order to mitigate the problems, we propose the replacement of logical sharing by physical sharing (memory and disk deduplication; e.g., KSM: Kernel Samepage Merging, Content Addressable Storage, etc). Original ELF binaries are transformed as self-contained binaries which include dynamic linked shared libraries as “pseudo-static”. The binaries become fat but physical resource usage is mitigated by deduplication. We have investigated the effect on Debian and Ubuntu and confirmed that the physical impact is low. Data centers of Cloud Computing utilize the deduplication techniques. Users and administrators should consider Linux images in terms of security and maintenance, and the usage of deduplicated fat binaries.
カーネル読書会での案内:クラウドコンピューティングでは仮想マシンが一つの主要な構成技術になっているが、このセキュリティ課題(I/O Fuzzing, Cross VM Side Channel Attack など)および対処について話します。日経コンピュータ 2010/03/31 の「仮想マシンに潜むセキュリティ問題」の内容を中心に議論したいと思います。
ACSAC2020 "Return-Oriented IoT" by Kuniyasu SuzakiKuniyasu Suzaki
Side of "Reboot-Oriented IoT: Life Cycle Management in Trusted Execution Environment for Disposable IoT devices" ACSAC (Annual Computer Security Applications Conference) 2020
Kernel Memory Protection by an Insertable Hypervisor which has VM Introspec...Kuniyasu Suzaki
IWSEC2014(The 9th International Workshop on Security 弘前) で"Kernel Memory Protection by an Insertable Hypervisor which has VM Introspection and Stealth Breakpoints"
USENIX OSDI 2012 Poster "Nested Virtual Machines and Proxies for Easily Implementable Rollback of Secure Communication" by Kuniyasu Suzaki, Kengo Iijima, Akira Tanaka, and Yutaka Oiwa, AIST: National Institute of Advanced Industrial Science and Technology; Etsuya Shibayama, The University of Tokyo
EuroSec2011 Slide "Memory Deduplication as a Threat to the Guest OS" by Kuniy...Kuniyasu Suzaki
EuroSec2011 (EuroSys2011 workshop) Slide of "Memory Deduplication as a Threat to the Guest OS" by Kuniyasu Suzaki
http://www.iseclab.org/eurosec-2011/program.html
1. Research Institute
for Secure Systems
Bitvisorをベースとした
既存Windowsのドライバメモリ保護
須崎 有康、八木 豊志樹、古原 和邦、
石山 智祥、村上 純一、鵜飼 裕司
(独)産業技術総合研究所 セキュアシステム研究部門
フォティーンフォティ技術研究所
2. 概要 Research Institute
for Secure Systems
• 背景
• ドライバメモリを守る理由
• ドライバメモリ保護に必要な技術
• インストール済みのOSの外部から挿入可能なハイパ
ーバイザー
• VM Introspection
• 関連研究
• 現状
• メモリの保護はStealth breakpointsを活用
• 改善計画
• まとめ
3. 背景 Research Institute
for Secure Systems
• クライアントおよびサーバ双方からの情報漏えいを防止するアク
セス制御技術の研究開発
• 総務省による戦略的情報通信研究開発推進制度(SCOPE) H23-25
• 産総研、サイエンスパーク、(FFRI)
• Windows上でアクセス制御を行うNonCopy (サイエンスパーク
社製品)を活用
• NonCopyはドライバによりファイルコピー、Screen Cut&Paste、印刷な
どを行うWindows APIを抑制する。
Internet
ネットワーク
メール添付、
利用禁止
プリンタ FTP NonCopyアーキテクチャ
印刷禁止
コピー&ペース アプリケーション
ト
デフォルトで
は閲覧のみ
オペレーティングシステム
禁止
NonCopy Driverwareコア・エンジン
NonCopyアクセス制御
ネットワーク
制御モジュール プリンタ ファイルシステム HID
LBCAS 制御モジュール 制御モジュール 制御モジュール
書き込み禁止
This is This is ライティング ネットワーク プリンタ ストレージデバイス マウス/キーボード
a pen. a pencil ソフト
ハードウェア
5. ドライバメモリ保護に
必要な技術
Research Institute
for Secure Systems
• ハイパーバイザーに必要な技術
1. インストール済みのOSに対して外部から挿入可
能なハイパーバイザー
2. VM Introspection
• 関連研究
6. Windowsドライバ保護に必要
な技術 1(デバイス管理問題) Research Institute
for Secure Systems
• 多くのハイパーバイザーは複数OSを1台のマシンで起動
するために使われている
• 例:IaaSクラウド
• 問題点
• ホストOSが必要
• 管理ソフトウェアの大規模化
• VMware ESXiは5.xよりホストOS無しになったが、管理サーバが必要
• 基本的にデバイスがホストOSの管理下になる
• VMデバイスモデルが固定
• デバイスはVM中の仮想デバイスで共有される
• プレインストールのOSとは異なる
• Xen, KVM, QEMUはQEMU Deviceモデルが標準
7. 既存のOSへの
ハイパーバイザー挿入
Research Institute
for Secure Systems
• 既存のOSが想定している物理デバイスをVM
環境内で提供する必要がある。
• VMデバイスモデルが同じにできればよい
• 各PC毎にデバイスをモデルを用意しなければならない
• VMからデバイスを直接アクセス
• I/O PassThrough。ハードウェアが限定。ハイパーバイ
ザーでも対応が必要
• Para-PassThrough。Bitvisorで提供される
8. Windowsドライバ保護に必要
な技術 2(VM Introspection) Research Institute
for Secure Systems
• ハイパーバイザーがドライバの動作、メモリ空間
を認識する必要がある。
• 守るべきドライバが組み込まれたことの認識
• Linux: create_module, init_module システムコールなど
• Windows: NtLoadDriver システムコールなど。
• 守るべきメモリ空間の認識
• 各種の実装あり。
9. VM Introspection Research Institute
for Secure Systems
• Ether [GITech Wenke Leeグループ, CCS’08]
• XenベースのVM Introspection。オープンソース。
対象OSはWindows XP SP2
• http://ether.gtisc.gatech.edu/source.html
• GreenKiller [FFRI Junichi Murakami, BlackHat’08]
• BitvisorベースのVM Introspection。対象OSは
Windows XP SP3
• Alkanet [立命館大学 大月さん、毛利先生, CSS’11]
• Bitvisorベースのシステムコールトレース。対象OS
はWindows XP SP3
10. ドライバ保護の類似研究 Research Institute
for Secure Systems
• Nooks [M.Swift, SOSP’03]
• 障害時にリカバーがメイン。
• HUKO[NDSS’11]
• 信頼できないドライバの保護。ドライバ用のメモリ空間とカ
ーネル用のメモリ空間の分離。CR3の値を変える。
• Windows7の Driver Isolation
• プリンタがメイン。
• OS2
• IA32アーキテクチャの4つのリング構造でカーネルとデバイ
スドライバを分ける。
11. ドライバメモリを保護する
ハイパーバイザー
Research Institute
for Secure Systems
• 既存OSへの挿入可能性、VM Introspectionを
考慮してGreen Killerベースで開発。
• DriverGurad と命名。
• 動作手順
• USBからハイパーバイザーを起動後、ハードディ
スクOSの起動
• ハイパーバイザーのドライバ認識
• 保護するメモリ領域の認識
• 攻撃に対する防御
• Stealth Breakpoints技術
12. 起動手順 Research Institute
for Secure Systems
• ハードディスクにインストール済みのOSに対して、起
動時にDriverGuardを挿入する
• Chain load技術
• 類似の技術にはLinuxのkexcシステムコールを使った
kbootがある。PS3Linuxで使われていた。
BIOS (USB is the first bootable device)
Go back to MBR
USB(GRUB) DriverGuard (Bitvisor)
(resides in memory)
chain loader
HardDisk(NTLDR) Windows
13. 現在の実装 1/2 Research Institute
for Secure Systems
• DriverGuardではGreenKillerによるWindows
の解析を利用
• 起動時に守るべきドライバの認識
• ドライバのIDとしてはタイムスタンプをIDとする
• ドライバはntkrnlpa.exeのLoadDriver関数を通る
ため、この関数をフック。
• フックはint 03H (0xCC)命令例に置き換えることで例外
をDriverGuardに通知。
14. 現在の実装 2/2 Research Institute
for Secure Systems
• 守るべきメモリ空間はドライバからのハイパーコール
で通知
• ドライバの改変が必要
• 現在対象のNonCopyではExAllocatePoolWithTagで
保護対象のメモリを確保していたが、他の領域で保護
対象にできる
15. 保護手順 Research Institute
for Secure Systems
② System Call “IopLoadDriver” loads a driver
Windows kernel Driver A
Hooked by DriverGard (protected
)
① Boot parameter ③ Hyper Call
tells a driver identification to protect tells a data region to protect
DriverGuard
All Code Section becomes A part of Data Section
Write-protected becomes Write-protected
Memory
Driver A Driver A
Code Data
Write Protect Read/Write Protect
16. 攻撃モデル Research Institute
for Secure Systems
• 本来のドライバ以外から攻撃を検出
• カーネル内で同じメモリ空間のドライバからの攻撃
17. メモリの保護 Research Institute
for Secure Systems
• Stealth Breakpoints [ACSAC’05]の技術の活用
• INT 03H (0xCC)に置き換えずにBreakpointの機能を実現。
メモリ内容を変えないため、攻撃者から検出され難い。
• ハイパーバイザーが守るべきメモリを管理するページテーブ
ルを空にし、アクセスが起こるたびにページフォルトを起こす
。
• ページフォルトをハイパーバイザーが捉え、正しいアクセスか
検証。問題が無ければアクセスを許す。
• 問題点
• 保護対象は4KBページ単位。
• 保護対象外でも4KBページ内のアクセスは全て検証されてしまう。
18. Stealth Breakpoints Research Institute
for Secure Systems
Process A (Normal)
CR3 Page Table Directory
0x88001000 0x88001000
0x88002000 0x88002000
Physical Memory
0x88003000 0x88003000
… … …
… … 0x41101000
0x41102000
Process B (Malicious)
0x41103000
CR3 Page Table Directory …
0x88001000 0x88001000 …
0x88002000 0x88002000
0x88003000 0x88003000 ③ Page fault which is
… … trapped by DriverGuard
… …
② Malicious Access
① Deleted by DriverGuard
after kernel set up.
19. 攻撃検出後の動作 Research Institute
for Secure Systems
• 問題を起こしたプロセスをとらえ、無限ループに
する
• Low IRQL(Interrupt ReQuest Level)で無限ルー
プのすることにより、他のプロセスは実行可能。但
し、現状ではCPUをかなり食うので他のプロセス
は遅くなる。
20. 動作例1 Research Institute
for Secure Systems
ログ表示ツールによる
Bitvisor(DriverGuard)
の動作確認
21. 動作例2 Research Institute
for Secure Systems
保護アドレスの確認
攻撃ツールのCPU
攻撃前使用量 (0%)
攻撃ツールからの保護
アドレスへの書き込み
22. 動作例3 Research Institute
for Secure Systems
保護アドレスの確認
攻撃ツールのCPU
攻撃後使用量
(98%)Low IRQLに
よる無限ループ
攻撃ツールからの保護 他のアプリも使えま
アドレスへの書き込み すが、遅くなります。
23. 現在DriverGuardの制約事項 Research Institute
for Secure Systems
• OSはWindowsXP SP3のみ
• BIOSの設定によりマルチプロセッサをDisabled(無効)とする
• OSの設定により仮想メモリ機能を無効の状態とする
• OSの設定によりPSE(Page Size Extension)を無効の状態と
する
• 保護領域のアドレス通知をすべて受け取るまでは保護領域は
守れない
• OSであるWindowsXP SP3をアップデートした場合は動作を保
証できない
24. 現状の課題 Research Institute
for Secure Systems
• ドライバのIDとしてタイムスタンプは不適切
• 実装が容易だが、改ざんされる恐れあり。
• ドライバでHyperCallする必要がある
• ドライバの改良が必要
• 警告確認がCPUの負荷の向上で判り難い
• ユーザ空間にハイパーバイザーの状態をポーリン
グする手法も考慮したが、これが改ざんされる(検
出漏れ)恐れがある
25. 改良予定 Research Institute
for Secure Systems
• ドライバの識別子としてドライバコードのSHA1とする
• ハイバーバイザーでSHA1の計算が必要
• ドライバの守るべき領域をヒープメモリとする
• ヒープメモリをハイパーバイザーが実行時に検出する必要あり
• ヒープは頻繁にアクセスされないと想定
• OSと非依存の警告
• 悪意のあるアクセスを検出した場合、OSと非依存の警告
• ハイパーバイザーがビープ音を鳴らすことやビデオドライバへ
の直接警告する
• Bitvisor 1.3で入った機能。(電通大の大山先生のADvisor)
• 現状では対象ビデオカードが限定。 Intel 945GMはちょっと古い?
26. まとめ Research Institute
for Secure Systems
• Windowsを対象としたドライバメモリの情報漏
えいを防ぐ、DriverGuardの提案
• Bitvisorベースとすることで、任意のインストール済
みOSに対して、起動時にハイパーバイザーを挿
入する
• Driverを理解するためにVM Introspection機能の
あるGreenKillerの活用
• Stealth Breakpointsによるアクセス検出