Mobile Testing 3
Insecure Logging
It means the application is storing some sensitive information in its log.
Hardcoding Issues
This is an important vulnerability because using reverse engineering it would be possible to see that sensitive information. Examples could be access keys, passwords, etc…
Shared Object Files/Libraries
In the above image, you can see it created the object of DivaJni class
The access method gets a text using JNI and checks whether the text entered by the user matches or not the valid key.
What is JNI? (Android Native Library)
Google develops the Android Native Development Kit (NDK) besides Android SDK. The purpose of NDK is helping developers to build libraries in C or C++.
When the native library built, The Java Native Interface (JNI) handles the communication between the native library and java based code.
Now let’s check the code of class DivaJni.java
From the above code, it is clear that a native library called soName
is loaded. Libraries will come with the APK file, and they are usually located within the "lib" directory.
Insecure Data Storage
Storing data is essential for many mobile apps. For example, some apps use data storage to keep track of user settings or user-provided data. Data can be stored persistently in several ways. The following list of storage techniques are widely used on the Android platform:
Shared Preferences
SQLite Databases
Internal Storage
External Storage
The following code snippets demonstrate bad practices that disclose sensitive information. They also illustrate Android storage mechanisms in detail.
Shared Preferences
The SharedPreferences API is commonly used to permanently save small collections of key-value pairs. Data stored in a SharedPreferences object is written to a plain-text XML file. The SharedPreferences object can be declared world-readable (accessible to all apps) or private. Misuse of the SharedPreferences API can often lead to exposure of sensitive data. Consider the following example:
Once the activity has been called, the file key.xml will be created with the provided data. This code violates several best practices.
The username and password are stored in clear text in
/data/data/<package-name>/shared_prefs/key.xml
.
Allows all applications can access and read the contents of
key.xml
.
SQLite Database (Unencrypted)
SQLite is an SQL database engine that stores data in .db
files. The Android SDK has built-in support for SQLite databases. The main package used to manage the databases is android.database.sqlite
. You may use the following code to store sensitive information within an activity:
Once the activity has been called, the database file privateNotSoSecure
will be created with the provided data and stored in the clear text file /data/data/<package-name>/databases/privateNotSoSecure
.
Sensitive information should not be stored in unencrypted SQLite databases.
SQLite Databases (Encrypted)
With the library SQLCipher, SQLite databases can be password-encrypted.
If encrypted SQLite databases are used, determine whether the password is hard-coded in the source, stored in shared preferences, or hidden somewhere else in the code or filesystem, Secure ways to retrieve the key include:
Asking the user to decrypt the database with a PIN or password once the app is opened (weak passwords and PINs are vulnerable to brute force attacks)
Storing the key on the server and allowing it to be accessed from a web service only (so that the app can be used only when the device is online)
Temporary Files
A temporary file uinfo
is created, where the credentials coming from the user input are saved.
Local Storage
It indicates that an external storage directory is used to save the credentials, inside a file called .uinfo.txt.
If the application uses the READ_EXTERNAL_STORAGE permission, then it can read the external storage from the SD card.
If the application uses the WRITE_EXTERNAL_STORAGE permission, then it has also permission to read the external storage from the SD card.
Input Validation Issues
SQL Injection
Input Validations Attacks are when an attacker purposefully sends strange inputs to confuse an application. Input validation routines serve as the first line of defense for such attacks. Examples of input validation attacks include buffer overflow, directory traversal, cross-site scripting, and SQL injection.
Webview Vulnerability
Webview is simply browser content being rendered into a mobile application.
As you can see in the above image,google.com is unreachable because the INTERNET permission has not included in the AndroidManifest.xml.
Using the File protocol, access to the uinfo
file can be achieved:
Buffer Overflow
Typing random string “hello” to check what happens.
The application is using JNI (Java Native Interface), which suggests that the method DivaJni is related to a program written in other languages.
Now, let’s explore the source code available at the link:
https://github.com/payatu/diva-android/blob/master/app/src/main/jni/divajni.c
After exploring the source code available at the above link, it is clear that the application is processing user-supplied input using strcpy() function.
Let's try giving large input values so the buffer will get overflow.
The problem is that the function strcpy does not check whether the size of the destination’s buffer is large enough to hold the source parameter.
Access Control Issues
Intent Filter Vulnerability 1
The application allows seeing the API credentials.
Now, our goal is to access this information, without clicking this button. Let’s see how to do it.
The “jakhar.aseem.diva.action.VIEW_CREDS” is the intent filter responsible for allowing the credentials to be displayed by the application.
Also, the AndroidManifest.xml indicates the presence of the mentioned intent filter:
If you notice the above piece of code, the activity is “protected” with an intent filter. The intent filter should not be treated as a protection mechanism. When an intent-filter is used with an application component such as activity, the component is publicly exported. For the same reason, this activity is vulnerable and hence it can be invoked by any application from outside.
using the Activity Manager tool we can start the intent filter jakhar.aseem.diva.action.VIEW_CREDS without using the DIVA application interface.
Intent Filter Vulnerability 2
Leaking Content Provider
x
Last updated