Transcript BootJacker: Compromising Computers using Forced Restarts

Outline
 Overview of Direct Access Security
 Little History of Computer Components
 Approach of BootJacker
 The Process
 Effectiveness on a Linux System
 How to Counteract
 Related Work
 Conclusion
Direct Access Security
 What prevents access to an attacker?





Screen Saver / Lock Screen Password Protection
Password Protected Login Screens
File Systems are Encrypted
Virtual Private Network Connections
Encrypted websites (SSL)
The Workings…..
 How exactly do these software measures work?
 Passwords or Keys are entered by the user at login or
resuming system state
 Trusted Platform Module (TPM) supplies the operating
system with the key
 Where do they go?
 After successful verification they are stored in the computers
volatile memory or Random Access Memory (RAM)
 Is that safe??????
Computer Components
 Computers are made up of many different parts, but lets
focus on one specific one:
 RAM
 Random Access Memory – This is where the computers
programs, processes, and other temporary information is stored.
 Continues power is needed to ensure contents are not corrupted
or erased.
 How long does the data stay active?
 In most cases the data is kept during restarts or brief power
outages
 With use of liquid nitrogen, memory can be stored up to a week!
Oh Rebooting Woes…
 So how much data is actually intact after a reboot?
 Most computer systems will overwrite sections of memory at
boot up
 Contains caching information for peripherals, i/o mappings, and
other motherboard related operations
Unleash the BootJacker
 A few things to know about BootJacker




BootJacker is a proof of concept
It will not work on Error Correcting Code (ECC) memory
Requires direct or physical access to the computer
It is Operating System dependent (Linux Kernel 2.6)
The Approach
 How does it work?
 BootJacker uses a vulnerability that volatile memory is not
completely erased when force restarted
 Using the pieces left over, BootJacker then resuscitates the
computer back to the live user session.
 This allows the attacker to have full admin rights to the
victim computer bypassing the security of the machine.
 Also allows for access to any open channels the user may of
have had open at the time of force restart
How does it really work…
 BootJacker operates like a small bootstrap environment,
at boot-up it begins to resuscitate the computer at its core
systems.
 Core Systems include both Hardware and Software
 Using what information is still provided within the volatile
memory
 BootJacker will be able to revive the machine in the state is
was before forced restart
 This is done with a little help…MALWARE!
 Terminator
 Attacks security and logging software
 Antivirus, intrusion detection tools, system logger deamons
 Allows Attacker to load tools
 RootShell -- Superuser Shell spawned by BootJacker
 Gives root access to the attacker
 Allows the attacker to implement what ever attack he or she wishes
--Resuscitation-ITS ALIVE!!!!!
 Hardware
 Interrupt Controller
 All interrupts are re-enabled
 Interrupts include system timer to keyboard.
 System Timer
 The timer needs to be exactly the same
 Otherwise this will prevent the system from resuscitating properly
 Keyboard & Mouse
 Hot-Swappable
 BootJacker sends a command to re-initialize them
Hardware Resuscitation….
 Display Monitor
 Uses standard VGA or VESA video modes
 Basic text mode to ensure compatibility
 After successful resuscitation, attacker can re-enable graphics
console
 Disk
 Relies on Linux’s error recovery routines
 Linux sends a re-initialization command to drives
 BootJacker responds after initialization is completed
 Coprocessor Unit
 BootJacker has to reset and re-initialize
 Coprocessor is disabled at system restart
 Network
 BootJacker utilizes the API’s of Linux to re-initialize the
network adaptor
 Since system restart only takes up to a minute, connections
don’t usually time out.
Software Resuscitation
 Page Tables
 BootJacker needs to discover the address of page locations
 If not, system resuscitation will fail
 Alt-SysRq-B
 Reboot method used to enable resuming of software
processes
 This helps ensure that the Stack does not become corrupt
 Allow for proper process/context reconstructing to occur
 Instructions are properly reloaded due to a call back method
caused by instructional fetch fault
 Software Interrupts
 Schedule
 Processes running before restart were on a schedule
 Schedule is attempting to run during resuscitation
 These are pushed on to a stack for future
 Using existing Linux API
 Interrupts are successfully re-enabled for all processes
 Scheduling is resumed
The Process
 How does a attacker implement this?
 Attacker needs to have direct access to the computer
 Stealing the computer
 Un-authorized access to the computer
 Removal of memory components
 Removing hard-drive & volatile memory
 Forced Restart is initialized
 Pressing of restart button on computer system
 Use of Hot-Key restarts (Alt-SysRq-B)
The Process Continued
 BootJacker is connected to the computer
 Bootable Device
 DVD / CD
 USB Flash/Hard Drive
 Network Boot
 BootJacker boots instead of host system
Process…
 BootJacker successfully revives the host operating system
 Attacker can now break the system with malware payloads
 If needed, the system can then be returned to the
