learn.hack.repeat

Catégorie : Malware

Microsoft corrige un zero-day utilisé pour propager Emotet.

Comme signalé en novembre, Emotet est redevenu une menace pour les ordinateurs de bureau. Ce mois-ci, Microsoft a inclus dans les mises à jour de sécurité de décembre, un correctif pour le zero-day qui a permis la propagation de ce malware, qui a été classé comme le plus dangereux au monde.

Comme chaque deuxième mardi du mois, les mises à jour des produits de Microsoft sont désormais disponibles. À cette occasion, un total de 67 failles de sécurité ont été incluses dans la mise à jour de Windows, dont sept sont critiques et les autres sont classées comme étant de haute sévérité.

L’une des plus critiques est une vulnérabilité qui usurpe le programme d’installation AppX affectant Microsoft Windows (CVE-2021-43890). Les attaquants ont exploité cette vulnérabilité pour installer des paquets comprenant certaines familles de logiciels malveillants comme Emotet, TrickBot ou Bazaloader.

D’autres failles de sécurité critiques ont été corrigées par la dernière mise à jour de Windows :

CVE-2021-43240 : vulnérabilité d’élévation de privilège liée au service NTFS.
CVE-2021-43883 : vulnérabilité d’élévation de privilège dans Windows Installer.
CVE-2021-41333 : vulnérabilité d’élévation de privilèges dans la file d’attente d’impression de Windows.
CVE-2021-43893 : vulnérabilité d’élévation de privilèges dans le système de fichiers cryptés (EFS) de Windows.
CVE-2021-43880 : vulnérabilité d’élévation de privilège dans l’administration des périphériques Windows Mobile.

Mais la mise à jour de décembre ne comprend pas seulement des failles liées à l’élévation de privilèges, mais aussi celles liées à l’exécution de code à distance dans Defender for IoT, le client de bureau à distance, le serveur SharePoint, etc.

Plus d’information:
https://msrc.microsoft.com/update-guide/releaseNote/2021-Dec
https://jabot.tech/emotet-fait-un-retour-en-force-grace-a-trickbot/

Une faille critique dans Apache Log4j

Une vulnérabilité zero-day dans la bibliothèque Apache Log4j a été divulguée. Elle est activement exploitée et permettrait l’exécution de code à distance sur les systèmes vulnérables.

Apache Log4j est une bibliothèque open source développée en Java qui permet aux développeurs d’écrire des messages de journal. Il s’agit d’une bibliothèque largement utilisée dans les logiciels populaires de divers fournisseurs, notamment Amazon, Apple iCloud, Cisco, Cloudflare, ElasticSearch, Red Hat, Steam, Tesla, Twitter et même des jeux vidéo tels que Minecraft.

La vulnérabilité, identifiée sous le nom de CVE-2021-44228 et surnommée « Log4Shell » ou « LogJam », est due aux fonctionnalités JNDI (Java Naming and Directory Interface) utilisées dans la configuration, les messages de journal et les paramètres qui ne fournissent pas de protection contre l’accès aux services d’annuaire distants et autres points finaux.

Cette faille de sécurité pourrait permettre à un attaquant distant non authentifié d’exécuter du code arbitraire chargé depuis des serveurs distants. Cela peut se faire par l’intermédiaire d’une simple chaîne de texte, qui amène une application à communiquer avec un hôte externe malveillant, à partir duquel la charge utile est téléchargée et exécutée localement sur le système affecté. À titre d’exemple, la possibilité d’exécuter du code à distance sur les serveurs de jeu Minecraft en tapant simplement un message spécialement conçu dans la boîte de discussion a été démontrée.

La vulnérabilité, découverte par Chen Zhaojun de l’équipe de sécurité d’Alibaba Cloud, a reçu un score CVSS de 10 sur 10 en raison, notamment, de sa gravité et de sa facilité d’exploitation.

Les versions d’Apache Log4j comprises entre 2.0-beta9 et 2.14.1, toutes deux incluses, sont affectées. L’Apache Software Foundation a publié des correctifs pour contenir la vulnérabilité dans les versions 2.15.0 et ultérieures.

Selon les experts en sécurité, cette faille dans Apache Log4j pourrait probablement être considérée comme la vulnérabilité la plus critique découverte au cours de cette année 2021.

