Over the past couple of days we’ve received some additional questions regarding the ASP.NET vulnerability. In this post we will answer some of the most common ones.
Is My ASP.NET Site Affected By This Issue?
Yes, all sites that use ASP.NET are affected by this vulnerability. You should follow the recommendations outlined in the advisory. The advisory includes a workaround that can help harden a server against attack. In our previous blog post we provided a script that can help you identify ASP.NET sites that could benefit from this hardening.
Has My Site Been Attacked?
The publicly disclosed exploit would cause the web server to generate thousands (or tens of thousands) of HTTP 500 and 404 error responses to requests from a malicious client. You can use stateful filters in your firewall or intrusion detection systems on your network to detect such patterns and block potential attackers. The Dynamic IP Restrictions module supported by IIS 7 can also be used to block these types of attacks.
Additionally, if your site has been attacked, you should see warnings in the application event log 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: 28e71767f3484d1faa90026f0947e945
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.
The highlighted exception detail is the most important piece of information in the event log entry to look for. It is possible to hit this error while developing new ASP.NET website code, and it can happen in certain production environments. However, if it did not appear on your production servers until recently, it is possible that it indicates an attack. Verifying that the time of these exceptions corresponds to the large number of requests described above would increase the confidence that this entry was caused by an attack.
-Kevin Brown, MSRC Engineering