Categories: Android

Android Application Penetration Testing – Part 8

In Last Part, Android Application Penetration Testing Part 7 We have seen about the Insecure external and internal storage and Insecure Communication.

Attacking through Content Provider:

We recommend reading content provider before starting is useful in cases when an app wants to share data with another app.

The Content Provider instance manages access to a structured set of data by handling requests from other applications. All forms of access eventually call Content Resolver, which then calls a concrete method of Content Provider to get access.

Required methods
Query (), Insert (), Update (), Delete (), Get Type (), On Create ()

As this method are same as the database. First, we must try to check injections through URIs

We can use drozer tool to check injections

Run scanner.provider.finduris –a

Run scanner.provider.injection -a

Content query –Uri

Mitigation – Android

If your content provider is just for your app’s use then set it to be android: exported=false in the manifest. If you are intentionally exporting the content provider then you should also specify one or more permissions for reading and writing.

If you are using a content provider for sharing data between only your own apps, it is preferable to use the android: protectionLevel attribute set to “signature” protection.

When accessing a content provider, use parameterized query methods such as query (), update (), and delete () to avoid potential SQL injection from untrusted sources.

INSECURE (weak) Cryptography:

Protecting sensitive data with cryptography has become a key part of most web applications. Simply failing to encrypt sensitive data is very widespread. Applications that do encrypt frequently contain poorly designed cryptography, either using inappropriate ciphers or making serious mistakes using strong ciphers. These flaws can lead to the disclosure of sensitive data and compliance violations.

by base 64 decoding – decoded username

we get the code from reverse engineering – algorithm use for authentication

cracking password with AES-Exploit

Mitigation:

Do not use weak algorithms, such as MD5 / SHA1. Favor safer alternatives, such as SHA-256 or better.

Generate keys offline and store private keys with extreme care. Never transmit private keys over insecure channels

Ensure that infrastructure credentials such as database credentials or MQ queue access details are properly secured (via tight file system permissions and controls), or securely encrypted and not easily decrypted by local or remote users

Ensure that encrypted data stored on disk is not easy to decrypt. For example, database encryption is worthless if the database connection pool provides unencrypted access.

Hard-coded password in source code:

Hardcoded passwords may compromise system security in a way that cannot be easily remedied.

It is never a good idea to hardcode a password. Not only does hardcoding a password allow all of the project’s developers to view the password, it also makes fixing the problem extremely difficult.

Once the code is in production, the password cannot be changed without patching the software. If the account protected by the password is compromised, the owners of the system will be forced to choose between security and availability.