asp.net .net security padding-oracle-attack
script

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



security padding-oracle-attack (10)

Acabo de leer en la red una vulnerabilidad de seguridad recién 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 toma 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 serio.

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 de 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!

EDIT: Déjame resumir las respuestas que obtuve

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

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

  • En posesión de la clave de la máquina de la aplicación, el atacante puede descifrar las cookies de autenticación.
  • Aún peor que eso, puede generar cookies de autenticación con el nombre de cualquier usuario. Por lo tanto, puede aparecer como cualquier persona en el sitio. La aplicación no puede diferenciar entre usted o el pirata informático 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 encriptado de las páginas. (Si usa ViewState para almacenar datos confidenciales, ¡no debería hacer esto de todos modos!)
  • Bastante inesperado : con el conocimiento de la clave de la máquina, el atacante puede descargar cualquier archivo arbitrario de su aplicación web, incluso los 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.

Ahora, concentrémonos en este tema.

La solución

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

Algunos otros pensamientos

  • Parece que not everyone 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 @Maelael como aceptada, pero las otras respuestas también son muy útiles.

¿Qué debo hacer para protegerme?

[Actualización 2010-09-29]

microsoft.com/technet/security/bulletin/MS10-070.mspx

Artículo de KB con referencia al arreglo.

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.

Básicamente, asegúrate de proporcionar una página de error personalizada para que un atacante no esté expuesto a errores internos de .Net, que siempre deberías estar en modo de lanzamiento / producción.

Además, agregue un tiempo de espera aleatorio en la página de error para evitar que el atacante sincronice 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 manera, 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 establecer customErrors mode="RemoteOnly" , ya que esto redireccionará a los clientes "reales". Solo la navegación desde localhost mostrará errores internos de .Net.

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

¿Lo que está en juego?

Si un atacante logra usar el exploit mencionado, él / ella 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 de sql-express automática que no quiere que nadie obtenga. Pero si está siguiendo las mejores prácticas, utilice 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 alternativa" para detalles de implementación sobre este tema.

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

Para obtener una explicación sobre "Comprender los ataques de Oracle de relleno", lea @Sri .

Comentarios al artículo:

El ataque que Rizzo y Duong han implementado contra las aplicaciones ASP.NET requiere que la implementación criptográfica en el sitio web tenga un oráculo que, cuando se envía texto cifrado, no solo descifre el texto, sino que también envíe un mensaje al remitente sobre si el relleno en el texto cifrado es valido

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 verdadero:

  • Su aplicación debe dar un mensaje de error acerca de que el relleno no es válido.
  • Alguien debe manipular sus cookies encriptadas o su estado de visualización.

Por lo tanto, si devuelve mensajes de error legibles por humanos en su aplicación como "Algo salió mal, inténtelo de nuevo", entonces debería estar bastante seguro. Leer un poco sobre los comentarios del artículo también proporciona información valiosa.

  • Almacenar un identificador de sesión en la cookie encriptada
  • Almacenar los datos reales en estado de sesión (persistido en un db)
  • Agregue una espera aleatoria cuando la información del usuario sea incorrecta antes de devolver el error, por lo que no puede cronometrarla

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

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

Acabo de publicar mi versión completa de esto en mi blog , después de una investigación adicional sobre el tema. Creo que es importante aclarar por qué están llegando tan lejos como para forjar una cookie de autenticación.

Sólo quiero aclarar algunos hechos:

  1. El ataque no te permite obtener la clave de la máquina directamente. Dicho esto, es muy parecido a lo que tenía, ya que permite descifrar los mensajes y modificar / reencriptar los nuevos.
  2. la forma en que se obtienen las claves reales es mediante el uso de su capacidad para modificar re / encrypt como en 1 y obtener el web.config. Desafortunadamente, hay razones por las que algunos ponen estas claves en el sitio web.config a nivel del sitio (discusión diferente), y en el video de muestra se benefician de que sea el valor predeterminado de DotnetNuke.
  3. para obtener el web.config todo lo que hay por ahí indica que están usando webresources.axd y / o scriptresources.axd. Pensé que funcionaban solo 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 me queda claro si alguna de las otras características de asp.net proporciona información diferente con la solución en su lugar, es decir, no sé si el relleno da resultados inválidos por error al rellenar resultados válidos en el ticket de autenticación ignorado (no sé si es o no el caso) ... el mismo análisis debería aplicarse a la cookie de sesión.
  5. El proveedor de membresía asp.net ''almacena'' roles en las cookies, desactívelo.

Aproximadamente 1, después de que los mensajes cifrados no pueden ser 100% arbitrarios, es necesario tolerar una pequeña pieza 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 sigue su propia guía en este caso: una característica se basa en que algo enviado al cliente es a prueba de manipulaciones.

Más en:

No sé si el relleno da resultados inválidos por error al rellenar los resultados válidos en el 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 del 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 mencionó Aristos, para el identificador de sesión en la cookie, eso es aleatorio para la sesión del usuario, por lo que tendría que ser rastreado de un usuario con el nivel de seguridad objetivo y resquebrajado mientras esa sesión esté activa. Incluso entonces, si confía en la autenticación para asignar / autorizar las operaciones del usuario, el impacto sería mínimo / dependería mucho de para qué se utiliza la sesión en esa aplicación.

