Test de Intrusión (III de VI)

****************************************************************************************
Artículo Publicado en PCWorld Abril 2007
- Test de intrusión [I de VI]
- Test de intrusión [II de VI]
- Test de intrusión [III de VI]
- Test de intrusión [IV de VI]
- Test de intrusión [V de VI]
- Test de intrusión [VI de VI]
****************************************************************************************

El mes pasado vimos como funcionaban las técnicas de footprinting y fingerprinting y vimos algunas herramientas como la google hacking database, los traceares, nmap o hping2 (ya está disponible hping3). Ahora vamos a centrarnos en la búsqueda de vulnerabilidades.

Identificación de Servicios y Software

Una vez que sabemos cuales son los sistemas operativos, firewalls y/o puertos abiertos es necesario descubrir las versiones de software que corren por esos servicios. Lo primero es intentar ver la información que se nos ofrece abiertamente. Para ello, suele bastar con realizar una conexión y recoger el banner del mismo servicio. El mes pasado vimos como contestaba un servidor web, pero esto se puede realizar con servicios FTP, SMTP o Listeners de Bases de Datos.

Imagen: Telnet a SMTP
Imagen: Telnet a FTP
En el caso de no poder afinar con el banner, con la inferencia de cruzar el sistema operativo, el puerto utilizado, etc…, para identificar la versión, tendremos que utilizar herramientas de fingerprinting de servicio. La mayoría de los escanners de vulnerabilidades (que vamos a ver en el tercer artículo) implementan estas técnicas para la mayoría de servicios. Una vez acotado el software, hay que buscarle los problemas.

Bug

El bug o fallo de seguridad es una característica de un software que puede hacer que el programa funcione incorrectamente o de manera no pensada. Muchos hackers definen bug como “funcionalidad no definida de un programa”. Entendemos como Software Fiable aquel que hace lo que tiene que hacer y como Software Seguro aquel que hace lo que tiene que hacer y nada más. Ese algo más entre el software fiable y el software seguro son los bugs.

El que un software no tenga bugs es muy complicado de conseguir, hay que tener en cuenta que un programa escrito en lenguaje C, compilado con dos compiladores distintos no genera el mismo código binario, luego un mismo código puede ser o no vulnerable dependiendo de compiladores, arquitecturas donde se ejecute, linkadores, etc..

En la búsqueda de bugs se utilizan dos aproximaciones distintas, que pueden realizarse manualmente y con ojos expertos, pero que se automatizan y que son las herramientas de análisis estático de código y análisis dinámico.

Herramientas de Análisis Estático de Código

Este tipo de herramientas mantienen una base de datos de patrones reconocidos como fallos de seguridad, como copia de parámetros con strcopy sin comprobar tamaños, etc… y lo que realizan es una búsquedas de esos parámetros en el código de un programa sin que este se esté ejecutando. Esta forma de escanear el código es lo que recibe el nombre de análisis estático. Estas herramientas pueden analizar códigos en ensamblador, desensamblados directamente del binario, o códigos fuente en lenguajes madre con .NET, C, php, C++, etc… o en códigos intermedios como Bytecodes o IL. La diferencia cualitativa entre estas herramientas es la base de datos de patrones que utilizan y la mayoría de las grandes casas de desarrollo de software consideran esto como un conocimiento competitivo y de valor de la compañía. Microsoft, desde el año 2002, utiliza herramientas propias de análisis de código estático en todos sus productos. En el mundo del software libre, a raíz del proyecto “bug hunting” financiado por el gobierno americano, utiliza a la compañía Coverity para realizar análisis estático de bugs en los principales proyectos de software libre desde Enero de 2006. Los informes con los primeros resultados de los análisis de Coverity están disponibles en http://scan.coverity.com

Existen múltiples herramientas de Análisis Estático de Código disponibles en la web, e incluso, muchos compiladores acompañan su entorno de desarrollo con herramientas de este tipo, como por ejemplo FxCop en Vistual Studio que comprueba desbordamientos de buffer, condiciones de carrera, etc…

Imagen: FxCop en Visual Studio
Proyecto Bug Hunting

En Enero del año 2006 comenzó, a instancias de una universidad y el gobierno Americano el proyecto Bug Hunting, cuyo objetivo era analizar los 50 proyectos Open Source más populares con las herramientas de Análisis Estático de Código de la empresa Coverity. Los resultados que aparecieron en Marzo de 2006 (un año para cuando salga publicado el artículo) están disponibles en la siguiente URL: http://scan.coverity.com. Se puede ver en la tabla, algunos de los resultados que se obtuvieron después de utilizar las herramientas de análisis estático.

Imagen: Resultados Coverity
Herramientas de Análisis dinámico

La búsqueda de bugs con herramientas de análisis dinámico tiene otra aproximación distinta. En este caso el programa a evaluar se ejecuta y se le pasan pruebas y verificaciones automáticas que van a evaluar las respuestas ante todo tipo de situaciones distintas. Una herramienta de este tipo debe ser capaz de evaluar todas las posibilidades de todos los puntos de entrada de información desde cualquier punto externo hacia la aplicación y detectar los casos anómalos.

