El rincón de JMACOE

Dos investigadores de seguridad, tailandeses Duong y Juliano Rizzo, han descubierto un error en el mecanismo predeterminado de cifrado que se utiliza normalmente para proteger las cookies se generan al implementar la autenticación por formularios en el de ASP.NET. El uso de su herramienta (el Padding Oracle Exploit tool o POET), puede repetidamente modificar una cookie de autenticación de los formularios ASP.NET cifrados con AES y, mediante el examen de los errores devueltos, determinar la Machine Key utilizada para cifrar la cookie. El proceso se afirma que es 100 por ciento confiable y dura entre 30 y 50 minutos para cualquier sitio.

Una vez que la Machine Key está determinada, los atacantes pueden crear falsas las cookies de autenticación por formularios. Si los diseñadores de sitios han optado por la opción de integrar información de las roles en la cookie de seguridad, entonces, los atacantes arbitrariamente podían asignarse roles de administrador. Esta exposición también afecta a otras funciones de proveedor membership, suplantación de protección en el ViewState, y la información cifrada que puede ser almacenada en las cookies o de lo contrario se pondrá a disposición del cliente.

Mientras que la exposición es amplia e inmediata, la solución es simple. El hack explota un error en la implementación .NET de la encriptación AES. La solución es cambiar a otro de los mecanismos de cifrado – para 3DES, por ejemplo. Dado que el cifrado para la composición y funciones de los proveedores está a cargo de ASP.NET, ninguna modificación de código existente es necesaria para la autenticación por formularios.

El método de cifrado se puede establecer en el archivo web.config para un sitio, en IIS 7 para un servidor Web, o en el archivo de configuración para .NET en un servidor %SYSTEMROOT%\Microsoft.NET\Framework\version\CONFIG\. Para sistemas de 64-bit, también se debe establecer en %SYSTEMROOT%\Microsoft.NET\Framework64\version\CONFIG\. Una entrada típica se vería así:

<machineKey validationKey="AutoGenerate,IsolateApps"
   validation="3DES"
   decryptionKey="AutoGenerate,IsolateApps"
   decryption="3DES" />

En una granja de servidores Web, este ajuste tiene que hacerse en todos los servidores de la granja.

Estos ajustes también se utilizan para evitar la suplantación (los datos ViewState se codifican pero no se cifran), así que al hacer este cambio también se cambiará el ViewState a usar 3DES. Los desarrolladores que estén usando un algoritmo AES en su código para cifrar la información disponible en el cliente deberían considerar la modificación de su código para utilizar un mecanismo de cifrado diferente.

Duong y Rizzo intentaran proporcionar más información en la Conferencia de Seguridad ekoparty el viernes, 17 de septiembre en Buenos Aires.