OPEN PLATFORM SECURITY FOR MOBILE INTERNET
Tieyan Li Irdeto (Online) Agenda
§ Open Mobile Platform: Risks and Mitigations
§ Mobile Application Protection
§ Android Platform Security
§ Dynamic & Full Lifecycle Security
3 Open Mobile Platform Open Platform Ecosystem
Top API Providers (i.e., Operators) Open Platforms (i.e., Social networks) API Consumers (i.e., Developers) Others (i.e., Advertisers)
Mobile Internet Open API
Application
Smartphone Open has a price .....
Walled Garden Open
• Open source • Apple controls what runs on the device via pla orm security • Apps have access to low level OS services • Apple limits OS services that are available to third • Mul ple app stores with no cer fica on or screening party apps process • Apple cer fies/screens all apps • Relies on users to make informed decisions about security • Apple interested in the health of the eco-system (e.g. App developers, network traffic) • Supply chain is much more complex than IOS
Pros Pros • Security is generally good (absent a jailbreak) • Android provides greater opportunity for mobile • Great consumer experience operators Cons • Lower cost smartphones • Mobile operators are marginalized in the iPhone Cons eco-system • Security and opera onal issues impact mobile • High cost of devices operators and consumers Risks and Mitigations
Web/network Network security attacks Access control
Malware/ spyware Anti-malware Anti-spyware
Remote/local Authentication simulation
Anti-hotlinking Hotlinking Application Reverse Engineering Tampering OS App protection: Illegal copying Anti-reverse engineering Hardware Anti-tampering Anti-copying Jailbreak/rootkits Platform security Building Trust Boundary
Open Cloud Pla orm
Smartphone Cloud Security
Platform Security
APP App Terminal/Device Security Security
Interface Security API Simpler, Closer, Vertical Security
Mobile Internet Vertical Security
ß Servers à
Open API ß Platforms à
ß Applications à
ß Devices à
ß Users à Mobile Application Protection Why App Protection?
§ The Evil-Twin § Piracy: Violate the intellectual property of the original Apps. § Malware injection: Re-packaged Apps may contain malwares, botnets, trojans, etc. § A recent study disclosed that nearly 86% of all malware payloads are found in re-packaged versions of legitimate applications.
§ Major task is to protect an App from: § Illegal copying § I.e., paid assets, virtual goods § Reverse-engineering § I.e., leading to loss of IP, re-packaging § Tampering § I.e., game cheating, bypass billing point, or piggybacking malicious code Attacks on software Software is susceptible to different attacks Tampering Data li ing Code li ing Reverse engineering Modifying control flow Run me memory inspec on Data/program file replacement Disassembly Branch jamming Differen al a ack Collusion Reverse control flow Interac ve debugging Process snooping Profit Automa c a ack Redeployed data files Dynamic library exploits Unauthorized use
Different attacks need different protection Software Protection
§ World leading technology to protect software against reverse engineering, and automated attacks.
Data Flow Transforms Reverse Control Flow Transforms White box crypto Tampering Integrity verifica on Engineering Dynamic Code decryp on Dynamic code decryp on Func on Signature Transforms
Core Technology
A ack So ware Diversity So ware Diversity A ack Automa on Automa on Distribu on Security Models
Hardest
White-box § Debuggers § Emulators § Other attack tools
§ Timing analysis Grey Box § Power analysis § Fault injection
Black-box Difficulty to Protect Assets Protect to Difficulty
Input / output Easiest Weakest Attack Effectiveness Strongest White-Box Cryptography
White-box cryptography ensures the input data, keys and resulting output data are protected at all times
Data Key
Transformed data Transformed key
White-box cryptography Transformed and encrypted output Trust Boundary
Trust Boundary
Pla orm Components App.exe • Program launcher • Digital cer ficates • Boot loader Stub • Hardware anchors • Drivers • Firmware Secure Agent
On/Off Decisions : Protected • Pla orm Integrity Resources • Node-lock • Applica on integrity Root of Trust • Resource integrity Op ons • Debugger checks Secure Hardware Controls execu on of the applica on: Device Fingerprint • Resource files Secure MicroSD flash • Access to online server Varying degrees of trust are supplemented by 2 way communica ons with the “head-end” Deployment Model
Customer or Hosted Modules App
Stub Agent Resource Individualiza on Genera on Protec on Agent
Protected Resources
Security Lifecycle Services
Countermeasures / Updates Internet
Countermeasures A ack A ack Design & Analysis Monitoring Development Run-time Application Protection
Applica on Market Mobile Device
APK protec on APK tool Download Resource Protec on Secure Class Loader APK Signing APK Java Access Control Secure Store Secure Agent Agent Genera on Secure Store
Ø Google Play’s App Encryption mechanism on Jelly Bean (Android 4.1) doesn’t provide “Post-download” App Protection! Towards Platform Security
Application Protection Platform Security x x √ √ √ App.√ App App App App App O/S x O/S √ Hardware x Hardware √
§ Applications are protected one by one § An alternative approach is to create a “trusted platform”, often a competing § Protected applications are trusted; approach to Trusted applications
§ Unprotected applications are not trusted; § “Platform Security” indirectly enables § Whole platform is not trusted. Applications security.
Android Platform Security Android Market
Source: Informa, 2011
§ Android accounts for 50% of smartphones sold worldwide § 300 million cumula ve units ac vated including 12 million tablets § Current ac va on rate is 850 thousand units/day (310 million annualized) § Large deployment of Android makes it a target for hackers Android Security Challenges
Malicious So ware Grayware Apps Trusted Apps / Enterprise Apps • Consumer malware • Apps that abuse Distributed by: privacy • Mobile operators • Security apps • Advanced threats • Apps that abuse the • Android market • Payment / mobile • Rootkits network • Third party app stores commerce apps • Botnets • Adware • Other • Customer support • Spyware • Tethering Apps apps • Hijacked Apps • Email apps • Compromised Apps • A ack tools • Salesforce apps • Censored Apps
Malicious So ware / Grayware Apps/ Trusted Apps/ Enterprise Apps
Affects: MNO’s, Consumers, Enterprises Affects: MNO’s, Enterprises
Impact: Network outages, customer support Impact: ability to deploy new apps/services, costs, consumer privacy, service fraud, brand consumer privacy, brand
Security Challenges; Security Challenges: • Detect Malicious Apps and Grayware • Prevent Trusted Apps/Enterprise Apps and data • Preven ng Malicious Apps and Grayware from being compromised • Protec ng the security func ons that prevent • Prevent piracy / hijacking of Apps these threats • Protec ng the security func ons that enable the above
Android Security Approaches
§ Google “Bouncer” § Once an applica on is uploaded, the service immediately starts analyzing it for known malware, spyware and trojans. It also looks for behaviors that indicate an applica on might be misbehaving, and compares it against previously analyzed apps to detect possible red flags. We actually run every applica on on Google’s cloud infrastructure and simulate how it will run on an Android device to look for hidden, malicious behavior.
§ Dissected by Jon Oberheide and Charlie Miller, on SummerCon’12. § It uses Linux + Cloud + Simulation (QEMU) § It will catch crappy malware, it won't catch sophisticated malware
§ Many other security approaches: § App censorship tools: RiskRanker, jointly by NCSU and NQ Mobile. § Mobile AV, security management solutions from security vendors. § Research works on Android permission models in Academia. BYOD
Personal Domain Work Domain § User can download/use apps from § Work apps authorized by corporate IT anywhere § Corp. IT set policy for apps/data § Corporate IT cannot access apps and data in § Prevent loss of data (emails, contacts, SMS, the Personal domain via the management other) via interface § Malware that infects the Personal § If the device is lost or stolen Domain § User can locate / lock / wipe § Lost/stolen device personal data § Removal or loss of SD card containing confiden al data
§ If the phone is lost or stolen: § Work data is encrypted § Work domain can be remotely wiped by corporate IT
Seamless transi on between Work and Personal apps/domains
Low device overhead
Ease of integra on / deployment
Domain Isolation Approaches
Work Domain
Personal Domain Work Domain Work Domain Apps Personal Domain Apps Apps Personal Domain Apps Android Apps Middleware Apps Android Android Virtual. Middleware Middleware Layer Linux Kernel Android Kernel Kernel Middleware Android Middleware Hypervisor
Hypervisor Linux Kernel (Host) Linux Kernel
Type 1 Hypervisor Type 2 Hypervisor OS- Level VM • Not currently supported by the • Exposed to kernel layer attacks • Exposed to user and kernel layer ARM instruction set • Less integration required with OEM malware • OEM Integration is an issue • Integration can occur later in • Heavy performance penalty for work apps • e.g. Redbend the development cycle • Requires work apps to be ported to the • e.g. VMware Mobile Horizons VM • Work app IPC handled by the VM • e.g. Enterproid Divide Domain Isolation Approaches
Domain A Domain B Normal World Secure World Domain A Domain B
Apps Apps Apps Apps Apps Apps
Android Middleware Rich OS Secure OS Android Middleware
Linux Kernel Hardware Linux Kernel
TrustDroid TrustZone An ideal solution? • Need to modify the Android • Leverage hardware security • No reliance on hardware middleware • Strong security for secure world • No duplication of software stack • Use Tomoyo Linux apps • Prevent advanced malwares • Exposed to kernel layer attacks • Security APIs for apps in Rich OS • Easy integration and adoption • Low CPU/memory/battery • Requires adoption by chip • Small TCB overhead manufacturers, mobile device • Maximize performance • Academic work OEMs • Minimize overhead • Strong assumption on TCB • e.g. ARM TrustZone, TEE • Seamless switch between domains Device View
User Space Alerts, Telemetry Remote Command Agent Android Remote Commands • Standard Android middleware
Android Libraries Dalvik VM
Secure Agent: Kernel Space • Loadable kernel module
System Call Interface • Controls access to kernel objects and services in accordance
with func onality and policies (e.g. app loading, memory Secure System Call Intercept Agent access, etc.) • Prevents rootkit installa on Linux Kernel • Monitors kernel integrity Secure Storage • Verifies integrity of apps and permissions • Maintains a persistent secure store for policy, signature and telemetry data
Hardware (SoC) Security • Agents are protected against tampering and reverse engineering • Communica ons via secure channels • All Agents can be diverse to prevent automated a acks • Built with small TCB • Secure anchoring to hardware SoC Domain Isolation
Personal Domain Work Domain Work Domain white list of apps authorized by corp. IT. Use of Work apps can be tied to: • User session • Presence of a SIM card • Kernel integrity • Other (e.g. location, integrity Android verification of apps )
X X Linux X Secure Kernel Agent IPC channels between domains are blocked
Domain isolation can be enforced if malware in the Personal Domain gains root access with Mandatory Access Control (MAC). Advanced threats such Personal Corporate Memory Work Files Memory Internet as rootkits are prevented. Files Network (encrypted)
Corporate Network are only accessible to apps in the Work Domain. Access to the Internet by Work Domain apps can also be controlled. Work Files are encrypted and not visible to apps in other domains and vice versa. Memory is protected against snooping (e.g. malware with root access, memory dumps, debuggers) Kernel Malware and Rootkits
§ It is relatively easy for Android malware to get root access by exploiting one of the OS layer vulnerabilities
§ A recent study, "Dissecting Android Malware: Characterization and Evolution,“ (Oakland 2012), found that 37% of Android malware samples studied contained root-level exploits and more than 90 percent of malware samples were botnet capable. § Root-level exploits are a particular concern because once a rootkit exploit has been installed in an Android device, detection and recovery are particularly difficult. § This addresses a fundamental security issue associated with Linux in that it does not enforce access control once a process has root access
§ Platform security solution must address kernel layer malware (e.g. malware that gains root access) and kernel rootkits Rootkit Attacks Exploit Exploit uid = 0 Rootkit Rootkit
Rootkit
X Android Android
X Linux Kernel Linux Kernel Rootkit
1. Gain Root Access – Leverage exis ng 2. Unpack/Install the Payload – Unpack payload and vulnerability to gain root access insert into kernel using LKM or /dev/kmem
Android Android
sys_call_ table New Payloads, X Linux Kernel Linux Kernel Commands Remote Payload Payload A acker Startup files X 4. A ack – At this point the a acker owns the device and can 3. Persistence/Concealment -- Conceal rootkit and do whatever he or she wishes to do remotely : establish permanence by modifying sys_call_table • Install new so ware and startup files. • Monitor all communica ons • Access the camera and microphone • Kill the device, etc. Exposure to Rootkit Attacks
Devices with AV signature detec on. Patched Devices All Android devices with the vulnerability used by the rootkit to gain root Devices without AV All unpatched access. signature detec on. devices without AV
Rootkit A ack signature detec on . Devices Exposed to a
Time Rootkit A ack Signature Generally OEM Patch Launched Available Available
§ Rootkit attacks often do the most damage when they are initially launched
§ Most mobile devices don’t have AV scanners so the exposure window can be lengthy Android Rootkit Families
DroidKungFu3 DKFBootKit Malware with root exploits LeNa DroidKungFu2 RootSmart DroidKungFuSapp
GingerMaster TGLoader DroidCoupon DroidDeluxe zHash DroidDream DroidKungFu
Kernel rootkits
Gingerbreak Exploid DoSDroid Zimperlich RAtC KillingInTheName Levitator MempoDroid Mindtrick (zergRush*) (Psneuter*)
Vold Ueventd Zygote Adbd Ashmem PowerVR mem_write
Netlink Setuid Kernel vulnerabilities
Note. Mindtrick assumes the device has been rooted so could leverage any of the known kernel vulnerabilities to gain root. Dynamic & Full Lifecycle Security Static Security
Security process Hacker process
Ini al a ack resistance H1: Analyze H2: Develop H3: Automate H4:Distribute Deployed Security a ack A ack A ack
Secure In the field implementa on
§ Focus on initial resistance § There will be a crack: § All static security solutions – even strong ones- in the market are compromised (see table) Dynamic Security
Robust Implementation Lifecycle management
A ack resistance Monitor & analyze hacker Deploy counter Respond to measures a acks Renew security progress A ack mi ga on
Hacker process
Multiple layers of security, diversity and H1: Analyze H2: Develop H3: Automate H4:Distribute renewability break the Security a ack A ack A ack hacker’s business model Security Lifecycle
Pre-Launch Post-Launch
Product Security Initial Attack Watch Mitigation Renewed Attack Development Design Resistance And Defend Planning Resistance
Optimize Security A ack A ack Countermeasures Design Design ActiveCloak Server Monitoring Analysis & Dev ActiveCloak Server Attack Mitigation and Recovery
§ Strong attack response Tamper Diverse § Reduces duration of attack resistance production $ Raises cost of attack Reduces scope of attack
Resulting Hacker Business Model
Time Investment Reward
Software Diversity Benefits Minimize scope of attack -- Prevent automated attacks Provide rapid recovery in the event of an attack Make the business unattractive to the hacker Summary
1, Openness VS. Security Mobile Internet needs Open Pla orm New malwares are coming Fast and Furious Innova ve Security is demanded
2, Security Strategy App protec on à pla orm security Dynamic, Mul -layer, Full lifecycle Simpler, Closer, Ver cal
Thank You!