OWASP MOBILE TOP 10 : Insecure Communication - Tutorial Boy -->
Home
Mobile Pentest

OWASP MOBILE TOP 10 : Insecure Communication

Introduction

When designing a mobile application, data is commonly exchanged in a client-server fashion. When the solution transmits its data, it must traverse the mobile device’s carrier network and the internet. Threat agents might exploit vulnerabilities to intercept sensitive data while it’s traveling across the wire. The following threat agents exist:
  • Exploitability: Easy
  • Prevalence: Common
  • Detectability: Average
  • Impact: Severe

Attack Vector

The exploitability factor of monitoring a network for insecure communications ranges. Monitoring traffic over a carrier’s network is harder than that of monitoring a local coffee shop’s traffic. In general, targeted attacks are easier to perform.

Security Weakness

Mobile applications frequently do not protect network traffic. They may use SSL/TLS during authentication but not elsewhere. This inconsistency leads to the risk of exposing data and session IDs to interception. The use of transport security does not mean the app has implemented it correctly. To detect basic flaws, observe the phone’s network traffic. More subtle flaws require inspecting the design of the application and the application's configuration.

Impact

This flaw exposes an individual user’s data and can lead to account theft. If the adversary intercepts an admin account, the entire site could be exposed. Poor SSL setup can also facilitate phishing and MITM attacks.

Insecure data may result in the following business impacts:
  • The network layer is not secure and is susceptible to eavesdropping.
  • The mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.
  • The mixed SSL sessions may expose the user’s session ID.

Prevention

Developers need to be very aware that there are also background processes going on which can store personal data that they may not know about.

It is crucial to see how they handle the following types of features :
  • 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).

Implementation

The prominent characteristics include packaging up some kind of sensitive data and transmitting it into or out of the device. Some examples of sensitive data include encryption keys, passwords, private user information, account details, session tokens, documents, metadata, and binaries. The sensitive data can be coming to the device from a server, it can be coming from an app out to a server, or it might be going between the device and something else local (e.g., an NFC terminal or NFC card). The defining characteristic of this risk is the existence of two devices and some data passing between them

IOS Specific Best Practices

Default classes in the latest version of iOS handle SSL cipher strength negotiation very well. Trouble comes when developers temporarily add code to bypass these defaults to accommodate development hurdles. In addition to the above general practices:
  • Ensure that certificates are valid and fail closed.
  • When using CFNetwork, consider using the Secure Transport API to designate trusted client certificates. In almost all situations, NSStreamSocketSecurityLevelTLSv1 should be used for higher standard cipher strength.
  • After development, ensure all NSURL calls (or wrappers of NSURL) do not allow self-signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate.
  • Consider using certificate pinning by doing the following: export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert.

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 that extends SSLSocketFactory, make sure the checkServerTrusted method is properly implemented so that the server certificate is correctly checked

Summary

Owasp mobile security provides you with a good overview of different mobile security threats, including related mobile device issues and threats. You can use this as an internal security baseline for mobile application development practices. With time you should update it with your internal processes to ensure secure SDLC practices are inherent to your development and deployment processes.

Post a Comment