Tuesday, 27 March 2012

Windows 8 App Container Security Notes - Part 1

Windows 8 is coming and with it Metro and a revised application sand-boxing model. We plan to do a series of posts over the next few months summarising what we discover about AppContainer or App Container (Microsoft seem to flick between the two terms). This introductory post is really a summary of the information we've gleaned from the Internet and SDK into a single coherent resource.

Note: As this is all subject to change prior to release what is true today may not be accurate tomorrow. All of Microsoft's documentation is stamped '[This documentation is preliminary and is subject to change.]'. The same should be said for this post as well.

What is App Container? 

App Container was introduced formally via the recent post by Microsoft titled 'Understanding Enhanced Protected Mode'. In this post Microsoft states:
"Windows 8 introduces a new security sandbox, called AppContainer, that offers more fine-grained security permissions and which blocks Write and Read Access to most of the system. There’s not a lot of documentation specifically about AppContainer because all Metro-style applications run in AppContainers, so most of the documentation is written from that point of view. For instance, here’s a page that describes the capabilities that a Metro-style application can declare that it needs: http://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx. Under the covers, it’s the AppContainer that helps ensure that an App does not have access to capabilities that it hasn’t declared and been granted by the user."
Distilling this down they've introduced a high-level capability model that translates to a more restricted version of low integrity processes. Going further than before in restricting IPC between processes, file access and event loopback network access.

Example Constraints with the new Capabilities

A Japanese blog in October last year documented the constraints from early Microsoft documentation. These are:
  • By default, an app can access only its AppData folder (including local, roaming, and temp sub-folders, all of which are deleted when a user uninstalls an app).
  • To directly access anything else through APIs, such as media libraries or documents, an app must declare that intent in its app manifest or a user must grant access by explicit action. Otherwise the APIs used to access the file system will fail.
  • Access to devices and sensors, especially webcams, microphones, and geolocation sensors, are also protected. Unless the app declares its intent, which is visible to users within the Store, the app will be denied access to those resources at runtime.

Integrity Levels and App Container

App Container is actually its own integrity level. This can be seen in the screen shot below:

Click for larger image

Mozilla have done an excellent job at documenting some of the new broker processes:
"The other child processes of svchost are the RuntimeBroker which is in charge of accessing privileged data or devices on behalf of regular metro apps and wkspbroker which is the "Remote app and desktop connection runtime broker". To sum up, svchost and wkspbroker.exe are not metro apps but metro support infrastructure." 
The Mozilla team also made this observation:
"Another difference is that named kernel objects of an AppContainer process are in a different namespace. For example, in this case the regular 'interactive user' session is session 3 so a regular named object 'Foo' from a traditional desktop application will be "\Sessions\3\BaseNamedObjects\Foo" which is what we see for IE10, while for metro apps it would be:
Were w,x,y,z are are part of a unique SID which is neither the interactive user SID or the user logon SID. In fact, it seems to be some kind of per-application id. " 
This enumeration is possible via the function  GetAppContainerNamedObjectPath.

Identifying an App Container Compatible Binary

So there appear to be two key ways to identify an App Container compatible binary. 

