Las cosas vulnerables que se ejecutan en contenedores siguen siendo vulnerables

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Se ha dicho —y no solo por mí— que el código malicioso cifrado sigue siendo código malicioso. El cifrado no cambia en absoluto su naturaleza, salvo quizá por impedir que la infraestructura de seguridad y de las aplicaciones detecte su tránsito por la red.

Lo mismo ocurre con las aplicaciones y plataformas que se ejecutan en contenedores. Si la aplicación es vulnerable, lo será tanto si se ejecuta sobre un sistema operativo como en una máquina virtual o, como sucede hoy en día, en un contenedor. Si la aplicación es vulnerable en el centro de datos, también lo será en la nube. Y viceversa.

Los contenedores no están diseñados para proteger las aplicaciones por arte de magia. Proporcionan cierta seguridad básica en la capa de red, pero la red no es la aplicación. Las aplicaciones tienen su propia superficie de ataque, que comprende su código y sus interfaces (API), así como los protocolos (HTTP, TCP) y la pila de aplicaciones que necesitan. Nada de esto cambia por añadir una entrada a una tabla IP ni por restringir de cualquier otro modo las solicitudes entrantes a aquellas que proceden del punto de entrada al entorno de contenedores.

El motivo por el que menciono esto es la Encuesta DevSecOps de Sonatype de 2017. En ella, el 88 % de los más de 2200 encuestados coincidió en que la seguridad de los contenedores era importante, pero solo el 53 % utiliza productos de seguridad para identificar aplicaciones, sistemas operativos o configuraciones vulnerables en los contenedores.

Los dos primeros elementos de esa estadística —las aplicaciones y el sistema operativo— me llamaron la atención porque son dos de los componentes de una pila de aplicaciones completa que no necesariamente cambian en función de la ubicación o del modelo operativo (nube, contenedores, virtualización, etc.). Una aplicación o API con una vulnerabilidad de inyección SQL (SQLi) o XSS no queda protegida por arte de magia al pasar de un modelo a otro. Esa vulnerabilidad está en el código. Lo mismo ocurre con las plataformas, que indiscutiblemente forman parte de la pila de seguridad de las aplicaciones. Una vulnerabilidad en la gestión de las cabeceras HTTP de Apache al ejecutarse en Linux seguirá existiendo si la aplicación pasa de un modelo tradicional basado en un sistema operativo a uno basado en contenedores.

Es importante —incluso imprescindible— que sigamos identificando vulnerabilidades en toda la pila de la aplicación independientemente de dónde o de qué forma se implemente la aplicación.

Al migrar a contenedores, es igual de importante mantener las medidas de protección de aplicaciones que ya se utilizan para las aplicaciones tradicionales. Un firewall de aplicaciones web resulta igual de beneficioso para las aplicaciones desplegadas en contenedores que para las desplegadas en la nube o en entornos tradicionales.

Lo mismo ocurre con las demás herramientas de seguridad que, según la encuesta, utilizan los encuestados, como las soluciones de análisis estático y en tiempo real (SAST, DAST, IAST y RASP). Aunque el uso de cortafuegos de aplicaciones web (WAF) supera al de otras herramientas, SAST y SCA (análisis de código fuente) también son habituales. SCA es un método estático para detectar problemas antes de la entrega. Voy a delatar mi edad al señalar que herramientas como lint pertenecen a la categoría de herramientas SCA y, aunque no revelan en tiempo real las vulnerabilidades derivadas de la interacción del código (y con los usuarios), sí pueden detectar algunos de los errores más comunes que cometen los desarrolladores y que provocan fugas de memoria, fallos o el tristemente célebre desbordamiento de búfer.

Sé lo que estás pensando. Estás pensando: «Lori, acabo de leer los Resultados de la encuesta para desarrolladores de Stack Overflow de 2017, y JavaScript es, con diferencia, el lenguaje preferido por los desarrolladores. Y como JavaScript es interpretado, todo eso de los desbordamientos de búfer y las fugas de memoria no son más que malos recuerdos de los viejos tiempos en los que programabas en C/C++».

Pero JavaScript —y otros lenguajes interpretados modernos— se implementa en última instancia en un lenguaje más cercano al hardware, como C/C++. Y, como se ha demostrado en el pasado, si se tienen los conocimientos suficientes, se puede aprovechar este hecho para crear un exploit contra el sistema.

Y aunque eso no sea motivo de preocupación, existen muchas otras vulnerabilidades en cualquier código, ya sea por las bibliotecas utilizadas o por el uso indebido de una llamada al sistema que comprometa la seguridad del servidor. Según estudios recientes, el 80 % de las aplicaciones están compuestas por componentes de código abierto. El estudio de Sonatype también señaló que, entre 2014 y 2017, se produjo un aumento del 50 % en las brechas de seguridad confirmadas o sospechosas relacionadas con componentes de código abierto. Muchos de estos componentes están escritos en lenguajes que se prestan a errores más graves, tanto porque están menos controlados como porque cada vez hay menos desarrolladores que dominen esos lenguajes.

La cuestión es que cualquier código puede contener vulnerabilidades. Y dado que el código es la base de las aplicaciones, que hoy en día son la cara visible de las empresas, es importante analizarlas y protegerlas, independientemente de dónde o cómo se implementen.

Contenedores o nube. Tradicionales o virtuales. Todas las aplicaciones deben analizarse en busca de vulnerabilidades y protegerse frente a ataques que aprovechen fallos de las plataformas y los protocolos. Sin excepción.

Las aplicaciones deben analizarse y probarse exhaustivamente durante el desarrollo y, después, volver a probarse en producción. Ambas cosas son necesarias, porque la falacia de la descomposición nos dice que la introducción de nuevos componentes cambia el punto de referencia. Las nuevas interacciones pueden sacar a la luz vulnerabilidades que no se habían descubierto anteriormente.

Para proteger las aplicaciones, tenga en cuenta lo siguiente:

• Utilice herramientas de análisis de código y aplicaciones durante el desarrollo. Intégrelas en el flujo de CI/CD si es posible.
• Vuelva a realizar las pruebas en producción por si la interacción con otros componentes o aplicaciones revela algún problema.
• Mantente al tanto de las vulnerabilidades de los protocolos y las plataformas, así como de las que se descubran en las bibliotecas de terceros que puedas utilizar
• Integra un firewall de aplicaciones web en tu arquitectura. Aunque no lo utilices en modo de bloqueo, es un recurso de valor incalculable en caso de que se descubra una vulnerabilidad de día cero en un protocolo o plataforma, o una vulnerabilidad en una biblioteca.

¡Mantente a salvo!

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie