ClickCease La ciberseguridad, en el aire

Tabla de contenidos

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

La ciberseguridad, en el aire

Joao Correia

25 de enero de 2023 - Evangelista técnico

En una serie de televisión ficticia que empezó a emitirse el año pasado, un espía cayó en desgracia al olvidar unos papeles clasificados de inteligencia en un tren público. Dichos papeles contenían una lista de espías que trabajaban encubiertos en el extranjero y eran muy importantes.

En un momento de "la realidad imita a la televisión" la semana pasada, un servidor mal protegido perteneciente a CommuteAir, una compañía aérea estadounidense, dejó un documento que contenía la "lista de exclusión aérea" accesible a piratas informáticos motivados.

Lista de exclusión aérea

A veces las historias son simplemente increíbles. La No Fly List es una lista de personas a las que se ha prohibido volar en vuelos comerciales en Estados Unidos, y tiene graves implicaciones para la seguridad nacional. No entraré en detalles sobre los campos que contiene, ni siquiera debatiré lo justificada o no que está dicha lista, ni siquiera su utilidad. Si estos aspectos de esta historia son de su interés, el artículo original del Daily Dot lo cubre en detalle y es una lectura muy interesante.

Es, como mínimo, deleznable reconocer que una lista con más de 1,5 millones de entradas se ha dejado en un lugar accesible (y, supongo, sin querer).

Ciberseguridad, pero sólo un poco

Según el informe original de Daily Dot, la aerolínea indicó que el servidor en el que se expuso el archivo era "un servidor de desarrollo, utilizado con fines de prueba" (citando la historia de Daily Dot). Este comentario lleva implícita la menor importancia que se daba a este servidor en comparación con otros sistemas.

La empresa también confirmó que los datos eran reales, aunque de una versión de 2019 de dicha lista de prohibición de vuelos.

De acuerdo con la normativa vigente, y dada la gravedad del suceso y sus posibles ramificaciones en materia de seguridad, han intervenido autoridades de ámbito federal como la TSA, el FBI y el CISA.

Mirando cómo se hizo el descubrimiento, que fue por un hacker, resulta que fue identificado en una búsqueda Shodan de servidores Jenkins - un paquete de software que automatiza los procesos de construcción y pruebas en el desarrollo de software y es, por desgracia, un nombre familiar en las historias comunes de incidentes de ciberseguridad. Para los menos familiarizados con el nombre, Shodan es un servicio público que ofrece búsquedas similares a las de Google para servicios de Internet. Por ejemplo, se le puede pedir que busque todos los servidores de correo electrónico accesibles en Internet o todos los sistemas de escritorio remoto desprotegidos con una dirección IP pública. Tanto para los actores de amenazas como para los script kiddies, aprender a utilizar Shodan es material de "Hacking 101".

Ahora bien, algunos servicios de TI son algo difíciles de clasificar adecuadamente en accesos "de cara al público" y "sólo privados" claramente definidos, es decir, servicios que requieren acceso desde fuera de la organización, al ser accesibles por Internet, por ejemplo, y servicios a los que sólo se debería poder acceder desde dentro de la red perimetral y que no tienen contacto directo con el exterior.

Sin embargo, Jenkins es uno de los que no ofrece ningún argumento. Es clara y exclusivamente un servicio exclusivo de infraestructura, sólo útil para desarrolladores, y como tal, nunca debería haber sido accesible mediante una consulta Shodan. Aunque muy completo, Shodan no es mágico: no puede encontrar un servidor si dicho servidor no está expuesto.

Pero localizar el servidor que ejecutaba Jenkins era sólo el primer paso. Tenía que haber algún tipo de recurso compartido no protegido o no autenticado dentro de Jenkins donde se encontrara el archivo. El proyecto Jenkins proporciona orientación para proteger un despliegue. Parece que algunos de los consejos proporcionados allí ni siquiera se siguieron.

¿Qué debería haberse hecho de otra manera?

Para empezar, los datos del mundo real nunca deberían usarse, y abusarse, de esta manera. Realmente no necesitas la lista real en tu sistema de pruebas sólo para asegurarte de que tu software puede tratarla adecuadamente. Por eso existen prácticas como el "data mocking", para crear datos "falsos" de apariencia real con este propósito exacto.

A continuación, se deberían haber seguido las mejores prácticas de Jenkins: ningún punto de acceso desprotegido, ningún recurso compartido, nada expuesto.

Entonces, los servidores de infraestructura nunca deberían haber tenido acceso externo en primer lugar. No lo requieren para su correcta ejecución, y si son necesarias conexiones exteriores reales para probar algún tipo de integración externa, para eso están los túneles ipsec.

Pero el verdadero quid de la cuestión es que los equipos de TI siguen teniendo visiones diferentes de los sistemas "secundarios" como estos cuando se trata de ciberseguridad. Los sistemas de primera línea, los sistemas centrales y los sistemas críticos reciben toda la atención, pero los sistemas de infraestructura como el de esta historia y otros como los servidores de impresión, los servidores internos de intercambio de archivos y similares pueden recibir una mirada de vez en cuando, probablemente cuando alguien se queja de un problema.

Guerrero de la ciberseguridad

(Todos los servidores están protegidos, salvo el de Jenkins.

https://knowyourmeme.com/memes/medieval-knight-with-arrow-in-eye-slot)

Este tipo de atención diferente da lugar a abolladuras en la proverbial armadura, y basta una pequeña brecha para que todo el castillo se desmorone.

Todo, en todas partes, versión informática

Proteger, supervisar y parchear todos los servidores, todo el tiempo, como si los datos críticos de la empresa estuvieran en todos y cada uno de ellos. Este debería ser el mantra -el único mantra- de una postura de seguridad moderna. Automatice todo lo posible, pero sin pasar por alto ningún sistema. Todos son igual de importantes para la seguridad.

A un actor de amenazas no le importará mucho si no puede entrar directamente en el servidor de base de datos. Mientras pueda entrar primero en el host de virtualización, será un paso rápido hacia los datos importantes.

El camino hacia el premio no tiene importancia. Sólo importa la recompensa. Depende del equipo azul asegurarse de que todos esos caminos estén bloqueados y protegidos adecuadamente.

fuente de la imagen: https://i.kym-cdn.com/entries/icons/original/000/035/146/knight.jpg

https://knowyourmeme.com/memes/medieval-knight-with-arrow-in-eye-slot

Resumen
La ciberseguridad, en el aire
Nombre del artículo
La ciberseguridad, en el aire
Descripción
Ciberseguridad: Un servidor mal protegido perteneciente a CommuteAir, dejó un documento que contenía "No Fly List" accesible a hackers motivados.
Autor
Nombre del editor
TuxCare
Logotipo de la editorial

¿Desea automatizar la aplicación de parches de vulnerabilidad sin reiniciar el núcleo, dejar el sistema fuera de servicio o programar ventanas de mantenimiento?

Más información sobre Live Patching con TuxCare

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín