Android security workshop OWASP Poland 24.02.2016

Agenda  Android fundamentals  Application components security  Coffee break (free cookies )  OWASP top 10 mobile risks  Reverse engineering & malware analysis

Android fundamentals Andrii Sygida OWASP Poland 24.02.2016

Agenda • Android Architecture • Android security fundamentals • Android 6.0 security release • Google security features

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

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

Android Architecture

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.

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

Android Runtime • Core libraries • Dalvik Virtual Machine • DVM vs JVM Differences • ART

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

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

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

Application Layer • SMS client app • Dialer • Web browser • Contact manager

APK how it’s works

Android Application Security • Android sandbox • Permission labels defined in AndroidManifest.xml • Signature • Install time security decisions • Android 6.0 Security release

Android 6.0 • Runtime Permissions • Verified Boot • Hardware-Isolated Security • Fingerprints • SD Card Adoption • Clear Text Traffic • System Hardening • USB Access Control

Defense layers

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

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

Verify Apps Apps are verified prior to install Warn for or block Potentially Harmful Applications Over 10 million installs verified every day

Verifying is on and visible when need

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.

Thank you  Any questions?

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

Application Components Security Alexander Antukh OWASP Poland 24.02.2016

Android Application Security Often the app contains some sensitive data: • Passwords • Authentication tokens • Contacts • Communication records • IP addresses or domain names to sensitive services

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

Android Application Components Activities Services Content providers Broadcast receivers

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 – • Services – • Content providers – • Broadcast receivers –

Android Manifest Sample manifest file: Note the following: • Permissions • Components and their attributes

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

Android Manifest • debuggable • enabled • exported • permission Activities Services Content providers Broadcast receivers Example components attributes:

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);

Drozer Open source tool to interact with other applications through IPC - leading security assessment framework for Android. Manual on installation and usage

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

Drozer Is installed in a default package of AppUse with adb, so enough just „click-and-play”

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

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

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

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

Activity components demo Activities

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

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

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

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

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

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

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

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 |

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

Content providers demo Content providers

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

Broadcast receivers • If receiver accepts broadcasts from untrusted sources, app is at risk Broadcast receivers

Broadcast receivers attacks Typical fail: authorization! • Enumerate receivers • Determine how the receiver handles the action • Send intent and enjoy Broadcast receivers

Broadcast receivers attacks … Sample manifest from GoatDroid: Broadcast receivers

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

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

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)

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

Thank you! • For additional questions or just to stay in touch: @c0rdis.

OWASP top 10 mobile risks Pawel Rzepa OWASP Poland 24.02.2016

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 ;).

What are we going to talk about…

Before we start… the threat model

M2 - Insecure data storage

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.

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

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/

Insecure data storage - demo

Insecure data storage – real example • Outlook stored all attachements as unencrypted and world readable files on external storage.

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.

M3 - Insufficient transport layer protection

Insufficient transport layer protection – what it is? • Simple words definition: application does NOT implement TLS or it does incorrectly.

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

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?

Cert Pinning - theory • Embedded in source code expected X509 certificate or public key. if (presented_cert == pinned_cert) Start_connection(); else Drop_connection();

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

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

Insufficient transport layer protection- example

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

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

M4 - Unintended data leakage

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.

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)

Unintended data leakage – how to find? • Extract data from leaking content providers using Drozer: dz> run app.provider.finduri • 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.

Unintended data leakage - demo

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").

M5 - Poor Authorization and Authentication

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.

Poor Authorization and Authentication – how to find? • Try to bypass authentication by accessing exported activities using Drozer: dz> run app.activity.start –component • 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

Poor Authorization and Authentication - demo

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

And always remember to… • …stay reasonable when you’re going to follow advices from the Internet…

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.

M6 - Broken Cryptography

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

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.).

Broken Cryptography - example • Encrypted db is definitely a good idea…

Broken Cryptography - example • …but not when you’re hardcoding passwords to decrypt it in code…

Broken Cryptography – real example • NQ Vault

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.

M7 - Client side injection

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

Client side injection – what to inject? • SQL injection to local db • XSS/WebView injection • Directory traversal • Intent injection

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);

Client side injection – how to find? • SQL injections: dz> run scanner.provider.injection –a • Data path traversal dz> run scanner.provider.traversal –a • Intent injections dz> run app.package.manifest –a dz> run app.activity.info –a dz> run app.service.info --permission null –a dz> run intents.fuzzinozer --package_name -- fuzzing_intent

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

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.

M9 - Improper session handling

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.

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).

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/

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.

Thank you! [email protected]

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

Reverse Engineering & Malware Analysis Daniel Ramirez OWASP Poland 24.02.2016

Anatomy of an apk

Getting our apk file • From the phone – APKOptic – Astro File Manager • Using ADB • Use APKpure

Decompiling || Disassembling • Decompiling: – High Level – Java Code • Disassembling: – Low Level – Assembly Code • Why Disassembling and not Decompiling?

Decompiling DEX JAR JAVA JAR DEX JAVA

Decompiling-Dex2Jar • dex2jar – Converts Dalvik bytecode (DEX) to java bytecode (JAR) – Allows to use any existing Java decompiler with the resulting JAR file

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!

JD-GUI

Luyten

No content

Disassembling DEX SMALI

Disassembling • Apktool – Open source Java tool for reverse-engineering Android app – Transform binary Dalvik byte code(dex) into Smali source

Signing apk • Using signapk.jar java -jar signapk.jar certificate.pem key.pk8 your- app.apk your-app-signed.apk • Using AppUse

Demo Time

Demo Decompiling Luyten

Demo Modify Smali Files

Demo

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.

Techniques to mitigate the Lack of Binary Protection

Verify Sign

Obfuscated • Some obfuscation tool, allow to encrypt String in source code. – ProGuard(*) – DexProtector – DexGuard

Anti-Emulator

Debuggable

Demo Time #2

Demo

Demo Decompiling Luyten

Demo Modify Smali Files

Demo

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

MALWARE

Malware Statistics #1

Malware Statistics #2

Malware #1-Flappy-bird • Some application ask for permission that don’t need. • E.g: Game asking for send sms ??

Malware #1-Flappy-bird • Some application ask for permission that don’t need. • E.g: Game asking for send sms ??

Malware #2-iMatch

Permissions Dangerous #1

Permissions Dangerous #2

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

Dendroid botnet -malware

Dendroid botnet - Manifest

Demo Time

DroidDream Malware • Steal sensitive data – IMEI –> block phone – IMSI – Device model – SDK

DroidDream example #1 - Paint • Access_coarse_location==GPS • Read_phone_state

DroidDream example #1.1

DroidDream example #2 – Hotgirls

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

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.

• [email protected]

No content

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