Android Application Security Testing Part-17: Android Application Source code Analysis
ANDROID
APPLICATION SOURCE CODE ANALYSIS
The Android operating system (OS)
leads the world's mobile platform market as the most used OS for mobile
devices. Accordingly, eight out of every ten mobile phones uses the Android OS.
Due to this, there are a multitude of mobile applications available for Android
devices. The Android OS provides developers with a flexible software
engineering platform that is easy to develop for, partly due to its open-source
nature. This is in contrast to the closed-source, sandboxed nature of the Apple
iOS. However, the flexible nature of the Android platform often results in
applications that have a great measure of system access that can result in a
number of high-risk vulnerabilities.
There are other
situations, partly unique to the Android OS, that result in security issues
with Android devices that might allow attackers to have an advantage. Combining
the popular mechanism of rooting with the practice of not upgrading to the
latest Android OS (and thus lacking important security patches) results in a
dichotomy between the desired security posture of an Android device, and the
reality. It is thus important for security professionals to manually review the
source code of Android apps to ensure that no high-risk vulnerabilities exist
that can be exploited, and for end-users to always upgrade to the latest,
patched Android OS in order to maintain a secure platform.
CHECKING JAVA CODE FOR INSECURITIES
The risks
associated with the Android platform are further increased by the use of the
Java programming language as its native language for application development.
Java is a popular, object-oriented programming language that has many inherent
security flaws that can present exploitable vulnerabilities in its
applications. According to security research, Java is known for providing major
attack surfaces and for presenting major security holes in software, such as
faulty race conditions, deadlocks, and access-control vulnerabilities.
Java is
mostly secure but can be improperly implemented by programmers in a way that
can allow attackers to fully exploit a system. It is imperative for security
engineers to review the source code of applications written with Java, and for
software engineers to utilize secure coding practices during the coding stages
of application development.
Security
Check in Source Code:
|
S. No.
|
To Check
|
Analysis Logic
|
|
1
|
Does the application leak sensitive information
via Property Files?
|
Check for presence of putString, MODE_PRIVATE,
MODE_WORLD_READABLE, MODE_WORLD_WRITEABLE, addPreferencesFromResource in
Source Code
|
|
2
|
Does the application
leak sensitive information via SD Card storage?
|
Check for presence of
WRITE_EXTERNAL_STORAGE in Android Manifest File and
getExternalStorageDirectory(), sdcard in Source code
|
|
3
|
Is the application vulnerable to TapJacking
attack?
|
Check for presence of <Button> tag not
containing filterTouchesWhenObscured="true" in Layout file
|
|
4
|
CanMalicious Activity
be performed due to insecure WebView implementation?
|
Check for presence of
addJavascriptInterface(),
setJavaScriptEnabled(true)
in Source code
|
|
5
|
Does the application leak sensitive information
via hardcoded secrets?
|
Check for presence of // and /* */ in Source code
|
|
6
|
Can sensitive
information be enumerated due to the enabled Autocomplete feature?
|
Check for presence of
<Input> tag not containing textNoSuggestions in Layout file
|
|
7
|
Does the application leak sensitive information
viaSQLite db?
|
Check for presence of db, sqlite, database,
insert, delete, select, table, cursor, rawQueryin Source code
|
|
8
|
Does the application
leak sensitive information due to insecure Logging mechanism?
|
Check for presence of
Log. In Source code
|
|
9
|
Is critical data of the application encrypted
using proper control?
|
Check for presence of MD5, base64, des in Source
code
|
|
10
|
Does the application
implement a insecure transport mechanism?
|
Check for presence of
http://, HttpURLConnection,URLConnection, URL, TrustAllSSLSocket-Factory,
AllTrustSSLSocketFactory, NonValidatingSSLSocketFactory in Source code
|
|
11
|
Does the application leak sensitive system
level information via Toast messages?
|
Check for presence of sensitive information
in Toast.makeText
|
|
12
|
Does the application
misuse or leaksensitive information like device identifiers or via a side
channel?
|
Check for the
presence of uid, user-id, imei, deviceId, deviceSerialNumber, devicePrint,
X-DSN, phone, mdn, did, IMSI, uuid in Source code
|
|
13
|
Is the application vulnerable to Intent
Injection?
|
Check for the presence of
Action.getIntent() in the Source code
|
|
14
|
Does the application
misuse or leaksensitive information like Location Info or via a side channel?
|
Check for the presence
of getLastKnownLocation(), requestLocationUpdates(), getLatitude(),
getLongitude(), LOCATION in Source code
|
·
Binary
protection:
o
Lack of binary protections in a mobile
application exposes the application to leakage of metadata, certification,
encryption keys, application logic and vulnerabilities, credentials (if
hard-coded), intellectual property and other sensitive data.
o
The impact for a business could vary
depending on how the attacker exploits the app. It could be revenue loss
because of piracy (for example a game with in-app purchases), intellectual
property theft, such as a competitor stealing parts of source code, or even reputational
damage if confidential client data such as personal identifiable information is
accessed.
o
What can an attacker potentially do
with an application’s binary? The following are a few examples:
§ Inject
backdoor code which will steal sensitive user data. They can then distribute
the application through third party App Stores or Internet forums.
§ Crack the
application and freely distribute it on the Internet.
§ Bypass any
binary protections in place widening the surface for further vulnerabilities
and exploitation
o
More on:
·
Hard coded
Credentials in Application Source code
o
Hard-coded credentials typically create
a significant hole that allows an attacker to bypass the authentication
·
Hard coded
sensitive information in Application code
o
If attacker ableto fin any secret
key, Addresses, emails, CC numbers and other IDs are used frequently
for registration, authentication and for other legitimate purposes or any
sensitive information they can misuse the sensitive information
·
Private IP
Disclosure
·
Weak
Encryption
o
Use Strong encryption mechanism to
store any sensitive information in the source code, otherwise it is very easy
to attackers to decrypt the data.
·
Application
is Vulnerable to XSS
o
WebView Potential XSS Attacks Checking:
Please check for the below code
"setJavaScriptEnabled(true)"
Which could
exposed to potential XSS attacks. Please check the web page code
carefully and sanitize the output
carefully and sanitize the output
If your app
really doesn’t require JavaScript usage within a WebView then don’t call
setJavaScriptEnabled(true).
·
WebView
Local File Access Attacks Checking
o
"setAllowFileAccess(true)"
o
The attackers could inject malicious
script into WebView and exploit the opportunity to access local resources.
This can be mitigated or prevented by disabling local file system access.
(It is enabled by default) Note that this enables or disables file system
access only. Assets and resources are still accessible using
file:///android_asset and file:///android_res.
o
More on:
§ https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowFileAccess(boolean)
·
WebView RCE
Vulnerability Checking:
o
WebView addJavascriptInterface
vulnerabilities
o
Injecting Java objects into the WebView
using the addJavascriptInterface(Object, String)method. This
method allows you to inject Java objects into a page's JavaScript context, so
that they can be accessed by JavaScript in the page.
o
addJavascriptInterface is used for
interface between JS code and local Java. If your browser or other
applications has implemented code like below, then you might be vulnerable. Hackers
can remote run code on your android device. And they can get remote shell or
even to install backdoor application on your device.
·
File Unsafe
Delete Checking:
o
Everything you delete may be recovered
by any user or attacker, especially rooted devices.
o
Please make sure do not use
"file.delete()" to delete essential files.
·
External
Storage Accessing
o
DO NOT write important files to
external storages
·
SQL
Injection
o
The SQLite used in android apps are
fully functional databases, so just like SQL Server or MySQL box they can be
susceptible to SQL injection. SQL injection typically works by adding data to
the query string or adding data in a form field; to give hackers access to a
database or unauthorized logins. SQL Injection is usually used to attack Web
Views or a web service but it can also be used to attack Activities.The root
cause of the SQL Injection vulnerability is due to the use of dynamic or
concatenated SQL queries. If SQL queries are constructed by concatenating user
supplied inputs; The user can then supply SQL attack vectors instead of valid
inputs and manipulate the backend SQL query.The injection process works by
prematurely terminating a text string and appending a new command. Because the
inserted command may have additional strings appended to it before it is
executed, the injected string is terminated with a comment mark “–”. Subsequent
text is ignored at execution time.
o
https://www.blackhat.com/docs/us-17/wednesday/us-17-Feng-Many-Birds-One-Stone-Exploiting-A-Single-SQLite-Vulnerability-Across-Multiple-Software.pdf
o
Finding PRAGMA key : More on - http://resources.infosecinstitute.com/android-hacking-security-part-16-broken-cryptography/#gref
·
Allow All
Hostname Verifier
o
If app does not check the validation of
the CN(Common Name) of the SSL certificate
("ALLOW_ALL_HOSTNAME_VERIFIER" field or
"AllowAllHostnameVerifier" class).
This is a critical vulnerability and allows attackers to do MITM attacks with his valid certificate without your knowledge.
"AllowAllHostnameVerifier" class).
This is a critical vulnerability and allows attackers to do MITM attacks with his valid certificate without your knowledge.
Some
more in vulnerbailities Source code analysis..
·
Invalid SSL Certificate
·
Autocomplete is not set to OFF
·
Directory Browsing
·
Improper exception Handling: In code
·
Application build contains Obsolete
Files
·
Failure to Implement Trusted Issuers
·
Ignore SSL Certificate Error
·
Weak Custom Hostname Verifier
·
Redundancy Permission Granted
·
Use of Insecure and/or Deprecated
Algorithms
·
Insecure permissions on Unix domain
sockets
·
Insecure use of network sockets
https://github.com/payatu/diva-android
https://androidtamer.com/learn_android_security
Automated
Tools:
There are
several open source tools for automated security analysis of an APK.
·
QARK
·
JAADAS
No comments