Test de Intrusión 2 parte

Expedientes de Seguridad

Cuando un bug es descubierto debe documentarse correctamente. Para ello cada fabricante de software suele mantener su propia forma de codificar los expedientes de seguridad, pero han surgido en Internet muchas empresas que se han dedicado a mantener sus propias bases de datos de expedientes de seguridad. El trabajo es arduo si pensamos en la cantidad de proyectos de software y lo rápido que se descubren nuevos bugs, con lo cual es imposible decir que una base de datos tiene todos los fallos conocidos. Lo que si está claro es que algunas se han convertido en un estándar de facto. Las dos bases de datos más utilizadas por la gente que se dedica a seguridad son Bugtraq de SecurityFocus [https://www.securityfocus.com/bid] y CVE (Common Vulnerabilities and Exposures) [https://cve.mitre.org/cve]. Ambas bases de datos codifican cada fallo con un identificador y a partir de ahí se analiza el software vulnerable, el software no vulnerable que podría ser susceptible de serlo por ser parte de la familia de productos o versiones, se discute sobre cual podría ser el alcance de dicho bug, si existe o no el exploit disponible para ese fallo y cual es la solución ofrecida por el fabricante. La ventaja de estas bases de datos, es que en cualquier momento se pueden consultar todos los expedientes de seguridad relativos a un determinado producto y versión para ver cuales son las soluciones a aplicar.

Como se puede ver en la imagen, los expedientes de seguridad almacenan los exploits asociados a estos fallos, luego, si el servidor tiene un fallo sin arreglar y el exploit es público nuestro servidor está en un claro riesgo, pero, aunque el exploit no sea público se deben aplicar las medidas de solución que recomiende el fabricante ya que, muchos exploits, debido a su importancia o impacto son de pago y puede que existan y estén circulando por Internet. Hay que recordar que los rumores hablan de precios desorbitados para exploits de productos populares o de alto nivel de criticidad. En la imagen se puede apreciar como security focus, relaciona su codificación con la codificación CVE.

Scanners de Explotación

Una de las herramientas que suelen aparecer justo después de que se haya hecho público el bug y el exploit asociado son scanners que implementan motores de búsqueda de servidores vulnerables a ese fallo y un mecanismo para ejecutar dicho exploit. Están preparados para lanzarlos de forma cómoda, ya que la mayoría de las veces se requiere hacer modificaciones en las POC para que estas funcionen en diferentes entornos, es decir, se requiere cierto nivel técnico para poder utilizarlos, mientras que con estas herramientas suele ser tan fácil como aplicar botones. Algunos ejemplos de estas herramientas en las siguientes capturas:Actualizaciones de Seguridad o Parches
La mayoría de las soluciones que se aplican a los fallos de seguridad del software suelen ser Actualizaciones de Seguridad o también llamados parches que nos ofrece el propio fabricante. Estos parches deben ser aplicados lo antes posible, tras haber realizado previamente las comprobaciones de que estos no afectan al funcionamiento normal de nuestra infraestructura por supuesto. La premura en la aplicación de los parches se debe a que en el momento en que se publica un parche se está acelerando la creación de los exploit. ¿Por qué? Pues porque el contar con el software sin parchear y con el software parcheado permite a los creadores de exploits realizar ingeniería inversa localizada. La idea es sencilla, se realiza una imagen del sistema sin parchear y luego otra imagen con el sistema parcheado, se comparan y se buscan las diferencias. Cuando se tienen localizados los ficheros modificados se realizan comparaciones de esos ficheros y mediante las técnicas de debugging, similares a las utilizadas para la creación cracks, se busca el punto de fallo en el programa. Digamos que publicar un parche es marcar el sitio del problema por lo que es muy importante actualizar lo antes posible. Esto ha hecho que ahora se hable de que el segundo martes de cada mes, día que Microsoft hace públicas sus actualizaciones de seguridad sea el día del parche y que el segundo miércoles de cada mes sea el día del exploit.Microsoft Baseline Security Analyzer
Lo primera herramienta que se debe utilizar para realizar una auditoría de caja blanca en mi organización es MBSA, que va a permitirnos comprobar si a algún equipo o servidor de nuestra organización le falta alguna actualización de seguridad. Esta herramienta es de Microsoft y por tanto solo nos va a comprobar las actualizaciones de seguridad de los productos Microsoft, por lo que si tenemos software de otras compañías, lo primero es ver como se distribuyen, se actualiza y se comprueba si nuestros productos tienen o no todas las actualizaciones de seguridad aplicadas.
Imagen: Microsoft Baseline Security Analyzer
MBSA no es solo una herramienta para buscar parches no instalados, sino que además es lo que denominamos una herramienta de Auditoría de caja blanca, porque nos va a recoger información sobre el sistema relativa a seguridad, desde la política de contraseñas, la configuración de seguridad del servidor Web o los servicios corriendo. Es de caja blanca porque exige la utilización de las credenciales de un usuario y es lo primero que se debe realizar en cualquier auditoría de seguridad de servidores Microsoft. Más información sobre MBSA en la siguiente URL: https://www.microsoft.com/technet/security/tools/mbsahome.mspx
En la misma línea que MBSA, Microsoft ofrece dos herramientas más, todas gratuitas, que son MS Exchange Best Practices Analyzer y MS SQL Server Best Practices Analyzer. Estas herramientas no se quedan solo en la configuración de seguridad sino que además ayudan a ajustar los servidores para poder aplicar medias de defensa en profundidad o ajuste del rendimiento. Si vamos a analizar la seguridad e un servidor los informes ofrecidos por estas herramientas son importantes y a tener muy en cuenta.
Los Escáneres de Vulnerabilidades
Este tipo de herramientas son la pieza principal cuando se va a realizar una auditoría de seguridad, tanto de caja blanca, como de caja negra. Engloban el conjunto de acciones necesarias para identificar las IPs activas, los puertos y servicios ofrecidos, la identificación del sistema operativo, el nivel de actualizaciones de seguridad aplicadas e incluso la detección y explotación de las vulnerabilidades encontradas. Dentro de los múltiples escáneres de vulnerabilidades los hay más o menos amigables, es decir, los hay que no ejecutan nunca la fase de intento de explotación de los fallos encontrados y otros que los prueban como forma normal de trabajo. Esto puede llevar a que la realización de una auditoría con un escáner poco "friendly" pueda "tumbar" algún servicio o servidor.
Si estas herramientas realizan todas las fases del proceso, ¿esto quiere decir que todas las herramientas anteriores no son necesarias? No, las herramientas anteriores son mucho más específicas en su función y permiten ser afinadas mucho más allá de lo que permitirá una escánner de vulnerabilidades completo.
Otra de las características de los escáneres de vulnerabilidades es que no son todos iguales, ni en la detección, ni en la evaluación de los riesgos, ni en la profundidad de los análisis, así que siempre es recomendable la utilización de, al menos, un par de ellos en un buen estudio.
Satán, Santa y Nessus
Aunque previamente habían aparecido muchos escáneres de una vulnerabilidad o un exploit, quizá el primer escáner de vulnerabilidades completo que se creo fue S.A.T.A.N. (Security Administrator Tool for Analyzing Networks). Su nombre creo mucha controversia así que realizaron apareció la versión SAINT "SANTA" (Security Administrator's Integrated Network Tool) que hoy en día se comercializa.
El relevo de estos lo cogió Nessus, apareciendo en el año 1998, de la mano de Renaud Deraison, la primera versión pública del producto. En su origen y hasta el año 2005 todas las versiones han salido bajo la licencia GPL, pero a finales del año 2005 anunció que la versión 3 sería gratuita pero no GPL. Las últimas versiones de Nessus se pueden obtener de la web https://www.nessus.org pero pertenecen a la empresa Tenable Network Security, la empresa que Renaud creo en el año 2002.
Nessus
Nessus es una de las herramientas preferidas por todos a la hora de realizar un test de penetración en una red debido a algunas de sus características.
- Actualización y funcionamiento mediante Plugins: Todos los escáneres de vulnerabilidades deben ofrecer un sistema de actualizaciones rápido para detectar las nuevas vulnerabilidades, que aparecen constantemente. En Nessus funciona mediante plugins, bajo demanda podemos actualizar la base de datos de conocimiento antes de cada ejecución para tener siempre actualizado el repositorio. Para hacer el sistema mucho más flexible en la creación de plugins y para poder ser alimentado con conocimiento propio podemos crear nuestros propios añadidos utilizando el lenguaje NASL (Nessus Attack Scripting Language).
Imagen: Detección de Plugins
Imagen: Actualización de Plugins
- Arquitectura cliente/servidor: El sistema está diseñado para funcionar desde distintos clientes contra distintos objetivos, así, Nessus corre como servicio en la máquina que desees y puede ser utilizado desde cualquier cliente. Esta arquitectura es independiente de plataforma y permite instalar, tanto los clientes como los servidores en arquitecturas Microsoft y *NIX. Esto va a permitir hacer esfuerzos económicos para tener un mejor servidor que va a ser productivo para muchos clientes. Además, los objetivos pueden ser casi de cualquier tipo ya que su base de conocimiento detecta vulnerabilidades en Servidores, clientes y dispositivos de red corriendo Windows, *NIX o MacOS.
Imagen: Configuración de Servicio Servidor
- Políticas de auditoría: Es importante que cualquier escáner de vulnerabilidades permita afinar la política a aplicar, poder elegir los servicios y las vulnerabilidades a auditar (no es lo mismo auditar un servidor de correo que un servidor FTP), que se integre con los distintos protocolos de comunicaciones (algunos escáneres tienen problemas con los protocolos SSL) y que se pueda decidir si queremos un escaneo amigable o uno hasta las últimas consecuencias, es decir, que pruebe todo aun asumiendo que podemos realizar una denegación de servicio en algunos servicios o en el sistema. Para ello en Nesuss, cuando creamos o editamos una política definiremos si queremos una Segura o no y después los plugings que queremos que pruebe en el proceso de auditoría.
GfI Languard Network Security Scanner
La empresa GFI tiene una amplia gama de herramientas de seguridad, desde herramientas para la protección de servidores, herramientas para la gestión y correlación de eventos de seguridad y como no un escáner de vulnerabilidades, LanGuard Network Security Scanner. Esta solución ha sido tradicionalmente una de las más utilizadas en entornos Microsoft y ha tenido una gran aceptación en España. El contar con la solución en castellano y con soporte en castellano para los clientes ofrecido desde España hizo de esta una de las opciones más utilizadas, además de una política de precios muy asequible. El producto no solo es un escáner de vulnerabilidades sino que además es una solución que permite desplegar parches. Al igual que Nessus y la mayoría de las soluciones equivalentes permite el perfilado de las políticas. Para escribir este artículo se ha utilizado la versión 8 del producto que actualmente está en versión beta. A la hora de escanear y auditar una plataforma Microsoft esta es una de las mejores soluciones, es la solución que más información ofrece y mejores resultados muestra. En las políticas por defecto expande algunas vulnerabilidades, es decir, las aprovecha, siempre que no sean dañinas. Muy recomendada, puedes bajarte una versión de evaluación totalmente funcional de la web https://www.gfihispana.com
Imagen: GFI Languard Network Security Scanner
Shadow Security Scanner
Esta herramienta, de Safety-Lab, ha sido una de mis preferidas durante mucho tiempo porque era "poco friendly", de hecho la llamábamos cariñosamente "la bestia parda". Esta forma de trabajar la herramienta le venía heredado de su predecesor Shadow Scanner, una herramienta que no se vendía y que estaba pensada no como Scanner de Vulnerabilidades sino como un Scanner para atacar, con opciones de bombardeo inclusive. Este perfil de la compañía se nota con otras herramientas como Shadow Instant Message, herramienta que se usa para "auditar la seguridad" de las conexiones de los sistemas de mensajería instantánea como MSN Messenger o Yahoo Messenger. Todavía es posible encontrar la primera herramienta en los "mentideros" de Internet. A día de hoy el mantenimiento y actualización de Shadow Security Scanner ha decaído ligeramente y personalmente creo que está por detrás de sus competidoras. No tiene soporte en castellano aunque sí en catalán. Puedes descargar una versión de evaluación completamente funcional durante 15 días desde la web de la compañía https://www.safety-lab.com.
Imagen: Shadow Security Scanner
E-eye Retina
La empresa E-eye, famosa por su sniffer IRIS, tiene la solución Retina para la auditoría de vulnerabilidades en software. Al igual que GFI, cuenta con presencia y soporte en España lo que hace de ella una buena alternativa. Se puede conseguir una versión totalmente funcional de 15 días de la web de la empresa: https://www.e-eye.com
Imagen: E-eye Retina Network Security Scanner
Otros Escáneres
Existen otros muchos escáneres de vulnerabilidades, tanto de pago, como realizados por comunidades de desarrolladores, quizás algunos echéis en falta ISS (Internet Security Scanner), NetBrute o XScan o cualquier otro, pero al final las ideas son similares. Mi recomendación como siempre es contar con un par de ellos como mínimo en cualquier test de intrusión que se vaya a realizar.
Resumen del proceso
Si tuviéramos que resumir brevemente cual es el proceso que hay que seguir para la realización de un test de intrusión sería el siguiente:
1.- Identifica que quieres auditar: Utilizando las técnicas de Footprinting y FingerPrinting vistas en la primera parte.
2.- Busca las vulnerabilidades de esos productos: Utilizando los expedientes de seguridad o los escáneres de vulnerabilidades vistos en la segunda y tercera parte.
3.- Busca los exploits para esas vulnerabilidades como vimos en la segunda parte de este artículo.
4.- Parchea para dejar el sistema corregido tal y como recomiende el fabricante del software en los expedientes de seguridad de la vulnerabilidad.
Este proceso debe ser parte del plan de mantenimiento de los servicios/servidores y debe estar igual de planificado como el proceso de copia de seguridad o de actualización de software, sin embargo, a día de hoy, esto lo realizan pocas empresas o no tantas como debieran en un claro síntoma de descuido hacia su sistema informático.
¿Eso es todo?
Pues no, en primer lugar hay que tener en cuenta que un test de intrusión realizado por dos auditores distintos puede obtener resultados dispares dependiendo de la destreza de un auditor a la hora de configurar las políticas de los escáneres para saltarse los mecanismos de seguridad intermedios o afinar los plugins a ejecutar. Además de todo esto hay que tener en cuenta que una auditoría de seguridad solo tiene validez para el punto de ejecución desde donde se ejecuta, es decir, imaginemos que realizamos un test de intrusión desde Internet y hay una vulnerabilidad que está siendo protegida por el firewall de perímetro a nivel de aplicación. Desde Internet podremos tener un sistema que aparentemente no es vulnerable, mientras que un acceso desde la intranet o desde una conexión VPN puede detectar la vulnerabilidad.Realización de una auditoría con Tenable Nessus 3
Tras haber descargado, activada e instalado el producto lo primero que tenemos que hacer es actualizar la base de datos de plugins del producto. Si es la primera vez que lo arrancamos lo preguntará él mismo, si no, tenemos una herramienta para invocar la actualización en cualquier momento. Después configuramos el servidor, eligiendo la dirección IP y el puerto por el que va a escuchar el servicio de Nessus. Eventualmente, para conexiones remotas, deberíamos generar la lista de usuarios a los que se les permite la conexión con este servidor.
Imagen: Gestión de usuarios en Nessus
Una vez creados los usuarios tendremos que crear las políticas de auditoría ajustadas a nuestros entornos, para ello arrancamos la herramienta de Scanner de Vulnerabilidad y se selecciona la opción de "Manage Policies" y se crea una nueva. Una vez creada tendremos dos opciones de configuración principal. En primer lugar deberemos seleccionar las opciones de configuración generales de la política. En esa lista se configurará, en primera instancia si es una política Segura o no. Si decidimos que la política sea segura ya no se lanzará ningún plugin que pueda dañar el servicio. Además, es importante configurar en estas opciones las propiedades de las credenciales a utilizar, la carga que se va a realizar del servidor y las opciones especificas de rutas, ubicaciones y características que se conozcan del servidor para poder afinar el uso de los plugins. Es aquí donde se nota la destreza o no de un buen auditor de seguridad.
Imagen: Gestión de políticas
Imagen: Configuración de Settings de una política
La otra parte a afinar son directamente los plugins, para ello, cuando creamos una política deberemos elegir que es lo que queremos buscar. No tiene sentido realizar búsqueda de fallos locales en Gentoo, cuando estamos auditando en remoto un Windows Server 2003 R2. Para facilitar esta gestión todos los plugins están agrupados en categorías y podremos añadir o quitar categorías o directamente plugins. La ejecución de muchos de los plugins se realizará teniendo en cuenta las configuraciones definidas previamente en la política.
Imagen: Configuración de Plugins
De todos y cada uno de los plugins que acompañan Nessus hay una ficha de información accesible en el programa y que se mantiene online en el sitio web de la compañía. Con simplemente hacer clic sobre el plugin podremos saber que es lo que mira, cual es el factor de riesgo y si el plugin puede afectar o no a nuestro servidor.
Imagen: Información de un Plugin
Una vez definida las políticas de auditoría podemos proceder ya a realizar el escaneo del servidor. Para ello seleccionamos comenzar una tarea de escaneo, elegimos la política y el motor Nessus desde el que deseamos que se realice, no hay que olvidar que la arquitectura de Nessus es cliente/servidor, gracias a lo que podremos configurar múltiples auditorías desde múltiples servidores.
El proceso completo se puede ver en la imagen siguiente:
Imagen: Proceso de Escaneo
Informe de Auditoría
Ahora a recibir los deberes. Cada vez que se termina un escaneo Nessus genera un informe de auditoría completo que se almacena en un fichero xml. Dicho informe permite que se realicen diferentes visualizaciones del mismo para reflejar la información que ha sacado el escaner. En los informes se podrá ver desde los datos que son puramente informativos hasta la información que es sustancialmente importante para la seguridad y debe ser corregida.
Imagen: Informe de auditoría
Vale, una vez que tienes el informe ¿qué se debe hacer? Bien, en un test de intrusión completo de una compañía se evalúan todas las vulnerabilidades intentando llegar al final, es decir, sí con un exploit se puede conseguir el control de un equipo de la organización, pues seguir adelante para ver hasta que nivel de riesgo se estaría en un caso de una vulnerabilidad similar y realizar un test de intrusión del sistema completo. Esto permitirá descubrir fallos en la política de seguridad de la red.
Si lo que queremos es simplemente corregir el servidor entonces deberemos seguir las recomendaciones para la solución de cada uno de los fallos, estas las vamos a encontrar en los expedientes de seguridad. Una vez aplicadas las medidas de remedio para todas las vulnerabilidades deberemos volver a escanear el mismo servidor y obtener un nuevo informe. El proceso debe repetirse hasta que el informe quede totalmente "limpio". Una de las características de Nessus que podemos utilizar para este proceso es la comparación de informes, con el que podremos comparar los cambios sufridos en la seguridad del servidor en cada cambio que apliquemos al servidor.
Imagen: Gestión de Informes
Hoy en día Nessus es el escáner de vulnerabilidades más utilizado a nivel mundial aunque no es el único y existen otras alternativas/complementos muy interesantes. Aunque hay bastantes escáneres de vulnerabilidades, en el artículo de hoy vamos a ver solo algunas de las mejores soluciones profesionales. El proceso de auditoría en cualquiera de estas soluciones es similar al explicado con Nessus.
Para terminar
Un último punto sobre el que hay que reflexionar antes de dar por terminado este artículo es la auditoría de las aplicaciones propias, es decir, los desarrollos personales. Una aplicación web puesta de cara a Internet, con https, con su firewall protegiéndola por delante, con su auditoría de seguridad con escáneres de vulnerabilidades limpia puede tener un bonito SQL Injection en un radio button y se acabó el cuento. En el caso de los desarrollos personales es necesario contar con una aproximación diferente, con herramientas distintas y con unos auditores más diestros, ya que no solo deben conocer el uso de las herramientas sino también los fallos en el desarrollo de tecnologías. Para aquellos que les interese este tema el mes que viene vamos a ver como se realiza un proceso de auditoría de una aplicación web y cuales son las herramientas que se pueden utilizar.
Para los impacientes que deseen ir abriendo boca les dejo los dos retos hacking que monté sobre test de intrusión en aplicaciones web. Del primero ya existe un solucionario publicado y del segundo se publicará a finales de Abril.