ASP.Net Forms Authentication Bypass

January 5, 2012 by · Comments Off on ASP.Net Forms Authentication Bypass
Filed under: Security 

It was recently announced that there is a vulnerability in ASP.Net Forms Authentication.  The vulnerability allows an attacker to assume the identity of another user within the application without the need to know the victim’s password.  This is a critical vulnerability as it could allow users to execute commands they do not have access to.   There are a few requirements that are needed for an application to be vulnerable:

  • The application must be using Forms Authentication to perform the authentication of each user.
  • The application must allow the user to control their user name.
  • The attacker must know, or be able to guess, the username of an existing user.

This vulnerability allows an attacker to impersonate another valid user in the system by tricking the system into creating the forms authentication ticket for the wrong user. Here is how the attack would work:

1. The attacker knows the user name of a valid user of the application.

2. The attacker registers a new account on the application using a specially crafted user name, which contains null bytes, to access the system.  An example would be a user name of: victimid%00Attackerid. 

3. The attacker’s username is accepted (unless custom input validation has been implemented) and stored in the database as “victimid%00Attackerid”.

4. The attacker logs into the application with his malicious user name “victimid%00AttackerId” and his password. 

  1. The full username “victimid%00Attackerid” is verified against the database, along with the password, and is successful.
  2. The ASP.Net engine passes the user name to an unmanaged DLL (yeah, remember the null byte) which is used to create the Forms Authentication Token.
  3. The unmanaged DLL reads in the user name “victimid%00Attackerid”, but because it uses null bytes to terminate strings, it stops reading the user name at the null byte.  This leaves a user name of “victimid”.
  4. The user name of “victimid” is used to create the authentication token used by forms authentication. 

5. The attacker know has an authentication ticket for the victim and is recognized as the victim. If the victim has admin rights, it is possible that the attacker may have them now as well. This may depend on how authorization is performed within the system.

The patch that was released resolves this issue by changing how the Forms Authentication ticket is created. It still uses the user name, but some changes were implemented to help block this issue. It is important to note that the new forms ticket is not compatible with the ticket created before the patch. This means that if there are any valid tickets out there when the patch is applied, they will be expired and the user will have to re-login to the application to get a new ticket. If you are running a web farm, all of the machines in the farm will need to be patched or none of them. This is due to that incompatibility in the ticket.

Note that the workaround regarding the ticketCompatibilityMode for the authentication bypass won’t be needed after the patch as that property appears to be going away. You are encouraged to visit the link below to view more information and make sure you apply the patch. This should come down with automatic updates, although I updated mine manually.

For more information you can read Microsoft’s Security Bulletin here: http://technet.microsoft.com/en-us/security/bulletin/ms11-100.

The information provided in this post is provided as-is and is for educational purposes only. It is imperative that developers understand the vulnerabilities that exist within the frameworks/platforms that they work with. Although there is not much you can really do when the vulnerability is found within the framework, understanding the possible workarounds and the risks associate with them help determine proper remediation efforts.

Tags: