[Wroclaw #1] Android Security Workshop

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

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

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

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.

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

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

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 – <activity>
• Services – <service>
• Content providers – <provider>
• Broadcast receivers – <receiver>

Android Manifest
Sample manifest file:
Note the following:
• Permissions
<uses-permission android:name="string"/>
<permission android:protectionLevel="…" />
• 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

• 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

• SQL injection
Content
providers
content://com.mwr.example.sieve.DBContentProvider/Passwords/ --selection "'"
unrecognized token: "')" (code 1): , while compiling: SELECT * FROM Passwords
WHERE (')
content://com.mwr.example.sieve.DBContentProvider/Passwords/ --projection "*
FROM Key;--"
| Password | pin |
| thisismypassword | 9876 |

• 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

<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

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

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

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/<apk_package_name>

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

example

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

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

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

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.

– 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

- demo

– 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…

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

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.

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

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!
pawel.rzepa@outlook.com

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

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 DEXJAVA

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!

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

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

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

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 #1-Flappy-bird
• Some application ask for permission that don’t
need.
• E.g: Game asking for send sms ??

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

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

• danielramirezmartin@gmail.com

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

[Wroclaw #1] Android Security Workshop

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (16)

Similar a [Wroclaw #1] Android Security Workshop

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

Más de OWASP

Más de OWASP (20)

Último

Último (17)

[Wroclaw #1] Android Security Workshop

Notas del editor