VULNERABILIDADES...TEORIA

¿Qué es una vulnerabilidad? ¿De qué tipo pueden ser?. Definimos una vulnerabilidad como un error en un componente informático, que puede provocar una brecha de seguridad en un sistema. Hay muchos tipos, y no todas son mal diseño. Podríamos clasificarlas en:

• Implementación.- Mala estrategia a la hora de implementar un sistema. Por ejemplo, si en una empresa se le asigna un usuario y contraseña temporal a un empleado cuando entra, y esta siempre es primera letra de nombre, y primer apellido, la configuración no está mal. Llega el usuario, la cambia cuando se sienta el primer día y listo. Para mi, es una mala implementación de un componente bien configurado.
• Configuración.- Esto es lo que yo llamo mal instalada. Algún técnico instala un componente físico o lógico, mal, por ejemplo, dejar un directorio web con permisos de escritura cuando no debería. Estos casos, bajo mi humilde experiencia, son MUY comunes.
• Dispositivo.- Por ejemplo, un Iphone que permite hacer llamadas incluso estando bloqueado con código. Una tarjeta de red en un servidor web que no admite mas de 300 conexiones concurrentes...
• Protocolo.- Por ejemplo WEP. Es un protocolo sobrádamente demostrado que es inseguro.
• Aplicación.- Cualquier fallo en una página web, o aplicación normal.

Como todos sabeis, y sino para eso estamos, hay muchos programas automaticos y semi-automaticos para realizar scanner´s de vulnerabilidades. Ya conoceis los nombres, y no es objeto ahora detallar ni publicitar ninguno, pero si que es cierto, que un scanner es la cuarta pata de cualquier sistema de seguridad. Los otros tres top-values son: anti virus, firewall y un buen IDS. Con el anti virus proveemos seguridad en el end-point( aunque los hay de gateway, de correo etc). Con el firewall definimos que es el end-point xD hasta donde pueden y podemos llegar etc. Con el IDS tenemos una solución pro-activa, que analiza el comportamiento de los sistemas con los procesadores, para alertarnos de determinadas amenazas.
Sin un buen scanner de vulnerabilidades, como sabemos que tenemos todo esto en marcha? bien configurado?.

Muchas empresas lejos de adoptar "el scanneo" como parte del proceso de seguridad, contratan a empresas para recibir un informe, bonito y habitualmente caro, y quedarse tranquilos de que son inviolables ( algunos casos solo para recibir un sello de certificación). Recomiendo adoptar esta técnica como parte del proceso, y realizarla:

• Periodicidad determinada por la empresa.
• Al instalar/modificar elementos del sistema.
• Al actualizar dispositivos.

Tradicionalmente se han dividido los tipos de scaneos en dos, Internos y externos. Pudiendo ampliarse esta definición a "scaneo de aplicaciones web" ya que las técnicas concretas para analizar fallos son totalmente distintas en un entorno de aplicación web, que en un scanner interno/externo.
Dentro del scaneo de vulnerabilidades, se puede hacer otra distinción respecto al conocimiento que tiene el auditor sobre el sistema, denominando "Analisis caja negra" al análisis realizado por el auditor sin ofrecerle a penas información del objetivo, y "Análisis caja blanca"  en el que se es especifican datos concretos para poder profundizar y obtener mejores resultados.
Soy partidario de realizar los dos. Realizar un test a ciegas, y con los resultados obtenidos decidir que sistemas son objeto del siguiente estudio, otorgar mas información, y realizar un test de caja blanca.

Retomando el tema del software automático/semi. decir que es un arma de doble filo, ya que el mismo aplicativo usa el auditor para ayudar, que el hacker para hackear. Es VITAL conocer todas las reglas, plugins, configuraciones del software, para realizar un test en condiciones. Por poner un ejemplo, si en un firewall bloqueo el trafico ICMP ( ping) desde el exterior, y un atacante usa este protocolo, para saber si un HOST esta vivo o no, automáticamente el scanner detendrá el "ataque" si está activada esa regla ( habitual en configuraciones por defecto de scanner de vulnerabilidades).Mejor un TCP PING a puertos por debajo del 1024 no?.
Entonces, una vez que tenemos los host a auditar, tenemos el método para determinar si están vivos o no, configuramos el método de escaneo de puertos ( no voy a entrar en detalle, lo haré en próximas entregas) y por último, iremos seleccionando UNO  a UNO los scripts, plugins, conguraciones que queremos testear, con el fin de saber que estamos haciendo ( evitar D.O.S. , falsos positivos, profundizar en el plugin,etc).

Otro día seguimos con las vulnerabilidades.