Actuellement, des Proof of Concept (PoC) ont été publiées et la vulnérabilité est activement exploitée. Des entreprises de cybersécurité telles que BitDefender, Cisco Talos, Huntress Labs et Sonatype confirment l’existence de scans massifs des applications concernées à la recherche de serveurs vulnérables et ont enregistré des attaques contre leurs pots de miel. Selon les déclarations de Cloudflare, ils ont été contraints de bloquer environ 20 000 requêtes par minute cherchant à exploiter la faille de sécurité ; ces attaques se sont produites vers 18 h UTC vendredi dernier et provenaient principalement du Canada, des États-Unis, des Pays-Bas, de la France et du Royaume-Uni.

Compte tenu de la facilité d’exploitation, les attaques visant les serveurs sensibles devraient continuer à se multiplier au cours des prochains jours. Il est donc fortement recommandé de s’attaquer immédiatement au problème.

La mise à niveau de la bibliothèque vers Apache Log4j 2.15.0 ou une version ultérieure corrige la faille de sécurité. Toutefois, s’il n’est pas possible d’appliquer les correctifs de sécurité, les contre-mesures suivantes sont recommandées pour atténuer le problème :

  • Dans les versions 2.10 à 2.14.1, il est recommandé de définir le paramètre log4j2.formatMsgNoLookups ou la variable d’environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true.
  • Dans les versions inférieures à 2.10 et jusqu’à 2.0-beta9, supprimez la classe JndiLookup du chemin des classes (en utilisant la commande zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).

Il est également recommandé d’effectuer des contrôles pour déterminer si une application est potentiellement vulnérable à la vulnérabilité « Log4Shell » en recherchant les fichiers correspondant au motif : log4j-core-*.jar. L’emplacement de ces fichiers indique quelle application doit être vérifiée (par exemple, sous Windows, si le fichier se trouve dans C:\Program Files\ApplicationName\log4j-core-version.jar, cela indique que l’application potentiellement affectée est ApplicationName). Sur les systèmes GNU/Linux, la commande lsof peut également être utilisée pour déterminer quels processus ont ces fichiers en cours d’utilisation.

Enfin, une compilation des hachages des différentes versions de la bibliothèque vulnérable est fournie sur GitHub pour faciliter leur recherche sur les systèmes.

Plus d’information :
log4shell/README.md at main · NCSC-NL/log4shell · GitHub
https://logging.apache.org/log4j/2.x/security.html
https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

Paquets malveillants dans le dépôt PyPI

Plusieurs paquets open source malveillants ont été découverts dans le populaire dépôt PyPI. Ils utilisent de nouvelles techniques pour ne pas être détectés.

PyPI (Python Package Index) est le dépôt officiel de logiciels pour les applications tierces dans le langage de programmation Python où des milliers de programmeurs publient leurs développements. Toutefois, les développeurs de logiciels malveillants profitent également de cette plateforme pour atteindre leurs objectifs.

L’équipe de recherche de JFrog Security a découvert jusqu’à 11 nouveaux paquets malveillants hébergés sur PyPI, avec plus de 40 000 téléchargements au total. Leurs auteurs ont utilisé plusieurs techniques avancées pour éviter la détection et rester dans le dépôt afin d’infecter le plus grand nombre de machines possible.

Liste des paquets malveillants. Source : jfrog.com

Les techniques utilisées sont les suivantes :

  • Utilisation du CDN Fastly pour faire croire que le trafic envoyé au serveur de commande et de contrôle (C2) est une communication légitime avec pypi.org.
  • Utilisation du cadre TrevorC2 pour masquer les communications client-serveur en les faisant ressembler à une navigation normale sur un site web, en envoyant des requêtes à des intervalles aléatoires et en cachant la charge utile malveillante dans des requêtes HTTP GET d’apparence normale.
  • L’utilisation des requêtes DNS comme canal de communication entre la machine victime et le serveur C2, en profitant du fait que ces requêtes ne sont normalement pas inspectées par les outils de sécurité. Lorsqu’un serveur DNS reçoit une demande, il recherche dans ses enregistrements l’adresse IP correspondant au nom de domaine demandé et, s’il ne la trouve pas, il envoie la demande au premier nom de domaine connu de l’adresse. En d’autres termes, si la demande est du type payload.domainemalveillant.com, comme le serveur DNS légitime qui reçoit la demande ne connaît pas la résolution de cette adresse, il la transmettra à domainemalveillant.com et il saura que la chaîne utilisée comme sous-domaine est le payload.
  • La division des paquets malveillants en deux parties : l’une étant l’élément malveillant et l’autre un paquet « légitime » qui précise simplement le paquet malveillant à importer. A partir de ces derniers, l’installation du paquet malveillant serait effectuée par « typosquattage » (paquets dont les noms sont des fautes de frappe de paquets populaires) ou « confusion de dépendance » (paquets malveillants portant le nom de paquets privés légitimes avec une version supérieure téléchargés dans des dépôts publics, forçant ainsi le gestionnaire de paquets à télécharger et installer le module malveillant).

