¿Qué tan grave es esta nueva vulnerabilidad de seguridad ASP.NET y cómo puedo solucionarlo?

Acabo de leer en la red sobre una vulnerabilidad de seguridad recientemente descubierta en ASP.NET. Puede leer los detalles aquí.

El problema radica en la forma en que ASP.NET implementa el algoritmo de cifrado AES para proteger la integridad de las cookies que generan estas aplicaciones para almacenar información durante las sesiones de los usuarios.

Esto es un poco vago, pero aquí hay una parte más aterradora:

La primera etapa del ataque requiere unos pocos miles de solicitudes, pero una vez que tiene éxito y el atacante obtiene las claves secretas, es totalmente sigiloso. El conocimiento criptográfico requerido es muy básico.

En general, no estoy lo suficientemente familiarizado con el tema de seguridad / criptografía para saber si esto es realmente tan grave.

Entonces, ¿deberían todos los desarrolladores de ASP.NET temer esta técnica que puede poseer cualquier sitio web de ASP.NET en segundos o qué?

¿Cómo afecta este problema al desarrollador ASP.NET promedio? ¿Nos afecta en absoluto? En la vida real, ¿cuáles son las consecuencias de esta vulnerabilidad? Y, finalmente: ¿hay alguna solución que evite esta vulnerabilidad?

¡Gracias por tus respuestas!

EDITAR: Déjame resumir las respuestas que recibí

Entonces, esto es básicamente un tipo de ataque de "oráculo de relleno". @Sri proporcionó una gran explicación sobre lo que significa este tipo de ataque. ¡Aquí hay un video impactante sobre el tema!

Sobre la gravedad de esta vulnerabilidad: Sí, de hecho es grave. Permite al atacante conocer la clave de máquina de una aplicación. Por lo tanto, puede hacer algunas cosas muy no deseadas.

• En posesión de la clave de máquina de la aplicación, el atacante puede descifrar las cookies de autenticación.
• Incluso peor que eso, puede generar cookies de autenticación con el nombre de cualquier usuario. Por lo tanto, puede aparecer como cualquiera en el sitio. La aplicación no puede diferenciar entre usted o el hacker que generó una cookie de autenticación con su nombre.
• También le permite descifrar (y también generar) cookies de sesión , aunque esto no es tan peligroso como el anterior.
• No es tan grave: puede descifrar el ViewState cifrado de páginas. (Si usa ViewState para almacenar datos confidenciales, ¡no debe hacer esto de todos modos!)
• Muy inesperado : con el conocimiento de la clave de la máquina, el atacante puede descargar cualquier archivo arbitrario de su aplicación web, ¡incluso aquellos que normalmente no se pueden descargar! (Incluyendo Web.Config , etc.)

Aquí hay un montón de buenas prácticas que obtuve que no resuelven el problema pero ayudan a mejorar la seguridad general de una aplicación web.

• Puede cifrar datos confidenciales con la configuración protegida
• Usar cookies solo de HTTP
• Prevenir ataques DoS

Ahora, centrémonos en este tema.

• Scott Guthrie publicó una entrada al respecto en su blog
• Publicación de blog de preguntas frecuentes de ScottGu sobre la vulnerabilidad
• La actualización de ScottGu sobre la vulnerabilidad
• Microsoft tiene un aviso de seguridad al respecto
• Comprender la vulnerabilidad
• Información adicional sobre la vulnerabilidad.

La solución

• Habilite customErrors y cree una página de error única a la que se redirigen todos los errores . Sí, incluso 404 . (ScottGu dijo que diferenciar entre 404 y 500 es esencial para este ataque). Además, ingrese Application_Erroro Error.aspxcoloque algún código que haga un retraso aleatorio. (Genere un número aleatorio y use Thread.Sleep para dormir durante tanto tiempo). Esto hará que sea imposible para el atacante decidir qué sucedió exactamente en su servidor.
• Algunas personas recomendaron volver a 3DES. En teoría, si no usa AES, no encontrará la debilidad de seguridad en la implementación de AES. Como resultado, esto no se recomienda en absoluto .

Algunos otros pensamientos

• Parece que no todos piensan que la solución es lo suficientemente buena.

