Test de Intrusión (IV 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]
****************************************************************************************

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 [http://www.securityfocus.com/bid] y CVE (Common Vulnerabilities and Exposures) [http://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.

Imagen: Últimos expedientes en Bugtraqid
Imagen: Expediente de Seguridad de un Bug
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:

Imagen: “RPC Jode Jode”. Antiguo scanner para un fallo RPC.
Imagen: WebDAV Scanner. Para detectar Servidores con WebDAV activado.
Imagen: WebDAV Exploit. Asociado al WebDAV Scanner
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: http://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.

Y el mes que viene

Pues en el último artículo de esta serie veremos las herramientas de scaneado de vulnerabilidades y como se debe realizar un proceso completo de la auditoría.

****************************************************************************************
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]
****************************************************************************************