Top desktop threats

MSRT top threats

Recently Published Analyses

We are pleased to announce the release of a new version of our Enhanced Mitigation Experience Toolkit (EMET) - EMET 3.0. EMET it is a free utility that helps prevent vulnerabilities in software from being successfully exploited for code execution. It does so by opt-ing in software to the latest security mitigation technologies. The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an update has not yet been applied.  Download it here:  http://www.microsoft.com/en-us/download/details.aspx?id=29851

This new version of the tool being released today addresses top feedback themes we have heard from users: EMET needs more enterprise configuration, deployment and reporting options. We have seen growing interest in adoption from enterprise and large scale networks and this new version includes enhancements for that segment. Here are some of the highlights of and new features in EMET 3.0.

• Making configuration easy
• Enterprise deployment via Group Policy and SCCM
• Reporting capability via the new EMET Notifier feature

Configuration

EMET 3.0 comes with three default "Protection Profiles". Protection Profiles are XML files that contain pre-configured EMET settings for common Microsoft and third-party applications. Under EMET’s installation directory, these files are in the

Deployment\Protection Profiles

folder. You can enable them as-is, modify them, or create new protection profiles based on them.

The three profiles that ship with EMET 3.0 are:

• Internet Explorer.xml: Enables mitigations for supported versions of Microsoft Internet Explorer.
• Office Software.xml: Enables mitigations for supported versions of Microsoft Internet Explorer, applications that are part of the Microsoft Office suite, Adobe Acrobat 8-10 and Adobe Acrobat Reader 8-10.
• All.xml: Enables mitigations for common home and enterprise applications, including Microsoft Internet Explorer and Microsoft Office.

Looking inside a profile, we see a list of programs with EMET mitigations. The example below shows all EMET mitigations enabled for Windows Media Player, with the exception of Mandatory ASLR:

<Product Name="Windows Media player">
<Version Path="*\Windows Media Player\wmplayer.exe">
<Mitigation Enabled="false" Name="MandatoryASLR"/>
</Version>
</Product>

Notice the “*” in the Path attribute above? In EMET 3.0, we also expanded the EMET grammar rules. Existing rules that you might have continue to work as-is and it is possible now to also use wildcards in EMET rules. This means that you no longer have to use the full path of an application in EMET rules. You can use the “*” character or simply use the image name, such as “iexplore.exe” in your rules. EMET will protect them regardless of where these applications may be installed. This has been one of the most requested features.

Deployment

EMET also comes with built-in support for enterprise deployment and configuration technologies. This enables administrators to use Group Policy or System Center Configuration Manager to deploy, configure and monitor EMET installations across the enterprise environment.

For Group Policy: EMET includes an ADMX file that contains the three protection profiles mentioned above as policies that can be enabled/disabled through group policy. There is also a policy that demonstrates how to add custom EMET settings.

For System Center Configuration Manager: The SCCM team blog post this morning provides a package and instructions for integration with various SCCM features. Read that blog post here: http://blogs.technet.com/b/configmgrteam/archive/2012/05/15/deploying-and-configuring-the-enhanced-mitigation-experience-toolkit.aspx

Reporting

With EMET 3.0, we have included an additional new reporting capability that we call "EMET Notifier". When you install EMET 3.0, this lightweight component is set to automatically start with Windows. It will show up in the notification area of your taskbar with an EMET 3.0 icon.

EMET Notifier has two duties:

• Write events out to the Windows Event Log
• Show important events via a tooltip in the taskbar notification area

EMET events are logged via the event source called EMET. These logs can be found in the Application log. There are three levels: Information, Warning and Error. Information messages are used for logging usual operation such as the EMET Notifier starting. Warning messages are used when EMET settings change. Error messages are used for logging cases where EMET stopped an application with one of its mitigations, which means an active attack has been blocked. An example entry can be seen below.

In addition to the error messages written to the Windows Event Log, when an EMET mitigation stops (crashes) an application by blocking an exploit, a message is displayed for the user. A toast style taskbar notification states which application is being stopped and which mitigation is causing EMET to stop it. You can see an example below.

Other EMET v3 developments

In addition to these features, EMET 3.0 comes with a number of other improvements and bug fixes. More details and a FAQ can be found in the User Guide that comes with the install. However, we would like to specifically highlight a couple of things here.

First, we have tested EMET 3.0 on the Windows 8 Consumer Preview and it works great - we encountered no problems at all so we encourage you to use EMET on all versions of Windows. Second, EMET 3.0 can be installed just fine on a system where EMET 2.1 (the previous release) was already installed. An upgrade or a new installation is no different. Your existing rules built for EMET 2.1 will continue to work just fine with EMET 3.0. Third, we would like to point out that EMET is an officially-supported Microsoft tool. That is a question we get a lot from enterprise customers. Microsoft's Customer Service & Support team offers forums-based support via http://social.technet.microsoft.com/Forums/en/emet/threads. We in MSRC Engineering are also very eager to promote EMET and help you use it so we are quick to respond to feedback, ideas, suggestions, or questions via switech -at- microsoft -dot- com. Please do not hesitate to reach out to us.

Acknowledgements

I would like to thank Chengyun Chu, Elias Bachaalany, Elia Florio, Jinwook Shin, Neil Sikka, and Nitin Kumar Goel for their various contributions to this release. Also a big thank you to Jason Githens and Hema Rajalakshmi from the System Center Configuration Manager team for their help and support.

- Suha Can, MSRC Engineering

There are several interesting “stories” to tell about security update MS12-034:

• Addressing the Duqu vulnerability again?
• Why so many affected products?
• Keyboard layout behavior introduced with Windows Vista conditionally applied down-level

Addressing the Duqu vulnerability again?

Five months ago, we released security update MS11-087 to address CVE-2011-3402, a vulnerability that was being exploited by the Duqu malware to execute arbitrary code when a user opened a malicious Office document. As you can read from the SRD blog post we published at the time, this vulnerability was due to an insufficient bounds check within the font parsing subsystem of win32k.sys.

In the time since we shipped MS11-087, we discovered that several Microsoft products contained a copy of win32k.sys’s font parsing code. Unfortunately, each copy of the code also contained the vulnerability addressed by MS11-087. The most troublesome copy was in gdiplus.dll. We know that several third party applications – 3rd party browsers in particular – might use gdiplus.dll to parse and render custom fonts. Microsoft Office’s version of gdiplus, called ogl.dll, also contained a copy of the vulnerable code. Silverlight included a copy of the vulnerable code. And the Windows Journal viewer included a copy of the vulnerable code.

The Office document attack vector leveraged by the Duqu malware was addressed by MS11-087 – Duqu is no longer able to exploit that vulnerability after applying the security update. However, we wanted to be sure to address the vulnerable code wherever it appeared across the Microsoft code base. To that end, we have been working with Microsoft Research to develop a “Cloned Code Detection” system that we can run for every MSRC case to find any instance of the vulnerable code in any shipping product. This system is the one that found several of the copies of CVE-2011-3402 that we are now addressing with MS12-034.

Why so many affected products?

At first glance, MS12-034 may seem to be addressing a number of unrelated vulnerabilities in unrelated products. For example, why would a keyboard layout handling vulnerability be addressed in the same update as a Silverlight issue? However, as described above, we needed to address the font parsing vulnerability (CVE-2011-3402) in a number of different products. As each new product was added to the security update package, the vulnerabilities planned-to-be-addressed in the same binary were also included.

Addressing CVE-2011-3402 required us to service ogl.dll, gdiplus.dll, win32k.sys, Silverlight, .NET Framework, etc.  Because gdiplus.dll was being addressed, several other fixes that were scheduled to be released in the same binary were looped in to this update.  For example, the local elevation of privilege vulnerabilities in win32k.sys (CVE-2012-0180,0181,1848) were added because we had already included win32k.sys to address TTF parsing issues.  The Silverlight and .NET Framework vulnerabilities were added because we were already servicing those binaries via CVE-2011-3402.  In the end, its probably for the best to require fewer updates to be installed but we understand that it can be confusing.  Hopefully that explanation will help you understand the reasoning behind the decision to include ten CVE's in a single bulletin.

Keyboard layout behavior introduced with Windows Vista conditionally applied down-level

In addition to addressing the vulnerabilities described in the bulletin, this security update also closes the malicious keyboard layout file attack vector. Windows Vista introduced a requirement that all keyboard layout files be loaded from %windir%\system32. MS12-034 ports that change downlevel to Windows XP and Windows Server 2003 as well. With this new update in effect, vulnerabilities like CVE-2012-0181 (being addressed today) and CVE-2010-2743 (one of the privilege escalation vulnerabilities used by Stuxnet) will be non-issues. Requiring an attacker to place a malicious file in the system32 directory prevents the vulnerability from being a threat.

You can read more about how this change is rolled out in the bulletin’s FAQ section, specifically “Are there special requirements related to applying the security update packages that address CVE-2012-0181?” The change will not affect systems where a keyboard layout outside %windir%\system32 is already registered on the system. You can also read more in Microsoft KB 2686509.

Acknowledgements

Many engineers worked hard to bring this larger-than-usual MS12-034 security update to you.  From the MSRC Engineering team, I especially want to thank Richard van Eeden and Cristian Craioveanu for their work on the font issues.  Ali Pezeshk and Gavin Thomas both also made larger-than-usual contributions to this update.  Elias Bachaalany, Elia Florio, Jinwook Shin, Neil Sikka, Ali Rahbar, and Suha Can all contributed to this update from the MSRC Engineering team.  Finally, thanks to Chengyun Chu for his work on the cloned code detection system that discovered the other instances of CVE-2011-3402.

Conclusion

MS12-034 addresses ten CVE’s affecting a number of different products. We hope that this blog post answers questions you might otherwise have had around the servicing decisions that went into this update. If you have any further questions, please email us at switech –at- microsoft –dot- com.

- Jonathan Ness, MSRC Engineering

Today we released 6 security bulletins. Four have a maximum severity rating of Critical with the other two addressing Important class vulnerabilities. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

- Jonathan Ness, MSRC Engineering

Security Update MS12-027 addresses a code execution vulnerability in MSCOMCTL.OCX, the Windows Common Controls ActiveX control. By default, this component is included with all 32-bit versions of Microsoft Office. We’d like to cover the following topics in this blog post:

• Limited, targeted attacks leveraging this vulnerability
• Mitigations in recent versions of Office to reduce the risk
• Extra protections to block all or specific ActiveX controls in Office documents
• The new Office 2010 kill bit feature

Limited, targeted attacks leveraging this vulnerability

We list MS12-027 as our highest priority security update to deploy this month because we are aware of very limited, targeted attacks taking advantage of CVE-2012-0158 vulnerability using specially crafted Office documents as exploit vector. The specific samples that we have seen have been RTF files attempting to exploit the vulnerability when opened in either WordPad or Microsoft Word. People who install the MS012-027 patch are protected against CVE-2012-0158 so we recommend applying the update right away. Microsoft Word includes various on-by-default mitigations and optional security hardening features that you might consider enabling. Read on to find out more.

