Android Penetration testing - Day 2

Agenda for
today’s
session
Automating Static analysis with
MOBSF Framework
Reverse Engineering the Android
APK file
Manual static analysis & Secure
code review in Android

Intro to
MOBSf
framework
• Mobile Security Framework (MobSF) is an automated, open
source, all-in-one mobile application (Android/iOS/Windows) pen-
testing framework capable of performing static, dynamic and
malware analysis.
• It is suggested by OWASP MSTG for static analysis of security in
mobile applications.
• It can be used for effective and fast security analysis of Android, iOS
and Windows mobile applications and support both binaries (APK,
IPA & APPX ) and zipped source code.
• MobSF can do dynamic application testing at runtime for Android
apps and has Web API fuzzing capabilities powered by CapFuzz, a
Web API specific security scanner.
• MobSF is designed to make your CI/CD or DevSecOps pipeline
integration seamless.
• It has a graphic UI in the form of web service. Web service consist
of a dashboard that presents the results of the analysis, its own
documentation site, an integrated emulator & an API that allows
users to trigger the analysis automatically.
• It is hosted on a local environment, so sensitive data never
interacts with the cloud.

How MOBSF works ?
In static analysis application is
tested from the inside out.
It analyses the source code or
binary without executing the
application.
It does not rely on runtime
environment.
It can be used to test code
during development, caching
vulnerabilities early on.
Static analysis security testing
tools must be run on the
application on a regular basis,
such as during daily/monthly
builds, every time code is
checked in, or a code release.

Requirements
for MOBSF
• Python 3.6+ — Python 3.6 Download
• Oracle JDK 1.7 or above — Java JDK Download
• Mac OS Users must install Command-line tools —
How to Install Command line Tools in Mac
• iOS IPA Analysis works only on Mac and Linux.
• Windows App Static analysis requires a Windows
Host or Windows VM for Mac and Linux. For
Windows App Static Analysis, Read Windows App
Static Analysis
NOTE:
• On Linux and Mac, install Oracle Java 1.7 or above
and make it the default one.
• On Linux, make sure you have 32 bit execution
support enabled.

MOBSF Installation – Part 1
1. Configuring static analyzer
Run following commands :
• git clone https://github.com/MobSF/Mobile-Security-Framework-
MobSF.git
• cd Mobile-Security-Framework-MobSF

We need to install dependencies before we are able to run:
• apt-get install python3-venv
• pip3 install -r requirements.txt

• Once done, we can run the setup file to install MobSF and all the
components automatically

MOBSF Interface
• Visit http://0.0.0.0:8000 in browser to access the mobsf interface

Decoding the
MOBSF
Components
1) Information
• Display data such as app icon, app name, size, package
name etc.MD5 & SHA1 are also shown. They can be useful
to detect known malicious applications.

2) Scan options
• Rescan the application
• Start the dynamic analysis
• Check the source, smali files,
java code & the manifest file

3) Signer Certificate Analysis
• In the certificate column, we
can see the signer certificate
where one can find important
information about the
developer, country, state,
type of algo, bit size etc.

4) Application Permissions
• There are various permissions that are
categorized as dangerous or normal.
• It is important from a security analyst’s
point of view to understand which
permissions can lead to further
damage.
• For example, if an application has access
to external media and stores critical
information on the external media it
could prove to be dangerous since the
files stored on external media are
globally readable and writable

5) Browsable Activities
• We can see all the activities that have
implemented a deep link schema.
• To understand all about deep links, its
implementation as well as exploitation.
• https://www.hackingarticles.in/and
roid-pentest-deep-link-
exploitation/

6) Network Security
Analysis
• In the network security section, one can find some details
about network security issues related to the application.
These issues can lead to critical attacks like MiTM sometimes.
• For Example: One can find that the application isn’t using the
SSL pinning mechanism implemented.

7) Manifest Analysis
• One can find many folds of
information from the android
manifest file like which activities are
exported, if the app debuggable or
not, data schemas etc.

8) Code Analysis
• We can see that MobSF has analysed and
compared some behaviour of the
application based on industry security
standard practices like OWASP MSTG and
mapped the vulnerabilities with OWASP
Top 10.
• It is interesting to see CWE mentioned and
CVSS score being assigned here which
might help various analyst scenarios and
help the creation of reports way easier.

9) Malware Analysis
• MobSF also hosts a section where
an APKiD analysis is given.
• APKiD is an open-source tool that
is very helpful to identify various
packers, compilers, obfuscators
etc in android files. It is analogous
to PEiD in APK.

9) Malware Analysis
(Contd.)
• Something related to malware analysis is the domain
malware check feature. Here, MobSF is extracting all the
URLs/IP addresses that are hard-coded or being used in the
application and shows its malware status as well as uses
ip2location to give out its geolocation as well.

10) Strings
• Strings are ASCII and Unicode-
printable sequences of
characters embedded within a
file. Extracting strings can give
clues about the program
functionality and indicators
associated with a suspect
binary.
• Many times, a third party IP
address with which APK is
communicating gets visible here,
sometime hardcoded
credentials too.

11) Emails
• One can also find hardcoded emails in
MobSF. This is all done using the decompiled
source code. Often a pentester can find
critical email IDs that were being used as a
credential on a third party site, say, to
access the database.

12) URLs
• Just like emails, URLs are often found hardcoded as well.
One can find juicy URLs that are being used sometimes.
Oftentimes analysts find malicious URLs being accessed as
well or even a C&C server.

13) Hardcoded
secrets
• Oftentimes developers have this habit of storing critical keys
like AWS ID and credentials in strings.xml and use an object
as a reference in java activity. But doing this doesn’t help in
any which way since strings.xml can be decoded easily.

14) Activity
Components Present
• A list of all the activities present can also be
scrolled using MobSF

15) Other
components
in Mobile
App

Downloading Mobsf reports
• Once you have done the analysis, it is possible to download the
report by sliding the menu bar slider on the left-hand side and click
generate the report.

Dependency for report download
• You might notice some errors while generating reports. To resolve
this, you can follow the below command and install wkhtmltopdf
module:
• apt-get install wkhtmltopdf

Pre-Requirements
• Application we goanna use for Reverse engineering & Manual static analysis is PIVAA
(Purposefully Insecure and Vulnerable Android Application)
Tools Used:
• ADB (Android Debug bridge)
• Drozer
• Genymotion
• Kali linux VM or other VMs
• Logcat
• APKTool & Jadx
• Hashcat
• Keytool & jarsigner
• dex2jar

Reverse
engineering the
Android APK File

ADB (Android Debug Bridge)
• Android Debug Bridge (adb) is a versatile command-line tool that lets
you communicate with a device.
• The adb command facilitates a variety of device actions, such as
installing and debugging apps, and it provides access to a Unix shell
that you can use to run a variety of commands on a device.
• adb is included in the Android SDK Platform-Tools package.
sudo apt-get install android-tools-adb
Adb can be connected:
• Via Usb cable; Enable usb debugging
• Via Wi-Fi : enabled wireless debugging

Usage of ADB with various Components

Using Jadx to decompile an APK

APKTool for Decompilation & APK rebuilding
• A tool for reverse engineering Android Apk files

Convert Dex files to java files.
If you wish to decompile any java files, you can do the following:
# Convert the Dex files into standard class files
• dex2jar application/classes.dex
# Now use the JD (Java Decompiler) to inspect the source
• jd-gui classes-dex2jar.jar
• You can do the changes in java classes or manifest files

Rebuilding the Apk file
# To recompile(build) the apk
• apktool b -f -d application
Or
• Apktool b application
• After recompiling (building) the apk the new apk will be generated in Dist
folder.
• Application — Dist- application.apk

Creating keys & Signing the APK file
• The APK must be signed before you run on your device.
• Before signing an apk, create a key if you don’t have an existing one. If
prompted for a password, create your own password.
# To generate a key.
• keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg
RSA -keysize 2048 -validity 10000
Now sign the APK with the key:
# Sign the apk
• jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-
key.keystore my_application.apk alias_name
# Verify apk
• jarsigner -verify -verbose -certs my_application.apk

Manual static Analysis & Secure code
review in Android

Following code level Vulnerabilities will be
covered in the upcoming slides
• Cleartext SQLite database
• User-supplied input in SQL queries
• Exported Content Providers with Insufficient Protection
• Enabled Application Backup
• Information Disclosure through Logging
• Storing Sensitive Data in External Storage
• Weak Hashing Algorithms
• Predictable Random Number Generators (PRNG)
• Weak Encryption Implementation (AES-ECB)
• Weak Initialization Vectors (IV) (AES-CBC)
• Hard-coded Data
• Enabled Debug Mode
• Exported Broadcast Receivers
• Exported Services

