190 votos

¿Cómo de seria es esta nueva ASP.NET vulnerabilidad de la seguridad y cómo puedo solución?

Acabo de leer en la red acerca de un recién descubierto una vulnerabilidad de seguridad en ASP.NET. Usted puede leer los detalles aquí.

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

Esto es un poco vago, pero aquí es más aterrador parte:

La primera etapa del ataque se lleva a un unos mil solicitudes, pero una vez que se tiene éxito y el atacante obtiene el las claves secretas, es totalmente stealthy.The de cifrado conocimientos necesarios muy básico.

Con todo, no estoy lo suficientemente familiarizado con la seguridad/cryptograpy tema para saber si realmente es tan grave.

Así, si todos los ASP.NET los desarrolladores de miedo esta técnica que puede poseer cualquier ASP.NET sitio web en cuestión de segundos o qué?

¿Cómo este problema afecta a la media ASP.NET desarrollador? Nos afecta a todos? En la vida real, ¿cuáles son las consecuencias de esta vulnerabilidad? Y, por último: ¿hay alguna solución que evita que esta vulnerabilidad?

Gracias por sus respuestas!


EDIT: permítanme resumir las respuestas que me dieron

Así que, este es básicamente un "padding oracle" tipo de ataque. @Sri proporciona una gran explicación acerca de lo que hace este tipo de ataque media. Aquí es un impactante video sobre el tema!

Acerca de la gravedad de esta vulnerabilidad: Sí, esto es realmente serio. Esto permite al atacante a conocer a la máquina clave de una aplicación. Por lo tanto, él puede hacer muy cosas no deseadas.

  • En posesión de la aplicación de la clave del equipo, el atacante puede descifrar las cookies de autenticación.
  • Incluso peor que eso, él puede generar las cookies de autenticación con el nombre de cualquier usuario. Por lo tanto, puede aparecer como cualquier persona en el sitio. La aplicación es incapaz de diferenciar entre usted o el hacker que genera una cookie de autenticación con su nombre para sí mismo.
  • También le permite descifrar (y también generar) las cookies de sesión, aunque esto no es tan peligroso como el anterior.
  • No es tan grave: Él puede descifrar el cifrado de ViewState de páginas. (Si utiliza ViewState para almacenar confidental de datos, que usted no debería hacer esto de todos modos!)
  • Bastante inesperado: Con el conocimiento de la clave del equipo, el atacante puede descargar cualquier archivo desde la aplicación web, incluso aquellos que normalmente no se puede descargar! (Incluyendo Web.Config, etc.)

Aquí hay un montón de buenas prácticas conseguí que no soluciona el problema, pero ayuda a mejorar la seguridad general de una aplicación web.

Ahora, vamos a centrarnos en este tema.

La solución

  • Habilitar customErrors y hacer un solo error de la página a la que todos los errores son redirigidos. Sí, incluso 404. (ScottGu dijo que diferenciar entre 404 y 500 son esenciales para este ataque). También, en su Application_Error o Error.aspx poner un poco de código que hace que un retraso aleatorio. (Generar un número aleatorio, y el uso Thread.Sleep a dormir por un largo tiempo.) Esto hará que sea imposible para el atacante para decidir qué es exactamente lo que sucedió en su servidor.
  • Algunas personas recomiendan el cambio de nuevo a 3DES. En teoría, si no hace uso de AES, no encuentro la debilidad de seguridad en la implementación de AES. Como resulta, esto es , no se recomienda en absoluto.

Algunos otros pensamientos

  • Parece que no todo el mundo piensa que la solución es lo suficientemente bueno.

Gracias a todos los que respondieron a mi pregunta. He aprendido mucho, no solo de este tema, pero la seguridad de la web en general. Yo marcados @Mikael la respuesta como aceptada, pero las otras respuestas son también muy útiles.

58voto

Mikael Svenson Puntos 18243

¿Qué debo hacer para protegerme?

[Actualización 2010-09-29]

Boletín de seguridad de Microsoft

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

ScottGu tiene enlaces de las descargas

[Actualización 2010-09-25]

Mientras estamos a la espera de la revisión, ayer ScottGu postet una actualización sobre cómo agregar un paso adicional para proteger sus sitios con una medida de URLScan regla.


Básicamente, asegúrese de proveer una página personalizada de error, de modo que un atacante no está expuesto a la interna .Net los errores, que siempre debe de todos modos en el/la modo de producción.

Además de agregar un tiempo aleatorio dormir en la página de error para evitar que el atacante tiempo las respuestas para mayor información sobre los ataques.

En el 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 de regresar con un código de estado 200. De esta manera, un atacante puede mirar el código de error o error en la información de la información que se necesita para ataques posteriores.

También es seguro para configurar customErrors mode="RemoteOnly", ya que esto permitirá redirigir "real" de los clientes. Sólo navegando desde localhost mostrará interna .Net de errores.

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

¿Qué está en juego?

Si un atacante administrar el uso de los mencionados explotar, él/ella puede descargar archivos internos desde dentro de la aplicación web. Normalmente web.config es un objetivo y puede contener información confidencial, como información de inicio de sesión en una base de datos de cadena de conexión, o incluso vincular a un automouted sql express base de datos, que usted no quiere a alguien a conseguir. Pero si usted está siguiendo las mejores prácticas de utilizar la Configuración Protegida para cifrar todos los datos sensibles en su web.config.

Enlaces a referencias

Leer de Microsoft comentario oficial acerca de la vulnerabilidad en http://www.microsoft.com/technet/security/advisory/2416728.mspx. Específicamente la "Solución" de la parte de detalles de implementación de este problema.

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

Para una explicación sobre "la Comprensión de Relleno de Oracle Ataques", se leía en @sri respuesta.


Comentarios para el artículo:

El ataque que Rizzo y Duong han implementado en contra de ASP.NET aplicaciones requiere que el crypto la aplicación en el sitio Web tienen un oráculo que, cuando se envía cifrado, no sólo descifrar el texto pero dar el remitente de un mensaje acerca de si el relleno en el texto cifrado es válida.

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

Para que el ataque funcione deben cumplirse las siguientes condiciones:

  • Su aplicación debe dar un mensaje de error sobre el relleno no es válido.
  • Alguien debe manipular con su cifrado cookies o viewstate

Así que, si vuelve legible por humanos mensajes de error en su aplicación como "Algo salía mal, por favor intente de nuevo" , a continuación, usted debe ser bastante seguro. Leyendo un poco en los comentarios sobre el artículo también proporciona información valiosa.

  • Almacenar un identificador de sesión en el crypted cookie
  • Almacenar los datos reales en el estado de la sesión (se conserva en un db)
  • Añadir al azar esperar cuando la información de usuario que está mal antes de devolver el error, así que no puedes tiempo

De esa manera secuestrar un cookie sólo puede ser utilizado para recuperar una sesión que probablemente ya no está presente o invalidada.

Será interesante ver lo que realmente está presentado en la conferencia Ekoparty, pero ahora yo no estoy demasiado preocupado acerca de esta vulnerabilidad.

40voto

Sripathi Krishnan Puntos 15402

La Comprensión De Relleno De Oracle Ataques

Vamos a suponer la aplicación acepta una cadena cifrada como un parámetro - si el parámetro es una cookie, un parámetro de url o algo inmaterial. Cuando la aplicación intenta decodificar, hay 3 resultados posibles :

  1. Resultado 1 : La cadena cifrada descifrar correctamente, y la solicitud fue capaz de hacer sentido de ella. Es decir, si la cadena cifrada fue un 10 dígitos del número de cuenta, después de descifrado de la solicitud que se encuentra algo así como "1234567890" y no "abcd1213ef"

  2. Resultado 2 : El relleno era correcto, pero después de descifrado de la cadena obtenida fue de galimatías que la aplicación no podía entender. Por ejemplo, la cadena descifrada "abcd1213ef", pero la aplicación se estaba esperando sólo números. La mayoría de las aplicaciones se mostrara un mensaje como "no Válido número de cuenta".

  3. Resultado 3 : El relleno era incorrecta, y la aplicación tiró algún tipo de mensaje de error. La mayoría de las aplicaciones se mostrará un mensaje genérico, como "Algún error".

En orden para un Relleno de Oracle ataque tenga éxito, el atacante debe ser capaz de hacer varias miles de solicitudes, y debe ser capaz de clasificar la respuesta en uno de los 3 cubos sin error.

Si se cumplen estas dos condiciones, el atacante puede eventualmente descifrar el mensaje y, a continuación, volver a cifrar con lo que él desea. Es sólo una cuestión de tiempo.

¿Qué se puede hacer para evitarlo?

  1. Cosa más simple - nada sensible nunca debe ser enviado al cliente, cifrados o sin cifrar. Mantener en el servidor.

  2. Asegúrese de que el resultado de 2 y resultado 3 en la lista anterior aparecen exactamente en el mismo para el atacante. No debe haber ninguna manera de averiguar la una de la otra. Esto no es del todo fácil, a pesar de que un atacante puede discriminar el uso de algún tipo de sincronización ataque.

  3. Como una última línea de defensa, tiene un Firewall de Aplicaciones Web. El relleno de oracle ataque de las necesidades para hacer varias peticiones que se ven casi similar (el cambio de un bit a la vez), entonces debería ser posible para una WAF para detectar y bloquear este tipo de solicitudes.

P.S. UNA buena explicación de Relleno de Oracle Ataques se pueden encontrar en este blog. Descargo de responsabilidad: NO es mi blog.

13voto

Aristos Puntos 40367

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

El ataque permite a alguien descifrar olfateó las cookies, el cual podría contener datos valiosos como los saldos bancarios

Ellos necesitan la cookie cifrada de un usuario que ya se han iniciado, en cualquier cuenta. Ellos también necesitan encontrar los datos de las cookies - espero que los desarrolladores no almacenar datos críticos de cookies :). Y no es una manera que tengo de abajo para no dejar asp.net almacenar datos en el login cookie.

¿Cómo puede alguien obtener la cookie de un usuario que está en línea, si no llega a sus manos en el explorador de datos? Ni oler el paquete IP ?

