Vulnerabilidade exim 21Nails destaca resiliência de código aberto

Views: 663
0 0
Read Time:7 Minute, 4 Second

No início deste ano, soluções de e-mail comerciais como o Microsoft Exchange fizeram manchetes de segurança com vulnerabilidades de “ProxyLogon“. Agora, o mundo de código aberto entrou em sua própria janela de exposição, com vulnerabilidades recém-divulgadas em um aplicativo de e-mail chamado “Exim“. Exim é o que é conhecido como um Agente de Transferência de Correio (MTA), e está incluído com muitas distribuições Linux comuns para fornecer serviços de e-mail de entrada e saída. Sua adoção é extremamente difundida — na verdade, alguns estimam que o Exim representa 60% dos MTAs na internet. Os pesquisadores de segurança da Qualys divulgaram esta semana descobertas que identificaram 21 vulnerabilidades únicas no código que compõem o aplicativo do servidor Exim e atribuíram um nome para descrevê-las: 21Nails.

Quando acorrentadas, essas vulnerabilidades poderiam, em teoria, permitir que um invasor entregasse o golpe mortal de execução de código remoto não autorizado (RCE). O invasor não precisa fazer login ou autenticar e pode executar comandos no servidor exposto. Felizmente, a equipe da Qualys vem analisando o Exim para vulnerabilidades desde pelo menos outubro do ano passado e coordenou com os desenvolvedores e mantenedores do projeto Exim para desenvolver patches e correções para as falhas. Embora ainda não existam exemplos conhecidos de atores mal-intencionados explorando essas falhas, quanto mais tempo elas permanecem não mediadas, maior a probabilidade de um invasor tirar vantagem delas.

Essa vulnerabilidade é mais um exemplo de quão importante é para as organizações entenderem sua própria postura de segurança— afinal, você não pode corrigir problemas que você não está ciente — e o impacto de uma exposição desse tipo depende em grande parte da rapidez com que os administradores são capazes de atualizar e corrigir seus servidores. Até agora, as taxas de patch entre os usuários do Exim se comparam favoravelmente às que se seguiram à revelação do Microsoft Exchange, destacando o valor da confiança do público em aplicativos de código aberto e o papel crítico que os usuários de código aberto desempenham na remediação de vulnerabilidades de forma rápida e eficiente.

Principais Takeaways

Código Aberto prova sua resiliência

Embora as vulnerabilidades do Exim tenham sido reveladas na esteira do hack do Microsoft Exchange, a diferença na captação por administradores tem sido notável. Mesmo enquanto os administradores do Microsoft Exchange lutam para pressionar as atualizações de segurança, os usuários do Exim já estão implantando a correção em massa, destacando a resiliência inerente das comunidades de software de código aberto e o valor da confiança pública nos testes e abordagem automatizada para aplicar atualizações de segurança.

Patching remedia vulnerabilidades oportunas

A análise do SecurityScorecard indica que as vulnerabilidades do Exim são difíceis de explorar, e há poucas evidências de que atores mal-intencionados conseguiram tirar vantagem deles na natureza neste momento. Seguindo a prática de divulgação responsável estabelecida, a equipe da Qualys trabalhou em estreita colaboração com os desenvolvedores e mantenedores da Exim para desenvolver patches e atualizações para o software, que já está disponível. Corrigindo rapidamente essas vulnerabilidades manterá os servidores Exim seguros antes que atores mal-intencionados tenham a chance de armar.

Potential for Third-Party Exposure Remains

Even if an organization has patched its own systems, a strong possibility still exists that vendors, partners, or other third parties have not. The SecurityScorecard platform allows users to identify which third-party systems may still be vulnerable, so they can take the appropriate precautions to prevent becoming the victim of ransomware or phishing attacks.

How Widespread are the Vulnerabilities?

SecurityScorecard has the capability to non-intrusively detect this and other vulnerabilities using in-house tools which continuously monitor for security exposures, giving us and our customers near real-time insights. Our preliminary analysis shows that the vulnerability is widespread, both by geography and by industry (note that our estimates may increase as more data becomes available).

Geographically, we can identify vulnerable Exim servers running in at least 63 countries (see diagram below). The vulnerability is present in servers in every major world economy and across business sectors

Exploit Details

