AppSec Blog

AppSec Blog

ASP.Net Forms Authentication Bypass

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:

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.


Posted January 23, 2012 at 3:37 PM | Permalink | Reply


thanks for your post but the membership provider doesn't allow user names with % signs.

Posted February 20, 2012 at 4:01 PM | Permalink | Reply


Forms authentication can be done without using the Membership Provider. In fact a lot of places already had a forms authentication system implemented before Microsoft came out with the membership provider (I know, I have written 3 of them at different employers.)

I think this is also part of the reason that Microsoft released the providers in version 2.0 of the .Net framework, they saw a lot of different implementations (and probably a lot of really scary implementations) and realized they could simplify what a lot of companies had to go through.

(yes, I am that old)

Posted February 20, 2012 at 8:20 PM | Permalink | Reply

James Jardine

Thanks for the response. In this example, although there is a % symbol in the user name, in combination with the 2 0's represents the null byte character. The string "victim[percent]00Attacker" must be manipulated outside of the text field, through a proxy. This is because the browser will encode the % sign automatically. Once you are in TamperData, or a proxy like Burp, you can set the string as shown and submit the request. This will then be stored in the database.

If you just view the database it will look like there are two users with the same user name. However, if you edit the table (assuming you are using SQL Server Management Studio) then you will notice a little box in place of the [percent]00 which indicates the null byte.

Post a Comment


* Indicates a required field.