Microsoft Word 2010 Protected View as a mitigation

By default, Microsoft Office 2010 opens documents originating from the Internet and from other potentially unsafe locations in a mode called Protected View.  This mode does not allow ActiveX controls to load.  If a victim running Office 2010 were to receive an exploit for CVE-2012-0158 over the internet or via email, the victim would need to click the Protected View's "Enable Editing" button before the malicious code would be allowed to run.  The screenshots below  show two examples of Protected View.

and

Disabling ActiveX controls in Microsoft Office

ActiveX-based attacks with documents are not new. In this blog we have covered the Behavior of embedded ActiveX controls in Microsoft Office documents (http://blogs.technet.com/b/srd/archive/2009/03/03/behavior-of-activex-controls-embedded-in-office-documents.aspx) three years ago, giving good advice and best practices on how to restrict (or disable) the initialization of embedded controls.

Without going into the details of the previous blog, we’ll just mention once more that Office 2007 and 2010 editions have a dedicated panel for ActiveX controls in Trust Center Settings which allows, in its safest configuration, to completely disable all controls embedded in documents or to prompt a warning dialog when a document tries to use certain type of controls as showed by the following picture.

Disabling specific embedded ActiveX controls with Office kill bit

The ActiveX kill bit feature has proven an effective measure in reducing the attack surface of Internet Explorer during the past years and so Microsoft Office has introduced this feature in a similar way. Office 2007 honors the Internet Explorer kill bit list. Office 2010 takes this a step further by blocking ActiveX controls from the Internet Explorer list and also allowing users to independently control through the registry which COM objects will not be able to run (Office 2010 COM kill bit). If the kill bit is set for the same ActiveX control in both locations, Office and Internet Explorer, and there is a conflict between the two settings, the Office COM kill bit has precedence. The location for setting the Office 2010 COM kill bit in the registry is HKLM/Software/Microsoft/Office/Common/COM Compatibility/{CLSID}, where CLSID is the class identifier of the COM object. To enable the Office COM kill bit for a specific control, first you need to add a registry key with the CLSID of the ActiveX control to block (NOTE: don’t forget the { } parenthesis!) and then add a value of 0x00000400 to the Compatibility Flags REG_DWORD.

Documents containing embedded controls will still be opened by Microsoft Office (some content of the document will be available and visible), however any blocked ActiveX control will not be loaded and will show up in the Office application as showed in the following picture:

Additional details about Office 2010 kill bit can be found at the following link: “Plan security settings for ActiveX controls for Office 2010” http://technet.microsoft.com/en-us/library/cc179076.aspx

Conclusions

The first option described in this blog (Trust Center settings) provides a general and very effective measure against attacks similar to the one observed for CVE-2012-0158, however this configuration needs to be carefully evaluated before wide adoption on corporate networks because it may block the execution of Office documents and applications with embedded ActiveX controls (e.g. an Excel spreadsheet using listbox control for selection). Organizations that have a highly restrictive security environment and concerns about ActiveX controls may consider deploying this setting via group policy or registry.

On the other hand, the second option described today (Microsoft Office 2010 COM kill bit) offers to users and organizations a more selective way to control which embedded ActiveX controls can be trusted and loaded from documents. An organization seeking to block a limited set of untrusted controls without having legacy problems with existing applications may find more useful deploying selective kill-bit configurations instead of using the general “disable all” option discussed earlier.

- Elia Florio, MSRC Engineering

One of the security bulletins released today, MS12-025, addresses a code execution vulnerability in the .NET Framework. To exploit the vulnerability, an attacker would build a malicious XBAP application and lure victims to a malicious website serving the XBAP.

The good news is that a zero-click “driveby” style attack is no longer possible from the Internet on workstations where MS11-044 (published June 2011) has been installed. MS11-044 introduced an additional security prompt for all XBAP’s encountered from the Internet Zone. A redacted example is pictured below:

We recommend not allowing XBAP’s to run unless you know and trust the Publisher listed in the security dialog. The security bulletin outlines steps to disable XAML browser applications in Internet Explorer on a per-zone basis if you do not need to use this functionality.

- Jonathan Ness, MSRC Engineering

Security Update MS12-020 addresses two vulnerabilities in Microsoft’s implementation of the Remote Desktop Protocol (RDP). One of the two, CVE-2012-0002, is a Critical, remote code execution vulnerability affecting all versions of Windows. This blog post shares additional information with the following goals:

• To strongly encourage you to make a special priority of applying this particular update;
• To give you an option to harden your environment until the update can be applied.

Note that CVE-2012-0002 was privately reported and we are not aware of any attacks in the wild. Additionally, the remote desktop protocol is disabled by default. However, due to the attractiveness of this vulnerability to attackers, we anticipate that an exploit for code execution will be developed in the next 30 days.

We understand and appreciate that our customers often need time to evaluate and install bulletins as appropriate for their environment. For systems running RDP without Network-Level Authentication (NLA) enabled, this post includes information on a mitigation that may be applied in advance of the bulletin.

Pre-auth, network accessible, service running as SYSTEM

This issue is potentially reachable over the network by an attacker before authentication is required. RDP is commonly allowed through firewalls due to its utility. The service runs in kernel-mode as SYSTEM by default on nearly all platforms (except for one exception described below). During our investigation, we determined that this vulnerability is directly exploitable for code execution. Developing a working exploit will not be trivial – we would be surprised to see one developed in the next few days. However, we expect to see working exploit code developed within the next 30 days.

The good news is that the Remote Desktop Protocol is disabled by default, so a majority of workstations are unaffected by this issue. However, we highly encourage you to apply the update right away on any systems where you have enabled Remote Desktop.

Workaround option: Enable Network Level Authentication (NLA) on Windows Vista and later platforms

There is something you can do to substantially reduce the risk on Windows Vista and later systems where RDP is enabled: You can enable Remote Desktop’s Network Level Authentication (NLA) to require authentication before a remote desktop session is established to the remote desktop server. On systems with NLA enabled, the vulnerable code is still present and could potentially be exploited for code execution. However, NLA would require an attacker to first authenticate to the server before attempting to exploit the vulnerability.

You can find instructions to enable NLA interactively or via group policy at http://technet.microsoft.com/en-us/library/cc732713.aspx. We’ve prepared a one-click “Fix it” solution that takes a registry-based approach to enable NLA. It is a simple MSI package that enumerates each of the “listener” registry subkeys under HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations and sets the “UserAuthentication” REG_DWORD to 1. The links below enable and disable NLA:

Enable NLA	Disable NLA
Microsoft Fix it 50844	Microsoft Fix it 50845

Enabling NLA will prevent older clients (including Windows XP and Windows Server 2003) from connecting, by default. NLA will not disrupt remote desktop connections initiated by Windows Vista and later versions of Windows because they support NLA by default. If you need to initiate a remote desktop protocol connection to an NLA-enabled server from a Windows XP client, you can install support for Credential Security Support Provider (CredSSP) on each connecting Windows XP client. Instructions for doing so can be found here: http://support.microsoft.com/kb/951608. You can also use this one-click Fix it solution on Windows XP SP3 clients to enable support for NLA:

Platforms and scenarios at reduced risk

Just to reiterate, remote desktop is not enabled by default and is not commonly enabled on client workstations. Additionally, there are two common scenarios where remote desktop services could be enabled but on which the vulnerability poses reduced risk.

First, servers providing Terminal Services Gateway service are not directly vulnerable to this issue. The reason is that external users connect to the TS Gateway by using RDP encapsulated in RPC over HTTPS via port 443. The TS gateway computer removes the SSL encryption from the RDP traffic and then forwards the traffic to port 3389 of the destination computer on the internal network. The Terminal Services session is then established with that destination computer, not with the TS Gateway system.

The second scenario at reduced risk is Windows Server 2008 R2 SP1 servers using the Remote Desktop feature called RemoteFX. This is a common scenario in virtualized environments. This scenario is at reduced risk because the vulnerable code is running in user-mode (not kernel-mode) with NetworkService rights (not SYSTEM rights). While NetworkService privileges are less severe than executing code as SYSTEM, it would still grant attackers an unfortunate foothold in the network – so it would be a mistake to allow this reduced risk discussion to slow your rate of bulletin application.

We are actively engaged with our MAPP partners to build network-based detection and protection signatures for this issue. The nature of this particular vulnerability should allow for strong IDS and IPS protection. So an additional scenario leading to reduced risk is to have one’s systems behind a protection product from one of our MAPP partners who has built strong detection for this issue.

Conclusion

We urge you to promptly apply this security update. We also encourage you to consider how you might harden your environment against unauthenticated, attacker-initiated RDP connections. Please let us know if you have any questions that can help you speed your deployment. You can reach out to us at switech –at- microsoft –dot- com.

- Suha Can and Jonathan Ness, MSRC Engineering

Today we are shipping a security update to address a Critical-class memory corruption vulnerability in the Microsoft C Run-Time Library (msvcrt.dll) shipped with Windows. We have issued the bulletin with Critical severity because attackers could potentially trigger the vulnerability by luring a victim into browsing to a malicious webpage that launches Windows Media Player, or by opening a malicious file with Windows Media Player.

Seldom-used functionality

While the Windows Media Player attack vector is unfortunate, one might look at the affected DLL (msvcrt.dll), recognize that a number of Microsoft applications load the DLL, and speculate that a large percentage of applications might be vulnerable. Thankfully, that is not the case. Based on what we have seen in our code base, the affected functions are rarely used by components shipping with Windows. At this time, Media Player is the only known vector to provide an exploit path for the vulnerability. And even if other attack vectors are discovered, after applying the security update, all Microsoft products will be protected from the issue.

Applications built with recent versions of Visual Studio are safe by default

All applications built with Visual Studio 2003 and higher are not affected by this issue, unless they are specifically loading msvcrt.dll. Starting from Visual Studio 2003, any program that is dynamically linked to the C Run-Time library will use msvcrXX.dll instead of msvcrt.dll.

It is important to note that msvcrt.dll is a known DLL. This means that it is a system component owned and built by Windows. It is intended for future use only by system-level components. An application should use and redistribute msvcrXX.dll. Windows will only look in %WINDIR%\system32 to locate msvcrt.dll. Any application that is linked to msvcrt.dll will load the vulnerable version, regardless of the presence of another version in the current directory – though, again, applying this bulletin eliminates the issue.

Guidance for 3rd party application developers

If you have developed an application by statically linking to the C Run-Time library shipped with Visual Studio, you are safe. If your program is dynamically linked to the C Run-Time library, then you should ensure that all your objects are linked with a recent version of Visual Studio. This will assure that you are using msvcrtXX.dll and are not affected by this problem.

- Ali Rahbar, MSRC Engineering

Today, we shipped security update MS12-014 to address an issue in the Indeo codec. With this blog post, we hope to preemptively answer some common questions that are likely to surface as researchers analyze this security update.

Indeo: Blast from the Past

Indeo is a video codec that was first developed in 1992, long before some of you reading this blog post were born. :) In the days before MPEG – and more than a decade before youtube – Indeo was one of the first video codecs allowing full-speed video playback without using hardware acceleration.

However, today Indeo is an obsolete technology. In fact, Windows Vista and all later versions of Windows shipped with the codec disabled by default. In 2009, we took a further step of attack surface reduction for older versions of Windows by releasing a security advisory and shipping an update to block Indeo from being launched in Internet Explorer or Windows Media Player. That update, shipped via Automatic Updates, removed the most common remote attack vectors for this code while still allowing games or other legacy applications to leverage the codec locally and continue to function.

MS12-014: Why and How

Windows now blocks the remote video playback functionality of Indeo but the codec itself and its infrastructure remain on the system for legacy application support. Unfortunately, a DLL Preloading issue has been identified leveraging Indeo. In the following set of circumstance, an attacker could run arbitrary code on a system:

• If an attacker lures a victim into browsing to a network share or WebDAV share where attacker has write access, AND
• If the attacker lures victim into double-clicking a content filetype that is handled by or registered to Indeo, AND
• If the attacker has placed a specifically-named malicious DLL on the share,
• Then Indeo will inadvertently load the malicious DLL while attempting to open the content file on which the victim double-clicked.

Due to the particular challenges in servicing Indeo, we took an unusual approach this time. This security update drops a “dummy DLL” on the system having the filename that the attacker’s malicious DLL would need to have to exploit the vulnerability. This effectively removes the vulnerability because the DLL will be found already on the system and Indeo will not attempt to load a malicious DLL from the attacker-controlled share.

Hope that helps answer questions you might have about this security update.

Thanks to Josh Carlson, MSRC Ops for the help with this one. (and congrats on shipping your first bulletin)

- Jonathan Ness, MSRC Engineering

Today we released nine security bulletins. Four have a maximum severity rating of Critical with the other five having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

- Jonathan Ness, MSRC Engineering

What's New in Security in Windows Server 2008 R2

Windows Server 2008 R2 introduces some changes from the security perspective of the operating system. The core changes are related to: authorization and access control, identity and authentication, information protection, security policies and security roles. To see the complete list of changes see What's New for Security in Windows Server 2008 R2.

Related security focused content covering Windows Server 2008 R2 and Windows 7 :

  Windows Server 2008 Security Guide

  Using Windows 7 and Windows Server 2008 R2: Controlling Communication with the Internet

  Threats and Countermeasures - Security Settings in Windows Server 2008 and Windows Vista

Windows Server 2008 R2 introduces some changes from the security perspective of the operating system. The core changes are related to: authorization and access control, identity and authentication, information protection, security policies and security roles. To see the complete list of changes see What's New for Security in Windows Server 2008 R2.

Related security focused content covering Windows Server 2008 R2 and Windows 7 :

  Windows Server 2008 Security Guide

  Using Windows 7 and Windows Server 2008 R2: Controlling Communication with the Internet

  Threats and Countermeasures - Security Settings in Windows Server 2008 and Windows Vista

Windows Server 2008 R2 introduces some changes from the security perspective of the operating system. The core changes are related to: authorization and access control, identity and authentication, information protection, security policies and security roles. To see the complete list of changes see What's New for Security in Windows Server 2008 R2.

Related security focused content covering Windows Server 2008 R2 and Windows 7 :

  Windows Server 2008 Security Guide

  Using Windows 7 and Windows Server 2008 R2: Controlling Communication with the Internet

  Threats and Countermeasures - Security Settings in Windows Server 2008 and Windows Vista

Windows Server 2008 R2 introduces some changes from the security perspective of the operating system. The core changes are related to: authorization and access control, identity and authentication, information protection, security policies and security roles. To see the complete list of changes see What's New for Security in Windows Server 2008 R2.

You can also find other security related scenarios with Windows Server 2008 R2 and Windows 7 in the following articles:

Windows Server 2008 R2 introduces some changes from the security perspective of the operating system. The core changes are related to: authorization and access control, identity and authentication, information protection, security policies and security roles. To see the complete list of changes see What's New for Security in Windows Server 2008 R2.

You can also find other security related scenarios with Windows Server 2008 R2 and Windows 7 in the following articles:

This month we released MS12-004 to address CVE-2012-0003 and CVE-2012-0004.

CVE-2012-0003

The most severe of these vulnerabilities is CVE-2012-0003 which is a Critical, Remote Code Execution vulnerability. This CVE affects all editions of Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Windows 7 is not affected by this vulnerability.

An effective workaround for CVE-2012-0003 is to disable Directshow’s MIDI parsing. Apply the following registry file would unregister the MIDI parser in Directshow.

Windows Registry Editor Version 5.00
[-HKEY_CLASSES_ROOT\CLSID\{D51BD5A2-7548-11CF-A520-0080C77EF58A}]

CVE-2012-0004

CVE-2012-0004 is an Important-class vulnerability also involving Windows Media Player. The vulnerability in the closed caption decoding component (L21 decoder) is contained within DirectShow. Therefore, the multimedia applications that leverage DirectShow to decode closed caption streams might be affected.

As a mitigation, the latest WMP player, WMP12, has closed caption turned off by default. As shown in the below picture, the setting to display close caption content is disabled. Therefore, WMP12 users are not affected by this vulnerability by default.

Summary

MS12-004 is our top-priority bulletin for January 2012; though the mitigation described above is effective and we have seen no exploitation attempts against either of the CVEs covered, we recommend that customers apply the bulletin as soon as possible.

Special thanks to Jeremy Tinder in MSRC and Ali Rahbar in MSRC Engineering.

- Chengyun Chu, MSRC Engineering

Today we released MS12-001, which addresses an issue that can enable an attacker to bypass a defense in depth feature known as SafeSEH. This bypass is limited in scope to applications that make use of binaries that were built with Microsoft Visual C++ .NET 2003 RTM. Binaries that have been built with Microsoft Visual C++ .NET 2003 Service Pack 1 and beyond are not affected. In this blog post we wanted to provide more details on the issue that has been addressed and what impact it has. In addition, we’ll clarify the parameters of the “Security Feature Bypass” vulnerability category assigned to this bulletin.

What is SafeSEH?

SafeSEH is a defense–in-depth security feature that is designed to make it more difficult for attackers to exploit certain types of vulnerabilities. In particular, SafeSEH is designed to prevent attackers from using an attack technique known as an “SEH overwrite”. More details on how this is accomplished can be found in a report we released in July of last year: http://go.microsoft.com/?linkid=9776900.

Microsoft released support for SafeSEH in Visual Studio 2003 RTM. Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1 were the first versions of Windows to be built with SafeSEH enabled.

What issue is being addressed?

This issue can result in SafeSEH not being enforced for a binary that has been built with support for SafeSEH. This occurs when a binary that was built with Microsoft Visual C++ .NET 2003 RTM is loaded by an application running on a version of Windows that is affected by MS12-001.

The reason that SafeSEH is not enforced in this scenario is because Microsoft Visual C++ .NET 2003 RTM produces binaries with metadata that is a different size than what the Windows loader expects. As a result, the loader conservatively falls back to assuming that the binary does not support SafeSEH. MS12-001 addresses this issue by allowing binaries to have metadata of the size that is produced by Microsoft Visual C++ .NET 2003 RTM.

What impact does this issue have?

Failing to enforce SafeSEH for a binary can enable an attacker to more easily develop an exploit for a vulnerability. The attacker must have found a vulnerability that can enable code execution for this to be possible; the issue addressed by MS12-001 does not enable code execution in and of itself. Furthermore, it does not enable elevation of privilege, information disclosure, or the like. For this reason, we’ve assigned MS12-001 to the very small category of “Security Feature Bypass” vulnerabilities. Though failure to enforce SafeSEH is by no means desirable, the issue in itself does not constitute an exploit vector.

Although the set of binaries affected by this issue is limited, some of the affected binaries are extensively used by applications. For example, the redistributable C runtime DLLs (such as msvcrt.dll) from Visual Studio 2003 are affected by this issue. These DLLs also do not enable support for ASLR and are therefore an attractive target for use in developing an exploit. EMET can be used to better mitigate these concerns by enabling mandatory ASLR and SEHOP for applications that make use of such DLLs.

Do I need to rebuild my binaries if they were built with Visual C++ 2003?

Installing the update for MS12-001 will fully address this issue without requiring any binaries to be rebuilt. Alternatively, this issue can also be resolved by rebuilding affected binaries with Microsoft Visual C++ .NET 2003 Service Pack 1 or later. You can determine if your binary is affected by this issue by using the Microsoft Visual C++ linker command “link.exe /dump /headers binary.dll”. Binaries with a Load Config Directory size of 0x48 are affected as shown below.

File Type: DLL
7.10 linker version
…
100000 size of heap reserve
1000 size of heap commit
0 loader flags
10 number of directories
3AC74 [    43E0] RVA [size] of Export Directory
49298 [      28] RVA [size] of Import Directory
52000 [     3B8] RVA [size] of Resource Directory
0 [       0] RVA [size] of Exception Directory
0 [       0] RVA [size] of Certificates Directory
53000 [    2B64] RVA [size] of Base Relocation Directory
39B48 [      38] RVA [size] of Debug Directory
0 [       0] RVA [size] of Architecture Directory
0 [       0] RVA [size] of Global Pointer Directory
0 [       0] RVA [size] of Thread Storage Directory
49078 [ 48] RVA [size] of Load Configuration Directory

Thanks to Gerardo Di Giacomo and our colleagues in Windows Sustained Engineering for their work on addressing this issue.

Matt Miller, MSEC Security Science

Today we released seven security bulletins. One has a maximum severity rating of Critical with the other six having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

- Jonathan Ness, MSRC Engineering

Today we released MS11-100, addressing a newly disclosed denial-of-service vulnerability affecting several vendors’ Web application platforms, including Microsoft’s ASP.NET. Yesterday, we posted an SRD blog describing the vulnerability and the detection and workaround opportunities. With this blog post, we’d like to update you on the following topics:

• Why is this bulletin rated “Critical” for a Denial-of-Service vulnerability?
• Signature progress from protection partners
• Updated snort rules
• Thanks to the ASP.NET team for holiday heroics

Why is this bulletin rated “Critical” for a Denial-of-Service vulnerability?

Yesterday evening, we published an Advanced Notification alerting customers to a new out-of-band security update planned to be released today. The notification listed the update as addressing a Critical Elevation-of-Privilege vulnerability, leading to several questions from customers who expected the bulletin addressing a Denial-of-Service vulnerability to be rated Important.

