Tanzu VMware

El mundo de los desarrolladores TI en 2022 da la bienvenida a dos noticias relevantes: La vulnerabilidad log4j y Tanzu VMware.

¿En qué consiste cada una? A continuación un breve resumen de cada una de ellas:

La vulnerabilidad log4j acaparó la atención (y nuestro tiempo libre). Los desarrolladores de todo el mundo se apresuran a parchear sus aplicaciones y sistemas a medida que se descubren nuevos vectores. Si tan solo hubiera una mejor manera.

¡La plataforma de aplicaciones Tanzu fue lanzada oficialmente! Con este lanzamiento, la plataforma de desarrollo construida sobre Kubernetes ahora está disponible para ayudar a los desarrolladores y equipos de operaciones a trabajar juntos para construir, operar y administrar sus aplicaciones de manera más fácil y segura.

Entendamos cómo estas dos noticias se relacionan.

El problema de vulnerabilidad log4j

La vulnerabilidad de Log4Shell destaca la importancia de adoptar proveedores de software de código abierto confiables para la empresa.

El 9 de diciembre se reveló una vulnerabilidad en una de las bibliotecas de Java más populares. Log4j (versión 2) se vio afectado por un “exploit” de día cero que resultó en la ejecución remota de código (RCE), lo que permitió a los atacantes ejecutar código remoto en entornos vulnerables. En esta etapa, todos han oído hablar de CVE-2021-44228, también conocido como Log4Shell.

Log4j es una biblioteca frecuente en los ecosistemas de Java utilizada por millones de aplicaciones en todas partes, por lo que el impacto de este CVE ha sido masivo. Prueba de su impacto es la alta puntuación CVSS otorgada a este CVE: 10 sobre 10.

¿Qué impacto tiene esto en las empresas?

Además, los productos de los principales proveedores de la nube, como AWS, Intel, Cisco, RedHat e incluso VMware, se han visto afectados en gran medida por la vulnerabilidad.

El impacto en las empresas fue enorme, lo que provocó que la mayoría de los equipos de ingeniería y operaciones detuvieran sus actividades diarias y el desarrollo de productos para priorizar la aplicación de parches provenientes de proyectos ascendentes y parchear su propio software construido internamente para atender esta vulnerabilidad crítica. Teniendo en cuenta los posibles efectos y riesgos que esta vulnerabilidad puede tener en las aplicaciones y los sitios creados con esta biblioteca, el equipo detrás de Log4j inmediatamente comenzó a trabajar en una solución.

En esta publicación, repasamos las respuestas y mitigaciones que se han lanzado, cómo algunas de ellas no resolvieron el problema y qué parches están disponibles para mantener sus instalaciones seguras contra esta vulnerabilidad.

Una retrospectiva de las correcciones y mitigaciones de Log4Shell

Muchas de las mitigaciones que se suponían viables ya se han desacreditado, ya que han aparecido nuevos vectores de ataque. Inicialmente, se pensó que ** los kits de desarrollo de Java (JDK) más nuevos ** no se vieron afectados, ** ** pero algunas personas demostraron que aún era posible eludir fácilmente las limitaciones introducidas por esos JDK recientes y reproducir el ataque.

Deshabilitar la búsqueda remota cuando se registran mensajes es otra medida insuficiente que inicialmente se consideró posible, pero más tarde se descubrió que las propiedades que rigen la búsqueda remota no se aplicaban en todos los escenarios posibles.

Además, aunque RCE fue el foco del exploit original, algunos miembros de la comunidad de código abierto demostraron nuevos ataques de vectores, como la capacidad de filtrar secretos que podrían existir como variables de entorno en servidores vulnerables. Posteriormente, los atacantes pueden extraerlos de los registros de acceso, que podrían haber sido utilizados en la naturaleza, como explica John Graham-Cumming de CloudFlare en esta publicación de blog.

Otro ataque de vector que se informó es un ataque de denegación de servicio (DOS), en el que los sistemas pueden desactivarse activando miles de mensajes de registro que terminan intentando abrir miles de conexiones remotas o activando la recurrencia descontrolada de las búsquedas autorreferenciales. Este ataque de DOS desencadenó la creación de CVE-2021-45105.

Inicialmente, el parche 2.15 enviado a la base de código Log4j2 fue insuficiente para mitigar por completo el problema original. Por ello, se planteó un nuevo CVE, CVE-2021-45046, y se liberó una nueva versión de Log4j2, la 2.16. Para aquellos que se ejecutan en la biblioteca Log4j1 original, ya obsoleta, eso no significa que estén exentos de peligro. Esta biblioteca también es vulnerable en algunos escenarios, aunque es más elaborada y aún no se ha publicado una solución.

