Download Android Malware for Pen-testing

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
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
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
<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
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