Before hearing about this vulnerability, we had planned to release a .NET security update addressing three vulnerabilities, one of which was a Critical elevation-of-privilege vulnerability. When this vulnerability notification arrived a few weeks ago, the ASP.NET team included the fix into the update already being developed and tested. So the bulletin today addresses four vulnerabilities, one of which is the ASP.NET Denial-of-Service vulnerability presented yesterday. You can read more about the other vulnerabilities in the Security Bulletin and we also invite you to join us for a webcast at 1:00 p.m. PST today (Dec 29) where we will describe the vulnerabilities and answer your questions live “on the air.” You can sign up for the webcast here.

Signature progress from protection partners

We have been working with our MAPP partners, answering questions and providing additional guidance. We are seeing early progress toward signatures, one of which being our own MMPC team having released a signature for the Forefront Threat Management gateway (TMG). The MMPC signature page is at http://www.microsoft.com/security/portal/Threat/Encyclopedia/NIS.aspx?threat=Vulnerability-Win-ASPNET-POST-DoS-CVE-2011-3414. We have also heard from partners about the progress they are making and are looking forwarding to seeing additional signatures this week. It’s exciting to see this information sharing mechanism working!

As we mentioned earlier, Web application servers from several vendors are affected by this same vulnerability. The “nice” thing about these kind of industry-wide issues is that our detection logic sent out to the MAPP partners results in protection for not just the Microsoft issue but for attacks targeting any affected platform.

Updated Snort rules

Sourcefire, while developing their IDS/IPS signature, has been kind enough to share their Snort rule with us and has given us permission both to use it in protecting Microsoft’s properties and also to share with customers. While the Snort rules we provided in the blog yesterday were effective in detecting the issue, Sourcefire's rules are more efficient. The first signature from yesterday would operate very rapidly, but the second – which had no static content match – would enter on every single TCP packet passing through the IDS. While it would exit rapidly in most cases due to the flowbit, the overhead from that would stack up and if the PCRE runs into a form post that sends 20+ parameters, the PCRE would start crunching away on the CPU quite rapidly. Thanks, Sourcefire team, for your help!

To that extent, here are two updated Snort rules:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"DOS generic web server hashing collision attack"; flow:established,to_server; content:"Content-Type|3A| application|2F|x-www-form-urlencoded"; nocase; http_header; pcre:"/([^=]+=[^&]*&){500}/OP"; reference:cve,2011-3414; reference:url,events.ccc.de/congress/2011/Fahrplan/events/4680.en.html; reference:url,technet.microsoft.com/en-us/security/advisory/2659883; classtype:attempted-dos; sid:20823; rev:1;)

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"DOS generic web server hashing collision attack"; flow:established,to_server; content:"Content-Type|3A| multipart/form-data"; nocase; http_header; pcre:"/(\r\nContent-Disposition\x3a\s+form-data\x3b[^\r\n]+\r\n\r\n.+?){500}/OPsmi"; reference:cve,2011-3414; reference:url,events.ccc.de/congress/2011/Fahrplan/events/4680.en.html; reference:url,technet.microsoft.com/en-us/security/advisory/2659883; classtype:attempted-dos; sid:20824; rev:1;)

This first rule covers the x-www-form-urlencoded use case in a single rule, instead of using flowbits, because the stream reassembler and http_inspect will put the entire request together, and allows you to view it as a single logical packet. That eliminates the concern about a rule without a content match, and means that it should be reasonably fast. Also, this changes the number of parameters necessary to trigger an alert down to 500, because a) that should have virtually no false positives in the wild anyway, and b) the fewer parameters the PCRE needs to count out, the faster the rule will be. The second rule covers the multipart/form-data use case.

Additional acknowledgement

The ASP.NET team has worked straight through the past several weeks to make this short turnaround release possible – building, packaging, and testing this security update in order to release packages in such a short time so we could protect customers as quickly as possible.

Yesterday’s SRD blog mentioned a few of the team members but missed several others. With apologies to the team members who didn’t get mentioned and at the risk of forgetting others, here are the key ASP.NET engineers who made this compressed schedule possible: Anand Paranjape, Pranav Rastogi, Jim Wang, Clay Compton, Matt Fei, Hong Li, Carl Dacosta, Amit Apple, Drago Draganov, Konst Khurin, Levi Broderick, Miguel Lacouture-Amaya, Jason Pang, Jim Carley, Jon Cole, Mike Harder, Zhenlan Wang, Dmitry Robsman, Jeffrey Cooperstein, Nazim Lala, Qing Ye, Reid Borsuk, Jamshed Damkewala, Christy Henriksson, Jose Reyes, William Mitchell, Darla Hershberger, Sophy Wang, and Ashutosh Kumar. Thanks, all of you and others behind the scenes for your work to get this package out in such a short time!

Dec 29 update:  Updated Snort rule with more efficient pcre from Sourcefire team.  Previously "/([\w\x25]+=[\w\x25]*&){500}/OPsmi".  Now "/([^=]+=[^&]*&){500}/OP".  Should be ~10x faster.  Thanks Caleb Jaren from the Microsoft Network Security Analysis & Monitoring team for testing it.

- Jonathan Ness, MSRC Engineering

Today, we released Security Advisory 2659883 alerting customers to a newly disclosed denial-of-service vulnerability affecting several vendors’ web application platforms, including Microsoft’s ASP.NET. This blog post will cover the following:

• Impact of the vulnerability
• How to know if your configuration is vulnerable to denial-of-service
• How to detect the vulnerability being exploited at network layer
• How to detect the vulnerability being exploited on the server
• Background on the workaround to protect your website

Impact of the vulnerability

This vulnerability could allow an anonymous attacker to efficiently consume all CPU resources on a web server, or even on a cluster of web servers. For ASP.NET in particular, a single specially crafted ~100kb HTTP request can consume 100% of one CPU core for between 90 – 110 seconds. An attacker could potentially repeatedly issue such requests, causing performance to degrade significantly enough to cause a denial of service condition for even multi-core servers or clusters of servers.

We anticipate the imminent public release of exploit code. Therefore, we encourage ASP.NET website owners to review the Security Advisory 2659883 and this blog post to evaluate the denial-of-service risk to your web property and to implement the workaround and/or attack detection mechanisms until a security update is available to comprehensively address the issue.

Vulnerable configurations

The root cause of the vulnerability is a computationally expensive hash table insertion mechanism triggered by an HTTP request containing thousands and thousands of form values. Therefore, any ASP.NET website that accepts requests having HTTP content types application/x-www-form-urlencoded or multipart/form-data are likely to be vulnerable. This includes the default configuration of IIS when ASP.NET is enabled and also the majority of real-world ASP.NET websites.

Detecting attacks at the network layer

Microsoft has released detailed detection guidance and code to test signatures to all 80 of our MAPP partners. We expect that the network-based IDS and IPS vendors in the program will build robust detection and protection signatures for this issue. Microsoft’s own Forefront Threat Management Gateway (TMG) will receive an update containing a signature for this issue today. (Vulnerability:Win/ASPNET.POST.DoS!NIS-2011-0001)

Microsoft’s internal network security analysis & monitoring team has developed a snort signature to detect attacks on the wire. They are currently testing it and plan to put it into production to protect Microsoft’s own network. There are two rules:

alert tcp any any -> any $HTTP_PORTS (msg:"Microsoft 2659883 URL Encoded Content flowbit"; flow:established,to_server; content:" application|2F|x|2D|www|2D|form|2D|urlencoded";nocase;http_header;flowbits:set,urlEncodedContentType;flowbits:noalert;classtype:misc-activity; sid:1000019; rev:1;)

alert tcp any any -> any $HTTP_PORTS (msg:"Confirmed Microsoft 2659883 payload";flow:established,to_server;flowbits:isset,urlEncodedContentType;pcre:"/(\w*(&|=)){1000,}/smi";flowbits:unset,urlEncodedContentType; sid:1000020;rev:1;)

The first rule will check for the content type “application/x-www-form-urlencoded”. If it is present, the rule will set the flowbit “urlEncodedType”. If the urlEncodedType flowbit is set, the second rule will check for 1000 or more form values being sent in the HTTP request. As Microsoft, the other affected vendors, and protection partners continue to investigate this issue, we will likely discover more efficient ways to detect exploits in the wild. Please contact us at switech –at- microsoft dot com with ideas for more efficient detection than the above.

Detecting attacks at the server level

Successful attacks will exhaust server CPU resources. Therefore, you can detect attacks by something as simple as Task Manager on the web server. The screenshot below shows the result of one malicious request against a 4 core machine. Notice that one entire core is dedicated to processing this one request (~25% CPU usage).

More information about the workaround to protect your web properties

The security advisory lists workaround steps to limit the maximum HTTP request size that ASP.NET will accept from clients. Attackers would need to send (relatively) large HTTP requests to exploit the vulnerability. So if your website does not normally need to accept large requests from legitimate users, you can configure ASP.NET to reject all requests larger than a certain size. Note that if your website does need to accept user uploads, this workaround is likely to block legitimate requests. In that case, you should not use this workaround and instead wait for the comprehensive security update.

If your application uses ViewState, we recommend limiting HTTP request size to 200kb. To do so, add the following to your ASP.NET configuration file:

<configuration>
 <system.web>
 <httpRuntime maxRequestLength="200"/>
 </system.web>
</configuration>

If your application does not use ASP.NET ViewState, we recommend limiting HTTP request size to 20kb.  To do so, add the following to your ASP.NET configuration file:

<configuration>
 <system.web>
 <httpRuntime maxRequestLength="20"/>
 </system.web>
</configuration>

Note that any requests larger than the maxRequestLength will result in a ConfigurationErrorsException thrown server-side and an HTTP error status returned to the client. Therefore, we want to stress that this workaround option will disrupt both legitimate and attack HTTP requests that exceed the request length. Therefore, please thoroughly test this workaround in your environment, focusing on any scenarios that involve uploading files or making large data submissions to the web service.

Non-workaround – URLScan

Microsoft’s URLScan tool often helps mitigate vulnerabilities involving malicious HTTP requests. However, it is not applicable in this particular case because the malicious form values in a successful attack are most likely to be in the body of the HTTP request, not in the URL itself. URLScan does not inspect the request body. Attacks are unlikely to be successful using only the URL (even factoring in cookies, headers, server variables, etc) due to a default 16KB limit for the combined request size excluding the request body. The request body is the only unbounded payload.

Conclusion

Our ASP.NET team is hard at work testing a security update for broad deployment. If you are concerned about the risk of your ASP.NET site being targeted by attackers, please consider implementing the detection and workaround guidance described in this blog post.

Thanks to the ASP.NET team for the hours and hours of work spent over the holiday on this issue - Dmitry Robsman, Jeffrey Cooperstein, Zhenlan Wang, Matt Fei, Nazim Lala, Jamshed Damkewala, Hong Li, Reid Borsuk and others! Thanks Mike Harder for your work investigating different workaround options. Thanks Dave Midturi, David Seidman, Andrew Gross, and Maarten van Horenbeeck for your help in coordination. Thanks Chengyun Chu and Ali Pezeshk for your technical investigation. And finally thanks Caleb Jaren and Abhijeet Hatekar for the snort signature help!

