Sharks in the Moat

by Phil Martin

  Side channel data leakage occurs when sensitive or private data is accessed in an unauthorized manner from unintended locations such as web caches, temporary directories, log files or screenshots. These locations are referred to as a side channel. iOS backgrounding, jailbreaking and keystroke logging can lead to a side channel disclosure of information that should have remained secret.

  There are several steps to mitigate this weakness. Caches must be encrypted, and anti-caching directives should be used for browser-based apps. All communication channels should be audited to ensure information leakage is not occurring. Sensitive information such as credentials should never be logged, and the same information should be removed from the screen before the app is backgrounded. Keystroke logging by field should be disabled, and the app should be debugged in general to see the various files that are created, written to or modified when the app is running.

  Reverse engineering is the process of running a mobile app through a decompiler, debugger, or disassembler. This act can quickly reveal weaknesses such as hardcoded keys, passwords or simply the internal architecture in general. The only mitigation for this type of activity is to try and obfuscate the code, but this is an example of security through obscurity and is not really security at all. Instead, we should take Kerckhoffs principle to heart and assume the source code will eventually get out. This forces us to implement secure code and to hide these sensitive data elements in secure locations. Never try and hide sensitive or private data inside of the app binary!

  Mobile DOS or DDoS

  A denial of service attack, or DoS attack, is the act of causing some resource to become unavailable, compromising one of the tenets of CIA. This is usually carried out by overwhelming a resource with a barrage of bogus network traffic such that it can no longer respond to legitimate requests. While a DoS is typically launched from a single host which limits its impact, a distributed denial of service attack, or DDoS attack, is carried out by many hosts and is limited only by the number of hosts involved and the bandwidth available to each. DDoS attacks are usually executed by an army of zombie computers, or computers that have been previously compromised and co-opted by an attacker. While it is possible to launch a DoS attack against a mobile device, that is somewhat of a wasted effort as the impact is almost negligible. Much more devastating is to use multiple mobile devices to launch a DDoS attack.

  Script kiddies can often launch a DDoS attack, and it is amazingly easy to migrate existing malware to work on mobile devices for this purpose. Beyond taking out a single remote target, mobile DDoS attacks can also cause congestion in the carrier network, causing an outage to other users. This two-for-one disruption makes mobile devices even more tempting to use as a zombie.

  Another aspect of mobile networks is the push notification capability that all carriers provide. In this case, a notification is pushed to devices from a central server. Unfortunately, an attacker can use this capability to flood the communications channel and cause a DoS scenario. Additionally, push notifications can be used to fake a message asking the user to install software that is really disguised malware. Thinking the message came from the carrier, the user is much more likely to follow the instructions.

  Broken Authentication

  Broken authentication occurs when credentials have been compromised in a way that allows an attacker to gain access to features or data. While an insecure design and implementation is the root cause of such a weakness, there are multiple ways to make this mistake. The use of basic authentication in which credentials are sent in clear text using Base-64 encoding is a common mistake when using SOAP services. Storing a password in clear text on a device is also quite common, with anyone having physical access to the device able to steal the password.

  At times, architects will try and get clever and use some type of unique identifier to represent a device instead of asking the user for credentials. For example, the IMEI uniquely identifies a physical device, while the IMSI is a unique number on the SIM card. Both values can easily be spoofed by an attacker, so this approach should never be used. In fact, some OSs are now preventing access to such information to discourage their use.

  If a password must be stored on a device, which is not an uncommon requirement to prevent reauthentication each time the app is loaded, it should be stored in an encrypted fashion only, with the encryption key being properly protected in a secure container. For more secure needs, don’t worry about inconveniencing the user by

  asking for reauthentication each time the app loads – even from being backgrounded. The complete mediation principle should always be obeyed for both local and remote resources.

  Bypassing Authentication

  To allow an app to kick-off another app, mobile OSs implement some type of mechanism to ask the OS to start an unrelated app. In iOS such a capability is called a URL scheme, and with Android it is called an intent. In these cases, a URL protocol is used to launch the action. For example, an email may contain a phone number, which if pressed, can launch the dialer app and automatically connect a phone call. By crafting a URL protocol to dial a 900 number, the attacker can get the carrier to charge the user’s account for the call. The displayed phone number does not have to be the number called, so if the user is not watching, they may not be aware of what is going on. The same technique can be used to launch any app, including Skype or another app that dials a number. This same vulnerability can be exploited by an iframe injecting HTML into another frame.

  To combat this type of behavior where another app might try to abuse our own app, explicit user permissions must be requested, and an app must not implicitly trust URL schemes or intent invocation code.

  Improper Session Management

  Man-in-the-middle attacks, or MITM attacks, are carried out by inserting yourself in between two communication endpoints and stealing data as it passes by. Because you are inserted into the middle of a channel, you can also alter data before passing it on. In this manner you might be able to steal session identifiers and use them in your own crafted messages, thereby gaining unauthorized access to data or capabilities. This can happen all without either party being any the wiser.

  The use of MITM attacks with mobile devices has become so prevalent that the term Man-in-the-Mobile, or MITMo, has been coined. MITMo attacks enable an attacker to intercept and ‘replay’ session tokens. Since these attacks often leverage malware, they are sometimes called ‘Malware-in-the-Mobile’.

  The primary countermeasure for this type of attack is to secure all communication channels, including the carrier network, Wi-Fi, Bluetooth and NFC. Out-of-band transaction verifications can be very useful. For example, when a mobile app is ready to execute a highly-sensitive activity, the backend server might generate a one-time token and send it via SMS to the device. This code must be entered before the transaction is executed.

  Session tokens should be generated with a high degree of entropy, or randomness, and the backend should have the ability to abandon a token at any time.

  Client-Side Injection

  SQL and command injection attacks are well-known threats for web apps, but the same vector can be used to attack mobile apps. In the case of a mobile device, a malicious user gains access to the UI and enters injection text into client-side fields, which are processed on the device or on a backend server.

  In either case, proper validation of input fields is the primary countermeasure. If possible, the app should make use of browser libraries that carry out validation, as these libraries are frequently updated with the latest techniques to recognize and defeat injection attempts.

  Jailbreaking and Sideloading

  While the term jailbreaking is mostly used with iOS, it is applicable to any proprietary OS which has been altered to allow unauthorized apps to be installed, thereby bypassing restrictions put in place by the carrier or device manufacturer. Jailbreaking itself is an exploit that takes advantages of an OS vulnerability.

  Sideloading applies to open source operating sy
