Como a Atlassian usou a Snyk para resolver o Log4Shell

Recentemente, a Snyk lançou uma série de sessões ao vivo de hacking, com duração de vários dias, em parceria com a AWS. Especialistas demonstraram explorações em tempo real e explicaram como se proteger dessas vulnerabilidades. A série ajudou o público a descobrir novas formas de reforçar a segurança em toda a pilha de aplicações para workloads na AWS.

Como parte da série, Micah Silverman (diretor de relações com desenvolvedores da Snyk) e Chris Walz (engenheiro sênior de segurança da Atlassian) conversaram sobre o Log4Shell. Para quem não conhece, o Log4Shell foi uma vulnerabilidade zero-day de grande alcance encontrada na onipresente biblioteca Java Log4j. A Snyk tem uma biblioteca abrangente de recursos sobre Log4j para você saber mais sobre a vulnerabilidade.

Neste artigo, vamos relembrar a experiência de Walz usando a Snyk para detectar e corrigir o Log4Shell na Atlassian, além da apresentação mais aprofundada de Silverman sobre o impacto do Log4Shell.

Como a Atlassian usa a Snyk para ampliar a segurança

A Atlassian tem milhares de repositórios e serviços na empresa, por isso não é viável analisar cada um individualmente. Foi por isso que a equipe de segurança da Atlassian criou uma automação que executa análises do Snyk Open Source sempre que há alterações de código em qualquer repositório.

Além disso, a automação usa os resultados das análises da Snyk para abrir tíquetes no Jira para cada problema de segurança. Os tíquetes são atribuídos ao desenvolvedor que fez a alteração no código e incluem um link para o repositório, além de orientações práticas para corrigir o problema. Depois que o problema é corrigido, o tíquete é fechado automaticamente.

“Temos um projeto do Jira usado por toda a empresa para todas as vulnerabilidades de segurança. Isso ajuda a dar visibilidade, criar automações em torno dele e garantir que os SLOs sejam cumpridos.”

Como resolver o Log4Shell na Atlassian

Em dezembro de 2021, a Apache Software Foundation anunciou uma vulnerabilidade crítica na biblioteca Log4j, que mais tarde recebeu o nome de Log4Shell. A Atlassian iniciou imediatamente uma investigação de segurança para entender se a empresa usava versões vulneráveis do Log4j, qual era a gravidade do impacto nos produtos que o utilizavam e o que poderia ser feito para corrigir o Log4Shell.

“Esse foi um dos piores problemas possíveis relacionados a dependências de bibliotecas. Usamos muito Java na Atlassian, então era um problema sério e iniciamos imediatamente uma investigação de segurança.”

A equipe de Walz sabia que a Snyk poderia ajudar a identificar quais projetos usavam o Log4j, mas a automação só era executada quando havia alterações de código. Era preciso garantir que as informações estivessem atualizadas. Como a vulnerabilidade Log4Shell tinha acabado de ser incluída no Banco de Dados de Vulnerabilidades da Snyk, a Atlassian criou um script para reanalisar rapidamente todos os projetos e detectar instâncias vulneráveis do Log4j.

Depois que a equipe de segurança confirmou que todos os dados sobre vulnerabilidades estavam atualizados, iniciou manualmente a segunda parte da automação: a sincronização com o Jira. O processo enviou automaticamente 1.426 tíquetes do Jira sobre vulnerabilidades do Log4j aos desenvolvedores responsáveis, para que pudessem corrigi-las rapidamente.

“Esses tickets do Jira foram criados automaticamente, sem que a equipe de segurança precisasse fazer nada. Em até 12 horas após o anúncio inicial, todas as pessoas que usavam uma versão vulnerável do Log4j receberam um ticket informando que era preciso atualizá-la.”

O impacto do Log4Shell

Como o Log4Shell era muito disseminado no ecossistema Java, o principal desafio para corrigi-lo era identificar onde estavam sendo usadas instâncias vulneráveis do Log4j. No entanto, não basta simplesmente analisar as dependências do projeto. A Snyk descobriu que a maioria das vulnerabilidades vem de dependências transitivas.

A inteligência de segurança precisa e atualizada da Snyk ajudou muitas empresas a detectar o Log4j em suas bases de código, embora mais de 60% das instâncias estivessem em dependências indiretas. Na verdade, a Snyk lançou rapidamente uma atualização da Snyk CLI, desenvolvida especificamente para detectar o Log4j em binários Java ou arquivos JAR.

“Tivemos que questionar tudo por causa da natureza desse problema. Essa é a faca de dois gumes do código aberto. O lado bom é que podemos responder aos problemas muito rapidamente, mas muitas vezes são necessários alguns dias para chegar a um ponto de estabilidade.”

Após analisar o impacto em todo o setor, a Snyk descobriu que mais de 17 mil pacotes Java foram afetados e que ocorreram mais de 800 mil tentativas de ataque nas primeiras 72 horas. No entanto, muitos invasores atacam empresas que nunca corrigem os problemas após esse período inicial. Por isso, é importante continuar analisando vulnerabilidades como o Log4Shell mesmo muito tempo depois da descoberta de uma correção.

“Às vezes, caímos na armadilha do ciclo de vulnerabilidades e respiramos aliviados quando surge uma forma de corrigir a vulnerabilidade. Mas esse é, na verdade, o meio da linha do tempo, porque uma parcela das empresas não corrige a vulnerabilidade a tempo — e é aí que os invasores entram em ação.”

Outras sessões da série:

• Explorando suas linhas de código mais vulneráveis com a StackHawk

• Explorando vulnerabilidades em seus workloads de contêineres com a AWS

• Invadindo seu Kubernetes mal configurado com a HashiCorp

Assista à sessão completa de hacking ao vivo da AWS com a Snyk e a Atlassian aqui.

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