- Suha Can and Jonathan Ness, MSRC Engineering

Today we released thirteen security bulletins. Three have a maximum severity rating of Critical with the other ten having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

Thanks to the entire MSRC Engineering team for the hard work on these cases!!

- Jonathan Ness, MSRC Engineering

This month we released MS11-090 to address a vulnerability in the Microsoft Time component (CVE-2011-3397), which features the deprecated time behavior that is still supported in IE6. We would like to provide further information about this issue and help explain why a “binary behavior kill bit” is the appropriate course of action.

Which products are affected?

The vulnerable component was removed from IE7 and later browsers. IE6 is the only supported browser that is affected.

What is, or was, the time behavior?

The time behavior is a feature of HTML+TIME 1.0, which was released in IE5. It provides an active timeline for enabling animated content.

Why is CVE-2011-3397 included in the ActiveX Kill Bits bulletin (MS11-090) instead of in the cumulative IE bulletin (MS11-099)?

The most appropriate remedy for this issue is to issue a kill bit to disable the deprecated binary behavior.

What is the binary behavior kill bit?

Usually, the kill bits we issue are targeted toward disabling specific ActiveX Objects. For example, the following registry key sets a kill bit for an ActiveX object on x86-based systems:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
"Compatibility Flags"=dword:00000400

The binary behavior kill bit is very similar. To set a kill bit for a particular binary behavior, you can use:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}]
"Compatibility Flags"=dword:04000400

The highlighted bit notifies IE to never load binary behaviors from the specific CLSID. The registry key for x64-based systems is:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control 

x86 IE:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control

For more information about the kill bit, please refer to David Ross’s excellent Kill-Bit FAQ Series. It will be updated shortly to discuss the binary behavior kill bit.

Special thanks to Kwan-Leung Chan and Eric Lawrence on the IE team.

- Chengyun Chu, MSRC Engineering

Today, we released MS11-087 addressing an issue in the font parsing subsystem of win32k.sys, CVE-2011-3402. The bulletin received a Critical rating due to a potential browser-based attack vector. We have not seen the browser-based attack vector exploited in the wild. The bulletin includes a workaround to disable this remote code execution attack surface. You might consider applying the workaround even after applying security update MS11-087, simply to reduce your attack surface. This blog explains how in more detail.

Issue Summary

This vulnerability has been used to drop the Duqu malware. An insufficient bounds check within the font parsing subsystem of win32k.sys could potentially allow a malformed font to corrupt ring0 memory. In the case of the Duqu dropper, a malformed font embedded inside an Office Word document triggered this memory corruption vulnerability to jump to attacker shellcode.

To be clear, Duqu did not exploit the browser-based attack vector. As far as we know, this vulnerability has only been exploited via a custom font embedded within an Office document. However, attackers could potentially construct a malicious font in such a way that it could be embedded in a webpage. There is an easy workaround to block that particular attack surface.

Protecting your environment

The best option for protecting against this particular vulnerability is to apply the MS11-087 security update. It will comprehensively address this issue.

If you are unable to apply the update right away and/or are concerned primarily about the browser-based attack surface, you might consider simply disabling IE’s ability to download custom fonts entirely. The side effect of this approach is potential display and layout glitches on web pages that leverage custom fonts to display text in interesting new ways. However, the vast majority of web sites use fonts included with Windows or use text layout tricks that do not require this particular custom font technology. Opening a web page that embeds a custom font after you have applied the workaround will cause Internet Explorer to display the text using a built-in font. Below, you can see the user experience of browsing to a webpage that leverages a custom font:

Figure 1: Webpage using custom, downloaded font

Figure 2: Same webpage displayed after workaround is applied

Workaround Steps

You can disable custom font download in Internet Explorer either interactively (using the GUI) or via Group Policy or a Management Deployment Script across multiple machines.

- Interactive deployment

• Launch Internet Explorer
• On the ‘Tools’ Menu select ‘Internet Options’.
• Click the ‘Security’ Tab.
• To change the setting for the ‘Internet’ zone select ‘Internet’ and press the ‘Custom Level’ button.
• Scroll down to the ‘Downloads’ section and select ‘Prompt’ or ‘Disable’ for the ‘Font Download’ security setting.
• Press OK to close the ‘Security Settings’ dialog box.
• Press OK to close the ‘Internet Options’ dialog box.

- Group Policy deployment

NOTE: The Group Policy MMC snap-in can be used to set policy for a machine, for an organizational unit or an entire domain. It is assumed that the reader will know how to deploy the steps below for their particular environment.

• · Open the group policy management and configure it to work with the appropriate group policy object (i.e. local machine, OU or domain GPO).
• · Navigate to the following node:
  • o User Configuration -> Windows Settings -> Internet Explorer Maintenance -> Security.
• · Double click ‘Security Zones and Content Rating’.
• · On the ‘Security Zones and Content Rating’ dialog box select ‘Import the current security zones and privacy settings’ and then click the ‘Modify settings’ button.
• · NOTE: This will create a group policy for Internet Explorer based on the settings of the currently logged in user.
• · On the ‘Internet Properties’ dialog box ensure the ‘Internet’ zone is selected and then press ‘custom level’.
• · Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.
• · Press OK to return to the ‘Internet Properties’ dialog box.
• · On the “Internet Properties’ dialog box select the ‘Local Intranet’ zone and then press ‘custom level’.
• · Scroll down to ‘Downloads’ and set ‘Font Download’ to ‘Prompt’ or ‘Disable’.
• · Press OK to return to the ‘Internet Properties’ dialog box.
• · Press OK to return to the ‘Security Zones and Content Ratings’ dialog box.
• · Press OK to return to the group policy management console.
• · Refresh the group policy on all machines or wait for the next scheduled group policy refresh interval for the settings to take effect.

- Managed Deployment Script deployment

This security setting can be manually entered into the registry by creating a registry script and importing it either by double clicking it or running regedit.exe as part of a logon or machine startup script. For managed deployments Regedit.exe can be used to import a registry script silently with the ‘-s’ switch. For more information on regedit command line switches refer to: http://support.microsoft.com/kb/q82821/

To set this setting to ‘Prompt’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

Windows Registry Editor Version 5.00
; Zone 1 is the local intranet zone
; 1604 is the Font download policy
; dword:00000001 sets the policy to prompt
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"1604"=dword:00000001
; Zone 3 is the internet zone
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1604"=dword:00000001

To set this setting to ‘Disable’ for the Internet and Local Intranet Zones paste the following text into a .REG file and then import the .REG file on managed machines as part of your organizations managed deployment process:

Windows Registry Editor Version 5.00
; Zone 1 is the local intranet zone
; 1604 is the Font download policy
; dword:00000003 sets the policy to disable
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\1]
"1604"=dword:00000003
; Zone 3 is the internet zone
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"1604"=dword:00000003

Bottom Line

We encourage you to first apply the security update to address this particular vulnerability. However, you might consider also blocking the browser-based font attack surface from within Internet Explorer as a good ‘attack surface reduction’ step. The tiny minority of web pages that embed custom fonts may display differently but you will be protected from any potential browser-based attack vectors leveraging custom fonts within Internet Explorer.

- Chengyun Chu and Jonathan Ness, MSRC Engineering

This month we released MS11-083 to address an externally found reference counter issue in TCP/IP stack. Here we would like to give further information about the exploitability of this vulnerability.
 
Vulnerability
The vulnerability presents itself in the specific scenario where an attacker can send a large number of specially crafted UDP packets to a random port that does not have a service listening. While processing these network packets it is observed that some used structures are referenced but not dereferenced properly. This unbalanced reference counting could eventually lead to an integer overflow of the reference counter.
  
Effects of reference count wrap around
With the above described vulnerability, when the system is deluged with network packets, the reference counter in the structure will keep incrementing and eventually wrap around.

If a dereference happens just after the counter has wrapped to zero, the structure will be freed. Depending on the timing conditions, four scenarios are possible:
• The memory is still mapped and contains the old data. No crash results and the system works as normal.
• The memory is unmapped and the system crashes when it is referenced. This results in a system denial-of-service.
• The memory is re-allocated for the same structure. No crash results and the system works as normal.
• The memory is re-allocated for a different structure. This could result in a system crash, or if attacker-controlled data is present, could lead to memory corruption or remote code execution.
 
Exploitability 
While the last scenario can theoretically lead to RCE, we believe it is difficult to achieve RCE using this vulnerability considering that the type of network packets required are normally filtered at the perimeter and the small timing window between the release and next access of the structure, and a large number of packets are required to pull off the attack. As a result, we assign an Exploitability Index of "2" for this vulnerability.

Ali Rahbar, Mark Wodrich from MSRC Engineering, Gangadhara Swamy from IDC.

Special thanks to Jeremy Tinder from MSRC.

Today we released eight security bulletins. Two have a maximum severity rating of Critical with the other six having a maximum severity rating of Important. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

- Jonathan Ness, MSRC Engineering

On January 10^th, Microsoft released MS12-006 in response to a new vulnerability discovered in September in SSL 3.0 and TLS 1.0. Here we would like to give further information about the technique used to exploit this vulnerability and workaround options Microsoft has released if you discover a compatibility issue after installing the update.

Is SSL broken?

Yes and no. Yes means that under certain circumstances, the attacker can decrypt the encrypted SSL traffic. No means that there are significant mitigating factors that would make the attacks difficult or impossible. By default, SSL 3.0 and TLS 1.0 are enabled on Windows operating systems.

What does the update do?

The update modifies the way that the Windows Secure Channel (SChannel) component sends and receives encrypted network packets. This addresses the vulnerability affecting WinHTTP and provides the possibility to enable the protection system-wide. However, in order to be protected from the web-based attack vector through Internet Explorer for this vulnerability, customers must install both MS12-006, and the Cumulative Security Update for Internet Explorer (2618444), MS11-099.

Attack vector

In the advisory, it is mentioned that the vulnerability could allow the attacker to decrypt the SSL 3.0/TLS 1.0 encrypted traffic. While the affected component is a Windows component, the primary vector is to attack the browser’s use of the HTTPS protocol to intercept sensitive information, such as the session cookie of the HTTPS session.

Mitigation

Based on our current investigation, the following are mitigating factors that would make any potential attack via currently known exploit vectors difficult or impossible:

• The HTTPS session must be actively attacked by a man-in-the-middle; simply observing the encrypted traffic is not sufficient.
• The malicious code the attacker uses to decrypt the HTTPS traffic must be injected and run within the user’s browser session.
• The attacker’s malicious code needs to be treated as from the same origin as the HTTPS server in order to it to be allowed to piggyback on an existing HTTPS connection. Most likely it requires the attacker to exploit another vulnerability to bypass the browser’s same origin policy.

Therefore, if the user closes all existing HTTP tabs and untrusted HTTPS tabs, then browses to the trusted HTTPS site, such as the log-in page of hotmail.com in a new browser session, and logs out of that HTTPS session before browsing any other HTTP sites or untrusted HTTPS sites, the user will NOT be at risk for this attack.

