In the light of the recent release of version 5.0 of Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) on July 31, it seems to be more than appropriate to talk a bit about the new features and some general things to take into account when using EMET (for the new certificate pinning feature of EMET 4.0, see Friedwart’s comment). For all of you who don’t know EMET, in short, it’s a free mitigation tool for Windows developed by Microsoft, helping the user by preventing vulnerabilities in software from being successfully exploited. The tool works by protecting applications via a number of security mitigation technologies, vastly extending Windows operating system mitigation capabilities as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).
regularly we get requests from customers where the idea of using Skype as a VoIP solution in their corporate environment is brought up. There are a lot of eavesdropping and more conceptual concerns (e.g. refer to this or this, and of course the legendary “Silver Needle in the Skype” paper from Black Hat EU 2006), but those won’t be covered in this post (just to say this: at ERNW the use of Skype is strictly prohibited at by policy).
However, we worked on an interesting request that focused on Skype’s security impact on end devices, mainly concerning Windows clients. Skype has many features e.g. file sharing between users, the ability to set the port on which Skype listens, or clients becoming supernodes, which in turn can be relevant for the overall security impact on network or clients. The interesting part from a corporate perspective is the ability to configure those Skype settings via GPO, for which Skype even used to provide an ADM file. However, the settings in this file were quite outdated, which made us decide to put together a file for the settings of the most recent version of Skype. Relevant resources for this are the Skype IT Administrators Guide and a corresponding TechNet article on ADMX files (Managing Group Policy ADMX Files Step-by-Step Guide).
Our Skype ADMX files can be found here for download.
Besides the concerns of Skype usage in corporate environments in general (as mentioned above, this post does not discuss those), we want to outline some of the settings that can be relevant to protect clients and network:
Disable File Transfer: Disable file transfer to achieve that any user can’t send any internal data trough Skype.
Disable Contact Import: This setting prevents any user to import contacts trough the application itself, importing contacts can be realized over Skype-Manager tool.
Disable Web Status: If you disable this setting any user can’t publish their online status.
Disable API: Prevents usage of Skype API for third party applications.
Disable Version Check: This setting prevents Skype to perform an initially version check.
Memory Only: This setting makes it possible to run Skype without storing data on the local disk.
Listen Port: Skype normally listens on a default Port, this setting restricts the port to your settings.
Disable Supernode: This setting prevents a random user to become a supernode which makes it possible for this user to intercept traffic.
Proxy Type: HTTPS or SOCKS5. This also enables the use of the proxy in general
Proxy Address: “hostname:port” e.g. “socks5.mydomain.com:5050”.
Proxy Username: “username” e.g. “socks5user”.
Proxy Password: “password” e.g. “socks5pass”.
Despite our critical opinion on Skype, we hope that the files might help the secure operation of Skype in environments where it has to be used for some reasons.
Best,
Sebastian & Matthias
PS: We tested the files in our environment and did not experience any problems. We’re happy about bug reports, however it might take time to deploy changes and we cannot provide any support/warranty on the files.
I recently stumbled over a document from Microsoft which lists all services/applications that support IPv6. Most of the content wasn’t new for me, but one item caught my attention. Windows Update. I haven’t heard before that Windows Update can be done over IPv6 (but this could just be me not looking hard enough ;)), so I was eager to test it out seeing if this is really the case. I was also curious why Microsoft referenced this document in the respective column. Continue reading “Microsoft Windows Update over IPv6 (or not?)”
On Saturday, April 26 Microsoft announced that Internet Explorer version 6 until version 11 is under potential risk against drive-by attacks from malicious websites, regardless of the underlying Microsoft operating system and the associated memory protection features integrated with the operating system. Microsoft has assigned CVE-2014-1776 to this unknown use-after-free vulnerability, which in the worst case could allow remote code execution if a user views a specially crafted website. If an attacker successfully exploits this vulnerability, s/he will gain the same rights and privileges as the current user (once again, activated User Account Control [UAC] helps keeping privileges of the user low).
The recommended mitigating controls from Microsoft, especially unregistering the VGX.DLL library has led to the misunderstanding, that many people thought the vulnerability is located in the VGX.DLL library. That is wrong. Instead, the vulnerability is located in mshtml.dll, mshtml.tlb, Microsoft-windows-ie-htmlrendering.ptxml, and Wow64_microsoft-windows-ie-htmlrendering.ptxml and therefore unregistering of the above library does not globally mitigate the vulnerability. It only mitigates a specific attack vector where Vector Markup Language (VML) is being used during the attack. Continue reading “The Role of VGX.DLL in the Context of the Latest IE 0-Day”
Microsoft released EMET v4.0 with a new (security) feature that enables protection against fraudulent websites or compromised root certification authorities (do you remember Comodo, DigiNotar, DigiCert, Turktrust et al. ;-)?)
EMET defines via “certificate trust“ a trust chain between the domain name of a website (and its associated website certificate) and a root CA certificate. This is done through so called “pinning rules”. Here is one of the default pinning rules of EMET 4.0 for the domain name login.live.com:
Actually a Windows Vulnerability (Microsoft Advisory 2757760) related to the Internet Explorer Version 7, 8 and 9 is in the news. Microsoft is aware of the problem, but there’s no patch available yet. We call this a 0-Day :-). Making the problem even worse, on monday reliable exploit code was released within the Metasploit project, so exploit code is already in the wild.
Disabling Active X and Active Scripting in the Internet Settings
But both of them have some impact: EMET must be deployed before any usage (btw. EMET can be configured via Group Policies) and disabling Active X and Active Scripting might break some business relevant web sites (that can be added to the “Trusted Sites” Zone, but might produce major operational effort).
There are more possible mitigating controls, so let’s just summarize some ideas:
Use of alternative browser: if you have it deployed already, go for it :-). Otherwise we have the same deployment issue as with EMET.
Sandboxing/Application Virtualization: It’s the same as with the alternate browser, of you have it, go for it, otherwise it will be a long term project. And be aware that also Application Virtualization won’t address all issues (see the ERNW Newsletter 32 for details).
No local admin rights: This doesn’t protect from exploiting the vulnerability, but at least reduces the impact. We strictly recommend to check the local administrator group and remove all users that don’t rely on it for fulfilling their business tasks. And btw. this topic is not new ;-), see also ERNW Newsletter 4, published in 2004!
Blocking communication for the clients at the corporate firewall: Be aware that this doesn’t really work. Modern exploit code is able to use the corporate proxy infrastructure including authentication to circumvent this control. Metasploit has exploit payloads for this.
Disabling/Blocking Flash content: While potentially not strictly required for exploitation, at least in some of the exploits currently observed in the wild Adobe Flash plays a major role. So like discussed in these Insinuator posts (1, 2 and 3), restricting the use of Adobe Flash would proactively prevent some known exploits from working. But the newly published Metasploit exploit doesn’t use Flash, so keep in mind that this mitigating control can only be used in addition to other ones.
So for a short term mitigation we recommend the following (especially for corporate environments)
Disabling Active X and Active Scripting via Group Policies
Disable/block Flash content
Remove unneeded local administrative privileges
If available use alternative browser or EMET
For long term mitigation (might also be feasible in small environments as short term mitigation):
Deploy EMET
Evaluate possibilities of application sandboxing/virtualization
Deploy alternative browser. Be aware that deploying a second browser might not be an option for big corporate environments (central management and supporting/maintaining additional software are the main reasons for this).
And finally DON’T PANIC ;-), start to address the problem in a professional way.
One of the four vulnerabilities rated “critical” from yesterday’s MS patchday, that is MS10-063, has an interesting “Workarounds” section as for MS Internet Explorer. There it’s stated:
“Disabling the support for the parsing of embedded fonts in Internet Explorer prevents this application from being used as an attack vector.”
which, according to the advisory, should/can be done by setting the “Font Downloading” parameter to “Disable”.
Which is exactly what this document suggests. So taking a preventive approach, once more, might have saved some concerns (“Will we be targeted by this one”) and patch/testing time…