android malware for pen-testing - ioactive · why custom android malware? •(see previous slide)...
TRANSCRIPT
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 Linux / Binary Blobs
Bionic (not glibc)
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 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>
#include <string.h>
#include <jni.h>
#include <stdio.h>
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);
<uses-permission android:name="android.permission.INTERNET" />
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
Android Data Stealers
Targeted Spyware
Malicious Android Downloaders
Source: https://www.lookout.com/
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?
Pub Key Fingerprint:
1ABA 463E D3ED B8B5 5935
7E07 55A8 049C 46CB 2398