La importancia de reducir la superficie de ataque.

Los atacantes logran penetrar una aplicación web por los más insospechados lugares. A veces inclusive el ataque es llevado a cabo por vectores que están relacionados pero que nada tienen que ver directamente con la aplicación web. Es común oír hablar de sitios vulnerados a través de servicios como FTP o SMTP e inclusive POP3, NNTP y muchos otros, pero: ¿Cuál es la razón por la cual este tipo de ataques son frecuentes? Lo que sucede es que la superficie de ataque de dichas aplicaciones es a veces demasiado extensa.


Para entender el concepto de "superficie de ataque" solo necesitamos imaginarnos a un bombardero de la segunda guerra mundial B25 (el atacante) tratando de visualizar la posición del objetivo a ser bombardeado. En esa época no existían radares sofisticados, ni posicionamiento por GPS, por lo cual la visibilidad del objetivo era uno de los principales factores que influían en que este pudiera ser alcanzado de forma más o menos eficiente.

Un objetivo más visible, necesitaba una protección antiaérea mejor y hasta se recurría en algunas ocasiones al camuflaje. También hay que recordar que del lado de atacante existían y existen los conocidos espías, que podían desde el campo de batalla, enviar información precisa acerca de la superficie, forma e importancia del objetivo. También un objetivo a veces bien camuflado, podía ser identificado por instalaciones adyacentes al mismo que no concordaban con el camuflaje. Por ejemplo un aeropuerto y sus aviones podían ser camuflados, pero si se existían grandes depósitos de combustible, muchos "graneros"con forma de angar, o demasiada actividad de personal, se podía comprometer el camuflaje y dejar al descubierto la operación.

Regresando a nuestro campo de batalla real, la web, y analizando el símil con el ejemplo anterior es indudable que mientras más rutinas, páginas dinámicas y especialmente formularios tenga una aplicación, mayor será su superficie de ataque. La cantidad de los anteriores es lo que determina su tamaño y llamaremos "superficie neta o necesaria".

Podemos después de lo anterior deducir que la posibilidad de un ataque es directamente proporcional a la superficie de ataque total de la aplicación.

Sin embargo, los servicios adicionales que utiliza el programador o que han quedado instalados por defecto, comprometen también la seguridad de nuestra aplicación web, tal como lo hacían la actividad del personal y los depósitos de combustible en el caso de nuestro ejemplo. Estos generan una superficie de ataque adicional, superflua o innecesaria que aumenta el riesgo de ataques.

Uno de los casos más comunes de este tipo de servicios instalados en los servidores y que a veces están completamente a disposición del atacante proviene de la instalación por defecto de paquetes de servicios pre-configurados, como por ejemplo XAMPP, algunas versiones de WAMP o LAMP  entre otros. Este enlace les llevará a una tabla de comparación de los más conocidos. También proviene de instalaciones de paquetes de código abierto mal configurados como manejadores de contenido CMS y otras utilidades.

El programador o el administrador del servidor, instalan dichos paquetes pre-configurados sin entender o percatarse de que la configuración por defecto es básica y hasta se pudiera decir que algo inocente. No hace falta decir por ejemplo, que no tiene mucho sentido proteger el servicio de MySQL si se deja el acceso al PhpMyAdmin completamente libre. Y esta es solo una de las configuraciones por defecto en las que no se repara a la hora de instalar el software pre-configurado.

Hay veces en que un simple escaneo de puertos permite verificar que tipo de software pre-configurado se ha instalado en un servidor web, ya que desde afuera de la red local se puede acceder a puertos como 21, 25, 110, 443, 119 y otros todos instalados en el mismo servidor, y así entablar conversaciones Telnet o de otro tipo con los servicios activos en dichos puertos. Si el atacante logra vulnerar uno solo de estos servicios inocentemente configurados desde el punto de vista de la seguridad, tendrá el camino prácticamente abierto hacia nuestra aplicación, o también podrá simplemente utilizar los servicios para sus fines, como enviar SPAM por el SMTP server, ubicar un sitio de phishing en nuestro servidor o simplemente colocar grandes cantidades de software ilegal para distribuirlo desde nuestro servidor FTP.

¿Y los espías? Cuando me refería a los espías quise hacer una comparación a lo que comúnmente se conoce como "Google Hacking Database". No hay mejor conocedor de nuestra aplicación web que Google. Los atacantes lo saben y hacen que trabaje para ellos mediante una serie de técnicas y consultas que han desarrollado y que permiten buscar sitios con determinadas vulnerabilidades conocidas en base a su tipo de servidor y servicio. Es realmente impresionante la cantidad de sitios vulnerables que puede mostrase mediante el uso del GHDB. El equipo de Google trabaja permanentemente en la caza de este tipo de consultas para reducir los posibles perjuicios, pero ellos mismos son víctimas del enorme potencial de la herramienta y no puede controlar su potencia por lo que permanentemente se descubren nuevos trucos.

Es claro que luego de leer este artículo Usted deberá tener un concepto algo más claro de lo que se conoce como "superficie de ataque" y posiblemente se le hayan ocurrido algunas ideas para reducirla. En otros artículos hablaremos de las técnicas de reducción y camuflaje de dicha superficie.

Hasta la próxima...