Reconocimiento y exploración en la Red de Conectividad del Estado

La Red de Conectividad del Estado (RCE) es una infraestructura que brinda servicios de conexión y ciberseguridad a alrededor de 114 servicios públicos. Parte de nuestra responsabilidad desde el CSIRT de Gobierno es mantener seguro este "patio trasero". Esto nos obliga a ser proactivos en nuestra búsqueda de vulnerabilidades y problemas en los servidores y aplicaciones web en la RCE que están expuestas a Internet.

En este artículo explicamos por qué es importante hacer reconocimiento y exploración en la RCE; y en qué consiste este servicio, incluyendo qué buscamos y qué esperamos no encontrar.

Por qué es importante el reconocimiento y exploración en la RCE

La RCE nació como una forma de bajar el costo de la conexión a Internet para servicios públicos al agrupar la demanda y generar una economía de escala. A poco andar fue evidente que era necesario proteger tanto la disponibilidad de la red como la confidencialidad de la información en ella, pues la red constituye un único punto de falla. Se agregaron entonces firewalls centrales, firewalls perimetrales en la entrada de las redes de cada servicio, y otros filtros. Sin embargo, esto no es suficiente por al menos cuatro razones:

1. Es evidente que si se expone un servidor hacia Internet, el firewall que lo protege no puede bloquearlo todo; lo usual es que al menos permita tráfico a través de los puertos 80 y 443 (para sitios web) y uno o más adicionales para la administración remota de aplicaciones (por ejemplo, el puerto 22; aunque éste podría omitirse si sólo se permite la administración de aplicaciones desde dentro de la RCE, pero es usual permitir cierto grado de comodidad para los usuarios). Y como todo atacante sabe, basta con sólo un puerto abierto y una aplicación vulnerable para abrir un flanco.
2. Como la RCE es un espacio común, y las necesidades son diferentes para distintas instituciones, no es posible proteger a todas las instituciones con un set común de reglas. Por eso existen firewalls perimetrales que "pertenecen" a cada institución. Sin embargo, muchas instituciones tienen conexiones a Internet propias, por fuera de la RCE, por razones como redundancia de la conexión a Internet. Dependiendo de adónde llega esta conexión, puede generar tráfico que es filtrado sólo parcialmente, aumentando el riesgo para la infraestructura de la organización (y del resto del vecindario).
3. Con cada aplicación expuesta a Internet a través de la RCE, aumenta el número de vulnerabilidades a las que se expone no sólo la institución, sino también todo el resto del vecindario.
4. Muchos servicios públicos no tienen presupuesto para ciberseguridad. A veces se realiza una inversión una vez y luego nunca más; a veces se espera que el encargado haga lo que pueda con los recursos existentes. Las razones de seguro son diversas, pero la que más frecuentemente escuchamos es que los recursos son escasos y siempre hay necesidades más urgentes.

Estos problemas son similares al de la basura en las ciudades: todos queremos una ciudad limpia, pero nadie está dispuesto a hacerse cargo de la basura de otros, ni a admitir un basurero en su casa o cerca de ella. También es similar al problema del "no vacunado": basta con que una persona en una sociedad no se vacune contra una enfermedad para que la enfermedad permanezca, y para que eventualmente el resto de las personas se enferme.

Por la razón que sea, no podemos esperar que todas las instituciones que se conecten a la RCE inviertan lo suficiente como para mantener la seguridad del conjunto. Es importante que exista una autoridad central, que se haga cargo de buscar "focos de infección" (vulnerabilidades), y que se preocupe de que todas las personas (instituciones) estén debidamente protegidas, incluso si las personas no saben que son vulnerables.

En qué consiste el servicio de reconocimiento y exploración

El CSIRT de Gobierno posee una lista de poco más de 12.700 dominios e IP, que llamamos lista gestionada. Esta lista fue construida con las respuestas de las instituciones a un formulario llamado N6, donde se solicitó a todos los encargados de ciberseguridad que informaran la lista de sitios web y direcciones IP que requerían monitoreo de forma continua.

El proceso completo de reconocimiento y exploración tiene tres fases. El siguiente es un pseudo-código (a la python) que explica cómo hacemos el reconocimiento y exploración:

En la primera fase, se toma la lista gestionada (que en el pseudo-código aparece como lista_original_sitios), se visita cada sitio web y dirección IP, y se chequea si la dirección está o no disponible para escaneo. Es frecuente que los sitios web y aplicaciones se muevan de dirección temporalmente (como cuando el servidor web responde con códigos 302 o 307); de forma permanente (códigos 301 o 308); sean redireccionados a otra parte vía JS o HTML ; o incluso que sean dados de baja de forma temporal (en caso de mantenciones) o permanente. Como resultado de la primera fase se obtiene una lista de direcciones revisables (que aparece como lista_actual_sitios en el pseudo-código).

