Stronger Windows 8 Still Vulnerable Through Apps, Users

UEFI and Secure Boot

With Windows 8, Microsoft introduces Secure Boot, which allows the boot sequence to be secure and trusted. For cryptographic verification of the boot components, the firmware is required to maintain:

• A “signature database” of signers or image hashes of Unified Extensible Firmware Interface (UEFI) applications/drivers and operating system loaders that can be trusted
• A “revoked signatures database” that includes signatures for items that can no longer be trusted

Here is a representation of how the secure-boot process works:

 

For PC and device makers to carry the “Designed for Windows 8” logo, they now must enable by default the UEFI with secure-boot support. Although Windows 8 will boot on systems with a standard BIOS, the system will not be allowed to carry the “Designed for Windows 8” logo.

This requirement has generated a lot of debate in the open source (especially Linux) community. Any lockdown of the OS can cause the installation of various distributions to become more complicated and cause of concern for users.

Microsoft will support signing for other OS vendors at a nominal cost, so that these vendors can build an OS that boots into systems designed for Windows 8. Fedora has announced plans to use this service. Ubuntu has not announced plans to buy into this service but will require manufacturers with “Ubuntu certified” hardware to include its key in the UEFI signature database. The Linux Foundation has published its own recommendations on how to make UEFI secure boot work with open platforms.

For ARM-based platforms Windows 8 will support booting only on UEFI-enabled systems.

UEFI will provide a very trusted boot sequence. Each component in the boot process validates the next one before it loads and executes.

ELAM Driver

The popularity of Windows means the operating system must support a huge number of devices. Windows requires non-Microsoft drivers (for input and output devices) to reach a usable stage, and Windows must trust those third-party drivers early in the boot process. This trust has been exploited by malware over the years to insert malicious drivers while booting. Such exploitation causes great problems because a compromised boot sequence renders the system unreliable, and requires significant help from antimalware solutions to repair and recover.

One protection mechanism introduced in Windows 8 is the early-load antimalware (ELAM) driver. This ensures that at least some antimalware software is running on the system as soon as possible. ELAM software assists boot-time protection by helping verify other drivers as they load, improving the secure boot process.

All ELAM drivers must be signed by Microsoft to help maintain trust. The data is stored in the registry hive, as that is the only persistent storage available for ELAM.

Although ELAM drivers are a significant improvement over the state of Windows 7, it is not clear how much they will benefit security. There are strict performance requirements for these drivers and their main purpose is only to validate signature data that is requested during the boot sequence. With variants of malware appearing every day and sophisticated targeted attacks striking organizations, signature verification does not provide comprehensive or proactive protection against such threats.

Sideloading and AppLocker

Businesses can install custom Metro-style applications on Windows without publishing these to the Windows Store. This is called sideloading, designed for organizations to deploy custom applications within their environments. There are certain requirements for sideloading:

• The application must be cryptographically signed
• The certificate used for signing the application must be installed and trusted by the system
• Group policy to allow trusted applications must be set
• To run the application the computer must be joined to a domain

Administrators can use AppLocker to prevent applications from being installed. They may create rules based on various conditions—including publisher, package name, and package version—and control centrally administrated systems. AppLocker provides a reactive and significantly limited mechanism to manage and enforce policy for organizations.

Take-Out Windows

Microsoft has introduced Windows To Go, a supported enterprise-grade OS deployment system that allows Windows 8 to boot from a USB drive—without requiring any of the Windows components to be preinstalled on the hardware that the USB drive is connected to.

Windows 8 will install drivers relevant for the hardware on which it boots for the first time (without requiring a reboot). Subsequently, it will boot directly to the OS and store the hardware profile information on the USB drive. This method also allows the USB drive to be secured using BitLocker.

Windows to Go is not supported on ARM platforms, and there are a few differences from the standard Windows install:

• Hibernate and Sleep are disabled by default
• Internal hard disks on the host computer are offline by default
• A preboot password replaces the Trusted Platform Module for the BitLocker drive encryption
• If you need to recover your Windows to Go drive or reset it to its original state, you will need to reimage the drive with a fresh copy of Windows because the Windows Recovery Environment is not available

The AppContainer

New in Windows 8 is AppContainer, a new sandbox/jail/process-isolation mechanism for applications. Metro apps executing in AppContainer run at “low-integrity” level. AppContainer provides or denies access to capabilities an application requests.

AppContainer benefits application developers, as they know that process isolation will reduce the risk their applications pose to the system while protecting their applications from tampering by other Metro applications.

Metro and Windows Desktop Apps

With Windows 8, desktop and Metro applications coexist to maintain backward compatibility with current Windows desktop applications. Windows also allows desktop applications to be installed and executed outside the usual constraints of Metro applications. This presents an interesting situation: Metro apps cannot get out of their sandbox; but desktop apps can enter the sandbox.