1) Cleartext SQLite database
• The PIVAA application stores data in an unencrypted SQLite database.
• Vulnerability: A malicious user or application with root privileges can
access this file and view potentially sensitive contents.
• Performing static analysis on the PIVAA Java source code recovered by
MobSF, we found a file called “DatabaseHelper.java” and We can see
that the application uses an SQLite database called “pivaaDB”.

Recommendations
• Use the SQLCipher library to password-encrypt the SQLite database.
• Ensure the password used to encrypt the database is not hard coded
or stored insecurely on the filesystem (e.g. shared preferences, etc.).
• An example of how the password can be retrieved to decrypt the
SQLite database file is by requiring the user to enter a password or
pin when the application is opened.

2) User-supplied input in SQL queries
• The PIVAA application allows user-supplied input in SQL queries.
• Vulnerability: User-supplied input into SQL queries can potentially
lead to a local SQL injection vulnerability in the mobile application.
• You can interact with the “pivaaDB” database mentioned earlier by
using the application and inputting SQL queries.

User-supplied input in SQL queries (Contd.)
• The query is being executed by the rawSQL method available in
SQLitedatabase class & no sanitization is being performed

Recommendations:
• Use SQL Prepared statements, which implement a pre-compiled SQL
query and parameters that act as placeholders for user input which
are required before the SQL query can be executed. This treats user
input as data and not as commands, e.g.:
# SQL Prepared Statement Example
• db.rawQuery("select * from " + DATABASE_TABLE + " where " + "username=?
and password=?", new String [] {loginUsername, loginpass})
• Try to sanitize input from users where possible and appropriate,
• e.g. if you are expecting an integer as input, then you can validate for integers
only.

3) Exported Content Providers with
Insufficient Protection
• The PIVAA application has implemented an exported content
provider with insufficient protections.
• Content providers are used to share app data with other
applications, which is normally stored inside a database or file.
Vulnerability: Insufficient protections for exported content providers
can lead to security issues such as information disclosure.
• Looking at the AndroidManifest.xml file for the PIVAA application, we
can see the content provider that has been exported.

Recommendations:
• Implement basic access control with the “android:permission”
attribute in the AndroidManifest.xml file. N.B. this defines both read
and write permissions to the content provider.
• Implement principle of least privilege with separate
“android:readPermission” and “android:writePermission” attributes
in the AndroidManifest.xml file to specify what apps can read and
write to the content provider.
• Following the principle of least privilege, the “<path-permission>”
element can be implemented in the AndroidManifest.xml file to
control access to subsets of data.

4) Enabled Application Backup
• The PIVAA application has the “android:allowBackup” attribute set to
true in the AndroidManifest.xml file.
• Vulnerability: Creating backups of an application may lead to
sensitive information disclosure.
• I can use the ADB “backup” command to create a backup of the
“com.htbridge.pivaa” package. Depending on the Android OS version
you have, you may be prompted for a password that will be needed
later to unpack the backup file.

Recommendations:
• Set the “android:allowBackup” attribute to false to disable backups.
• If the “allowBackup” attribute in the manifest file is not set, then by
default a backup of the apps data can be made.

5) Information Disclosure through Logging
• The PIVAA application produces log messages when performing a lot
of tasks.
• Vulnerability: Logging sensitive data may expose the data to attackers
or malicious applications, and it violates user confidentiality.
Recommendations:
• Use tools like ProGuard (included in Android Studio).
• ProGuard is a free Java class file shrinker, optimizer, obfuscator, and
preverifier.
• It detects and removes unused classes, fields, methods, and
attributes and can also be used to delete logging-related code.

6) Storing Sensitive Data in External Storage
• The PIVAA application stores sensitive data on a external SD card.
• Vulnerability: Files saved to external storage are world-readable and
can be modified.
Recommendations:
• Do not store sensitive data in external storage.
• Store sensitive data and files in internal storage. Files saved to
internal storage are by default private to your application; neither the
user nor other applications can access them. When users uninstall
your application, these files are removed.

