Stronger Windows 8 Still Vulnerable Through Apps, Users

This is the third in a series of posts about Microsoft Windows 8, the Metro interface, and our view of its security status. To review the first two articles, click here and here.

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:

 

Windows 8 Secure Boot

Windows 8 Secure Boot

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.

Honey Singh Featured on Phishing Sites

Co-author: Avdhoot Patil

Phishing sites using celebrities as bait are on a rampage. In July 2012, Honey Singh, also known as Yo Yo Honey Singh, a popular Indian rapper, singer, music producer, and actor was featured on phishing sites. Symantec observed several phishing sites that spoofed a social networking brand that claimed to have an application for Honey Singh. The phishing sites were hosted by a free web hosting service.

The phishing sites promoted Honey Singh’s 2011 album, International Villager. A poster of the album's artwork was displayed on the left side of the phishing page and the login form was displayed on the right side. The phishing sites claimed to have an application that enabled users to listen to the Punjabi star's latest songs and videos. As with most applications on social networking sites, the application made a request to the user before allowing access. After a user's login credentials were entered into the phishing site, users were redirected to Honey Singh’s official website to create the illusion of a valid login. Users who fell victim to the phishing sites had their information stole. Phishers used this information to commit identity theft.
 

Internet users are advised to follow best practices to avoid phishing attacks:

  • Do not click on suspicious links in email messages
  • Avoid providing any personal information when answering an email
  • Never enter personal information in a pop-up page or screen
  • When entering personal or financial information, ensure the website is encrypted with an SSL certificate by looking for the padlock, https, or the green address bar
  • Frequently update your security software (such as Norton Internet Security 2012) which protects you from online phishing

The Things They Stored: Malte Spitz Delivers a Powerful Talk on Mobile Carriers Recording Your Daily Life

The mobile phone you carry in your pocket has revolutionized daily life, but it’s also made possible a surveillance society previously only dreamed of by the likes of the Stasi, KGB and NSA.

Malte Spitz, a German Green Party politician, wanted to know what his carrier, T-Mobile, collected on him, and filed suit to get the data. After a settlement, he got a CD of the data the company retained, and in a TedGlobal talk on June 27, he brought down the house, calling for others to fight for their right to self-determination in the digital age.

Although there is no mandatory data retention law in the U.S., none of the major carriers tell the public how long they store the data, nor do they make it possible for a citizen to request the data stored about himself or herself.

Luckily, the ACLU cleverly got this information, which seems to be freely shared with the Justice Department, by sending government sunshine requests to state and local police that the feds shared information with.

The answers should scare you.

As for your ISP? None of the major ISPs disclose this data (we tried to get it in 2007), and few online companies share their data-logging practices, either.

Reverse-Engineered Irises Look So Real, They Fool Eye-Scanners

Researchers reverse-engineered iris codes to create synthetic eye images that tricked an iris-recognition system into thinking they were authentic. Can you tell if this is the real image or the synthetic one? All images courtesy of Javier Galbally

LAS VEGAS — Remember that scene in Minority Report when the spider robots stalk Tom Cruise to his apartment and scan his iris to identify him?

Things could have turned out so much better for Cruise had he been wearing a pair of contact lenses embossed with an image of someone else’s iris.

New research being released this week at the Black Hat security conference by academics in Spain and the U.S. may make that possible.

The academics have found a way to recreate iris images that match digital iris codes that are stored in databases and used by iris-recognition systems to identify people. The replica images, they say, can trick commercial iris-recognition systems into believing they’re real images and could help someone thwart identification at border crossings or gain entry to secure facilities protected by biometric systems.

The work goes a step beyond previous work on iris-recognition systems. Previously, researchers have been able to create wholly synthetic iris images that had all of the characteristics of real iris images — but weren’t connected to real people. The images were able to trick iris-recognition systems into thinking they were real irises, though they couldn’t be used to impersonate a real person. But this is the first time anyone has essentially reverse-engineered iris codes to create iris images that closely match the eye images of real subjects, creating the possibility of stealing someone’s identity through their iris.

“The idea is to generate the iris image, and once you have the image you can actually print it and show it to the recognition system, and it will say ‘okay, this is the [right] guy,’” says Javier Galbally, who conducted the research with colleagues at the Biometric Recognition Group-ATVS, at the Universidad Autonoma de Madrid, and researchers at West Virginia University.