| Artículos | 01 MAR 2007

Test de intrusión (II)

Tags: Histórico
Chema Alonso.
El mes pasado vimos cómo funcionaban las técnicas de footprinting y fingerprinting, además de algunas herramientas como Google Hacking Database, nmap o hping2 (ya está disponible hping3). A lo largo de esta entrega vamos a centrarnos en la búsqueda de vulnerabilidades.

Después de saber cuáles son los sistemas operativos, firewalls y/o puertos abiertos (lo que vimos en la pasada entrega), es necesario descubrir las versiones de software que corren por esos servicios. Lo primero es tratar de ver la información que se nos ofrece abiertamente. Para ello, basta con realizar una conexión y recoger el banner del mismo servicio. El mes pasado vimos cómo contestaba un servidor web, pero esto se puede realizar con servicios FTP, SMTP o Listeners de Bases de Datos.
En el caso de no poder afinar con el banner, con la inferencia de cruzar el sistema operativo o el puerto utilizado para identificar la versión, tendremos que utilizar herramientas de fingerprinting de servicio. La mayoría de los scanner de vulnerabilidades (los veremos con más detenimiento en la tercera entrega) 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 intrínseca del software a través de la cual, es posible que un programa funcione incorrectamente o de manera inesperada. En el argot de los hackers lo definen 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.
Llegar a conseguir que un software no tenga bugs es muy complicado, 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 o linkadores, entre otros.
En la búsqueda de bugs se utilizan dos aproximaciones distintas, que pueden realizarse tanto manualmente como con ojos expertos.

Herramientas de Análisis Estático de Código
Este tipo de herramientas mantienen una base de datos de patrones clasificados como fallos de seguridad, como, por ejemplo, copia de parámetros con la función strcopy sin comprobar tamaños. Estas herramientas realizan una búsqueda de esos parámetros en el código de un programa cuando no está en tiempo de ejecución. 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, o C++, entre otros, 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, por ejemplo, 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, se 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.
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 FxCod en Vistual Studio que comprueba desbordamientos de buffer, condiciones de carrera, y demás.

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. Una herramienta de este tipo debe ser capaz de evaluar todas las posibilidades desde todos los puntos de entrada de información y cualquier punto externo hacia la aplicación, además de 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
Ésta es una herramienta básica en la tarea de realizar un test de intrusión en una compañía. Es un entorno que combina una base de datos de cabeceras de exploits y de payloads para poder realizar el test en unos determinados servidores. Actualmente, la versión 3.0 beta 3 tiene un actualizador automático de las bases de datos y herramienta de administración web.

0 days, o ataques de día cero
El término “0-days” se va a repetir mucho en las auditorías de seguridad. Exploit de 0-days es el término que indica la aparición de una cierta vulnerabilidad para la que todavía no hay solución. El aprovechamiento de las vulnerabilidades de día cero es especialmente crítico, ya que, como no existe ningún tipo de solución, es relativamente sencillo explotarlas. El principal problema es que, para protegerse, es necesario realizar tareas preventivas de configuración manual, por lo que muchas empresas permanecen vulnerables hasta que se publica la solución en forma de actualización a través de los canales habituales. No obstante, consideramos necesario hacer constar la diferencia entre un servidor en 0-days y un exploit de 0-days:

- 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, tomar 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 t

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información