Vulnerabilidades em código aberto derrubaram a Equifax. Como você pode se proteger?

A Equifax, gigante do monitoramento de crédito, informou na semana passada que sofreu uma invasão que expôs dados extremamente pessoais de 143 milhões de pessoas. A empresa afirmou que a causa raiz foi uma vulnerabilidade no Apache Struts, uma biblioteca Java muito popular. A empresa conduziu mal sua resposta ao ataque, e proteger nossos dados é responsabilidade dela. No entanto, a Equifax não é, de forma alguma, a única organização exposta a vulnerabilidades do Struts ou de outras bibliotecas de código aberto.

É provável que a Equifax tenha sido comprometida por uma destas vulnerabilidades: a vulnerabilidade de execução remota de comandos (RCE), fácil de explorar, divulgada em março passado ou a nova vulnerabilidade de RCE divulgada na semana passada, quase tão grave quanto a primeira. Apesar do grande destaque dado a esses problemas, quem usa esses pacotes demora muito para corrigi-los.

Analisamos cerca de 1.000 projetos de código aberto no GitHub que dependem diretamente do Struts, e 64% ainda estão vulneráveis à grave falha de março. Praticamente todos estão vulneráveis à falha divulgada na semana passada. Em uma análise separada de milhares de projetos Java testados pelo Snyk, 78% estavam suscetíveis à RCE de março quando foram verificados pela primeira vez, e 100% estavam vulneráveis ao problema da semana passada. (Depois, alertamos os usuários sobre essas falhas e ajudamos a corrigi-las.)

O risco dessas vulnerabilidades não é teórico: elas representam uma ameaça real e imediata. Após a divulgação da RCE do Struts em março, vimos um número grande e crescente de ataques reais que exploravam essa falha de segurança conhecida e fácil de explorar. Da mesma forma, a vulnerabilidade divulgada na semana passada está provocando grandes ondas de ataques.

Quem é responsável?

Violações de segurança costumam desencadear uma série de acusações, com cada parte envolvida tentando culpar outra pelo desastre. Infelizmente, a questão da responsabilidade pela segurança do código aberto é complexa…

Neste caso, é fácil apontar o dedo para o Apache Struts.

Na última década, foram divulgadas mais de 40 vulnerabilidades no Apache Struts, incluindo falhas graves como as RCEs mencionadas anteriormente. Isso pode levar você a pensar que o Struts é uma biblioteca insegura, mas está longe de ser verdade. Na realidade, a equipe foi rápida e responsável ao corrigir os problemas encontrados e, ao contrário de muitos projetos de código aberto, chegou a adaptar correções importantes para versões antigas e menos mantidas do software. A Apache publicou uma resposta bem elaborada sobre o incidente da Equifax.

Os próximos na lista de culpados são os desenvolvedores da Equifax que criaram o portal invadido.

Eles optaram por usar uma biblioteca de código aberto de terceiros sem verificar se havia vulnerabilidades conhecidas nem monitorar o surgimento de novas falhas, e isso terminou em desastre. Esses desenvolvedores têm, de fato, responsabilidade, já que criar software seguro faz parte de suas atribuições. No entanto, é importante lembrar que desenvolvedores não são especialistas em segurança e muitos desconhecem os riscos de usar uma biblioteca de código aberto. Além disso, em grandes organizações como a Equifax, muitas vezes os desenvolvedores não têm autonomia para “pensar fora da caixa” e assumir responsabilidades além do que foi solicitado explicitamente.

Ao considerar as responsabilidades formais, a culpa recai sobre a equipe de segurança da Equifax.

Essa equipe é formalmente encarregada de manter os sistemas seguros e claramente não conseguiu fazer isso. Embora não haja dúvida de que falhou, se a equipe de segurança da Equifax for como todas as outras que conheci, provavelmente não tem as condições necessárias para proteger as aplicações da empresa. As equipes de segurança costumam ter 100 vezes menos pessoas que as equipes de desenvolvimento e simplesmente não conseguem acompanhar o ritmo do desenvolvimento moderno de software, ainda mais acelerado pelo uso dessas mesmas bibliotecas de código aberto. Se apenas a equipe de segurança for responsável por cuidar da segurança, uma grande violação será praticamente inevitável.