stems, such as Android, and allows the installation of apps that are not officially sanctioned by the app store, such as Google’s Play Store. The OS itself allows such a behavior by flipping specific settings but comes with substantial risks.

  Both jailbreaking and sideloading can result in a number of risks, such as the following:

  The device can experience decreased stability, since unauthorized apps normally do not follow the best coding practices. This might involve poor memory management or decreased battery life.

  It might void the warranty since most mobile devices do not support jailbroken devices. Should the device require repairs in the future, the manufacturer may refuse.

  It might result in a bricked device, meaning the device has been rendered completely unusable and cannot be restored to a working state. An unstable jailbreaking process can often leave a device in this state.

  It might result in the owner being locked out from the official app store. Apple does not allow jailbroken devices to download apps from the official app store, and users of jailbroken devices will have to depend on other avenues to get apps. Cydia is the best example of an alternative to the Apple App Store.

  Jailbroken devices are usually much more vulnerable to malware and rootkits and are more likely to wind up being used as a zombie in an attack. Companies should prohibit the use of jailbroken or sideloaded devices that connect to the company infrastructure.

  One last note - if you are going to ignore all of these warning and still jailbreak or sideload a device, then at least change the root password to reduce the chance of being exploited!

  Mobile Malware

  Malicious apps are on the rise, even those downloaded and installed from supposedly safe app stores. The most common attacks compromise weaknesses in NFC, block update to the device, or extort money from the user by using ransomware. There are now mobile phone development kits that allow unsophisticated hackers to create native apps without even knowing how to write an actual app!

  Secure Guidelines and Principles

  Let’s end this section on mobile security by going over a few principles that should be followed by all mobile app developers. The Smartphone Secure Development Guidelines for App Developers, published by the European Network and Information Security Agency, or ENISA, provides some decent bullet points to follow as a checklist:

  Identify and protect sensitive data on the mobile device

  Handle password credentials securely on the device

  Ensure sensitive data is protected in transit

  Implement user authentication, authorization and session management correctly

  Keep the backend APIs (services) and the platform (server) secure

  Secure data integration with third party services and applications

  Pay specific attention to the collection and storage of consent for the collection and use of user’s data.

  Implement controls to prevent unauthorized access to paid for resources (e.g., wallet, SMS, phone calls, etc.)

  Ensure secure distribution/provisioning of mobile applications

  Carefully check any runtime interpretation of code for errors

  OWASP also provides some fairly excellent guidelines for mobile app development that you should be familiar with.

  Technologies

  The security principle of leveraging existing components applies not only to software but to technologies as well. In addition to reducing work load, this approach provides security benefits as well. Similar to the mindset of “Don’t roll your own security algorithms!”, by using proven technologies we inherit the increased scrutiny these technologies have been put through.

  Authentication

  Put simply, authentication is the process of verifying the genuineness of a subject’s identity. This can be accomplished using something you know, something you have, and something you are.

  The Security Support Provider Interface, or SSPI, abstracts calls to authenticate and allows developers to leverage it without understanding the complexities of the authentication protocol. SSPI provides a pluggable interface so that any number of authentication technologies can be leveraged, but by default supports the following:

  SPNEGO, a protocol that negotiates the best security protocol

  Kerberos, a mature delegation model

  SChannel, which allows data to be securely transmitted

  Digest, which protects credentials using hashing

  Using this approach is much better than writing a custom implementation from scratch.

  Identity Management

  Identity management, or IDM, is the combination of policies, processes and technologies for managing information about digital identities. This applies to both humans and non-humans, such as networks, servers, applications and services.

  User identities will be primarily one of two types – insiders, such as employees and on-site contractors, and outsiders such as partners, vendors and customers. IDM answers the following questions:

  Who or what is requesting access?

  How are they authenticated?

  What level of access can be granted based on the security policy?

  Figure 116: The IDM Life Cycle

  The IDM life cycle covers everything from identity provisioning, management and de-provisioning as shown in Figure 116.

  The provisioning process is where we create digital identities. At first glance this may sound pretty simple, but when an organization has multiple systems that need to work together, identities can get messy if the process is not automated. However, automating such a process requires very careful design as roles must span multiple systems. Now, individual privileges, or permissions, or even sometimes called entitlements, can be unique to a given system but should be tied to a role that multiple systems share.

  When managing identities, we are referring to the following activities:

  Renaming an existing identity

  Adding or removing roles to an identity

  Adding or removing privileges for a given role, also called entitlement management

  Keeping access rights in-line with changing regulatory requirements and policies

  Auditing successful and unsuccessful access attempts

  Synchronization of multiple identities for access to multiple systems

  It is important to record any activity that renames an identity, and to maintain a history of activity before and after the identity was renamed. For example, if a personal email address is used as the primary identity, users may periodically wish to switch the email address used. In this case, we must preserve all activity previously carried out using the old email address and merge it with activity being performed under the new email address. Otherwise, we have hampered the ability to claim non-repudiation.

  De-provisioning activities are primarily concerned with terminating access to all systems for that identity, including the appropriate notifications. Access termination will be carried out by either deactivating an account or deleting it entirely. Keep in mind that if we delete an account, we will no longer be able to go back and see what that account was up to, as all history will probably also be deleted. Therefore, it is usually better to deactivate an account for a period of time as dictated by security policies, and then delete it later. Some regulatory compliance rules may not allow us to delete an account. However, a deactivated account can be reactivated by an attacker, and represents a risk that we must address.

  The Sarbanes-Oxley Act 404 section requires that controls be reviewed at least once per year, and identity and access controls are no different. Access certification, or reviewing and approving existing access entitlements, needs to be carried out as part of this process.

  Let’s cover a couple of the technologies IDM commonly uses.

  Directories

  A directory is a repository for identities, used to locate users and discover more information about them, such as office location and phone number. A directory may use its own internal database to store the information, or hook into
external systems and aggregate the information for use by a consumer. When software is designed to integrate with a directory, it usually uses the Lightweight Directory Access Protocol, or LDAP. If you have ever heard of the X.500 protocol, LDAP replaced it. The biggest boost to productivity that directories provide is that it acts as a central place to store and maintain identities, preventing each application or system from having to implement their own silo’d version of identity management. Some of the more popular directories in use are Tivoli, Sub ONE, Oracle Internet Directory, Active Directory, Novell eDirectory, OpenLDAP and Red Hat Directory Server.

  Metadirectories and Virtual Directories

  When identities are stored in multiple locations, it can be a challenge to ensure they all stay synchronized. For example, we might have an LDAP directory along with a legacy application that manages its own identities. To keep the two in-synch we need some way to automatically synch both systems. Enter a metadirectory, which automates the synchronization and can handle some limited transformation of data between different formats as well.

  Unfortunately, Metadirectories do not expose an interface that can be programmatically invoked. That is why virtual directories were invented. A virtual directory exposes identity data through a service so the identity can be transformed into a claim that applications can understand. Virtual directories are more capable than Metadirectories as they can act as gatekeepers and ensure data being used is authorized and compliant with a security policy.