Cómo y cuándo se ataca a Microsoft: análisis de vulnerabilidades

lunes, 7 de julio de 2014

Microsoft ha publicado un par de artículos muy interesantes en su blog de seguridad, donde se desgrana qué tipo de fallos de seguridad son los más atacados y cuándo se ha descubierto un exploit para ellos. Pretenden dejar claro que han mejorado (y es cierto), pero veamos algunos detalles que no mencionan y reflexiones derivadas de la evolución mostrada en los últimos años.

Lo primero, ha sido estudiar las causas de las vulnerabilidades más graves (las de ejecución de código) en su software desde 2006 a 2013. Según la raíz del problema, la vulnerabilidad será más o menos difícil de explotar por un atacante, aunque todas concluyan con la posibilidad de controlar del sistema. Es un estudio interesante porque:

  • Se centra en vulnerabilidades graves y explotables. Nada de números camuflados entre las "no explotables" o la gravedad.
  • No se compara más que con sus propios productos.
  • Las vulnerabilidades estudiadas no se encuentran contaminadas por el comportamiento del usuario. En este caso no importa qué haga ni qué ejecute (tan solo un poco qué visite, quizás, pero no parece relevante).

El estudio se resume en esta gráfica.

Causa de las vulnerabilidades de ejecución de código en Microsoft desde 2006

Lo primero que se observa es un descenso pronunciado de los desbordamientos de pila clásicos. Estas son las más sencillas de explotar por un atacante... y detectar por el equipo de programación. Es cierto, Microsoft ha librado una lucha contra este tipo de fallo y al pensar en la seguridad desde el diseño, ha prohibido el uso de técnicas de programación que puedan derivar en este tipo de desbordamiento y de librerías de C que se sabían inseguras. Incluso incorporan un "banned.h" para que el compilador avise directamente. Parece que da resultado...

Pero nada desaparece sin que lo sustituya otra técnica, puesto que los niveles de explotación se mantienen. Use-after-free es un fallo más complejo de detectar programando, y por eso Microsoft no puede detenerlo tan fácilmente. Si los atacantes no encuentran desbordamientos de pila, acuden a este fallo de manejo de objetos que puede derivar en ejecución de código. Además, da la "casualidad" de que este tipo de vulnerabilidades se encuentra más en los programas "cliente" y en concreto en el navegador, que es el tótem preferido por los exploiters: ejecución de código en IE implica tener el control del cliente con solo visitar una web.

Los exploits que evitaban la carga de DLL desde otras rutas fue una moda desde que se detectó el método, pero era fácil de corregir y dos años después ya casi no se encuentran programas que lo lo permitan (al principio la lista fue interminable, tanto de Microsoft como de otros). El desbordamiento de heap, más difícil de detectar en tiempo de programación (y de explotar), se mantiene invariable en estos años.

¿Han descendido las vulnerabilidades?

Una de los métodos que tiene Microsoft para luchar contra las vulnerabilidades de ejecución de código son DEP y ASLR, introducidos en Vista en 2006. Son las armas implementadas de forma predeterminada para amedrentar a los exploiters. Pero no tanto. La aparición de ROP, las fugas de direcciones de memoria, o el uso de librerías que no son compatibles con ASLR ha permitido a los atacantes seguir sacando provecho de estas vulnerabilidades. Pero aunque el el statu quo se ha mantenido, "huyendo" a otros tipos de vulnerabilidad o con la aparición de métodos nuevos... parece que según Microsoft, el número de vulnerabilidades de ejecución de código explotadas ha descendido un 70% en los últimos tres años en el software de la compañía. Este gráfico así lo muestra:

¿Cuándo se ha detectado un exploit para una vulnerabilidad de ejecución de código en Microsoft?
Esta imagen explica que, de las 20 vulnerabilidades que fueron explotadas en 2013 en sus productos, 13 se descubrieron siendo explotadas en forma de 0-day. 6 vulnerabilidades se descubrieron siendo explotadas durante los 30 días siguientes al anuncio del fallo, y solo una más tarde. Y, aunque en Microsoft destaquen sus bondades y la interpretación de estadísticas y barras se preste a todo tipo de argucias argumentales, este gráfico es muy curioso por varias razones. Algunas que consideramos relevantes.

