Please consider donating:


BlackHatEU2013 – Day1 – Hardening Windows 8 Apps for the Windows Store

The first talk after having lunch at BlackHat Europe 2013, title “Hardening Windows 8 Apps for the Windows Store” is delivered by Bill Sempf (@sempf). Usually, the first slot after lunch is not really a gift to speakers as attendees tend to be busy digesting lunch at that time.  Perhaps the absence of slides during the presentation might help keeping people awake :)

Bill starts his presentation by interacting with the audience and asks who has played with Windows 8 and/or has done development on Windows 8.   He explains that the start screen is really cool if you have a touch enable device.  If you are using a regular laptop/desktop, you’ll probably going to skip this start screen and go back to Windows 7 mode.  Bill started writing apps for Windows 8 since the OS got released and is author of the “Windows 8 application development for dummies” book.

There are 3 ways to build a Windows Store app.  You can build .Net applications, Windows ASP.Net, WPF applications etc in Windows 8, using C++ or C#.  Silverlight apps, however, are gone.  The Windows 8 start screen tiles are Windows 8 Apps, based on WinRT.  Although this is fundamentally different than Silverlight, it’s quite easy to make the move to WinRT.  Keep in mind that there are significant limitations to what you can do from WinRT.  In fact, you don’t have access to sockets. You can connect to port 80 and 443, but that’s about it.  You can’t connect to a SQL server, read email.  You don’t even have access to the filesystem in a way this is possible in normal “traditional” applications.  On the other hand, the development environment comes with a large number of templates that help lowering the barrier to get started with WinRT development.   In addition to C++ and C# to write WinRT apps (both using XAML), you can also use Javascript, which is now closely integrated with WinRT using the WinJS engine.  In fact, at least half of the applications in the Windows store today are written in JavaScript, Bill says.

As the number of applications in the Windows Store increases, the use of Windows 8 will become a reality in the enterprise, which means we’l have to deal with it eventually.

From a WinRT login perspective, all you need is a Microsoft account (similar to the iTunes account for Apple, or your GMail account for Android). The Windows RT environment has APIs that allow applications to access this login information from within an application.

Bill explains that in WinRT, calls to a service shouldn’t take longer than 15 seconds. If they do, you’ll need to handle communication and actions asynchronously.  Unfortunately, the demo didn’t work because of internet connectivity issues.

“Capabilities” are subject to the Windows Store policy. They will cause popups and request the user to “accept” a message before a certain action can occur. If you are looking at app store applications, make sure to review the list with capabilities and their settings.  When developing an application, start with “no capabilities” and turn them on one by one, until the application works.

“Declarations” are the opposing side of “Capabilities”. Declarations allow you to define what type of access the application needs from the OS.  Even if apps don’t know anything about each other, can still work together by setting them as a “share” target. If you enable your app to be a “share” target, you’d better provide the code to handle this properly, Bill explains.  The “Evernote” app is a good example on NOT how to do this.

Applications need to be able to store “stuff” somewhere.  Apps may use “cookies” or “config files” that need to get updated at runtime. SInce WinRT doesn’t really have access to the traditional filesystem, the apps need to use Windows.Storage.ApplicationData. One of the ways to store data is by using  “roaming settings” (which essentially tells Windows to save the data in the cloud, hosted at Microsoft… somewhere… we think).  Traffic seems to be encrypted, Bill continues, but this might still be a privacy issues, especially because you don’t really know where the data is stored. In fact, by looking at the traffic, Bill noticed that some of the data gets actually stored at Google.  If you’re using the “localStorage” technique to store data, keep in mind that everything is stored in plain text xml.  If you want to make it safer, you’ll have to use online “services” instead, so you can store/retrieve data over http/https.  Combine this with the fact that people expect to be mobile, this means you’ll have to expose these services to the internet to make this work.

From a Windows App testing perspective, Bill continues, this means you’ll probably should focus on testing these service first, just like any other web application. You could use OWASP Zed Attack Proxy (ZAP), which is free, or Burp if you have a license.  The WinRT dev environments comes with anti XSS libraries enabled. Bill mentions that it might be possible to bypass this XSS protection library. In other words, think of the App to be a web app that interacts with a service.  This means tests for SQL Injection / JSON injection…  Also, do a code review. Do not set  .innerHTML but use .innerText instead to avoid XSS issues inside your app.

WinRT comes with support for hashing/encryption, through crypto.CryptographicBuffer.

In addition to using the Windows account to log on to WinRT, you can also take advantage of OAuth functionality.  OAuth will take over the entire authentication portion of the application. All you need to do is call OAuth (Windows.Security.Authentication.Web.WebAuthentication) and WinRT will take care of everything for you.

Applications will just die on unhanded exceptions, without giving away stack trace information.

Finally, code defensively. It’s trivial to get the source code of  your apps because they are stored locally (c:\Windows\WindowsApps) and not obfuscated by default.  With WinJS code, you don’t even need to use a decompiler, because the code is stored in a .js file. Don’t store secrets or hardcode keys in your code.


  • Choose your storage carefully
  • Test the service layers
  • Apply least privilege (Capabilities / Declarations).  Don’t click all the things :)
  • Code defensively




© 2013, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.

Comments are closed.

Corelan Training

We have been teaching our win32 exploit dev classes at various security cons and private companies & organizations since 2011

Check out our schedules page here and sign up for one of our classes now!


Want to support the Corelan Team community ? Click here to go to our donations page.

Want to donate BTC to Corelan Team?

Your donation will help funding server hosting.

Corelan Team Merchandise

You can support Corelan Team by donating or purchasing items from the official Corelan Team merchandising store.

Protected by Copyscape Web Plagiarism Tool

Corelan on Slack

You can chat with us and our friends on our Slack workspace:

  • Go to our facebook page
  • Browse through the posts and find the invite to Slack
  • Use the invite to access our Slack workspace
  • Categories