Cómo Atlassian usó Snyk para resolver Log4Shell

Snyk lanzó recientemente una serie de hackeos en vivo de varios días con AWS, en la que expertos demostraron exploits en tiempo real y explicaron cómo protegerse contra esas vulnerabilidades. Esta serie ayudó a los espectadores a descubrir nuevas formas de mejorar la seguridad en toda la pila de aplicaciones para las cargas de trabajo de AWS.

Como parte de la serie, Micah Silverman (director de Relaciones con Desarrolladores de Snyk) y Chris Walz (ingeniero sénior de Seguridad de Atlassian) hablaron sobre Log4Shell. Para quienes no lo conocen, Log4Shell fue una vulnerabilidad de día cero de gran alcance detectada en la omnipresente biblioteca Java Log4j. En Snyk tenemos una biblioteca completa de recursos sobre Log4jpor si quieres obtener más información sobre la vulnerabilidad.

En esta publicación, repasaremos la experiencia de Walz usando Snyk para detectar y corregir Log4Shell en Atlassian, así como la charla más detallada de Silverman sobre el impacto de Log4Shell.

Cómo Atlassian usa Snyk para escalar la seguridad

Atlassian tiene miles de repositorios y servicios en toda la empresa, por lo que no es práctico analizar cada uno por separado. Por eso, el equipo de seguridad de Atlassian creó una automatización que ejecuta análisis de Snyk Open Sourcecada vez que hay cambios de código en cualquier repositorio.

Además, la automatización toma los resultados de los análisis de Snyk y crea tickets en Jira para todos los problemas de seguridad. Estos tickets se asignan al desarrollador que confirmó el cambio de código e incluyen un enlace al repositorio y recomendaciones prácticas para solucionar el problema. Una vez que se corrige el problema, el ticket se cierra automáticamente.

«Tenemos un proyecto de Jira que se usa en toda la empresa para todas las vulnerabilidades de seguridad. Eso ayuda a tener visibilidad, crear automatizaciones a su alrededor y asegurarnos de que se cumplan los SLO».

Cómo resolver Log4Shell en Atlassian

En diciembre de 2021, Apache Software Foundation anunció la vulnerabilidad crítica en la biblioteca Log4j, que más tarde se conocería como Log4Shell. Atlassian inició de inmediato una investigación de seguridad para averiguar si la empresa usaba versiones vulnerables de Log4j, qué tan grave era el impacto en los productos que usaban Log4j y qué se podía hacer para corregir Log4Shell.

«Este fue uno de los peores problemas posibles relacionados con las dependencias de bibliotecas. En Atlassian usamos mucho Java, así que era un problema grave y de inmediato iniciamos una investigación de seguridad».

El equipo de Walz sabía que Snyk podía ayudarlos a identificar qué proyectos usaban Log4j, pero su automatización solo se ejecutaba cuando había cambios de código. Necesitaban asegurarse de contar con información actualizada. Como la vulnerabilidad Log4Shell acababa de agregarse a la base de datos de vulnerabilidades de Snyk, Atlassian escribió un script para volver a analizar rápidamente todos sus proyectos y detectar instancias vulnerables de Log4j.

Una vez que el equipo de seguridad confirmó que todos los datos sobre vulnerabilidades estaban actualizados, inició manualmente la segunda parte de su automatización: la sincronización con Jira. Esta envió automáticamente 1,426 tickets de Jira sobre vulnerabilidades de Log4j a todos los desarrolladores pertinentes para que pudieran corregirlas rápidamente.

«Estos tickets de Jira se crearon automáticamente, sin que el equipo de seguridad tuviera que hacer nada. En las 12 horas posteriores al anuncio original, todas las personas que usaban una versión vulnerable de Log4j recibieron un ticket para actualizarla».

El impacto de Log4Shell

Como Log4Shell estaba tan extendido en el ecosistema Java, la clave para corregirlo era identificar dónde se usaban instancias vulnerables de Log4j. Sin embargo, esto no se resuelve simplemente revisando las dependencias del proyecto. Snyk ha descubierto que la mayoría de las vulnerabilidades provienen de dependencias transitivas.

La inteligencia de seguridad oportuna y precisa de Snyk ayudó a muchas empresas a detectar Log4j en sus bases de código, aunque más del 60 % de las instancias eran dependencias indirectas. De hecho, Snyk lanzó rápidamente una actualización de Snyk CLI diseñada específicamente para detectar Log4j en binarios Java o archivos JAR.

«Tuvimos que cuestionarlo todo debido a la naturaleza de este problema. Esta es la espada de doble filo del código abierto. Lo bueno es que podemos responder a los problemas muy rápido, pero a menudo se necesitan unos días para alcanzar un punto de estabilidad».

Tras analizar el impacto en toda la industria, Snyk descubrió que más de 17,000 paquetes Java se vieron afectados y que hubo más de 800,000 intentos de ataque en las primeras 72 horas. Sin embargo, muchos atacantes se enfocan en empresas que nunca corrigen los problemas después de ese período inicial. Por eso es importante analizar continuamente las vulnerabilidades, como Log4Shell, mucho después de que se descubre un parche.

«A veces caemos en la trampa del ciclo de las vulnerabilidades y suspiramos aliviados cuando encontramos una forma de corregirlas. Pero, en realidad, ese es el punto medio de la cronología, porque cierto porcentaje de las empresas no las corregirá a tiempo, y es entonces cuando los atacantes entran en acción».

Otras sesiones de la serie incluyeron:

• Cómo explotar tus líneas de código más débiles con StackHawk

• Cómo explotar vulnerabilidades en tus cargas de trabajo de contenedores con AWS

• Cómo hackear tu Kubernetes mal configurado con HashiCorp

Mira la sesión completa de hackeo en vivo de AWS con Snyk y Atlassian aquí.

Play Video: Exploiting Risks in Your Open Source Dependencies with Atlassian