Black swans? What’s that?A very interesting research result that is unlikelyto happen in real life
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
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
Gaining access..It’s all about programming a “weirdmachine” (Sergey Bratus et al.)
The weird machineIn short: “a machine that executes anunexpected series of instructions”
By examples• ROP• JIT Spraying – Dion Blazakis• SpiderMonkey Bytecode Hijacking – ThomasDullien• JIT code hijacking – Chris Rohlf and YanIvnitskiy• …
ExploitationExploitation is setting up, instantiating, andprogramming the weird machine - ThomasDullien
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)
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)
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..
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?
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*
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
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
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
Not so much on iOSVulnerability Exploit Patch Availability Malformed CFF Star (JailbreakMe 2.0) 10 days T1 Font Int Overﬂow Saﬀron (JailbreakMe 3.0) 9 days
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
Malware - takeaway• Does only matter on Android and jailbrokeniOS• It scales, it’s easy and it lasts• Can this be fixed? Yes, Apple did
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!
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
Infrastructure• Separate processor• Customized RTOS• Mostly closed-source• Most of them run on ARM (notableexception Hexagon)• Separated (mostly) from the App processor
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
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)
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
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?
So ..1) High ROI2) Very few mitigations3) Detection is hardGreat target for motivated attackers!
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
First caseNot very viable..On the flipside, you can potentially get hugeaccess to the deviceMost likely a black swan
Second caseYou can compromise the device by using tags(simple stickers) -> do not need proximity
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
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?)
DevelopersRealize where the important data is andsegregate itI know Java sucks but don’t write your own C/C++ service for your Android app
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”)
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)
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
In which you can askquestions or insult mePart 5