unsuspecting owner
 A few hiccups…
 If the drive is inserted before force restart
 Could cause intrusion software to detect the insertion
A Few Side Notes
 Alternate booting
 Attacker may need to configure bios to boot from removable
media
 Most BIOS will boot from CD
 Most will not boot from USB
 Operating Systems Attack
 BootJacker will need to be recompiled for different kernels
 Timing
 The quicker you are the better chance you have
 Memory is volatile, could be refreshed over time (BIOS
dependant)
Effectiveness
 Test System Hardware
 IBM InteliStation M Pro




2 GHZ Intel Pentium 4
512 MB of RAM
IDE Disk Drive
Intel Pro/100 Network Card
 This configuration is optimal for Hardware Resuscitation
 Operating System
 Linux 2.6 Kernel (x86 – 32 Bit)
Time to Test…
 Test Tasks Performed
 gcc: Compilation of the C source file containing the
H.264/MPEG-4 AVC video compression codec in the MPlayer
[37] media program.
 gzip: File compression using the deflate compression
algorithm.
 wget: File download.
 convert: JPEG image encoding.
 aespipe: AES file encryption.
 During the middle each test the computer was force
restarted
 The tasks were successfully completed after resuscitation
Security Test Applications
 SSH
 Secure shell connection between two computers
 SSL
 Web browser session to a secure web server
 PPTP
 Secure connection to a secure network
 University or Business
 dm-crypt & Loop-AES
 Encrypted File Systems
Results
 SSH & SSL
 Both are stored in user space
 After successful resuscitation
 Attacker was able to access secured sessions on SSH
 Attacker was also able to view secured websites
 Email
 Online Banks
 VPN
 During the process of BootJacker
 VPN connections stay intact
Results…
 Linux File Encryption
 After successful exploitation
 Full access to encrypted drives remained
 dm-crypt
 Loop-AES
Time
 So how long does this take to do….
 Less then 60 seconds!
 In most cases it took less then 30 seconds
 In most test runs
 Most time was consumed by the BIOS boot process
How to Counteract
BootJacker
 System Reconfiguring
 Prevent the system from alternate booting
 Password protecting BIOS
 Use of ECC memory
 Requiring memory tests at each boot
 Clears out memory
 Operating System Reconfiguration
 Prevent secrets/keys from being stored in volatile memory
 Drop secure connections when screen saver / lock screen
events occur
 Encrypt memory & stop computations until user has
authenticated
Related Work
 FireWire Protocol Attack
 Access physical memory thru FireWire port
 Allows access to keys and other secret data stored in volatile
memory
 Cold Boot Attacks
 Access memory to view keys and other secret information
stored in volatile memory
 Uses a memory tool that analyses contents of volatile
memory for specific secured data
 Vbootkit & eEye BootRoot
 Install code that is executed on next boot cycle
 Place malware on the system to monitor secrets
 Does not attempt to recover information from memory or
revive the system
Conclusion
 Pros
 Easily achieve access to the system
 No need for knowledge about the user
 Bypass security algorithms within the system
 Intrusion Detection, Antivirus, Loggers
 Have access to current secure sessions
 VPN, SSH, SSL, File Encryption
 Complete processes being executed before force restart
 gcc, gzip, wget, convert, aepipe
 Achieve Root access to the system
 Terminator, RootShell
Conclusion….
 Pros Continued
 Mass Distribution
 Since most corporations and companies use the same software
& hardware setup
 One compiled version can be used on a wide amount of machines
 Practical Use
 Forensics
 Recovery of data
Conclusion….
 Cons
 Not a very diverse attack
 Needs to be recompiled based on:
 System Hardware
 Operating System Kernel
 Not effective against ECC
 Newer computers implement ECC memory
 Limited to older systems
 No support for multi-core
 New systems built today are exercising multi-core
 Physical Interaction needed
 Direct access to the computer is required
References

J. Mäkinen. Automated OS X Macintosh password retrieval via firewire.
http://blog.juhonkoti.net/2008/02/29/automated-os-x-macintosh-password-retrievalviafirewire, 2008.

Trusted Computing Group. Trusted Platform Module version
1.2.http://www.trustedcomputinggroup.org/specs/TPM/.

WiebeTech. HotPlug: Transport a live computer without shutting it down.
http://www.wiebetech.com/products/HotPlug.php, 2008.

R. Anderson. Security Engineering: A Guide to Building Dependable Distributed Systems. Wiley,
First edition, January 2001.

A. Boileau. Hit By A Bus: Physical Access Attacks with Firewire. In RUXCON, Sydney, Australia,
Sep 2006.

Wikipedia

W. Link and H. May. Eigenshaften von MOS-Ein-Transistorspeicherzellen bei tieften
Temperaturen. In Archiv fur Elektronik und Ubertragungstechnik, pages 33–229–235, June 1979