Workaround

One workaround we would encourage the web server administrators to do is to give a higher priority for the RC4 Cipher Suite than CBC since the attack only affects cipher suites that use CBC. By giving a higher priority for RC4 on the server, RC4 instead of CBC will be used in the security communication since all of windows clients support RC4, unless put in FIPS compliant configuration. Please refer to this MSDN article to learn how to perform this operation via group policy. It is an effective option for web server administrators using Windows Vista or Windows Server 2008 and later platforms.  We recommend putting TLS_RSA_WITH_RC4_128_SHA as the top of the priority list, as indicated in the following image:

We would also encourage users and web administrators to enable the newer security protocols, such as TLS 1.1, on both the client side and the server side. By default, these are disabled (more below). If the browser and web server both enable TLS 1.1, the HTTPS traffic uses TLS 1.1 protocol instead of SSL 3.0/TLS 1.0, and thus won’t be affected by such attacks. TLS 1.1 protocol is supported in Windows 7 and Windows 2008 R2.

Automated FixIt Options:

Microsoft has released several FixIts to help automate enabling TLS 1.1 and a workaround FixIt to disable the functionality of the update if you find a compatibility issue that you need immediate ability to rollback without uninstalling.

To ENABLE TLS 1.1 for Internet Explorer and other WinINET-based applications running on Windows 7 and Windows Server 2008 R2, please click here: 

To ENABLE TLS 1.1 for server-side components running on Windows 7 and Windows Server 2008 R2, click here: 

If you would like to revert the changes made by these FixIt's, you can find a corresponding DISABLE Fixit for both the client side and server-side changes at http://support.microsoft.com/kb/2588513.

To temporarily DISABLE the security update to confirm a compatibility issue without having to uninstall it, click here: 

To re-enable the security update, click here: 

Why TLS 1.1 is not enabled by default?

The main reason to not enable TLS 1.1 by default is due to compatibility problems. We need more servers to implement HTTPS protocols correctly so we can enable TLS 1.1 by default in the client in the future versions of IE. We will work hard to drive adoption of TLS 1.1 or TLS 1.2 as an industry-wide effort.

Special thanks to Nasko Oskov and Eric Lawrence.

Update Sep 27 - Mitigating factors list applies to all currently known attack vectors.  Thanks for the suggestion to clarify, Juliano.

Update Mar 14, 2012– Renaming to reflect release of MS12-006 and adding links for additional FixIt items. Special thanks to Kevin Ledman. 

- Chengyun Chu, Jonathan Ness and Mark Wodrich from MSRC Engineering

Last week, we released Security Advisory 2607712, notifying customers that fraudulent digital certificates had been issued by certificate authority DigiNotar. We’d like to follow up on that notification in this blog post by explaining more about the potential risks and actions you can take to protect yourself from any potential attacks that would leverage those fraudulent certificates.

• Scope of the risk
• Vulnerable configurations
• What Microsoft is doing to protect you
• What you can do to protect yourself
• Additional protections built-in to Windows Update

Scope of the risk

Digital certificates issued by a trusted Certificate Authority (CA) establish the identity of a computer. Protocols that assure your privacy, such as SSL (HTTPS) and TLS, leverage a server’s digital certificate to ensure that no third party can eavesdrop on or tamper with conversations between a client and the server. Clients and servers establish their identity via a digital certificate. Clients make a decision to trust the identity of the server because they trust that a CA verifies the legitimacy of the person or company requesting the certificate. If a trusted CA were to be compromised or tricked into issuing fraudulent certificates, a malicious attacker could potentially request and be granted a digital certificate that would allow the attacker to participate in HTTPS conversations, snooping on or tampering with the contents.

For an attack to be successful, an attacker must have been issued a digital certificate for the server or domain to which the client is initiating a connection. Also, the attacker must be able to tamper with the conversation in progress. Practically speaking, this tampering can happen in one of three ways:

• The attacker is on your local network (open wireless network, for example);
• The attacker owns or operates the network infrastructure between the victim client and the listening server; or
• The attacker controls the DNS server used by your ISP, or can influence your choice of DNS server via DHCP responses if a client gets DNS settings via DHCP.

Without this type of “man-in-the-middle” access, an attacker would be unlikely to be successful in carrying out an attack.

In this particular case, we were originally aware of fraudulent certificates issued by DigiNotar for *.google.com and have since become aware of fraudulent certificates issued for *.microsoft.com, *.windowsupdate.com, www.update.microsoft.com, and a number of other domains for which conversation privacy is extremely important. Windows Update is a special case addressed later in the blog; however, suffice it to say that if the attacker had one of those certificates and had man-in-the-middle access to your network traffic, they could potentially snoop on (or change the contents of) conversations between you and any of those domains.

Vulnerable configurations

All versions of Windows are affected by this attack. However, when a user initiates an HTTPS SSL connection via Internet Explorer on Windows Vista, Windows 7, or Windows Server 2008 and encounters a new root certificate, the Windows certificate chain verification software checks a list of valid root certificates, which is hosted on Windows Update. As of August 29th, this Certificate Trust List (CTL) on Windows Update has been revised to remove DigiNotar from the list of trusted Certificate Authorities so that any certificates issued by DigiNotar are no longer trusted for HTTPS conversations.

Windows XP and Windows Server 2003 do not have the same Windows Update check mechanism. Instead, these versions of Windows rely on a static list of trusted root certificate authorities. This list is updated through the non-security update “Update for Root Certificates (KB 931125)”. DigiNotar was not initially included as a trusted root certificate in Windows XP, so if you have never installed this update, you are not vulnerable to any certificates issued by them.

However, any Windows XP or Windows Server 2003 system that installed this update as of November 2008 or later would have DigiNotar added as a trusted root certificate. Administrators of these systems can follow the steps in the “What you can do to protect yourself” section below to take proactive actions to remove DigiNotar as a trusted root Certificate Authority until Microsoft releases an update that fully addresses this problem.

Windows Phone devices are unaffected. No Windows Mobile devices have a DigiNotar certificate in the Trusted Root Certificate Store.

What Microsoft is doing to protect you on Windows Vista and later platforms

Microsoft has updated the Certificate Trust List (CTL) hosted on Windows Update to remove DigiNotar as a trusted root Certificate Authority. Attacks targeting Internet Explorer users on Windows Vista and later platforms any time after August 29th will likely fail. However, we should note that systems having previously encountered DigiNotar certificates may have cached DigiNotar as a trusted root Certificate Authority. This cached list is updated client-side every seven days. Therefore, the last date on which any attack targeting Internet Explorer users on Windows Vista and later platforms might possibly be successful is September 5th.

What Microsoft is doing to protect you on Windows XP and Windows Server 2003

We are currently preparing an update for Windows XP and Windows Server 2003 platforms which will add DigiNotar to our Untrusted Certificate Store. This update will be available soon.

What you can do to protect yourself

First, as indicated in the security advisory, we recommend keeping Microsoft software updated. If you’re able to do so, opt into Automatic Updates to automatically get the Windows XP and Windows Server 2003 updates when they become available.

Second, you can choose to delete the DigiNotar root from the root store manually. You might consider doing this if you believe the risk to your network or system is urgent and you would like to take action before the Windows XP and Windows Server 2003 update becomes available. After doing this, you’ll also need to clear the local cache. The steps for both removing the DigiNotar root from the trusted root CA store and clearing the cache are listed below.

Step 1: Remove the DigiNotar Root from the trusted root CA store

• Click Start, click Start Search, type mmc, and then press ENTER.
• On the File menu, click Add/Remove Snap-in
• Under Available snap-ins, click Certificates, and then click Add
• Under This snap-in will always manage certificates for, click Computer account, and then click Next
• Click Local computer, and click Finish
• If you have no more snap-ins to add to the console, click OK
• In the console tree, double-click Certificates
• Double-click the Trusted Root Certification Authorities store and click on Certificates to view all certificates in the store
• Select the two DigiNotar Root CA certificates. You can confirm the right certificates by checking their thumbprints which should be “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c” and “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”
• Right-click the certificates and select Delete

To perform the above steps from the command-line, you can use the certutil.exe tools as follows:

• certutil -delstore authroot “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c”
• certutil -delstore authroot “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”

If you distribute roots in your enterprise using group policy, follow the instructions to remove a root across an enterprise network via group policy - http://technet.microsoft.com/en-us/library/cc786148(WS.10).aspx. In step 3 of those group policy instructions, choose the root CA in question here - DigiNotar Root CAs with thumbprints "c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c" and "43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3".

Step 2: Clear the cache to remove any older cached CTL

The simplest way to do so is to use “certutil –urlcache * delete”. This will clean up the cache for the current user. You can find further documentation on this step, including a Microsoft Fix It package to clean up the cache, at http://support.microsoft.com/kb/2328240

--

As indicated above, most customers on Windows Vista and later platforms are already protected due to the updated Certificate Trust List on Windows Update, which is checked when Windows encounters a new root Certificate Authority. To ensure that DigiNotar has not been cached locally as a trusted root CA, you can clear the local cached CTL as explained above. A fresh CTL will automatically be downloaded the next time Windows encounters a new root CA.

There is one final edge case to consider that will not be automatically protected:

• If you are an enterprise customer having Windows Vista and later workstations; and
• If you have disabled the auto root update mechanism via the group policy option; and
• If you have manually added DigiNotar as a trusted root authority –

  Then you likely will want to add the DigiNotar roots to the Untrusted Certificate Store via group policy.

Additional protections built-in to Windows Update

Attackers are not able to leverage a fraudulent Windows Update certificate to install malware via the Windows Update servers. The Windows Update client will only install binary payloads signed by the actual Microsoft root CA certificate, which is issued and secured by Microsoft. Also, Windows Update itself is not at risk, even to an attacker with a fraudulent certificate.

Thanks to Yogesh Mehta, Shain Wray, Charles Anthe, and Mark Wodrich for the help with this blog post.

Updated Sept 5:  Added certutil.exe command line example.  Thanks Uwe Wizovsky for the tip.

- Jonathan Ness, MSRC Engineering

Today we released 13 security bulletins. Two have a maximum severity rating of Critical, nine have a maximum severity rating of Important, and two have a maximum severity rating of Moderate. We hope that the table below helps you prioritize the deployment of the updates appropriately for your environment.

- Jonathan Ness, MSRC Engineering

Today we released MS11-058 to address two vulnerabilities in the Microsoft DNS Service. One of the two issues, CVE-2011-1966, could potentially allow an attacker who successfully exploited the vulnerability to run arbitrary code on Windows Server 2008 and Windows Server 2008 R2 DNS servers having a particular DNS configuration. We’d like to share more detail in this blog post and help you make a risk decision for your environment.

• Affected DNS configuration
• Unlikely to be exploited for code execution
• More detail about the attack vector
• Answers to common questions

Affected DNS configuration

