Mobile Testing 3

Insecure Logging

It means the application is storing some sensitive information in its log.

# Finding Process ID of Application
adb shell ps | grep -i appname

# Now we have entered the credit card number, let’s check the log if we can see it or not.
adb shell logcat | grep -i 19586

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…

cat HardcodeActivity.java

Shared Object Files/Libraries

cat Hardcode2Activity.java

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.

strings libdivajni.so

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:

SharedPreferences sharedPref = getSharedPreferences("key", MODE_WORLD_READABLE);
SharedPreferences.Editor editor = sharedPref.edit();
editor.putString("username", "administrator");
editor.putString("password", "supersecret");
editor.commit();

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.

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
  <string name="username">administrator</string>
  <string name="password">supersecret</string>
</map>

  • Allows all applications can access and read the contents of key.xml.

root@hermes:/data/data/sg.vp.owasp_mobile.myfirstapp/shared_prefs # ls -la
-rw-rw-r-- u0_a118    170 2016-04-23 16:51 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:

SQLiteDatabase notSoSecure = openOrCreateDatabase("privateNotSoSecure", MODE_PRIVATE, null);
notSoSecure.execSQL("CREATE TABLE IF NOT EXISTS Accounts(Username VARCHAR, Password VARCHAR);");
notSoSecure.execSQL("INSERT INTO Accounts VALUES('admin','AdminPass');");
notSoSecure.close();

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.

SQLiteDatabase secureDB = SQLiteDatabase.openOrCreateDatabase(database, "password123", null);
secureDB.execSQL("CREATE TABLE IF NOT EXISTS Accounts(Username VARCHAR,Password VARCHAR);");
secureDB.execSQL("INSERT INTO Accounts VALUES('admin','AdminPassEnc');");
secureDB.close();

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)

# Access SQLite Database
cd /data/data/jakhar.aseem.diva/databases
qlite3 ids2
sqlite> .tables
android_metadata  myuser          
sqlite> select * from myuser;
test|testtest

Temporary Files

InsecureDataStorage3Activity.java

A temporary file uinfo is created, where the credentials coming from the user input are saved.

cat info-419988827tmp

Local Storage

cat InsecureDataStorage4Activity.java

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.

adb shell "cat /storage/emulated/0/.uinfo.txt"

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.

cat SQLInjectionActivity.java

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:

file:///sdcard/.uinfo.txt

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.

adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS

Intent Filter Vulnerability 2

adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS2 --ez "check_pin" false

Leaking Content Provider

cat NotesProvider.java
cat AndroidManifest.xml
adb shell content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes

x

PreviousMobile Testing 2

Last updated