On September 17, Microsoft released Microsoft Security Advisory (2416728), “Vulnerability in ASP.NET Could Allow Information Disclosure.” As stated in the advisory, Microsoft is investigating a new public report of a vulnerability in ASP.NET. Additional information about the issue can also be found in Understanding the ASP.NET Vulnerability on the Microsoft Security Research and Defense blog, and in the following blog posts by Microsoft .NET Developer Platform Vice President Scott Guthrie:

All Microsoft Exchange versions starting with Exchange 2003 use ASP.NET in a manner where potential for this vulnerability exists. However, if you have implemented a default configuration within your environment there are only a handful of files which may contain sensitive data that could be potentially accessed. In addition this sensitive data is only useable if the attacker has managed to penetrate the additional defense layers built into Exchange.

How to detect an attack on Exchange

An attack attempt against Exchange Server should generate warnings in the application event log of your server similar to:

Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 11/11/1111 11:11:11 AM
Event time (UTC): 11/11/1111 11:11:11 AM
Event ID: 1309
Event sequence: 133482
Event occurrence: 44273
Event detail code: 0
Application information:
Application domain: c1db5830-1-129291000036654651
Trust level: Full
Application Virtual Path: /
Application Path: C:\foo\TargetWebApplication\
Machine name: FOO
Process information:
Process ID: 3784
Process name: WebDev.WebServer40.exe
Account name: foo
Exception information:
Exception type: CryptographicException
Exception message: Padding is invalid and cannot be removed.

We strongly recommend customers monitor their Application logs for instances of this event and investigate them if seen. These event logs would contain an Event Occurrence field that provides a counter of the number of exceptions triggered.

Note: You may also see this warning event logged due to other reasons (including cases for example where you have mismatched keys on a web-farm, or a search engine is following links incorrectly, etc), so its presence does not necessarily indicate an attack of this nature.

The presence of this ‘Event Occurrence’ also does not indicate that an attack was successful.

If the event is detected and you believe it is the ASP.NET attack, it is possible to use stateful filters in your firewall or intrusion detection systems on your network to detect patterns and block malicious clients.

As indicated in the advisory, Microsoft is currently working to develop a security update to address this vulnerability with details of any fix released in the future being reposted on this blog and the Microsoft Security Advisory (2416728) page.

Microsoft will release the security update once it has reached an appropriate level of quality for broad distribution. We will post again to inform Exchange customers once this security update has been released to resolve the ASP.Net issue. We do not have an ETA for this fix being available at the time of writing.

Kevin Bellinger

Not applicable
Thanks for the update Kevin. Is the workaround mentioned in "Microsoft Security Advisory (2416728)" not required on Exchange servers?
Not applicable
What are the additional defenses in Exchange that make it difficult to use the sensitive data in the case of a successful exploit?

In a case with Exchange 2003 (Server 2003) behind an Exchange 2007 CA (Server 2008), do I need the workaround on both servers to prevent external attacks?
Not applicable
Thanks for the info.  I'd also like to know if the workaround in the published advisory is something that should be considered for Exchange?  Or is changing the behavior of error pages something that could impact CAS function?
Not applicable
I found this article that indicates the required steps in Exchange 2007. Can someone confirm these are the correct steps?

1. Rename C:Program FilesMicrosoftExchange ServerClientAccessowaautherror.aspx

to   error.bak.aspx

2. Paste contents of error2.aspx as listed here


into a new version of C:Program FilesMicrosoftExchange ServerClientAccessowaautherror.aspx

3. Add a new web.config (probably doesn't exist) at your website root.  In our case:

C:Program FilesMicrosoftExchange ServerClientAccessweb.config


view plaincopy to clipboardprint?

01.<?xml version="1.0" encoding="UTF-8" standalone="yes"?>  


03.  <system.web>  

04.    <customErrors mode="On" defaultRedirect="/owa/auth/error.aspx" />  

05.  </system.web>  


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>



   <customErrors mode="On" defaultRedirect="/owa/auth/error.aspx" />



This will then be used by other child virtual directories that don't override the customErrors element.

4. Optional:  our /ews/web.config had an overriding customErrors that redirected to a (non-existent) GenericErrorPage.htm.


Not applicable
Does this also impact Team Foundation Server 2008 and or Project Server 2007?  Both of which use Windows SharePoint Services 3.0…. If so is the temporary fix the same?