As I mentioned in my last post, I have a solution in the works to prevent the Padding Oracle exploit from working against the FormsAuthentication tickets & cookies. The workaround adds a handful of security-related features that might be interesting to you. I plan to expand on it to add other modules relating to web security.
The EnhancedSecurityModule adds server-side state to ASP.NET's FormsAuthentication subsystem. This drop-in module works with most ASP.NET applications, breaks the Padding Oracle exploit, and paves the way for new features such as kicking, banning, and restricting users to a single IP. Check it out:
http://sws.codeplex.com/
For a high-level understanding of how it works, check out the project page.
How the EnhancedSecurityModule Works
The EnhancedSecurityModule attaches to the BeginRequest, EndRequest, and Error events of each request. The FormsAuthenticationModule does it’s job somewhere in the middle during the AuthenticateRequest event. My module compares the state of the request before FormsAuthentication kicks in to the state of the request just before the response is sent to the user. If it detects that a FormsAuthenticationCookie was issued in between those two points, the current request must have been the postback of the login form (or execution of the Login action) that resulted in a successful login. It intercepts the FormsAuthenticationCookie and FormsAuthenticationTicket on their way out to the user and records all information about both (along with the IP address of the client) in a record on the server. It assigns a randomly generated GUID to the record & computes a salted SHA-512 hash of the FormsAuthenticationTicket’s properties, concatenates them and stuffs them in the UserData field in the FormsAuthenticationTicket. It rebuilds the FormsAuthenticationCookie and replaces the outbound cookie with the new one.
At the beginning of each subsequent request, the StatefulFormsAuthenticationModule attempts to extract the FormsAuthenticationTicket from the FormsAuthenticationCookie. If it finds one, it attempts to parse the UserData field, separating the SHA-512 hash from the GUID used as a key to the server-side store of information about the cookie and ticket. If the hash matches, it attempts to retrieve all of the information about the cookie and ticket that the server knew to be factual when it issued them from the server-side store. If it finds the information, it cross-validates just about every property in the FormsAuthenticationCookie, FormsAuthenticationTicket, and even the current request state (IP address) against the information stored on the server. If everything matches, the module allows the FormsAuthenticationCookie to continue to exist. The FormsAuthenticationModule's AuthenticateRequest event handler kicks in and establishes the identity for the request, the authorization subsystem operates on the assumption the identity is correct, and all is right with the world.
If anything breaks down in the validation process, the server attempts to destroy the FormsAuthenticationCookie on the client’s browser, removes the cookie from the Request’s Cookies collection, and forces the request to run anonymously. Even if the client maliciously refuses to destroy the cookie, it is removed from the processing pipeline at the beginning of each and every request.
Additionally, there are some posts out there claiming that users can download web.config via a padding oracle attack on WebResource.axd. The module looks for CryptographicExceptions on requests dealing with .axd files, introduces a random, configurable delay, and returns an HTTP 200 response telling the attacker to go away.
I’m still doing analysis on the exploit tools that I’ve seen and will try to adapt the module to stand in the way of any attack vectors I’ve found. If I’ve missed a spot, please let me know and/or submit patches.
About the Project
The StatefulFormsAuthenticationModule project is a derivative work of another FormsAuthentication-related project that I’ve been working on for the past few years, the .NET client for JA-SIG’s CAS authentication system (http://www.jasig.org/cas). I’ve been hacking away at FormsAuthentication since 2008.
When I first read about the Padding Oracle exploit, I began analyzing the DotNetCasClient code and realized that one of the features I added to it theoretically eliminated the FormsAuthenticationTicket attack vector (the ServiceTicketManager). Given the potential widespread impact of the problem, I decided to strip that aspect of the code away from the CAS module and create a free-standing module that protects FormsAuthentication users regardless of whether they are using CAS. If you happen to be looking for a rock solid, cross-platform Single Sign-On solution, check it out.