Thank you for your interest in our newsletters. You will receive an email shortly to confirm your subscription.
Alex Plaskett, Head of Technical Research and Dr David Chismon, Security Consultant
10 mins read
Windows Phone 8 is Microsoft’s latest flagship OS for mobile devices, containing a number of security features to protect data.
Whilst security research has been performed into Windows Phone 7, very little has been published about Windows Phone 8. This article aims to provide an overview of the security considerations to bear in mind when developing third party applications on the platform.
The following key high-level areas should be considered:
Whilst Windows Phone 8 has a large number of security controls, mistakes can be made in the development process which expose the third party application to higher risk. By considering the following key areas in the development and assessment process, this risk can be mitigated.
Windows Phone 8 provides several mechanisms for protecting data stored on the device. Firstly, WP8 has BitLocker full disk encryption, which protects the entire storage medium on the device and includes the isolated storage containers used by applications. This prevents an attack on the physical flash chips trying to bypass device restrictions. However, if an attacker has compromised the WP8 operating system, all data will appear unencrypted. WP8 is expected to be more resilient to so-called ‘cold boot attacks’ as it has a verified boot chain which should prevent booting into other operating systems, the technique used in the FROST toolkit for Android. However, an important issue with BitLocker is that it is currently not possible for an individual to enable it, as it requires an enterprise ActiveSync connection or device management policy to do so.
Nevertheless, it is possible to encrypt an application’s data in addition to the protection provided by BitLocker. Microsoft recommends using the “protect/unprotect” methods provided by the Data Protection API (DPAPI), as these manage key creation and storage. In this way, applications have individual keys, so they can only access their own data. The key is protected by the WP8 OS, meaning that developers do not have to try and protect it themselves. However, should an attacker exploit the OS and gain administrator or SYSTEM level privileges out of the application sandbox, they would be able to obtain the keys. The DPAPI protect mechanisms are intended for protecting data such as passwords and database connection strings. If developers wish to protect more information, they should store the data in a SQLCEdatabase and apply a password, as this automatically protects the database with AES encryption. The password to the database can then be stored using the DPAPI.
Unfortunately, WP8 does not support other mechanisms, such as the SecureString class, so data that is present in RAM may be obtainable by attackers, particularly if they have high-level access as provided by an exploit. This may be a way for attackers to obtain passwords, i.e. by intercepting them in memory once decrypted by DPAPI. However, currently, no public vulnerabilities exist through which to perform this attack and it would require a break in the sandbox security to do so, therefore the difficulty of this type of attack is high.
More information can be found on encrypting data in Windows Phone applications on the Windows Phone Dev Center.
Whilst Windows Phone 7 offered no mechanisms for direct app-to-app communication, Windows Phone 8 supports limited app-to-app communication in the form of file and protocol handlers. In this way, WP8 is more akin to IOS than Android, which implements several inter-process communication mechanisms (that are the source of the majority of security issues in apps). WP8 applications are able to register file extensions and protocols that they will handle. If a file of that type is opened, or a link for that protocol clicked, the registered application will open. WP8 will prevent registering certain filetypes and protocols and if multiple applications have registered for a particular file type or protocol, the user will be presented with a choice.
Once a file has been selected, the app receives a notification with a GUID that it can use to copy the file from an OS-provided ‘SharedStorage’ into its own ‘Isolated Storage’. An app could therefore communicate by writing the communication to a file with the extension of the target app and then ‘opening’ the file. The target app can then read out the contents of the file. Alternatively, an app can register to handle a protocol, and so, calling a URL such as “myapp://StuffToPassToApp” will cause MyApp to receive the contents of the string. So, for example, opening the URI bingmaps:?cp=40.726966~-74.006076 will open bingmaps centred over New York.
Security issues can arise because any app on the device is able to send any content they choose via a file or protocol handler and that content may not be parsed or handled safely by the receiving app. For example, consider an application that used the contents of a protocol URI to perform a database lookup: it may be possible to cause deletion of the data or worse if the URIincludes SQL command characters.
Because Windows Phone 8 supports both managed and native code, there are different vulnerability classes to be considered. Managed applications are often found to misuse platform APIs or be vulnerable to injection style attacks. For example, Push Notification and embedded WebBrowser control need to follow security best practices.
Although there are no public exploits currently demonstrating issues against native code, these applications can be vulnerable to corruption and memory lifecycle issues. Whilst there are many security controls built into the compiler and OS, memory corruption vulnerabilities could still expose an application to excessive risk and therefore should still be considered when implementing native code.
Mobile applications are often supported by web service/cloud infrastructure which provides the application with the data necessary for its operations. Mobile applications often contain similar problems to thin client applications where security controls are implemented in the client side but not in the server side. By tampering with the client, it is often possible to perform unauthorised actions. It is therefore imperative that end-to-end testing is performed on mobile applications, including their supporting infrastructure. Any vulnerability there can expose end users of the mobile application to significant risk.
Microsoft provides best practice guidelines for Web Service security on the Windows Phone Dev Center.
Windows Phone 8 has the ability to send traffic over both secure and insecure channels. The transport security mechanisms in place are used to provide a secure connection between two endpoint devices, the client (being the mobile handset itself) and any of the servers with which it communicates. Windows Phone 8 cipher suit offers a number of ciphers to support secure communication. No weak ciphers are supported by the platform’s SSL implementation by default, and all ciphers are at least 128-bit strength. However, when deciding on the transport mechanism for an application, care should be taken to ensure that encryption is used to protect sensitive data in transit.
A problem with mobile applications on other platforms is that developers often disable certificate checking to use self-signed certificates whilst in development, and then do not re-enable this functionality in production. On Windows Phone 8, there is currently no well documented way of doing this, and, whilst it still may be possible to accomplish with significant manipulation of the platform, it is not a typical issue associated with Windows Phone 8 applications (in comparison with Android and iOS).
More information on communication in Windows Phone 8 can be found on the Windows Phone Dev Center.
A number of processes can be introduced into the software development lifecycle of Windows Phone 8 applications which can significantly enhance their security.
Threat modelling of Windows Phone 8 applications should be performed to highlight possible threats to the application. The mitigations documented in the threat model can then be used to perform penetration testing to verify that they are effective. Having threat modelling documentation available before performing penetration testing greatly increases its effectiveness in identifying gaps in the security model. More information can be found here.
Source code reviews of Windows Phone 8 mobile applications should be performed to highlight any development issues which could impact security. It is recommended that white box security assessments are performed, because the security features of WP8 (such as application encryption/obfuscation) make black box assessments a significantly time-intensive process with its restricted visibility and control over the platform.
Whilst a source code review helps eliminate a number of classes of vulnerability, some issues are difficult to identify through this method alone, such as complex state machine issues and parsing bugs. Manual and automated testing, such as file format fuzzing or web service request manipulation, should be performed to ensure vulnerabilities in this area are identified.
Mobile applications are often supported by web service infrastructure, which is critical to the security of Windows Phone 8 applications. It is therefore recommended that hardening and testing is performed against any infrastructure supporting mobile applications.