[Actualización 28/09/2010] FINAL
Actualización de seguridad Microsoft Security Bulletin MS10-070 – Important Asi que a descargar…. Primeramente mediante Microsoft Download Center (forma manual), o puedes (si quieres) esperar unos días y estará entre nosotros por Windows Update /Windows Server Update Service.
[Actualización 24/09/2010]
Se actualizo la solución provisoria en el aviso de seguridad Microsoft Security Advisory (2416728) para agregar un filtro mas de “protección” para este caso especifico que lee los mensajes de error de nuestra aplicación. La idea es implementar el filtro de URL para no permitir peticiones con “aspxerrorpath=” en el IIS, aquí podremos utilizar Request Filtering o URLScan (leer mas abajo la Tarea 2)
[Actualización 21/09/2010]
Doy enlace a un post de Sergio Tarrillo donde da un timeline de los últimos días y un ejemplo de aplicar la solución provisional: Reciente vulnerabilidad de ASP.NET y BlogEngine.Net
[Actualización 20/09/2010]
Doy enlace al post de Alberto Diaz donde aplica la solución provisional en SP 2010: SharePoint 2010. Vulnerabilidad 0 days de ASP.NET.
Donde en los comentarios nos da el enlace al blog de Sharepoint: Security Advisory 2416728 (Vulnerability in ASP.NET) and SharePoint.
[Actualización 19/09/2010]
Doy enlace a un post de David Salgado donde da su punto de vista (el cual comparto): El 0 day de asp.net… modo de evitarlo? y referencias
Mas de uno ya se habrá enterado pero ayer se presento en una conferencia esta vulnerabilidad (ekoparty), yo por mi parte lo encontré por un comentario de un amigo en el trabajo cuando hace dos días me envió un articulo, así que lo venia siguiendo.
Que me llevo ver los resultados de la Conferencia de Seguridad ekoparty http://www.ekoparty.org/ que presentaron el tema
La vulnerabilidad fue publicada luego de presentarse:
Y como lo comenta Scott Guthrie… , It’s important (el tiene su blog mas información). También publicó unas preguntas frecuentes
Cuando se publica la vulnerabilidad tenemos unas “soluciones de compromiso/provisionales” y también unas herramientas para que los responsables de infraestructura pueda escudriñar los sitios del IIS de un server y detectar posibles configuraciones débiles
Problema
Ayer a la tarde en la conferencia se expuso una vulnerabilidad de ASP.NET para todas las versiones de ASP.NET(desde la 1.1 a la 4.0) para todos los sistemas operativos:
“Un atacante que aprovechara esta vulnerabilidad podría ver los datos, como el estado de vista, que fue cifrado por el servidor de destino, o leer datos de archivos en el servidor de destino, como el web.config…”
Como hablamos con Lautaro, si el web.config encima tiene datos sensibles (acuérdense que se puede encriptar la cadena de conexión) estamos en graves problemas.
Mas Técnico:
Solución (provisional)
[Actualización 28/09/2010] FINAL
Ya esta la solución final (un parche de seguridad) leer aquí Microsoft Security Bulletin MS10-070 – Important
No es necesario aplicar las “soluciones provisionales” una vez aplicado la solución final
A las horas… se publicó “la contra oferta”, (para salir del paso como se diría) básicamente es:
“Habilitar los errores ASP.NET personalizado y mapear todos los códigos de error a la misma pagina de error”
Pero también utilizar una página de error “con un poco de código” (miren el enlace de Secuity Advisor) donde establece un timeout
Dos tareas a realizar “provisionalmente” para nuestra protección [Actualización 24/09/2010]
- [En la App Web] Habilitar los errores ASP.NET personalizado y mapear todos los códigos de error a la misma pagina de error (independientemente del error detectado)
- [En el Servidor IIS] Bloqueo de los request que especifican la ruta de error. Es decir no permitir “aspxerrorpath=” en el querystring
La solución final se desplegara mediante Windows Update, así que a estar atentos. Cuando vea la luz la solución final, estos “filtros de protección” ya no lo debemos aplicar.
TAREA 1: Habilitar los errores ASP.NET personalizado y mapear todos los códigos de error a la misma pagina de error
Ejemplos:
- ASP.NET 3.5 o anterior…
<location allowOverride="false">
<system.web>
<customErrors mode="On" defaultRedirect="~/error.html" />
</system.web>
</location>
- En ASP.NET 3.5 SP1 o superior (NET 4.0)
<location allowOverride="false">
<system.web>
<customErrors mode="On" redirectMode="ResponseRewrite" defaultRedirect="~/ErrorPage.aspx" />
</system.web>
</location>
Como comenta Scott en su blog, también es recomendable un “delay” en la pagina de error
Ejemplo:
<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>
TAREA 2: Bloqueo de los request que especifican la ruta de error (aspxerrorpath)
Aquí tenemos dos alternativas,
Opcion A) Request filtering
Si estamos en Windows Vista Service Pack 2, Windows Server 2008 Service Pack 2, Windows 7, Windows Server 2008 R2.
Podremos utilizar un característica del IIS 7 Request Filtering
| Windows 7 |
Windows 2008 |
Activando una característica…
 |
Agregando un rol…
 |
Una vez instalado debemos ir a denegar: aspxerrorpath=
Por linea de comando utilizando AppCmd
appcmd set config /section:requestfiltering /+denyQueryStringSequences.[sequence=’aspxerrorpath=’]
Opcion B) URLScan
Aqui utilizaremos URLScan para filtrar las peticiones en nuestros IIS (versiones 5.1/6/7)
Hay que modificar la el archivo UrlScan.ini (%windir%system32inetsrvurlscan) y en la linea bajo [DenyQueryStringSequences] agregar:
aspxerrorpath=
Nos quedaría:
[DenyQueryStringSequences]
aspxerrorpath=
Herramienta (Script) para detectar las aplicaciones vulnerables
Para comenzar a fixear, ejecute la herramienta (es un script) que nos informa en un servidor ”las web con la vulnerabilidad a flor de pecho”, que los responsables de infraestructura pueden ejecutar en un server y verificar todas las web del IIS.
Espero que les sirva de ayuda o guía,… o a modo informativo.
Enlaces
y profesionales del 
