OpenSSL é uma biblioteca de software de código aberto amplamente utilizada para implementar comunicações seguras em redes de computadores. Quão amplamente utilizado? Bem, é provável que, se você já acessou uma página HTTPS, tenha feito isso por meio de criptografia OpenSSL. A biblioteca fornece funções criptográficas e protocolos para criptografia, descriptografia, autenticação e verificação de assinatura digital de dados. O OpenSSL pode ser encontrado em quase qualquer lugar onde haja necessidade de proteger servidores web, servidores de e-mail, redes privadas virtuais (VPNs) e outros tipos de comunicação em rede.
Olhando para o parágrafo acima, deve ficar claro o quão importante é o OpenSSL para o bom funcionamento da Internet. É um componente crítico da infraestrutura de segurança de muitos sistemas e aplicativos de computador. Ajuda a proteger dados confidenciais contra acesso não autorizado e ajuda a garantir a integridade e autenticidade das comunicações de rede. É por isso que os mantenedores da biblioteca levam as vulnerabilidades muito a sério e tentam corrigi-las o mais rápido possível. Imaginar que os atacantes obtenham acesso às linhas de comunicação seguras da infra-estrutura da World Wide Web é quase impensável.
Neste artigo, examinaremos as vulnerabilidades que geraram o patch 3.0.7 do OpenSSL em outubro de 2022 e veremos o que podemos aprender com a maneira como os mantenedores do OpenSSL cuidaram do problema.
As vulnerabilidades
Em 25 de outubro de 2022, o Projeto OpenSSL publicou um consultivo avisando que um novo patch chegará em breve para lidar com alguns crítico vulnerabilidades. A tag 'crítica' implica que as vulnerabilidades provavelmente serão exploráveis e que é provável o roubo de chaves privadas e/ou RCE nos servidores afetados.
Uma semana depois, em 1º de novembro de 2022, o Projeto OpenSSL lançou o novo patch, 3.0.7, e o vulnerabilidades específicas eles pretendiam consertar. Entretanto, a classificação das vulnerabilidades foi rebaixada de crítica para “alta gravidade”.
Então, quais são essas vulnerabilidades?
CVE-2022-3602 – Estouro de buffer de 509 bytes do endereço de e-mail X.4 – Na verificação de certificado X.509, especificamente na verificação de restrição de nome, pode ocorrer uma saturação de buffer de quatro bytes. Quatro bytes controlados pelo invasor na pilha podem ser estourados por um invasor usando um endereço de e-mail malicioso. Uma falha (resultando em negação de serviço) ou execução potencialmente remota de código pode ser causada por esse buffer overflow. Inicialmente, foi classificado como crítico, mas testes adicionais mostraram que diversas plataformas usam proteções contra estouro de pilha para reduzir o risco de execução remota de código.
CVE-2022-3786 – Estouro de buffer de comprimento variável de endereço de e-mail X.509 – Na verificação de certificado X.509, especificamente na verificação de restrição de nome, pode ocorrer uma saturação de buffer. Um invasor pode criar um endereço de e-mail malicioso em um certificado para preencher a pilha com qualquer número de bytes que contenha o caractere “.”, que é o número decimal 46. Uma falha pode ocorrer como resultado desse buffer overflow (causando um negação de serviço).
Apenas para reiterar a gravidade dessas vulnerabilidadessão, a CISA, a Agência de Segurança Cibernética e de Infraestrutura dos EUA, divulgou um consultivo no mesmo dia do OpenSSL, encourapedindo aos usuários e administradores que revisem o Documentação OpenSSL e atualização, quando aplicável, para o novo patch 3.0.7.
Conforme discutido anteriormente, RCE (execução remota de código) em sistemas operacionais ou servidores de e-mail executando OpenSSL seria muito ruim, então faz sentido revelar apenas o vulnerabilidades assim que um patch adequado for encontrado e oferecido.
O que acontece depois
Assim que o comunicado inicial foi publicado, as pessoas começaram a lutar. 'Não entre em pânico' era uma frase comum no momento mostrando o quão seriamente as pessoas levaram a notícia de que o OpenSSL tem recursos críticos vulnerabilidades.
Assim que o comunicado foi publicado, todas as partes interessadas relevantes estavam se esforçando para descobrir qual versão do OpenSSL era usada em seu servidor, sistema operacional, aplicativo, pacote, etc. Além do uso interno do OpenSSL, as pessoas também precisavam descobrir se algum de seus terceiros fornecedores terceiros ou prestadores de serviços estavam usando uma versão vulnerável do OpenSSL. Na época, se você não tivesse certeza de qual versão estava usando ou não tivesse certeza de qual versão seus fornecedores e provedores de serviços estavam usando, era considerado mais seguro colocar um aplicativo offline em vez de arriscar um potencial RCE.
Como o comunicado forneceu antecipadamente o cronograma para o patch, isso deu às pessoas tempo para descobrir sua própria infraestrutura e a de seus fornecedores e prestadores de serviços. A ideia era planejar tudo o que fosse necessário em termos de infraestrutura envolvida para que assim que o patch fosse lançado, a atualização, se necessária, pudesse ocorrer.
Como lidaria com isso?
Agora digamos que você seja engenheiro em uma empresa que, até onde você sabe, utiliza OpenSSL em seus servidores. Assim que o comunicado for lançado, você precisará descobrir qual versão da biblioteca está em uso e onde (incluindo qualquer código legado, se ainda estiver em execução) e, em seguida, descobrir a mesma coisa para qualquer um de seus fornecedores ou provedores de serviços.
Este é o lugar onde um SBOM poderia realmente ser útil. Um SBOM significa Software Bill Of Materials e é uma lista de todos os componentes e dependências de software que compõem um determinado produto de software. Um SBOM normalmente inclui informações como nomes e versões de todos os componentes de software (veja onde estou indo com isso), suas fontes e licenças e quaisquer vulnerabilidades conhecidas ou problemas de segurança associados a cada componente.
Se você, como engenheiro responsável, certificou-se de ter um SBOM atualizado para cada um de seus produtos, então descobrir onde você estava usando OpenSSL e qual versão estava em uso teria sido uma simples questão de executar uma pesquisa no arquivo SBOM . Se você também pediu SBOMs atualizados de qualquer fornecedor ou provedor de serviços com o qual sua empresa estava trabalhando, você também poderia ter feito a mesma pesquisa lá.
Como você foi informado de que as vulnerabilidades afetavam apenas as versões entre 3.0.0 e 3.0.6, tudo o que você precisa fazer é verificar quais versões você estava executando para saber quais aplicativos precisavam ser desativados ou atualizados com o novo patch – 3.0.7. XNUMX.
Apenas para mostrar o quão extensa é a lista de sistemas operacionais e aplicativos corporativos conhecidos que usam OpenSSL, confira isto Lista publicado como um serviço público para que as pessoas soubessem o quanto deveriam estar preocupadas.
Como um hub de segurança baseado em evidências pode ajudar
Como parte do cenário em evolução da segurança cibernética, incluindo iniciativas tão abrangentes vulnerabilidades, estamos atualmente testemunhando a evolução da segurança de aplicativos para segurança da cadeia de suprimentos de software. Uma nova geração de ferramentas e tecnologias foi desenvolvida para tentar resolver estes problemas. Ao oferecer uma plataforma contínua de garantia de segurança de código baseada em evidências que pode atestar a confiabilidade do ciclo de vida de desenvolvimento de software e dos componentes de software, ferramentas e soluções automatizadas ajudam as organizações a alcançar um novo nível de segurança. O mapeamento contínuo de dependências e vulnerabilidades torna mais simples remediar ou aplicar patches quando eles estiverem disponíveis.
Escriba é um centro de segurança da cadeia de suprimentos de software. Ele reúne provas e as apresenta para cada construção que passa pelo pipeline de CI/CD. O objetivo da solução da Scribe era facilitar a adesão às regulamentações e às melhores práticas da UE e dos EUA para aumentar a transparência do software e promover a confiança entre desenvolvedores e usuários de software. A plataforma possibilita criar e compartilhar SBOMs abrangentes, bem como outros insights de segurança. Além disso, a plataforma pode confirmar se a compilação que você está visualizando está em conformidade com a estrutura SSDF do NIST e com os requisitos de nível 3 do SLSA. Você não precisa mais se preocupar em descobrir onde está usando qual versão de qual biblioteca, porque você tem um armazenamento de evidências com um SBOM para cada uma de suas compilações. Agora, descobrir isso é tão simples quanto procurar uma frase específica em um documento de texto.
Uma palavra final: Esteja preparado para a próxima grande divulgação de vulnerabilidade
A história do projeto OpenSSL do patch 3.0.7 nos oferece dois pontos de vista igualmente importantes sobre como lidar com vulnerabilidades potencialmente críticas.
Do lado afetado – a empresa ou projeto que foi potencialmente comprometido por essas vulnerabilidades, informamos a transparência. Eles não divulgam imediatamente informações que possam causar danos, mas divulgam tudo o que podem assim que tomam conhecimento de um problema. Além disso, eles também oferecem um cronograma para correção, além do máximo de informações possível sobre o problema. Uma vez existente um patch ou remediação, eles não hesitaram em revelar exatamente o que estava errado e como isso poderia ser potencialmente explorado. Esse tipo de transparência incentiva a confiança. Os usuários e clientes desejam saber e sentir que a empresa se preocupa mais com eles, ou pelo menos tanto, quanto com os resultados financeiros ou com seu conselho de administração.
Em 2014, o projeto OpenSSL foi vítima de um bug crítico denominado 'Sangramento do Coração' – uma falha crítica na implementação TLS/DTLS do OpenSSL que possibilitou que um invasor obtivesse segredos como material de chave de criptografia, senhas e outras informações confidenciais dos servidores afetados. Heartbleed mostrou o que uma vulnerabilidade crítica no OpenSSL pode fazer, pois afetou uma ampla variedade de programas e distribuições Linux. Tentar identificar e corrigir todos os sistemas vulneráveis deu às equipes de segurança meses de dores de cabeça. Implementar uma ferramenta, como um SBOM, que possa tornar mais rápida e simples a atualização e correção de seu software seria uma vantagem para a equipe de segurança cibernética de qualquer empresa.
Do lado da correção – saber exatamente com o que você tem que trabalhar – qual versão de quais pacotes você está usando é essencial para poder lidar com qualquer emergência potencial. Tomando o Log4J como exemplo – algumas empresas ainda estão tentando descobrir se são ou não afetadas por esta vulnerabilidade mais de um ano após sua descoberta.
O fato de que você não precisa se preocupar apenas com seu software e servidores, mas também com os fornecedores terceirizados que você usa ou com os provedores de serviços com os quais você trabalha, mesmo usando conexões API, significa que nós, todos de nós, realmente precisamos construir uma rede de confiança entre nós. Essa confiança deverá depender, tanto quanto possível, de provas concretas. Crie e rastreie seus próprios SBOMs e os de qualquer empresa com a qual você faça negócios, compartilhe esses SBOMs e demonstre boa-fé ao anunciar e corrigir qualquer vulnerabilidade explorável de que tome conhecimento.
Seria necessário que todos nós trabalhássemos juntos para chegar a um mundo onde compartilhar tais evidências fosse tão comum quanto compartilhar as últimas relações públicas da empresa nas redes sociais. Sem esta confiança, estamos apenas a preparar o terreno para a próxima grande vulnerabilidade crítica, que irá desmantelar a infra-estrutura interligada que todos nós trabalhamos arduamente para manter.
Este conteúdo é oferecido a você pela Scribe Security, um fornecedor líder de soluções de segurança de cadeia de suprimentos de software ponta a ponta – fornecendo segurança de última geração para artefatos de código e processos de desenvolvimento e entrega de código em todas as cadeias de suprimentos de software. Saiba mais.
Artigos Relacionados
