# Mobile Testing 3
## Insecure Logging
It means the application is storing some sensitive information in its log.
```c
# 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…
```c
cat HardcodeActivity.java
```
### Shared Object Files/Libraries
```c
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.
.png?alt=media\&token=89f3717e-fa28-4d74-9777-f3891d306717)
```c
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:
```java
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//shared_prefs/key.xml`.
```markup
```
* 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:
```java
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//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.
```java
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)
```c
# 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
```c
InsecureDataStorage3Activity.java
```
.png?alt=media\&token=973274c2-0b83-4525-812c-d48975388978)
A temporary file **`uinfo`** is created, where the credentials coming from the user input are saved.
```c
cat info-419988827tmp
```
### Local Storage
```c
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\_STORAG**E 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.
```c
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.
```c
cat SQLInjectionActivity.java
```
### **Webview Vulnerability**
Webview is simply browser content being rendered into a mobile application.
%20\(1\).png?alt=media\&token=627e27cb-0f33-4dfc-abad-13fac89900ce)
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:
```c
file:///sdcard/.uinfo.txt
```
.png?alt=media\&token=923b00dd-4017-4e65-ae10-9ffe68385974)
### **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:
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.
.png?alt=media\&token=9001260c-6e21-48d4-a7cc-d507ca71e262)
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.
.png?alt=media\&token=13a6c56a-ff95-4be7-bc2a-6a2070a21e34)
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.
```c
adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS
```
### Intent Filter Vulnerability 2
.png?alt=media\&token=97f312b1-4375-4420-aa30-7963cb539dd5)
```c
adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS2 --ez "check_pin" false
```
### Leaking Content Provider
```c
cat NotesProvider.java
```
.png?alt=media\&token=316a96fc-816e-489e-80a8-7b387c59e778)
```c
cat AndroidManifest.xml
```
.png?alt=media\&token=1beaef4b-523b-445f-889c-1f4af5f7ec99)
```c
adb shell content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes
```
x