1

Building Custom Android Malware for Penetration Testing

Stephan Chenette

Director of R&D, IOActive Labs

Who am I?

• Stephan Chenette

• About Me:

•Director of R&D @ IOActive

•eEye, SAIC, Websense [13+yrs]

•Breaking technology to expose weakness

•Building technology / innovation

* This is my 3rd time speaking at BruCON =]

2

Audience

• Built/Bought/Broken defensive security controls for android malware

• Foundation - Android malware/apps

• This presentation is an overview of my experience and methodology blackbox penetration testing a android security control

3

Why Build Custom Android Malware for Penetration Testing?

4

Why?

• Classical thoughts of Penetration Testing (you think Network)

• Important to focus on Individual Security Controls

•Mobile Device Management, Gateway AV, Desktop AV, Application Stores, etc.

• Compartmentalizing “security tests” (from ITW malware) (non contrived/theoretical)

• Systematically/Structurally attempt to bypass a security control

• Improvement in technology

• Improvement in education for the developer

• Help in determining and/or exposing risks to current boundaries of a product/technology

5

Previous Presentations

Previous Known Work:

“Dissecting the Android Bouncer”

Jon Oberheide, Charlie Miller

http://jon.oberheide.org/files/summercon12-bouncer.pdf

6

Introduction to Android

7

What is Android?

Android is a mostly open source operating system that runs on small devices. It is built on top of Linux

and runs a VM called Dalvik, similar to the Java VM, but optimized for speed.

From top to bottom, the stack looks like this:

8

Applications written in Java

A framework called the Android SDK

C++ Libraries and the Dalvik Virtual

Machine

Linux

Applications written in Java

9

Android SDK

Android SDK - Framework for developing applications:

• Like the .NET Framework

• APIs you can call to access key features of Android

10

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 Java code running under the Dalvik VM. All security in Android is enforced at the kernel level through processes and uids

11

Android NDK

12

#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 WORLD!\n", file); fflush(file);

fclose(file);

}

return (*env)->NewStringUTF(env, "Hello from JNI (with file io)!");

}

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

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

<uses-permission android:name="android.permission.INTERNET" />

Applications written in C/NDK (iOS port)

13

Java Virtual Machine (stack based) much slower

Dalvik Virtual Machine (register based) much faster

Dalvik VM

The applications built for Android are run on top the Dalvik Virtual Machine.

This is a Process Virtual Machine, like the Java Virtual Machine or the .NET Runtime

The Dalvik virtual machine (DVM)

• register-based machine which executes Dalvik bytecode instructions.

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

14

Android Linux

Linux - Underlying OS that runs the Dalvik VM

• Very lightly modified version of linux kernel

• But user space wholly unlike that of any other linux system.

• File IO

• Process Management

• Drivers for:

• Display

• Camera, Audio, Video

• Keypad

• WiFi and other networking resources

• Inter-process Communication

15

Developing an APK in Android

1. Android programmers write android apps in java. Native apps can included and written in native languages e.g. C++ and are compiled for the native architecture (ARM/MIPS, etc.)

2. The IDEs like eclipse use the JDK to generate .class files which are then converted to .dex files (dalvik executable). AAPT is then use to build the APK

3. The dalvik virtual machine (dalvikvm) in Android can then run these dalvik executables by translating them to native instructions.

16

Enough Intro, Let’s Start Building Malware!

17

Approach/Methodology

Research In The Wild (ITW) Android Malware

• Techniques

• Methodologies

18

Research Defensive Security Controls

• Techniques

• Methodologies

1. Probe Environment (RECON)

2. Upload and test ITW Malware (Test barrier to entry)

3. Regroup

4. Upload “trojaned” apps / altered versions of ITW Malware

5. Regroup

6. Upload unit-tests (real-world/fabricated samples)

7. Mix, max and combine unit-based tests into samples

Research In The Wild (ITW) Android Malware

19

20

Initial Analysis

• What is malware?

• What are the different malware categories?

• Methodology/Techniques

21

What is Malware?

Malware

something malicious, right !?

22

What is Malware?

Malware

• Anything that breaks the security model (without the users consent)

• 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

• Breaks Network policy

• Example: not-compatible.

• 1964 Jacob Elllis V.S. Ohio

• How do you define P0rn? …“You know it when you see it”

23

What is Malware?

24

What is Malware?

Is this

Malware?

25

Android Malware Categories

Android Premium

Service Abusers

Android Adware

Android Data Stealers

Targeted

Spyware

Malicious Android

Downloaders

Source: https://www.lookout.com/

26

Android Malware Analysis

