├── GCC2022 ├── README.md ├── UEFI BIOS Security Pre-class Exercises.md └── UEFI BIOS Security.pdf ├── README.md ├── [C4]UEFI BIOSセキュリティ.pdf └── [C4]UEFI BIOSセキュリティの事前学習.md /GCC2022/README.md: -------------------------------------------------------------------------------- 1 | # Materials for the "UEFI BIOS Security" class 2 | 3 | at Global Cybersecurity Camp 2022 4 | 5 | Class abstract: https://gcc.ac/gcc_2022/lecture4/ 6 | -------------------------------------------------------------------------------- /GCC2022/UEFI BIOS Security Pre-class Exercises.md: -------------------------------------------------------------------------------- 1 | Pre-class exercises 2 | ==================== 3 | 4 | Goals 5 | ------ 6 | - Allows students to take as much time as they want 7 | - Helps students to connect with each other through group work 8 | - Strengthens the understanding of technical details through follow up lectures in the later day 9 | 10 | Non-goals 11 | ---------- 12 | - Raises students' levels for the lecture 13 | - The pre-class exercises offer an opportunity of self-guided learning for those who wish 14 | - Replacing the contents of the lecture 15 | - The amount of learning through the 4-hour long lecture only is limited 16 | - To learn and retain new information, one should spend time with hands-on exercises 17 | - Getting the right answers 18 | - The pre-class exercises are an opportunity for learning 19 | 20 | Procedures 21 | ----------- 22 | - The trainer will make groups with about 6 students 23 | - Each group discusses and decides how to work on the exercises 24 | - It is encouraged to ask questions to the trainer on Slack 25 | - All exercises are real-world cases and explained in various articles online; do the necessary research 26 | - No need to submit answers, although groups may be asked to talk about their finding, learning, or thoughts during the lecture 27 | - It is not expected to be able to answer all exercises. If you could, you probably do not need to take the lecture 28 | - Focusing on only the exercise(s) that interests you is perfectly fine 29 | - There is no ordering requirement between exercises, although software setup used in the exercise 2 may be required for other exercises 30 | 31 | Prerequisites 32 | -------------- 33 | - Host: Windows + WSL, macOS on Intel Processors, x64 Ubuntu 34 | - Virtual machine: x64 Windows or Linux is helpful for the exercise 1 but not required 35 | - Windows 10 ISO image can be [downloaded or created with the media creation tool](https://www.microsoft.com/en-us/software-download/windows10) 36 | - VMware Workstation Player, Pro, and Fusion is tested 37 | - VirtualBox and QEMU should work but are untested 38 | - Make sure to make the VM UEFI-based, as opposed to the legacy-BIOS-based. Some software uses the legacy-BIOS by default 39 | 40 | 41 | Exercise 1: Analyzing the 3rd party built UEFI module used in game cheating 42 | ============================================================================ 43 | 44 | Tags 45 | ----- 46 | Architecture (runtime drivers), UEFI driver code reading 47 | 48 | Goals 49 | ------ 50 | - Familiarize yourself with source code and build procedures of 3rd party UEFI modules 51 | - Understanding of source code is very helpful for reverse engineering exercise 52 | - Understand the impacts of the UEFI module-based hacking tools based on the threat models of both PC game security and general IT security 53 | 54 | Introduction 55 | ------------- 56 | UEFI BIOS is capable of executing modules that are built by non-original equipment manufacturer (OEM) entities. This allows, for example, the device owner to build and execute her modules from the USB thumb driver through the UEFI shell. Such modules started to be widely used in hacking communities such as game cheat developers and users due to its low technical hurdle. 57 | 58 | [CRZEFI](https://github.com/rasyidabdulhalim/CRZAIMBOT) is one of such modules designed for cheating on the online game called Apex Legends. 59 | 60 | Instructions 61 | ------------- 62 | 1. Build CRZEFI, which is the UEFI part of the project 63 | ``` 64 | $ sudo apt update 65 | $ sudo apt install gnu-efi 66 | $ git clone https://github.com/rasyidabdulhalim/CRZAIMBOT.git 67 | $ cd CRZAIMBOT/CRZEFI/ 68 | $ git checkout cd04d44a3fdfe38c83c38b96dbb14e810471f8aa 69 | $ make 70 | ... 71 | objcopy -j .text -j .sdata -j .data -j .dynamic \ 72 | -j .dynsym -j .rel -j .rela -j .reloc \ 73 | --target=efi-rtdrv-x86_64 memory.so memory.efi 74 | $ ls 75 | Makefile definitions.h dummy.h main.c main.o memory.efi memory.so 76 | ``` 77 | 2. Optionally, execute the module in a VM by following the instruction in the project 78 | 3. Explain the high-level purpose (functionality) of CRZEFI 79 | 4. Discuss impacts of similar attacks on game security. For example, why do cheat developers use UEFI modules, over kernel-mode modules? 80 | 5. Research and discuss possible countermeasures. For example, detection and/or prevention methods and their limitations if any. 81 | 6. Consider whether the same approach might be used by malware. And if so, in what attack scenarios with what limitations. 82 | 83 | 84 | Exercise 2: Reverse engineering the UEFI module used in by malware 85 | =================================================================== 86 | 87 | Tags 88 | ----- 89 | Malware 90 | 91 | Goals 92 | ------ 93 | - Familiarize yourself with UEFI modules and static reverse engineering tools 94 | - Know what the real "UEFI malware" looks like 95 | 96 | Introduction 97 | ------------- 98 | The below OS layers, particularly UEFI BIOS, have become frequent attack targets in the last few years. This is due to improved security for the above OS layers making existing layers less attractive for attackers, but also, because of greater impacts when attacking UEFI BIOS is successful. For example, an attacker may be able to achieve the following if she was able to install malware into UEFI BIOS: 99 | 1. Persisting malware that survives from OS re-installation 100 | 2. Executing code without being monitored and deleted by most of security software 101 | 3. Bypassing security features implemented by an OS and hypervisor 102 | 103 | MosaicRegressor is such a malware reported in 2020, which achieves (1) and (2) above using UEFI modules. 104 | 105 | Instructions 106 | ------------- 107 | 1. Set up a static reverse engineering environment for UEFI BIOS modules 108 | - Ghidra + efiSeek (free, Windows, some Linux?) 109 | - IDA Pro + efiXplorer (Windows, macOS, Linux) 110 | - Binary Ninja + bn-uefi-helper (untested) 111 | 2. Reverse engineer SmmInterfaceBase and SmmAccessSub. Then, verify discoveries about their implementations with the [report](https://securelist.com/mosaicregressor/98849/) 112 | - Many API's details can be found in the [EDK2 repository](https://github.com/tianocore/edk2) or the [UEFI specification](https://uefi.org/sites/default/files/resources/) 113 | 114 | Attachments 115 | ------------ 116 | 117 | | File | SHA256 | 118 | |------------------|------------------------------------------------------------------| 119 | | SmmInterfaceBase | c7c3e039700bc6072f84ff99ecb22557e460dcd2214539938a6a0ef73b9caa88 | 120 | | SmmAccessSub | b73df2299f1b61629d40e1896efdf170a6c6b44e3fd3f833fad081fcf08a3cbd | 121 | | SmmReset | 29759388b83c2141bdc224ce1ba348fe3778ffec86b2716bcd6eacc839363737 | 122 | | Ntfs | dfcdcabd576d8717dcc570a2820947e385f0e10bdb2d9a332e7a5823ea51b3ac | 123 | 124 | 125 | Exercise 3: Reverse engineering a vulnerable SMM module 126 | ======================================================== 127 | 128 | Tags 129 | ----- 130 | Architecture (Firmware File System, System Management Mode), attack surface, vulnerability 131 | 132 | Goals 133 | ------ 134 | - Learn SMM from the perspective of attack surfaces in UEFI BIOS 135 | - Understand the possible impacts of SMM vulnerabilities 136 | - Discuss the possible mitigation approaches against similar vulnerabilities 137 | 138 | Introduction 139 | ------------- 140 | Part of UEFI modules run at the processor mode called System Management Mode (SMM), which is at the higher privilege level than an OS and a hypervisor. Those modules are referred to as SMM modules, and on System Management Interrupt (SMI), their SMI handlers are executed. The SMI handlers must verify any inputs that may be manipulated by lower privileges (such as the OS) before using them, historically, the SMM developers have been failing to do this. As a result, an attacker may be able to do the following if there is a vulnerability that allows arbitrary code execution on SMM: 141 | 1. Persisting malware that survives from OS re-installation 142 | 2. Executing code that is not visible from OS, hypervisor, or any software debuggers 143 | 3. Bypassing security features implemented by an OS and hypervisor 144 | 145 | The attached file is a UEFI BIOS image containing an SMM module with such a vulnerability. This vulnerability (CVE-2021-26943) allows ring-0 code to modify contents of arbitrary physical memory locations including SMM code and data due to the lack of input validation from ring-0. 146 | 147 | Instructions 148 | ------------- 149 | 1. Find the `NvmeSmm` SMM module from the UEFI image using [UEFITool](https://github.com/LongSoft/UEFITool). Extract its `PE32 image section` into a file and confirm its SHA256 value is `A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003`. 150 | 2. Identify the handler for SMI 0x42. 151 | 3. Identify logic with incomplete input validation from the lower privilege controllable location within the SMI handler (ie, find the vulnerability). 152 | - No need of reading sub-command implementations. The problem exists before that. 153 | 4. Consider how to attack and how it could be abused (ie, what impact would be). 154 | 5. Consider how one can discover UEFI BIOS versions with the identical (vulnerable) SMM module. 155 | - Can be from the perspective of any of SMM module developers, security researchers, IT administrators in organizations 156 | 6. Consider how one can discover UEFI BIOS version with similar but new SMM vulnerable modules 157 | - Ditto 158 | 159 | Attachments 160 | ------------ 161 | 162 | | File | SHA256 | 163 | |----------------|------------------------------------------------------------------| 164 | | UX360CA-AS.303 | A2288B225C9C5B3D0FC524CB6DA9A6131EB29A8A73D1FC528F4822841FDC34B9 | 165 | | NvmeSmm | A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003 | 166 | 167 | 168 | Exercise 4: Reverse engineering Windows malware that infects UEFI BIOS 169 | ======================================================================= 170 | 171 | Tags 172 | ----- 173 | Architecture (security mechanism), attach surface, vulnerability, malware 174 | 175 | Goals 176 | ------ 177 | - Learn how UEFI BIOS is protected from unauthorized modification on the Intel platform 178 | - Understand possible impacts of the malware that infects UEFI BIOS when protection mechanisms are not properly used 179 | 180 | Introduction 181 | ------------- 182 | BIOS is stored in a storage called an SPI flash that is different from HDD and SSD, and is read and executed by the platform on power-up. BIOS is highly security-sensitive as it contains the SMM modules that run at the high privilege and implementation of security features such as Secure Boot and the use of the Trusted Platform Module (TPM). For this reason, the platform, specifically, Platform Controller Hub (PCH), also known as a chipset, implements several registers that protect the SPI flash from modification outside SMM, and UEFI BIOS code written by OEMs and BIOS vendors must configure those registers before the OS starts to properly protect the flash. However, many OEMs and BIOS vendors have failed to do this historically, and thus, there have been many cases the SPI flash was writable from the OS or a hypervisor. 183 | 184 | [Lojax](https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/) discovered in 2018 is the malware that exploits such vulnerabilities and modifies and injects malicious code into UEFI BIOS from kernel-mode. 185 | 186 | Instructions 187 | ------------- 188 | 1. Study Lojax 189 | 1. Explain functionalities of the following 3 bits by referring to the [specification of Intel 9 Series PCH](https://www.intel.com/content/www/us/en/products/docs/chipsets/9-series-chipset-pch-datasheet.html) 190 | - BIOSWE 191 | - BLE 192 | - SMM_BWP 193 | 2. Explain under what condition ReWriter_binary.exe infects the SPI flash concerning those 3 bits 194 | 2. Consider and discuss how devices with the vulnerability used by Lojax could be identified and protected 195 | 3. Consider and discuss how new malware exploiting the same vulnerabilities can be detected and prevented 196 | 197 | Attachment 198 | ----------- 199 | 200 | | File | SHA256 | 201 | |-----------------|------------------------------------------------------------------| 202 | | ReWriter_binary | fc28ad61fc748c08e8714cb247e741b736ebf0d9dfbcc3579f66fe3168326f61 | 203 | | SecDxe | 7ea33696c91761e95697549e0b0f84db2cf4033216cd16c3264b10daa31f598c | 204 | 205 | - Do NOT run ReWriter_binary on a physical machine. It is a Windows executable. 206 | -------------------------------------------------------------------------------- /GCC2022/UEFI BIOS Security.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tandasat/UEFI-BIOS-Security/ef79d9d58011d916abfdee7eba108223cd1f9785/GCC2022/UEFI BIOS Security.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 「UEFI BIOSセキュリティ」の講義および事前学習資料 2 | 3 | セキュリティキャンプ2021 4 | 5 | 講義概要：https://www.ipa.go.jp/jinzai/camp/2021/zenkoku2021_program_list.html#list_c4 6 | -------------------------------------------------------------------------------- /[C4]UEFI BIOSセキュリティ.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/tandasat/UEFI-BIOS-Security/ef79d9d58011d916abfdee7eba108223cd1f9785/[C4]UEFI BIOSセキュリティ.pdf -------------------------------------------------------------------------------- /[C4]UEFI BIOSセキュリティの事前学習.md: -------------------------------------------------------------------------------- 1 | 事前学習 2 | ======== 3 | 4 | 前提 5 | ----- 6 | - 4時間の講義で理解できる技術内容は薄い 7 | - 4時間の対話的セッションは技術内容の学習に適さないフォーマット 8 | - 4時間のセッションだけでは受講生間のネットワークの構築の助けにならない 9 | - 事"後"学習では、その後で生徒間や生徒講師間のコミュニケーションを取れない可能性が高い 10 | 11 | 事前学習の目的 12 | -------------- 13 | - 本人が望むだけ時間を取り学習できるようにする 14 | - グループワークを通して参加者間のネットワーク構築の助けとする 15 | - 4時間のセッションを、事前学習のフォローアップに充て、技術的理解をさらに深める場とする 16 | 17 | 事前学習の目標ではないこと 18 | ------------------------ 19 | - 講義に向けて全員のレベルを一定まで上げる事 20 | - 事前学習は、学習意欲と時間のある人が望むだけ学習できる題材を提供する 21 | - 講義の内容を自習で振り替える事 22 | - そもそも講義では十分な学習はできない。十分な理解を求めるのであれば事前事後学習が初めから必須 23 | - 事前学習課題に対する正答を得る事 24 | - 事前学習は自己学習の機会である 25 | 26 | 進め方 27 | ------ 28 | - 講師が3～5名程度からなるグループを作成し通知する 29 | - グループは話し合い、グループ内でどのように進めるか決めるが、最終的な成果物はグループとしてまとめる 30 | - Slack等での講師へ質問は推奨する 31 | - 題材はすべて実例のためインターネットで情報が見つかる。必要に応じて情報収集すること 32 | - 回答の提出は不要。ただし講義で、ごく簡単な説明を各グループに求める場合がある 33 | - すべての課題に回答できることは期待されてない（もしできたら、あなたはこの講義を受講する意味があまりない） 34 | - 興味のあるトピックに集中してもよい 35 | - 課題はどの順序で取り組んでもよい（ただし課題２のソフトウェアセットアップは課題３，４でも必要） 36 | - 参照されている書籍を読む必要はない（座学的な要素は講義で扱う）。主に事後学習の参考のため示した 37 | - 書籍：[Building Secure Firmware: Armoring the Foundation of the Platform](https://www.oreilly.com/library/view/building-secure-firmware/9781484261064/) 38 | 39 | 事前要件 40 | -------- 41 | - ホスト：x64 Ubuntu、またはWindows+WSL、またはmacOS（だだしmacOSでは課題１のビルドはできない） 42 | - 仮想マシン：x64 WindowsまたはLinuxの仮想マシン（課題１のみ） 43 | - Windows 10のISOは[Windows 10 のダウンロード](https://www.microsoft.com/ja-jp/software-download/windows10)から直接ダウンロード、もしくはメディア作成ツールを経由して作成できる 44 | - 英語情報を調べる気合 45 | 46 | 書籍内の関連セクション 47 | --------------------- 48 | - Introduction to Firmware (p.3) 49 | 50 | 51 | 課題１：ゲームチートに用いられるサードパーティー製UEFIモジュールの分析 52 | ================================================================= 53 | 54 | タグ 55 | ----- 56 | アーキテクチャ（Runtime Driver）、ソースコード 57 | 58 | 目標 59 | ----- 60 | - gnu-efi版サードパーティー製UEFIモジュールのソース、ビルドおよび実行手順を大まかに理解する 61 | - ソースコードの理解はリバースエンジニアリングの演習に役立つ 62 | - 一時話題を集めたUEFIベースのチート技術について、ゲームセキュリティと一般セキュリティ両方の観点から脅威モデルと影響を理解する 63 | 64 | 概要 65 | ----- 66 | UEFI BIOSはOEMが出荷するモジュール群とは別に、サードパーティー製の独立したモジュールを扱う機能がある。これにより、例えば、デバイス所有者が独自のモジュールをビルドし、USBトライブからUEFI Shellを通して実行できる。このようなモジュールは、その技術的障壁の低さや特長により、2019年頃よりハッカーコミュニティーで広く使われ始め、ゲームチートにも利用されてきた。 67 | 68 | [CRZEFI](https://github.com/rasyidabdulhalim/CRZAIMBOT)はそのようなモジュールをApex Legendsというオンラインゲームのチート用にカスタマイズしたものである。 69 | 70 | 指示 71 | ---- 72 | 1. UEFIモジュールであるCRZEFIをビルドし、手順に従い仮想マシン内で実行しなさい 73 | - VMware Fusion/Workstation Proをインストールし、x64 WindowsまたはLinuxの仮想マシンを作成する 74 | - OSのインストールを開始する前に、VMの構成がUEFIベースである事を確認する 75 | - Virtual BoxとQEMUは未テストだが使用可能なはず 76 | - 手順メモ 77 | ``` 78 | $ sudo apt update 79 | $ sudo apt install gnu-efi 80 | $ git clone https://github.com/rasyidabdulhalim/CRZAIMBOT.git 81 | $ cd CRZAIMBOT/CRZEFI/ 82 | $ git checkout cd04d44a3fdfe38c83c38b96dbb14e810471f8aa 83 | $ make 84 | ... 85 | objcopy -j .text -j .sdata -j .data -j .dynamic \ 86 | -j .dynsym -j .rel -j .rela -j .reloc \ 87 | --target=efi-rtdrv-x86_64 memory.so memory.efi 88 | $ ls 89 | Makefile definitions.h dummy.h main.c main.o memory.efi memory.so 90 | ``` 91 | その後、`How To Load Memory.efi`の手順に従い仮想マシン内で実行しなさい 92 | 2. CRZEFIの機能概要を説明しなさい 93 | 3. CRZEFIの手法がゲームセキュリティに与える影響について考察しなさい。例えば、なぜチート開発者はUEFIモジュールを使うのか考察しなさい 94 | 4. CRZEFIへの潜在的な対策方法や対策技術を調査、考察しなさい。例えば、防止方法、検出方法、それらの利点と欠点を考察しなさい 95 | 5. CRZEFIの手法がマルウェアにも用いられるか否か、用いられる場合、どのような利用（攻撃）シナリオや制限等があるか考察しなさい 96 | 97 | 98 | 課題２：マルウェアが用いるUEFIモジュールの解析 99 | =========================================== 100 | 101 | タグ 102 | ---- 103 | マルウェア 104 | 105 | 目標 106 | ----- 107 | - UEFIモジュールの静的解析ツールと方法に親しむ 108 | - 実際のUEFIマルウェアがどのようなものか知る 109 | 110 | 概要 111 | ----- 112 | ここ数年、攻撃者はOSより下のレイヤー、とりわけUEFI BIOSを狙う傾向がある。この理由には、OS以上のレイヤーのセキュリティが向上し、より攻撃しやすい対象に移行していることに加え、UEFI BIOSへの攻撃が成功した場合に攻撃者が得られるメリットが大きいという側面もある。例えば、UEFI BIOSにマルウェアコードをインストールできた場合、攻撃者は次の機能を得ることができる。 113 | 1. OS再インストール後でも維持される常駐能力 114 | 2. セキュリティソフトに監視、削除されないコード実行能力 115 | 3. OSやハイパーバイザーレベルのセキュリティを部分的にバイパスする能力 116 | 117 | MosaicRegressorは2020年に報告されたマルウェアで、UEFIモジュールを用いて上記の(1)と(2)を達成している。 118 | 119 | 指示 120 | ----- 121 | 1. UEFI BIOSモジュールの静的解析環境を構築しなさい 122 | - Ghidra + efiSeek（無料） 123 | - IDA Pro + efiXplorer（有料）または 124 | - Binary Ninja + bn-uefi-helper（有料） 125 | 2. SmmInterfaceBaseとSmmAccessSubモジュールを静的解析し、その実装を[解析情報](https://securelist.com/mosaicregressor/98849/)と比較しなさい 126 | - 多くのAPIは[EDK2レポジトリー](https://github.com/tianocore/edk2)または[UEFI仕様書](https://uefi.org/sites/default/files/resources/UEFI_Spec_2_9_2021_03_18.pdf)から見つけることができる 127 | 128 | 添付ファイル 129 | ------------ 130 | 131 | | ファイル | SHA256 | 132 | |------------------|------------------------------------------------------------------| 133 | | SmmInterfaceBase | c7c3e039700bc6072f84ff99ecb22557e460dcd2214539938a6a0ef73b9caa88 | 134 | | SmmAccessSub | b73df2299f1b61629d40e1896efdf170a6c6b44e3fd3f833fad081fcf08a3cbd | 135 | | SmmReset | 29759388b83c2141bdc224ce1ba348fe3778ffec86b2716bcd6eacc839363737 | 136 | | Ntfs | dfcdcabd576d8717dcc570a2820947e385f0e10bdb2d9a332e7a5823ea51b3ac | 137 | 138 | 139 | 課題３：脆弱なSMMモジュールの解析 140 | =============================== 141 | 142 | タグ 143 | ---- 144 | アーキテクチャ（Firmware File System, System Management Mode）、アタックサーフェイス、脆弱性 145 | 146 | 目標 147 | ----- 148 | - SMMについて、UEFI BIOSに潜むアタックサーフェイスという観点から学習する 149 | - 脆弱なUEFI BIOSのセキュリティに対する潜在的な影響度を理解する 150 | - 脆弱なUEFI BIOSの脅威を緩和する方法を議論する 151 | 152 | 概要 153 | ----- 154 | UEFI BIOSモジュール群の一部はSystem Management Mode（SMM）と呼ばれる、OSやハイパーバイザーよりも高い権限で動作する。SMMモジュールは、System Management Interrupt（SMI）を通してOSから呼び出され、対応するSMIハンドラーを実行する。SMIハンドラーは、低い権限（OS）がコントロールできるあらゆる入力について安全に検査、対応する必要があるが、SMMモジュールの開発者（OEMとBIOSベンダー）は歴史的にこれに失敗してきている。そのような場合の結果これらのモジュールにSMMでの任意コードが実行可能な脆弱性があると、攻撃者は例えば次のことができるようになる。 155 | 1. UEFI BIOSの書き換えによる、OS再インストール後でも維持される常駐 156 | 2. OS、ハイパーバイザー、デバッガー等から不可視の領域でのコード実行 157 | 3. OSやハイパーバイザーレベルのセキュリティ機能の完全なバイパス 158 | 159 | 添付のファイルは、そのような脆弱性のあるSMMモジュールを含むUEFI BIOSイメージである。本モジュールの脆弱性（CVE-2021-26943）は、高い権限（SMM）で動作するSMIハンドラーが、低い権限（Ring 0）がコントロールできる値を十分に検証せずに使用することによって、SMM権限での任意アドレスの書き換えができるというものである。 160 | 161 | 指示 162 | ----- 163 | 1. [UEFITool](https://github.com/LongSoft/UEFITool)を用い、UEFI BIOSイメージから`NvmeSmm`SMMモジュールを見つなさい。次に、その`PE32　image section`をファイルとして取り出し、SHA256の値が`A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003`であることを確認しなさい。 164 | 2. ファイルを静的解析しSMI 0x42のハンドラーを特定しなさい 165 | 3. SMIハンドラーのなかで、低い権限からの入力値の検証と対応が安全でない処理、理由を特定しなさい（ie, 脆弱性を発見し説明しなさい） 166 | - サブコマンドの実装は読む必要がない。問題個所はそれ以前のコード 167 | 4. 脆弱性の攻撃方法と悪用方法（影響）について考察しなさい 168 | 5. まったく同じ（脆弱性がある既知の）SMMモジュール使用したUEFI BIOSをどのように発見できるか考察しなさい 169 | - SMMモジュール開発者、セキュリティ研究者、組織のIT管理者、その他、いずれの視点でも良い 170 | 6. 類似の脆弱性がある（未知の）SMMモジュールをどのように発見できるか考察しなさい。 171 | - 同上 172 | 173 | 添付ファイル 174 | ------------ 175 | 176 | | ファイル | SHA256 | 177 | |----------------|------------------------------------------------------------------| 178 | | UX360CA-AS.303 | A2288B225C9C5B3D0FC524CB6DA9A6131EB29A8A73D1FC528F4822841FDC34B9 | 179 | | NvmeSmm | A9C762B13FC9C4156603D674C6DAEBC4369520D95ACB1D0FA976078D6F7F1003 | 180 | 181 | 書籍内の関連セクション 182 | --------------------- 183 | - X86 SMM (p.681) 184 | 185 | 186 | 課題４：WindowsからUEFI BIOSに感染するマルウェアの解析 187 | ==================================================== 188 | 189 | タグ 190 | ---- 191 | アーキテクチャ（セキュリティ）、アタックサーフェイス、脆弱性、マルウェア 192 | 193 | 目標 194 | ----- 195 | - Intelプラットフォームにおいて、UEFI BIOSがどのように不正な書き換えから保護されているか学習する 196 | - 保護が適切に設定されていない場合の影響を、UEFI BIOSに感染するマルウェアの解析を通して理解する 197 | 198 | 概要 199 | ----- 200 | BIOSはSPIフラッシュと呼ばれる、ハードディスクやSDDとは異なるデバイスに内容が保存されており、システムは、起動時にその内容を読み取り実行を開始する。BIOSには高い権限で実行されるSMMモジュールや、Secure Bootなどのセキュリティ機能の実装が含まれており、セキュリティ上、非常に機微である。そのためプラットフォーム（とりわけサウスブリッジ）には、SMM以外からのSPIフラッシュの書き換えを禁止できるレジスターが用意されており、OEMが出荷するUEFI BIOSコードは、OSが起動する前にそれらを有効にしてSPIフラッシュを保護する必要がある。しかしながら、歴史的に多くのOEMとBIOSベンダーがこれを行わないデバイスを出荷しており、SPIフラッシュがOSやハイパーバイザーから書き込み可能な場合がある。 201 | 202 | 2018年に発見された[Lojax](https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/)はこのような脆弱性を悪用し、カーネルモードからUEFI BIOSを書き換え、悪意のモジュールを挿入するマルウェアである。 203 | 204 | 指示 205 | ----- 206 | 1. Lojaxについて調べなさい 207 | 1. Lojaxがチェックする、BIOSの書き込み保護に関連した以下の３ビットの機能を[Intel 9 Series PCHの仕様書](https://www.intel.com/content/www/us/en/products/docs/chipsets/9-series-chipset-pch-datasheet.html)を引用しながら説明しなさい 208 | - BIOSWE 209 | - BLE 210 | - SMM_BWP 211 | 2. ReWriter_binary.exeを静的解析し、その機能を上記３ビットと関連付けて簡単に説明しなさい 212 | 2. Lojaxが悪用する脆弱性があるデバイスやUEFI BIOSをどのように発見、対処できるか考察しなさい 213 | 3. 同脆弱性を悪用するマルウェアをどのように一般化して発見、対処できるか考察しなさい 214 | 215 | 添付ファイル 216 | ------------ 217 | 218 | | ファイル | SHA256 | 219 | |-----------------|------------------------------------------------------------------| 220 | | ReWriter_binary | fc28ad61fc748c08e8714cb247e741b736ebf0d9dfbcc3579f66fe3168326f61 | 221 | | SecDxe | 7ea33696c91761e95697549e0b0f84db2cf4033216cd16c3264b10daa31f598c | 222 | 223 | - ReWriter_binaryはWindows実行可能ファイル。実機で実行しないこと。 224 | - 意図しない実行への防止策としてMZヘッダーを変更している。 225 | 226 | 書籍内の関連セクション 227 | --------------------- 228 | - BIOS Write Protection (p.745) 229 | - Race Condition Attack (p.107) 230 | - Race Condition Attack Prevention (p.698) --------------------------------------------------------------------------------