retroac ve detec on of malware with applica ons to mobile
play

Retroac(ve Detec(on of Malware with Applica(ons to Mobile Pla8orms - PowerPoint PPT Presentation

Retroac(ve Detec(on of Malware with Applica(ons to Mobile Pla8orms Markus Jakobsson KarlAnders Johansson FatSkunk 1 Market forecast for mobile More smartphones than PCs in 23 years Dominant pla@orms targeted 4G will fuel


  1. Retroac(ve Detec(on of Malware with Applica(ons to Mobile Pla8orms Markus Jakobsson Karl‐Anders Johansson FatSkunk 1

  2. Market forecast for mobile • More smartphones than PCs in 2‐3 years – Dominant pla@orms targeted • 4G will fuel apps and mobile Internet use – M‐commerce, M‐voJng, Parental Control, … • Phones are personal , have rich data – Social use makes users more vulnerable • Power limitaJons stymie AnJ Virus products – Power consumpJon increases with # threats • Likely big threats: – Bluetooth viruses, (piracy) trojans, social malware

  3. Trends: Faster, stealthier, smarter kits, recompilers, polymorphism malware oTen installs AV (limit compeJJon) produced by organized crime

  4. Contrast: What the consumer wants Freedom Undo

  5. What makes this challenging 1. Malware masquerades and deceives 2. Malware will not allow itself be erased 3. Malware can catch interrupts 4. Malware can edit system calls/responses 5. Malware is bad, will not cooperate

  6. Main principles • To block detecJon, malware must be ac2ve . • To be acJve, malware needs to be in RAM . • RAM is faster than flash and radio. 6

  7. monolith kernel 1. Swap out all programs (malware may refuse) cache RAM Contact markus@fatskunk.com for more details incl. improvements. 7

  8. monolith kernel 1. Swap out all programs (malware may refuse) 2. Overwrite all “free” RAM pseudo‐random content(malware refuses again) cache RAM Contact markus@fatskunk.com for more details incl. improvements. 8

  9. monolith kernel 1. Swap out all programs (malware may refuse) 2. Overwrite all “free” RAM pseudo‐random content(malware refuses again) cache RAM Contact markus@fatskunk.com for more details incl. improvements. 9

  10. monolith kernel 1. Swap out all programs (malware may refuse) 2. Overwrite all “free” RAM pseudo‐random content (malware refuses again) 3. Compute keyed digest of all RAM cache (access order unknown a priori) RAM Contact markus@fatskunk.com for more details incl. improvements. 10

  11. monolith kernel 1. Swap out all programs (malware may refuse) 2. Overwrite all “free” RAM pseudo‐random content (malware refuses again) 3. Compute keyed digest of all RAM cache (access order unknown a priori) RAM Contact markus@fatskunk.com for more details incl. improvements. 11

  12. monolith kernel 1. Swap out all programs (malware may refuse) 2. Overwrite all “free” RAM pseudo‐random content (malware refuses again) 3. Compute keyed digest of all RAM cache (access order unknown a priori) External verifier provides this RAM Contact markus@fatskunk.com for more details incl. improvements. 12

  13. monolith kernel 1. Swap out all programs (malware may refuse) 2. Overwrite all “free” RAM pseudo‐random content (malware refuses again) 3. Compute keyed digest of all RAM cache (access order unknown a priori) External verifier will Jme this (and check result of computaJon) RAM Contact markus@fatskunk.com for more details incl. improvements. 13

  14. Adversary wants to replace the legiJmate monolith kernel F with a monolith funcJon F’ s.t. F'(x)=F(x) for all x, kernel running in same amount of Jme, where F and F’ do not hand 1. Swap out all programs over control to the same processes (malware may refuse) at the end of their execuJon. 2. Overwrite all “free” RAM pseudo‐random content (malware refuses again) 3. Compute keyed digest of all RAM cache AcJve malware agent can: (access order unknown a priori) 1. Send to flash (incurs delays) 2. Recompute contents (ow!) 3. Get external help (latency) 4. Do all correctly, then cause hand‐over to wrong process 5. Agree to die / get detected 1‐4 will fail RAM Contact markus@fatskunk.com for more details incl. improvements. 14

  15. Some details • Only requirement: know amount/type hardware • Full use of caching (instrucJon + data) • Strategy to maximize penalty for flash access • Two adversarial models: external aoacker or no • SIM card can be used as low‐latency Jmer Contact markus@fatskunk.com for more details incl. improvements. 15

  16. Some stats • Variant implemented ‐ takes <3s on 256MB, 600 MHz Android board • Speedup for mulJ‐core • Detects all acJve malware – retroacJvely • Provable security – no heurisJcs • Suitable for mobile pla@orms • Can be combined with a “secure rsync” Contact markus@fatskunk.com for more details incl. improvements. 16

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend