The below post shows the exception event that shows signs of the attack in progress. Also, found some Dynamic IP Restriction module for IIS 7 that can be used to block this attack.
Exception event that this attack would triger:
What would an attack look like on the network or in my logs?
The publicly disclosed exploit would cause the web server to generate thousands (or more likely tens of thousands) of HTTP 500 and 404 error responses to requests from a malicious client.
We can use stateful filters in the firewall, application or network, or intrusion detection systems on the network to detect such patterns and block such clients. The Dynamic IP Restrictions module supported by IIS 7 can also be used to block these types of attacks.
An attack attempt like this should also generate thousands of 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: 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.
Note that there are non-attack reasons to see this error as well (including cases where you have mismatched keys on a web-farm, or a search engine is following links incorrectly, etc), so its presence does not always necessarily indicate an attack, however, we can take preventive measures.
The exception also does not mean that an attack was successful. Implementing the <customErrors> workaround we have provided can protect your application from the public exploit, and ensure that these exceptions do not disclose information that an attacker can use against the application.
Complete description of why we should follow this workaround:
Well, while the workaround contains a really valuable information, relevant for every system (as for not disclosing the real error), and it will prevent the automated tool released by the researchers to hack your system, it will, by far, NOT protect you from a potential attack!
How so? The workaround assumes that the potential attacker will look for an HTTP error response status (500), or for an error page containing a specific exception message. However, it is enough for attacker to recognize an abnormal, or just different system behavior on certain requests.
Let’s get back to our ASP.NET system that stores an encrypted sensitive information in a cookie. Each request, the system will probably decrypt this information and use it. In case the ciphertext in a cookie is invalid, an exception will be thrown, and the system may act according to one of the following scenarios:
· Return a 500 error response - very user unfriendly!
· Return a default ASP.NET YSOD exception page - extremely bad in production environment!
· Return a page stating only the exception’s message - also very bad!
· Return a constant page, stating there was an error, without providing details– a good practice, this is actually the Microsoft’s workaround
· “Swallow” the exception, and behave like the cookie does not exist. The response may be a redirect to another pager, or just a a slightly changed HTML (instead of user’s name, a “login” link) – This is the way ASP.NET Forms Authentication works.
Note that every one of the possible responses is different from the normal one. Even the last scenario described above, as clean as it is, still returns a distinctively different response. Therefore, an attacker can take advantage of it, and write a simple script that infers this abnormal behavior to an Invalid Oracle’s answer. It is that simple!
Some useful links related to this attack:
Dynamic IP Restriction: http://www.iis.net/download/DynamicIPRestrictions
URLScan - IIS 6.0 and lesser: http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx
RequestFiltering - IIS 7.0 and above: http://www.iis.net/ConfigReference/system.webServer/security/requestFiltering
Sharepoint Workaround: http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx
