Building Custom Android Malware BruCON 2013


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Building Custom Android Malware BruCON 2013

  1. 1. 1 Building Custom Android Malware for Penetration Testing Stephan Chenette Director of R&D, IOActive Labs
  2. 2. 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
  3. 3. 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
  4. 4. Why Build Custom Android Malware for Penetration Testing? 4
  5. 5. 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/technology5
  6. 6. Previous Presentations Previous Known Work: “Dissecting the Android Bouncer” Jon Oberheide, Charlie Miller bouncer.pdf 6
  7. 7. Introduction to Android 7
  8. 8. 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
  9. 9. Applications written in Java 9
  10. 10. Android SDK Android SDK - Framework for developing applications: • Like the .NET Framework • APIs you can call to access key features of Android 10
  11. 11. 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
  12. 12. 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" />
  13. 13. Applications written in C/NDK (iOS port) 13
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. Enough Intro, Let’s Start Building Malware! 17
  18. 18. 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
  19. 19. Research In The Wild (ITW) Android Malware 19
  20. 20. 20 Initial Analysis • What is malware? • What are the different malware categories? • Methodology/Techniques
  21. 21. 21 What is Malware? Malware something malicious, right !?
  22. 22. 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. 23. 23 What is Malware?
  24. 24. 24 What is Malware? Is this Malware?
  25. 25. 25 Android Malware Categories Android Premium Service Abusers Android Adware Android Data Stealers Targeted Spyware Malicious Android Downloaders Source:
  26. 26. 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
  27. 27. Top Threats 27 Source:
  28. 28. 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 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
  29. 29. 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
  30. 30. Top Threats 30 Source:
  31. 31. Top Threats 31 Source: 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.
  32. 32. Top Threats 32 Source: 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, Payload  • The app posts the phone number to the GGTracker remote server, where the malware starts to subscribe the device to premium services.
  33. 33. Top Threats + 1000s Other Apps 33 Source:
  34. 34. 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
  35. 35. Obfuscation • ProGuard / DexGuard • API Reflection • Encrypted Network Communication • Encrypted Files 35
  36. 36. In-House Framework • Added functionality to framework • Library of repeatable security tests 36
  37. 37. Research Defensive Technologies 37
  38. 38. 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.
  39. 39. Building Custom Android Malware 39
  40. 40. 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 Malware40
  41. 41. Target 41 • Reviewer  • End detection engine • End user • Internal resource that is adjacent to the android device (e.g. internal network) • Etc.
  42. 42. 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.
  43. 43. 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 }
  44. 44. 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
  45. 45. Probes – Determine Environment 45 • Record Audio • Take Video • Take Photos • Send Existing Photos
  46. 46. Probes – Determine Environment 46 • Other Processes/Apps on device • Other permissions/intents of installed apps • Info-leak in error messages?
  47. 47. Upload ITW Malware • ADRD • AnserverBot • Asroot • BaseBridge • BeanBot • Bgserv • CoinPirate • CruseWin • DogWars 47 • DroidCoupon • DroidDeluxe • DroidDream • DroidDreamLight • DroidKungFu1 • DroidKungFu2 • FakeNetflix • EndofDay • And many more…
  48. 48. 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
  49. 49. 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
  50. 50. Android App Entry Point 50 Layout/activity_main.xml: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns: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.
  51. 51. Android App Entry Point 51
  52. 52. Android App Entry Point 52
  53. 53. Android App Entry Point 53
  54. 54. Broadcast Actions 54
  55. 55. AndroidManifest.xml 55
  56. 56. 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.
  57. 57. Collecting Device Data 57 import; 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 ""; } …
  58. 58. 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
  59. 59. 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:
  60. 60. 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
  61. 61. End Result  Modular Framework 61
  62. 62. 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 =]
  63. 63. 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)
  64. 64. 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”
  65. 65. Questions? Stephan Chenette, Email: stephan.chenette @ Twitter: @StephanChenette Slide Share: Thanks to JEB Analysis Tool, Jurriaan Bremer, Robert Erbes, Esteban Fayo and the IOActive Team! 65
  66. 66. Supplemental 66
  67. 67. 67 Android Malware Repositories • Mal Genome Project • Virus Share • Wepawet • Kaspersky (+Other AV Vendors) • Contagio
  68. 68. Android APK Reversing 68
  69. 69. Android APK Structure 69 PK ZIP Android APK
  70. 70. Android APK Structure 70
  71. 71. Decompiling an Android APK File 71 unzip AXML- Printer2 dex2jar or ded Android Manifest XML classes dex Text Version XML jd-guiclasses 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
  72. 72. Decompiling an Android APK File 72 JEBAndroid APK Text Version XML .java .java .java res res res assets assets assets This is my preferred method
  73. 73. 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 $$$ 73
  74. 74. Source Executable 1.Compile 2.Export (zip & sign)  APK 74
  75. 75. 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
  76. 76. 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
  77. 77. 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