Por que CVEs devem receber prioridade um para resolução
Já expliquei antes por que a segurança do aplicativo é uma pilha . Digo isso novamente porque às vezes precisamos lembrar que os aplicativos modernos nunca são implantados sozinhos. Não são.
Todo aplicativo moderno é implantado em algum tipo de plataforma. Pode ser Apache ou IIS. Pode ser um servidor de aplicativos Oracle ou IBM. Pode ser node.js com Express ou Python com todas as bibliotecas necessárias. Assim como dependemos de sistemas operacionais e virtualização/contêineres para nos fornecer rede, os aplicativos dependem de plataformas e bibliotecas para lidar com coisas como TCP e HTTP.
Além disso, os desenvolvedores usam bibliotecas para funcionalidade. Reinventar a roda é perda de tempo, então os desenvolvedores recorrem ao código aberto e outros meios para analisadores JSON, gerenciamento de arquivos, autenticação e autorização e suporte a bancos de dados. Layout e gerenciamento de interface do usuário também. Hoje em dia, a maioria dos desenvolvedores recorre a bibliotecas para fornecer essas funções, para que possam se concentrar no que agrega valor: lógica de negócios e serviços.
Uma inspeção de aplicativos realizada em 2017 pela Contrast Labs descobriu que “bibliotecas de software de terceiros representam 79% do código de um aplicativo”. Para Java, a média foi de 107 bibliotecas diferentes. Para .NET? 19. Curiosamente, estou usando pelo menos cinco bibliotecas diferentes com node.js.
Mas o que deveria surpreender é 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, isso representa apenas 2% das vulnerabilidades conhecidas (ou seja, CVEs). O código personalizado representa praticamente o restante, com 97,3% das vulnerabilidades.
Esse risco desproporcional de segurança de fornecimento entre bibliotecas e vulnerabilidades pode explicar por que uma pesquisa da SANS descobriu 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 para garantir a segurança de soluções de terceiros. Apenas 23% dos programas de segurança incluem COTS.”
Humpf. Bem, isso pode explicar a baixa taxa de resposta para resolução de vulnerabilidades, conforme relatado pela Kenna Security. Em 2015, a Kenna Security relatou uma pesquisa conduzida em uma amostra de 50.000 organizações com 250 milhões de vulnerabilidades e mais de um bilhão (BILHÃO) de eventos de violação e encontrou dois pontos muito interessantes com relação à correção de vulnerabilidades:
- Em média, as empresas levam de 100 a 120 dias para corrigir vulnerabilidades.
- Em 40-60 dias, a probabilidade de um CVE ser explorado chega a mais de 90%.
- O intervalo entre a probabilidade de exploração e o fechamento de uma vulnerabilidade é de cerca de 60 dias.
Em outras palavras, a maioria das organizações não está abordando esses 2% de vulnerabilidades com rapidez suficiente para evitar serem comprometidas por uma delas. Talvez porque estejam localizados em bibliotecas que não estão incluídas no programa de segurança da organização.
Independentemente do motivo , isso precisa ser prioridade número um. E deixe-me explicar o porquê.
Antigamente, os invasores tinham que:
- Descubra a vulnerabilidade
- Procure um site de vítima
- Tentar executar um exploit
Isso era manual e demorado. A menos que você fosse um alvo famoso, ninguém iria perder tempo com você.
Hoje em dia, as vulnerabilidades são compartilhadas na velocidade da Internet (que é a velocidade da luz, caso você esteja se perguntando). O backbone óptico, você sabe) e a descoberta de alvos são automatizados. Scripts e bots são capazes de procurar e marcar sites para comprometimento muito mais rápido (e mais barato) do que pessoas. É da mesma forma que botnets do tamanho da Estrela da Morte são criadas a partir de dispositivos IoT desprotegidos . A automação não melhora apenas a produtividade dos mocinhos.
Esses são ataques não direcionados . Ataques de oportunidade, se preferir, que não são planejados. Você pode não ter dados valiosos ou interessantes, mas tem recursos. E os recursos podem ser usados para encontrar outras vítimas e perpetrar outros ataques e, bem, você sabe como isso termina.
Ataques não direcionados são especialmente comuns após a publicação de um CVE. Isso ocorre porque seu código personalizado é único; embora haja muitas vulnerabilidades nele, leva tempo e esforço para encontrá-las. Explorar um CVE que existe em uma biblioteca ou plataforma comumente usada é moleza. A oportunidade é boa demais para deixar passar, porque o retorno do investimento é alto, alto, alto. O Verizon DBIR observou em 2015 que “70% dos ataques exploraram vulnerabilidades conhecidas que tinham patches disponíveis”.
É por isso que a aplicação de patches – seja por meio de atualizações de software reais ou virtualmente por meio do uso de um firewall de aplicativo da web – deve ser a Prioridade Um após a divulgação de um novo CVE em qualquer uma das 79% das bibliotecas que compõem seu aplicativo. Se esse CVE estiver relacionado à plataforma (pense no Apache Killer) , é melhor que seja a Prioridade “Deixar tudo”, porque a digitalização de servidores web e de aplicativos é ainda mais fácil do que a varredura de vulnerabilidades em bibliotecas.
A verdade é que, se você não for conhecido o suficiente para ser alvo, ainda estará em risco. Você provavelmente está usando a mesma pilha de organizações de alto perfil, e isso significa que ataques não direcionados provavelmente o encontrarão. Se você acha que não, considere que posso ir até o banco de dados CVE e encontrar todos os CVEs publicados relacionados ao node.js. Depois, vou até builtwith.com e procuro sites criados com Express – um framework node.js. Não só descobri que o site conhece “ 230.116 sites ativos que usam o Express e mais 263.872 sites que usaram o Express historicamente”, mas também fornece convenientemente um link para baixá-los.
Não é bem o shodan.io dos aplicativos da web, mas não é muito mais difícil juntar dois e dois e chegar a um exploit bem-sucedido.
Portanto, não cometa o erro de pensar que, por não ser “grande o suficiente”, um CVE em uma biblioteca ou plataforma web pode ser ignorado.
É assim que as pessoas acabam virando tendência no Twitter. E não no bom sentido.
Esteja seguro. Priorize respostas a CVEs que afetam toda a sua pilha de aplicativos. De cima para baixo.