Device Backup Jepordizes App Data
All mobile device’s include data backup capabilities. In most cases two forms of backup exist local and cloud based. Local backups are performed when mobile devices are connected to home PCs over USB and cloud based backups occur continuously on the mobile device using Wi-Fi or Cellular connections. Backup solutions store all kinds of sensitive data completely unknown to the mobile applications that may own it. As a result, sensitive data is essentially replicated to devices out of the control of the application or organization (BYOD). Regardless of whether an application’s data is encrypted or unencrypted at rest, it is all backed up. This includes all data stored within apps, emails, and attachments.
Device backup is a requirement by all users of personal mobile devices due to the sensitivity of irreplaceable data they commonly possess (contacts, photos, etc). Device and data backup ensure that if the device is lost/stolen or the owner upgrades a device their data and apps can be easily transferred. Provided the frequency of these events, backups are performed regularly by all mobile devices. Individual applications or an enterprise simply cannot disable the functionality due to this requirement and basic platform capabilities that afford no ability to do so.
Cloud Based Backup
iCloud and Google Cloud are the two most popular cloud-based backup capabilities afforded to iOS and Android devices. Mobile cloud backup services are generally free for all users, enabled by default when shipped, and available with a paid subscription for additional storage capacity. Cloud backup is always on and stores device data in a remote location accessible from anywhere in the world with an internet connection. Cloud backup is the most convenient form of backup as user involvement is minimal, it is also the most dangerous for installed applications.
All mobile devices support some method of traditional local backup. Local backup automatically transfers data when a mobile device is connected via USB to a computer such as a home workstation to sync music or explicitly backup. In contrast to cloud solutions, local backups store all data on the destination device it’s connect to, in most cases the destination device, such as home PC, is less secure than any cloud based datacenter and exposes the data to all conventional risks of workstation computing.
Backup data commonly includes:
Photos and videos
iMessage, text (SMS), email, and MMS messages
Cloud Backup Risks
When using a cloud based solution backup data is ultimately protected via a username/password defined by the device owner during cloud setup. Applications and organizations (BYOD apps) have no visibility into the security of these credentials, the frequency of backup, or the composition of backup data. Currently, there exists no ability for organizations to enforce cloud backup usage or cloud password complexity. Unlike the original application-level password, a user’s cloud password may vary significantly in complexity and exposure to compromise. User cloud credentials are used for many purposes that greatly increase the risk of capture, such as buying music, buying apps, logging into apple.com or google.com, and obviously the cloud solution itself.
Multiple attack vector exist that allow an attacker to gain access to a target user’s Cloud backup (CEO, CFO, etc) and expose plaintext application data or application level encrypted data. These attacks result in the recovery of the user defined cloud credentials. Since cloud backup solutions don’t require physical access to anything, the user’s cloud credentials allow an attacker to compromise a mobile device from across the world. The following is a brief list of methods used by attackers to acquire Cloud backup credentials from mobile devices in addition to standard phishing attacks:
This vulnerability allowed an attacker to simply reset a user’s iCloud password online and recover all data.
iOS email vulnerabilities can be leveraged to display fake iCloud login prompts to users through attacker email campaigns.
A tool was recently released capable of brute forcing accounts again with no access to the device, through bypassing Apple’s online iCloud password attempt limiter.
DNS servers can employ tricks to bypass a device locked with iCloud; devices are commonly locked with iCloud when lost or stolen.
Local Backup Risks
Local backups reduce the risks associated with remotely accessible storage through the use of local storage on workstations owned by the mobile device user. This reduction in exposure is meet by a decrease in the security of the actual backup files. Security controls on home PCs provide significantly less security than that of a cloud provider datacenter. In most case these are greatly inferior to that of the mobile device where the data originally resided or corporate standards (BYOD). Users do have the option of encrypting backups using their mobile device passcode, but by default data is unencrypted. On Apple iOS if a user elects to encrypt backups using a passcode iOS will actually store even more sensitive data.
iTunes doesn’t encrypt your backups by default. To encrypt a backup in iTunes for the first time, you’ll need to turn on the password-protected Encrypt Backup option. After you turn on Encrypt Backup, iTunes automatically makes encrypted backups for that device from then on. An encrypted iTunes backup includes certain information that other backups don’t: Saved passwords, Wi-Fi settings, Website history, and Health data.
While a mobile device PIN/password complexity can be controlled via enterprise BYOD solutions, commercial applications have no visibility – therefore passcode encrypted backups cannot be relied upon. The security and volume of destination devices in which the data is replicated on is uncontrollable and unknown. The use of local backups increases exposure by replicating the data to devices that are relatively unattended, insecure, used by a variety of users (e.g., home PCs).
What does this mean for BYOD?
Data stored within BYOD applications, such as a secure container, are treated the same as any other application on the device and therefore backed up to a Cloud datacenter or locally to non-corporate device. In most cases secure container solutions store data encrypted at the application level, thus requiring an encryption key commonly derived from the application-level password. While technically encrypted, this encryption is always reliant on a secure application-level password. Unless an organization’s secure container solution (e.g., Good, AirWatch, MobileIron) requires that users employ productivity-robbing 6 character alphanumeric upper/lower case passwords, data is at risk if any backup solution is in use on the device. BYOD applications perform encryption in software, unlike the hardware-based operating system encryption that was shaved off during the backup process. Encryption performed in software is prone to accelerated brute force. Given the difficulty in entering complex passwords on mobile keyboards, mobile passwords and the keys derived from them are relatively simple and cracked offline very quickly. See how Sentegrity augments password based encryption with transparent authentication.
Commercial applications succumb to the same risks. BYOD applications are generally designed with some level of security consideration. Commercial applications are developed with extreme variances in security controls. A vast number of sensitive commercial applications, such as mobile banking, may not encrypt any local application data – therefore sensitive banking information such as account numbers may be inadvertently backed up to a remote repository in plaintext. In this situation, the user’s online banking credentials are invalidated as the data has now been automatically replicated and is only protected by the user controlled cloud credential.
Encryption is not the answer
As outlined BYOD apps that perform encryption are not safe from this threat. Any level of encryption whether it be application or operating system level is vulnerable. Once a backup is recovered by an attacker, all data unencrypted or encrypted on the device (such as emails, text/SMS, voicemail, and MMS) is in jeopardy of breach. The application’s security configuration comes under extreme scrutiny as the only barrier between data breach. In addition to any custom application-level encryption, the manner in which the mobile app was configured to store data on the OS itself can determine its fate. For example, iOS devices always store a copy of the coveted “keybag” during backup. The “keybag” is a sensitive file where apps and the operating system store encryption keys or other passwords in a centralized manner.
Complete Class Key: An OS level classification and key used to decrypt and encrypt application data when the device is unlocked and locked. Under normal operation when the user unlocks the device, the operating system accesses the hardware encryption module embedded in the phone which includes a unique ID to derive this key. This key is then used to decrypt files of this classification on the device. During backup this key is replicated outside of the hardware and made accessible in the “keybag”.
First Authentication Class Key: An OS level classification and key used to decrypt sensitive files the first time after a reboot. This classification affords capabilities without having the user enter a device passcode, allowing applications to run/refresh in the background on a locked device, or provide features to the OS such as when a call is received on a locked device. During backup this key is replicated to the destination.
No Class Key: A blank OS key used to decrypt data that has no specific encryption class elected. This data is backed up in plaintext via a cloud or local solution. This means both portions of the operating system and third party applications who have opted for this class are instantly vulnerable to breach from a backup file.
Regardless of the encryption class employed by an application an attacker with access to backup data, can access the key bag and extract encryption keys to decrypt the device and various data. For example, data once protected by the user’s passcode can be decrypted without any knowledge of the actual passcode since the key was backed up. Applications must be aware of backup settings to avoid undermining the security of their data when it is unknowingly replicated. In this example data can be decrypted without ever knowing the user’s password due to a basic backup setting.
Consumer devices cannot be controlled, and commercial applications or enterprise BYOD programs cannot mandate how personal devices are backed up or used. This type of attack vector is rarely considered by an organization or application developer. Sentegrity employs comprehensive trust measurements that afford insight into a variety of device configurations, including iCloud, fully abstracting an organization and app from even considering all the threats their mobile data may face.
Trust measurements reflect a device’s unique security posture; a device employing any form of data replication such as local backup or iCloud impacts the TrustScore accordingly. Sentegrity’s mobile security experience lead to the creation of the “Device Backup” TrustFactor. Trust Measurements prevent organizations and applications from having to know or understand any threat their application faces.