El 19 de diciembre, Apache Software Foundation lanzó Log4j2 2.17, que resuelve de forma incremental los problemas de DOS planteados en CVE-2021-45105 y completa, al menos por ahora, un par de semanas frenéticas de actividad en el espacio de seguridad en torno a las bibliotecas de registro de Apache.

¿Qué hacer ante esta situación?

Si está afectado y está en Log4j2, las opciones más seguras son actualizar a Log4j2 2.17 o eliminar JndiLookup.class del classpath de la aplicación como se sugiere en las notas de seguridad de Apache Log4j.

La necesidad de una fuente confiable para consumir componentes de código abierto.

En este contexto, hemos aprendido que cuando aparece una vulnerabilidad en cualquiera de los componentes o bibliotecas sobre los que se construyen nuestras aplicaciones, toda nuestra infraestructura puede verse comprometida.

Como consecuencia, los desarrolladores y operadores siempre deben monitorear la fuente del código ascendente de sus aplicaciones y mantener actualizadas todas las dependencias de la aplicación. De lo contrario, todos sus sistemas pueden quedar fácilmente expuestos a incontables daños.

Pero ese es un esfuerzo enorme que pocas organizaciones pueden permitirse. Y, la pregunta más importante: ¿es viable tener docenas de personas rastreando todas estas dependencias, asegurándose de que estén actualizadas, en buen estado y parcheadas con las últimas correcciones de CVE, mientras garantizan el cumplimiento interno, en lugar de centrarse en construir nuevas soluciones para la empresa?.

VMware Application Catalog: Una efectiva herramienta para manejar estos riesgos

Muchas organizaciones son cada vez más conscientes de los desafíos asociados con la seguridad de la cadena de suministro de software. Esto incluye gobiernos y agencias federales. De particular interés es, por ejemplo, la orden ejecutiva del presidente de los Estados Unidos, sobre la mejora de la ciberseguridad de la nación, que ordenó al Instituto Nacional de Estándares y Tecnología (NIST) brindar orientación sobre la seguridad de la cadena de suministro.

Como parte de eso, el Apéndice F de las Prácticas de gestión de riesgos de la cadena de suministro cibernético para sistemas y organizaciones repasa controles específicos de OSS:

Los proyectos de código abierto son diversos, numerosos y utilizan una amplia gama de modelos operativos. La procedencia, integridad, mantenimiento de soporte y otras funciones subyacentes de muchos de estos proyectos no se entienden bien o no son fáciles de descubrir y varían de un proyecto a otro.

Como vemos en el caso de Log4j, esta situación ha afectado a muchas empresas que ejecutaban versiones anteriores de Log4j y Java. Los parches Log4j2, por ejemplo, requieren Java 8. Cualquiera que ejecute Java 7 y versiones anteriores es vulnerable a estos ataques. Y aunque el equipo detrás de Log4j está trabajando en una solución, no está claro cuándo podría entregarse.

Cuando algo como Log4Shell se convierte en "Log4Hell", es imprescindible tener una fuente única, privada y confiable para consumir componentes de aplicaciones de código abierto, como VMware Applications Catalog.

¿Qué es VMware Applications Catalog?

VMware Applications Catalog proporciona una rica biblioteca de componentes básicos pre empaquetados y confiables en forma de contenedores, gráficos de Helm y máquinas virtuales entregados directamente en un repositorio privado de su elección.

Todas las soluciones disponibles en el catálogo se actualizan continuamente con cambios de código ascendentes, se reconstruyen, se prueban (mediante la ejecución de varios análisis CVE y antivirus) y se envían al registro de clientes. Todos los metadatos están disponibles para usted, por lo que siempre puede estar informado sobre las versiones, las correcciones y los resultados del análisis que cada paquete incluye y pasa.

Por lo tanto, los usuarios de VMware Applications Catalog tienen la confianza de ejecutar solo aplicaciones y componentes confiables y seguros en sus entornos de producción.

Además de esto, VMware Applications Catalog le permite personalizar la biblioteca de activos disponibles al seleccionar el sistema operativo base que desea usar para cada imagen. Esta flexibilidad permite una experiencia de autoservicio superior para los desarrolladores, al tiempo que aplica sin problemas las mejores prácticas operativas, de seguridad y de cumplimiento.

Estas capacidades hacen que VMware Applications Catalog sea un activo invaluable para las empresas que necesitan llevar aplicaciones rápidamente a producción mientras mejoran la productividad a través de la automatización de procesos manuales, como monitorear y mantener actualizadas las dependencias de las aplicaciones.