Android Malware for Pen-testing - IOActive [PDF]

Android Malware for Pen-testing IOAsis San Fransicso 2014

Dr. Who? Robert Erbes Senior Security Consultant

(not a doctor)

Target Audience • The Malicious Defender ™ – i.e., Someone who believes that the best way to evaluate the effectiveness of a security defense is to TEST it. And test it again. And test it again. And test it again…

Why Custom Android Malware? • (See Previous Slide) TEST TEST TEST • One doesn’t just trivially trust ITW Malware – (at least not in polite societies)

• To develop scenarios that match what you actually care about – BYOD – Internal App Store – Prove to management that installing XYZ really isn’t a good idea – Validating Security Product does what it’s supposed to…

The Playground

Architecture Overview GO! • Android is an open source (mostly) operating system that runs on small devices. It is built on top of a slightly modified version of Linux • Runs apps within a VM called Dalvik, which is similar to the Java VM, but optimized for speed. • (stack layout on next slide…)

Android Layer Cake Java

SDK / NDK Bionic (not glibc) Linux / Binary Blobs

Android SDK • Framework for developing applications: – Like the .NET Framework

• Lots of example patterns you can use • APIs you can call to access key features of Android

Android NDK • •

•

The Android Native Development Kit (NDK) is a toolset that allows you to implement parts of your app using native-code languages such as C and C++ If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device. Native code is no different from code running under the Dalvik VM. All security in Android is enforced at the kernel level through processes and UIDs

NDK Madness

#include #include #include jstring Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env, jobject thiz ) { FILE* file = fopen("/sdcard/hello.txt","w+"); if (file != NULL) { fputs("HELLO CRAZY NAME!\n", file); fflush(file); fclose(file); } return (*env)->NewStringUTF(env, "Hello from JNI (with file io)!"); }

int sockfd = socket(AF_INET, SOCK_STREAM, 0);

Dalvik VM • Register-based machine which executes Dalvik bytecode instructions. – Which are generated from Java class files

• Different from a JVM, hence its bytecode is different from Java bytecode.

• As of Android 2.2 has a JIT Compiler

The Kernel • Linux - Underlying OS that runs the Dalvik VM • Very lightly modified version of Linux kernel • 4.0  3.4 Kernel • Pre 4.0  2.6.x Kernel

• But user space wholly unlike that of any other linux system. • File IO. File System tweaks (/system, /data, etc) • Process Management • Drivers (can be binary blobs) for: • Display • Camera, Audio, Video • Keypad • WiFi and Carrier • Inter-process Communication

Building an App 1. Android programmers write android apps in Java. Native apps can be included and written in native languages (e.g. C++) and are compiled for the native architecture (ARM/MIPS, etc.) 2. Then IDEs like eclipse use the JDK to generate .class files which are then translated to .dex files (Dalvik executable). The Android Asset Packaging Tool (AAPT) is then use to build the APK 3. The Dalvik virtual machine in Android can then run these Dalvik executables by translating them to native instructions.

Building “Not an App” • Device drivers appears to be exactly the same as in Linux – Only on ARM/MIPS whatever

• Assets (mentioned earlier) can be anything. This makes them REAL easy to build. 

APK Contents

And We’re Done. • (not really) • We now have – An idea about the pieces involved – A very basic guide about writing software

• What about malware?

Well, What is Malware? • “You know it when you see it” – 1964 Jacob Elllis V.S. Ohio

• Anything that breaks the android security model • Deceptive/hide true intent – bad for user / good for attacker e.g. surveillance, collecting passwords, etc.

• Applications that are detrimental to the user running the device. • Harms a user – – – –

Financial Privacy Personal information – location (surveillance) , Stealing resources – cracking, botnets – processing power

• Example: not-compatible.

More generically • Malware is any piece of software/script/hardware that you don’t want on your Android device, for any reason.

In The Wilde

Categorical Malware

Android Premium Service Abusers Android Adware Source: https://www.lookout.com/

Targeted Spyware

Android Data Stealers

Malicious Android Downloaders

https://www.lookout.com/resources/top-threats

Droid Dream Infection Vector  DroidDream hid the malware in seemingly legitimate applications to trick unsuspecting users into downloading the malware (more than 50 apps on the Android App Store were found to contain Droid Dream) Entry Point  Requires user to launch application. Post-Launch malware will start a service then launch the host application’s primary activity Elevated Privileges  1) “exploid” to attempt to exploit a vulnerability in udev event handling in Android’s init. If “exploid” fails… 2) “rageagainstthecage”, leveraging a vulnerability in adbd’s attempt to drop its privileges. Payload  Sends device information to C&C e.g. IMEI, IMSI and device model and SDK version, Checks if already infected, by checking package com.android.providers.downloadsmanager is installed. If this package is not found it will install the second payload, which is bundled as sqlite.db. This part of the malware will be copied to the /system/app/ directory, installing itself as DownloadProviderManager.apk. Copying the file using this method, to this directory will silently install the APK file, and not prompt user to grant permissions as in a standard app installation process.

Droid Dream (phase 2) Entry Point  triggered by Intents it listens for on the device. receiver for BOOT_COMPLETED and PHONE_STATE intents single service: Payload  DownloadManageService controls a timer-scheduled task Gather information and send to C&C and install: • ProductID – Specific to the DroidDream variant • Partner – Specific to the DroidDream variant • IMSI • IMEI • Model & SDK value • Language • Country • UserID – Though this does not appear to be fully implemented Zombie agent that can install any payload silently and execute code with root privileges at will.

Pentest Scenario

BYOD • Malicious behavior to test: – Tracking Network Surface • WiFi / bluetooth sniffing / profiling

– Tracking Physical Location • GPS Coordinates, accelerometers, altimeters, etc

– On the Network • (GSM -> WiFi -> “Secure” network) – USB

• Egress filtering policies

– Visual/Audio snooping…

Other Means of Being Evil • Bypassing Detection – Arbitrary Code “injection” • Known Vulnerable Libs • Custom Vulnerable Libs • Malicious updating mechanism

– Data Exfiltration • Angry Birds(?!)

Delivery Mechanism • Existing Device under our Control • Complete customization: – Inject/replace device driver – Vulnerable Library + Later exploitation – Malicious Update

• Existing Application – Decompilation + insertion

Launch Mechanisms Unlike other programming paradigms in which apps are launched with a main() method, the Android system initiates code in an Activity instance by invoking specific callback methods that correspond to specific stages of its lifecycle.

Launch via Broadcast • A broadcast receiver is an Android component which allows you to register for system or application events. All registered receivers for an event will be notified by the Android runtime once this event happens. • For example applications can register for the ACTION_BOOT_COMPLETED system event which is fired once the Android system has completed the boot process. • A receiver can be registered via the AndroidManifest.xml file. • Alternatively to this static registration, you can also register a broadcast receiver dynamically via theContext.registerReceiver() method.

• The Broadcast receiver can then start a service to perform any number of actions.

Some Example Broadcast Intents

But… • With so many options, wouldn’t it be nice to automate the generation of malicious apps? • Why yes. Yes it would. • (And we did)

So… • Customized malware is King.

• What can you do?

Security Models Should be Explicit • As policy, your org allows X and Y. But NO Z.

• If something breaks the model, it’s Malware.

Deception Is Bad • Within your model: – If an application does X when it says Y…

• It’s malware.

The Paranoid Validate • Everything.

• Test. And Test. And Test… http://www.flickr.com/photos/adactio/4012169563/

Done (really!) Questions? [email protected]

Pub Key Fingerprint: 1ABA 463E D3ED B8B5 5935 7E07 55A8 049C 46CB 2398