OWASP Mobile Security Guidelines (ANDROID)

Overview

As mobile application developers we should be familiar with possible security risks that a mobile application might face. Knowing possible risks makes it easier to avoid possible pitfalls and write more secure applications.

Ø OWASP (Open Web Application Security Project)

It is an online community of security specialists that have created freely available learning materials, documentation and tools to help build secure web and mobile applications. Among others they have compiled a list of 10 most common threats to mobile applications.

Ø Statistics

Before we look into each risk in more detail let’s talk about statistics. Most popular apps on the App store and on Google Play store should not be vulnerable to these risks, right? Unfortunately, they are

Apps on Google Play store found out that 85% of apps violate at least one top 10 risk.

Of these apps 50% have insecure data storage and almost the same number of apps use insecure communication.

These mistakes happen a lot more often than we might think.

Ø M1 Improper platform usage

Misuse of a platform feature or failure to use platform security controls. Might include:

ü android intents

ü platform permissions

ü misuse of other security controls

How to fix it ?

Since intents are sent to other Android components such as Activities, Services and Broadcast Receivers, these components may be public or private. Set these components to android:exported=false in the app Manifest to stop this.

<serviceandroid:name=".RSSPullService"android:exported="false"/>

If you require your components to only be accessible to other applications from the same organisation and signed with the same key then it is recommended to use the <permission> element, with a protection level of signature in the Manifest.

<!-- Create a unique permission for your apps --><permission android:name="com.mycompany.message.permission.OUR_MESSAGE" android:protectionLevel="signature" /><uses-permission android:name="com.mycompany.message.permission.OUR_MESSAGE" />

The Android security documentation is a great resource in this area. This guide from ISEC Partners is also very useful.

Ø Intent Sniffing

· A malicious Android application can register to receive broadcast or implicit intents from any other app. Malicious apps can then read the data passed with the intent, which may be considered sensitive. This process is called intent sniffing, and is quite easy to achieve with readily-available tools.

· For example, if an app opens the web browser with a URL the malicious application could read the data within the URL. Another possibility is that an app may supply a user’s typed-in credentials to a broadcast intent to launch authenticated activities.

How to fix it?

· You should always use explicit intents, rather than passing data between apps using broadcast intents. To create an explicit intent, ensure that you define a component name for the Intent object:

· Our Intent explicitly starts the DownloadService class in our app

Intent downloadIntent = new Intent(this, DownloadService.class);downloadIntent.setData(Uri.parse(fileUrl));startService(downloadIntent);You should also set android:exported to false on any activities or services that you don’t want other apps to call:<serviceandroid:name=".RSSPullService"android:exported="false"/>

Ø Insecure File Permissions

o Insecure file permissions are one of the most common mistakes when it comes to using the Android platform’s facilities for data storage. Using the ‘world readable’ and ‘world writeable’ file permissions can cause data leaks and expose apps to attackers who are able to overwrite the app’s data.

o One especially risky area is when dynamically loading code from files outside of your application APK, which can leave the application open to code injection. Dynamically loaded code runs with the same permissions as the rest of the application, so it must come from a verifiable source and only be accessible to your main application code.

o How to fix it?

o Follow the principle of least privilege when assigning permissions and avoid giving a file MODE_WORLD_READABLE or MODE_WORLD_WRITEABLE permissions. These permissions do not provide the ability to limit access to particular apps or provide any control of data format.

o You should instead use a ContentProvider to share a file between apps, which can offer read and write permissions and can make dynamic permission grants on a case-by-case basis. You can also encrypt files using a key placed in the KeyStore and protect it with a user password that is not stored on the device.

Ø M2 Insecure data storage

Android’s SharedPreferences stores data unencrypted on the filesystem. These files are protected by standard Linux-style file permissions, restricting access to only the application binary. On a rooted device these files are easily accessible however, so you should never store sensitive information here without encrypting it first.
When searching for file encryption examples for Android be aware that many of these include use of the Crypto provider and the “SHA1PRNG” algorithm. Unfortunately, the SHA1PRNG is no longer considered cryptographically strong and as a result Google has deprecated the Crypto provider and SHA1PRNG algorithm in Android Nougat. The correct way to implement encryption is Cryptography. Which we can discuss further.

Sensitive information should not be stored in unencrypted SQLite databases.

SQLite Databases (Encrypted)

With the library SQLCipher, SQLite databases can be password-encrypted.

SQLiteDatabase secureDB = SQLiteDatabase.openOrCreateDatabase(database, “password123”, null);

secureDB.execSQL(“CREATE TABLE IF NOT EXISTS Accounts(Username VARCHAR,Password VARCHAR);”);

secureDB.execSQL(“INSERT INTO Accounts VALUES(‘admin’,’AdminPassEnc’);”);

secureDB.close();

Secure ways to retrieve the database key include:

· Asking the user to decrypt the database with a PIN or password once the app is opened (weak passwords and PINs are vulnerable to brute force attacks)

· Storing the key on the server and allowing it to be accessed from a web service only (so that the app can be used only when the device is online)

Example: Tinder

