This week, Xbox LIVE issued a Service Alert warning that you might receive phishing messages if you play the Xbox game Modern Warfare 2. If you receive a matchmaking message that seems suspicious, ignore it.

Microsoft is aware of the problem and is working to resolve the issue. For the most current information, see Xbox LIVE Status.

To help protect yourself from phishing and fraud, see Email and web scams: How to help protect yourself.

A vulnerability is a weakness that enables a cybercriminal to attack computer hardware, software, or services. Companies or individuals sometimes find vulnerabilities in the software of other companies, and there are different ideas about what to do with that information. Some companies disclose it publicly, possibly with the idea of pressuring the owner to fix it quickly. However, this also exposes vulnerabilities to cybercriminals.

Last summer Microsoft announced that we would be working directly with researchers and vendors to minimize the security risks for customers through a process called Coordinated Vulnerability Disclosure (CVD). Last week we announced an update to this process.

Here’s a simple description of how CVD works:

Finders disclose newly discovered vulnerabilities in hardware, software, and services directly to the vendors of the affected product or to a coordinator who will report to the vendor privately. The finder then allows the vendor time to diagnose and offer fully tested updates, workarounds, or other corrective measures before the finder discloses detailed vulnerability or exploit information to the public.

The vendor continues to coordinate with the finder throughout the vulnerability investigation and provides the finder with updates on case progress. Upon release of an update, the vendor may recognize the finder in bulletins or advisories for finding and privately reporting the issue.

For a more detailed description, see Microsoft Security Response Center: Coordinated Vulnerability Disclosure or watch a video about how CVD works at TechNet Edge.

Hi all,

I wanted to point Forefront Protection 2010 for SharePoint (FPSP) customers to a TechNet Wiki article that was recently written. The purpose of this article is to provide performance data that shows FPSP’s enhanced performance over the previous version of the product, Forefront Security for SharePoint (FSSP). It also describes the overall system performance overhead in adding FPSP to your SharePoint environment, and provides configuration options for further improving system performance if you so desire.

 Forefront Protection 2010 for SharePoint Performance Data
 
Thanks for reading.
 
Scott Floman
Forefront for Office UA

Hi all,

I wanted to point Forefront Protection 2010 for SharePoint (FPSP) customers to a TechNet Wiki article that was recently written. The purpose of this article is to provide performance data that shows FPSP’s enhanced performance over the previous version of the product, Forefront Security for SharePoint (FSSP). It also describes the overall system performance overhead in adding FPSP to your SharePoint environment, and provides configuration options for further improving system performance if you so desire.

 Forefront Protection 2010 for SharePoint Performance Data
 
Thanks for reading.
 
Scott Floman
Forefront for Office UA

Hi all,

I wanted to point Forefront Protection 2010 for SharePoint (FPSP) customers to a TechNet Wiki article that was recently written. The purpose of this article is to provide performance data that shows FPSP’s enhanced performance over the previous version of the product, Forefront Security for SharePoint (FSSP). It also describes the overall system performance overhead in adding FPSP to your SharePoint environment, and provides configuration options for further improving system performance if you so desire.

 Forefront Protection 2010 for SharePoint Performance Data
 
Thanks for reading.
 
Scott Floman
Forefront for Office UA

Hi all,

I wanted to point Forefront Protection 2010 for SharePoint (FPSP) customers to a TechNet Wiki article that was recently written. The purpose of this article is to provide performance data that shows FPSP’s enhanced performance over the previous version of the product, Forefront Security for SharePoint (FSSP). It also describes the overall system performance overhead in adding FPSP to your SharePoint environment, and provides configuration options for further improving system performance if you so desire.

 Forefront Protection 2010 for SharePoint Performance Data
 
Thanks for reading.
 
Scott Floman
Forefront for Office UA

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

• 4720 – user account creation
• 4738 – user account change
• 4741 – computer account creation
• 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

• PASSWD_NOTREQD 0x0020
• LOCKOUT 0x0010
• HOMEDIR_REQUIRED 0x0008
• (undeclared) 0x0004
• ACCOUNTDISABLE  0x0002
• SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

• 4720 – user account creation
• 4738 – user account change
• 4741 – computer account creation
• 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

• PASSWD_NOTREQD 0x0020
• LOCKOUT 0x0010
• HOMEDIR_REQUIRED 0x0008
• (undeclared) 0x0004
• ACCOUNTDISABLE  0x0002
• SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

• 4720 – user account creation
• 4738 – user account change
• 4741 – computer account creation
• 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

• PASSWD_NOTREQD 0x0020
• LOCKOUT 0x0010
• HOMEDIR_REQUIRED 0x0008
• (undeclared) 0x0004
• ACCOUNTDISABLE  0x0002
• SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

Hi all,

