modern techniques toconference.hitb.org/files/hitbsecconf2019ams/materials...automatic backtracking...
TRANSCRIPT
1
MODERN TECHNIQUES TO DEOBFUSCATE AND
UEFI/BIOS MALWARE
HITB 2019 AMSTERDAM
HITBSecConf2019 - Amsterdam
by Alexandre Borges
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM2
Malware and Security Researcher. Speaker at DEFCON USA 2018 Speaker at DEFCON CHINA 2019 Speaker at CONFidence Conf. 2019 Speaker at BSIDES 2018/2017/2016 Speaker at H2HC 2016/2015 Speaker at BHACK 2018 Consultant, Instructor and Speaker
on Malware Analysis, Memory Analysis, Digital Forensics and Rootkits.
Reviewer member of the The Journal of Digital Forensics, Security and Law.
Referee on Digital Investigation: The International Journal of Digital Forensics & Incident Response
Agenda:
Few words about anti-reversing METASM Keystone + uEmu MIASM BIOS/UEFI rootkits:
Windows Boot Process MBR / VBR / IPL / KCS ELAM / Control Integrity Secure Boot BIOS Guard / Boot Guard UEFI Protections + chipsec
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
ANTI-REVERSING
(few words)
HITB 2019 AMSTERDAM3
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 4
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Obfuscation aims to protect software of being reversed, protect intellectual property and, in our case, malicious code too.
Honestly, obfuscation does not really protect the program, but it is able to make the reverser’s life harder than usual.
Thus, at end, obfuscation buys time by enforcing reversers to spend resources and time to break a code.
We see obfuscated code every single day when analyzing droppers in VBA and PowerShell, so it might seem not to be a big deal.
However, they use very basic obfuscated techniques when they are compared to sophisticated threats.
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM5
We can use IDA Pro SDK to write plugins for:
extending the IDA Pro functionalities:
analyzing some code and data flow
automatizing the unpacking process of strange malicious files.
writing a loader to modified MBR structure.
Unfortunately, there are packers and protectors such as VMprotect, Themida, Arxan and Agile .NET that use modern obfuscation techniques, so making code reversing very complicated.
HITB 2019 AMSTERDAM 6
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Most protectors have been used with 64-bit code (and malware).
Original IAT is removed from the original code (as usually applied by any packer). However, IAT from packers like Themida keeps only one function(TlsSetValue( )).
Almost all of them provides string encryption.
They check the memory integrity.
Thus, it is not possible to dump a clean executable from the memory (using Volatility, for example) because original instructions are not decoded in the memory.
Instructions (x86/x64 code) are virtualized and transformed into virtual machine instructions (RISC instructions).
.NET protectors rename classes, methods, fields and external references.
HITB 2019 AMSTERDAM 7
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Some packers can use instruction encryption on memory as additional memory layer.
Obfuscation used by these protectors is stack based, so it makes hard to handle virtualized code statically.
Virtualized code is polymorphic, so there are many virtual machine representations referring to the same CPU instruction.
There are also lots of fake push instructions.
There are many dead and useless codes.
There is some code reordering using many unconditional jumps.
All obfuscators use code flattening.
HITB 2019 AMSTERDAM 8
int hitb(int x)“Virtualizer” (bytecodes)
vm_call_1(opcodes, x)
Fetching bytes, decoding them to instructions and dispatching to handlers
Protectors using virtual machines introduces into the obfuscated code:
A context switch component, which “transfers” registry and flag information into VM context (virtual machine). The opposite movement is done later from VM machine and native (x86/x64) context (suitable to keep within C structures during unpacking process )
This “transformation” from native register to virtualized registers can be one to one, but not always.
Inside of the virtual machine, the cycle is:
fetch instruction decode it find the pointer to instruction and lookup the associate opcode in a handler table call the target handler
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 9
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Constant unfolding: technique used by obfuscators to replace a constant by a bunch of code that produces the same resulting constant’s value.
Pattern-based obfuscation: exchanging of one instruction by a set of equivalent instructions.
Abusing inline functions.
Anti-VM techniques: prevents the malware sample to run inside a VM.
Dead (garbage) code: this technique is implemented by inserting codes whose results will be overwritten in next lines of code or, worse, they won’t be used anymore.
Code duplication: different paths coming into the same destination (used by virtualization obfuscators).
HITB 2019 AMSTERDAM 10
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Control indirection 1: call instruction update the stack pointer return skipping some junk code after the call instruction (RET x).
Control indirection 2: malware trigger an exception registered exception is called new branch of instructions.
Opaque predicate: Apparently there is an evaluation (jz / jnz) to take a branch or another one, but the result is always evaluated to true (or false), which means an unconditional jump. Thus, there is a dead branch. Usually, a series of arithmetic / logic tricks are used.
Anti-debugging: its used as an irritating technique to slow the process analysis.
Polymorphism: it is produced by using self-modification code (like shellcodes) and by using encrypting resources (similar most malware samples).
HITB 2019 AMSTERDAM 11
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Call stack manipulation: Changes the stack flow by using instruction tricks composed with the ret instruction, making the real return point hidden.
Is it possible to deobfuscate virtualized instructions? Yes, it is possible by:
using reverse recursive substitution (similar -- not equal -- to backtracking feature from Metasm).
using symbolic equation system is another good approach (again.... Metasm and MIASM!).
There are many good IDA Pro plugins such as Code Unvirtualizer, VMAttack, VMSweeper, and so on, which could be used to handle simple virtualization problems.
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
METASM + MIASM
HITB 2019 AMSTERDAM12
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 13
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
sub eax, C3add eax,ecxadd eax, C3
sub eax, C3sub eax, A3add eax,ecxadd eax, A3push edxmov edx, 62inc edxdec edxadd edx, 61add eax, edxpop edx
push ebxmov ebx, C3sub eax, ebxpop ebxsub eax, A3sub eax, 38add eax, ecxadd eax, 38add eax, A3push edxpush ecxmov ecx, 62mov edx, ecxpop ecxinc edxadd edx, 61dec edxadd eax, edxpop edx
add eax, ecx
12
3
4
How to reverse the obfuscation and, from stage 4, to return to the stage 1?
HITB 2019 AMSTERDAM 14
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
METASM works as disassembler, assembler, debugger, compiler and linker. Key features:
Written in Ruby C compiler and decompiler Automatic backtracking Live process manipulation Supports the following architecture:
Intel IA32 (16/32/64 bits) PPC MIPS
Supports the following file format:
MZ and PE/COFF ELF Mach-O Raw (shellcode)
root@kali:~/programs# git clone https://github.com/jjyg/metasm.git root@kali:~/programs# cd metasm/ root@kali:~/programs/metasm# make root@kali:~/programs/metasm# make all
Include the following line into .bashrc file to indicate the Metasm directory installation:
export RUBYLIB=$RUBYLIB:~/programs/metasm
HITB 2019 AMSTERDAM 15
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
This is our code from previous slide to be deobfuscated and backtracked.
Starts the disassembler engine and dissassemble from the first address (zero).
based on metasm.rb file and Bruce Dang code.
HITB 2019 AMSTERDAM 16
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Starts the backstrace engine and walk back in the code.
Determines which is the final instruction to walk back from there.
HITB 2019 AMSTERDAM 17
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Logs all the “backtracked” instructions.
Shows the effective instructions, which might alter the final result.
HITB 2019 AMSTERDAM 18
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 19
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM20
Great!
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM21
These are the effective instructions.
HITB 2019 AMSTERDAM 22
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Emulation is always an excellent method to solve practical reverse engineering problems and , fortunately, we have the uEmu and also could use the Keystone Engine assembler and Capstone Engine disassembler.
Keystone Engine acts an assembler engine and:
Supports x86, Mips, Arm and many other architectures. It is implemented in C/C++ and has bindings to Python, Ruby, Powershell and C#
(among other languages).
Installing Keystone:
root@kali:~/Desktop# wget https://github.com/keystone-engine/keystone/archive/0.9.1.tar.gz root@kali:~/programs# cp /root/Desktop/keystone-0.9.1.tar.gz . root@kali:~/programs# tar -zxvf keystone-0.9.1.tar.gz root@kali:~/programs/keystone-0.9.1# apt-get install cmake root@kali:~/programs/keystone-0.9.1# mkdir build ; cd build root@kali:~/programs/keystone-0.9.1/build# apt-get install time root@kali:~/programs/keystone-0.9.1/build# ../make-share.sh root@kali:~/programs/keystone-0.9.1/build# make install root@kali:~/programs/keystone-0.9.1/build# ldconfig root@kali:~/programs/keystone-0.9.1/build# tail -3 /root/.bashrc export PATH=$PATH:/root/programs/phantomjs-2.1.1-linux-x86_64/bin:/usr/local/bin/kstool export RUBYLIB=$RUBYLIB:~/programs/metasm export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
HITB 2019 AMSTERDAM 23
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
instructions from the original obsfuscated code
Creating a keystone engine
Assembling our instructions using keystone engine.
Freeing memory and closing engine.
HITB 2019 AMSTERDAM 24
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 25
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
IDA Pro confirms our disassembly task.
HITB 2019 AMSTERDAM 26
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
To install Capstone: apt-get install libcapstone3 libcapstone-dev
HITB 2019 AMSTERDAM 27
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Original code disassembled by Capstone.
HITB 2019 AMSTERDAM 28
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Download uEmu from https://github.com/alexhude/uEmu Install Unicorn: pip install unicorn. Load uEmu in IDA using ALT+F7 hot key. Right click the code and choose the uEmu sub-menu.set up before
running uEmu
This result confirms our previous conclusion.
HITB 2019 AMSTERDAM 29
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
MIASM is one of most impressive framework for reverse engineering, which is able to analyze, generate and modify several different types of programs.
MIASM supports assembling and disassembling programs from different platforms such as ARM, x86, MIPS and so on, and it is also able to emulate code by using JIT.
Therefore, MIASM is excellent to de-obfuscation.
Installing MIASM:
git clone https://github.com/serpilliere/elfesteem.git elfesteem cd elfesteem/ python setup.py build python setup.py install apt-get install clang apt-get remove libtcc-dev apt-get install llvm cd .. git clone http://repo.or.cz/tinycc.git cd tinycc/ git checkout release_0_9_26 ./configure --disable-static make make install
HITB 2019 AMSTERDAM 30
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
pip install llvmlite apt-get install z3 apt-get install python-pycparser git clone https://github.com/cea-sec/miasm.git root@kali:~/programs/miasm# python setup.py build root@kali:~/programs/miasm# python setup.py install root@kali:~/programs/miasm/test# python test_all.py apt-get install graphviz apt-get install xdot (testing MIASM) root@kali:~/programs# python
/root/programs/miasm/example/disasm/full.py -m x86_32 /root/programs/shellcode
INFO : Load binaryINFO : okINFO : import machine...INFO : okINFO : func ok 0000000000001070 (0)INFO : generate graph fileINFO : generate intervals[0x1070 0x10A2]INFO : total lines 0
(testing MIASM) xdot graph_execflow.dot
HITB 2019 AMSTERDAM 31
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 32
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Opens our file. The Container provides the byte source to the disasm engine.
Instantiates the assemble engine using the x86 32-bits architecture.
Runs the recursive transversal disassembling since beginning.
Generates a dot graph.
Set “llvm” as JIT engine to emulate and initialize the stack.
Set the virtual start address, register values and memory protection.
Adds a breakpoint at the last line of code.
Run the emulation.
HITB 2019 AMSTERDAM 33
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 34
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 35
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Our proposed code.
HITB 2019 AMSTERDAM 36
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Get the IRA converter.
Initialize and run the Symbolic Execution Engine.
HITB 2019 AMSTERDAM 37
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 38
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
BIOS/UEFI THREATS
HITB 2019 AMSTERDAM39
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 40
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Since Windows Vista, the main protection against rootkits have been the KCS (Kernel-mode Code Signing Policy) that prevents any unsigned kernel module to be loaded.
KCS forces all integrity checks on drivers started on boot (PnP/non-PnP) in x64 systems.
In a general way, rootkits could try to bypass the KCS:
disabling it by changing BCD variables to put the system in testsigning mode.
exploiting some vulnerability to modify the boot process.
using a driver with valid certificate from third party companies to attack the system.
disabling the Secure Boot, which forces BIOS to verify UEFI and system boot files.
HITB 2019 AMSTERDAM 41
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Code Integrity can be only disabled by changing BCD variables whether the Secure Boot is disabled.
Unfortunately, BIOS/UEFI threats attacks earlier boot stages, before KCS starts running, so KCS is not effective against bootkits.
Therefore, the malware´s goal is to attack any point before common defenses start to compromise the boot process.
Fortunately, the Code Integrity in Windows 8 and later are not controlled by only one variable (nt!g_CiEnabled) and there are several other “control variables”.
As the KCS is not able to fight against bootkits, which load before any system/kernel protection starts, so Secure Boot could help us because:
it checks the integrity of Windows boot files and UEFI components.
it checks the bootloader’s integrity.
HITB 2019 AMSTERDAM42
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
On Windows 10, the protection against the kernel and Windows boot componenents were improved through the Virtual Secure Mode.
VSM (Virtual Secure Mode) provides an isolation for the Windows kernel and critical system modules from other components by using virtualization extensions of the CPU.
Therefore, non-critical drivers are not able to disable code integrity because they run in separated containers.
As we already know, VSM is composed by:
Local Security Authority (to keep processes based on LSASS working)
Kernel Mode Code Integrity (KMCI)
Hypervisor Code Integrity
HITB 2019 AMSTERDAM 43
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Finally, we can talk about the Device Guard that is composed by:
Configurable Code Integrity (CCI): assure that only trusted code runs from the boot loader.
VSM Protected Code Integrity: represents the KMCI (Kernel Mode Code Integrity) and Hypervisor Code Integrity (HVCI) in the VSM.
Platform and UEFI Secure Boot: protects the UEFI and boot components by using digital signature.
To use the advantages and run on systems that Device Guard is active:
driver can’t load data as executable code.
driver can’t alter anything on the system memory.
allocated pages can’t be executable and writable at same time.
Likely, many malware samples don’t follow these recommendation, so they don’t work on systems that Device Guard is on.
HITB 2019 AMSTERDAM 44
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Windows offers other protection options to protect against malware such as ELAM (Early Launch Anti-Malware) to prevent malicious and unauthorized code to execute in the kernel land.
There are many interesting aspects about ELAM:
It is based on callback methods, which monitors drivers and registries.
ELAM classifies drivers in good, bad and unknown.
Its decisions are based on image’s name, hash, registry location and certificate issuer/publisher.
There are some possible values used in the ELAM policy, but the default one (PNP_INITIALIZE_BAD_CRITICAL_DRIVERS) is suitable for most sceneries because it allows to load bad critical drivers, but not bad non-critical drivers.
HITB 2019 AMSTERDAM 45
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
At winload.exe execution, ELAM can not access any binary on disk because the drivers to access the disk is not ready yet.
ELAM is excellent against rootkit, but it is not appropriate against bootkits, which usually load before winload.exe executing (Windows executable that loads ELAM).
HITB 2019 AMSTERDAM 46
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
In legacy systems, bootkits could attack:
MBR: they compromising either MBR boot code or partition table (located at 0x1be).
VBR: as VBR (Volume Boot Record) holds the information about the filesystem’s type, so the idea is to compromise BIOS parameter block (BPB) to change the IPL loading process (next stage) or even executing a malicious code.
The target field to attack is the “Hidden sectors” field, which provides the IPL location, in the BPB.
The malicious code could be loaded from a hidden and encrypted file system.
After the malicious code being execute, so the “real IPL” is loaded.
HITB 2019 AMSTERDAM 47
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
IPL: the IPL (Initial Program Loader) holds necessary bootstrap code to locate the OS loader.
Thus:
Compromising the IPL might cause the execution of a malicious code instead of loading the bootmgr module.
A malicious IPL could load a malicious kernel driver during the booting process.
Some malicious IPL codes are polymorphic. Take care.
HITB 2019 AMSTERDAM 48
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Changing the “Hidden sectors” field could cause loading a malicious code instead of executing the IPL.
BIOS_PARAMETER__BLOCK_NTFS
HITB 2019 AMSTERDAM 49
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Once the bootmgr module is loaded, so the malware’s goal is to circumvent the code integrity verification.
Furthermore, the bootmgr and windload.exe have a central responsability in perform the transition between real mode to protect mode.
Both executables are critical for bootkits because they need to keep the control of the boot process during this transition.
Once the the code integrity checking has been disabled, it is possible to replace important boot components such as kdcom.dll by a malicious one.
HITB 2019 AMSTERDAM 50
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
BIOS disk services provides several operations:
extended read (0x42)
extended write (0x43)
extended get driver parameters (0x48)
Subverting (hooking) INT 13h handle (including reading and writing operation from disk) it is one of the best way to compromise:
the bootmgr
winload.exe
the kernel.
HITB 2019 AMSTERDAM 51
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Of course, it is pretty easy to disassemble a MBR in IDA Pro:
dd.exe -v if=\\.\PHYSICALDRIVE0 of=mbr.bin bs=512 count=1 Set the offset to 0x7c00 and disassemble it as 16-bit code.
Clean MBR.
HITB 2019 AMSTERDAM 52
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Infected MBR.
HITB 2019 AMSTERDAM 53
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
C:\> "C:\Program Files (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -r Windows_7_x86-cl2-000002.vmdk -t 0 infected.vmdk
root@kali:~# qemu-img convert -f vmdk -O raw infected.vmdk infected.raw root@kali:~# dd if=infected.raw of=mbr_infected.bin bs=512 count=1 root@kali:~# file mbr_infected.bin
br_infected.bin: DOS/MBR boot sector
Install Bochs and create a bochsrc file pointing to the converted image above:
romimage: file= "C:\Program Files (x86)\Bochs-2.6.9\BIOS-bochs-latest"vgaromimage: file= "C:\Program Files (x86)\Bochs-2.6.9\VGABIOS-lgpl-latest"megs: 32ata0: enabled=1, ioaddr1=0x1f0, ioaddr2=0x3f0, irq=14ata0-master: type=disk, path="C:\VMs\infected.raw", mode=flat, cylinders=1024, heads=16, spt=63boot: diskvga: extension=vbemouse: enabled=0log: nullogprefix: %t%e%dpanic: action=fatalerror: action=reportinfo: action=reportdebug: action=ignore# display_library: win32, options="gui_debug"
HITB 2019 AMSTERDAM 54
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM 55
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Infected MBR being debugged
HITB 2019 AMSTERDAM 56
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Another way to debug and analyze a MBR using IDA Pro is also simple:
Dowload the ida.py from http://hexblog.com/ida_pro/files/mbr_bochs.zip
Copy the ida.py to your preferred folder (I’ve copied it to Bochs installation folder), edit the first lines to adapt it to your case:
# Some constantsSECTOR_SIZE = 512BOOT_START = 0x7C00BOOT_SIZE = 0x7C00 + SECTOR_SIZE * 2BOOT_END = BOOT_START + BOOT_SIZESECTOR2 = BOOT_START + SECTOR_SIZEMBRNAME = "C:\VMs\mbr_infected.bin"IMGNAME = "C:\VMs\infected.raw"
HITB 2019 AMSTERDAM 57
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
A better approach is to use a debugger instead of using an emulator.
If you are using VMware Workstation, change the .vmx configuration file from the target machine to include the following lines:
monitor.debugOnStartGuest32 = "TRUE“ / monitor.debugOnStartGuest64 = "TRUE“
Breaks on the first instruction since the power on.
debugStub.listen.guest32 = "TRUE“ / debugStub.listen.guest64 = “TRUE”
Enables guest debugging.
debugStub.hideBreakpoints = "TRUE“
Use hardware breakpoint instead of using software breakpoints.
Power on the virtual machine.
Launch the IDA Pro, go to Debugger Attach Remote GDB debugger
HITB 2019 AMSTERDAM 58
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
We’ve set Hostname as “localhost” because we starts the debugger in the same host of the VM.
The debugging port must be 8832.
After configuring the Debug application setup, click on OK button and choose “attach to the process started on target” as shown below.
HITB 2019 AMSTERDAM 59
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
After debugger starting, go to Views Open subviews Segments (or hit SHIFT+F7), right click and go to “Edit Segments”.
Change the “Segment bitness” option to 16-bit (remember: MBR run in real mode, which is 16-bit):
HITB 2019 AMSTERDAM 60
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Go to Debugger Breakpoints Add breakpoint Set the breakpoint at 0x7c00 (start of the MBR code).
HITB 2019 AMSTERDAM 61
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Continue the process (F9) and discard eventual exceptions.
HITB 2019 AMSTERDAM 62
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
BIOS MBR
EFI
VBR Bootmgr
Bootmgfw.efi
BCD
winload.exe
kdcom.dll
ELAM
ntoskrnl.exe
Code Integrity
UEFI is supported since Windows 7 SP1 x64
ci.dll
HAL.dll
Classifies modules as good, bad and unknown.
Additionally, it decides whether load a module or notaccording to the policy.
Bootkits could attack it before loading the kernel
and ELAM.
IPL
It holds the boot configuration information
The bootmgr uses the INT 13h disk service (from real mode) to access the disk service in protected mode.
Subverting INT 13h would be lethal because winload.exe use it to load its modules.
Code integrity is shared between kernel and ci.dll, but nt!CiEnable variable controls everything (Win 7 only).
HITB 2019 AMSTERDAM 63
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Compromising the MBR code makes possible to load any malicious code from anywere (even encrypted and from a hidden storage) and compromise the kernel by disabling the code integrity module, so making possible to load malicious kernel drivers (rootkits).
Remember that any malicious driver can “bypass” intermediate driver layers.
Upper-level class filter driver
Upper-level filter driver
Function Driver
Lower-level class filter driver
Low-level device filter driver
Bus Filter driver
Bus Driver
Driver development is usually done in pair, where the class driver handle general tasks, while the miniport-driver implement specific routines to the individual device.
Using the right I/O control code (IOCTL_SCSI_PASS_TRHOUGH_DIRECT), the malicious driver is able to “bypass” protections provide by programs.
Malicious driver
Kernel Filter Driver
Security Application Filter driver 3
Security Application Filter driver 2
Security Application Filter driver 1
Disk filter driver
Bus Filter Driver
IRP
IoCallDriver()
HITB 2019 AMSTERDAM 64
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Additional bootkit/rootkit techniques:
Hooking the IRP_MJ_INTERNAL_CONTROL handler from the mini-port disk driver object (DRIVER_OBJECT) to monitor/modify the data flow to disk.
Bootkits/rootkits use callback methods to be notified about important events:
PsSetLoadImageNotifyRoutine: provides notification when a process, library or kernel memory is mapped into memory.
PsSetCreateThreadNotifyRoutine: points to a routine that is called when a thread starts or ends.
IoRegisterFsRegistrationChange: provides notification when a filesystem becomes available.
HITB 2019 AMSTERDAM 65
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
IoRegisterShutdownNotification: the driver handler (IRP_MJ_SHUTDOWN) acts when the system is about going to down.
KeRegisterBugCheckCallback: helps drivers to receive a notification to clean up before the shutdown.
PsSetCreateProcessNotifyRoutine: this callback is invoked when a process starts or finishes. Usually, it is used by AVs and security programs.
CmRegisterCallback( ) or CmRegisterCallbackEx( ) functions are called by drivers to register a RegistryCallback routine. This kind of callback is invoked when threads performs operations on the registry.
Malware has been using RegistryCallback routines to check whether their persistence entries are kept and, just in case they have been removed, so the malware is able to add them back.
HITB 2019 AMSTERDAM 66
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Compromising INT 1 interruption, which is responsible for handling debugging events.
Hiding partitions/filesystems at end of the disk. Additionally, encrypting them.
Hooking key kernel modules routines such as DriverUnload( ) to prevent anyone to unload the malicious module.
Some rootkits call NtRaiseHardError( ) to force a crash and, afterwards, loading a malicious driver.
To force the BIOS reload the MBR to the memory (once it is infected or MFT is encrypted), the INT 19h is used.
HITB 2019 AMSTERDAM 67
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
UEFI has changed the bootkit’s attack profile: previously, BIOS’ industry didn’t have any standard, but UEFI established an unique one. Thus, a malware could be use to attack any platform (Write once, reuse always)
MBR + VBR + IPL are completely removed by UEFI. Additionally, UEFI support GPT format, whose signature is 0x200.
UEFI is stored in the SPI flash and most part of the UEFI code is run in protected mode.
The new bootmgfw.efi locates the winload.efi kernel loader (small changes.... )
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
HITB 2019 AMSTERDAM68
Windows 8 has introducted the necessary support to UEFI Secure Boot.
UEFI Secure Boot offers protection to boot components (OS bootloaders, UEFI DXE drivers and so on) against modification, but it doesn’t offer protection against malware infecting the firmware.
UEFI Secure Boot uses PKI to validate UEFI modules loaded from SPI.
Unfortunately, this approach doesn’t work with Terse Executable (TE) format, which doesn’t have embedded digital signature.
HITB 2019 AMSTERDAM 69
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
UEFI Secure Boot is composed by:
Platform key (PK), which establishes a trust relationship between the platform owner and the platform firmware. This platform key verifies the KEK (Key Exchange Key).
KEK establishes a trust relationship between the platform firmware and OS.
Additionally, the KEK verifies db and dbx (both in NVRAM):
Authorized Database (db): contains autorized signing certificates and digital signatures.
Forbidden Database (dbx): contains forbidden certificates and digitial signatures.
Of course, if the Platform Key is corrupted, so everything is not valid anymore because the Secure Boot turns out disabled.
HITB 2019 AMSTERDAM 70
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Another two databases that are also used by Secure Boot:
dbr: contains public key (certificates) used to validate OS recovery loader’s signatures.
dbt: contains timestamping certificates used to check an digital signature’s timestamp of UEFI executable, which prevents the usage of an expired signature in an executable.
Pay attention: the security of all components are based on the integrity of the SPI Flash.
Of course, once we could modify the SPI Flash content, so the UEFI Secure Boot could be disabled.
To help us to detect any compromise of platform firmware:
Verified Boot: checks whether the platform firmware was modified.
Measured Boot: get hashes from boot components and stores them into the TPM (Trusted Platform Module) configuration registers.
HITB 2019 AMSTERDAM 71
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
UEFI components: SEC PEI DXE BDS TSL RT AL
SEC Security (Caches, TPM and MTRR initialization)
PEI Pre EFI Initialization (chipset initialization + memory controller)
DXE Driver Execution Environment (SMM initialization + devices initialization , Dispatch Drivers, FV enumumeration)
BDS Boot Device Select (Hardware discovery + physical device enumeration)
TSL Transient System Load
RT Run Time
BDS + DXE are responsible for finding the OS loader (path indicated by UEFI variable)
HITB 2019 AMSTERDAM 72
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Before proceeding, remember about SMM basics (ring -1):
Interesting place to hide malware because is protected from OS and hypervisors.
The SMM executable code is copied into SMRAM and locked there during the initialization.
To switch to SMM, it is necessary to triger a SMI (System Management Interrupt) and save the current content into SMRAM, so the SMI handler is being executed.
SMI handlers works as interfaces between the OS and hardware.
Compromising a SMM driver, for example, makes possible to gain SMM privilege and, from this point, to disable the SPI Flash protection and modify a DXE driver. Game over.
user mode malware rootkit SMM SPI flash / BIOS
HITB 2019 AMSTERDAM 73
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
If the OS Secure Boot is disabled, the boot process can be compromised because the Patch Guard is only “running” after the boot process.
Check the KPP (Kernel Patch Protection) protected areas that are covered:
!analyze –show 109 (on WinDbg)
The UEFI Secure Boot protects and prevents attacks to modify any component component before the OS boot stage.
Who does protect the system before UEFI Secure Boot being active?
Boot Guard, which is based on cryptographic keys.
Who does protect the platform against attacks trying to compromise the flash and the entire platorm?
BIOS Guard, which protect and guarantee the integrity of the BIOS.
HITB 2019 AMSTERDAM 74
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Boot Guard is used to validate the boot process by flashing a public key associated to the BIOS signature into the FPFs (Field Programmable Fuses) within the Intel ME.
Is it a perfect solution? Unfortunately, few vendors have left these fuse unset. It could be lethal.
Additionally, a malware could alter the flash write protection and change the SPI flash.
Even using the Boot Guard to protect the boot process, we have to protect the SPI flash using the BIOS Guard to protect against a SMM driver rootkit, for example.
BIOS Guard is essential because, in the past, some malware threats already attacked the system by modifying the SMI routine of BIOS to compromise the update process.
HITB 2019 AMSTERDAM 75
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
CPU boot ROM
Boot Guard runs the Authenticated Code Module
Loaded into Authenticated Code RAM
SEC + PEI (IBB)
Verifies the IBB (Initial Boot Block)
BIOS
The ACM implements Verified and Measured Boot.
Public key’s hash, which is used to verify the signature of the code with the ACM, is hard-coded within the CPU.
Boot Guard protection makes modifying BIOS very hard if the attacker doesn’t know the private key.
At end, it works as a certificate chain checking.
IBB verifies the BIOS content
SPI Flash Memory
HITB 2019 AMSTERDAM 76
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
In this case, we have the BIOS Guard, which protects the entire platform against attacks:
SPI Flash Access, preventing an attacker to escalate privileges to SMM by altering the SPI.
BIOS update, which an attacker could update/replace the BIOS code with a bad-BIOS version through a DXE driver.
BIOS Guard forces that only trusted modules, authorized by ACM, are able to modify the flash memory.
Thus, protecting against implants.
HITB 2019 AMSTERDAM 77
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
SEC
PEI
DXE
BDS
TSL (Transient. System Load)
FLASHBoot Guard
OS Secure Boot
UEFI Secure Boot
UEFI Secure Boot
IBB
malwareand exploits attack here
Hypervisor
Windows Boot Loader
Kernel drivers
Windows
ELAM
3rd party drivers
Apps
The Windows uses the UEFI to load the Hypervisor and Secure Kernel.
Acts on driversthat are executed before Windows being loaded and initialized.
BIOS Guard
Modifying an existing DXE driver (or add a new one) could allow malicious execution at DXE stage.
It is possible to modify a UEFI DXE driver by compromising the SPI flash protection, so bypassing/disabling the UEFI Secure Boot.
HITB 2019 AMSTERDAM 78
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
https://github.com/LongSoft/UEFITool
HITB 2019 AMSTERDAM 79
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Capsule update is used update the UEFI components.
Possible place to compromise the UEFI image.
HITB 2019 AMSTERDAM 80
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Exists other SPI flash protections that are set up at DXE stage:
SMM_BWP (SMM BIOS Write Protection): protects SPI flash against writing from malware running outside of the SMM.
BLE (BIOS Lock Enable bit): protects the SPI flash against unauthorized writes. Unfortunately, it can be modified by malware with SMM privileges.
BIOSWE (BIOS Write Enable Bit): it is a kind of “control bit”, which is used to allow a BIOS update.
Protected Ranges: it is designed to protect specific regions as SPI flash, for example.
Additionally, there are six Protected Ranges registers: PR0 to PR5. No doubts, it is a good protection against changes from SMM
because its policies can’t be changed from SMM.
HITB 2019 AMSTERDAM 81
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
chipsec_util.py spi dump spihitb.bin
HITB 2019 AMSTERDAM 82
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
chipsec_util.py decode spi.bin
Remember that a BIOS update could be composed by different parts such as CPU microcode (internal firmware), Gbe (hardware network stack), BMC(Baseboard Management Controller, which provides monitoring and management), AMT (Active Management Platform, which provides remote access to devices), ME (Management engine), EC (Embedded Controller) and so on.
ME: an x86 controller that provides root-of-trust.
EC: defines which component has read/write access to other regions. It also works as security root of trust.
HITB 2019 AMSTERDAM 83
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
chipsec_main --module common.bios_wp
Unfortunately, the SMM BIOS write protection (SMM_BWP), which protects the entire BIOS area, is not enabled.
HITB 2019 AMSTERDAM84
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
chipsec_main.py -m common.spi_lock
The HSFSS.FLOCKDN bit, which comes from HSFSTS SPI MMIO Register, prevents changes to Write Protection Enable bit.
At end, a malware couldn’t disable the SPI protected ranges to enable access to SPI flash memory.
HITB 2019 AMSTERDAM 85
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
python chipsec_main.py --module common.bios_ts
BIOS Top Swap Mode allows a fault-tolerant update of BIOS boot block.
If BIOS Top Swap Mode is not locked, so malware could redirect the reset vector execution to the backup bootblock, so loading a malicious bookblock code.
HITB 2019 AMSTERDAM 86
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
python chipsec_main.py --module common.smrr
SMRR (System Management Range Registers) block the access to SMRAM (reserved by BIOS SMI handlers) while CPU is not in SMM mode, preventing it to execute SMI exploits on cache.
HITB 2019 AMSTERDAM 87
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
Few important side notes are:
Just in case the SMM code try to “read” some information from outside of SMM, so it would be interesting to check if the pointer is valid by using SmmIsBufferOutsideSmmValid( ) function.
ME (Management Engine) Applications can use the HECI (Host Embedded Communication Interface) to communicate with the kernel from Windows, for example. So ME and HECI handlers are a very critical components.
The same concern should be dedicated to AMT, which is an ME application.
The SPI flash is composed by descriptors, GbE, ME, Data, EC and BIOS, where ME has full access to the DRAM and it is always working.
Descriptors GbE MEPlatorm
DataEC BIOS
HITB 2019 AMSTERDAM 88
ALE
XA
ND
RE
BO
RG
ES
–M
ALW
AR
E A
ND
SE
CU
RIT
Y R
ES
EA
RC
HE
R
My sincere thank you to:
HITB Conference staff.
You, who have reserved some time attend my talk.
Please, you should never forget:
“ The best of this life are people.”
HTTP://WWW.BLACKSTORMSECURITY.COM89
ALE
XA
ND
RE
BO
RG
ES
–IT
IS
NO
T A
LLO
WE
D T
O
CO
PY
OR
RE
PR
OD
UC
E T
HIS
SLI
DE
.
Malware and Security Researcher. Speaker at DEFCON USA 2018 Speaker at DEFCON CHINA 2019 Speaker at CONFidence Conf. 2019 Speaker at BSIDES 2018/2017/2016 Speaker at H2HC 2016/2015 Speaker at BHACK 2018 Consultant, Instructor and Speaker
on Malware Analysis, Memory Analysis, Digital Forensics and Rootkits.
Reviewer member of the The Journal of Digital Forensics, Security and Law.
Referee on Digital Investigation: The International Journal of Digital Forensics & Incident Response
THANK YOU FOR ATTENDING MY TALK.
Twitter:
@ale_sp_brazil@blackstormsecbr
Website: http://blackstormsecurity.com
LinkedIn: http://www.linkedin.com/in/aleborges
E-mail: [email protected]