7) Weak Hashing Algorithms
• The PIVAA application provides a feature that allows users to hash any
string they enter using the MD5 hashing algorithm.
• Vulnerability: MD5 hashing algorithm should not be used when
reliable hashing of data is required.
Recommendations:
• Use stronger hash algorithm's such as SHA-256, SHA-3, bcrypt ,
scrypt ,etc. when reliable hashing is required.
• Make sure to salt password hashes, which is an additional input of
data that helps to safeguard passwords in storage.

8) Predictable Random Number Generator
(PRNG)
• The PIVAA application uses the Random Java class to generate
pseudorandom numbers:
• java.util.Random
• Vulnerability: The numbers generated by this class are not random
and can be predictable.

Recommendations:
• Use a cryptographically strong random number generator (RNG) like
“java.security.SecureRandom” in place of this PRNG when a
cryptographically strong random number needs to be used.
• Use the generated random values only once.
• You should not expose the generated random value.
• If you have to store it, make sure that the database or file is secure.

9) Weak Encryption Implementation
• The PIVAA application implements AES encryption with Electronic Code
Book mode.
• Vulnerability: “AES/ECB/PKCS5Padding” has been proven to be insecure.
Recommendations:
• Do not use ECB mode for cryptographic operations. Use the code below
instead for cryptographic operations:
• Cipher cipher = Cipher.getInstance("AES/CFB/PKCS5Padding");
• Be aware that the code below will default to ECB mode, even if it is not
specified:
• Cipher cipher = Cipher.getInstance("AES");

10) Usage of Weak Initialization Vector
• The PIVAA application implements AES encryption with Cipher Block
Chaining (CBC) mode but uses a predictable initialization vector (IV).
• Vulnerability: Predictable IVs can be exploited by chosen plain text
attack.

Recommendations:
• Initialization Vector should be unpredictable.
• Initialization Vector should be Random.
• Initialization Vector should not be hard coded.
• Initialization Vector should be created using
java.security.SecureRandom rather than java.util.Random .

11) Hard-coded Data
• The PIVAA application contains sensitive hard-coded data.
• Vulnerability: Sensitive data hard-coded into an applications code can
be easily retrieved by malicious users and used to perform other
attacks.

Recommendations:
• Store sensitive data in a external file located in a secure directory
from where it can be retrieved.
• Use the Android KeyStore to securely store cryptographic keys.

12) Enabled Debug Mode
• The PIVAA application has debug mode enabled.
• Vulnerability: Debug mode should be disabled in production build
applications because it can expose technical information and facilitate
reverse engineering.

Recommendations:
• For Android applications, make sure the “android:debuggable”
attribute is set to false in the AndroidManifest.xml file to disable
debug mode.

13) Exported Broadcast Receivers
• The PIVAA application has exported a broadcast receiver without any
permissions set. Broadcast receivers are designed to listen to system
wide events called broadcasts (e.g. network activity, application
updates, etc.) and then trigger something if the broadcast message
matches the current parameters inside the Broadcast Receiver.
• Vulnerability: Any application, including malicious ones, can send an
intent to this broadcast receiver causing it to be triggered without any
restrictions.

Recommendations:
• Control what applications can receive a broadcast sent from your
application by passing a permission alongside the intent when
attempting to trigger a broadcast receiver. Only applications that have
requested and been granted that permission can receive the
broadcast intent from the sending application.
• Control what broadcasts can be received by your application by
setting a permission in the AndroidManifest.xml file which restricts
access to a broadcast receiver to only those apps that have requested
and been granted that permission.

14) Exported Service
• The PIVAA application has exported a service that performs audio
recording and stops after the file reaches 1MB in size. Services are an
Android component that runs in the background and does not
normally provide a user interface to interact with. These services are
used to perform tasks in the background such as downloading large
files or playing music, without blocking the user interface.
• Vulnerability: This service is exported without any permissions in the
AndroidManifest.xml file, which means any application can abuse this
feature to record audio.

Recommendations:
• Determine if a service needs to be exported.
• A service is generally not exported but if it is, then strong permissions
should be set in the AndroidManifest.xml file.
• Keep in mind that specifying intent filters with a component in the
AndroidManifest.xml file will result in the component being exported
by default unless the export attribute is set to false.

Android Penetration testing - Day 2

More Related Content

What's hot

Similar to Android Penetration testing - Day 2

More from Mohammed Adam

Recently uploaded

Android Penetration testing - Day 2