Una forma de evitar esto es no permitir el uso de cookies de transporte sin encriptación ssl.

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

También uno más de la medida es evitar el almacenamiento de las Funciones de las cookies.

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

Ahora acerca de las cookies, que no son seguras para regular las páginas, esto necesita un poco más pensando en lo que a la izquierda de su usuario hacer y qué no, cómo confiar en él, lo comprobación adicional, usted puede hacer (por ejemplo, si usted ve un cambio en el ip, tal vez deje de confiar en él hasta entrar en la página de seguridad).

Referencia:
http://stackoverflow.com/questions/2498599/can-some-hacker-steal-the-cookie-from-a-user-and-login-with-that-name-on-the-web

Cómo comprobar de donde los ataques vienen y no volver a dar informaciones. Escribí aquí una manera sencilla de evitar que el relleno no es válido y registro en el mismo momento para rastrear a los atacantes: http://stackoverflow.com/questions/1821243/cryptographicexception-padding-is-invalid-and-cannot-be-removed-and-validation-o/2551810#2551810

El camino a la pista de que el atacante es para comprobar que el relleno no es válido. Con un procedimiento sencillo que se puede rastrear y bloquear, ellos necesitan de algunos miles de llamar en su página para encontrar la clave !

Update 1.

He de descargar la herramienta que supongo que esa es la CLAVE y descifrar los datos, y como digo su trampa en el anterior código de verificación el viewstate. De mis pruebas esta herramienta tiene muchas más para corregir, por ejemplo, no se puede escanear comprimidos estado de la vista tal como es y su choque en mis pruebas.

Si alguien pruebe a utilizar esta herramienta o método, el código anterior se puede rastrear y puede bloquear el uso de la página con código simple como este "Evitar la Denegación De Servicio (DOS)", o como en este código para la prevención de Denegación de servicio.

Actualización 2

Al parecer por lo que he leído hasta ahora que el sólo pensar que es realmente lo necesitan para no dar información sobre el error, y acaba de colocar una página personalizada de error y si lo desea, puede crear y un retraso aleatorio a esta página.

un video muy interesante sobre este tema.

Así que todas las por encima de su medida más para más protección, pero no 100% necesarios para este tema en particular. Por ejemplo, para utilizar ssl cookie es resolver la snif problema, el no almacenar en caché las Funciones de los cookies es bueno a no enviar y obtener grandes cookies, y para evitar algunos de los que tienen todo listo romper el código, simplemente colocar el rol de administrador de la cookie de él.

El viewstate de la pista es sólo una medida más para buscar el ataque.

12voto

ScottS Puntos 5247

Aquí está la respuesta de MS. Todo se reduce a "utilizar una página personalizada de error" y que no va a dar a la basura cualquier pistas.

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

12voto

Martin Vobr Puntos 3443

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

Es costumbre IHttpModule en lugar de customErrors afectados?

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

R: yo recomendaría temporalmente la actualización del módulo para siempre redirigir a la página de búsqueda. Una de las formas de este ataque es que las obras se ve la diferenciación entre 404 y 500 errores. Siempre devuelve el mismo código HTTP, y enviarlos en el mismo lugar, es una manera de ayudar a bloquear.

Tenga en cuenta que cuando el parche viene a solucionar este problema, usted no necesita hacer esto (y puede volver al antiguo comportamiento). Pero por ahora, me gustaría recomendar la no diferenciación entre 404 y 500 para los clientes.

¿Puedo seguir utilizando diferentes errores 404 y 500 errores?

Q: puedo tomar todavía se puede tener una página de error 404 personalizado definido además del defecto de redirección en caso de error, sin violar los principios descritos anteriormente?

R: No - hasta que la liberación de un parche para el real revisión, se recomienda la solución anterior que homogeniza todos los errores. Una de las formas de este ataque es que las obras se ve la diferenciación entre 404 y 500 errores. Siempre devuelve el mismo código HTTP, y enviarlos en el mismo lugar, es una manera de ayudar a bloquear.

Tenga en cuenta que cuando el parche viene a solucionar este problema, usted no necesita hacer esto (y puede volver al antiguo comportamiento). Pero por ahora no se debe diferenciar entre 404 y 500 para los clientes.

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

P: ¿Cómo funciona esto permitirá la exposición de web.config? Esto parece habilitar el descifrado de ViewState sólo, hay otro relacionado con la vulnerabilidad que permite también la divulgación de información? Hay un documento en el que se detalla el ataque para una mejor explicación de lo que está pasando?

R: El ataque de que fue mostrado en el público se basa en una característica en ASP.NET que permite que los archivos (normalmente javascript y css) para ser descargado, y que está protegida con una clave que se envíen como parte de la solicitud. Desafortunadamente, si son capaces de forjar una clave que pueden usar esta característica para descargar el archivo web.config de una aplicación (pero no los archivos fuera de la aplicación). Es evidente que la liberación de un parche para esto - hasta entonces la solución anterior se cierra el vector de ataque.

EDIT: más preguntas frecuentes disponibles en la segunda publicación de blog en http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X