This is the article for those of you who have already previously setup Drozer or are returning to test your next Application a few weeks later and do not quite remember the exact syntax to get Drozer purring.
Reconnecting Drozer – Quickstart
Instead of heading back to the last article on setting up Drozer completely here is the quick start to get back online.
- Boot Up your Genymotion Device which has the Drozer agent installed, pull it up and turn it on (bottom right hand corner)
- Now pull up a console (command line) and change your directory over to your platform-tools folder.
adb forward tcp:31415 tcp:31415to begin using the correct ports required for Drozer
- Switch your directory to your drozer folder and then type
drozer console connectand you are back in business
Examining Mobile Web Applications w/ Drozer:
At this point in time I want you to type the command
list this is going to demonstrate all of the modules available for you to execute in this session much like the -h or –help command would get you a list of sample syntax that can be used.
The next command is finding the application package for the APP you are testing.
run app.package.list -f (name of app or company)I have given you a few examples above, this will search for the application package which we will be running additional commands for. As you can see a search for google pulls up a significant amount of applications, fortunately Drozer puts the (App Name) in brackets so it is very easy for you to identify your application even if you are testing a few at the same time.
For this test I will be using Etar which is an open source calendar application which I have already run these commands on and there are no shown vulnerabilities with this tools (demonstrating code) as I have already found the application package I will be using.
**Disclosure: Please only be testing applications which you have either written permissions from individuals with authority to test and application, is documented as Open Source (express permissions given – static testing only), or is your own proprietary application in which you are testing for vulnerabilities.
Next, find out some more information on the app you will be looking at first.
run app.package.info -a (application) use the location found in the screenshot above, in my example it was the ws.xsoh.etar – see below.
As you can see above, the version number is listed, the path, the .apk file, permissions and typically a broadcast receiver would define the permissions(when its supported by a private company).
You should be Screen shooting this data and save them as artifacts when submitting your testing documentation (and for your own reference so you do not have to run these commands again)
If you need to pull an .apk for any reason please see the article already written in regards to MobSF (Mobile Security Framework) where extracting .apk files is documented.
run app.package.attacksurface (application)
This command will get you into territory which has made Drozer so popular in the mobile web application security world. Lets take a look.
As we can see here, there are 7 activities which have been exported along with 3 broadcast receivers. Now as security testers it is up to us to make sure that these exported activities and attack surfaces are sensitive and/or vulnerable by design. If they are vulnerable we can take it a step further and use the other Drozer modules to test and exploit these activities.
Be aware and on the lookout for a line that may be included at the bottom of this attack surface result:
As security testers this is big. First and foremost this is most likely an item on your Mobile web application security checklist in which case if you do not see this output, most likely this application is not in Dev mode and has been released appropriately and is in Prod state.
So what does it mean if you do see that this application is debuggable? Good question.
When an application is debuggable it means that the development team did not turn this “feature” off, it also means that as a penetration tester we are able to take our pick of debuggers attach it to the process and walk through every single set of instructions while executing arbitrary code in the application (good times). InfoSec institute has an excellent article on digging deeper when you application is debuggable and injecting runtime code.
run app.activity.info -a (application)
As you can see in this open source application which is the new free software for android calendar it is using basically all code from the com.android.calendar packages which is why I chose this application.
When using this next command, look for something that was custom written by the creators. Something that is unique to the app in particular that is either a standalone activity or an activity behind any type of authentication page in which the application can be taken advantage of. You would be amazed at some of the things you can discover, Password Lists, Usernames, developer documentation, just remember to Document Everything.
run app.activity.start --component (application) (activity)
Run each activity, witness how it interacts with your application, change parameters, share items, change settings, and see what can be seen and changed within your mobile web application.
Many times the
app.service.send can be used to send messages to each individual service, other times it may take writing customer drozer modules as well to truly get the outputs you are looking to get from your Mobile Web Application
Digging Deeper ~
Drozer is capable of building more complex commands on top of just picking activities and running them within the application. you can also type
in front of your command and see what options are available to you
run app.activity.start --component (application) (activity)
Here we can see that we can continue to use Drozer with a much more ‘explicit intent’ by using optional arguments provided within the help command documentation.
While there is not much to see on my sample application using these next few commands it is very important that you continue to analyze the application you are testing with these as I am sure there will not only be content, but possible vulnerabilities and findings as well.
Content Provider Information
run app.provider.info -a (app)
~This will list content provider information – please run this as while you may not have found a vulnerability within the application itself I have seen a number of times where there are significant vulnerabilities or SQL injection flaws within the content providers of the Mobile App.
Drozer Scanner Module
Also Drozer is able to search for SQL Injection with its scanner module but for directory traversal as well.
run scanner.provider.injection -a (app)
run scanner.provider.traversal -a (app)
Run these to find vulnerable content providers that are easily visible to the scanner.
run scanner.provider.finduris -a (app)
This scanner module will allow you to bring together a list of content URI’s that are accessible and then we are able to take a look and try to retrieve and query information from the URI’s or possibly modify data in any correlating databases.
run app.provider.query content://(content provider as seen in previous command output here)
Now we have data, but how to test it?
Here is where you direct knowledge of Android comes into play.
We know that the Android platform is big on using SQLite databases for storing snippets, metadata, and user data. Since we know these data bases use SQL, we know that SQL injection is right around the corner. If you don’t know SQL, you can learn enough in a day off of CodeCademy to be dangerous with it.
Here are a few exploit examples testing for SQL vulnerabilities
run app.provider.query content://(content provider) --verticle_id: 1
Looking at certain id’s within the database
run app.provider.query content://(content provider) --projection "'"
Testing the projection field
run app.provider.query content://(content provider) --selection "'"
Testing the Selection field.
run app.provider.query content://(content provider) --projection "* FROM SQLITE_MASTER WHERE type='table';--"
Use any error messages received to craft your requests to tray to list all tables or query specific tables
run app.provider.query content://(content provider) --projection "* FROM Key;--"
Underlying File Systems
These content providers are in place in order to share data, files, and information to other applications outside of the application in which you are using. This is called sand-boxing. There are a number of commands you can use within drozer that I will list in a second, but I personally use Root Browser to dig deeper into the filesystem of the application, and if I require a file I can use drozer to download it if I prefer.
to make sure you have the right file, read it
run app.provider.read content://(content provider)/data/data/(filename)
then download it.
run app.provider.download content://(content provider)/data/data/(filename)
Wrap up ~
It is important to remember that you do not have to memorize EVERYTHING! You just have to know where to find it. If you ready this whole article awesome. If you put to use the information delivered in this article, even better!
Personally I hack to learn.
Since I do plan to stop learning, I will definitely not stop Hacking!
I hope you do the same.
Cyber Incision Out.