Android Security Workshop

OWASP Poland

Transcript

1. Android security workshop OWASP Poland 24.02.2016
2. Agenda  Android fundamentals  Application components security  Coffee break (free cookies )  OWASP top 10 mobile risks  Reverse engineering & malware analysis
3. Android fundamentals Andrii Sygida OWASP Poland 24.02.2016
4. Agenda • Android Architecture • Android security fundamentals • Android 6.0 security release • Google security features
5. Intro • Android is the world's most popular mobile platform. Features: • Multi-tasking • Widgets • Notifications • Voice Typing and Actions • Photos and video • Most widely used smartphone OS • Phones, tablets, Google TV and more
6. Stats • There are 1.2 billion mobile users. By 2018 that number with be 5 billion. • Mobile adoption is growing 8x faster than traditional web applications. • Mobile payments will exceed $90 Billion by 2017 Bugcrowd Cybersecurity Research 2015
7. Android Architecture
8. Linux Kernel • The architecture is based on the Linux ( started from 2.6) kernel. • This layer is core of android architecture. It provides service like power management, memory management, security etc. • It helps in software or hardware binding for better communication.
9. Libraries • The next layer is the Android’s native libraries. • It is this layer that enables the device to handle different types of data. • The WebKit library is responsible for browser support, SQLite is for database, FreeType for font support, Media for playing and recording audio and video formats
10. Android Runtime • Core libraries • Dalvik Virtual Machine • DVM vs JVM Differences • ART
11. Dalvik VM • The software that runs the apps on Android devices • It's fast, even on weak CPUs • it will run on systems with little memory • it will run in an energy-efficient way • Provides application portability and runtime consistency • Runs optimized file format (.dex) and Dalvik bytecode • Java .class / .jar files converted to .dex at build time
12. ART VS DVM • Android 4.4 – Experimental. From android 5.0 - Default • Ahead-of-time (AOT) compilation • Improved garbage collection • Improved diagnostic detail in exceptions and crash reports
13. Application Framework Activity Manager: Manages the activity life cycle of applications Content Providers: Manage the data sharing between applications Telephony Manager: Manages all voice calls. Location Manager: Location management, using GPS or cell tower Resource Manager: Manage the various types of resources we use in our Application
14. Application Layer • SMS client app • Dialer • Web browser • Contact manager
15. APK how it’s works
16. Android Application Security • Android sandbox • Permission labels defined in AndroidManifest.xml • Signature • Install time security decisions • Android 6.0 Security release
17. Android 6.0 • Runtime Permissions • Verified Boot • Hardware-Isolated Security • Fingerprints • SD Card Adoption • Clear Text Traffic • System Hardening • USB Access Control
18. Defense layers
19. Google Play 1 2 3 4 5 Require and validate Developer information Review Applications before distribution Permanently stop distribution Reduce attacker flexibility Remove applications after installation
20. Apps from Unknown Sources By default, only Google Play and other pre-installed app stores are allowed to install apps The vast majority of installs come from Google Play
21. Verify Apps Apps are verified prior to install Warn for or block Potentially Harmful Applications Over 10 million installs verified every day
22. Verifying is on and visible when need
23. Core security features to build secure applicaton • The Android Application Sandbox. • An application framework with robust implementations of common security functionality such as cryptography, permissions. • An encrypted file system that can be enabled to protect data on lost or stolen devices. • User-granted permissions to restrict access to system features and user data. • Application-defined permissions to control application data on a per-app basis.
24. Thank you  Any questions?
25. Links • http://developer.android.com/about/dashboards/index.html • https://docs.google.com/presentation/d/1YDYUrD22Xq12nKkhBfwoJBfw2Q- OReMr0BrDfHyfyPw/pub?start=false&loop=false&delayms=3000&slide=id.g1202bd8e5_0193 • http://www.cubrid.org/blog/dev-platform/android-at-a-glance/ • http://news.softpedia.com/news/Google-Introduces-Android-L-Developer-Preview-Material-Design-ART-64-Bit-Support-Volta-448367.shtml • http://developer.android.com/tools/building/index.html • http://android-anything.diandian.com/post/2011-09-28/5377936 • http://www.vogella.com/tutorials/Android/article.html#androiddevelopment_art • https://source.android.com/devices/tech/dalvik/index.html • https://en.wikipedia.org/wiki/Android_Runtime • https://source.android.com/devices/tech/dalvik/gc-debug.html • https://source.android.com/security/overview/app-security.html • http://www.javatpoint.com/internal-details-of-hello-android-example • https://decompileandsecureapk.wordpress.com/2014/05/10/decompile-and-secure-android-apk/ • http://developer.android.com/tools/debugging/debugging-memory.html#LogMessages • https://source.android.com/devices/ • http://www.cubrid.org/blog/dev-platform/android-at-a-glance/ • http://developer.android.com/training/articles/security-tips.html • https://developer.android.com/guide/topics/manifest/manifest-intro.html • https://source.android.com/security/overview/app-security.html • http://www.compiletimeerror.com/2012/12/blog-post.html#.VsReZ_krKM- • http://www.slideshare.net/Sperasoft/sperasoft-talks-android-security-threats?qid=d4d0db3a-0451-4150-95e0- dcd364cc95b4&v=qf1&b=&from_search=8 • http://www.eazytutz.com/android/android-architecture/ • http://www.tutorialspoint.com/android/android_architecture.htm
26. Application Components Security Alexander Antukh OWASP Poland 24.02.2016
27. Android Application Security Often the app contains some sensitive data: • Passwords • Authentication tokens • Contacts • Communication records • IP addresses or domain names to sensitive services
28. Android Application Security Global problems in securing the applications: • How sensitive data is stored – Isolation – Privilege separation • How sensitive data is transmitted – Extra-device communication – Inter-application communication – Inter-component communication
29. Android Application Components Activities Services Content providers Broadcast receivers
30. Android Application Components AndroidManifest.xml: defines in which way the app works and what kind of interaction between components and outer world is possible. Permissions are set there, too. • Activities – <activity> • Services – <service> • Content providers – <provider> • Broadcast receivers – <receiver>
31. Android Manifest Sample manifest file: Note the following: • Permissions <uses-permission android:name="string"/> <permission android:protectionLevel="…" /> • Components and their attributes
32. Android Manifest Protection levels: • dangerous – increased risk (directly affect users) • normal – minimal risk (default value) • signature – same certificate • signatureOrSystem – same certificate || app in Android system image
33. Android Manifest • debuggable • enabled • exported • permission Activities Services Content providers Broadcast receivers Example components attributes:
34. Intents An intent is a defined object used for messaging that is created and communicated to an intended application component. It includes all relevant information about calling application, desired application component and request actions/data Intent intent = new Intent(Intent.ACTION_VIEW); intent.setData(Uri.parse("http://www.google.com")); String pack = "com.android.browser"; ComponentName comp = new ComponentName(pack, pack + ".BrowserActivity"); intent.setComponent(comp); startActivity(intent);
35. Drozer Open source tool to interact with other applications through IPC - leading security assessment framework for Android. Manual on installation and usage
36. Drozer The best thing about Drozer: you don’t need to write your apps to interact with other apps :) dz> run app.activity.start --action android.intent.action.VIEW --data-uri http://www.google.com --component com.android.browser com.android.browser.BrowserActivity
37. Drozer Is installed in a default package of AppUse with adb, so enough just „click-and-play”
38. Activity components An Activity provides a screen with which users can interact in order to do something. Users can perform operations such as making a call, sending an SMS, etc. Example: login screen of your Facebook app. Activities
39. Activity components attacks • If an activity can be triggered by other apps (by an attacker), it can be abused! • Launching by intents, it’s possible to achieve the following: – Modify data in background – Tricking the user – Leaking sensitive information Activities
40. Activity components attacks • General hijacking scheme: • Results of an attack: – Malicious Activity could read the data in the Intent and then immediately relay it to a legitimate one – Spoofing the expected Activity’s user interface to steal user-supplied data (phishing) Activities
41. Activity components attacks Activities • List and launch exported activities dz> run app.activity.info -a com.mwr.example.sieve Package: com.mwr.example.sieve com.mwr.example.sieve.FileSelectActivity com.mwr.example.sieve.MainLoginActivity com.mwr.example.sieve.PWList dz> run app.activity.start --component com.mwr.example.sieve com.mwr.example.sieve.PWList
42. Activity components demo Activities
43. Services A Service can perform long-running operations in the background and does not provide a user interface. Other components can bind to a Service, which lets the binder invoke methods that are declared in the target Service’s interface. Intents are used to start and bind to Services Example: playing music or downloading a file. Services
44. Services attacks Although generally don’t seem dangerous, they could potentially perform sensitive operations. To attack a service one need interaction (it must be exported or respond/accept input from message formats like intents, files, or the network stack) Services
45. Services attacks Typical attacks: Denial of Service and Information Leakage • Find exported services • Launch them one-by-one with logcat to check for sensitive info • Fire off intents and wait for it! Services
46. Content providers A content provider presents data to external applications as one or more tables. In other words, content providers can be treated as interfaces that connect data in one process with code running in another process. Example: using content providers, any app can read SMS from inbuilt SMS app’s repository in our device. Content providers
47. Content providers • What info can they hold? – User’s phone numbers – Passwords – SMS • And one of the main problems are again permissions! run app.provider.info --permission null Content providers
48. Content providers attacks • Unrestricted access to app database – Just query it! * – run app.provider.query content://settings/secure • SQL injection • Path traversal * Other attack vectors on auth might include altering data e.g. by using app.provider.insert command Content providers dz> run scanner.provider.injection -a com.mwr.example.sieve
49. Content providers attacks • Unrestricted access to app database Content providers dz> run scanner.provider.finduris -a com.mwr.example.sieve ... Accessible content URIs: content://com.mwr.example.sieve.DBContentProvider/Keys/ content://com.mwr.example.sieve.DBContentProvider/Passwords content://com.mwr.example.sieve.DBContentProvider/Passwords/ dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --vertical
50. Content providers attacks • SQL injection Content providers dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --selection "'" unrecognized token: "')" (code 1): , while compiling: SELECT * FROM Passwords WHERE (') dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "* FROM Key;--" | Password | pin | | thisismypassword | 9876 |
51. Content providers attacks • Path traversal Content providers One interesting real-life example: http://blog.seguesec.com/2012/09/path-traversal-vulnerability-on-shazam-android-application/ dz> run app.provider.read content://com.mwr.example.sieve.FileBackupProvider/etc/hosts 127.0.0.1 localhost dz> run app.provider.download content://com.mwr.example.sieve.FileBackupProvider/data/data/com.mwr.e xample.sie ve/databases/database.db /home/user/database.db Written 24576 bytes
52. Content providers demo Content providers
53. Broadcast receivers A broadcast receiver is a component that responds to system-wide broadcast announcements such as Battery Low, boot completed, headset plug etc. Though most of the broadcast receivers are originated by the system, applications can also announce broadcasts. Broadcast receivers
54. Broadcast receivers • If receiver accepts broadcasts from untrusted sources, app is at risk Broadcast receivers
55. Broadcast receivers attacks Typical fail: authorization! • Enumerate receivers • Determine how the receiver handles the action • Send intent and enjoy Broadcast receivers
56. Broadcast receivers attacks <receiver android:name=".broadcastreceivers.SendSMSNowReceiver” android:label="Send SMS" > <intent-filter> <action android:name="org.owasp.goatdroid.fourgoats.SOCIAL_SMS" /> </intent-filter> </receiver> … <uses-permission android:name="android.permission.SEND_SMS" /> Sample manifest from GoatDroid: Broadcast receivers
57. Broadcast receivers attacks public void onReceive(Context arg0, Intent arg1) { context = arg0; SmsManager sms = SmsManager.getDefault(); Bundle bundle = arg1.getExtras(); sms.sendTextMessage(bundle.getString("phoneNumber"), null, bundle.getString("message"), null, null); Utils.makeToast(context, Constants.TEXT_MESSAGE_SENT, Toast.LENGTH_LONG); } The following is the code that determines how the receiver handles the org.owasp.goatdroid.fourgoats.SOCIAL_SMS actions: Broadcast receivers
58. Broadcast receivers attacks run app.broadcast.send --action org.owasp.goatdroid.fourgoats.SOCIAL_SMS --component org.owasp.goatdroid.fourgoats org.owasp.goatdroid.fourgoats.broadcastreceive rs.SendSMSNowReceiver --extra string phoneNumber 1234567890 --extra string message PWNED Broadcast receivers
59. General defenses for App Components Applies for all abovementioned items: • Setting "android:exported" attribute to "false" (only this user ID as the current app will be able to access the activity) • Limiting access with custom permissions for an activity (RECEIVE_SMS and others)
60. References • http://developer.android.com/guide/components/index.html • http://developer.android.com/guide/topics/manifest/manifest-intro.html • http://resources.infosecinstitute.com/android-hacking-security-part-1-exploiting-securing-application- components/ • http://resources.infosecinstitute.com/android-hacking-security-part-2-content-provider-leakage/ • http://resources.infosecinstitute.com/android-hacking-security-part-3-exploiting-broadcast-receivers/ • http://yinzhicao.org/courses/f15/cse343443/slides/mobilesecurity.pdf • https://www.safaribooksonline.com/library/view/android-security-cookbook • https://www.mwrinfosecurity.com/system/assets/937/original/mwri_drozer-user-guide_2015-03-23.pdf • https://manifestsecurity.com/android-application-security-part-5/ • https://manifestsecurity.com/android-application-security-part-8/ • https://www.eecs.berkeley.edu/~daw/papers/intents-mobisys11.pdf • http://blog.seguesec.com/2012/09/path-traversal-vulnerability-on-shazam-android-application/ • https://github.com/tanprathan/MobileApp-Pentest-Cheatsheet#android-application-penetration-testing
61. Thank you! • For additional questions or just to stay in touch: @c0rdis.
62. OWASP top 10 mobile risks Pawel Rzepa OWASP Poland 24.02.2016
63. Important notes • The goal of this presentation is to provide you a basic knowledge about mobile risks and easy methodology to find those risks in your applications. • If you want to add anything important/interesting and related to the topic – feel free to interrupt me ;).
64. What are we going to talk about…
65. Before we start… the threat model
66. M2 - Insecure data storage
67. Insecure data storage – what it is? • Simple words definition: valuable pieces of data (e.g. passwords, cookies, personal information) are stored in the data-stores on the device in insecure (plain text or reversable encoding) format.
68. Insecure data storage – what to look for? • Look for any sensitive information in: – SQLite databases (local) – XML Data Stores – Plain text configuration files – Cookie stores – SD Card
69. Insecure data storage – how to find? • Install and run application for some time • Monitor changes in /sdcard before and after installing an application • Analyze package files on different stages: adb pull /data/data/<apk_package_name>
70. Insecure data storage - demo
71. Insecure data storage – real example • Outlook stored all attachements as unencrypted and world readable files on external storage.
72. Insecure data storage - mitigations • Don’t store data unless it’s absolutely necessarry. • Use encryption for local storage (use method setStorageEncryption). • For databases consider using SQLcipher for Sqlite data encryption. • Ensure any shared preferences properties are NOT MODE_WORLD_READABLE.
73. M3 - Insufficient transport layer protection
74. Insufficient transport layer protection – what it is? • Simple words definition: application does NOT implement TLS or it does incorrectly.
75. What do you mean „incorrectly”? • Insecure implementations are: – Using known weak ciphers / version (e.g. SSLv2/SSLv3, RC4) – Securing only part of the communication (e.g. only authentication) – Lack of certificate inspection
76. Certificate inspection in web applications – chain of trust. • In web applications the validation of certificate is on the side of a browser. • It is done by a „chain of trust”. • But how a mobile app can know if it is communicating with a proper server?
77. Cert Pinning - theory • Embedded in source code expected X509 certificate or public key. if (presented_cert == pinned_cert) Start_connection(); else Drop_connection();
78. Cert Pinning - reality • Guys from Leibniz Universität Hannover tested 100 apps and… • 21 apps trust all certificates • 20 apps accept all hostnames • And in the end they asked developers why it happened… More: https://www.owasp.org/images/7/77/Hunting_Down_Broken_SSL_in_Android_Apps_-_Sascha_Fahl%2BMarian_Harbach%2BMathew_Smith.pdf
79. Insufficient transport layer protection- how to find? • Passive analysis with Wireshark/Burp (to check if all traffic is encrypted) • Use Mallodroid: ./mallodroid.py –f AppToCheck.apk –d ./javaout • Look for end point implementation flaws using SSLyze (or https://www.ssllabs.com/ssltest/ for public domain): sslyze --regular www.example.com:443
80. Insufficient transport layer protection- example
81. Insufficient transport layer protection- few facts from reality • According to the FireEye research from July 17 2014, among 1000 most-downloaded free applications in the Google Play store: Source: https://www.fireeye.com/blog/threat-research/2014/08/ssl-vulnerabilities-who-listens-when-android-applications-talk.html
82. Insufficient transport layer protection- mitigations • Any sensitive data MUST be transfered over TLS • How to do it properly? Follow the rules: https://www.owasp.org/index.php/Transport_Layer_Protectio n_Cheat_Sheet
83. M4 - Unintended data leakage
84. Unintended data leakage – what it is? • Simple word definition: OS/frameworks puts sensitive information in an insecure location in the device. • Important note: insecure data storage talks about developer conscious efforts to store data in insecure manner, while unintended data leakage refers to OS/framework specific quirks which can cause data leakages.
85. Unintended data leakage – common leakage points • URL Caching • Copy/Paste buffer Caching • Logging • Analytics data sent to 3rd parties (e.g. ads sending GPS location)
86. Unintended data leakage – how to find? • Extract data from leaking content providers using Drozer: dz> run app.provider.finduri <package_name> • Use logcat to verify what is being logged using ADB: adb logcat [output filter] • Use listener (Burp/Wireshark) to monitor what is being sent to 3rd parties. • Use Intent Sniffer to see if any confidential data is sent via Intents.
87. Unintended data leakage - demo
88. Unintended data leakage - mitigations • NEVER log any sensitive information (observe what you’re storing in crashlogs). • Disable copy/paste function for sensitive part of the application. • Disable debugging (android:debuggable="false").
89. M5 - Poor Authorization and Authentication
90. Poor Authorization and Authentication – what is it? • Simple words definition: if you’re able to bypass authentication and/or laverage your privileges then… your app has poor authorization and/or authentication.
91. Poor Authorization and Authentication – how to find? • Try to bypass authentication by accessing exported activities using Drozer: dz> run app.activity.start –component <component_name> • Intercept traffic with Burp and modify parameter to login as other user/see unauthorized content (e.g. by manipulating device ID). • Test account lockout policy • Test strong password policy
92. Poor Authorization and Authentication - demo
93. Poor Authorization and Authentication – real example • A flaw in application can become an entry point to compromise an operating system. • For example a Viber app: https://www.youtube.com/watch?time_continue=40&v=rScheIQDD0k
94. And always remember to… • …stay reasonable when you’re going to follow advices from the Internet…
95. Poor Authorization and Authentication - mitigations • Assume that client-side authorization and authentication controls can be bypassed - they must be re-enforced on the server-side whenever possible! • Persistent authentication (Remember Me) functionality implemented within mobile applications should never store a user’s password on the device. It should be optional and not be enabled by default.
96. M6 - Broken Cryptography
97. Broken Cryptography – what it is? • Simple words definition: using insecure implementation or implementing it in a insecure way. • Few reminders (yeah I know you know it…): – encoding != encryption – obfuscation != encryption
98. Broken Cryptography – how to find? • Decompile the apk using dex2jar (or luyten for more verbose result) and review jar file in JD-GUI. • Look for decryption keys (in attacker-readable folder or hardcoded within binary). • Try to break encryption algorithm if an application uses custom encryption. • Look for usage of insecure and/or deprecated algorithms (e.g. RC4, MD4/5, SHA1 etc.).
99. Broken Cryptography - example • Encrypted db is definitely a good idea…
100. Broken Cryptography - example • …but not when you’re hardcoding passwords to decrypt it in code…
101. Broken Cryptography – real example • NQ Vault
102. Broken Cryptography - mitigations • Use known, strong cryptography implementations. • Do not hardcode keys/credentials/OAUTH tokens. • Do not store keys on a device. Use password based encryption instead.
103. M7 - Client side injection
104. Client side injection – what it is? • Simple words definition: malicious code can be provided as an input and executed by the application (on the client side). • The malicious code can come from: – Other application via intent/content provider – Shared file – Server response – Third party website
105. Client side injection – what to inject? • SQL injection to local db • XSS/WebView injection • Directory traversal • Intent injection
106. A new Android’s toy – the Intents • Android application can talk (Inter-Process- Communication) to any other component (e.g. other application, system service, running new activity etc.) via special objects called Intents. Intent i = new Intent(Intent.ACTION_VIEW,Uri.parse(„https://owasp.org”)); Intent i = new Intent(android.provider.MediaStore.Action_IMAGE_CAPTURE);
107. Client side injection – how to find? • SQL injections: dz> run scanner.provider.injection –a <package_name> • Data path traversal dz> run scanner.provider.traversal –a <package_name> • Intent injections dz> run app.package.manifest –a <package_name> dz> run app.activity.info –a <package_name> dz> run app.service.info --permission null –a <package_name> dz> run intents.fuzzinozer --package_name <package_name> -- fuzzing_intent
108. Client side injection – real example • The UniversalMDMClient (built-in application Samsung KNOX – a security feature to seperate personal and professional activities). • Crafted URI with „smdm://” prefix allows for remote installation of ANY application, while a user thinks he’s installing an update for UniversalMDMClient. • How it works in practice? https://www.youtube.com/watch?time_continue=56&v=6O9OBmsv-CM
109. Client side injection - mitigations • Always validate on a server side any user input! • For internal communication use only explicit Intents. • Avoid using Intent-filter. Even if the Activity has atribute „exported=false” another application can define the same filter and a system displays a dialog, so the user can pick which app to use.
110. M9 - Improper session handling
111. Improper session handling – what it is? • Simple words definition: if your session token can be guessed, retrieved by third party or never expires then you have a problem.
112. Improper session handling – how to find? • Intercept requests with proxy (e.g. Burp) and verify if: – Verify if a session expires (copy a cookie and try to use it after 30 minutes) – Verify if a session is destroyed after authentication state changes (e.g. switching from any logged in user to another logged in user) – Verify if you are able to guess any other session (e.g. it’s easy to impersonate other user when application uses device ID as a session token).
113. Improper session handling – few facts from reality • What we know is that „sessions have to expire”… • …but how long should it REALLY last? • According to experiment* the average application session (counted from opening an app to closing it) lasts… 71.56 seconds. * - http://www.mendeley.com/research/falling-asleep-angry-birds-facebook-kindle-large-scale-study-mobile-application-usage/
114. Improper session handling - mitigations • Invalidate session on a server side. • Set session expiration time adjusted to your application. • Destroy all unused session tokens. • Use only high entropy, tested token generation resources.
115. Thank you! pawel.rzepa@outlook.com
116. References • https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks • https://github.com/ikust/hello-pinnedcerts • http://www.exploresecurity.com/testing-for-cipher-suite-preference/ • http://resources.infosecinstitute.com/android-hacking-security-part-4-exploiting-unintended-data-leakage-side-channel-data-leakage/ • http://www.slideshare.net/JackMannino/owasp-top-10-mobile-risks • https://manifestsecurity.com/android-application-security/ • https://mobilesecuritywiki.com/ • http://androidcracking.blogspot.de/2014/02/zerdeis-luyten-worthwhile-jd-gui.html • https://www.acsac.org/2011/openconf/modules/request.php?module=oc_program&action=view.php&a=&id=111&type=3&OPENCONF=54jm3hh7l aelc19qq6ernql5m2 • https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Mobile_Threat_Model • https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Security_Testing • https://www.owasp.org/images/7/77/Hunting_Down_Broken_SSL_in_Android_Apps_-_Sascha_Fahl%2BMarian_Harbach%2BMathew_Smith.pdf • https://www.ssllabs.com/ssltest/ • http://www.slideshare.net/ibmsecurity/overtaking-firefox-profiles-vulnerabilities-in-firefox-for-android • http://resources.infosecinstitute.com/cracking-nq-vault-step-by-step/ • http://www.slideshare.net/ibmsecurity/pinpointing-vulnerabilities-in-android-applications-like-finding-a-needle-in-a-haystack • https://github.com/linkedin/qark • https://www.mendeley.com/catalog/falling-asleep-angry-birds-facebook-kindle-large-scale-study-mobile-application-usage/ • http://blog.quarkslab.com/abusing-samsung-knox-to-remotely-install-a-malicious-application-story-of-a-half-patched-vulnerability.html • http://www.bkav.com/top-news/-/view_content/content/46264/critical-flaw-in-viber-allows-full-access-to-android-smartphones-bypassing-lock- screen • http://thehackernews.com/2014/05/microsoft-outlook-app-for-android.html • https://drive.google.com/file/d/0BxOPagp1jPHWVnlzWGNVbFBMTW8/view?pref=2&pli=1
117. Reverse Engineering & Malware Analysis Daniel Ramirez OWASP Poland 24.02.2016
118. Anatomy of an apk
119. Getting our apk file • From the phone – APKOptic – Astro File Manager • Using ADB • Use APKpure
120. Decompiling || Disassembling • Decompiling: – High Level – Java Code • Disassembling: – Low Level – Assembly Code • Why Disassembling and not Decompiling?
121. Decompiling DEX JAR JAVA JAR DEX JAVA
122. Decompiling-Dex2Jar • dex2jar – Converts Dalvik bytecode (DEX) to java bytecode (JAR) – Allows to use any existing Java decompiler with the resulting JAR file
123. Decompiling – Java Decompilers • JD-GUI || Luyten – Closed source Java decompiler – Combined with dex2jar, you can use JD-GUI or Luyten to decompile Android applications • Both are Java decompilers but have different OUTPUT!
124. JD-GUI
125. Luyten
127. Disassembling DEX SMALI
128. Disassembling • Apktool – Open source Java tool for reverse-engineering Android app – Transform binary Dalvik byte code(dex) into Smali source
129. Signing apk • Using signapk.jar java -jar signapk.jar certificate.pem key.pk8 your- app.apk your-app-signed.apk • Using AppUse
130. Demo Time
131. Demo Decompiling Luyten
132. Demo Modify Smali Files
133. Demo
134. Lack of binary protection • At this point if you can read the source code of the application, modify the behavior of the application  doesn’t have enough protection.
135. Techniques to mitigate the Lack of Binary Protection
136. Verify Sign
137. Obfuscated • Some obfuscation tool, allow to encrypt String in source code. – ProGuard(*) – DexProtector – DexGuard
138. Anti-Emulator
139. Debuggable
140. Demo Time #2
141. Demo
142. Demo Decompiling Luyten
143. Demo Modify Smali Files
144. Demo
145. Recap • We’ve seen how it’s possible change the behavior of an app by disassembling, modify the smali code and recompiling the app • Some techniques to “try” to prevent the lack of binary protection
146. MALWARE
147. Malware Statistics #1
148. Malware Statistics #2
149. Malware #1-Flappy-bird • Some application ask for permission that don’t need. • E.g: Game asking for send sms ??
150. Malware #1-Flappy-bird • Some application ask for permission that don’t need. • E.g: Game asking for send sms ??
151. Malware #2-iMatch
152. Permissions Dangerous #1
153. Permissions Dangerous #2
154. Dendroid botnet Botnet especially developed for attacking android user’s which has the functionalities like • Record call • Block SMS • Take video/photo • Send text • Send contacts • Get user account • Call Number • Update App • Delete files • Get browser history • Get call history • Get inbox SMS
155. Dendroid botnet -malware
156. Dendroid botnet - Manifest
157. Demo Time
158. DroidDream Malware • Steal sensitive data – IMEI –> block phone – IMSI – Device model – SDK
159. DroidDream example #1 - Paint • Access_coarse_location==GPS • Read_phone_state
160. DroidDream example #1.1
161. DroidDream example #2 – Hotgirls
162. How to Protect Yourself • Go to Settings → Security → Turn OFF "Allow installation from unknown sources" . • Always keep an up-to-date Anti-virus app • Avoid unknown and unsecured Wi-Fi hotspots
163. Summary • Obfuscate the code and mitigate the lack of binary protection using anti-emulator,etc. • Be aware of what permissions you’re giving to the application.
164. • danielramirezmartin@gmail.com
166. References • https://manifestsecurity.com/android-application-security/ • https://github.com/strazzere/anti-emulator • Book:The mobile hackers handbook • Book:Android Hackers Handbook • http://darkmatters.norsecorp.com/2015/07/15/how-to-reverse-engineer- android-applications/ • https://blog.netspi.com/attacking-android-applications-with-debuggers/ • http://briskinfosec.blogspot.co.uk/2014/07/apktool-for-android-security- test-in.html • https://decompileandsecureapk.wordpress.com/2014/05/10/decompile- and-secure-android-apk/ • http://hackerz-inn.blogspot.co.uk/2014/12/android-botnet-dendroid- step-by-step.html