04 octubre 2010

Explotación de Windows, pasado, presente y futuro - 2/3

Continuamos con esta serie de artículos, y nos metemos en el año 2000. Empezamos con Windows 2000, a partir del cual vienen cosas muy interesantes.

Podríamos llamar a esta época la edad de oro de los desarrolladores de exploits ya que, desgraciadamente, Microsoft olvidó implementar una protección contra buffer overflow en sus sistemas. Los ataques clásicos funcionaban genial, y vemos en muy contadas ocasiones vulnerabilidades complejas, aunque la explotación en sí no era complicada.

Debido a estas pobres protecciones nos encontramos con virus (gusanos) de los que se habló bastante en su momento, y tuvieron una fuerte repercusión.

Por ejemplo, el gusano Sasser, que explotaba un fallo en LSASS; SQL Slammer, que utilizaba otro fallo en SQL Server; u el conocidísimo Blaster que explotaba un fallo en el servicio DCOM RPC, y además incluía un mensaje dedicado:
billy gates why do you make this possible ? Stop making money
and fix your software!!

También tenemos exploits clásicos y muy funcionales:
  • DCOM RCP exploit por flashsky (de xfocus).
  • MS Windows (RPC DCOM) exploit por HD Moore (Metasploit).
  • Kill Bill exploit por Alexander Sotirov.
  • MS Windows Plug-and-Play exploit por houseofdabus.

Además nos encontramos con algunas herramientas gráficas, como el conocido SMBdie que podía producir un cuelgue inmediato en cualquier sistema vulnerable.

Acerca de stack overflows clásicos hay algunos papers muy buenos y muy bien documentados:

También tenemos algunos sobre heap overflows clásicos:

Si cambiamos de área, hay un extenso trabajo en cuanto a vulnerabilidades basadas en el propio kernel de Windows (ya no tan clásicas):

Después de todo esto, volvemos al área de trabajo del usuario con ¡protecciones de memoria!

Debido a todos los abusos del sistema que hemos visto antes (tanto gusanos, como ténicas de explotación), Microsoft decide implementar protecciones de memoria. A partir de Windows XP SP2 (Windows XP Tablet PC Edition 2005), Windows Server 2003 SP1 (nivel de SO) y Visual Studio 2003 (nivel de compilador) estas protecciones empiezan a ser utilizadas.

Vamos a ver un resumen de ellas:
DEP (Data Execution Prevention), una medida implementada en los sistemas modernos de Microsoft que está pensada para evitar que las aplicaciones ejecuten código de una región de memoria no ejecutable. Ayuda a prevenir algunos exploits que almacenan código gracias a, por ejemplo, un buffer overflow. Puede ser implementada mediante hardware (CPUs que permiten marcar páginas de memoria como no ejecutables) o vía software (para CPUs que no tienen soporte). Más información sobre DEP aquí.

/GS (Buffer Security Check), es una opción de compilación añadida desde Visual Studio 2003 para prevenir buffer overruns que sobreescriben la dirección de retorno. La protección se basa en poner una cookie entre el buffer y la dirección de retorno, de forma que si se sobreescribe esta cookie la comprobación falle y se termine el proceso. Información más detallada aquí.

/SAFESEH (Image has Safe Exception Handlers), otra opción de compilación añadida en Visual Studio 2005. Información detallada aquí.

ASLR (Address Space Layout Randomization), implementado en Windows Vista, Server 2008 y Windows 7. Se basa en hacer aleatorias las direcciones clave de la memoria (ejecutables, DLLs, heap, stack), de forma que nunca sean las mismas. Hay mucha información sobre esta medida, teneis más aquí y aquí.

SEHOP, usado en los sistemas Windows más modernos (como 2008 y 7). La idea detrás de esta medida viene del artículo de Matt Miller, Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP.

Heap Protections, Microsoft también ha introducido algunas protecciones nuevas de heap, como heap meta cookie, safe unlinking ...

Por último, se me hace difícil terminar esta parte sin hacer referencia a EMET (ya en su versión 2.0), un toolkit del cual Fermín J.Serna (@fjserna) tiene cierta culpa y que permite a los usuarios implementar estas tecnologías en aplicaciones arbitrarias (especialmente de terceros), lo que ayuda a evitar que sean explotadas. Podeis ver la presentación que hizo Fermín en la RootedCON 2010 sobre el toolkit aquí, y aquí un ejemplo de como EMET 2.0 puede bloquear un exploit para Adobe Reader.

Dentro de poco la tercera y última entrega, donde veremos la respuesta de los investigadores de seguridad a estas protecciones, e intentaremos hacer una predicción de lo que nos espera en este campo de la seguridad.

Parte 1
Parte 2
Parte 3

3 comments :

Newlog dijo...

Muy buena entrada Alberto!

Ya tenía ganas de la segunda parte, y espero que la tercera no se haga esperar. Imagino que la reservaréis para el próximo lunes? Para empezar bien la semana, no?

Venga!

aran dijo...

Muy buena entrada!

alguien sabe que tecnica utilizan los ultimos zeus para ejecutar el codigo malicioso atravez de procesos del sistema como el explorer.exe, dwm.exe y el taskhost.exe?

un saludo

Ruben dijo...

mola!