The first is through the DLL Characteristics in the PE header (note: Microsoft haven't issued updated PE COFF specifications to include this yet). This characteristic is set via the Microsoft linker using /APPCONTAINER:[NO] (Visual Studio 2011 and above).

How can we verify this? Well if we look inside C:\Program Files (x86)\Windows Kits\8.0\App Certification Kit\AppContainerCheck.dll we see.

ImageOptionalHeader optionalHeader = item.PE.OptionalHeader;
  if (optionalHeader != null)
   ushort num = (ushort)optionalHeader.GetField(ImageOptionalHeader.Fields.DllCharacteristics);
   if ((num & 4096) != 0)
    checkResult = CheckResult.Passed;
    additionalInfo.Add(Resources.Information, Resources.ImageAppContainer);

The second way to identify App Container applications is through their manifest. The Visual Studio 2011 GUI provides a break down of the capabilities (more on these later) and allows them to be modified. What this translates too is something like:


SIDs and Tokens

Windows is a world of SIDs and Tokens. So it should come as no surprise that both have been used to support the App Container model.

New SID Constants

Microsoft have defined two new sets of SID constants to support App Container. The first of these are App Container SID Constants

The second set are the Capability SID Constants. These define if the resulting SID will have the capabilities such as being an Internet Client, Server (or both), access to Pictures, Music, Documents, Shared Certificates or Removable Storage.

App Container Tokens

Microsoft Windows is where the token is king. Some tweaks have occurred to tokens in order to support App Containers. 

At a high-level the AuthzGetInformationFromContext function can be used with a AUTHZ_CONTEXT_INFORMATION_CLASS enumeration with an enum of AuthzContextInfoAppContainerSid to retrieve a TOKEN_APPCONTAINER_INFORMATION  structure. There is also a setter function by the name of AuthzSetAppContainerInformation.

A token verification function capable of handling App Containers is CheckTokenMembershipEx It allows the caller to specify CTMF_INCLUDE_APPCONTAINER, which according to Microsoft will:
"allows app containers to pass the call as long as the other requirements of the token are met, such as the group specified is present and enabled"

These are the changes in WinNT.h that reflect the above compared to the Windows 7a SDK:
// Application Package Authority.

#define SECURITY_APP_PACKAGE_AUTHORITY              {0,0,0,0,0,15}

#define SECURITY_APP_PACKAGE_BASE_RID               (0x00000002L)
#define SECURITY_APP_PACKAGE_RID_COUNT              (8L)
#define SECURITY_CAPABILITY_BASE_RID                (0x00000003L)
#define SECURITY_CAPABILITY_RID_COUNT               (5L)

// Built-in Packages.


// Built-in Capabilities.

#define SECURITY_CAPABILITY_INTERNET_CLIENT                     (0x00000001L)
#define SECURITY_CAPABILITY_PICTURES_LIBRARY                    (0x00000004L)
#define SECURITY_CAPABILITY_VIDEOS_LIBRARY                      (0x00000005L)
#define SECURITY_CAPABILITY_MUSIC_LIBRARY                       (0x00000006L)
#define SECURITY_CAPABILITY_DOCUMENTS_LIBRARY                   (0x00000007L)
#define SECURITY_CAPABILITY_REMOVABLE_STORAGE                   (0x0000000AL)

#define SECURITY_CAPABILITY_INTERNET_EXPLORER                   (0x00001000L)

The shared user certificates capabilities and the associated changes with storage are explained here.


Several networking changes to support isolation.

Firewall Changes for App Container

Microsoft has introduced some new structures to the in-built Firewall to support App Containers. 

Network Isolation

Windows 8 introduces the concept of network isolation (.docx). This brings with it a raft of new functions, we wont list them all but the interesting ones in our mind (for attack surface enumeration) are:
The network isolation features rely the new capability SID constants to allow an application to be:
  • Internet client
  • Internet Server
  • Private network client
If you need to grant an exemption to an application to allow it to speak over loop back then the network isolation document / Fiddler blog post shows how it can be done:

To Make Your App Exempt by Package ID (SID)

%windir%\system32\CheckNetIsolation.exe LoopbackExempt –a –p=S-1-15-2-4125766819-3228448775-2449327860-2490758337-1264241865-3581724871-2122349299 
To Make Your App Exempt by Appcontainer Name

%windir%\system32\CheckNetIsolation.exe LoopbackExempt –a –n=stocks_mw26f2swbd5nr 
To Remove the Exemption for a Specific App by Package ID

%windir%\system32\CheckNetIsolation.exe LoopbackExempt –d –p=S-1-15-2-4125766819-3228448775-2449327860-2490758337-1264241865-3581724871-2122349299 
To Remove All Exemptions (For All Apps)

%windir%\system32\CheckNetIsolation.exe LoopbackExempt –c 
To See All Apps that are LoopbackExempt

%windir%\system32\CheckNetIsolation.exe LoopbackExempt –s

Windows Filtering Platform

The Windows Filtering Platform is described by Microsoft as:
"Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for creating network filtering applications. The WFP API allows developers to write code that interacts with the packet processing that takes place at several layers in the networking stack of the operating system."
This too has seen some support added for App Containers. There are now two additional filtering condition flags:
  • FWP_CONDITION_FLAG_IS_APPCONTAINER_LOOPBACK - Tests if the network traffic is AppContainer loopback traffic.
  • FWP_CONDITION_FLAG_IS_NON_APPCONTAINER_LOOPBACK - Tests if the network traffic is non-AppContainer loopback traffic.

App Container Profiles

Microsoft have created two support functions for the creation and deletion of App Container profiles. These are:

These functions are exported by UserEnv.dll (not present in Windows 7). It should be noted that a quick hunt through IDA shows these are just stub functions for CreateAppContainerProfileWorker and DeleteAppContainerProfileWorker in ext-ms-win-profile-userenv-l1-1-0.dll.

Some other interesting enumeration functions, again for attack surface analysis, are (the names are pretty self explanatory):
Anyway that's it for the first post, we hope you find it useful...

Further Reading / Links

No comments:

Post a Comment