Gracias a todos los que respondieron mi pregunta. Aprendí mucho no solo sobre este problema, sino también sobre la seguridad web en general. Marqué la respuesta de @ Mikael como aceptada, pero las otras respuestas también son muy útiles.

¿Qué debo hacer para protegerme?

[Actualización 2010-09-29]

Boletín de seguridad de Microsoft

Artículo de KB con referencia a la solución

ScottGu tiene enlaces para las descargas

[Actualización 2010-09-25]

Mientras esperamos la solución, ayer ScottGu publicó una actualización sobre cómo agregar un paso adicional para proteger sus sitios con una regla personalizada de URLScan.

Además, agregue un tiempo de espera aleatorio en la página de error para evitar que el atacante cronometre las respuestas para obtener información adicional sobre el ataque.

En web.config

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

Esto redirigirá cualquier error a una página personalizada devuelta con un código de estado 200. De esta forma, un atacante no puede mirar el código de error o la información de error para obtener la información necesaria para futuros ataques.

También es seguro configurarlo customErrors mode="RemoteOnly", ya que esto redirigirá a los clientes "reales". Solo navegar desde localhost mostrará errores internos .Net.

La parte importante es asegurarse de que todos los errores estén configurados para devolver la misma página de error. Esto requiere que establezca explícitamente el defaultRedirectatributo en la <customErrors>sección y asegúrese de que no se establezcan códigos por estado.

¿Lo que está en juego?

Si un atacante logra utilizar el exploit mencionado, puede descargar archivos internos desde su aplicación web. Por lo general, web.config es un objetivo y puede contener información confidencial como información de inicio de sesión en una cadena de conexión de base de datos, o incluso un enlace a una base de datos sql-express automatizada que no desea que alguien se apodere. Pero si sigue las mejores prácticas, utiliza la Configuración protegida para cifrar todos los datos confidenciales en su web.config.

Enlaces a referencias

Lea el comentario oficial de Microsoft sobre la vulnerabilidad en http://www.microsoft.com/technet/security/advisory/2416728.mspx . Específicamente, la parte "Solución" para detalles de implementación sobre este tema.

También hay información en el blog de ScottGu , que incluye un script para encontrar aplicaciones ASP.Net vulnerables en su servidor web.

Para obtener una explicación sobre "Comprensión de los ataques de Oracle de relleno", lea la respuesta de @ sri .

Comentarios al artículo:

El ataque que Rizzo y Duong han implementado contra las aplicaciones ASP.NET requiere que la implementación de cifrado en el sitio web tenga un oráculo que, cuando se envía texto cifrado, no solo descifrará el texto sino que le dará al remitente un mensaje sobre si el relleno en el texto cifrado es válida .

Si el relleno no es válido, el mensaje de error que recibe el remitente le dará información sobre la forma en que funciona el proceso de descifrado del sitio.

Para que el ataque funcione, lo siguiente debe ser cierto:

• Su aplicación debe dar un mensaje de error acerca de que el relleno no es válido.
• Alguien debe alterar sus cookies cifradas o viewstate

Entonces, si devuelve mensajes de error legibles por humanos en su aplicación como "Algo salió mal, intente nuevamente", entonces debería estar bastante seguro. Leer un poco sobre los comentarios sobre el artículo también brinda información valiosa.

• Almacenar una identificación de sesión en la cookie cifrada
• Almacene los datos reales en estado de sesión (persistió en un db)
• Agregue una espera aleatoria cuando la información del usuario sea incorrecta antes de devolver el error, para que no pueda cronometrarlo

De esa manera, una cookie secuestrada solo se puede usar para recuperar una sesión que probablemente ya no esté presente o invalidada.

Será interesante ver lo que realmente se presenta en la conferencia Ekoparty, pero en este momento no estoy demasiado preocupado por esta vulnerabilidad.

Comprender los ataques de Oracle Relleno

Supongamos que su aplicación acepta una cadena encriptada como parámetro, ya sea que el parámetro sea una cookie, un parámetro de URL o alguna otra cosa sea irrelevante. Cuando la aplicación intenta decodificarlo, hay 3 resultados posibles:

1. Resultado 1 : la cadena cifrada se descifró correctamente, y la aplicación pudo darle sentido. Es decir, si la cadena encriptada era un número de cuenta de 10 dígitos, después del descifrado, la aplicación encontró algo como "1234567890" y no "abcd1213ef"

