¿Son fiables los analizadores automáticos de vulnerabilidades Web?

2

Visto 4387 veces | Publicado el 20/09/2011 | opinion


Últimamente, la tendencia en materia de seguridad es emplear, cada vez más, herramientas para facilitar la ardua tarea de verificar el nivel de seguridad real de una aplicación web. Nombres como Appscan, Webinspect, Acunetix y otros tantos son cada vez más conocidos y utilizados por los profesionales en cualquier proyecto de auditoria o de pentest. Las ventajas son innumerables pero también los riesgos, y es necesario conocerlos y valorarlos a la hora de decidir el presupuesto de que se dispone para analizar si una página Web puede ser comprometida, desde el punto de vista de la seguridad, o si, por el contrario, cumplirá con su cometido a la perfección.

Por Escáner Web se entiende cualquier programa con la capacidad de analizar la seguridad de una aplicación o página Web, es decir, debe incluir los siguientes complementos:

a) Un navegador Web para poder interpretar el código HTML, javascript y demás de la propia página.
b) Un "spider" o "crawler" para poder detectar toda la estructura de navegación de la Web (archivos, directorios, ficheros de imágenes, etc.)
c) Un escáner propiamente dicho para hallar fallos de configuración y vulnerabilidades a nivel Web.
d) Un interface de usuario amigable y fácil de utilizar, que permita configurar de forma sencilla la aplicación y todos los parámetros de análisis.
e) Un generador de reportes que incluya las vulnerabilidades y errores encontrados, su posible impacto para la aplicación Web y la forma de corregir los mismos de forma genérica.

Existen multitud de herramientas así, comerciales de pago y con licencia GNU, para Windows y para Linux, más sencillas y más completas, de desarrolladores conocidos como HP e IBM y otros no tanto, etc.

VENTAJAS Y BENEFICIOS

