building custom android malware brucon 2013
DESCRIPTION
TRANSCRIPT
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