2. Resultado 2 : el relleno fue correcto, pero después del descifrado, la cadena obtenida era un galimatías que la aplicación no podía entender. Por ejemplo, la cadena se descifró a "abcd1213ef", pero la aplicación solo esperaba números. La mayoría de las aplicaciones mostrarán un mensaje como "Número de cuenta no válido".

3. Resultado 3 : el relleno era incorrecto y la aplicación arrojó algún tipo de mensaje de error. La mayoría de las aplicaciones mostrarán un mensaje genérico como "Se produjo un error".

Para que un ataque de Padding Oracle tenga éxito, el atacante debe poder realizar varios miles de solicitudes, y debe poder clasificar la respuesta en uno de los 3 grupos anteriores sin error.

Si se cumplen estas dos condiciones, el atacante eventualmente puede descifrar el mensaje y luego volver a cifrarlo con lo que desee. Es solo una cuestión de tiempo.

¿Qué se puede hacer para prevenirlo?

1. Lo más simple: cualquier cosa sensible nunca debe enviarse al cliente, encriptada o no encriptada. Mantenlo en el servidor.

2. Asegúrese de que el resultado 2 y el resultado 3 en la lista anterior le parezcan exactamente iguales al atacante. No debería haber forma de descubrir uno del otro. Sin embargo, esto no es tan fácil: un atacante puede discriminar utilizando algún tipo de ataque de tiempo.

3. Como última línea de defensa, tenga un firewall de aplicaciones web. El ataque del oráculo de relleno necesita hacer varias solicitudes que se vean casi similares (cambiando un bit a la vez), por lo que debería ser posible que un WAF capture y bloquee tales solicitudes.

PD: Una buena explicación de Padding Oracle Attacks se puede encontrar en esta publicación de blog . Descargo de responsabilidad: NO es mi blog.

Por lo que leí hasta ahora ...

El ataque permite que alguien descifre las cookies inhaladas, que podrían contener datos valiosos, como saldos bancarios.

Necesitan la cookie encriptada de un usuario que ya ha iniciado sesión, en cualquier cuenta. También necesitan encontrar datos en las cookies. Espero que los desarrolladores no almacenen datos críticos en las cookies :). Y hay una forma que tengo a continuación para no permitir que asp.net almacene datos en la cookie de inicio de sesión.

¿Cómo puede alguien obtener la cookie de un usuario que está en línea si no tiene en sus manos los datos del navegador? ¿O esnifar el paquete IP?

Una forma de evitar eso es no permitir que las cookies se transporten sin cifrado SSL.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

También una medida más es evitar almacenar Roles en las cookies.

<roleManager enabled="true" cacheRolesInCookie="false">

Ahora, sobre las cookies que no son seguras para las páginas normales, esto necesita pensar un poco más sobre lo que dejó a su usuario hacer y qué no, cómo confía en él, qué verificación adicional puede hacer (por ejemplo, si ve un cambio en la IP , tal vez deje de confiar en él hasta que vuelva a iniciar sesión desde la página de seguridad).

Referencia:
¿Puede algún hacker robar la cookie de un usuario e iniciar sesión con ese nombre en un sitio web?

Cómo verificar de dónde vienen los ataques y no devolver información. Escribí aquí una forma simple de evitar que el relleno no sea válido y al mismo tiempo iniciar sesión para rastrear a los atacantes: Excepción criptográfica: el relleno no es válido y no se puede eliminar y la validación del MAC del estado de vista falló

La forma de rastrear al atacante es verificar que el relleno no sea válido. Con un procedimiento simple, puede rastrearlos y bloquearlos: ¡necesitan miles de llamadas en su página para encontrar la clave!

Actualización 1.

He descargado la herramienta que supone que es encontrar la CLAVE y descifrar los datos, y como digo, su trampa en el código anterior es verificar el estado de la vista . De mis pruebas, esta herramienta tiene mucho más que arreglar, por ejemplo, no puede escanear el estado de vista comprimido tal como está y su bloqueo en mis pruebas.

Si alguien intenta usar esta herramienta o este método, el código anterior puede rastrearlos y puede bloquearlos fuera de su página con un código simple como este "Prevenir la denegación de servicio (DOS)" , o como este código para prevenir la denegación del servicio .

Actualización 2