Tinder app vulnerability: how sharing location data harms your privacy

The trendy dating app Tinder has been praised for its simplicity, but it’s security and privacy practices don’t deserve…

www.abine.com

Tinder introduced a feature that showed people logged on near you. Problem: the exact location of every person near you was sent to the device.

First fix was to provide distance only, but it was possible to spoof the location and to use triangulation.

Second fix was to send this data without precision.

Website that made it possible to track down Tinder users

To show how bad the discovered vulnerability was an app was created by users to show tinder users with exact location.

Ø M3 Insecure communication

Might include:

ü poor handshaking/weak negotiation,
(f. ex. lack of certificate pinning)

ü incorrect SSL versions,

ü cleartext communication of sensitive assets,

ü HTTP instead of HTTPS.

Example: Misafe smart watches

Hacking MiSafes’ smartwatches for kids is child’s play MiSafes, the maker of surveillance devices meant to track kids, is back in the news. This time it’s due to the… nakedsecurity.sophos.com

Communication was not encrypted and not correctly authenticated.

Attackers could:

ü retrieve real-time GPS coordinates of the kids’ watches,

ü call the child on their watch,

ü create a covert one-way audio call, spying on the child,

ü send audio messages to the child on the watch, bypassing the approved caller list

ü retrieve a photo of the child, plus their name, date of birth, gender, weight and height.

How Do I Prevent ‘Insecure Communication’?

General Best Practices

ü Assume that the network layer is not secure and is susceptible to eavesdropping.

ü Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.

ü Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.

ü Use strong, industry standard cipher suites with appropriate key lengths.

ü Use certificates signed by a trusted CA provider.

ü Never allow self-signed certificates, and consider certificate pinning for security conscious applications.

ü Always require SSL chain verification.

ü Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.

ü Alert users through the UI if the mobile app detects an invalid certificate.

ü Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).

ü If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrypted data will provide a secondary defense against confidentiality violation.

ü Android Specific Best Practices

ü Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.

ü If using a class which extends SSLSocketFactory, make sure checkServerTrusted method is properly implemented so that server certificate is correctly checked.

Ø M4 Insecure authentication

ü If the mobile app is able to anonymously execute a backend API service request without providing an access token, this application suffers from insecure authentication;

ü If the mobile app stores any passwords or shared secrets locally on the device, it most likely suffers from insecure authentication;

ü If the mobile app uses a weak password policy to simplify entering a password, it suffers from insecure authentication; or

ü If the mobile app uses a feature like TouchID, it suffers from insecure authentication.

ü failing to identify the user at all when that should be required,

ü failure to maintain the user’s identity when it is required,

ü weaknesses in session management.

ü The security researcher was able to bypass 2FA by forcing 4 digit code. There was no limit of how many times the sent 4 digit code could be entered.

ü Problem: gain access to account with information on rides, payment methods, orders.

Ø M5 Insufficient cryptography

Cryptography is a method of protecting information and communications through the use of codes, so that only those for whom the information is intended can read and process it.

In computer science, cryptography refers to secure information and communication techniques derived from mathematical concepts and a set of rule-based calculations called algorithms, to transform messages in ways that are hard to decipher. These deterministic algorithms are used for cryptographic key generation, digital signing, verification to protect data privacy, web browsing on the internet, and confidential communications such as credit card transactions and email.

Modern cryptography concerns itself with the following Three objectives:

1. Confidentiality: the information cannot be understood by anyone for whom it was unintended

2. Integrity: the information cannot be altered in storage or transit between sender and intended receiver without the alteration being detected

3. Authentication: the sender and receiver can confirm each other’s identity and the origin/destination of the information

Recommended algorithm:

When you have the freedom to choose which algorithm to use (such as when you do not require compatibility with a third-party system), we recommend using the following algorithms:

Class

Recommendation

Cipher

AES in either CBC or GCM mode with 256-bit keys

MessageDigest

SHA-2 family (eg, SHA-256)

Mac

SHA-2 family HMAC (eg, HMACSHA256)

Signature

SHA-2 family with ECDSA (eg, SHA256withECDSA)

The following sections include snippets that demonstrates how you can complete common cryptographic operations in your app.

Context context = getApplicationContext();MasterKey mainKey = new MasterKey.Builder(context)        .setKeyScheme(MasterKey.KeyScheme.AES256_GCM)        .build();String fileToRead = "my_sensitive_data.txt";EncryptedFile encryptedFile = new EncryptedFile.Builder(context,        new File(DIRECTORY, fileToRead),        mainKey,        EncryptedFile.FileEncryptionScheme.AES256_GCM_HKDF_4KB).build();InputStream inputStream = encryptedFile.openFileInput();ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();int nextByte = inputStream.read();while (nextByte != -1) {    byteArrayOutputStream.write(nextByte);    nextByte = inputStream.read();}byte[] plaintext = byteArrayOutputStream.toByteArray();byte[] plaintext = ...;KeyGenerator keygen = KeyGenerator.getInstance("AES");keygen.init(256);SecretKey key = keygen.generateKey();Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5PADDING");cipher.init(Cipher.ENCRYPT_MODE, key);byte[] ciphertext = cipher.doFinal(plaintext);byte[] iv = cipher.getIV();

