Open Mobile Menu


Five Reasons Your Windows 8 Application Needs a Penetration Test

Views: 3072

Written By: Bill Sempf December 19, 2013

The market is working its way slowly into the next phase of the mobile space, and Windows is a part of it with Windows 8 and the Windows Store. Microsoft has made the barrier to entry very low for Windows Store apps, making use of Visual Studio, C# (or C++) and XAML, as well as a new HTML and JavaScript stack. Developers have a lot of options and familiar tools to work with. The billion-installed-user base is going to be a significant draw, and like it or not your organization will be making or consuming Windows 8 apps in the future.

Regardless of whether you are a builder or a user, you need to know that the risk surface of a Windows 8 app is surprisingly wide and deep. Here I’ll go over five considerations for pentesting your apps before they go in the store (or looking at the ones you are using that you got from the store).

If you don’t review your code, someone else will

They can see your code. Anyone who installs an app can see the HTML and JS, or in .NET at least the XAML (although dotPeek will give you a pretty good look at the binary as well).

Getting to the code

Files for installed apps are in C:\Program Files\WindowsApps, which is 'hidden' so make sure you have 'View Hidden Items' turned on. This folder isn't accessible by the governing user even if you are running as the administrator, which you shouldn't be. The easiest way to get access to the folder is to take ownership of the folder and everything in it.  You can do this with Powershell if you like.

Get-ChildItem 'C:\Program Files\WindowsApps' -recurse | ForEach-Object {Get-Acl $_.FullName}

But is remarkably easy to do in the UI, so that is how I did it.  Right click on C:\Program Files\WindowsApps and select Properties, then click on the Security tab. From there you can click Advanced to get the Advanced Security Settings.

Click the Change link and then type in your Microsoft Account email address. Then press enter, OK, and OK again to close all of the dialog boxes. From there you can easily navigate to any installed apps.

Open one of these, Barnes and Noble’s Nook software for instance, and you can see that the file structure is just as it would be in Visual Studio.

Figure 1: Source of Barnes and Noble’s Windows Store app

From there you can browse at will. As expected, apps written in C++ or .NET are compiled EXEs, although the XAML is still browsable. Nothing that a small dose of dotPeek won't fix, I am sure. I'll leave that as an exercise for the reader.

The implications

What are the implications of all of this? Vulnerabilities are a significant amount easier to find when the source code is available. For a web application, even when it is largely JavaScript enabled, some processing is done on the server. In a Windows Store app, there is no such option.

For some apps, there may be some consideration for keys to services such as Google, Bing or other service providers.  For instance, we are using Weather Underground in an app I am developing, and the client's use key is right there in the settings.js file. Usually, that would be accessed server-side in a regular web app, and apparently we are going to have to do something similar for the Windows 8 app. One possible solution would involve wrapping external services in your own service layer and then accessing those to get the values provided by the original service.

There has been some discussion of changing code, recompiling using the provided key, and getting access to for pay content or disabling ads. I am not a fan of ripping off developers (being one myself) so I won't go into that here. It could be a very significant detriment to those seeking to monetize apps, however.

The most significant issue, as usual, is lack of developer awareness. If the developer doesn't realize that all of their code is easily browsable, then they may make poor decisions in the construction, commenting or production of the code base.

Identity is baked into Windows Store apps

Unlike Android or iOS apps, Windows Store apps are identity-aware. Apps can use Windows Live or OAuth for baked-in identity information. Poorly written applications have the potential to take advantage of identity information that isn’t appropriate for the app, and the user might not even know that such information is accessible to the app. For instance, personal phones, photos, and friend information is available from the more advanced Windows Live permissions. If your users are bringing their own devices, and logging in with their company Microsoft accounts, this is something you should know about.

Windows Live

Generally, your login for a Windows 8 system that’s not on a domain is your Microsoft Account, formerly Live or Passport login. For many users this is the key to a lot of different services, like HotMail, SkyDrive, MSDN and TechNet for technicians, social networking, and more. The WinRT API gives a developer an easy way to leverage this information with Live Connect.

While the Live Connect service is an awesome feature, it seems like a very ripe Cross-Site Request Forgery target to me. This isn’t something you need to harden your apps against, but the ease with which a malicious app might be able to make use of users’ credentials seems like something to take into consideration when setting up the policy for your organization.

When the user installs the app, the installation process asks the user what information they are willing to share. If the app developer changes that information, and then redeploys to the store, and the user updates, the app does not make it clear that the information access has changed. While I don’t have a cool code sample of this, I encourage you to try it. This seems to be a dramatic flaw in the identity management of Windows Store apps, and should be considered when selecting an identity system.


Apps that don’t use Windows Live for login often will use OAuth from another provider, like Facebook or Twitter. This does make the developer’s life a LOT easier as the OAuth standard interaction and service calls are baked into the WinRT API.

