Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
Today, we released an update to address a vulnerability in Group Policy Preferences (MS14-025). Group Policy Preferences was an addition made to Group Policy to extend its capabilities. Among other things, Group Policy Preferences allows an administrator to configure:
Group Policy Preferences are distributed just like normal group policy: An XML file containing the settings is written to the SYSVOL share of the domain controllers, and computers periodically query the SYSVOL share (authenticating to it using their computer account) for updates to the group policy.
Several of the Group Policy Preferences allow credentials to be specified. When this option is used, the password is symmetrically encrypted using a static key and written to the XML file along with the rest of the settings. What is this key you ask? It turns out, we document it on MSDN: http://msdn.microsoft.com/en-us/library/cc422924.aspx.
If an attacker is able to get access to the SYSVOL share (which is open to all authenticated users, so a malicious or spear phished employee will have access to it) and obtain the AES encryption key used to encrypt/decrypt passwords set with GPP (which we document on MSDN), the attacker will be able to obtain the credentials set with GPP.
Microsoft has observed that Group Policy Preferences abuse is one of the most common tactics used by attackers to elevate permissions in a domain. Multiple toolkits used by attackers such as Metasploit (http://www.rapid7.com/db/modules/post/windows/gather/credentials/gpp) and PowerSploit (https://github.com/mattifestation/PowerSploit/blob/master/Exfiltration/Get-GPPPassword.ps1) provide easy to use methods for retrieving and decrypting GPP passwords. In the worst case scenario, companies use Domain Administrator credentials in their Group Policy Preference accounts, resulting in a full domain compromise as soon as the attacker is able to access with SYSVOL share (and decrypt the passwords using the documented key).
Microsoft has released an update to change the behavior for this issue, but companies using GPP need to take action. Microsoft has removed the ability to create or modify any Group Policy which contains a Group Policy Preference that specifies account credentials. The only action that can be performed on such a Group Policy is “delete”. Note that Microsoft is not automatically disabling these Group Policies because we do not want to disrupt existing environments which rely on this feature. You can see in the picture below that when attempting to create a local account the “username” and “password” fields are disabled. If you attempt to create a user, an error dialog will be displayed.
In addition to the change in behavior, Microsoft is providing customers with two PowerShell scripts. The first script, Enum-SettingsWithCpassword, will search existing GPO’s for use of the account password functionality. We urge companies to immediately run this script and delete vulnerable GPO’s detected.
The second script, Invoke-PasswordRoll, can be used to set local administrator passwords on remote systems (something that Group Policy Preferences is commonly used for). The script takes a list of usernames and computers, and uses PowerShell remoting to connect to each computer and change each specified usernames password to a randomized password. The username/password combinations will be written recorded in a file on disk (which is encrypted, but optionally can be stored in clear-text). Note that the script enforces randomized passwords to ensure the local accounts cannot be used in pass-the-hash attacks.
You can find both scripts at http://support.microsoft.com/kb/2962486.
- Joe Bialek, MSRC engineering team
Dynamically loading libraries in an application can lead to vulnerabilities if not secured properly. In this blog post we talk about loading a library using LoadLibraryEx() API and make use of options to make it safe.
Know the defaults:
Control the DLL search order:
There are various option to modify the order in which the loading library is searched other than the default search order when absolute name is provided.
Some of the APIs that can influence the DLL search order/path by the LoadLibraryEx() are as below:
LoadLibraryEx() provide many flags that can be used to alter the default search order. Below table lists most of the flags and also depicts the DLL search order that is followed for each of them. Some of the options even consider the paths set with above mentioned APIs.
Table 1: Depicting different options to the LoadLibraryEx and how it affects the DLL search order.
Loading library as non-executable:It is not always required to load a library as an executable image. LoadLibraryEx() makes it possible to load a library as a data file, or an image resource, for example. For this purpose, it supports following different options:
These options helps in treating a file as a normal data file rather as an executable module. Loading with this option doesn't call DLLMain() and none of the memory space of the loaded DLL data is marked as executable.
Blocking the library from loading:Sometimes it might be required to block a library or block an illegitimate library from loading into an application. Check out following facilities to aid that:
To summarize our discussion:
To ensure secure loading of libraries
Some common attack vectors we see:
- Swamy Shivaganga Nagaraju, MSRC engineering team
Today we released eight security bulletins addressing 13 unique CVE’s. Two bulletins have a maximum severity rating of Critical while the other six have a maximum severity rating of Important. The table is designed to help you prioritize the deployment of updates appropriately for your environment.
(Common Controls - MSCOMCTL)
Installing this update will prevent this control from being used as an ASLR bypass in any potential future exploits.
(Group Policy Preferences)
Backdoor:Win32/Koceg Backdoor:Win32/Optixpro.T Backdoor:Win32/Small Backdoor:Win32/Xtrat PWS:Win32/Zbot Rogue:Win32/Elepater Rogue:Win32/FakeRean Trojan:Win32/Dynamer!dtc Trojan:Win32/Malagent Trojan:Win32/Malex.gen Trojan:Win32/Meredrop Trojan:Win32/Otran Trojan:Win32/Rimod Trojan:Win32/Sisron TrojanDropper:Win32/Sirefef TrojanSpy:Win32/Juzkapy VirTool:MSIL/Injector VirTool:Win32/Obfuscator Virus:Win32/Neshta Worm:Win32/Autorun Worm:Win32/Fasong Worm:Win32/Ludbaruma Worm:Win32/Rahiwi
- Jonathan Ness, MSRC engineering team