Lições das vulnerabilidades do OpenSSL — parte 1: prepare sua cadeia de suprimentos para a próxima vulnerabilidade crítica

É cedo numa manhã de terça-feira de outubro, excepcionalmente quente. Você confere seus e-mails enquanto toma a primeira xícara de café ou chá do dia e quase cospe tudo ao ler que o OpenSSL lançará uma atualização para corrigir uma VULNERABILIDADE CRÍTICA. Na mesma hora, você se lembra do Heartbleed. Rapidamente, escreve uma mensagem no Slack para seu chefe e, logo antes de clicar em "enviar", percebe que já sabe exatamente o que ele vai perguntar: onde fomos afetados e como vamos corrigir isso?

A equipe do projeto OpenSSL avisou sobre a vulnerabilidade com cerca de uma semana de antecedência, causando pânico. Quando finalmente divulgou o que havia sido corrigido na versão 3.0.7, acabou rebaixando o nível de gravidade para alto e revelou duas novas vulnerabilidades. Mas e se essa fosse a próxima Heartbleed? Você estaria preparado? Como descobriria se foi afetado — e onde? Onde precisaria procurar? Afinal, não é uma questão de "se" haverá uma nova vulnerabilidade crítica em uma biblioteca amplamente usada, mas de "quando".

Nesta série em duas partes, vamos abordar alguns pontos que você deve considerar ao identificar vulnerabilidades na cadeia de suprimentos de software. Embora o foco seja o OpenSSL e as bibliotecas relacionadas, também vamos considerar vulnerabilidades em geral. Para começar, vamos falar sobre onde procurar bibliotecas vulneráveis e compartilhar algumas dicas e truques de busca.

Onde procurar bibliotecas vulneráveis na cadeia de suprimentos

As duas novas CVEs do OpenSSL (CVE-2022-3602 e CVE-2022-3786) são problemas de estouro de buffer que afetam as versões 3.0.0 a 3.0.6 do OpenSSL. Felizmente, as versões 1.x, muito mais comuns na prática, não foram afetadas. "Ótimo", você pode pensar, "só preciso procurar os hosts que têm o OpenSSLv3 instalado". Embora seja um bom primeiro passo, há outros aspectos a considerar e muitos outros lugares — e formas — em que versões vulneráveis podem estar escondidas.

Hosts, máquinas virtuais e imagens de contêiner

Os recursos usados para executar cargas de trabalho geralmente não são considerados parte da cadeia de suprimentos, mas não deixe de verificá-los. Além de conferir se há versões afetadas do OpenSSL em hosts físicos — servidores, desktops, laptops e estações de trabalho —, você também precisa considerar os hosts virtuais. Eles podem ser máquinas virtuais (VMs) executadas nos seus próprios hipervisores, mas também instâncias de computação na AWS, no GCP, no Azure ou em outros provedores de nuvem. Essas instâncias, sejam EC2, GCE ou qualquer outra sigla de marca, são possíveis alvos de exploração. Boas configurações de nuvem e rede podem restringir o acesso a essas instâncias, mas é melhor manter um inventário pesquisável. Para isso, você pode instalar proteção de endpoint nos hosts ou usar ferramentas nativas da nuvem, como o AWS Inspector, que detecta cargas de trabalho AWS no ambiente da AWS, incluindo as instâncias EC2. Neste artigo, vamos nos concentrar no software.

Além de hosts físicos e virtuais, mais de 90% das organizações que entrevistamos também executam cargas de trabalho em contêineres e sem servidor, dinâmicas e efêmeras, que podem ser um pouco mais difíceis de verificar. Essas cargas de trabalho são efêmeras, pois podem durar pouco tempo, e dinâmicas, pois podem ser instanciadas conforme uma programação ou em resposta a eventos. Por isso, não basta verificar os contêineres que estão em execução: você também precisa conferir as imagens de contêiner do seu inventário, que podem chegar a centenas ou milhares. 

As imagens de contêiner costumam ser armazenadas em um registro de contêiner, como Docker Hub, Quay ou JFrog Artifactory, ou em um repositório de imagens fornecido pelo provedor de nuvem. Além disso, as imagens podem ser implantadas como cargas de trabalho ou servir de base para outras imagens. As vulnerabilidades costumam ser transitivas. Se você encontrar um pacote vulnerável em uma imagem de contêiner, é possível — e até provável — que as imagens derivadas dela, criadas com `FROM` a imagem original, também sejam afetadas.

Isso deve dar uma boa ideia de onde procurar o OpenSSL nos hosts (físicos, virtuais e efêmeros). Nesses locais, o OpenSSL provavelmente foi instalado por gerenciadores de pacotes — por exemplo, com `brew (or yum, or apt) install openssl` — ou por meio de pacotes baixados e instalados manualmente. No entanto, há outras maneiras de pacotes vulneráveis chegarem aos seus sistemas.

Código-fonte e dependências

Você pode ter versões específicas do OpenSSL instaladas nos hosts — por exemplo, para usar SSH ao se conectar a outros hosts. Mesmo que essas ocorrências de nível superior não sejam vulneráveis, pode haver outras instâncias instaladas pelo software que você usa, junto com ele ou pelo software que você desenvolve e implanta. Essas instâncias entram na sua cadeia de suprimentos quando o código tem uma dependência direta das bibliotecas do OpenSSL. Por exemplo, quando o aplicativo especifica bibliotecas do OpenSSL nas dependências, como em `requirements.txt`, `pom.xml` ou `Gemfile`. Isso também pode acontecer quando algum elemento da árvore de dependências do aplicativo depende do OpenSSL, mesmo que as dependências transitivas estejam muitas camadas abaixo. Por exemplo, seu aplicativo usa uma biblioteca auxiliar que, por sua vez, depende de uma biblioteca criptográfica; a cadeia continua até que a árvore de dependências revele que a biblioteca "qux" adicionou o OpenSSL 3.05, embora nenhuma das bibliotecas intermediárias sequer apareça no seu `Gemfile` de três linhas. Se algo na árvore de dependências do aplicativo incluir bibliotecas do OpenSSL, elas também estarão na lista de materiais de software (SBOM) do aplicativo.

Às vezes, desenvolvedores de aplicativos simplesmente copiam e distribuem as bibliotecas do OpenSSL junto com os aplicativos, em vez de incluí-las por meio de gerenciadores de pacotes. Nesse caso, a biblioteca é incorporada ao aplicativo durante o processo de build, em vez de depender da presença de bibliotecas externas.

Prepare-se para a próxima vulnerabilidade na cadeia de suprimentos com a Snyk

Ao usar Snyk Container e Snyk Open Source para proteger sua cadeia de suprimentos de software, você pode monitorar proativamente seus contêineres e projetos de código aberto. Em vez de correr para encontrar imagens de contêiner ou pacotes de código aberto vulneráveis, você pode saber se foi afetado antes mesmo da divulgação das vulnerabilidades e ter a tranquilidade de já saber o que responder quando clicar em "enviar" no Slack para mandar aquela mensagem ao seu chefe.

Se ainda não tem uma conta, crie hoje mesmo uma conta gratuita da Snyk e economize tempo e esforço nas suas buscas. Volte na próxima semana para acompanhar a continuação da nossa conversa sobre como encontrar — e corrigir — vulnerabilidades na cadeia de suprimentos.