This vulnerability affects DNS servers that allow attackers to issue lookup requests for another domain name in a way that would cause the DNS server to request the answer from a malicious DNS server. Specifically, if an attacker can cause a DNS server to request a DNS NAPTR resource record from a malicious DNS server, the attacker could potentially trigger the vulnerability described by CVE-2011-1966 on the DNS server of which the attacker is making the request.

One common affected configuration is a caching or relay DNS server on a corporate network where a malicious user is lurking. Less likely to be affected are authoritative DNS servers hosting zones exposed to the Internet, where recursion is often disabled. For example, anyone on the Internet can connect to the microsoft.com authoritative DNS server, but that server will not relay requests to a malicious DNS server.

More information about the DNS protocol, DNS recursion and forwarding:

• How DNS query works
• Understanding forwarders

Unlikely to be exploited for code execution

An affected system receiving a malicious NAPTR resource record from a malicious DNS server will result in heap memory corruption. For this reason, the security bulletin describes this issue as having the potential for remote code execution. However, due to the nature of this vulnerability, it is far more likely to result in a denial-of-service condition where the DNS service terminates unexpectedly and less likely to result in remote code execution.

This is due to the type of vulnerability and the platform mitigations provided by Windows Server 2008. The issue is a sign-extension vulnerability where a small negative number is expanded to a larger type without proper checks. Later, this large negative number is used as a memcpy count to populate a heap buffer. The copy length will always be at least 0x80000000 bytes long so the copy operation itself will likely fail in the absence of 2+ GB of memory available to be copied. Even if an attacker is able to successfully populate memory for the copy to succeed and massage the heap to gain control of the process, the platform mitigations of ASLR, DEP, and the heap metadata protection must still be overcome before malicious code could be run. And, finally, an attacker has only three opportunities to exploit a particular DNS server - the service control manager will no longer restart it after it crashes three times. While code execution is theoretically possible, we think a denial-of-service is most likely. Hence, we have rated the likelihood of exploit code for remote code execution appearing in the next 30 days as “3 – Functioning Exploit Code Unlikely”.

More detail about the attack vector

Due to the distributed nature of the DNS protocol, DNS servers configured to resolve names on behalf of client and applications usually support recursion (unless explicitly disabled by Admin), allowing them to talk and exchange information with other DNS Servers. The vulnerability exists in the way a Microsoft DNS Server parses NAPTR records from a remote DNS server. Here is an example, assuming the attacker controls the contoso.com DNS server and has configured it to return malicious NAPTR record data:

The victim DNS server in this case could be an unpatched Microsoft DNS Server with recursion / forwarding enabled. The attacker knows that the victim server will communicate with the contoso.com DNS Server to fetch the DNS NAPTR record requested by the client. The attacker’s malicious DNS Server then responds with the malformed NAPTR data which triggers a crash on the victim DNS Server. The victim server crashes due to the CVE-2011-1966 vulnerability while attempting to parse the malicious NAPTR record content. The crash happens only for a particular set of data for NAPTR records.

Answers to common questions

Q: I don’t host NAPTR record; is this patch applicable to my deployment?

A: Yes. As indicated above, the problem lies in the code that parses the malformed data while receiving it from other sources, not while hosting it. If your DNS Servers have recursion enabled and allows potential attackers to issue requests, this patch should be applied.

Q: I host only authoritative zones on my DNS server and have disabled recursion. Is it vulnerable?

A: This configuration is technically not vulnerable. However, due to the dynamic nature of networks, we recommend that you patch all DNS servers to prevent future configuration changes from opening attack surface.

Q: Are enterprise deployments vulnerable to this attack?

A: Enterprise networks that use a web proxy and do not allow enterprise DNS server to resolve Internet names would certainly be at reduced risk. One attack vector remaining in that case is that of an attacker with minor access rights on an enterprise network bringing up a malicious DNS server. However, they will likely face difficulty in coercing the real enterprise DNS server to direct queries to it without some level of administrative privilege.

Acknowledgements

Thanks Bruce Dang, Saaransh Bagga, Shreyas Behera, Jeremy Tinder, Nicolas Guigo, Matt Miller, and Jeff Westhead for contributing to this blog post.

- MSRC Engineering

How can you protect yourself, your business, and your customers when faced with an unknown or unpatched software vulnerability? This question can be difficult to answer but it is nevertheless worthy of thoughtful consideration. One particularly noteworthy answer to this question is provided in the form of exploit mitigation technologies such as DEP and ASLR, which are designed to make it difficult and costly for an attacker to exploit a software vulnerability. The protection offered by exploit mitigations is generally independent of a single vulnerability and therefore opens the door to protecting against the exploitation of vulnerabilities that may currently be unknown or that have not yet been addressed through a security update.

The virtues of exploit mitigations are something that we strongly believe in at Microsoft. This belief is clearly demonstrated by the exploit mitigation features we have added to our products over time (DEP, ASLR, /GS, etc) and through policies in the Microsoft’s Security Development Lifecycle (SDL) that require product teams to leverage these features. Although many of these technologies have been available for quite some time, we have found that adoption by third-party software vendors has been slower than we would like. We have also heard from many enterprise administrators that they have difficulty justifying the use of exploit mitigations or are hesitant to make use of them because of performance and compatibility concerns. This is something we would like to change.

In the interest of helping to encourage adoption within the enterprise and by third-party software vendors, we have published a paper entitled Mitigating Software Vulnerabilities. This paper provides justification for the use of exploit-mitigation technologies and enumerates the set of technologies that are available today. The description of each technology includes an overview of how the technology works and what performance, compatibility, and deployment considerations should be taken into account, if any. The availability of each technology is also presented for supported operating system and compiler versions. The paper concludes with a set of recommended actions for software developers, enterprise administrators, and home and business users. In particular, we recommend that the Enhanced Mitigation Experience Toolkit (EMET) be used to evaluate the impact of enabling certain mitigations and to protect systems and applications that may be at-risk.

It is our hope that this paper will demonstrate the need for exploit mitigations and help encourage adoption of exploit mitigation technologies within the Windows ecosystem. We encourage you to check back frequently for more information about upcoming security tools and technologies at http://www.microsoft.com/security/msec.aspx.

- Matt Miller, Microsoft Security Engineering Center

The single Critical vulnerability in today’s batch of security updates addresses an issue in the Bluetooth stack. Your workstations’ risk to this vulnerability varies, depending on a number of factors. I’d like to use this blog post to outline those risk factors.

How can I protect my system?

The best way to protect any potentially vulnerable system is to apply the MS11-053 security update. If you are not able to apply the security update, you can close off the attack surface by preventing any Bluetooth device from connecting to your computer. The graphic below shows the Windows 7 Bluetooth Settings option for doing so. Side effect: Your Bluetooth mouse or headset will stop working until you re-allow Bluetooth devices to connect to your computer.

Am I vulnerable to remote code execution attacks today?

Short answer: Probably not. And here’s why:

Exploitability: First, we assigned this vulnerability with an Exploitability Index rating of “2”. We believe it will be difficult to build a reliable exploit for code execution using this vulnerability. It’s more likely that attackers will discover a way to cause a system denial-of-service (“bugcheck” / “bluescreen”) using this vulnerability.

Discoverability: Secondly, your system’s 48-bit Bluetooth address is not “discoverable” by default. Notice in the Bluetooth Settings screenshot above that Bluetooth devices are not allowed by default to “find” this computer. If your system were “discoverable,” it would respond to attacker SDP queries with its Bluetooth address. But in the default state, an attacker must obtain your Bluetooth address another way – either via bruteforcing it or extracting it from Bluetooth traffic captured over-the-air.

Extracting Bluetooth address by sniffing traffic: If you have paired a Bluetooth peripheral and are actively communicating, it is hard but not impossible to extract the Bluetooth address from the traffic sent over-the-air. A device is available on the market for $10,000 - $30,000 to do this in about 5 minutes. Research continues to advance in this space and we expect in years to come that this will become quicker for attackers. But for now, it remains difficult but not impossible to extract the Bluetooth address from over-the-air traffic.

Proximity: Finally, while this vulnerability is exposed remotely, it is not reachable over the Internet. An attacker must be physically nearby to target you. Again, recent research has widened the definition of “nearby” for Bluetooth but suffice to say that an attacker would need to be within line-of-sight. This nearby attacker then could spend several hours brute-forcing your Bluetooth address and attempting to exploit the vulnerability.

This combination of factors leads us to believe that systems are unlikely to be exposed to reliable remote code execution exploits via this vulnerability in the next 30 days.

Thanks to Krupa Poobala-chandran from the Windows Sustained Engineering team for the help yesterday afternoon pulling this blog post together.

- Jonathan Ness, MSRC Engineering

Hi.