The SecurityScorecard Investigations & Analysis team examined the 21 vulnerabilities in detail, with the aim of understanding how impactful they truly are. The security research community has developed “proof of concept” (POC) exploits that provide valuable insight regarding how to exploit the vulnerabilities. The SecurityScorecard team sought to further understand how difficult they might be to exploit, as well as what level of access an attacker might reasonably be expected to obtain.

Our findings were mixed. While many have reported that these vulnerabilities can result in an attacker obtaining unauthenticated root access on a target system, our analysis indicates that only one of the 21 vulnerabilities could lead to that result. Most of the 21Nails lead to the attacker gaining access as the “Exim” user. Since the Exim service by default does not run as root, the attacker would have limited access to the underlying operating system. This is in part due to the best practices of open source operating systems and security by design practiced by software developers. Still, the Exim user is trusted by the Exim software, which means the attackers could likely send email messages with a sender address and recipient address of their choice. Further privilege escalation is required for the attacker to obtain more significant administrative access to the target system; however, one of the 10 remote code execution vulnerabilities can be combined with any of the 11 local privilege escalation vulnerabilities to gain root privileges.

Com isso em mente, a vulnerabilidade de acesso ao nível raiz ainda não foi demonstrada com sucesso e continua sendo um risco teórico neste momento. Além disso, a análise indica que a exploração dessas vulnerabilidades pode variar significativamente em dificuldade, com alguns exigindo esforço extremo e condições específicas para existir. Embora essas vulnerabilidades sejam preocupantes e inevitavelmente serão armadas por atores de ameaças, nossa análise indica que seria necessário um ator de ameaças bem equipado — como um APT financiado pelo Estado-nação — para realizar um ataque bem-sucedido projetado para extrair informações úteis ou comprometer um número significativo de sistemas em escala. A equipe de Investigação & Análise não descobriu evidências de qualquer exploração por atores mal-intencionados na natureza — embora continuemos monitorando a situação.

Próximos passos/Ações Recomendadas

Os administradores do sistema precisam atualizar imediatamente o Exim para a versão 4.94.2 (ou a versão fixa/corrigida do repositório do pacote upstream, dependendo da versão do Linux que está sendo usada). Muitas das distribuições Linux mais utilizadas, incluindo CentOS, RHEL e SuSE, já prepararam seus repositórios de gerenciador de pacotes com as correções necessárias.

Embora o patch tenha apenas alguns dias de idade, já observamos uma taxa significativa de adoção entre os sistemas afetados — inclusive dentro do período inicial de 24 horas. Isso indica que muitas das máquinas potencialmente afetadas pelas vulnerabilidades exim estão em um ciclo de atualização automática, destacando um dos pontos fortes do software de código aberto. Os usuários confiam em aplicativos de código aberto porque são completamente testados pela comunidade, dando-lhes a confiança para atualizar seus servidores sem esperar por mais patches veterinários e atualizações críticas de segurança. Um produto de código aberto como o Exim pode ter vulnerabilidades, mas os usuários sabem que podem confiar nas correções quando são emitidas. Contraste isso com o patch do Microsoft Exchange, onde a adoção e implantação dos quais tem em grande parte nivelado.

Equipes de segurança e desenvolvedores também podem usar a plataforma do SecurityScorecard para ver todos os sistemas afetados pela vulnerabilidade — incluindo seus próprios sistemas, bem como os de seus fornecedores e provedores de serviços. É importante lembrar que mesmo que seu próprio sistema não seja afetado, isso não significa necessariamente que você pode dormir tranquilo. Um fornecedor vulnerável representa um risco real de segurança. Mesmo sem acesso raiz, um invasor capaz de enviar e-mails usando um servidor de e-mail “confiável” pode causar danos significativos. Os endereços de e-mail acumulam reputações ao longo do tempo, e macros/malware podem escapar sem serem detectados se forem originários de um endereço previamente confiável. As organizações podem usar o insight que obterem através da plataforma do SecurityScorecard para colocar fornecedores não recortados em uma categoria de e-mail diferente, submetendo-os a um maior escrutínio. Quando o tempo de conscientização sobre riscos de segurança é mais importante, ter uma plataforma que ofereça automação em escala é inestimável.

FONTE: SECURITY SCORECARD

POSTS RELACIONADOS