Algunos enlaces significativos:

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

La clave que se está atacando se utiliza para proteger las cookies de estado y de sesión. Normalmente, esta clave se genera 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 de trabajo, por supuesto, para una aplicación ocupada, esto podría ser días (es decir, sin mucho 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 de servidores web (es decir, todas las instancias de la granja de servidores 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, uso 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}

(Utilizando 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 teclas anteriores (o los procesos del trabajador del ciclo si se han estado ejecutando durante un tiempo).

[Editar 2010-09-21: Se agregaron enlaces a la parte superior]

De lo que he leído hasta ahora ...

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

Necesitan la cookie cifrada de un usuario que ya haya 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 manera 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 obtiene los datos del navegador? ¿O oler el paquete IP?

Una forma de evitarlo es no permitir que las cookies se transporten sin cifrado ssl.

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

También una medida más es evitar el almacenamiento de roles en las cookies.

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

Ahora sobre las cookies que no son seguras para las páginas normales, esto requiere pensar más en lo que dejó a su usuario y en qué no, cómo confía en él, qué cheque adicional puede hacer (por ejemplo, si ve un cambio en la IP). , quizás 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 comprobar de dónde vienen los ataques y no devolver información. Escribí aquí una forma sencilla de evitar que el relleno no sea válido y el registro al mismo tiempo para localizar a los atacantes: CryptographicException: el relleno no es válido y no se puede eliminar y la validación de viewstate MAC falló

La forma de rastrear al atacante es verificar que el relleno no es 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 visualización . Desde mis pruebas, esta herramienta tiene muchas más que arreglar, por ejemplo, no puede escanear el estado de vista comprimido tal como está y se bloquea 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 "Evitar la denegación de servicio (DOS)" o como este código para evitar la denegación de servicio .

Actualización 2

Parece por lo que he leído hasta ahora que lo único que creo es que realmente es necesario que no devuelva 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.

Por lo tanto, todo lo anterior es más importante para más protecciones pero no el 100% necesario para este problema en particular. Por ejemplo, el uso de la cookie ssl es resolver el problema del snif, no almacenar en caché los roles en las cookies, es bueno no enviar y recuperar cookies grandes, y para evitar que alguno tenga listo el código, simplemente coloque el rol de administrador en la galleta de él.

La pista del estado visual es solo una medida más para encontrar el ataque.

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

not

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

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

Agregando 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 el IHttpModule personalizado en lugar de customErrors?

P: No tengo un elemento declarado en mi web.config, en su lugar tengo un IHttpModule dentro de la sección. Este módulo registra el error y 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 este problema, no necesitará hacerlo (y podrá volver al comportamiento anterior). Pero por ahora recomiendo no diferenciar entre 404 y 500 a los clientes.

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

P: ¿Supongo que todavía podemos tener una página 404 personalizada definida además del redireccionamiento predeterminado en caso de error, sin violar los principios descritos anteriormente?

R: No, hasta que publiquemos 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 este problema, no necesitará hacerlo (y podrá volver al comportamiento anterior). Pero por el momento no debe diferenciar entre 404 y 500 a clientes.

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

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

R: El ataque que se mostró en público se basa en una función en ASP.NET que permite la descarga de archivos (normalmente javascript y css), y que se protege 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 los archivos fuera de la aplicación). Obviamente, lanzaremos un parche para esto, hasta que la solución anterior cierre el vector de ataque.

EDITAR: Preguntas frecuentes adicionales disponibles en la segunda entrada del blog en http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

Entendiendo los ataques Oracle de 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 algo más no tenga importancia. Cuando la aplicación intenta decodificarla, 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 cifrada era un número de cuenta de 10 dígitos, después de descifrar la aplicación encontró algo así como "1234567890" y no "abcd1213ef"

  2. Resultado 2 : El relleno fue correcto, pero después de descifrar la cadena obtenida fue un engaño que la aplicación no pudo entender. Por ejemplo, la cadena se descifra 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 fue 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 "Ocurrió un error".

Para que un ataque de Padding Oracle tenga éxito, el atacante debe poder hacer 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 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, cifrada o no cifrada. Mantenlo en el servidor.

  2. Asegúrese de que el resultado 2 y el resultado 3 en la lista anterior sean exactamente iguales para el atacante. No debería haber manera de descifrar una de la otra. Sin embargo, esto no es tan fácil: un atacante puede discriminar usando algún tipo de ataque de tiempo.

  3. Como última línea de defensa, tiene un Firewall de aplicaciones web. El ataque oracle de relleno debe realizar varias solicitudes que parecen casi similares (cambiar un bit a la vez), por lo que debería ser posible que un WAF detecte y bloquee dichas solicitudes.

PS Una buena explicación de los ataques de Oracle de relleno se puede encontrar en esta publicación de blog . Descargo de responsabilidad: no es mi blog.