En la segunda fase se visita cada dirección revisable (es decir, cada dirección que responda a nivel de aplicativo web y/o a nivel de servidor), y se aplica una serie de tests a esa dirección. La intención de cada test es determinar si el sitio web o aplicación posee o no una vulnerabilidad o fallo de configuración específicos. La versión más actualizada de los tests aplicados está en los términos y condiciones específicas del servicio de reconocimiento y exploración. Como resultado de la segunda fase, se obtiene una lista de vulnerabilidades pre-confirmadas asociadas a algunas de las direcciones revisables.

En la tercera fase, se busca la institución que corresponde a cada una de las direcciones para las que se encontraron vulnerabilidades pre-confirmadas, y un analista realiza una verificación descartando falsos positivos en las detecciones. Recordemos que las detecciones son vulnerabilidades y/o fallos de configuración que llevarían a una posible vulneración de los aplicativos o de los servicios que expone el servidor. En caso de que el problema sea confirmado, se informa al encargado de ciberseguridad de la institución de la vulnerabilidad o fallo de configuración, cuándo se encontró, la evidencia de la vulnerabilidad, y algunas recomendaciones para corregirla.

¿Qué buscamos?

Tal como se dice arriba, la lista de tests que aplicamos está en los términos y condiciones del servicio, pero a la fecha de este artículo, la siguiente es la lista de tests aplicados:

1. Detección de sitios con versiones de PHP vulnerables: Dado que PHP es un lenguaje muy común (a enero del 2024, más de 3/4 de los sitios web en el mundo usan PHP), y que existe una serie de versiones de PHP con vulnerabilidades serias, este test busca si alguno de los sitios revisados usa versiones vulnerables de PHP.
2. Detección de sitios con versiones de Wordpress vulnerables: Alrededor de un 43% de los sitios web en el mundo está hecho con Wordpress. Wordpress es también muy común entre los sitios web de gobierno. Por eso, con este test buscamos versiones de Wordpress vulnerables.
3. Detección de sitios vulnerables a clickjacking: El clickjacking es una técnica que superpone una capa (un iframe) malicioso sobre un sitio legítimo, con el objetivo de capturar datos confidenciales, como credenciales de acceso. Puede ser evitado de forma sencilla, agregando un header al sitio web (X-Frame-Options). Este test chequea si el header anterior está presente en el sitio web revisado.
4. Detección de sitios con versiones expuestas de ASP.NET: ASP.NET es un lenguaje diseñado por Microsoft para construir sitios web. Este test busca versiones expuestas en el HTML de un sitio web que puedan ser vulnerables.
5. Detección de sistemas de autentificación sin protección SSL/TLS: Muchos sitios expuestos en Internet tienen una página de autenticación (login) sin tener un certificado TLS; con ello el username y password que los usuarios tipeen puede ser observado desde la misma red haciendo sniffing. Este test detecta páginas de login sin certificado TLS. Esto es a propósito de lo establecido en el Decreto Supremo N°1, de 2015, de Segpres, en el art. 15.
6. Detección de sitios con cifrados SSL/TLS vulnerables y/o algoritmos obsoletos: Existen varias opciones de algoritmos de cifrado en TLS para cifrar las páginas web enviadas entre un cliente y un servidor. No todos los algoritmos son seguros; para algunos se han descubierto vulnerabilidades. Este test busca algoritmos obsoletos usados por el servidor web para cifrar la comunicación.
7. Detección de sitios con certificados SSL/TLS expirados o por expirar: Los certificados TLS son generados con una fecha de vencimiento, para evitar que un posible problema de seguridad se perpetúe. Este test mira la fecha de expiración del certificado TLS para alertar sobre certificados vencidos o por vencer.

Hasta hoy (2 de mayo de 2024), el servicio había estado detenido porque hemos estado rediseñándolo para depurarlo y hacerlo más eficiente. El objetivo principal del rediseño es hacer el escaneo tan liviano como una persona visitando el sitio con su navegador. Los tests que realizamos no son invasivos; se realizan sólo a través de los puertos 80 y 443, y en total cada sitio es visitado entre 10 y 20 veces (lo que no debiera ser significativo si se compara con las visitas usuales que recibe cualquier sitio web de gobierno).

Dentro de las próximas semanas reiniciaremos el servicio; antes de hacerlo, lo anunciaremos con tiempo para que cada institución pueda informarse oportunamente de los sitios web que le pertenecen y que serán escaneados, y para permitir agregar, cambiar o eliminar sitios web de la lista.