Las redes de información se han adueñado de nuestro mundo, impartiéndonos en el proceso una constante necesidad de conexión. Con el correr del tiempo se multiplican exponencialmente y abarcan servicios destinados a maniobrar con datos cada vez más sensibles.
En este contexto, la realización de un test de penetración sobre estas redes nos permitirá el estudio de vulnerabilidades y la estimación del riesgo e impacto relacionados a ellas, produciendo un reporte de gran valor para el cliente.
Recordemos antes que toda evaluación de seguridad estructural de red se construye sobre las siguientes etapas:
- Exploración: sondeo de la red para establecer hosts activos, sus puertos abiertos y aquellos servicios expuestos.
- Valoración de la vulnerabilidad: investigar potenciales entradas al sistema.
- Explotación: comprometer un host mediante el uso de una vulnerabilidad o mal configuración.
- Post Explotación: recolección de certificados y avance sobre la red hasta tener el control deseado.
Deberemos definir el alcance de la prueba: por un lado tenemos la evaluación externa, que se realiza fuera del perímetro de red del cliente, enfocándose en servicios expuestos a Internet entre un rango de direcciones IP definidas por él.
Por otro lado, la evaluación interna permite diagnosticar la red dentro del entorno del cliente, con una conexión directa a la intranet o DMZ.
¿Cómo ponemos a prueba la seguridad de una red?
Podemos identificar un conjunto de variables cuyo análisis no debería escapar nunca a un proceso de pentesting en entornos de networking. A continuación se detallan algunas de ellas.
Falta de parches de seguridad
La ausencia de los últimos parches de seguridad en terminales constituye un punto de acceso fácil para atacantes, ya que existen exploits para un gran número de vulnerabilidades conocidas públicamente.
Así, en una red genérica, es altamente probable que alguna de las estaciones de trabajo no se encuentre actualizada, incluyendo cajas registradoras, lectores de tarjetas, cámaras, y dispositivos integrados en general.
En este aspecto, el escenario más común a encontrar se constituye por una estructura basada en oficinas con Windows como plataforma y diferentes niveles de actualización en cada terminal, debido a la carencia de una solución integral como WSUS (Windows Server Update Services) para el despliegue de software actualizado.
Además, es factible encontrar máquinas antiguas en las que es “fácil” tomar control del sistema local (LocalSystem en Windows).
Uso de credenciales por defecto
Es un hecho que muchos dispositivos, aún más aquellos que se encuentran en etapa de prueba, son mantenidos con sus configuraciones por defecto. Lo mismo aplica a servidores de aplicación e interfaces de administración.
Diccionarios de credenciales por defecto son fácilmente hallados en Internet, así como también herramientas para el ingreso por fuerza bruta.
El escenario más probable será esta vez un ambiente DMZ con servidores Linux y Apache Tomcat ejecutándose con credenciales por defecto. Podremos entonces desplegar un WAR personalizado para lograr la ejecución de comandos, crear un dump de los hashes de contraseñas de usuarios y acceder al resto de los servidores mediante el uso de SSH o Telnet.
Footprint de red excesivo
Muchos servicios son innecesariamente expuestos al perímetro de la red. El esfuerzo por mantener una red heterogénea es la causa primaria de descuidos respecto al footprint de la misma.
Aquellos servicios que corren en el localhost pueden resultar de gran utilidad al momento de profundizar el control de la red durante la etapa de post explotación.
A pesar del corriente uso de SSH/Telnet como método de acceso remoto, es aún posible hallar entornos basados en R-Services para asuntos de administración de red, cuyo uso presupone potenciales vulnerabilidades frente a ataques de fuerza bruta sobre las listas de control de acceso ACL de estos servicios.
Otro aspecto que demanda revisión es la presencia del NIS (Network Information Service) en sistemas Linux para el manejo centralizado de usuarios, ya que el mismo puede ser consultado anónimamente por un atacante para recuperar los hashes de contraseñas de usuarios, permitiéndole ganar acceso al sistema y escalar desde allí su ofensiva.
Pobre segregación en la red o falta de la misma
Lograr un correcto diseño de segmentación de red no es juego de niños, y muchas variables deben ser tenidas en cuenta. El particionado por restricciones de máscara, filtro de MACs, y las soluciones de Control de Acceso a Red (NAC) pueden volverse ineficientes. Por otro lado, la segregación de capa de aplicación puede dejar lugar a exfiltraciones de datos o ataques de tunelización.
A modo de ejemplificación para esto último, supongamos dos dominios de Windows sin conexiones aparentes entre ellos, pero ambos ubicados detrás de un servidor Proxy en una tercera red. En tal caso, dicho Proxy podría terminar sirviendo a propósitos maliciosos mediante la redirección de tráfico desde un dominio a otro utilizando una variación de tunelización HTTP mediante el método CONNECT (habilitado por defecto en HTTPS).
Manejo ineficiente de excepciones
Las redes son fenómenos complejos de diseñar y mantener. Muchas veces la documentación no abunda, y diversas reglas inicialmente temporales son configuradas en dispositivos intermedios como firewalls para terminar nunca siendo cambiadas. Es posible también que con el pasar del tiempo se hayan definido reglas contradictorias, u otras que se solapan entre sí. Además, muchas expresiones regulares presentes en estas excepciones pueden convertirse en un fácil blanco de ataque.
La mayor parte de estos dispositivos presenta una interfaz web de administración que abre camino a potenciales ataques de HTTP verb tampering en los que el agresor intercepta peticiones de logueo y reemplaza el método POST por HEAD para obtener el identificador de una sesión vinculada a un usuario legítimo.
Enfoque de whitelisting por sobre blacklisting
El primero consiste hacer hincapié sobre aquello a lo que debe concederse acceso, mientras que el segundo apunta a lo que debe ser denegado. El uso de whitelisting incorpora un abanico de factores a analizar con el objeto de garantizar la seguridad de la red. Así, deberemos comprobar que los mecanismos de acceso no son vulnerables a métodos de codificación u otras técnicas más sofisticadas que atacan directamente a las herramientas de administración de whitelists, entre las que podemos mencionar ataques a mecanismos de distribución de software, robo de firmas digitales, ataques a cuentas clave de administradores, infiltración de intrusos en la organización, y otras.
El blacklisting, por el contrario, resulta un método muy eficiente siempre que sea factible su implementación.
Post Explotación
Una vez que un pentester ha identificado las brechas iniciales que permitirían ganar acceso al sistema, el deber será explorar por falencias que apunten a expandir el control sobre el mismo.
Situándose en los zapatos del enemigo, visualizará posibles cursos maliciosos de acción que servirán como escenarios de prueba. Entre ellos podemos mencionar el crear un usuario administrador, construir una puerta trasera o backdoor, inspeccionar el sistema de archivos, espiar y redirigir el tráfico de red o consultar el Controlador de Dominio (DC, Domain Controller) en Windows, o el servidor NIS en servidores basados en Unix.
En resumen…
En nuestro vasto mundo de interconexiones, la seguridad de la información se ve reducida a la protección de nuestras redes. Un diseño basado en la cuidadosa comprensión de las plataformas y aplicaciones utilizadas es vital para reducir el riesgo de ataque.
El pentesting periódico de redes deviene en un análisis crucial al momento de corregir fisuras y generar planes de contingencia adecuados, manteniéndonos competitivos ante las nuevas amenazas y cerciorándonos de nunca ser tomados desprevenidos.
