Por que as CVEs devem ter prioridade máxima na correção

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Já expliquei anteriormente por que a segurança de aplicações é uma pilha de camadas. Repito isso porque, às vezes, precisamos nos lembrar de que as aplicações modernas nunca são implantadas isoladamente. Nunca.

Toda aplicação moderna é implantada em algum tipo de plataforma. Pode ser Apache ou IIS. Pode ser um servidor de aplicações da Oracle ou da IBM. Pode ser node.js com Express ou Python com todas as bibliotecas necessárias. Assim como dependemos de sistemas operacionais e de virtualização/contêineres para fornecer conectividade de rede, as aplicações dependem de plataformas e bibliotecas para lidar com recursos como TCP e HTTP.

Além disso, os desenvolvedores usam bibliotecas para implementar funcionalidades. Reinventar a roda é uma perda de tempo, por isso eles recorrem ao código aberto e a outras fontes para obter analisadores de JSON, gerenciamento de arquivos, autenticação e autorização, suporte a bancos de dados, além de layout e gerenciamento da interface do usuário. Hoje, a maioria dos desenvolvedores recorre a bibliotecas para fornecer essas funções, podendo assim se concentrar no que agrega valor: lógica de negócios e serviços.

Uma análise de aplicações realizada em 2017 pela Contrast Labs constatou que “bibliotecas de software de terceiros representam 79% do código de uma aplicação”. Para Java, a média era de 107 bibliotecas diferentes. Para .NET? 19. No meu caso, estou usando pelo menos cinco bibliotecas diferentes com node.js.

Mas o que deveria chamar sua atenção é o que eles descobriram sobre o estado da segurança em relação a essa divisão.

Embora 79% de um aplicativo seja composto por bibliotecas, elas representam apenas 2% das vulnerabilidades conhecidas (ou seja, CVEs). O código personalizado responde por praticamente todo o restante, com 97,3% das vulnerabilidades.

Esse risco desproporcional à segurança da cadeia de suprimentos entre bibliotecas e vulnerabilidades pode explicar por que uma pesquisa do SANS constatou que “embora 23% dos entrevistados dependam fortemente de produtos e serviços de software de terceiros (COTS, serviços baseados em nuvem e software de código aberto), eles não estão assumindo responsabilidade suficiente por garantir a segurança das soluções de terceiros. Apenas 23% dos programas de segurança incluem COTS.”

Hum. Bem, então, isso pode explicar o baixo índice de resposta à correção de vulnerabilidades relatado pela Kenna Security. Em 2015, a Kenna Security divulgou uma pesquisa realizada com uma amostra de 50.000 organizações, abrangendo 250 milhões de vulnerabilidades e mais de um bilhão (BILHÃO) de eventos de violação, e identificou dois pontos muito interessantes em relação à correção de vulnerabilidades:

• Em média, as empresas levam de 100 a 120 dias para corrigir vulnerabilidades.
• Entre 40 e 60 dias, a probabilidade de uma CVE ser explorada ultrapassa 90%.
• O intervalo entre a provável exploração e a correção de uma vulnerabilidade é de cerca de 60 dias.

Em outras palavras, a maioria das organizações não está corrigindo esses 2% de vulnerabilidades com rapidez suficiente para evitar que uma delas comprometa seus sistemas. Talvez porque elas estejam localizadas em bibliotecas que não fazem parte do programa de segurança da organização.

Independentemente do motivo disso, isso precisa ser a prioridade número um. E deixe-me explicar por quê.

Antigamente, os invasores precisavam:

1. Descobrir a vulnerabilidade
2. Procure um site vítima
3. Tentar executar um exploit

Esse processo era manual e demorado. A menos que você fosse um alvo de grande visibilidade, ninguém perderia tempo com você.

Hoje, as vulnerabilidades são compartilhadas à velocidade da Internet (que é a velocidade da luz, caso você esteja se perguntando. Backbone óptico, sabe?) e a descoberta de alvos é automatizada. Scripts e bots conseguem localizar e marcar sites para invasão com muito mais rapidez (e a um custo menor) do que as pessoas. É da mesma forma que botnets do tamanho da Estrela da Morte são criadas a partir de dispositivos de IoT desprotegidos. A automação não está apenas aumentando a produtividade dos mocinhos.

Esses são ataques não direcionados — ataques de oportunidade, por assim dizer, que não são planejados. Talvez você não tenha dados valiosos ou interessantes, mas tem recursos. E esses recursos podem ser usados para encontrar outras vítimas e realizar outros ataques e, bem, você sabe como isso termina.

Ataques não direcionados são especialmente comuns após a publicação de uma CVE. Isso acontece porque seu código personalizado é único; embora ele possa conter muitas vulnerabilidades, encontrá-las exige tempo e esforço. Explorar uma CVE presente em uma biblioteca ou plataforma amplamente utilizada é muito fácil. A oportunidade é boa demais para ser desperdiçada, pois o retorno sobre o investimento é muito, muito, muito alto. O DBIR da Verizon de 2015 observou que “70% dos ataques exploraram vulnerabilidades conhecidas para as quais já havia correções disponíveis”.

É por isso que a aplicação de patches — seja por meio de atualizações de software propriamente ditas ou virtualmente, com o uso de um firewall de aplicações web — deve ser a prioridade número um assim que uma nova CVE for divulgada em qualquer uma das bibliotecas que compõem 79% da sua aplicação. Se essa CVE estiver relacionada à plataforma (como o Apache Killer), é melhor que ela se torne a prioridade “Largue Tudo”, pois identificar servidores web e de aplicações é ainda mais fácil do que procurar vulnerabilidades em bibliotecas.

A verdade é que, mesmo que você não tenha visibilidade suficiente para ser um alvo, ainda corre riscos. Provavelmente, você usa a mesma pilha de tecnologia que organizações de grande visibilidade, o que significa que ataques não direcionados provavelmente chegarão até você. Se acha que isso não acontecerá, considere que posso acessar o banco de dados de CVEs e encontrar todas as CVEs publicadas relacionadas ao node.js. Depois, acesso rapidamente o builtwith.com e procuro sites criados com Express — um framework do node.js. Além de descobrir que o site tem conhecimento de “230.116 sites ativos que usam Express e de outros 263.872 sites que já usaram Express”, ele também disponibiliza convenientemente um link para baixá-los.

Não chega a ser o shodan.io dos aplicativos web, mas também não é muito mais difícil juntar as peças e chegar a um exploit bem-sucedido.

Portanto, não cometa o erro de achar que, por você não ser “grande o suficiente”, uma CVE em uma biblioteca ou plataforma web pode ser ignorada.

É assim que as pessoas acabam virando assunto no Twitter. E não de um jeito bom.

Proteja-se. Priorize as respostas a CVEs que afetam toda a stack da sua aplicação. De cima a baixo.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie