Preparação eficiente contra a vulnerabilidade do OpenSSL 3.x
Atualização (1º de novembro de 2022): A entrega de conteúdo da Akamai via HTTP e HTTPS não é afetada por esta vulnerabilidade, pois os servidores estão usando uma versão não impactada do OpenSSL. Além disso, os sistemas da Akamai utilizam mecanismos de proteção de pilha padrão do setor que atenuariam o vetor de ataque descrito. A Akamai está aplicando patches a qualquer sistema interno potencialmente afetado, mas não acreditamos que essas ações gerarão tempo de inatividade para nossos clientes.
Em 25 de outubro, a equipe de projetos do OpenSSL anunciou uma correção de segurança de uma vulnerabilidade crítica no OpenSSL versão 3.x. O patch está com lançamento programado para 1º de novembro de 2022, entre 13h e 17h UTC.
Este anúncio gerou alvoroço devido ao uso disseminado do OpenSSL. Com este artigo, esperamos ir direto ao assunto e fornecer informações gerais e dicas sobre como detectar e mitigar a ameaça sem especulação. A primeira parte da publicação descreverá o OpenSSL e o escopo da vulnerabilidade. A segunda parte descreverá como o OpenSSL é usado em aplicações e fornecerá ferramentas para detectar ativos vulneráveis. Fique à vontade para ir direto a estes utilitários, se preferir.
Nota: esta publicação abrange um incidente em evolução e será atualizada à medida que mais informações forem coletadas e a correção for lançada.
Qual é o escopo desta vulnerabilidade?
Essa vulnerabilidade causou preocupação na comunidade de segurança porque é incomum que a equipe do OpenSSL classifique uma vulnerabilidade como crítica, posteriormente rebaixada para "alta." Desde a implementação desses identificadores de vulnerabilidades após o Heartbleed (uma vulnerabilidade que leva a um vazamento de memória e possível divulgação de senhas), houve apenas uma outra, CVE-2016-6309 que foi categorizada como "crítica."
De acordo com os requisitos da equipe do OpenSSL, para ser classificada como crítica, uma vulnerabilidade afeta configurações comuns e é passível de exploração. Um exemplo destas vulnerabilidades pode incluir "divulgação significativa do conteúdo da memória do servidor (potencialmente revelando detalhes do usuário), vulnerabilidades que podem ser facilmente exploradas remotamente para comprometer as chaves privadas do servidor ou onde a execução remota de código é considerada provável em situações comuns".
Considerando o quão comum é a biblioteca OpenSSL, tal vulnerabilidade pode ser prejudicial. No entanto, embora a conscientização seja necessária, ainda não há motivo para pânico. A biblioteca OpenSSL é muito comum, mas sua versão mais amplamente utilizada é a 1.X.X, e a vulnerabilidade afeta apenas as versões 3.0.0 e posteriores do OpenSSL (lançadas somente em setembro de 2021). Portanto, a vulnerabilidade provavelmente será menos comum do que a distribuição da própria biblioteca OpenSSL.
Executamos nossas ferramentas de detecção em algumas de nossas redes gerenciadas e descobrimos o seguinte:
Aproximadamente 50% dos ambientes monitorados tinham pelo menos uma máquina com ao menos um processo que dependia de uma versão vulnerável do OpenSSL.
Destas redes, a porcentagem de máquinas na rede que tinham alguma dependência de uma versão vulnerável do OpenSSL variou de 0,2% a 33%.
A cobertura mediana foi de 6,1% e a média foi de 11,3% com desvio padrão de 11,6%.
Estas estatísticas não levam em conta o uso não vulnerável do OpenSSL. A única métrica tomava por base as máquinas com pelo menos um processo que depende de uma versão vulnerável do OpenSSL (3.0 a 3.6). Outros processos em execução na mesma máquina não foram levados em consideração.
O que é OpenSSL?
OpenSSL é um kit de ferramentas de software de código aberto e, como tal, as versões do OpenSSL são basicamente versões de código-fonte. Em termos de detecção, isso significa que há uma infinidade de maneiras pelas quais uma aplicação pode carregar ou depender do OpenSSL, daí a importância da vulnerabilidade.
Primeiro, precisamos definir os três componentes do OpenSSL.
libcrypto – uma biblioteca criptográfica com implementação de muitos protocolos (tais como AES, RSA, ChaCha etc.)
libssl – uma biblioteca que implementa todos os protocolos TLS até TLSv1.3
openssl - um utilitário de linha de comando para várias operações (como geração de certificados)
Para que uma aplicação dependa do OpenSSL, ela precisa utilizar alguma lógica de código de libcrypto ou libssl (openssl é uma aplicação em si que depende dos outros dois).
Como mitigar a vulnerabilidade do OpenSSL
A primeira etapa para mitigar a ameaça do OpenSSL é detectar ativos vulneráveis. Embora seja um conselho comum, raramente ele é acompanhado por métodos práticos. Fornecemos uma lista de aplicações vulneráveis conhecidas (abaixo), bem como um método geral para encontrar aplicações vulneráveis em sua rede.
Segmentação: mitigação pré e pós-patch
Embora a aplicação de patches possa não ser possível imediatamente, uma vez que a maior dependência do OpenSSL vem do software do fornecedor (que precisa aplicar a correção por conta própria), ainda podemos aproveitar a visibilidade que podemos obter da detecção. Podemos usar segmentação e roteamento para reduzir a propagação que um invasor pode ter ao abusar da vulnerabilidade.
Podemos impor mais restrições aos ativos voltados para a Internet, sob a forma de uma DMZ (mais rigorosa).
Podemos criar mais segmentação em todo o domínio, para que uma máquina interna violada não possa ser usada para se propagar para toda a rede. Isso também pode ser usado para reduzir a superfície de ataque de uma máquina vulnerável somente à parte da rede com a qual ela realmente precisa se comunicar.
Além disso, podemos aproveitar essa visibilidade e detecção para criar um plano de ação de aplicação de patches e garantir que nada seja ignorado. Depois que os patches são liberados e o processo de aplicação de patches é concluído, podemos executar novamente a lógica de detecção e comparar os resultados. O ideal é que não restem máquinas vulneráveis.
Quais aplicações sabemos que são vulneráveis?
BoringSSL (usado no Google Chrome) e LibreSSL são duas bibliotecas baseadas no código OpenSSL e ainda não são afetadas pela vulnerabilidade futura.
Diferentes distribuições Linux geralmente são fornecidas com a biblioteca OpenSSL. Se você opera um ambiente Linux, talvez queira verificar se está usando uma das seguintes versões, que são fornecidas com o OpenSSL vulnerável.
Red Hat Enterprise Linux 9
Ubuntu 22.04 ou superior
CentOS Stream9
Kali 2022.3
Debian 12
Fedora 36
Se estiver usando uma distribuição Linux que não esteja na lista, não há garantia de segurança contra vulnerabilidades. Se você atualizou ativamente a biblioteca (como parte do comando de atualização de um gerenciador de pacotes, por exemplo), você também estará vulnerável. Você pode digitar "openssl version" no seu terminal para checar a versão da biblioteca.
O Docker também divulgou suas diretrizes para a próxima versão, em que estimam que cerca de 1.000 repositórios de imagens poderão ser afetados em várias imagens oficiais do Docker e imagens do Docker Verified Publisher. Isso inclui imagens baseadas em variações das distribuições do Linux mencionadas acima.
Há também algumas estruturas que podem ser afetadas. Node.js v18.x e v19.x estão usando o OpenSSL 3 e, portanto, são considerados afetados pela vulnerabilidade. Novas atualizações serão anunciadas nesta Haifei Li.
Outra linguagem de programação que fez desenvolvedores se arrepiarem foi a Golang. As bibliotecas em binários Go estão estaticamente vinculadas, o que pode ter exigido que os desenvolvedores da Go recompilem seu software. Quando a equipe Golang anunciou novas versões menores que incluíram correções de segurança na mesma data do próximo patch OpenSSL, as pessoas vincularam as duas e presumiram que estavam relacionadas. Não se preocupe: foi alarme falso. As versões da Golang não estão relacionadas à vulnerabilidade futura.
É provável que a lista de aplicações vulneráveis aumente nos próximos dias, e esta publicação será atualizada conforme necessário. As próximas seções fornecerão métodos e ferramentas de detecção para ajudar você a descobrir quais aplicações em seu ambiente usam o OpenSSL 3 e estão, portanto, vulneráveis também. Se preferir, você pode ir direto aos mecanismos de detecção.
Um método geral para detectar aplicações usando OpenSSL 3
Nota: esta seção apresenta os detalhes internos de como uma aplicação usa OpenSSL. Caso interesse apenas a detecção, você pode acessar diretamente nossas regras YARA ou consultas OSQuery.
O OpenSSL pode ser vinculado a uma aplicação de forma estática e dinâmica. Com a vinculação estática, o código-fonte do OpenSSL é incluído como parte do código da aplicação, e ambos são compilados juntos no mesmo binário. Com a vinculação dinâmica, o OpenSSL é compilado separadamente em uma biblioteca compartilhada (libssl.dll e libcrypto.dll no Windows; libssl.so e libcrypto.so no Linux). O código da aplicação tem referências na biblioteca compartilhada, que são resolvidas pelo sistema operacional quando ele carrega a aplicação.
Como isso se transforma em detecção? Praticamente, um método para detectar binários compilados estaticamente será suficiente. Por quê? Porque se uma aplicação em execução carregar dinamicamente o OpenSSL, ou mesmo se ele carregar dinamicamente uma biblioteca que, por sua vez, carrega dinamicamente o OpenSSL (e assim por diante), eventualmente algumas bibliotecas do OpenSSL compiladas estaticamente serão carregadas. Como todo o carregamento dinâmico ocorre no contexto do mesmo processo, basta percorrer a lista de bibliotecas carregadas em cada processo e encontrar a compilação estática.
Sendo assim, precisamos descobrir como é um OpenSSL compilado estaticamente. Felizmente, é bastante simples. Todas as compilações estáticas do OpenSSL contêm uma string de versão, semelhante a esta: OpenSSL 3.0.6 11 Oct 2022, em que 3.0.6 é o número da versão. Detectar essa string é muito simples e pode ser feito com Regex ou YARA.
Mas pode não ser completamente preciso. Como o OpenSSL é um código aberto, os usuários podem alterar facilmente a lógica de controle de versão para atender às suas necessidades (e, portanto, fazer com que nossa detecção falhe). Só vimos isso acontecer uma vez (com a Cisco, que usou a string CiscoSSL 1,1.1k.7.2.225 ), mas isso também pode acontecer com outros fornecedores.
O que fazer agora?
Embora não saibamos muito até que a correção seja liberada, há algumas coisas que podem ser feitas antecipadamente para o patch. Nossa equipe criou alguns utilitários que você pode executar em seu ambiente para visibilidade e facilidade para efetuar a mitigação. Os clientes da Akamai Guardicore Segmentation com o recurso Insight habilitado podem executar facilmente essa lógica em seu ambiente.
YARA
A regra principal que podemos escrever é para a string mencionada acima. Para fins de brevidade, limitaremos nossa detecção apenas às versões reais do OpenSSL afetadas pela versão, mas podemos facilmente modificar nossos critérios.
rule openssl_version {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
Caso não queira depender da string, também podemos procurar a aplicação principal que depende do OpenSSL, mas analisando as importações do executável. Contudo, é um método menos infalível, e deve ser encarado como tal.
import "elf"
import "pe"
rule elf_import_openssl {
condition:
(elf.type == elf.ET_EXEC or elf.type == elf.ET_DYN) and
(
for any i in (0..elf.symtab_entries):
(
elf.symtab[i].name contains "@OPENSSL_3"
)
)
}
rule pe_import_openssl {
condition:
pe.is_pe and
(
for any i in (0..pe.number_of_imports):
(
pe.import_details[i].library_name contains "libcrypto-3" or pe.import_details[i].library_name contains "libssl-3"
)
)
}
osquery
Usando as consultas acima, também podemos aproveitar a tabela YARA do osquery para executar estas regras em todos os processos em execução.
WITH FIRST_QUERY AS (SELECT DISTINCT
proc.pid,
proc.path,
proc.cmdline,
proc.cwd,
mmap.path AS mmap_path
FROM process_memory_map AS mmap
LEFT JOIN processes AS proc USING(pid))
SELECT *
FROM FIRST_QUERY
JOIN yara ON yara.path = FIRST_QUERY.mmap_path
WHERE sigrule = 'rule openssl_3 {
strings:
$re1 = /OpenSSL\s3\.[0-6]{1}\.[0-9]{1}[a-z]{,1}/
condition:
$re1
}
'
AND yara.count > 0
É claro que você também pode inserir outras regras YARA que mencionamos ou adicionar mais ou menos filtros para restringir ou ampliar o número de arquivos verificados.
Resumo
A equipe do OpenSSL adotou uma abordagem interessante informando as equipes de segurança sobre a próxima correção a ser lançada. Este anúncio proporcionou aos agentes de defesa tempo para preparar e mapear ativos críticos que estão na fila para aplicação de patches. Nesta postagem do blog, tentamos ajudar a fazer exatamente isso, localizando as aplicações e ativos que exigirão atenção no dia do patch.
Este é um processo em andamento e atualizaremos esta publicação do blog à medida que novas informações forem divulgadas, portanto, não se esqueça de voltar aqui para novidades. Você também pode nos seguir no Twitter para obter mais atualizações em tempo real.