The application hands control over to WinRT, which will handle the framing under the covers, as shown in the next image:

Figure 2: Using OAuth in Windows Store apps

Doing this gives the users the benefit of single-sign-on without putting their Windows Live information at risk. It could be a great way to provide identity integration to your users, especially if the added features of a specific provider is useful in your app.

Storage doesn’t work like you think it does

Windows 8 apps can store data in a variety of different ways, which can lead to security vulnerabilities, often via information disclosure or tampering. Services can be peeked at, remote settings are going who-knows-where, and local HTML5 databases are all editable by the user.

Local Settings

The local storage in Windows.Storage isn’t that much of a big deal – apps keep local data all the time. It’s the other kinds of local storage that I am concerned with – specifically data which is kept in HTML5 storage.

SessionStorage, LocalStorage, and WebSQL all work in Windows Store apps. They all make use of a database that is stored locally and can be accessed easily with Windows Explorer.

LocalSettings in particular is troublesome, because most developers think of it as protected, but it is not. A quick look with procmon shows the location of an editable XML file in the Application Data directory tree. Storing high scores (or account numbers) in there is a bad idea.

Remote Settings

This one freaks me out a bit, even though I haven’t found a way to exploit it. A developer can use Windows.Storage.ApplicationData.current.roamingSettings to save values ‘somewhere’ that a user can then pick up in the same app in the same user account on another machine.

This is clearly sending information to Azure and storing it with my Microsoft account and app ID. Don’t you just think it’s strange that this data is just going somewhere, where the app developer and end user have no control at all, and then getting pulled back for later use?

Looking at WireShark, you can see where the send and receive happen to

Figure 3: Wireshark results for remoteSettings

A man in the middle attack can’t easily get access to the encrypted TLS data, but either way, isn’t there a privacy consideration when storing my apps data who-knows-where?

Service Communication is very visible

Web applications went ‘service oriented’ in the middle of the 2000s, embracing first SOAP, and then ReST, as the business layer communication medium. This was beneficial to development managers because shared functionality could be easily orchestrated without complex standards like COM+ or CORBA. The services were constrained by the firewall and consumed by the web server, which would render the pages before delivery to the client.

As the mobile revolution spawned, these same services were gradually repurposed to support iPhone and Android apps. Previously internal services were poked through the firewall, and accessed directly.

Now, with Windows machines using these services, the likelihood that attackers are going to look at the services using a proxy will dramatically increase. It is trivial to analyze and attack service calls that are made by Windows 8 apps, and if the same services that used to support the web site are now supporting the Windows Store apps, testing is significantly more important.

HTML5 comes with its own vulnerabilities

Cross site scripting is a common flaw in web applications, but it is just as possible in a Windows Store application. As usual, the key is sanitizing your inputs. Code Review should catch flaws like this, but it requires a careful and thoughtful review.

From the code review perspective, anytime user input is handled on either end, it needs to be reviewed. Sanitize inputs and outputs. It’s not that tough. The kicker is that it is currently VERY tough to smoke test a Windows 8 application. The testing I did for this sample was ALL manual, copying and pasting from RSnake’s XSS cheatsheet.

Cross Site Scripting isn’t the only place developers can get into trouble with JavaScript. For instance, performing an Eval with data that is provided by a user in the payload is always a bad idea, but it can create utter havoc in a cloud based Windows 8 application. Fortunately, eval and execUnsafeLocalFunction (both supported in Windows 8) are easy to search for in the codebase.

In conclusion

Windows Store apps are fairly well isolated from the operating system, but the security and privacy considerations of the platform development are worth considering. Windows Store apps should undergo a detailed security assessment before go-live and after any major changes. A few parting things to remember:

  • Code Defensively
  • Choose Storage Carefully
  • Test Your Service Layer
  • Apply Least Privilege 

Secure coding practice will keep your developers out of trouble mostly, but a solid understanding of the platform is necessary to discover all risks. AppSec Consulting’s Windows 8 experience can help you make good decisions about your Windows Store experience.

Bill Sempf

Bill Sempf is a software security architect. His breadth of experience includes business and technical analysis, software design, development, testing, server management and maintenance, and security. In his 20 years of professional experience he has participated in the creation of well over 200 applications for large and small companies, managed the software infrastructure of two Internet service providers, coded complex software happily in every environment imaginable, tested the security of all natures of applications and APs, and made mainframes talk to cell phones. He is the author of C# 5 All in One for Dummies and Windows 8 Programming with HTML5 For Dummies; a coauthor of Effective Visual Studio.NET and many other books, a frequent contributor to industry magazines; and has recently been an invited speaker for the ACM and IEEE, BlackHat, CodeMash, DerbyCon, BSides, OWASP, the International XML Web Services Expo and the Association of Information Technology Professionals. Bill also serves on the board of the Columbus branch of the Open Web Application Security Project, and is the Administrative Director of Locksport International.

read more articles by Bill Sempf