Purposefully Insecure and Vulnerable Android Application (PIVAA) is an updated version of Damn Insecure Vulnerable Application and when I look at this application I think its really cool and I want to try to test it
Sauce link: https://github.com/HTBridge/pivaa
But in this post, we are going to focus on the database security and best practice part of the application.
1st challenge:
Cleartext SQLite database
The mobile application uses an unencrypted SQLite database. This database can be accessed by an attacker with physical access to the mobile device or a malicious application with root access to the device. The application should not store sensitive information in clear text.before we move on to the actual testing, I just want to say that I think this is actually rather a best practice not a vulnerability in android penetration testing.
to solve this problem, first, I try to do some simple static analysis to find which class that contains string "SQLiteDatabase"
ok we got hit and it seems it only shows one class which is DatabaseHelper.java
Let's try to open with it and we find the following information about the database:
the database name is "pivaaDB" and there are little information show us what is the column name that is used by the application. Next, install the application in your emulator and browse to its directory using adb tool.
Download the database use adb again and open it using sqlite3 command utility
According to OWASP MSTG sensitive data need to be stored inside encrypted database and you can enable encryption in sqlite3 database using this method:
SQLiteDatabase secureDB = SQLiteDatabase.openOrCreateDatabase(database, "password123", null);
link: https://github.com/OWASP/owasp-mstg/blob/master/Document/0x05d-Testing-Data-Storage.md
2nd challenge:
User-supplied input in SQL queries
Inclusion of user-supplied input into SQL queries can potentially lead to a local SQL injection vulnerability in the mobile application. The correct approach is to use prepared SQL statements beyond user's control.I think the explanation is pretty straightforward to never trust input from user and don't forget to sanitize the input before you process it.
application need to use content provider to interact with database so we need to find which class that handling content provider. You can do this by using static analysis using grep again
we got hit and file with name VulnerableContentProvider.java seems promising lets take a look at it.
if you try to read the source code it is show that our input is passed to the "query" function and inside the function they use object name "db" from DatabaseHelper to execute our input using "rawSQLQueryCursor". Also, it seems that our input is also show in the log (Log.i)
lets check this DatabaseHelper class
Navigate you attention to the "rawSQLQueryCursor" function, notice that our input is execute as sql query and lucky for us it is not sanitize. This make us capable to do sql injection. To execute this i will use drozer tools to interact with the database.
from the result we can see that the application have one content provider that is exported by other application.
To exploit the content provider, type:
Yesss we are able to retrieve the database using sql injection and as you can see our input is log and you are able to see it using adb logcat
cheers :)
Comments
Post a Comment