Algunos ejemplos de herramientas de este tipo son Valgrind, pensada para detectar condiciones de carrera en entornos multihilo y errores de memoria, Dmalloc.h, que es una librería que se usa para comprobar las reservas de memoria o VB Watch que inyecta códigos de análisis dinámico dentro de los programas para monitorizar su funcionamiento.

Exploits

Una vez que se han encontrado los bugs, el objetivo es crear una herramienta que saque partido de ellos, es decir, que sea capaz de hacer uso de esa “funcionalidad no definida del programa”. Para ello, se analizan las posibilidades y alcance de ese bug y se opta por un determinado exploit. Todos los exploits tienen dos partes diferenciadas, la cabecera, que es lo que se denomina exploit puramente, y el cuerpo, denominado payload. La cabecera es la parte artesana que depende de cada bug en concreto, mientras que el payload son acciones ya programadas que se reutilizan. Por ejemplo, una acción típica de un exploit sería devolver una shell de comandos de la máquina explotada a un determinado puerto. Este payload se va a poder reutilizar para múltiples cabeceras distintas.

Metasploit Framework

Esta herramienta es una herramienta básica en la tarea de realizar un test de intrusión en una compañía. Es un entorno que aúna una base de datos de cabeceras de exploits y de payloads para poder realizar el test en unos determinados servidores. Actualmente en la versión 3.0 en beta 3 tiene un actualizador automático de las bases de datos y herramienta de administración web.

Imagen: Metasploit Update
En la siguiente imagen se puede ver como, mediante el interfaz web, podemos configurar los diferentes payloads para un exploit, en este caso, un exploit de Samba para Linux.

Imagen: Configuración de Payload para un Exploit de SAMBA en Linux
0 days

El término “0-days” se va a repetir mucho en las auditorías de seguridad:

- Un servidor en 0-days es aquel que tiene actualizado todo su software a las últimas versiones, es decir, que el software no tiene ningún bug conocido. Ese es el punto más seguro en que se puede tener el software de un servidor.

- Un exploit de 0-days es aquel que funciona en servidores 0-day, es decir, que actualmente no existe una versión de software más moderna para solucionar ese problema.

El objetivo de una auditoría de seguridad será obtener un servidor de 0-days y, si existiesen exploits de 0-days, tomad las medidas para que el software vulnerable no se vea expuesto. Es decir, bloqueando peticiones en firewalls, fortificando las restricciones en las máquinas o con políticas de seguridad en las directivas de seguridad de la red.

POC y Los Meses temáticos

Cuando se quiere realizar un completo test de intrusión en un servidor no valen solo las herramientas comerciales y las que nos ofrecen los fabricantes ya que hay mucha información que no sale por los canales comunes. Las llamadas Pruebas de Concepto (POC) actualmente son muchas de pago y es normal que se sepa que existe un exploit pero que no sea de uso público. Durante el año pasado H.D. Moore, uno de los principales contribuyentes al proyecto Metasploit, decidió realizar meses temáticos junto a otros investigadores de seguridad, orientados a buscar exploits 0-days en diferentes áreas. Así, durante el mes de Julio se centró en los navegadores de Internet, durante el mes de Noviembre en los kernels de los sistemas operativos, durante el mes de Enero en Apple y ya, Stefan Esser ha anunciado para el mes de marzo, el mes de los fallos en PHP. Habrá que estar atentos. En estos proyectos “temáticos” el objetivo es buscar un bug al día y hacerlo público. Esto, lógicamente, creo mucha controversia ya que los canales de información tradicionales son los de avisar al fabricante para que lo corrija sin que los clientes queden expuestos. Esta controversia llevó, a que se anunciara para la última semana del año 2006 la Semana de los fallos de Oracle Database, por parte de Cesar Cerrudo, un investigador de seguridad centrado en Bases de datos, pero, debido a la presión pública la cancelara.

Las POC pueden encontrarse en muchos sitios Web dedicados a la seguridad informática: FRSirt (http://www.frsirt.com), Milworm (http://www.milwOrm.com) o Packet Storm (http://packetstormsecurity.org/) son algunos de los más utilizados.

Imagen: Últimas POC remotas en MilwOrm
Los meses temáticos se pueden encontrar en las siguientes URLS:

- Mes de los fallos de los Navegadores: http://browserfun.blogspot.com/
- Mes de los fallos de los Kernels: http://kernelfun.blogspot.com/
- Mes de los fallos de Apple: http://applefun.blogspot.com/
- Mes de los fallos de PHP: http://blog.php-security.org/

Imagen: Últimos días en el mes de los fallos de Apple

****************************************************************************************
Artículo Publicado en PCWorld Abril 2007
- Test de intrusión [I de VI]
- Test de intrusión [II de VI]
- Test de intrusión [III de VI]
- Test de intrusión [IV de VI]
- Test de intrusión [V de VI]
- Test de intrusión [VI de VI]
****************************************************************************************