1. Reducción de costes: el precio y el esfuerzo en horas de revisar una aplicación Web se reducen considerablemente utilizando herramientas comerciales del tipo de las anteriormente nombradas, Acunetix, Appscan, Webinspect, etc. A pesar de que el precio por licencia de uso es importante, basta realizar unos pocos análisis y revisiones para amortizar la herramienta. Además, existen incluso aplicaciones que no son comerciales sino Open Source que también son importantes, es el caso de Wapiti, ya comentado en Hacktimes (http://hacktimes.com/vulnerabilidades_en_aplicaciones_web_-_wapiti), Skipfish, el conocido Nikto, etc.

2. Disponibilidad y automatización: al poder programar y automatizar cualquier análisis de seguridad, se puede repetir tantas veces como sea necesario para verificar que se han corregido los errores y vulnerabilidades ya detectados. También se puede definir una frecuencia determinada para que se revise una página Web concreta una vez al mes, por ejemplo, y comprobar así si ha habido cambios en la misma y detectar incluso anomalías que pudieran indicar un ataque a la página en forma de intrusión o Denegación de Servicio (DoS). Si en un escaneo programado la página no está operativa puede ser debido a un ataque de DoS o un problema de disponibilidad no controlado.

3. No son necesarias habilidades específicas en seguridad: al ser todo el proceso de revisión prácticamente automático, no es necesario perfiles profesiones con amplios conocimientos en seguridad y su correspondiente sueldo elevado ya que la herramienta lo hace todo, revisa, analiza, detecta las vulnerabilidades y errores de configuración, sugiere soluciones, genera los informes y reportes, etc. Suelen ser herramientas que funcionan bajo Windows, de fácil instalación y uso, que no requieren de conocimientos avanzados ni de redes ni de seguridad. Simplemente es necesario conocer la URL de la página Web a analizar, tener cierta destreza con el ratón y saber leer lo que la herramienta proporciona como informe, leer, no entender ni interpretar. Por otro lado, mientras el escaner revisa y analiza, el administrador en cuestión puede dedicarse a otras cosas mucho más productivas para la empresa.

INCONVENIENTES Y DESVENTAJAS

1. Gran cantidad de falsos positivos y falsos negativos: dos peticiones iguales en momentos diferentes a la aplicación Web por parte del escáner, pueden generar respuestas distintas que la herramienta puede interpretar de forma errónea y reportar como una vulnerabilidad inexistente. Anuncios, dependencias con otras páginas y aplicaciones, usuarios conectados interactuando con la Web analizada, etc. En multitud de ocasiones la revisión de seguridad se limita a pasar la herramienta automática y no se verifica la existencia de las vulnerabilidades reportadas, pudiendo ser falsos positivos o indicios de otras vulnerabilidades sí presentes pero no detectadas por la herramienta. También, otras veces, la página Web analizada presenta diverso código y contenido inútil para revisar la seguridad de la misma que una persona puede identificar de forma rápida y sencilla, pero que no lo es tanto para un ordenador y la correspondiente aplicación automática. Otro temaimportante es que un ordenador no es capaz de entender la lógica de la aplicación Web, y el escaneo de seguridad se basa en comprobar la respuesta de la página Web ante los controles y tests que tiene predefinidos la herramienta de análisis como vulnerabilidades ya conocidas.

2. Imposibilidad de encontrar 0days y errores de diseño: al basarse el análisis en comprobar la respuesta de la página Web ante los controles y tests que la herramienta tiene predefinidos como vulnerabilidades ya conocidas, es muy difícil detectar la presencia de errores no conocidos (0days) y que no están incluidos en la base de datos del escáner Web con el que se realiza la revisión de seguridad. Además, es complicado que un ordenador pueda entender la lógica de la aplicación, cosa que para un técnico con conocimientos no supone ningún reto.

3. Problemas con vulnerabilidades de aplicación conocidas como Cross Site Scripting (XSS) y SQL Injection (SQLi): estas vulnerabilidades en todas sus modalidades (Blind SQLi, Stored XSS, reflected, etc.) presentan multitud de patrones de ataque, y si además se encuentran por en medio mecanismos de seguridad como WAF, IPS, firewalls y otros, las herramientas automáticas no son capaces de modificar sus peticiones para evadir dichos filtros que plantean estos dispositivos de seguridad. En diversas ocasiones, se ha reportado una vulnerabilidad de SQLi estándar como Blind SQL y la solución para corregirla es ligeramente distinta. Otro problema es que numerosas herramientas automáticas no detectan como ataque de SQLi una vulnerabilidad en "ORDER BY", además es diferente la forma de tratar esta vulnerabilidad en función del motor de base de datos existente, ya sea MS SQL, MySQL, PostgreSQL, etc.

4. Riesgos directos para la aplicación Web: ya no solo por el límite de peticiones que una herramienta automática puede lanzar en paralelo contra la aplicación Web que puede saturar a la misma y dejarla inaccesible para sus usuarios legítimos, sino también por el tipo de patrones y pruebas que tiene definidas para encontrar vulnerabilidades. Una de esas pruebas consiste en utilizar la conocida sentencia para detectar vulnerabilidades de SQLi, "or 1=1--". En una petición de "SELECT" no hay problema pero si eso mismo acompaña a una petición de "DELETE" quedaría una cosa parecida a "DELETE FROM users where id=1 or 1=1 --" con lo que esto supondría para la aplicación Web. Un técnico no usaría nunca este método de ataque pero aún existen muchas herramientas que se sirven de ella como patrón de ataque.

Resumiendo, para entornos productivos, lo más recomendable para disponer de un nivel aceptable de seguridad en las aplicaciones Web es combinar escaneos con herramientas automáticas y detectar aquellas vulnerabilidades de bajo nivel ya conocidas, y disponer también de técnicos de seguridad con amplios conocimientos que puedan realizar pruebas manuales específicas para cada aplicación. No es lo mismo revisar un CMS conocido tipo Wordpress, Joomla, etc. que una página Web sin contenido dinámico ni base de datos detrás. Un técnico puede ajustar las pruebas y los análisis a realizar en función de las necesidades de cada caso, se trata de soluciones no industrializadas.

Más información y comparativas actualizadas sobre el uso de aplicaciones y escáners Web en:

http://sectooladdict.blogspot.com/2011/08/commercial-web-application-scanner.html

donde se analiza el funcionamiento de prácticamente la totalidad de las herramientas existentes para auditorias Web.


septiembre 26 11:37 a.m.
Braguitas Calientes dijo:

Muy bueno el articulo. Últimamente se abusa de estas herramientas como si fueran la panacea y se peca de la ligera revisión de resultados. Con lo que el informe final que se entrega al cliente, no es mas que un corta/pega del informe automatizado, sin traducir ni el idioma, ni las vulnerabilidades detectadas para hacerlas más entendibles a personal no técnico. Lo que se podría traducir en: Si tienes una licencia de tal herramienta, ya eres auditor de seguridad.

septiembre 25 11:29 p.m.
MeTalSluG dijo:

Muy buen aporte. La comparativa que enlazas al final del articulo es muy interesante. Es curioso lo mal parado que sale algun conocido escaner web de pago y lo bien que puntuan algunas tools open source como arachni.


Añadir comentario











Búsqueda

Síguenos


El staff de Hacktimes ruega a cualquier persona interesada en la distribución y/o publicación de estos artículos que lo haga sin alterar su contenido y cite a su autor y/o la fuente original. Muchas gracias.

Todos los artículos publicados se encuentran bajo la licencia Creative Commons