ASP.NET – Parches navideños

Ya estamos llegando al final del 2011 y Microsoft parece celebrarlo con un puñado de inusuales parches navideños. Esta entrega es importante no porque las vulnerabilidades afectan directamente a una enorme cantidad de usuarios y su actividad online en portátiles Windows, tabletas y estaciones de trabajo, sino porque ASP.NET mantiene un código vulnerable que permite lanzar fácilmente ataques DoS contra sitios web de alojamiento, la autenticación de técnicas de evasión, y los desvíos furtivos hacia otros sitios web (los más peligrosos hacia sitios phishing y sitios que alojan exploits tipo client-side y spyware). Sin duda todo esto provoca escalofríos.

¿ASP.NET?¿A quién le importa? Con toda seguridad que a Microsoft y a los clientes de su sitio IIS. Con la gran cantidad de ataques distribuidos DDoS (denegación de servicio) que provienen no sólo de chantajistas y de otros sitios competidores, sino también de enormes cantidades de actividades de intercepción de titulares de noticias por parte de grupos hacktivistas, el “recientemente revelado” virus para colapsar tablas hash es importante para los operadores del sitio IIS que quieran permanecer funcionales.

Se ha descrito este parche como uno de “emergencia”. Pero las actividades de los investigadores en este sentido datan de finales de noviembre (29 de noviembre) para Microsoft y del 1 de noviembre para otras marcas como PHP, Google, Oracle, Python, Ruby, etc. Quizás la ventana de descubrimiento de uno o dos meses ofrezca algunas pistas sobre la cantidad de tiempo que les toma a estas marcas arreglar vulnerabilidades bien conocidas. También resulta curioso en esta emergencia que sean Larry Wall y su equipo de Perl quienes re-desarrollaron los algoritmos de su tabla hash hace tiempo, asegurándose de que su código no sea vulnerable a estos ataques. Su trabajo fue realizado por completo en fuente abierta, y los desarrolladores de PHP 4 y 5, Java, Apache Tomcat, Apache Geronimo, Jetty, Oracle, Glassfish, ASP.NET, Python, Plone, CRuby 1.8, JRuby, Rubinius, y v8 no parecen haberlo notado ni realizado otras compensaciones ya que su código es completamente vulnerable. Una sencilla petición enviada a servidores que ejecutan uno de estos sistemas podría colapsar el 100% del CPU por varios minutos, provocando la caída del sitio. Por supuesto que felicitamos a los chicos de Microsoft por reaccionar rápidamente y resolver este problema en medio de las celebraciones navideñas. Esperamos que las otras marcas también puedan reaccionar con la misma rapidez; parece ser un problema persistente.

También están presentes en el escenario otras tres vulnerabilidades notificadas en privado, que pueden no haber tenido el mismo efecto mediático que los ataques DoS porque no fueron expuestas al público. La peor de las tres es quizás la de elevación de privilegio (EoP), conocida como la “evasora de formularios de autenticación de ASP.NET”. (Resulta difícil decir cuál de las vulnerabilidades es la peor, pero Microsoft clasifica esta como “crítica” mientras que la vulnerabilidad DoS se clasifica como “Importante”). Al atacante se le pide que registre una cuenta en el servidor y luego que apunte la cuenta de un usuario cuyo nombre conoce, algo que en la mayoría de los sitios web que he visto, no es un obstáculo infranqueable en absoluto. Desde ahí, el atacante puede enviar una petición y asumir el contexto de la cuenta del usuario atacada en el servidor web; en ese momento, tiene las llaves de todas las puertas. Parece que la urgencia de este conjunto de parches se debe a que es una vulnerabilidad crítica. El momento del lanzamiento de estos parches es inusual, considerando que Microsoft informa que ninguno de ellos se está usando en los ataques que detectaron. Pero, bueno, si los parches están listos, ¿por qué no publicarlos todos de una vez, en lugar de esperar por otro ciclo? El momento de su publicación es quizás una señal de madurez en el desarrollo e implementación de procesos.

Las otras dos vulnerabilidades son una EoP y una muy inusual que permite que el atacante desvíe a los usuarios desde sitios web vulnerables (que pueden ser muy, muy populares) hacia sitios web maliciosos de su elección. Aunque no hemos detectado extraordinarios volúmenes de desvíos desde sitios web legítimos y reconocidos hacia sitios maliciosos Blackhole o sitios phishing, es algo que estamos vigilando en este momento.