¿Qué se deduce del gráfico?

  • En los titulares, Microsoft habla de la caída de vulnerabilidades desde 2010, pero no de la subida desorbitada hasta ese año, ni sus razones. ¿Por qué esa explosión de un año a otro? En 2010, con IE8 y Windows ya en el mercado, el número de vulnerabilidades se dispara... fue un año convulso en Microsoft, y también para los atacantes. La creación de exploits les costó más esfuerzo (muchos más se crearon dentro de los 30 días posteriores al anuncio de la vulnerabilidad). Quizás sea porque estaban naciendo las nuevas técnicas para eludir DEP y ASLR, ya implantados con Windows 7, que se introducía en el mercado en ese momento y al que necesitaban llegar los atacantes. O también cabe otra teoría. ¿Puede ser que muchas de esas vulnerabilidades fueran encontradas por la propia Microsoft y luego los exploiters crearan el ataque? Esto en realidad sería positivo, una especie de "cura" interna por parte de la compañía para eliminar puntos débiles.
  • Si se habla desde 2006 es porque fue cuando se introdujo Vista, el primer sistema operativo con medidas de seguridad reales de serie... Si miramos de nuevo el gráfico, vemos que el número de vulnerabilidades de ejecución de código para las que se ha encontrado exploit, no ha variado sustancialmente desde 2006. Quizás, tras la desaparición de XP y la introducción de mejoras sustanciales de seguridad en el sistema, se podría esperar una caída más pronunciada en los exploits contra Microsoft... pero no parece que sea el caso. Como decíamos, el statu quo se mantiene. Las defensas mejoran pero los ataques son más sofisticados.
  • Echamos de menos una aclaración sobre a qué software se refieren exactamente en las gráficas. Pero aunque no lo mencionen, sí es cierto que el número de vulnerabilidades de ejecución remota de código explotadas en programas servidor de Microsoft (Exchange, MSSQL, IIS, etc) es casi anecdótico desde hace años.
  • El número de vulnerabilidades descubiertas en forma de 0-day (siendo explotadas) no ha descendido en absoluto desde 2006. Son las más peligrosas y las que más daño causan a los usuarios.
  • En 2013, los exploits posteriores a los 30 días ya no tienen apenas presencia. No sirven a los atacantes. Y aquí quizás entra en juego el parcheo rápido y automático de Windows, que tanto bien ha proporcionado a los usuarios.
  • Se nota un descenso pronunciado a partir de 2012 del número de vulnerabilidades. ¿Microsoft ha mejorado o es que ya no suponían mucho interés para los atacantes? Un poco de todo. Recordemos que a partir de 2012 ocurrió algo muy interesante en el mundo de la seguridad: Java y sus fallos. Un auténtico caos que, hasta 2013, lo dominó todo (Oracle fue objeto de mofa durante dos años). Lo más sencillo para los atacantes era crear exploits triviales para Java y conseguir resultados óptimos. Solo hace falta ver el gráfico más abajo para comprender qué ocurrió en 2013. Entonces, desde el punto de vista de los atacantes ¿para qué analizar tanto el software de Microsoft (que además se hace más complicado cada vez) si se dispone de Java para mantener los niveles de infección y poder explotar? Ya sabemos que la correlación no implica causalidad, pero puede ser una teoría interesante. Habría que ver qué ocurre durante este año y el próximo para confirmar.

Fuente: Kaspersky

Pero en resumen, no se puede decir que Microsoft no haya mejorado. Es un hecho que explotar IE es ahora mucho más "caro" para un atacante, entre otras razones. Un detalle que mencionan, casi de pasada, es que aunque el número de 0-day en 2006 es parecido a los de 2013, no son de la misma "naturaleza": una buena parte se han encontrado atacando a objetivos muy específicos, es decir, hablamos de ciber-guerra. A medida que un 0-day tiene más valor, los atacantes no lo "malgastan" en el usuario medio... lo aprovechan para usos más "lucrativos" y potentes.

Sergio de los Santos
ssantos@11paths.com

No hay comentarios:

Publicar un comentario en la entrada