i am working with a IT software House our managers and network engineers also have domain admin rights. now i am facing from last month that some one deleting user profile folders from our shared folder. i am trying to catch that person by log files but un successful. can anyone help me any tool or way to find that person who is doing that:(

Hello, I use a home brew backup program in C# that uses the archive attribute of each file to determine whether the file has changed and should be backed up (during an incremental backup).

I also routinely change add and remove user access privileges to the drives.  Typically all file privileges are inherited from the drive (root).  These drives are run-of-the-mill logical partitions.

Well, I've found when I change the access privileges to the drive, all of the archive attributes of all of the files under it are reset.   This makes no sense to me because no data has changed in the files, just the access. 

Could someone enlighten me as to how to stop the archive attribute from changing just because I change the disk privileges?   Should I just change to explicit (as opposed to inherited) privileges?

--tom

Hello

I have a digitally signed program, which' certificate shows the validity period as 4.12.2008 to 12.12.2009. It was issued from Verisign to Logitech.

The validity period is expired, but the certificate status says "This certificate is OK" and i can't see any errors.

I don't understand why it doesn't produce an error.

If a program is digitally signed during that period (4.12.2008 to 12.12.2009) will it show the status as OK even years after that, because the actual signing was done during that period?

Hello. 

If company users work offline and they run a code signed software, how does the certificate revocation status check work? 

The revocation status tries to check from an online server, whether the certificate used to sign the software is legit, but if the users are off-line, will it produce an error? Especially an error that is visible to end-users?

Thanks for your help

Hello guyz,

I need some help regarding enterprise ca issue.

Problem: Recently My main active directory server has crashed together with root enterprise ca. the server is up again and i'm trying to restore to previous CA state but cannot locate any backup. is it possible to restore PKI from a subordinate?? Previously the PKI has been deployed to 50+ server across the country, it would be disastrous for me to re-deploy a fresh one.

note: the question above comes from a newbie ;p ..still trying to understand the cert/pki architecture. i could not find any stright-forward workaround for this issue elsewhere.

Hello all,

When using pkiview to see the health of our environment, we get red x's from a 2003 server, but from a 2008 server we get all "OK's".. Really frustrating because it leads you to believe something might be underlying wrong or not working....

Anyone else seen this weird sort of behavior??

Thanks!

Windows Server 2008 R2 introduces some changes from the security perspective of the operating system. The core changes are related to: authorization and access control, identity and authentication, information protection, security policies and security roles. To see the complete list of changes see  What's New for Security in Windows Server 2008.

You can also find other security related scenarios with Windows Server 2008 R2 and Windows 7 in the following articles:

Hello experts,

Wanted to post a question and get your opinion recommendations.  I am currently in the process of setting up a secondary Issuing CA that can support the new CNG/ECC algorithms.   Everything has been successful thus far, and I able to install a certificate that uses the RSASSA-PSS Signature Algorithm as well as the sha256 Signature Hash Algorithm.

My problem is, however, when I scroll to the bottom of this certificates details pane, the field that displays the "Thumbprint Algorithm" still shows up as SHA1. Is this what is expected?  I would assume that the thumbprint algorithm should match the SHA256 path.

Thanks again for any comments/suggestions!

Windows Server 2008 R2 introduces some changes from the security perspective of the operating system. The core changes are related to: authorization and access control, identity and authentication, information protection, security policies and security roles. To see the complete list of changes see  What's New for Security in Windows Server 2008.

You can also find other security related scenarios with Windows Server 2008 R2 and Windows 7 in the following articles:

Hi everybody.

I am testing smart card logon in windows server 2003. I have Windows 2003 Server sp2 installed computer. I have rised on it Active Directory domain service, IIS and Cerification Authority(Enterprise). From internet explorer I am trying to enroll a certificate for a smart card. I am using following smart cards: CardMan 3121 by Omnikey and GemPC Twin Reader. Smart cards are Gemalto Classic V3 and Siemens CardOS v4.3b.  But when I tried to request a certificate for a smart card on behalf of another user by using the smart card certificate enrollment station an unexpected error occured. (An unexpected error occured. Error: (0x80090023)

Hello!

I need to write script which check that account used as service account for SQL Server DBEngine winservice has defined local policy "Lack Pages". How I can do it? Initially Ithought about SC SDSHOW...but now I'm not shure that it's right tool :( Could you share you thoughts?

Thank you!

Someone has gained access to my email account. How do I correct and block?

Background: A friend sent me personal pictures, which I viewed but left in the email -- I did not download onto my computer. Those pix have now appeared on an adult ____ site, causing massive embarassment all around.

Any suggestions on protecting my email account greatly appreciated. I've sent a message to yahoo but dont know what else to do.

Hi,

We have a Radius server program (.Net) that we have written.

We use the program to authenticate multiple platforms. For example, using the IAS / NPS to forward VPN authentication requests to our Radius program. The program performs a verification of the user id / password and returns - success / failed

The question:

We want to achieve SSO. In other words - authenticate using our own algorithm and then make an AD authentication and return the success ticket  to the VPN somehow.

How to do the above.

Samples ? Where to look for coding instructions ?

Thanx

Hi,

We have a Radius server that authenticates multiple platforms using an OTP Token. The Radius is on a Windows Server 2003. The Radius server only authenticates the user id and OTP and returns - success / failure.

We have a Forefront TMG VPN installed on a domain member Windows Server 2008 R2.

We want to authenticate the user ids using the Radius server.

We want a single sign on.

The questions:

Can we configure the Forefront to use Web Forms authentication and customize the Login Web Form to first call the Radius server for OTP authentication and if successful, complete the AD authentication ?

Is there another way to perform Single Sign on ?

I hope my question is clear...

Thanx

We apply all december security patches to some of our windows XP professional SP3 clients and now they are have local profile issues(basically profile is not loading on them) on them.    Has Microsoft gotten an similar reports on this subject.    Or what patch is causing this issue?

Thanks in advance

My question is in regards to MS Article ID 904943

Authentication may not succeed when you use PEAP-MS-CHAP-v2 as the authentication method for an 802.1X connection in Windows Vista, Windows XP, Windows Server 2003, and Windows 2000

Symtoms:

When you use Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP-v2) as the authentication method for an 802.1X connection, computer authentication may not succeed. If computer authentication is the only authentication method that is used to establish a connection, the connection may not succeed

Method 1 of the work around states:

Use both computer and user authentication. Although computer authentication does not succeed, user authentication establishes a secured connection. Therefore, the computer password is reset.

Question:

Does this pertain only to a wired computer or should this also work if the user is attempting to connect using a wireless connection?

I am dealing with this same situation now and I have found that it only works if the computer is connected with a network cable. Any information to the contrary would be greatly appreciated as there are others in my department that believe it should work wired or wireless.

Thanks,

rich

I'd like to write a security policy where the principals are executables rather than users. For example, a policy rule in this framework might specify that Internet Explorer isn't allowed to touch certain files. I've looked around a bit and come to the tentative conclusion that the only way to do this is by writing a driver. Are there any source code examples of drivers that can do this?

A few weeks ago, the Security Event log on the domain controller started filling up with events with ID 565 and 562. Here are some samples of these events:

Event Type:    Success Audit
Event Source:    Security
Event Category:    Directory Service Access
Event ID:    565
Date:        2010/10/26
Time:        11:51:22 AM
User:        MYDOMAIN\WORKSTATION2$
Computer:    DC1
Description:
Object Open:
     Object Server:    Security Account Manager
     Object Type:    SAM_SERVER
     Object Name:    CN=Server,CN=System,DC=local,DC=corporate,DC=com
     Handle ID:    1105360
     Operation ID:    {0,72326666}
     Process ID:    424
     Process Name:    C:\WINDOWS\system32\lsass.exe
     Primary User Name:    DC1$
     Primary Domain:    MYDOMAIN
     Primary Logon ID:    (0x0,0x3E7)
     Client User Name:    WORKSTATION2$
     Client Domain:    MYDOMAIN
     Client Logon ID:    (0x0,0x180F59E)
     Accesses:    READ_CONTROL
            InitializeServer
            EnumerateDomains
            Undefined Access (no effect) Bit 7
           
     Privileges:    -

     Properties:
---
    samServer

     Access Mask:    0

Event Type:    Success Audit
Event Source:    Security
Event Category:    Object Access
Event ID:    562
Date:        2010/10/26
Time:        11:51:22 AM
User:        MYDOMAIN\WORKSTATION2$
Computer:    DC1
Description:
Handle Closed:
     Object Server:    Security Account Manager
     Handle ID:    1105360
     Process ID:    424
     Image File Name:    C:\WINDOWS\system32\lsass.exe

In every one of these events, the "user" is the same workstation. The workstation is running Windows 7 Pro x64; the domain controller is running Windows Server 2003. If I take the Process ID over to the workstation, Task Manager says that the process is svchost.exe run with arguments "-k netsvcs".

The number of events appearing in the event log is very large. We are not getting events like this for other workstations, at least not in this quantity. Something must be going wrong on the workstation. What can I do to identify and fix the problem?

I learned yesterday, that my password for the "Admin" account has been changed. Apart from restricted user accounts, I have a second with administrative rights. So there's no problem accessing my machine and asigning a new password.

However, I would very much like to find out how is such a password change possible.

I hoped to find a hint to the cause if I cracked the mysterious "new" password. The method I applied (rainbow tables, 'ophcrack' ) would only work on weak passwords or under certain circumtances, but I was lucky: The password was set to a primitive "ad".

I reason that this password change can't happen accidentally; someone might have spied my old password. Not by 'Ophcrack'; that never worked on any of my passwords, and no one had physical access to my PC.

However, I implemented a VPN and Remote Desktop. I used both only once from a hotel and used the Admin user name and password for that. This log in has been the last access with my admin login data up to now and since then the password has been invalid, i.e. changed.

I used a Windows Vista Home Basic for the VPN access. On the Windows XP machine as the server, except from the user 'Admin', two more users were allowed to make a connection by VPN: A user with restricted rights, 'joe', and a user, 'VPN-Benjamin', that was only created to login via VPN, but has no user account in the XP OS.

That evening, I used the user 'Admin' and the user 'VPN-Benjamin'. These two had their passwords changed, to 'ad' and to 'ben', which I found by Ophcrack. The user 'Joe' that I did not use the evening, kept his password.

This gives some vent to the hypothesis, that my data might have been eavesdropped that evening.

The hotel provides a free network access to their guests; all share the same ISSD and the same password. I use it like any public network and set my network in Vista accordingly to 'public', so that my folders stay concealed.

I first made the connection into the internet, and then logged into the VPN. The VPN is set to 'Private' network.

If you consider the facts I gave here, do you find any hints on the reason why both passwords have changed, and to such primitive ones, too?

I'd appreciate any qualified hints. Maybe you spot a blunder I made?

Joe

I need some help understanding how the Security Center knows when an anti-virus product is out of date.  In a home situation, neither McAfee nor Symantec seem to have user editable settings for this.  In the corporate setting, using McAfee VSE with ePO I cannot find a setting for this, but I can in Symanetc Endpoint.

the point of this is we're trying to implement NAP, and the two settings for A/V in the NAP server areIs A/V installed and Is A/V up-to-date.  Research indicates that NAP checks with Security Center to find out if A/V is up to date, but where does Security Center get that setting?

What's New for Security in Windows Server 2008

Using Windows 7 and Windows Server 2008 R2: Controlling Communication with the Internet

Windows Server 2008 Security Guide

Threats and Countermeasures - Security Settings in Windows Server 2008 and Windows Vista

I have two customers in different network types with this same problem. In each case folks were sharing files between machines and suddenly last week the shares stopped working unexpectedly.

Customer 1 has a SBS2003R2 and a small number of domain members. It is highly underutilized. The domain members are of various Win OS vintages back only to XPsp3. On this system I can ping the server IP but not its name. PCs attempting to join the domain can not resolve the link http://server/connectcomputer/ and SQL applications must attach to the db using the IP in place of the server name. The server can not resolve its own name.

Customer 2 has two XPsp3 machines in the same MSHOME workgroup. Sharing worked then suddenly stopped after some event.

In both cases, the list of shared folders is visible but access is denied. Internet DNS resolution works in both systems.

Hi.

Whenever I turn on the computer, I get a pop-up labelled "                    ".exe - Bad Image, which continues to popup after a new application is opened, or just at random. It says "                    ".DLL is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. I use "    " because the name of the file always changes, and usually isn't an actual existing file. Is this malware or a virus? I've done several full system scans with Norton, and malwarebytes, but nothing seems to find any viruses or get rid of it. If anyone could please help, it would be greatly appreciated. Thanks.

Hi,

Basically how do I verify the Product Key for Windows 7 Operating System before installing ? Is there a program I can download to check the 25 key ?

Ordinarily running under limited access rights, protects the system; including virus scanners.

Weyell.... it seems the malware writers have found a loophole through which to screw with the virus scanner.

From a Windows XP limited access account, users (meaning, any program,) can modify the following file...
[i]"%allusersprofile%\application data\windows genuine advantage\data\data.dat"[/i]

Strategically modified, MSE eventually begins to think it's on a system that failed validation.

Needs to fix that ASAP !!!

Thanks...