Generate a digital signature

You need to have a PrivateKey object containing the signing key, which you can generate at runtime, read from a file bundled with your app, or obtain from some other source depending on your needs.

byte[] message = ...;PrivateKey key = ...;Signature s = Signature.getInstance("SHA256withECDSA");s.initSign(key);s.update(message);byte[] signature = s.sign();

Example: Ola app

Major Bug in Ola App can Make you Either Rich or Poor! — Appknox | Mobile App Security, Resources…

Despite the hiccup caused by the recent ban on cab aggregators, India’s cab-hiring app market continues to grow at…

blog.appknox.com

Appknox scanned the Ola app and discovered major weaknesses in how cryptographic keys were used. They discovered that the cryptographic key used was “PRODKEYPRODKEY12“. The same key was also used to encrypt passwords which means that users other accounts where they were reusing passwords might have been at risk as well.

The researchers were able to intercept requests between the app and the server, fake request for money and receive the money.

Ø M6 Insecure authorization

Authorization is the function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular.

Authorization gives those users permission to access a resource.

· Authorization is a process by which a server determines if the client has permission to use a resource or access a file.

· Authorization is usually coupled with authentication so that the server has some concept of who the client is that is requesting access.

· The type of authentication required for authorization may vary; passwords may be required in some cases but not in others.

· In some cases, there is no authorization; any user may be use a resource or access a file simply by asking for it. Most of the web pages on the Internet require no authentication or authorization.

Might include:

ü failures in authorization
(authorization decisions in the client side, forced browsing, etc.)

ü able to execute over-privileged functionality.

It is distinct from authentication issues (e.g., device enrolment, user identification, etc.).

Example: Viper smart start

Remote smart car hacking with just a phone.

tl;dr: Calamp which provides the backend for a lot of really well known car alarm systems had a misconfigured reporting…

medium.com

A security researcher discovered that the Viper smart start failed to correctly authorize users. After you log in to the server it was possible to change the id number of the car and gain access among other things the car’s location. It was also possible to change data about the car and open the car remotely.

Ø M7 Client code quality

Catch-all for code-level implementation problems in the mobile client.

Might include:

· buffer overflows,

· format string vulnerabilities,

· various other code-level mistakes where the solution is to rewrite some code that’s running on the mobile device.

· Avoid asking the unnecessary Permissions.

· Memory Leakage

Apply Lint and Obfuscation

Ø M8 Code tampering

Tampering is the process of changing a mobile app (either the compiled app or the running process) or its environment to affect its behavior.

Ø Binary Patching

ü Patching is the process of changing the compiled app, e.g., changing code in binary executables, modifying Java bytecode, or tampering with resources. This process is known as modding in the mobile game hacking scene. Patches can be applied in many ways, including editing binary files in a hex editor and decompiling, editing, and re-assembling an app. We’ll give detailed examples of useful patches in later chapters.

Ø Code Injection

ü Code injection is a very powerful technique that allows you to explore and modify processes at runtime. Injection can be implemented in various ways. Code injections happen when a piece of software is deliberately modified to insert a module of code, generally malicious, that performs an unintended operation. These unintended operations can range from data stealing, to user surveillance among others. Hence, in this particular case, it is particularly important that applications are signed. An application that has been signed from a trusted manufacturer will not contain injected code. Avoid them with Obfuscation or by applying ProGuard rules.

Example: Pokemon GO

How Pokémon Go Fans Hacked ’Em All: And How to Prevent Similar Reverse-Engineering | Nordic APIs |

Every developer hopes for huge user bases populated by large amounts of monthly users. People using an application to…

nordicapis.com

Fans reverse engineered the application, fed wrong geolocation data and time to find rare pokemon and make eggs hatch faster. A website was created that showed the location of every pokemon on a map, which changed the game dynamics quite a lot.

Website that displayed location of every pokemon

This hack might not seem as dangerous as the ones above but it or how Niantic handled it still cost the company reputation and users.

Ø M9 Reverse engineering

Might include analysis of the final core binary to determine its

ü source code,

ü libraries,

ü algorithms and other assets.

Reverse engineering makes it easier to exploit other vulnerabilities in the application. It can reveal information about backend servers, cryptographic constants and ciphers, and intellectual property.

Example: other examples above

I decided to not include a separate example, since reverse engineering was used on most examples listed.

Ø M10 Extraneous functionality

an attacker seeks to understand extraneous functionality within a mobile app in order to discover hidden functionality in in backend systems.

Might include:

ü hidden backend functionality,

ü other internal development security controls not intended for production environment.

How to Prevent?

ü The best way to prevent this vulnerability is to perform a manual secure code review using security champs or subject matter experts most knowledgable with this code.

ü Examine the app’s configuration settings to discover any hidden switches;

ü Verify that all test code is not included in the final production build of the app;

ü Examine all API endpoints accessed by the mobile app to verify that these endpoints are well documented and publicly available;

ü Examine all log statements to ensure nothing overly descriptive about the backend is being written to the logs;

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store