Selon les déclarations des chercheurs en sécurité, ces paquets ne se distinguent pas par leur dangerosité, mais ce qui est remarquable, c’est le niveau croissant de sophistication avec lequel ils ont été développés.

Il convient de noter que les administrateurs du dépôt PyPI ont supprimé les paquets malveillants après avoir reçu le rapport.

Plus d’information:
https://jfrog.com/blog/python-malware-imitates-signed-pypi-traffic-in-novel-exfiltration-technique/

Cloudflare atténue une attaque DDoS avec des pics de trafic de 2Tbps

Cloudflare, une société américaine de gestion de contenu, de sécurité Internet et de serveurs de noms de domaine distribués, a détecté et bloqué avec succès une attaque par déni de service distribué (« DDoS »), avec des pics allant jusqu’à 2Tbps, la plus puissante observée à ce jour.

L’entreprise a publié un rapport d’incident, qui indique que l’attaque a été menée par un réseau d’environ 15 000 bots exécutant une variante du malware Mirai, qui affecte les appareils IoT. Les appareils identifiés dans le botnet auraient été infectés par l’exploitation d’une vulnérabilité d’exécution de code à distance dans une version non corrigée de Gitlab (CVE-2021-22205), pour laquelle il existe des exploitations publiques qui ont été activement exploitées entre juin et juillet 2021.

Source : blog.cloudflare.com

Les attaques identifiées dans le DDoS étaient des attaques d’amplification DNS et d’inondation UDP. Ces attaques consistent à profiter de la fonctionnalité mise en œuvre par les serveurs de résolution DNS en effectuant des requêtes avec un trafic amplifié, dans le but de rendre le serveur et son infrastructure inaccessibles. D’autre part, les attaques par inondation UDP consistent à envoyer des paquets UDP massifs afin de rendre le serveur incapable de traiter et de répondre à de nouvelles demandes légitimes.

Selon l’entreprise, les attaques DDoS de haute intensité avec un trafic de l’ordre du térabit sont en augmentation, de multiples attaques de ce type ayant été reçues au cours du dernier trimestre de cette année.

Plus d’information:
https://blog.cloudflare.com/cloudflare-blocks-an-almost-2-tbps-multi-vector-ddos-attack/

Crackonosh

Le malware Crackonosh est surprenant non pas par son objectif ou sa formule de propagation, mais par sa technique pour passer inaperçu. Pour se propager, il utilise les cracks typiques et les téléchargements « warez » que l’utilisateur exécute lui-même, parfois même en mode administrateur. Sa formule pour atteindre l’utilisateur n’est donc pas très intéressante. Cependant, une fois exécuté, il modifie le système pour qu’il fonctionne en mode sans échec et redémarre en mode sans échec. Dans ce mode, Windows lance le strict minimum (y compris les pilotes) pour fonctionner et ne lance donc pas le système antivirus. Une fois dans ce mode, désactivez Defender et voyez s’il existe un autre antivirus pour le neutraliser également. Au prochain redémarrage « normal », ils ne fonctionneront plus.

Il désactive également les mises à jour et place une fausse icône verte de « vérification » sur le système afin que l’utilisateur ne remarque rien d’anormal. Il est intéressant de noter qu’il n’utilise pas de commande et de contrôle, mais envoie des paquets UDP à des adresses IP aléatoires. S’il y trouve de nouvelles versions de lui-même, il se met à jour à partir de ce système infecté.

Enfin, il extrait du Monero en « empruntant » des ressources système sans être détecté. Cela lui a permis de ne pas être détecté depuis 2018.

Plus d’information:
https://decoded.avast.io/danielbenes/crackonosh-a-new-malware-distributed-in-cracked-software/

Page 6 of 6

Fièrement propulsé par WordPress & Thème par Anders Norén