Información detallada sobre la vulnerabilidad de ASP.NET descrita en el Documento Informativo de Seguridad 2416728
Hola todos, les escribe Roberto Arbeláez.
El 17 de Septiembre liberamos el Documento informativo de Seguridad 2416728 acerca de una vulnerabilidad de seguridad en ASP.NET. Esta vulnerabilidad existe en todas las versiones de ASP.NET.
Recomendamos que todos los clientes apliquen de inmediato una solución temporal (que se describe a continuación) para impedir que los atacantes utilicen esta vulnerabilidad contra sus aplicaciones ASP.NET.
A continuación, información detallada y preguntas frecuentes sobre esta vulnerabilidad, tomada del blog de Scott Guthrie.
¿Qué permite la vulnerabilidad?
El atacante que utiliza esta vulnerabilidad puede solicitar y descargar archivos dentro de una Aplicación ASP.NET como el archivo web.config (el cual con frecuencia contiene datos confidenciales).
El atacante que explota esta vulnerabilidad también puede descifrar los datos que se envían al cliente en un estado cifrado (como los datos ViewState dentro de una página).
Cómo funciona la vulnerabilidad
Para comprender cómo funciona esta vulnerabilidad, necesita saber acerca de los oráculos criptográficos (cryptographic oracles). Un oráculo en el contexto de la criptografía es un sistema que ofrece pistas mientras usted formula preguntas. En este caso, existe una vulnerabilidad en ASP. NET la cuál actúa como un oráculo de relleno (padding oracle). Esto permite que el atacante envíe texto cifrado al servidor Web y sepa si se descifró correctamente al examinar qué código de error devolvió el servidor Web. Al realizar varias solicitudes (y observar qué errores se devolvieron) el atacante puede saber lo suficiente para descifrar con éxito el resto del texto cifrado.
Cómo resolver temporalmente la vulnerabilidad
Una solución temporal que usted puede utilizar para prevenir esta vulnerabilidad es habilitar la característica <customErrors> de ASP.NET, y configurar explícitamente sus aplicaciones para que siempre devuelvan la misma página de error, sin importar el error que se genere en el servidor. Al redireccionar todas las páginas de error a una página de error única, usted impide que el atacante pueda diferenciar entre los diferentes tipos de errores que ocurren en el servidor.
Importante: No basta simplemente con activar CustomErrors o configurarla en RemoteOnly. También necesita asegurarse de que todos los errores están configurados para devolver la misma página de error. Esto requiere que usted establezca explícitamente el atributo “defaultRedirect” en la sección <customErrors> y se asegure de que no esté establecido ningún código por estado.
Cómo habilitar la solución temporal en ASP.NET V1.0 a V3.5
Si usted utiliza ASP.NET 1.0, ASP.NET 1.1, ASP.NET 2.0 o ASP.NET 3.5 entonces debe seguir los pasos a continuación para habilitar <customErrors> y correlacionar todos los errores a una página de error única:
1) Edite el archivo raíz Web.Config de su Aplicación ASP.NET. Si el archivo no existe, entonces cree uno en el directorio raíz de la aplicación.
2) Cree o modifique la sección <customErrors> del archivo web.config para establecer las configuraciones a continuación:
<configuration> <system.web> <customErrors mode="On" defaultRedirect="~/error.html" /> </system.web> </configuration>
3) Posteriormente usted puede agregar un archivo error.html a su aplicación que contenga la página de error de su elección (que incluya el contenido que usted desee). Este archivo aparecerá cada vez que ocurra un error dentro de la aplicación Web.
Notas: Lo importante que se debe observar de lo anterior es que customErrors está establecido en “activo”, y que todos los errores se manejan a través de la página de error defaultRedirect. No hay ninguna página de error código por estado definida, lo cual significa que no hay sub-elementos <error> dentro de la sección <customErrors>. Esto impide que el atacante pueda diferenciar por qué ocurrió un error en el servidor, e impide que se divulgue la información.
Cómo habilitar la solución temporal en ASP.NET V3.5 SP1 y ASP.NET 4.0
Si usted utiliza ASP.NET 3.5 SP1 o ASP.NET 4.0 entonces debe seguir los pasos a continuación para habilitar <customErrors> y redireccionar todos los errores a una página de error única:
1) Edite el archivo raíz Web.Config de su Aplicación ASP.NET. Si el archivo no existe, entonces cree uno en el directorio raíz de la aplicación.
2) Cree o modifique la sección <customErrors> del archivo web.config para establecer las configuraciones a continuación. Observe el uso de redirectMode=”ResponseRewrite” con .NET 3.5 SP1 y .NET 4.0:
<configuration> <system.web> <customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/error.aspx" /> </system.web> </configuration>
3) Posteriormente usted puede agregar un archivo Error.aspx a su aplicación que contiene la página de error apropiada de su elección (que incluye el contenido que usted desea). Este archivo aparecerá cada vez que ocurra un error dentro de la aplicación Web.
4) Recomendamos agregar el siguiente código al manejador de eventos de servidor Page_Load() dentro del archivo Error.aspx para agregar un retraso pequeño de hibernación aleatorio. Esto ayudará a ofuscar más a fondo los errores.
Versión VB
A continuación se encuentra la versión VB de un archivo Error.aspx que usted puede utilizar, y el cual tiene un retraso pequeño de hibernación aleatorio en él. No necesita compilarlo en una aplicación, simplemente puede guardar este archivo Error.aspx en el directorio de la aplicación en su servidor Web:
<%@ Page Language="VB" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
Sub Page_Load()
Dim delay As Byte() = New Byte(0) {}
Dim prng As RandomNumberGenerator = New RNGCryptoServiceProvider()
prng.GetBytes(delay)
Thread.Sleep(CType(delay(0), Integer))
Dim disposable As IDisposable = TryCast(prng, IDisposable)
If Not disposable Is Nothing Then
disposable.Dispose()
End If
End Sub
</script>
<html>
<head runat="server">
<title>Error</title>
</head>
<body>
<div>
Lo sentimos – ocurrió un error
</div>
</body>
</html>
Versión C#
A continuación se encuentra la versión C# de un archivo Error.aspx que usted puede utilizar, y el cual tiene un retraso pequeño de hibernación aleatorio en él. No necesita compilar éste en una aplicación, de otra manera simplemente puede guardarlo en el directorio de la aplicación en su servidor Web:
<%@ Page Language="C#" AutoEventWireup="true" %>
<%@ Import Namespace="System.Security.Cryptography" %>
<%@ Import Namespace="System.Threading" %>
<script runat="server">
void Page_Load() {
byte[] delay = new byte[1];
RandomNumberGenerator prng = new RNGCryptoServiceProvider();
prng.GetBytes(delay);
Thread.Sleep((int)delay[0]);
IDisposable disposable = prng as IDisposable;
if (disposable != null) { disposable.Dispose(); }
}
</script>
<html>
<head runat="server">
<title>Error</title>
</head>
<body>
<div>
Un error ocurrió al procesar su solicitud.
</div>
</body>
</html>
Cómo verificar si la solución temporal está habilitada
Una vez que aplique la solución temporal anterior, puede probarla para asegurarse de que la sección <customErrors> está correctamente configurada al acceder a una URL como ésta en su sitio: https://misitio.com/paginaquenoexiste.aspx (reemplace “misitio.com” por la dirección de su sitio web)
Si usted ve que aparece la página de error personalizada (porque la página “paginaquenoexiste.aspx” que usted solicitó no existe) entonces su configuración está correctamente establecida. Si ve un error estándar de ASP.NET, entonces es probable que haya omitido uno de los pasos anteriores. Para ver más información acerca de lo que podría estar causando el problema, puede probar la configuración <customErrorsmode=”remoteOnly”/>, la cual le permitirá ver el mensaje de error si usted se conecta al sitio desde un explorador local.
Cómo encontrar aplicaciones ASP.NET vulnerables en su servidor Web
Publicamos una secuencia de comandos .vbs que usted puede guardar y ejecutar en su servidor Web para determinar si hay aplicaciones ASP. NET instaladas en él que tengan desactivado <customErrors>, o qué mensajes de error diferentes dependiendo de los códigos de estado.
Usted puede descargar la secuencia de comandos .vbs aquí. Simplemente copie/pegue la secuencia de comandos en un archivo de texto de nombre “DetectCustomErrors.vbs” y guárdelo en una unidad de almacenamiento (disco duro) local. Posteriormente lance una ventana de comando que esté elevada como administrador y ejecute “cscript DetectCustomErrors.vbs” para ejecutarla contra su servidor Web local. Enumerará todas las aplicaciones dentro de su servidor Web y verificará que se haya especificado la configuración <customErrors> correcta.
Marcará cualquier aplicación donde encuentre que el archivo web.config de una aplicación no tiene la sección <customErrors> (en cuyo caso será necesario que lo agregue), o que no lo tiene establecido correctamente para solucionar temporalmente este ataque (en cuyo caso será necesario que lo actualice). Imprimirá “ok” para cada archivo web.config de la aplicación que encuentre que está bien. Se espera que esto facilite localizar los programas.
Nota: Desarrollamos esta secuencia de comandos de detección en las últimas horas, y la afinaremos más a fondo en el futuro. Se publicará una actualización cada vez que realicemos algún cambio a ella.
Preguntas frecuentes acerca de la vulnerabilidad de seguridad de ASP.NET
A continuación encontrará respuestas a algunas preguntas comunes que han formulado muchas personas respecto a la vulnerabilidad.
¿Microsoft va a liberar una actualización para reparar la vulnerabilidad?
Sí. Estamos trabajando en una actualización para ASP.NET que liberaremos a través de Windows Update una vez que se haya probado completamente y esté lista para su extensa distribución.
Hasta que la actualización esté disponible, también publicaremos los detalles sobre las soluciones temporales (como la que se describe en esta publicación) que se pueden aplicar de inmediato para ayudar a protegerse contra la vulnerabilidad. Observe que las soluciones son temporales, y no se requerirán una vez que la actualización repare la vulnerabilidad en los productos subyacentes. Tienen como objetivo ofrecer pasos que usted puede emprender de inmediato hasta que la actualización esté disponible.
¿Se trata de un problema en ASP.NET o de alguna vulnerabilidad criptográfica?
Ésta vulnerabilidad existe debido a la manera como ASP.NET utiliza la criptografía en ciertas circunstancias, que permite filtraciones de información por “canales alternativos” (side channels), también conocidos en seguridad como “covert channels”, a través de las respuestas de error. El uso actual de ASP.NET del encryption padding proporciona información en las respuestas de error que puede utilizar alguien malintencionado para atacar al sistema. Repararemos esta vulnerabilidad en la actualización de seguridad.
¿Esto afecta tanto a los formularios Web Forms de ASP.NET como a MVC de ASP.NET?
Sí, la explotación que se reveló públicamente se puede utilizar contra todos los tipos de Aplicaciones ASP.NET (incluyendo tanto formularios Web Forms como MVC).
¿Esto afecta a SharePoint?
Sí, la explotación que se reveló públicamente también se puede utilizar contra SharePoint 2010. El equipo de SharePoint recientemente publicó un artículo en su blog que describe una solución temporal que usted puede aplicar hasta que liberemos la actualización de seguridad.
¿Cómo se vería un ataque en la red o en mis registros?
La explotación que se reveló públicamente provocaría que el servidor Web generara miles (o probablemente docenas de miles) de respuestas de error HTTP 500 y 404 a las solicitudes de un cliente malintencionado.
Usted puede utilizar filtros de control de estado en su firewall o sistemas de detección de intrusiones en su red para detectar dichos patrones y bloquear tales clientes. El módulo Restricciones dinámicas de IP respaldadas por IIS 7 también se pueden utilizar para bloquear estos tipos de ataques.
Un intento de ataque como éste también debe generar miles de alertas en el registro de eventos de la aplicación de su servidor similar a:
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 11/11/1111 11:11:11 AM
Application information:
Application domain: c1db5830-1-129291000036654651
Application Virtual Path: /
Exception information:
Exception type: CryptographicException
Exception message: Padding is invalid and cannot be removed.
Es importante resaltar que también pueden haber razones no asociadas con ataques para ver este tipo de errores (incluyendo los casos en los que se tengan llaves no concordantes –mismatching keys- en una granja Web, o en los casos en los que un motor de búsqueda siga vínculos de forma incorrecta, etc.), de manera que la presencia de este tipo de errores no indica necesariamente un ataque.
La excepción tampoco implica que el ataque haya sido exitoso. La implementación de la solución temporal <customErrors> que proporcionamos puede proteger su aplicación contra la explotación, y garantizará que estas excepciones no divulguen información que el atacante pueda utilizar contra la aplicación.
¿Qué hace la solución temporal <customErrors>?
La solución temporal descrita anteriormente en este mismo artículo puede ser utilizada para proteger su aplicación contra la explotación al habilitar la característica <customErrors> de ASP.NET, y configurar explícitamente sus aplicaciones para siempre devolver la misma respuesta de error, sin importar el error que se encuentre en el servidor. Al redireccionar todas las páginas de error a una página de error única, usted puede dificultar que un atacante utilice la explotación para distinguir entre los diferentes tipos de errores que ocurren en un servidor.
Si usted utiliza .NET Framework versión 3.5 SP1 o 4.0, la solución temporal ofrece mayor protección al ayudar también a mitigar los ataques potenciales asociados a análisis de tiempo. La solución temporal utiliza la opción redirectMode="ResponseRewrite" en la característica customErrors e introduce un retraso aleatorio en la página de error. Estas dos soluciones trabajan juntas para dificultar que un atacante deduzca el tipo de error que ocurrió en el servidor al medir el tiempo que tomó recibir el error.
¿Puedo configurar una respuesta personalizada de la página de error 404 y una redirección predeterminada para el resto de los errores?
No. Al hacer esto usted sigue permitiendo que el atacante pueda distinguir entre un error 404 y otros tipos de errores. Lo homogenización de los errores es un componente crucial para mitigar este ataque. Observe que ésta es una solución temporal hasta que haya disponible una actualización de seguridad para reparar la vulnerabilidad del producto subyacente. Esta solución temporal no se requerirá una vez que liberemos la actualización de seguridad.
¿Soy vulnerable si tengo mi propio módulo de error personalizado?
Si las respuestas que se envían desde el módulo de registro personalizado no permiten que el cliente distinga entre las respuestas de error ya sea a través de su contenido, o el tiempo que toma para enviarlas, entonces dicho módulo es un reemplazo adecuado para la solución temporal de customErrors. Estas respuestas incluyen tanto la respuesta HTTP completa como el código de error HTTP. Si algo de lo anterior no se cumple en todo momento, entonces su solución no es suficiente. En su lugar usted debe enviar la misma respuesta de error para todos los errores hasta que la actualización de seguridad esté disponible para reparar la vulnerabilidad subyacente.
¿Me debo preocupar acerca de la vulnerabilidad si no almaceno ninguna información confidencial en mi estado de vista?
Sí, debe hacerlo. Hay una combinación de ataques que se demostró públicamente que pueden permitir fugas del contenido de su archivo web.config, incluyendo cualquier información confidencial no cifrada del archivo. Usted debe aplicar la solución temporal para bloquear el ataque de padding oracle en su etapa inicial del ataque. La actualización de seguridad reparará esta vulnerabilidad.
¿Cuáles son las mejores prácticas para proteger mis datos dentro del archivo web.config?
Siempre es una buena práctica cifrar los datos de configuración confidenciales dentro de los archivos web.config. De esa manera si su archivo web.config alguna vez queda expuesto, los atacantes no pueden utilizar su contenido. Esta documentación de MSDN describe cómo cifrar las secciones de configuración del archivo web.config: https://msdn. microsoft.com/en-us/library/zhhddkxy(VS.80).aspx. Este tutorial también ofrece más muestras de cómo cifrar el contenido del archivo web.config: https://www.4guysfromrolla.com/articles/021506-1.aspx
¿Por qué recibo un error cuando ejecuto la secuencia de comandos .vbs de detección de vulnerabilidades?
Al principio de éste artículo se indicó una secuencia de comandos .vbs que usted puede ejecutar contra un servidor para identificar cualquier aplicación dentro de él que necesite actualizar sus secciones <customErrors> como una solución temporal contra la explosión que se reveló públicamente.
En IIS 7, la secuencia de comandos requiere que usted instale la característica de compatibilidad de administración de IIS 6 para poder utilizar esta secuencia de comandos. Para habilitar esta característica, ejecute Agregar/Quitar programas en la estaciones de trabajo y Agregue los servicios del rol del servidor Web en los sistemas operativos de servidor, y seleccione la característica IIS 6.0 Management Compatibility dentro del área de características “Internet Information Services”. Si esta característica ya está instalada, por favor asegúrese de ejecutar la secuencia de comandos con los privilegios de administrador.
Cómo encontrar más información acerca de esta vulnerabilidad
Usted puede conocer más acerca de esta vulnerabilidad en:
- Documento informativo de Seguridad 2416728 de Microsoft
- Artículo sobre Cómo entender la vulnerabilidad de ASP.NET del blog de SR&D de Microsoft
- Artículo sobre la vulnerabilidad en el blog del Centro de respuesta de seguridad de Microsoft (MSRC)
- Artículo sobre la vulnerabilidad en Blog del equipo de SharePoint
Foro para preguntas
Establecimos un foro dedicado en el sitio www.asp.net para ayudar a responder preguntas acerca de esta vulnerabilidad.
Formule sus preguntas aquí para obtener ayuda acerca de esta vulnerabilidad.
Resumen
Publicaremos más detalles conforme aprendamos más, y liberaremos una revisión que se pueda utilizar para corregir la causa raíz del problema (y evitar la necesidad de la solución temporal anterior).
Hasta entonces, por favor aplique la solución temporal anterior a todas sus aplicaciones ASP.NET para impedir que los atacantes las exploten.
***Esta información fué tomada del artículo publicado en el Blog de Scott Guthrie aqui y de su sección de preguntas frecuentes aqui ***
Saludos,
Roberto Arbeláez
Security Program Manager for Latin America
CSS Security
Microsoft Corp.
del.icio.us Tags: Microsoft,seguridad,ASP.NET,vulnerabilidad,2416728
Technorati Tags: Microsoft,seguridad,ASP.NET,vulnerabilidad,2416728