Parece por lo que leí hasta ahora que lo único que realmente se necesita es que no brinde información sobre el error , y simplemente coloque una página de error personalizada y, si lo desea, puede crear y un retraso aleatorio en esta página.

Un video muy interesante sobre este tema.

Entonces, todo lo anterior es más medida para obtener más protecciones, pero no es 100% necesario para este problema en particular. Por ejemplo, usar la cookie SSL es resolver el problema snif, no almacenar en caché los roles en las cookies, es bueno no enviar y recuperar cookies grandes, y evitar que alguien tenga todo listo para descifrar el código, simplemente coloque el rol de administrador en La galleta de él.

El seguimiento del estado de vista es solo una medida más para encontrar el ataque.

Aquí está la respuesta de MS. Todo se reduce a "usar una página de error personalizada" y no dará ninguna pista.

EDITAR
Aquí hay información más detallada de scottgu.

Agregar las respuestas de ScottGu tomadas de la discusión en http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

¿Se ve afectado IHttpModule en lugar de customErrors?

P: No tengo un elemento declarado en mi web.config, sino que tengo un IHttpModule dentro de la sección. Este módulo registra el error y lo redirige a una página de búsqueda (para 404) o a una página de error (para 500). ¿Soy vulnerable?

R: Recomendaría actualizar temporalmente el módulo para redirigir siempre a la página de búsqueda. Una de las formas en que funciona este ataque es que busca la diferenciación entre 404 y 500 errores. Siempre devolver el mismo código HTTP y enviarlos al mismo lugar es una forma de ayudar a bloquearlo.

Tenga en cuenta que cuando salga el parche para solucionar esto, no necesitará hacer esto (y puede volver al comportamiento anterior). Pero por ahora recomendaría no diferenciar entre 404 y 500 a los clientes.

¿Puedo seguir usando diferentes errores para los errores 404 y 500?

P: Supongo que todavía podemos tener una página 404 personalizada definida además de la redirección predeterminada en caso de error, sin violar los principios descritos anteriormente.

R: No, hasta que lancemos un parche para la solución real, recomendamos la solución anterior que homogeneiza todos los errores. Una de las formas en que funciona este ataque es que busca la diferenciación entre 404 y 500 errores. Siempre devolver el mismo código HTTP y enviarlos al mismo lugar es una forma de ayudar a bloquearlo.

Tenga en cuenta que cuando salga el parche para solucionar esto, no necesitará hacer esto (y puede volver al comportamiento anterior). Pero por ahora no debe diferenciar entre 404 y 500 para clientes.

¿Cómo permite esto la exposición de web.config?

P: ¿Cómo permite esto la exposición de web.config? Esto parece permitir el descifrado de ViewState solamente, ¿hay otra vulnerabilidad relacionada que también permita la divulgación de información? ¿Hay un documento que detalla el ataque para una mejor explicación de lo que está sucediendo?

R: El ataque que se mostró en público se basa en una característica de ASP.NET que permite la descarga de archivos (típicamente javascript y css) y que está protegida con una clave que se envía como parte de la solicitud. Desafortunadamente, si puede falsificar una clave, puede usar esta función para descargar el archivo web.config de una aplicación (pero no archivos fuera de la aplicación). Obviamente, lanzaremos un parche para esto; hasta entonces, la solución anterior cierra el vector de ataque.

EDITAR: Preguntas frecuentes adicionales disponibles en el segundo blog en http://weblogs.asp.net/scottgu/archive/2010/09/20/frequency-asked-questions-about-the-asp-net-security-vulnerability.aspx

En mi opinión, no existe una prevención general para esto, debe manejarse caso por caso:

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

Algunos enlaces importantes:

• Aviso de seguridad de MS 2416728 (esta es la información oficial)
• Información adicional del equipo de investigación y defensa de seguridad de MS
  • "Comprender la vulnerabilidad de ASP.NET" (2010-09-17)
  • "Información adicional sobre la vulnerabilidad de ASP.NET" (2010-09-20)
• Scott Gu: "Importante: vulnerabilidad de seguridad de ASP.NET" (2010-09-18)

[Para responder al aspecto de seriedad de esto (lo que ha sido publicado y las soluciones están cubiertas por otras respuestas).]

