Security Considerations in the Windows Phone 8 Application Environment

Microsoft's latest flagship, mobile OS.

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:

  • Application Data Protection
  • Application Interaction
  • Platform API/Code Security
  • Supporting Infrastructure Security
  • Transmission Security

Application Development

Applications for Windows Phone 8 can be developed in either native (C++/WinRT) or managed languages (C#) using the Windows Phone 8 development SDK. HTML5/JavaScript is not currently supported, unlike Windows 8 metro applications. This allows WP8 developers to use platform APIs to develop feature-rich applications for the platform. There is a large amount of developer documentation available including platform APIs.

Security Considerations

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.

Application Data Protection

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 theWindows Phone Dev Center.

Application Interaction

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 willprevent 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.

Platform API/Code Security

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.

Supporting Infrastructure Security

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.

Transmission Security

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.

Key Recommendations

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

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.

Application Source Code Reviews

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.

Manual/Automated Application Testing

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.

Infrastructure Testing

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.



Accreditations & Certificates

MWR is an accredited member of The Cyber Security Incident Response Scheme (CSIR) approved by CREST (Council of Registered Ethical Security Testers).
MWR is certified under the Cyber Incident Response (CIR) scheme to deal with sophisticated targeted attacks against networks of national significance.
We are certified to comply with ISO 9001 and 14001 in the UK, internationally accepted standards that outline how to put an effective quality and environmental management systems in place.
MWR is certified to comply with ISO 27001 to help ensure our client information is managed securely.
As an Approved Scanning Vendor MWR is approved by PCI SSC to conduct external vulnerability scanning services to PCI DSS Requirement 11.2.2.
We are members of the Council of Registered Ethical Security Testers (CREST), an organisation serving the needs of the information security sector.
MWR is a supplier to the Crown Commercial Service (CCS), which provides commercial and procurement services to the UK public sector.
MWR is a Qualified Security Assessor, meaning we have been qualified by PCI to validate other organisation's adherence to PCI DSS.
As members of CHECK we are measured against high standards set by NCSC for the services we provide to Her Majesty's Government.
MWR’s consultants hold Certified Simulated Attack Manager (CCSAM) and Certified Simulated Attack Specialist (CCSAS) qualifications and are authorized by CREST to perform STAR penetration testing services.