Your SlideShare is downloading. ×

A tale of mobile threats

223

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
223
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. A tale of mobile threatsVincenzo IozzoDirector of Security EngineeringTrail of Bits, Inc
  • 2. In which I blame peoplePart 1
  • 3. Why mobile?11% increase“Total smartphone sales in 2011 reached472 million units and accounted for 31percent of all mobile devices sales, up 58percent from 2010.” - Gartner
  • 4. That’s how we deal with mobile
  • 5. How does offense work?•  Attacker’s mindset•  Gaining access•  Keeping access/stealing data
  • 6. We currently fail badly at theunderstanding the first two
  • 7. First problem: spot the difference
  • 8. Black swans? What’s that?A very interesting research result that is unlikelyto happen in real life
  • 9. Why black swans exist?“Machines can remain vulnerable longer thanyou can remain sane”The security community is fixated onpersistanceA lot of people forget the mantra: “whoeverscores is right”Technical elegance is highly valued
  • 10. Black swans and attacker mathAttackers are resource-constrained: “TheExploit Intelligence Project” (Dan Guido)Attackers are rational human beingsAttackers will take a given exploitation pathIFF no cheaper paths are available
  • 11. Exploitation paths
  • 12. A rational attacker
  • 13. A black swan
  • 14. Practical exampleA rational attackerA black swan (AKA: are you nuts?)
  • 15. So…VS1 0
  • 16. Unless..The ROI on a black swan is higher, for somedefinition of “return”Flame md5 collision attack comes to mindTherefore our graph is weighted
  • 17. Weight functionThat’s very hard to calculate in the general caseSome examples in “Attacker Math 101” (Dino Dai Zovi)A bit out of scope hereBut we can usually draw a line easily
  • 18. What if two paths are equallycost effective?
  • 19. Gaining access..It’s all about programming a “weirdmachine” (Sergey Bratus et al.)
  • 20. The weird machineIn short: “a machine that executes anunexpected series of instructions”
  • 21. By examples•  ROP•  JIT Spraying – Dion Blazakis•  SpiderMonkey Bytecode Hijacking – ThomasDullien•  JIT code hijacking – Chris Rohlf and YanIvnitskiy•  …
  • 22. ExploitationExploitation is setting up, instantiating, andprogramming the weird machine - ThomasDullien
  • 23. Controlling the machine•  You need write primitives•  You need infoleaks/memleaksFor both you need some degree of controlover the application.It’s either pure data or you can directlyinfluence the application state (eg: throughan interpreter of some kind)
  • 24. Controlling the machine 2Just data = most likely you need multiple bugs(infoleak, write primitive, etc)Through interpreter = most likely you just needone (see comex jailbreaks for example)
  • 25. Me no like exploitsThis process is challenged in a few ways:•  Negate the initialization (fix bugs)•  Make the setup hard (heap/stack mitigations,ASLR)•  Make it hard to put together ‘weirdinstructions’ (ASLR, DEP, JIT hardening)•  Reduce/Neutralize the effects of a runningweird machine (sandboxing, code signing)•  More to come in the future..
  • 26. Get to the data/persistence•  How hard is to get your code on a target?•  How far away is the data you care for fromyou?
  • 27. For future reference..So here’s the thing:In a few years everything an attacker caresfor will be inside a browser/mobile appDo sandboxes help with that? *NO*
  • 28. Let’s wrap upAttacker’s mindset: take the most cost-effectivepathWhen it comes to exploitation the most cost-effective path is:1) As close as possible to your data2) Reduces as much as possible the need formultiple bugs/exploits3) Reduces maintenance cost
  • 29. In which I actually talk aboutmobilePart 2
  • 30. Drive-bysMobile  Town   Desktop  City  
  • 31. Too few and too many~8%  of  total  web  traffic  comes  from  mobile  devices  Breakdown  by  version  /  features  (+  varying  rates  of  feature  support)  
  • 32. Like Facebook..
  • 33. TakeawayDrive-bys don’t matter and realistically neverwillHard to get anything useful (contrary todekstops) out of themHard to run the attack in the first placeThe web is the future of the desktop, apps arethe future of mobile = attackers behaveaccordingly
  • 34. MalwareApple  App  Store   Google  Marketplace  
  • 35. One of the reasons
  • 36. Malware lasts long on Android0%10%20%30%40%50%60%70%80%90%100%4.x  -­‐  ICS  /  JB  3.x  -­‐  Honeycomb  2.3  -­‐  Gingerbread  2.2  -­‐  Froyo  2.1  -­‐  Eclair  1.X  -­‐  Cupcake  /  Donut  Android  Exploit   Time  to  Patch  50%  Exploid  (2.1)   294  days  RageAgainstTheCage  (2.2.1)   >  240  days  
  • 37. Not so much on iOSVulnerability   Exploit   Patch  Availability  Malformed  CFF   Star  (JailbreakMe  2.0)   10  days  T1  Font  Int  Overflow   Saffron  (JailbreakMe  3.0)   9  days  
  • 38. AppStore vs Google PlayApple enforces accountabilitySandbox escape: Android > iOSFragmented user-base = the investment lastslongerOn Android privesc are enough to causetroublesThat being said: jailbroken iOS = Android
  • 39. Malware - takeaway•  Does only matter on Android and jailbrokeniOS•  It scales, it’s easy and it lasts•  Can this be fixed? Yes, Apple did
  • 40. App specificAndroid NDK can open up this attack surfacea lotInteresting because applications are likely lessaudited than system codeBut more importantly: interesting data will beinside the app. Why go anywhere else?Expect them in the future!
  • 41. More “smart” in phone?
  • 42. Enter baseband
  • 43. A few words on it•  Most of the code in there is old (1990 old)•  Based on the assumption that the actorsare trusted•  Most of the research has been done by RalfPhilipp Weinmann•  His research led to bug fixing and somemitigations
  • 44. Infrastructure•  Separate processor•  Customized RTOS•  Mostly closed-source•  Most of them run on ARM (notableexception Hexagon)•  Separated (mostly) from the App processor
  • 45. Baseband weird machinesIncreased attention being paid to bugs inthereStill a very big surface with few (known) actorsBig state machine based on a giant interface,so hard to fuzzNeed profound knowledge to find certainbugs
  • 46. Baseband weird machine 2Very few mitigations in placeStill most of the heap metadata exploitation ispossible (eg: write4 primitives on Infineon)No ASLR, no “sandboxes”Remote: control through data onlyLocal: “interpreter” (AT commands)
  • 47. Baseband - persistenceGood luck with forensics/IRDepending on how the App processorinteracts with the BB it might lead to full-device compromiseRegardless: access to phone calls, SMS anddata
  • 48. Attack scenarios•  Remote exploit to steal/alter/make sms/data/phone calls•  App remote-> BB local rootkit•  BB remote -> BB local rootkit•  DDos in case of crisis?
  • 49. So ..1)  High ROI2)  Very few mitigations3)  Detection is hardGreat target for motivated attackers!
  • 50. NFCThat’s complicated…
  • 51. NFC - capabilitiesCan potentially lead to device compromisethrough malformed packets at protocol level –device proximityCan lead to device compromise at‘application level’ – tag proximitySteal data – roughly 1.5 meters with customhardwareAuth bypass issues
  • 52. First caseNot very viable..On the flipside, you can potentially get hugeaccess to the deviceMost likely a black swan
  • 53. Second caseYou can compromise the device by using tags(simple stickers) -> do not need proximity
  • 54. Second caseYou can either run your exploit for browser andstuff (might require some kind of permission)Compromise through tag parsing!Mobile Pwn2own 2012 was won using thisapproachThis is more interesting! Rational black swan
  • 55. In which I give advicesPart 3
  • 56. Software vendorsPut in place the mitigations that *matter*Hire full-time exploit writers (just a few) anddesign mitigations based on themReduce attacker’s control over your product(why does WinRAR need an x86 interpreter?)
  • 57. DevelopersRealize where the important data is andsegregate itI know Java sucks but don’t write your own C/C++ service for your Android app
  • 58. Policy makersPlan for the threats that are hard to spot (eg:baseband). Enforce encryption forcompany data on employees devicesDo not allow jailbreaks of any kindSegregate mobile devices from the rest ofyour company network (treat them as“untrusted”)
  • 59. In which I make provocativestatementsPart 4
  • 60. ConclusionIf you don’t know *what* you’re protecting,you’ll failLikewise if you don’t know what you’reprotecting *against*, you’ll failYou don’t need a horde of code auditors &policy people, you need a CEO (chiefexploitation officer)
  • 61. Specific to mobileWorry more about the “phone” than the“computer”App sandboxes are great to make persistencehard, way less so for data exfiltrationAndroid is bad, you don’t want that in yourcompanyNFC is/will be more a “physical” security issuethan an Infosec one
  • 62. In which you can askquestions or insult mePart 5
  • 63. Thanks!Questions?vincenzo@trailofbits.com

×