La clave que se está atacando se usa para proteger tanto el estado de visualización como las cookies de sesión. Normalmente, esta clave es generada internamente por ASP.NET con cada nueva instancia de la aplicación web. Esto limitará el alcance del daño a la vida útil del proceso del trabajador, por supuesto, para una aplicación ocupada, esto podría ser días (es decir, no es un límite). Durante este tiempo, el atacante puede cambiar (o inyectar) valores en ViewState y cambiar su sesión.

Aún más en serio si desea que las sesiones puedan abarcar la vida útil de los procesos de trabajo, o permitir granjas web (es decir, todas las instancias en la granja pueden manejar cualquier sesión de usuario), la clave debe estar codificada, esto se hace en web.config:

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

Esas son, por supuesto, claves recién creadas, utilizo el siguiente PowerShell para acceder al generador de números aleatorios criptográficos de Windows:

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

(Usando una longitud de matriz de 20 para la validación y 16 para las claves de descifrado).

Además de modificar las páginas de error públicas para no filtrar el error específico, parece un buen momento para cambiar las claves anteriores (o ciclos de procesos de trabajo si se han estado ejecutando durante un tiempo).

[Editar 2010-09-21: Se agregaron enlaces al principio]

Acabo de publicar mi opinión completa sobre esto en mi blog , después de una investigación adicional sobre el tema. Creo que es importante aclarar por qué están llegando a falsificar una cookie de autenticación.

Solo quiero aclarar algunos hechos:

1. El ataque no le permite obtener la clave de la máquina directamente. Dicho esto, es más o menos como lo había hecho, ya que permite descifrar los mensajes y modificar re / cifrar nuevos.
2. la forma de obtener las claves reales es mediante el uso de su capacidad para modificar re / cifrar como en 1 y obtener el web.config. Desafortunadamente, hay razones por las cuales algunos ponen estas claves en web.config a nivel de sitio (discusión diferente), y en el video de muestra se benefician de que ese sea el valor predeterminado de DotnetNuke.
3. para obtener el archivo web.config todo apunta a que están usando webresources.axd y / o scriptresources.axd. Pensé que estos solo funcionaban con recursos integrados, pero parece que ese no es el caso.
4. si la aplicación es asp.net MVC, realmente no necesitamos webresources.axd y / o scriptresources.axd, por lo que se pueden desactivar. Tampoco usamos viewstate. Dicho esto, no está claro para mí si alguna de las otras características de asp.net proporciona información diferente con la solución alternativa establecida, es decir, no sé si el relleno proporciona resultados inválidos por error mientras que el relleno arroja resultados válidos en un ticket de autenticación ignorado (no sé si es o no el caso) ... el mismo análisis debe aplicarse a la cookie de sesión.
5. Las funciones de caché del proveedor de membresía asp.net en las cookies, desactívelas.

Aproximadamente 1, afaik, los mensajes cifrados no pueden ser 100% arbitrarios, es necesario tolerar un pequeño pedazo de basura en algún lugar del mensaje, ya que hay 1 bloque en el mensaje que descifra el valor que no se puede controlar.

Finalmente, me gustaría decir que este problema es el resultado de que ms no siga su propia guía en este caso: una función se basa en que algo enviado al cliente es a prueba de manipulación.

Más en:

No sé si el relleno arroja resultados inválidos por error mientras que el relleno arroja resultados válidos en un ticket de autenticación ignorado (no sé si es así o no) ... el mismo análisis debería aplicarse a la cookie de sesión.

La cookie de autenticación está firmada y, a partir de la información en el documento, no deberían poder generar una cookie firmada si no llegan a las claves reales (como lo hicieron en el video antes de falsificar la cookie de autenticación).

Como Aristos mencionó, para la identificación de la sesión en la cookie, eso es aleatorio para la sesión del usuario, por lo que debería ser rastreado por un usuario con el nivel de seguridad objetivo y descifrado mientras esa sesión está activa. Incluso entonces, si confía en la autenticación para asignar / autorizar las operaciones del usuario, entonces el impacto sería mínimo / dependería mucho de para qué se utiliza la sesión en esa aplicación.

Se ha lanzado un parche para este error en Windows Update: http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVC también se ve afectado por este problema (como lo es Sharepoint, ...)

He cubierto la solución para MVC aquí: ¿ASP.NET MVC es vulnerable al ataque de relleno de oráculo?