O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

[Wroclaw #1] Android Security Workshop

Carregando em…3

Confira estes a seguir

1 de 166 Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Quem viu também gostou (16)


Semelhante a [Wroclaw #1] Android Security Workshop (20)

Mais de OWASP (20)


Mais recentes (20)

[Wroclaw #1] Android Security Workshop

  1. 1. Android security workshop OWASP Poland 24.02.2016
  2. 2. Agenda  Android fundamentals  Application components security  Coffee break (free cookies )  OWASP top 10 mobile risks  Reverse engineering & malware analysis
  3. 3. Android fundamentals Andrii Sygida OWASP Poland 24.02.2016
  4. 4. Agenda • Android Architecture • Android security fundamentals • Android 6.0 security release • Google security features
  5. 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. 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. 7. Android Architecture
  8. 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. 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. 10. Android Runtime • Core libraries • Dalvik Virtual Machine • DVM vs JVM Differences • ART
  11. 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. 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. 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. 14. Application Layer • SMS client app • Dialer • Web browser • Contact manager
  15. 15. APK how it’s works
  16. 16. Android Application Security • Android sandbox • Permission labels defined in AndroidManifest.xml • Signature • Install time security decisions • Android 6.0 Security release
  17. 17. Android 6.0 • Runtime Permissions • Verified Boot • Hardware-Isolated Security • Fingerprints • SD Card Adoption • Clear Text Traffic • System Hardening • USB Access Control
  18. 18. Defense layers
  19. 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. 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. 21. Verify Apps Apps are verified prior to install Warn for or block Potentially Harmful Applications Over 10 million installs verified every day
  22. 22. Verifying is on and visible when need
  23. 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. 24. Thank you  Any questions?
  25. 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. 26. Application Components Security Alexander Antukh OWASP Poland 24.02.2016
  27. 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. 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. 29. Android Application Components Activities Services Content providers Broadcast receivers
  30. 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. 31. Android Manifest Sample manifest file: Note the following: • Permissions <uses-permission android:name="string"/> <permission android:protectionLevel="…" /> • Components and their attributes
  32. 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. 33. Android Manifest • debuggable • enabled • exported • permission Activities Services Content providers Broadcast receivers Example components attributes:
  34. 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. 35. Drozer Open source tool to interact with other applications through IPC - leading security assessment framework for Android. Manual on installation and usage
  36. 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. 37. Drozer Is installed in a default package of AppUse with adb, so enough just „click-and-play”
  38. 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. 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. 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. 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. 42. Activity components demo Activities
  43. 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. 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. 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. 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. 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. 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. 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. 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. 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 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. 52. Content providers demo Content providers
  53. 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. 54. Broadcast receivers • If receiver accepts broadcasts from untrusted sources, app is at risk Broadcast receivers
  55. 55. Broadcast receivers attacks Typical fail: authorization! • Enumerate receivers • Determine how the receiver handles the action • Send intent and enjoy Broadcast receivers
  56. 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. 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. 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. 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. 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. 61. Thank you! • For additional questions or just to stay in touch: @c0rdis.
  62. 62. OWASP top 10 mobile risks Pawel Rzepa OWASP Poland 24.02.2016
  63. 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. 64. What are we going to talk about…
  65. 65. Before we start… the threat model
  66. 66. M2 - Insecure data storage
  67. 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. 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. 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. 70. Insecure data storage - demo
  71. 71. Insecure data storage – real example • Outlook stored all attachements as unencrypted and world readable files on external storage.
  72. 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. 73. M3 - Insufficient transport layer protection
  74. 74. Insufficient transport layer protection – what it is? • Simple words definition: application does NOT implement TLS or it does incorrectly.
  75. 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. 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. 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. 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. 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. 80. Insufficient transport layer protection- example
  81. 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. 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. 83. M4 - Unintended data leakage
  84. 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. 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. 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. 87. Unintended data leakage - demo
  88. 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. 89. M5 - Poor Authorization and Authentication
  90. 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. 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. 92. Poor Authorization and Authentication - demo
  93. 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. 94. And always remember to… • …stay reasonable when you’re going to follow advices from the Internet…
  95. 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. 96. M6 - Broken Cryptography
  97. 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. 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. 99. Broken Cryptography - example • Encrypted db is definitely a good idea…
  100. 100. Broken Cryptography - example • …but not when you’re hardcoding passwords to decrypt it in code…
  101. 101. Broken Cryptography – real example • NQ Vault
  102. 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. 103. M7 - Client side injection
  104. 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. 105. Client side injection – what to inject? • SQL injection to local db • XSS/WebView injection • Directory traversal • Intent injection
  106. 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. 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. 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. 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. 110. M9 - Improper session handling
  111. 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. 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. 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. 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. 115. Thank you! pawel.rzepa@outlook.com
  116. 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. 117. Reverse Engineering & Malware Analysis Daniel Ramirez OWASP Poland 24.02.2016
  118. 118. Anatomy of an apk
  119. 119. Getting our apk file • From the phone – APKOptic – Astro File Manager • Using ADB • Use APKpure
  120. 120. Decompiling || Disassembling • Decompiling: – High Level – Java Code • Disassembling: – Low Level – Assembly Code • Why Disassembling and not Decompiling?
  121. 121. Decompiling DEX JAR JAVA JAR DEXJAVA
  122. 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. 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. 124. JD-GUI
  125. 125. Luyten
  126. 126. Disassembling DEX SMALI
  127. 127. Disassembling • Apktool – Open source Java tool for reverse-engineering Android app – Transform binary Dalvik byte code(dex) into Smali source
  128. 128. Signing apk • Using signapk.jar java -jar signapk.jar certificate.pem key.pk8 your- app.apk your-app-signed.apk • Using AppUse
  129. 129. Demo Time
  130. 130. Demo Decompiling Luyten
  131. 131. Demo Modify Smali Files
  132. 132. Demo
  133. 133. 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.
  134. 134. Techniques to mitigate the Lack of Binary Protection
  135. 135. Verify Sign
  136. 136. Obfuscated • Some obfuscation tool, allow to encrypt String in source code. – ProGuard(*) – DexProtector – DexGuard
  137. 137. Anti-Emulator
  138. 138. Debuggable
  139. 139. Demo Time #2
  140. 140. Demo
  141. 141. Demo Decompiling Luyten
  142. 142. Demo Modify Smali Files
  143. 143. Demo
  144. 144. 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
  145. 145. MALWARE
  146. 146. Malware Statistics #1
  147. 147. Malware Statistics #2
  148. 148. Malware #1-Flappy-bird • Some application ask for permission that don’t need. • E.g: Game asking for send sms ??
  149. 149. Malware #1-Flappy-bird • Some application ask for permission that don’t need. • E.g: Game asking for send sms ??
  150. 150. Malware #2-iMatch
  151. 151. Permissions Dangerous #1
  152. 152. Permissions Dangerous #2
  153. 153. 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
  154. 154. Dendroid botnet -malware
  155. 155. Dendroid botnet - Manifest
  156. 156. Demo Time
  157. 157. DroidDream Malware • Steal sensitive data – IMEI –> block phone – IMSI – Device model – SDK
  158. 158. DroidDream example #1 - Paint • Access_coarse_location==GPS • Read_phone_state
  159. 159. DroidDream example #1.1
  160. 160. DroidDream example #2 – Hotgirls
  161. 161. 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
  162. 162. 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.
  163. 163. • danielramirezmartin@gmail.com
  164. 164. 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

Notas do Editor

  • Google has introduced a new virtual machine known as ART ( Android Runtime).

    Until version 5.0, Android used Dalvik as a process virtual machine with trace-based just-in-time (JIT) compilation to run Dalvik "dex-code" (Dalvik Executable), which is usually translated from the Java bytecode. Following the trace-based JIT principle, Dalvik performs the compilation each time an application is launched. Android 4.4 introduced Android Runtime (ART) бwhich uses ahead-of-time (AOT) compilation to entirely compile the application bytecode into machine code upon the installation of an application.

    ART introduces ahead-of-time (AOT) compilation, which can improve app performance.
    At install time, ART compiles apps using the on-device dex2oat tool. This utility accepts DEX files as input and generates a compiled app executable for the target device.
    This results in approx. 30% larger compile code, but allows faster execution from the beginning of the application.
    This also saves battery life, as the compilation is only done once, during the first start of the application.
    The garbage collection in ART has been optimized to reduce times in which the application freezes.
    Improved diagnostic detail in exceptions and crash reports
    This means that Android L will run exclusively on ART compiler, which translates into double the performance of Dalvik's when it comes to running apps, more efficient RAM usage and support for 64-bit.
    The 64-bit support means that handset makers can now fit in 4GB of RAM inside a smartphone, but that also means compatibility with new ARM instructions, basically a lot more power.

    Each time an application needed memory to be allocated and the heap (a space of memory dedicated to that app) would not be able to accommodate that allocation, the GC would fire up. Garbage collection - Availability of JVM, which automatically takes care of unused objects, making development easier and shortens debug time. If you have never written on these languages, then take with and try to write a program, and feel how valuable that is provided by your language for free.

    Improve Garbage collection
    Garbage collection (GC) can impair an app's performance, resulting in choppy display, poor UI responsiveness, and other problems. ART improves garbage collection in several ways:
    One GC pause instead of two
    Parallelized processing during the remaining GC pause
    Collector with lower total GC time for the special case of cleaning up recently-allocated, short-lived objects
    Improved garbage collection ergonomics, making concurrent garbage collections more timely.
    Compacting GC to reduce background memory usage and fragmentation

    Improved diagnostic detail in exceptions and crash reports
    ART gives you as much context and detail as possible when runtime exceptions occur. ART provides expanded exception detail for java.lang.ClassCastException, java.lang.ClassNotFoundException, andjava.lang.NullPointerException. (Later versions of Dalvik provided expanded exception detail forjava.lang.ArrayIndexOutOfBoundsException and java.lang.ArrayStoreException, which now include the size of the array and the out-of-bounds offset, and ART does this as well.)

    ART Clarify

    This means that Android L will run exclusively on ART compiler, which translates into double the performance of Dalvik's when it comes to running apps, more efficient RAM usage and support for 64-bit.
    The 64-bit support means that handset makers can now fit in 4GB of RAM inside a smartphone, but that also means compatibility with new ARM instructions, basically a lot more power.