• Like

2013 Toorcon San Diego Building Custom Android Malware for Penetration Testing


In this presentation Stephan will discuss some recent research that emerged he was asked to build malicious applications that bypassed custom security controls. He will walk through some of the basics …

In this presentation Stephan will discuss some recent research that emerged he was asked to build malicious applications that bypassed custom security controls. He will walk through some of the basics of reversing malicious apps for android as well as common android malware techniques and methodologies. From the analysis of the wild android malware, he will discuss techniques and functionality to include when penetration testing against 3rd-party android security controls.

Stephan Chenette is the Director of Security Research and Development at IOActive where he conducts ongoing research to support internal and external security initiatives within the IOActive Labs. Stephan has been in involved in security research for the last 10 years and has presented at numerous conferences including: Blackhat, CanSecWest, RSA, EkoParty, RECon, AusCERT, ToorCon, SecTor, SOURCE, OWASP, B-Sides and PacSec. His specialty is in writing research tools for both the offensive and defensive front as well as investigating next generation emerging threats. He has released public analyses on various vulnerabilities and malware. Prior to joining IOActive, Stephan was the head security researcher at Websense for 6 years and a security software engineer for 4 years working in research and product development at eEye Digital Security.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Building Custom Android Malware for Penetration Testing Stephan Chenette Director of R&D, IOActive Labs 1
  • 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 •Offensive Defense Series 2
  • 3. About this presentation This presentation is an overview of my experience and methodology black box penetration testing a android security control 3
  • 4. Format import time ... start = time.time() end = start + (60*75) while True: Present() if Raise_Your_Hand() == True: Try_To_Answer() now = time.time() if now >= end: print(“Presentation Over!") break 4
  • 5. The goal we were given • Test today’s In The Wild (ITW) malware techniques and methodologies against a particular security control • Create and/or use existing malicious android applications and get them past the security control (test review/controls NOT security in phone) • Suggest improvements to the security control Android App 5 Security Control User’s Phone
  • 6. Why? • Important to focus on Individual Security Controls/Process •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 6
  • 7. Previous Presentations Previous Known Work: “Dissecting the Android Bouncer” Jon Oberheide, Charlie Miller http://jon.oberheide.org/files/summercon12bouncer.pdf 7
  • 8. Agenda • Approach to Accomplishing our Goal • **Introduction to Android – Q&A** • Reversing Android Applications – Q&A • Defensive Technologies – Q&A • Building Custom Android Malware – Q&A • • • 8 Philosophical Rant on “What is Malware?” Techniques/Methodologies Conclusion
  • 9. Agenda • Approach to Accomplishing our Goal • **Introduction to Android – Q&A** • Reversing Android Applications – Q&A • Getting to know Defensive Technologies – Q&A • Building Custom Android Malware – Q&A • • • 9 Philosophical Rant on “What is Malware?” Techniques/Methodologies Conclusion
  • 10. Approach to Accomplishing our Goal Given the goal of duplicating ITW techniques: • Understand the Android Platform • Studied Defensive Technology e.g. how would you detect malicious apps. • Analyzed ITW Malware • Categorized the Malware • Functionality • Class • Duplicated individual functionality • Made Alternative versions (building on prev. defensive tech. knowledge) 10
  • 11. Agenda • Approach to Accomplishing our Goal • **Introduction to Android – Q&A** • Reversing Android Applications – Q&A • Goal/Approach • Defensive Technologies – Q&A • Building Custom Android Malware – Q&A • • • 11 Philosophical Rant on “What is Malware?” Techniques/Methodologies Conclusion
  • 12. Introduction to Android 12
  • 13. 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: Applications written in Java A framework called the Android SDK C++ Libraries and the Dalvik Virtual Machine Linux 13
  • 14. Applications written in Java 14
  • 15. Android SDK Android SDK - Framework for developing applications: • Like the .NET Framework • APIs you can call to access key features of Android 15
  • 16. Android NDK • • 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. • 16 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++ 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
  • 17. Android NDK <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 WORLD!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" /> 17
  • 18. Applications written in C/NDK (iOS port) 18
  • 19. 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. Java Virtual Machine (stack based)  much slower Dalvik Virtual Machine (register based)  much faster 19
  • 20. 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 20
  • 21. Developing an APK in Android 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. 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. 21
  • 22. Agenda • Approach to Accomplishing our Goal • **Introduction to Android – Q&A** • Reversing Android Applications – Q&A • Where to download Android Malware (research) • Getting to know Defensive Technologies – Q&A • Building Custom Android Malware – Q&A • • • 22 Philosophical Rant on “What is Malware?” Techniques/Methodologies Conclusion
  • 23. Android APK Reversing 23
  • 24. Where to get Android Malware • Mal Genome Project • Virus Share • Virus Total • • • • 24 Wepawet Kaspersky (+Other Security Vendors) Offensive Computing Contagio
  • 25. Android APK Structure PK ZIP Android APK 25
  • 26. Android APK Structure 26
  • 27. Decompiling an Android APK File Android APK Android Manifest XML unzip classes dex dex2jar or ded Text Version XML AXMLPrinter2 classes jar jd-gui .java .java .java unzip classes classes jar classes jar .class jad 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/ 27
  • 28. Decompiling an Android APK File Android APK Text Version XML JEB .java .java .java assets assets assets 28 res res res This is my preferred method
  • 29. 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/ 29
  • 30. Android Reversing Tool Bag Source: http://tracedroid.few.vu.nl/thesis.pdf 30
  • 31. Source Executable 1.Compile 2.Export (zip & sign)  APK 31
  • 32. 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. 32
  • 33. Executable  Source • dex files  dalvik opcode • To convert.dex files to a more understandable form we can convert it to smali representation • Dalvik opcodes to smali (intermediate/assembly based language and is a direct mapping. 33
  • 34. 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 • …Just use JEB =] http://www.android-decompiler.com/ 34
  • 35. Agenda • Approach to Accomplishing our Goal • Introduction to Android – Q&A • Getting to know Defensive Technologies – Q&A • Building Custom Android Malware – Q&A • • • 35 Philosophical Rant on “What is Malware?” Techniques/Methodologies Conclusion
  • 36. Defensive Technologies 36
  • 37. Detection Technologies • Ultimate goal is to upload app to “walled garden” (restrictive environment) • 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 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. • Fuzzy hashing against known apps • AndroidManifest.xml file • Dynamic Behavior Analysis • 37 DroidBox - https://code.google.com/p/droidbox/
  • 38. Agenda • Approach to Accomplishing our Goal • Introduction to Android – Q&A • Getting to know Defensive Technologies – Q&A • Building Custom Android Malware – Q&A • • • 38 Philosophical Rant on “What is Malware?” Techniques/Methodologies Conclusion
  • 39. Enough already, Let’s Start Building Malware! 39
  • 40. Approach/Methodology Research In The Wild (ITW) Android Malware • Techniques • Methodologies 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) 40 7. Mix, max and combine unit-based tests into samples
  • 41. Where do we start? • What is malware? • What are the different malware categories? • Methodology/Techniques 41
  • 42. What is Malware? Malware • Not always easy to define [ start philosophical rant] • 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 of malware vs.. useful tool: not-compatible. • 1964 Jacob Elllis V.S. Ohio - How do you define P0rn? …“You know it when you see it” 42
  • 43. What is Malware? 43
  • 44. What is Malware? 44 Is this Malware?
  • 45. Android Malware Categories Android Premium Service Abusers Android Adware 45 Android Data Stealers Source: https://www.lookout.com/ Targeted Spyware Malicious Android Downloaders
  • 46. 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 46
  • 47. Top Threats 47 Source: https://www.lookout.com/resources/top-threats
  • 48. 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. 48
  • 49. Top Threats Droid Dream 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. 49
  • 50. Top Threats 50 Source: https://www.lookout.com/resources/top-threats
  • 51. Top Threats 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. GGTracker 51 Source: https://blog.lookout.com/wp-content/uploads/2011/06/GGTracker-Teardown_Lookout-Mobile-Security.pdf
  • 52. Top Threats Entry Point  When installing, the user is prompted with a list of permissions the application requires: • 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. android.permission.ACCESS_WIFI_STATE android.permission.CHANGE_WIFI_STATE android.permission.CHANGE_NETWORK_STATE android.permission.ACCESS_NETWORK_STATE Payload  android.permission.RECEIVE_BOOT_COMPLETED android.permission.INTERNET • The app posts the phone android.permission.READ_PHONE_STATE number to the GGTracker android.permission.READ_SMS remote server, where the android.permission.RECEIVE_SMS malware starts to subscribe the android.permission.SEND_SMS device to premium services. GGTracker 52 Source: https://blog.lookout.com/wp-content/uploads/2011/06/GGTracker-Teardown_Lookout-Mobile-Security.pdf
  • 53. Top Threats + 1000s Other Apps 53 Source: https://www.lookout.com/resources/top-threats
  • 54. 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 • Calles API methods via reflection • Took advantages of bugs in DEX2JAR to break manual/automated analysis if using DEX2JAR (will break analysis only if using DEX2JAR) 54
  • 55. Worth Investigating HoseDex2Jar • Injected files into the header Source: Tim Strazzere http://hitcon.org/2013/download/Tim%20Strazzere%20-%20DexEducation.pdf 55
  • 56. Obfuscation • ProGuard / DexGuard • Used at compile time • API Reflection • Used by desktop Java malware for years • Reflection can allow a program to create a “method pointer” (a rough analogy for better understanding) and invoke the target method by using it. • Uses this feature to deceive any casual static code analysis module which tries to detect whether a sample is calling the method that sends SMS messages. (e.g.:sendTextMessage()) • Encrypted Network Communication • Encrypted Files 56
  • 57. Building Custom Android Malware 57
  • 58. 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) • • • 58 Decompile/Obfuscate/Re-Write Recompile Upload •Merge with legitimate applications •Fabricate Android Malware
  • 59. Target • Reviewer  • End detection engine • End user • Internal resource that is adjacent to the android device (e.g. internal network) • Etc. 59
  • 60. Probes – Determine Environment 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. 60
  • 61. Probes – Determine Environment Red Pill/Blue Pill Test - Running in an emulator?? if (android.os.Build.MODEL.equals(“google_sdk”)) { // emulator } else { //not emulator } 61
  • 62. Probes – Determine Environment Anti-Emulation Tim Strazzere’s Anti-Emulator Project (Lookout Security) https://github.com/strazzere/anti-emulator 62
  • 63. 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. 63
  • 64. Probes – Determine Environment • • • • 64 Record Audio Take Video Take Photos Send Existing Photos
  • 65. Probes – Determine Environment • Other Processes/Apps on device • Other permissions/intents of installed apps • Info-leak in error messages? 65
  • 66. Upload ITW Malware • ADRD • AnserverBot • DroidDeluxe • Asroot • DroidDream • BaseBridge • DroidDreamLight • BeanBot • DroidKungFu1 • Bgserv • DroidKungFu2 • CoinPirate • FakeNetflix • CruseWin • EndofDay • DogWars 66 • DroidCoupon • And many more…
  • 67. Build Common Scenarios 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 67
  • 68. 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 • • 68 Actions start immediately (service, thread, etc.) Actions which start based on a timer
  • 69. Android App Entry Point 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. 69
  • 70. Android App Entry Point 70
  • 71. Android App Entry Point 71
  • 72. Android App Entry Point 72
  • 73. Broadcast Actions 73
  • 74. AndroidManifest.xml 74
  • 75. Build functionality 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. 75
  • 76. Collecting Device Data 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 ""; } … 76
  • 77. Build Custom Scenarios 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 77
  • 78. Android Exploitation Space 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. 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. 78 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. 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
  • 79. 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 fullout 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” 79 Source: “A Survey of Android Malware”, Xuxian Jiang, Yajin Zhou
  • 80. Considerations • Store • • Gateway/Desktop AV • • Setup entire end-to-end test Behavior Analysis Engine • 80 Set time of Application release to some date in the future (to make sureit’s not downloaded None =]
  • 81. Agenda • Approach to Accomplishing our Goal • Introduction to Android – Q&A • Getting to know Defensive Technologies – Q&A • Building Custom Android Malware – Q&A • • • 81 Philosophical Rant on “What is Malware?” Techniques/Methodologies Conclusion
  • 82. Conclusion • Malware is a matter of perspective • Trivial to get “malware” onto a system • Custom malware • • 82 almost guaranteed to get through because majority detection techniques are focused on known-bad (signatures/clustering)
  • 83. Conclusion • • 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” • 83 Hashes work (on known samples) App review process should have way to determine if good app has been “trojanized” use certificates for known good and known bad
  • 84. Questions? Stephan Chenette, Twitter: @StephanChenette Slide Share: http://www.slideshare.net/schenette Thanks to JEB Analysis Tool, Jurriaan Bremer, Robert Erbes, Esteban Fayo and the IOActive Team! 84