I wanted to point Forefront Protection 2010 for SharePoint (FPSP) customers to a TechNet Wiki article that was recently written. The purpose of this article is to provide performance data that shows FPSP’s enhanced performance over the previous version of the product, Forefront Security for SharePoint (FSSP). It also describes the overall system performance overhead in adding FPSP to your SharePoint environment, and provides configuration options for further improving system performance if you so desire.

 Forefront Protection 2010 for SharePoint Performance Data
 
Thanks for reading.
 
Scott Floman
Forefront for Office UA

In Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, there are four events that contain a user account control (UAC) flags value:

• 4720 – user account creation
• 4738 – user account change
• 4741 – computer account creation
• 4742 – computer account change

This value is a bitmask value, and it’s represented in textual format as a hexadecimal value, e.g. 0x1234.

The “decoder key” for this value is in Knowledge Base article 305144.  If you’re a developer type, the actual declaration is in IADS.H in the Windows SDK.

Ned points out that the article is missing an entry:

0x04000000 – PARTIAL_SECRETS_ACCOUNT  (i.e. “Read-Only Domain Controller”)

I also want to point out that Windows will set the undeclared value 0x4.  I don’t know what this value does, if anything.

To decode this value, you can go through the property value definitions in the KB article from largest to smallest.  Compare each property value to the flags value in the event.  If the flags value in the event is greater than or equal to the property value, then the property is “set” and applies to that event.  Subtract the property value from the flags value in the event and note that the flag applies and then go on to the next flag.  Here’s an example:

Flags value from event: 0x15

Decoding:

• PASSWD_NOTREQD 0x0020
• LOCKOUT 0x0010
• HOMEDIR_REQUIRED 0x0008
• (undeclared) 0x0004
• ACCOUNTDISABLE  0x0002
• SCRIPT 0x0001

0x0020 > 0x15, so PASSWD_NOTREQD does not apply to this event

0x10 < 0x15, so LOCKOUT applies to this event.   0x15 – 0x10 = 0x5

0x4 < 0x5, so the undeclared value is set.  We’ll pretend it doesn’t mean anything.   0x5 – 0x4 = 0x1

0x2 > 0x1, so ACCOUNTDISABLE does not apply to this event

0x1 = 0x1, so SCRIPT applies to this event.  0x1 – 0x1 = 0x0, we’re done.

So this UAC flags value decodes to: LOCKOUT and SCRIPT.

Severity Rating: Important – Revision Note: V1.1 (April 28, 2011): Added a link to Microsoft Knowledge Base Article 2478960 under Known Issues in the Executive Summary.Summary: This security update resolves a privately reported vulnerability in the Local Security Authority Subsystem Service (LSASS) in Windows XP and Windows Server 2003. This security update is rated Important for all supported editions of these operating systems. For more information, see the subsection, Affected and Non-Affected Software, in this section. The vulnerability could allow elevation of privilege if an attacker logs on to a system and runs a specially crafted application. An attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely or by anonymous users.

Our friends over at the FutureFed blog reported that Windows 7 the has passed  the Common Criteria (CC) certification process and achieved Evaluation Assurance Level 4 with augmentation (EAL4+). Common Criteria certification is an international standard recognized by 26 member nations including the United States and is a procurement requirement for U.S. Defense and national security customers.

With this certification, we are excited that our federal customers as well as foreign governments can feel secure in deploying Windows 7, having successfully passed the rigorous security testing protocols set forth by the National Information Assurance Partnership.

Several governments have already successfully deployed Windows 7, including the Moscow North District Prefecture in Russia, the Vernon Hills Police Department in Chicago, Illinois, the City of Miami, Florida and the City of Stockholm, Sweden.

This is exciting news, but not surprising as Windows 7 is our most secure operating system to date. In addition to enhancing existing security features in Windows, we incorporated customer feedback throughout the development process of Windows 7 to deliver innovative new security features, including Direct Access, AppLocker and BitLocker To Go.

Congratulations, Windows 7!

Our friends over at the FutureFed blog reported that Windows 7 the has passed  the Common Criteria (CC) certification process and achieved Evaluation Assurance Level 4 with augmentation (EAL4+). Common Criteria certification is an international standard recognized by 26 member nations including the United States and is a procurement requirement for U.S. Defense and national security customers.

With this certification, we are excited that our federal customers as well as foreign governments can feel secure in deploying Windows 7, having successfully passed the rigorous security testing protocols set forth by the National Information Assurance Partnership.

Several governments have already successfully deployed Windows 7, including the Moscow North District Prefecture in Russia, the Vernon Hills Police Department in Chicago, Illinois, the City of Miami, Florida and the City of Stockholm, Sweden.

This is exciting news, but not surprising as Windows 7 is our most secure operating system to date. In addition to enhancing existing security features in Windows, we incorporated customer feedback throughout the development process of Windows 7 to deliver innovative new security features, including Direct Access, AppLocker and BitLocker To Go.

Congratulations, Windows 7!

Our friends over at the FutureFed blog reported that Windows 7 the has passed  the Common Criteria (CC) certification process and achieved Evaluation Assurance Level 4 with augmentation (EAL4+). Common Criteria certification is an international standard recognized by 26 member nations including the United States and is a procurement requirement for U.S. Defense and national security customers.

With this certification, we are excited that our federal customers as well as foreign governments can feel secure in deploying Windows 7, having successfully passed the rigorous security testing protocols set forth by the National Information Assurance Partnership.

Several governments have already successfully deployed Windows 7, including the Moscow North District Prefecture in Russia, the Vernon Hills Police Department in Chicago, Illinois, the City of Miami, Florida and the City of Stockholm, Sweden.

This is exciting news, but not surprising as Windows 7 is our most secure operating system to date. In addition to enhancing existing security features in Windows, we incorporated customer feedback throughout the development process of Windows 7 to deliver innovative new security features, including Direct Access, AppLocker and BitLocker To Go.

Congratulations, Windows 7!

These days almost everything online requires a password. You already know that you should use complicated passwords and that you shouldn’t use the same password for every account. Here are more tips on how to create stronger passwords and how to test your password strength.

If you want to know why it’s so important to create different strong passwords for all of your accounts (and to change them often), see How I’d hack your passwords by MSN Money blogger, John Pozadzides.

Severity Rating: Critical – Revision Note: V1.1 (April 27, 2011): Corrected the bulletin replacement information for all supported editions of Windows Vista and Windows Server 2008.Summary: This security update resolves a privately reported vulnerability in Microsoft Windows. The vulnerability could allow remote code execution if an attacker created a specially crafted SMB packet and sent the packet to an affected system. Firewall best practices and standard default firewall configurations can help protect networks from attacks originating outside the enterprise perimeter that would attempt to exploit these vulnerabilities.

Severity Rating: Important – Revision Note: V1.2 (April 27, 2011): Corrected the severity table and vulnerability section to add CVE-2010-4701 as a vulnerability addressed by this update. This is an informational change only.Summary: This security update resolves two publicly disclosed vulnerabilities in Microsoft Windows. The vulnerabilities could allow remote code execution if a user opened a specially crafted fax cover page file (.cov) using the Windows Fax Cover Page Editor. An attacker who successfully exploited either of these vulnerabilities could gain the same user rights as the logged-on user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

Introduction

Recently we’ve encountered a number of cases where customers wanted to use TMG to require strong authentication for some parts of a published web site (e.g. Outlook Web Access, OWA) but not for others (e.g. Exchange Active Sync, EAS).

This post will describe how to configure TMG for similar scenarios.

Background

The TMG authentication process, as described here, has three phases:

• Receipt of client credentials.
• Validation of client credentials against an authentication provider such as Active Directory, RADIUS, or SecurID Authentication Manager.
• Delegation of authentication to Web servers that are behind TMG Server, such as Exchange.

The first two phases are configured on the TMG Web listener while the third is configured on the specific publishing rules.

This fact can be used to use the same Web listener for different publishing rules with different authentication requirements.

Example

In the following example we will show how to publish two different internal Web sites on the same IP address and port (i.e. the same Web listener). One site will require authentication and the other will not. The technique used in this example can also be used for different paths instead of different sites.

Configuring the Web listener

The “trick” is that only for some rules the Web listener will require authentication. This means that even though authentication is configured on the Web listener, it will not require users to authenticate if they are using a path or site associated with an “All users” rule (as “All users”, including non-authenticated users, are allowed). Here is an example of the Web listener configuration:

Configuring the Web publishing rules

Next we configure a Web publishing rule for the sites or paths that do not require authentication. We use the Web listener defined above and set the rule’s “Users” tab to apply to “All Users”:

Then we configure a Web publishing rule for the sites or paths that require authentication. We use the same Web listener as in the above rule, but here we set the rule’s “Users” tab to apply to “All Authenticated Users”:

We end up with two rules on the same listener (and the same IP address/port), one requiring authentication while the other doesn’t:

If a request matches the first, “No auth” rule, it will be allowed through without being prompted for authentication. However, if the request is matched to the second, “Auth” rule, it will be prompted for authentication and will only be allowed through if the authentication succeeds.

Authors:

Roman Golubchyck,  Senior Development Engineer.

Ori Yosefi, Senior Program Manager.

In continuation of our support for the takedown activities on the Win32/Afcore botnet, we are releasing a second edition of MSRT in April. This edition includes variants of Afcore released by the criminals behind it at approximately the same time as the previous edition of MSRT. While MSRT has traditionally been released on the second Tuesday of the month alongside other security releases, we are not tied to this schedule. We can, and will, release MSRT as needed to support takedown activities or other times when the impact will be potentially significant. This additional release is on request and we welcome other requests in the future.

This release also includes some additional enhancements to the MSRT engine for other malware families, which have also been incorporated into definitions for Microsoft Security Essentials and the Forefront products since the last MSRT release.

– Jeff Williams, Principal Group Program Manager, MMPC