2. 2
360 Marvel Team
Established in May 2015, the first professional could
computing and virtualization security team in China.
Focusing on attack and defense techniques in virtualization
system.
â fuzzing framework
â guest machine escape technology
â Hypervisor risk defense technology
8. 8
Attacking Processes in cloud computing
1.⯠Enter VM via web or other devices
2.⯠Exploit virtualization system vulnerabilities to escape VM
3.⯠lateral movements to others VMs on host
4.⯠Access to host network
10. 10
The attack surface
â˘âŻ Hardware virtualization componentsâ diversity
Qemuďź 30+
Vmwareďź20+
â˘âŻ Bridge between inside-outside
VM os -> device emulators -> Host os
â˘âŻ Related Vulnerabilities result big dangers
â˘âŻ Limitation
12. 12
Basic intro
Attack surface ďź hardware virtual components
Environment ďź qemu ďź vmware
Testing results ďź more than 20 vulnerabilities
Challenges ďź lower layers hard to predictďź
Trends
â˘âŻ more attack surfaces
â˘âŻ more kinds of virtualization systems
13. 13
â˘âŻ Hardware virtualization focus on lower layers
â˘âŻ Testing data totally different
Compare to traditional targets
System Kernel
Hypervisor
14. 14
1. Analyze data which flowed to components
2. Change flowed-in dataâs contents and timing
3. Recording all of tiny abnormal activities
4. Analyze abnormal activities, takes and optimize fuzz
framework.
Methods for testing hardware virtual components
15. 15
Other factors of fuzz framework
1.Flexibility (other OS)
â˘âŻ vm in Linux
â˘âŻ coding in C and Python
2. Deeply understand VM system
â˘âŻ language for coding
â˘âŻ development environment
â˘âŻ coding style
17. 17
Fuzz framework working flow (part 1)
1. Set up network and hardware environment, launch server, client
and monitor.
2. Load system hook module, get all of machinesâ device emulators
3. Client ask server for testing data of emulators, server send out
required data.
4. Client received and loaded testing data, launch test.
5. Monitor continually monitor hypervisor, and record logs.
18. 18
Fuzz framework working flow (part 2)
6. Notify the server after client testing finished
7. Server get logs from client and monitor, save it.
8. Server launch log analyze module, determine if anything
wrong happened, and notify admins.
9. Analyze program exceptions, optimize fuzz framework
21. 21
â˘âŻ Device access ports
â˘âŻ Device deal with structures used by data.
â˘âŻ Device data processing
Testing data
22. â˘âŻ User space: generate testing dat,
send request to client kernel
â˘âŻ Kernel space: apply for memory, fill
memory, send info to ports
â˘âŻ Device emulatorďźtesting data flow
insideďźtrigger exceptions
22
Testing data attacks
user space
Kernel space
Device controller
23. 23
Monitor
VM management
â˘âŻ Snapshot
â˘âŻ Reboot
â˘âŻ VM device editing
Dynamic debugging
â˘âŻ Debugging Mode on Start
â˘âŻ Load Debugging Plugin
VM processing log
â˘âŻ User space
â˘âŻ Kernel space
24. 24
Exceptions occur in device emulator
â˘âŻ VM os crash
â˘âŻ Hypervisor crash
â˘âŻ Invisible results
29. 29
â˘âŻInitialization
Port Allocation ďź Address Mapping
Device Status Setting, Resource Allocation
â˘âŻData Transfer
'Write Command' to device TDT register
process of descriptor
3 types descriptor ďź context ďź data ďź legacy
data xfer
set status ďź wait for next instruction
â˘âŻProcessing Details
Circular Memory
TSO ďź tcp segmentation/flow control.
Principle of e1000 Network Device