Please take a moment to read http://bit.ly/demandglobalchange, to help share the message and support the initiative to tell our leaders to focus on addressing the global world problems, instead of complaining about the effects of their lack of leadership. Be a leader yourself, and share this with as many people as possible. #demandglobalchange // https://www.facebook.com/demandglobalchange



Please consider donating: https://www.corelan.be/index.php/donate/


1,173 views

HITB2012AMS Day 1 – WinRT The Metro-politan Museum of Security

WinRT : The Metro-politan Museum of Security

Sébastien Renaud and Kévin Szkudlpaski start their talk by introducing themselves.  They both work as Security Researcher at Quarkslab, focusing on reverse engineering, dissecting network protocols and file formats. They will talk about the Windows Runtime, the foundation for the Metro platform in Windows 8.

The agenda for this talk contains the following items.

  • Windows 8
  • WinRT – Applications & Components
  • WinRT – Internals
  • Windows Store
  • Sandbox
  • Conclusions

Windows 8

Sébastien explains that their research started out of curiosity for the new Windows 8 operating system. They wanted to look at the Windows 8 and diff the Windows 7 RTM kernel versus the Windows 8 DP (Developer Preview) Kernel.  During the research, they discovered an interesting new API.

Windows 8 has a new UI, called Metro.  The start button has disappeared in the Windows 8 Desktop.   WinRT is the backbone of Metro apps and introduces a new programming model.

Metro apps, Sébastien continues, are only distributed through the Windows Store.   They are executed in an “App Container”, which means:

  • secured through a sandbox
  • severely limited resources access, and explicit permissions needed
  • Uses a restricted subset of .Net and Win32 API’s.

WinRT – Applications & Components

Windows 8 provides a layered approach to develop and run applications.  There’s a variety of development environments and languages you can use for Metro applications.

20120524 103811

Applications get installed per user. You don’t need to have administrative privileges to install/run those applications.  They are packaged (*.appx) for deployment. The package is signed, compressed, contains ALL needed files and can target multiple platforms (x86, x64, ARM).

To install an application, you’ll need to visit the Windows Store. Inside the package, there’s an AppxManifest.xml file, which describes the application registration, including Application, Capablities and Extensions definitions.  The manifest contents get mapped into registry keys, stored under HKCU. The application itself gets stored somewhere under the Windows.Launch extension.

Capabilities define what the app can do or what it needs to access:

  • Network: Enterprise auth, client, server & client, Intranet, Text Messaging, etc
  • File System: Document, Pictures, Music, Video
  • Devices: Location (GPS), Mic, Proximity, Removable Storage

Class & Extension are basically “Catalogs”

  • Extension : “I implement this contract” (e.g. Launch)
  • Class: describes the WInRT classes (a concrete implementation)

WinRT – Internals

An Application automatically implements the “Launch contract”.

System queries the extension catalog to find the right extension. Explorer.exe queries the extensions catalog, checks if it’s  the right object to activate, and activates it.  Activation means : a request is sent to RPCS, which checks if the process is already running or not, sends request to DCOM launch service (which runs as System) and the app is started.

Sébastien explains how the WinRT base works and that is has a couple of layers before projecting itself into a language. He shows a sample C++ application that uses  WinRTComponent() and shows the various methods and vtable breakdown that is part of objects used in the sample application.  He moves to the asm listing for the application and shows the instructions used to reference virtual function pointers from the vtable.

Windows Store

Kevin jumps in and explains the purpose of the Windows Store.   Microsoft decided to force you to go through the store to download WInRT applications.   Signing is mandatory, so Microsoft will control all apps.   When an app is verified by MS, you need to make sure

  • it is linked with SAFESEH, DYNAMICBASE and NXCOMPAT
  • it doesn’t hang or crash
  • doesn’t use any forbidding API.

Of course, you can use shell coding tricks to find the base of an API and call it that way.  Even if you can execute code (CreateProcess for example), everything still runs within the AppContainer context.  It’s also important to know that you can’t prevent syscalls from being executed.

The AppContainer uses an additional PE flag.

Sandbox

A sandbox is a mechanism to isolate untrusted processes, Kevin explains.   In most implementations, it will isolate a process that runs with limited rights, uses a broker that will execute specific actions for the isolated process.  Sandboxing techniques use Restricted Tokens, Jobs, multiple Desktop/Workstations, and Low integrity levels (available since Windows Vista), preventing you to write to a higher-level integrity process and to change your privileges.

Chrome vs WinRT

Kevin continues by explaining why comparing both sandboxes is interesting. The Chrome sandbox is designed for security only, and the WinRT AppContainer is made for running applications.

Chrome uses a restricted SID, most of the SID groups are disabled and isolation relies on job and desktop (Windows XP) and integrity level (vista and up). Microsoft uses LowBox, which is a modified _TOKEN structure, and uses a new syscall NtCreateLowBoxToken to create a very limited token.   The SepAccessCheck API was slightly modified to support the changed structure.

Chrome implements the broken and isolated processes within the same executable (chrome.exe)  It uses some kind of fork() to differentiate, and implements its own access policies. LowBox, the MS implementation, uses COM.

From an IPC point of view, Chrome uses API hooking to easily sandbox a process (thru a closed source plugin) and performs checks on the parameters.  The broker and the sandboxed process uses some shared memory.  In LowBox, each request is a COM object and uses an ALPC port to transport marshaled COM objects (NtAlpcSendWaitReceive)

Conclusions

WinRT has a new design and new API.  The technique relies on COM technology.  The AppContainer provides some level of isolation, transparent to users & developers (implement ed inside the kernel), and the isolation is implemented in the kernel as well, which makes it easy to implement.

Interesting talk, good to see Microsoft is stepping up and providing easy ways to implement sandboxes in Windows 8.

2012, Corelan Team (corelanc0d3r). All rights reserved.

Related Posts:

Comments are closed.

Corelan Live training

Since 2011, Corelan GCV has been teaching live win32 exploit dev classes at various security cons and private companies & organizations.

You can read more about the training and schedules here

Demand Global Change

The world needs your help !

Please take a few moments to read the "Demand Global Change Call For Action" document at
http://bit.ly/demandglobalchange
Read the full document at
http://bit.ly/demandglobalchange_full and share the message with as many people as possible.

Like the Facebook page, and SHARE it with everyone you know.



Donate

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.

Protected by Copyscape Web Plagiarism Tool

Corelan Team Merchandise

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

Corelan on IRC

You can chat with us and our friends on #corelan (freenode IRC)

Categories