sandboxing & virtualization: modern tools for combating...
TRANSCRIPT
Sandboxing & Virtualization: Modern Tools for Combating Malware
Anup K. Ghosh, PhD Founder [email protected] www.invincea.com
Research Professor Center for Secure Information Systems George Mason University
May 2010
The User IS the Target (and an Unwitting Accomplice)
• Ubiquitous usage of Internet and PDFs has enabled adversaries to shi8 tac:cs
• Full frontal assaults s:ll exist but it is far easier to prey on the psychology of the user • Trust in social networks
• Faith in Internet search engines
• Trusted sites
• Spear-‐phishing
• Fear mongering
“I don’t know security…but I know what I like. Click, click, click…”
Stan from Accoun-ng| December 2010
Your first line of defense is also your weakest link…how many thousands of users vulnerabili-es are in your network?
Curiosity Not Only Kills the Cat…
• 2 month study finds Google serves 69% of total malware by search engine (1)
• 60% of top Google search terms delivered user to malicious sites in first 100 results (2)
• 10% of all malware analyzed by Cisco in Q3 2010 was encountered through the search engine(3)
(1) Barracuda Labs Report -‐ July 2010 (2) McAfee threat report – November 2010 (3) Cisco threat report – November 2010
User psychology: • Google = Internet • Google = Trust • Internet = Trust
• Malware authors use Search Engine Op:miza:on to poison search results
A Massive Problem with Malware: Growing in Volume & Sophistication
4
• 60,000 new pieces of malware released on a daily basis in Q3 2010 – 4x more than 2007 (1)
• PDF exploits were the leading cause of infec:ons in 2009(2)
• 99.4% of malicious programs aimed at Windows(3)
• 20,000,000+ unique pieces of malware iden-fied in 2010 (4)
Very important note…these are just the pieces that have signatures…more on that in a minute (1) McAfee threat report – November
(2) Symantec – April 2010 (3) G Data Malware Report Jan-‐Jun 2010 ( (4) PandaLabs – December 2010
A Core Belief… We Must Break the Security Insanity Cycle
• Wash, rinse, repeat security
• Servicing problems not solving them
• Finding out Tuesday that we were pwned on Monday
• Whack-‐a-‐mole problem resolu:on
Large Enterprise Defense Strategy: Castle & Moat Approach
6
Web Gateway
Incoming Threats
Firewalls
IDS/IPS
APTs
O-‐days
Zeus Botnet
Drive-‐bys
Targeted Adacks
Internet Firewalls • Perimeter fencing
• Only stops “known bad” url requests
Network Gateways • Requires signatures of “known bad” • Choke-‐point for Web traffic – scale? • Requires successful breaches to iden:fy new malware
• Misses malware requiring human interac:on
An:-‐virus • Requires signatures of “known bad” • Malware built to avoid AV detec:on
• Signature updates lag by days/weeks
Existing Defenses are Inadequate
Network
7
An:-‐Virus
Pull vs Push Attack Model
8
IDS
Firewall
Endpoint Security Suite
Independent Studies Reveal The Gaps Left by Anti-Virus
9
* Malware Detec:on Rates for Leading AV Solu:ons, A Cyveillance Analysis, August 2010
> “Day 1” An9-‐Virus Effec9veness
> “Day 30” An9-‐Virus Effec9veness
Average An9-‐virus detec9on rate * • 19% “Day 1” • 62% “Day 30”
Innovating for Today and Tomorrow… Making Prevention Possible Once Again
2010 “The Year of the Sandbox” 2011 “100% Virtualized Applica9ons”
• Move high-‐risk applica:ons to fully virtualized environment
• Provide seamless segrega:on of browser and PDF reader from na:ve opera:ng system
• Automa:c, behavioral based detec:on and restora:on
• Forensic data capture and feed to larger infrastructure
Commendable efforts -‐ but too much residual risk is leT on the table…
Solutions Exist – NSA Recommendations
hdp://www.nsa.gov/ia/_files/factsheets/Best_Prac:ces_Datasheets.pdf
Sandboxing Leaves Residual Risk
Application Virtualization Threat Protection Landscape
13
Application Sandboxing
> Applica:ons share the same kernel in sandboxing solu:ons
> Kernel-‐level exploits break the sandbox
14
Physical Hardware
Host Opera9ng System (kernel)
Vulnerable Module
Vulnerable Module
Applica9ons
sandbox Rendering Engine
Browser Kernel
IPC
sandbox
HTML, JS, etc
Rendered Bitmap Sandboxing/Lightweight Virtualiza:on
Architecture
Google Chrome Sandbox Architecture
Hardware Virtualization (Type II)
> Kernel for target applica:on is dis:nct from host system > Infec:ons of applica:on and kernel do not effect Host OS, given
secure configura:on 15
Physical Hardware
Host Opera9ng System (kernel c)
Applica9on
Virtual Machine Virtual Machine
Guest Opera9ng System (kernel a)
Guest Opera9ng System (kernel b)
Applica9on
Virtual Desktop Architecture
> Virtual Desktop users are not separated by any virtualiza:on layer
> Compromise of one user can lead to compromise of several
16
Physical Hardware
Hypervisor (e.g., VMware ESX)
Host OS (e.g., MS Server 2008 with Terminal Services) Single, Shared Kernel
User A Virtual Desktop
User B Virtual Desktop
User C Virtual Desktop
Secure Hardware Virtualization
> Process confinement
> File system confinement > Kernel confinement
> Network confinement > Real-‐:me detec:on that covers previously unseen adacks
> Fast complete recovery to a known clean state
> Forensics for root-‐cause analysis > Integrity monitoring of virtualiza:on layer
> Usability
17
Invincea Browser Protection
• Type II hardware virtualized browser environment
• Signature-‐free malware detec:on • Generates real-‐:me forensic threat intelligence
• Easy to use & deploy
18
Demo of an Infection
Anup K. Ghosh, PhD Founder & CEO [email protected] www.invincea.com
May 2010