Windows Store Apps Can Compromise PC Security
In this Ask the Admin, I’ll explain why you should use application control to restrict which Windows Store apps users can run.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Most security experts agree that curated application stores are beneficial in helping protect operating systems from malware. Windows Store brought with it the promise of more secure personal computing. And it can lead to a more secure environment. But there are several ways developers can use the store to compromise a PC.
As reported by Ed Bott on ZDNet last year, an app he downloaded from the Windows Store called Torrenty contained a hyperlink that appeared to provide an update to the app. When the user clicks on the update link, it opens the default browser and downloads a file called setup.exe. To the unsuspecting user, it might seem like a genuine update for the Windows Store app. But the file installs a win32 BitTorrent client. As Bott points out, it could have been much worse. Setup.exe might have installed a keylogger or ransomware. Torrenty is no longer available in the Windows Store.
Torrenty was a Universal Windows Platform (UWP) app and would have needed to pass Microsoft’s approval process before it was published in the store. The inclusion of a hyperlink that tricked users into downloading a separate app should have been flagged as an issue but Microsoft’s approval process for apps at the time was clearly flawed. The ability to launch hyperlinks from UWP apps provides an easy way for developers to break out of the app container sandbox and trick users into installing additional software or launch other kinds of attacks.
Hosted and Progressive Web Apps
The story doesn’t end there. Legacy win32 apps ported to the store using Microsoft’s Desktop Bridge and UWP apps are the two most common kinds of app in the store. Hosted Web Apps (HWAs), which are run from the developer’s server, were introduced in Windows 10 as an alternative to packaged web apps. Because developers can make changes to the code of HWAs on their own server, there is no need for a store submission for every app update. These apps can also make use of Universal Windows Platform features, such as the ability to run offline, push notifications, and live tiles.
HWAs give developers a convenient way to get their apps into the store and keep them updated. But because HWAs don’t need to be approved every time developers makes changes, there is always the possibility that an update could introduce undesirable functionality or that the server hosting the app could be compromised.
Microsoft is also planning to introduce support for Progressive Web Apps (PWAs) in the Windows Store in a future version of Windows 10. PWAs are similar to HWAs but support a set of HTML5 standards that blur the lines between web apps and locally installed software. Unlike how Google Chrome allows users to run PWAs, Microsoft will require users install PWAs from the Windows Store.
The issue of whether developers will submit their PWAs to the Windows Store is a sticking point, so Microsoft plans to automatically trawl the Internet for suitable PWAs and package them automatically for store submission. PWAs could pose security similar threats as HWAs.
For more information on Progressive Web Apps in Windows 10, see Microsoft Adding Support for Progressive Web Apps in Windows 10 on Petri.
Block Untrusted Windows Store Apps
Application stores are a good idea and you can even create your own private store using Windows Store for Business. If you want to be sure that Windows stays secure in your organization, it is best to use application whitelisting to restrict which Windows Store apps users can run or block access to the public store completely.
See Windows Store for Business on Petri for more information on how to configure your own organizational store.
Microsoft removed the ability to block access to the Windows Store using a Group Policy setting in Windows 10 Professional version 1511. The store app can still be blocked in Windows 10 Enterprise and Education SKUs using AppLocker or by enabling the Turn off the Store application Group Policy setting under Computer Configuration > Administrative Templates > Windows Components > Store.
If you do not want to block access to Windows Store but would like to control which apps users can run, create an AppLocker whitelist of approved applications. Don’t forget that Windows 10 includes some default Windows Store apps, like Settings and Microsoft Edge, so you will need to examine which apps are installed on your systems by default and include them in your whitelist.
The risks associated with Windows Store apps can also be reduced by enabling AppLocker or Device Guard to enforce a whitelist of trusted win32 apps, scripts, and Windows Installer files. AppLocker and Device Guard are only available in the Enterprise and Education SKUs of Windows 10.
The Windows 10 Creators Update includes a setting that restricts users to install only apps from the Windows Store. You can turn on this setting by enabling Configure App install Control in Group Policy under Computer Configuration > Administrative Templates > Windows Components > Windows Defender SmartScreen > Explorer. The setting can also be managed by users with administrative privileges if it hasn’t been configured using Group Policy, in the Settings app under Apps and features. Windows 10 S is also limited to Edge and Windows Store apps.
In this Ask the Admin, I talked about why you should control which Windows Store apps users can install and discussed some controls that can be used to restrict access to the store.
Follow Russell on Twitter @smithrussell.