In our tests we found that process-enumeration APIs were accessible to Metro apps, but they returned only limited results. But the same APIs used by desktop apps displayed all the applications, including Metro, started by that user. This is no surprise because desktop applications are not restricted by any AppContainer.

It’s interesting that we were able to inject code from a desktop app inside an executing Metro app; neither application was running with any elevated privileges and the injected code executed without any errors.

This function presents a host of security risks for app developers handling sensitive or confidential user data in this environment.

Windows Credential Providers

Additional Windows Credential providers have been built and ship by default within Windows 8. These include gesture and PIN-entry based (different from regular passwords) based credentials in addition to the current set in earlier versions of Windows. The primary changes are in relation to the user interface changing from users selecting an authentication method then the user account for logging in to selecting a user account then an authentication method. This again reflects the user-centric changes being made to Windows.

Internally new interfaces have been introduced to support these changes as well as some new guidelines around the enumeration of user accounts.

Metro vs. Android

Windows 8 Metro application security and the Microsoft Store remind us a lot of Android apps and security. Let’s compare the security of each, especially the application permissions. On Android, users are prompted to review permissions and approve them before an application is installed, but that adds little value because users generally speed through the buttons to get the app working.

Here is a side-by-side comparison between the two:

Android Apps	Windows 8 Metro Apps
Application Vetting
Rogue applications have made it into Google Play (formerly Android Market) and to user devices. Because new apps can be available within minutes, there may be little, if any, manual verification.	Microsoft claims to review all apps before they appear. The Windows Store follows a strict set of requirements that aim to prevent advertising-only apps.
Non-Standard Installation Routines
From any publisher’s website. User must do a one-time “allow unknown sources” configuration change. From email attachment: mail client displays “Install Now” button.	Possible via command line. Requires a trusted certificate installed on the target machine and the app signed via that certificate. The system must be joined to a domain.
Signatures
All apps must be signed or they will not install.	All applications must be signed or they will not install.
Users can create self-signed certificates. No certificate authority is needed.	Apps need a root certificate trusted by the system. Non-Microsoft-signed applications must be joined to a domain.
Interapplication Isolation
All apps are isolated from each other by user permission on folders associated with the app folder.	All apps are isolated from each other and cannot directly access each other’s data folders.
Developers can create multiple applications with the same user ID to allow access to each other’s folders.	Interapplication interfaces must be defined for exchanging data between applications.
Common storage locations can be accessed by declaring permissions.	Common storage locations can be accessed by declaring permissions.
Storage Organization
A unique user is created for each installed app. Can be a shared user if the app developer chooses. For shared user, multiple apps can access app’s local storage. If MODE_WORLD_WRITABLE or MODE_WORLD_READABLE is specified for files, they become accessible to other apps.	Fully unrestricted access only in the app’s own local storage folder.
Download folder is located within publicly accessible directory.	User’s download folder has write-only access to the app, which can create new files and folders. As soon as file is closed, it is no longer available to the app.
Apps must request access to locations. Either an application has access to files or not. The system doesn’t provide access to file data if the application doesn’t have permissions to access the files.	Apps that don’t require unrestricted access to the file system can use the file-picker dialog to prompt users to select files. Windows 8 also provides a most-recently-used list for apps to access; this allows fully restricted apps to reopen a file that a user has allowed the app to open.
All apps can read system settings. Changing them requires permission in the app manifest (WRITE_SETTINGS).	Metro apps have no access to the registry.
An app requests access to an SD card, and can add, remove, or modify contents.	An app can access on removable storage only associated file types listed in the manifest. The app cannot access removable storage on HomeGroup PCs.
Application Permissions
Permissions that an app requires must be declared. The app is restricted to those listed.	Permissions that an app requires must be declared. The app is restricted to those listed.
System permissions include mount/unmount file system, retrieve information about running apps, format external storage, or kill other apps.	None of the documented capabilities provides system-level access to Metro apps.

 

As with every version of Windows, we see various kernel improvements. With these changes to the OS, Microsoft has made a safer environment for users. But this environment is still vulnerable to the following security risks:

• Socially engineered emails or websites with executable attachments
• Vulnerabilities and exploits targeting Windows applications
• Mass-distributed desktop malware

Most of the malware that we see today does not go after the BIOS. Some go after the boot sequence and most go after the post-boot injection points such as start-up folders, AutoRun registry keys, and autoload DLL/component injection points. The secure boot architecture handles the preboot sequence and makes a good stab at boot driver validation, but there is some distance to go to guard all the injection points used by most malware.

Future posts will include more analysis of Windows 8 and the state of its security. We will also explore implications for users and discuss best security practices for operating systems and applications.