Isso nos leva ao responsável final por esse fiasco: a equipe executiva da Equifax.

A equipe executiva é moral e legalmente responsável por proteger nossos dados pessoais e decide quanto investir nessa proteção, mesmo que isso afete os lucros e o crescimento. Também cabe a ela fazer com que toda a empresa se preocupe com segurança, em vez de deixar essa responsabilidade nas mãos de uma equipe pequena. Por fim, é seu dever entender que adotar práticas modernas de desenvolvimento, como o uso de bibliotecas de código aberto, também traz novos riscos — e que eles precisam ser bem gerenciados. Não tenho ressalvas quanto à responsabilidade da equipe executiva, a não ser lembrar que nenhuma organização é invulnerável e que uma falha não significa necessariamente negligência ou incompetência.

Como evitar ser a próxima Equifax

Em vez de procurar culpados, vamos pensar em como evitar que sua empresa entre para a lista de grandes violações de segurança. Veja algumas medidas que você pode adotar para se proteger, agora e continuamente.

1. Faça uma análise. Verifique suas aplicações com uma ferramenta de segurança de código aberto que identifique bibliotecas vulneráveis, incluindo as falhas de RCE do Struts, e não se esqueça de testar todas as suas aplicações.

2. Corrija os problemas encontrados. Tirar a venda dos olhos e identificar bibliotecas vulneráveis é um primeiro passo necessário, mas, se você não corrigir os problemas encontrados, continuará tão vulnerável quanto antes. Não basta registrar as vulnerabilidades: corrija-as.

3. Monitore as vulnerabilidades nas bibliotecas que você usa. É ótimo verificar agora se há bibliotecas vulneráveis, mas você pode ter certeza de que novas vulnerabilidades serão descobertas amanhã, como acabamos de ver no caso do Struts. Configure alertas para receber notificações sobre novas vulnerabilidades divulgadas e poder corrigi-las antes que os invasores as explorem.

4. Encontre ferramentas de segurança que os desenvolvedores possam usar. Sua equipe de segurança não consegue dar conta de tudo, e os desenvolvedores têm necessidades diferentes das equipes de segurança em relação às ferramentas. Encontre ferramentas de segurança que os desenvolvedores gostem de usar e incentive suas equipes de desenvolvimento a adotá-las. Assim como fizemos com o DevOps, precisamos que mais pessoas assumam a responsabilidade pela segurança — uma abordagem frequentemente chamada de DevSecOps.

Se você não sabe por onde começar, comece com uma análise usando a CLI ou a integração com o GitHub do Snyk. É claro que sou suspeito para recomendar essa solução, mas, no mínimo, o plano gratuito do Snyk vai identificar os problemas nas suas aplicações e ajudar você a começar a corrigi-los. Se não quiser usar o Snyk, procure outra ferramenta — mas tome alguma providência antes que esse problema saia do controle.

O problema não é o Struts

Por fim, vale destacar que esse problema não se limita ao Struts nem ao ecossistema Java Maven. Só no último mês, foi divulgada uma vulnerabilidade de execução arbitrária de código no popular pacote npm do Node.js pg, além de uma vulnerabilidade de cross-site scripting no framework Python django.

No mês anterior, as vulnerabilidades divulgadas incluíram uma falha de XSS no Spark Core, uma popular plataforma de big data baseada em Java, e foram descobertos dezenas de pacotes maliciosos no registro do npm. Estudos realizados no início deste ano mostram que 77% dos sites usam uma biblioteca JavaScript vulnerável em sua página inicial.

Os números não param. Em resumo, monitorar e corrigir vulnerabilidades nas bibliotecas de código aberto é essencial para qualquer organização hoje, e a única maneira de realmente resolver esse problema é incorporar esse processo ao desenvolvimento. Se precisar de orientação para começar, envie um e-mail para nós e ajudaremos você a dar os primeiros passos. Mas, seja o que for que você faça, aprenda com o erro da Equifax e não baixe a guarda.