Infection Vector - How it installed on the device

Entry Point – How the malicious behavior is initiated

Elevated Privileges – if and how it gained root privileges

Payload – it’s Purpose and functionality

Hosting – does it contain embedded apps

Top Threats

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

Top Threats

28

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

Top Threats

29

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

Powerful zombie agent that can install any payload silently and execute code with root

privileges at will.

Droid Dream

Top Threats

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

Top Threats

31 Source: https://blog.lookout.com/wp-content/uploads/2011/06/GGTracker-Teardown_Lookout-Mobile-Security.pdf

GGTracker

Infection Vector User is phished into visiting to a website that tricks them into installing a

battery manager application file from a fake Android Market store.

Top Threats

32 Source: https://blog.lookout.com/wp-content/uploads/2011/06/GGTracker-Teardown_Lookout-Mobile-Security.pdf

GGTracker

Entry Point

When installing, the user is prompted with a list of

permissions the application requires:

android.permission.ACCESS_WIFI_STATE

android.permission.CHANGE_WIFI_STATE

android.permission.CHANGE_NETWORK_STATE

android.permission.ACCESS_NETWORK_STATE

android.permission.RECEIVE_BOOT_COMPLETED

android.permission.INTERNET

android.permission.READ_PHONE_STATE

android.permission.READ_SMS

android.permission.RECEIVE_SMS

android.permission.SEND_SMS

• This malware will either start

itself after receiving an SMS or

having the application launched.

• On the first launch, it

communicates with the tracking

server, ggtrack.org.

Payload

• The app posts the phone

number to the GGTracker

remote server, where the

malware starts to subscribe the

device to premium services.

Top Threats + 1000s Other Apps

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

Most Sophisticated Malware Yet

OBAD

• Installs as device admin app (permissions)

• Very difficult to uninstall

• Heavily Obfuscated

• Send SMS to Premium numbers

• Download other malware

• Remote command Execution

• Called API methods via reflection

• Took advantages of bugs in DEX2JAR to break manual/automated analysis if using DEX2JAR

34

Obfuscation

• ProGuard / DexGuard

• API Reflection

• Encrypted Network Communication

• Encrypted Files

35

In-House Framework

• Added functionality to framework

• Library of repeatable security tests

36

Research Defensive Technologies

37

Bypassing Detection

38

• Ultimate goal is to get app to user

• To do that you have to upload app to “walled garden”

• To do that you must bypass detection capabilities / review process

• Detection capabilities

• Hashes

• Native apps

• Dex files

• Dalvik opcodes sigs

• Decompile dalvik to smali and use sigs

• Fuzzy hashing against known apps

• AndroidManifest.xml file

Suspicious Permissions

android.permission.READ_FRAME_BUFFER (read frame buffer)

android.permission.CLEAR_APP_CACHE (delete all application cache data)

android.permission.WRITE_SECURE_SETTINGS (modify secure system settings)

android.permission.INJECT_EVENTS (inject user events)

android.permission.BIND_DEVICE_ADMIN (interact with device admin)

android.permission.INSTALL_PACKAGES (directly install applications)

android.permission.DELETE_PACKAGES (delete applications)

Etc.

Building Custom Android Malware

39

Methodology

• Define the target and objectives

• Profile target

• Determine environment

• Determine detection capabilities

•Upload ITW Malware • Determine what gets caught and what doesn’t

• “Rinse and Repeat”

•Create Alternative Versions (Private) • Decompile/Obfuscate/Re-Write

• Recompile

• Upload

•Merge with legitimate applications

•Fabricate Android Malware

40

Target

41

• Reviewer

• End detection engine

• End user

• Internal resource that is adjacent to the android device (e.g. internal network)

• Etc.

Probes – Determine Environment

42

What’s the first thing you’d do if you go explore a new universe?

Send out a few probes to gather information, right?

No Different here.

Probes – Determine Environment

Red Pill/Blue Pill Test - Running in an emulator??

43

if (android.os.Build.MODEL.equals(“google_sdk”)) {

// emulator

} else {

//not emulator }

Probes – Determine Environment

• Device info

• IMEI, Device Model/Make etc.

• GEO Location help determine language to write app in

• IP Address / 3G/4G or on wifi network?

• Scan for available blue-tooth devices

• Egress filtering? ports open, etc.

44

Probes – Determine Environment

45

• Record Audio

• Take Video

• Take Photos

• Send Existing Photos

Probes – Determine Environment

46

• Other Processes/Apps on device

• Other permissions/intents of installed apps

• Info-leak in error messages?

Upload ITW Malware

• ADRD

• AnserverBot

• Asroot

• BaseBridge

• BeanBot

• Bgserv

• CoinPirate

• CruseWin

• DogWars

47

• DroidCoupon

• DroidDeluxe

• DroidDream

• DroidDreamLight

• DroidKungFu1

• DroidKungFu2

• FakeNetflix

• EndofDay

• And many more…

Build Common Scenarios

48

Scenario Description

Android Premium Service Abusers Premium service abusers subscribe users to various "services" that add to their phone bill at the end of the month

Android Adware Android apps that use abusive advertising tactics

Android Data Stealers Android data stealers often bilk users of information such as their operating system version, product ID, International Mobile Equipment Identity (IMEI) number and other information that could be used in future attacks

Malicious Android Downloaders Once a malicious downloader has infected a victim's Android device, it is designed to contact a remote server to await instructions or download additional Android malware

Android App Entry Point

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.

• Services which start at broadcast receiver callback

• Callbacks which correspond to a user action

• Actions start immediately (service, thread, etc.)

• Actions which start based on a timer

49

Android App Entry Point

50

Layout/activity_main.xml:

<?xml version="1.0" encoding="utf-8"?> <LinearLayout

xmlns:android="http://schemas.android.com/apk/res/android"

android:layout_width="match_parent" android:layout_height="match_parent"

android:orientation="vertical" > <Button android:id="@+id/button1"

android:layout_width="wrap_content" android:layout_height="wrap_content"

android:onClick="onClick" android:text="Button" /> </LinearLayout>

A broadcast receiver (short 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.

Android App Entry Point

51

Android App Entry Point

52

Android App Entry Point

53

Broadcast Actions

54

AndroidManifest.xml

55

Build functionality

56

Functionality

Autostart on boot

Get phone number, IMSI, IMEI, …

Send information to C&C

WiFi connection-aware ( run when phone charging)

Hide application icon

Log SMS/Send SMS

Etc.

Collecting Device Data

57

import android.app.Activity;

import android.content.Context;

import android.telephony.TelephonyManager;

public class PhoneInfo {

public static String getMyPhoneNumber(Activity a) {

try {

TelephonyManager mTelephonyMgr; mTelephonyMgr =

(TelephonyManager) a.getSystemService(Context.TELEPHONY_SERVICE);

return mTelephonyMgr.getLine1Number();

} catch (Exception e) { return ""; }

}

public static String getMyIMEI(Activity a){

try {

TelephonyManager mTelephonyMgr; mTelephonyMgr =

(TelephonyManager) a.getSystemService(Context.TELEPHONY_SERVICE);

return mTelephonyMgr.getDeviceId();

} catch (Exception e) { return ""; } …

Build Custom Scenarios

58

Scenario Description

Vulnerable Lib Build an android app that uses a vulnerable version of libcurl (why? – because then the client will be exploitable)

ALL Intents Build an android app that asked for ALL POSSIBLE permission (why? – this will help us determine if they are filtering by permission)

Various NDK Examples Same functionality but as a native library Can call any static Java API from the NDK going through JNI as long as you’re running in a library instead of an application and instead the dalvik vm

Android Exploitation Space

59

ASHMEM

The ASHMEM custom shared

memory allocator written by

Google has a nasty bug that allows

your device to be easily rooted.

Maybe they should have stuck with

POSIX SHM, but the bad guys

aren't complaining.

Exploid

Nearly identical to a vulnerability

fixed in the Linux udev daemon in

2009, Exploid impacts Android's

init daemon by forgetting to check

whether Netlink messages are

coming from the trusted kernel ...

or a malicious app.

Gingerbreak

A commonly-abused vulnerability

in the wild by Android malware,

Gingerbreak affects the Android

volume manager (vold) via, you

guessed it, the same Netlink issue

as Exploid. Badness ensues.

Levitator

Malicious apps will undoubtedly be

“levitating” their privileges using

this vulnerability that affects the

PowerVR kernel module used for

3D graphics on all S-series devices

and allows unfettered access to

kernel memory.

Mempodroid

Inherited from the upstream Linux

kernel, a vulnerability in the

/proc/pid/mem interface allows for

writing arbitrary memory in the

address space of a setuid process.

It's about as complicated as it

sounds, but attackers are smart

like that.

Wunderbar

Another crossover from the Linux

kernel, this NULL pointer

dereference was one of the first

privilege escalation vulnerabilities

exploited on the Android platform,

thanks to faulty mmap_min_addr

protection on ARM.

ZergRush

No, it has nothing to do with

StarCraft, sorry. The ZergRush

vulnerability in Android's libsysutils

allows an attacker to overwhelm

the system with command

arguments, not zerglings, and take

full control of your device.

Zimperlich

Always check return values.

Android's Zygote process, from

which all new apps are spawned,

forgets this important rule and fails

to check the return value of

setuid(2), leading to plentiful root

shells!

Source: http://www.xray.io/#vulnerabilities

Android Exploitation Space

• Android Master Key – one of the most recent and exploit

• It lets you get at system-android-app-level permissions, not full-out root, but that's enough to do some serious harm (read text messages without permissions, etc.) Might be in a different class than the full-out root exploits, though.

“The Android platform is a complicated system that consists of not only the Linux kernel, but also the entire Android framework with more than 90 open-source libraries includingWebKit, SQLite, and OpenSSL. The complexity naturally introduces software vulnerabilities that can be potentially exploited for privilege escalation.”

“among 1260 samples in our dataset, 463 of them (36.7%) embed at least one root exploit”

60 Source: “A Survey of Android Malware”, Xuxian Jiang, Yajin Zhou

End Result Modular Framework

61

Considerations

62

• Store

• Set time of Application release to some date in the future (to make sureit’s not downloaded

• Gateway/Desktop AV

• Setup entire end-to-end test

• Behavior Analysis Engine

• None =]

End Notes

63

• Malware is a matter of perspective

• Trivial to get “malware” onto a system

• Custom malware

• almost guaranteed to get through

• because majority detection techniques are focused on known-bad (signatures/clustering)

Mitigations/Improvements

64

• Hashes work (on known samples)

• Focus for detect engines should be apps that break the security model (e.g. exploitation root)

• Apps that conform to security model but deceive users can have dangerous permissions highlighted for users

• App reviewers should thoroughly verify what an app does and what it’s supposed to do before being downloaded to a user, auto-deny on key permissions, and ask for more details

• App review process should involve running apps and reviewing code coverage

• App review process should involve using any and all dynamic information to help catch “known malicious artifacts” to consolidate ‘deep-review bucket”

• App review process should have way to determine if good app has been “trojanized”

Questions?

Stephan Chenette,

Email: stephan.chenette @ ioactive.com

Twitter: @StephanChenette

Slide Share: http://www.slideshare.net/schenette

Thanks to JEB Analysis Tool, Jurriaan Bremer, Robert Erbes, Esteban Fayo and the IOActive Team!

65

Supplemental

66

67

Android Malware Repositories

• Mal Genome Project

• Virus Share

• Wepawet

• Kaspersky (+Other AV Vendors)

• Contagio

Android APK Reversing

68

Android APK Structure

69

PK ZIP

Android APK

Android APK Structure

70

Decompiling an Android APK File

71

unzip AXML-

Printer2

dex2jar or ded

Android Manifest

XML

classes dex

Text Version

XML

jd-gui classes jar

.java

unzip classes

jar classes

jar classes .class

jad

.java .java

Android APK

Sony Ericon has a tool that does all of the above in a graphic layout APKAnalyzer

http://developer.sonymobile.com/knowledge-base/tools/analyze-your-apks-with-apkanalyzer/

Decompiling an Android APK File

72

JEB Android APK

Text Version

XML

.java .java .java

res res res

assets assets assets

This is my preferred

method

Android Reversing Tool Bag

• The Android SDK, of course, and Eclipse

• Android APK Tool - for reverse engineering 3rd party, closed, binary Android apps

• dex2jar, which converts Android’s Dalvik executables into normal Java jar files.

• JD-GUI, which decompiles jar files into java source file

• ADB service (the Android Debug Bridge) – for debugging apps

• JEB – if you’re serious about reversing and can spend the $$$ http://www.android-decompiler.com/

73

Source Executable

1.Compile

2.Export (zip & sign) APK

74

Executable Source

• Dalvik bytecode is different from Java bytecode, Hence, Java decompilers cannot decompile it.

• To overcome this issue is to use bytecode-to-bytecode compilers like

• DED (JED better version)

• dex2jar

• to transform the Dalvik bytecode into Java bytecode and then to use a regular Java decompiler

• jd-gui

• dava

• Such a method is prone to errors that may exist in the conversion of the bytecode, resulting erroneous source code.

75

Executable Source

• dex files dalvik opcode

• To convert.dex files to a more understandable form we can convert it to smali representation

• Davikic opcodes to smali (intermediate/assembly based language and is a direct mapping.

76

Executable Source (sort-of)

• smali can't be used to completely reconstruct java source code

• Java is a very developed language

• smali is more of an assembly based language.

• Doesn’t have necessary information to be translated to Java

77