Security issue when using forms authentication in ASP.NET
Tells Peter Vogel
Two security researchers, Thai Duong and Juliano Rizzo, discovered a bug in the default encryption mechanism involved in protecting cookies commonly used to implement Forms Authentication in ASP.NET. Using the tools developed by the researchers ( Padding Oracle Exploit Tool or POET), you can modify cookies encrypted using the AES encryption mechanism and, by examining returned errors, calculate the Machine Key used to encrypt cookies. According to the researchers, the process is 100% reliable and takes from 30 to 50 minutes for any site.
Once the machine key has been determined, the attacker can create dummy authentication cookies. And if the site developers have chosen the option of embedding information about the role of this user in cookies, then the attacker can assign himself the role of administrator. This security hole may affect other functions of the role membership provider, protection against ViewState spoofing, other encrypted data that may be stored in cookies or otherwise available on the client side.
')
The bad news is that the problem is extensive and requires an immediate solution. The good thing is that its solution is quite simple. This hack exploits a bug in the .NET encryption implementation using AES. The solution is simple - you need to switch to using another encryption mechanism - for example, 3DES. And since the encryption of membership and role providers is handled by ASP.NET, no modification of existing code using form authentication is needed.
The encryption method can be changed in the web.config file for the site, in IIS 7 for the web server, or in the .NET configuration file on the server in the% SYSTEMROOT% \ Microsoft.NET \ Framework \ version \ CONFIG \ directory. On 64-bit systems, it is also necessary to change the configuration file in the% SYSTEMROOT% \ Microsoft.NET \ Framework64 \ version \ CONFIG \ directory. A typical entry would look like this:
On the web farm, this setting should be changed on all servers in the farm.
These parameters are also used to prevent ViewState from being spoofed (ViewState data is encoded, but not encrypted). Therefore, if you make these changes, it will also lead to ViewState encryption using 3DES.
Developers who use AES to encrypt information available on the client should consider changing the code to use a different encryption mechanism.
Dong and Rizzo intend to provide more detailed information on this issue at a security conference to be held on Friday, September 17 in Buenos Aires.
Two security researchers, Thai Duong and Juliano Rizzo, discovered a bug in the default encryption mechanism involved in protecting cookies commonly used to implement Forms Authentication in ASP.NET. Using the tools developed by the researchers ( Padding Oracle Exploit Tool or POET), you can modify cookies encrypted using the AES encryption mechanism and, by examining returned errors, calculate the Machine Key used to encrypt cookies. According to the researchers, the process is 100% reliable and takes from 30 to 50 minutes for any site.
Once the machine key has been determined, the attacker can create dummy authentication cookies. And if the site developers have chosen the option of embedding information about the role of this user in cookies, then the attacker can assign himself the role of administrator. This security hole may affect other functions of the role membership provider, protection against ViewState spoofing, other encrypted data that may be stored in cookies or otherwise available on the client side.
')
The bad news is that the problem is extensive and requires an immediate solution. The good thing is that its solution is quite simple. This hack exploits a bug in the .NET encryption implementation using AES. The solution is simple - you need to switch to using another encryption mechanism - for example, 3DES. And since the encryption of membership and role providers is handled by ASP.NET, no modification of existing code using form authentication is needed.
The encryption method can be changed in the web.config file for the site, in IIS 7 for the web server, or in the .NET configuration file on the server in the% SYSTEMROOT% \ Microsoft.NET \ Framework \ version \ CONFIG \ directory. On 64-bit systems, it is also necessary to change the configuration file in the% SYSTEMROOT% \ Microsoft.NET \ Framework64 \ version \ CONFIG \ directory. A typical entry would look like this:
<machineKey validationKey="AutoGenerate,IsolateApps"
validation="3DES"
decryptionKey="AutoGenerate,IsolateApps"
decryption="3DES" />On the web farm, this setting should be changed on all servers in the farm.
These parameters are also used to prevent ViewState from being spoofed (ViewState data is encoded, but not encrypted). Therefore, if you make these changes, it will also lead to ViewState encryption using 3DES.
Developers who use AES to encrypt information available on the client should consider changing the code to use a different encryption mechanism.
Dong and Rizzo intend to provide more detailed information on this issue at a security conference to be held on Friday, September 17 in Buenos Aires.
Source: https://habr.com/ru/post/104258/
All Articles