Nouveau DemonBot Découvert – Boulevard de la sécurité – Bien choisir son serveur d impression
Utilisez-vous Hadoop pour l'analyse de données? Si tel est le cas, sachez qu'un nouveau bot cible les clusters Hadoop dans le but de lancer des attaques DDoS s'appuyant sur la puissance des serveurs d'infrastructure cloud. Hadoop est une infrastructure de traitement distribué open source qui gère le stockage et le traitement des données pour les applications Big Data exécutées dans des systèmes en cluster.
Radware Threat Research Center surveille et surveille un agent malveillant qui exploite l'exécution d'une commande à distance non authentifiée Hadoop YARN afin d'infecter les clusters Hadoop avec un nouveau bot peu sophistiqué qui s'identifie comme DemonBot.
DemonBot ne se propage que via des serveurs centraux et n'expose pas le comportement semblable à un ver présenté par les robots basés à Mirai. À ce jour, Radware surveille plus de 70 serveurs d’exploitation actifs qui répandent activement DemonBot et exploitent les serveurs à un taux cumulé de plus d’un million d’explosions par jour. Notez que, même si nous n'avons trouvé aucune preuve que DemonBot cible activement les appareils IoT pour le moment, Demonbot n'est pas limité aux serveurs x86 Hadoop et est compatible binaire avec la plupart des appareils IoT connus, conformément aux principes de construction Mirai.
Ce n'est pas la première fois que les serveurs d'infrastructure cloud sont ciblés. Plus tôt ce mois-ci, Ankit Anubhav, chercheur en sécurité, a découvert un pirate informatique exploitant le même bogue Hadoop Yarn dans une variante du botnet Sora. Les clusters Hadoop sont généralement des plates-formes très capables et stables, capables de représenter individuellement des volumes de trafic DDoS beaucoup plus importants que les périphériques IoT. Les vecteurs d’attaque DDoS pris en charge par DemonBot sont les inondations UDP et TCP.
Sommaire
Les exploits de Hadoop YARN
Radware Research suit des acteurs malveillants exploitant une exécution de commande à distance non authentifiée Hadoop YARN pour laquelle le code de preuve de concept a été publié pour la première fois ici en mars dernier. YARN, encore un autre négociateur de ressources, est une condition préalable à Enterprise Hadoop et offre une gestion des ressources de cluster permettant à plusieurs moteurs de traitement de données de gérer les données stockées sur une seule plate-forme. YARN expose une API REST qui permet aux applications distantes de soumettre de nouvelles applications au cluster. L'exploit nécessite deux étapes:
Notre réseau de tromperie a enregistré des tentatives répétées pour / ws / v1 / cluster / apps / nouvelle-application, commençant lentement fin septembre et atteignant plus d'un million de tentatives par jour pendant la majeure partie du mois d'octobre.
Le nombre d'adresses IP uniques à l'origine des demandes est passé de quelques serveurs à plus de 70 serveurs cette semaine.
Les anciens exploits de serveurs hors ligne faisaient maintenant référence à une variante connue de Mirai, Owari, tristement célèbre en raison du faible mot de passe utilisé par les pirates pour sécuriser leur base de données de commande et de contrôle:
Plus récemment, cependant, nous avons trouvé Owari remplacé par un nouveau bot:
Ce nouveau binaire ‘bash’ a été ajouté au serveur le dimanche 21 octobre.st. Le même serveur héberge également le script shell typique que nous attendions des malwares IOT multiplateformes:
Alors que le botnet contient tous les indicateurs typiques de Yet-Another-Mirai-Botnet, un examen plus attentif des fichiers binaires s’est révélé suffisamment différent pour permettre la poursuite de l’enquête.
DemonBot v1 – © Self-Rep-NeTiS
L’inversion du binaire non-dépouillé ‘bash’ a révélé des noms de fonctions inconnus et une chaîne atypique qui fournissait une empreinte unique pour le code du botnet:
La recherche dans les archives de pastebin a rapidement révélé une correspondance unique avec un document collé le 29 septembre.th par un acteur allant par le pseudonyme de Self-Rep-NeTiS. La pâte contenait le code source complet d’un réseau de zombies que l’acteur a surnommé «DemonBot». Des recherches ultérieures dans les archives ont révélé le code source du serveur de commande et de contrôle DemonCNC et le script Python Build des robots multi-plateformes.
DemonBot.c et DemonCNC.c avaient tous deux une signature identique:
DemonCNC
Le service DemonBot Command and Control est un programme C autonome censé s'exécuter sur un serveur de commande et de contrôle central. Il fournit deux services:
- Un service d'écoute de commande et de contrôle de bot permettant aux bots de s'inscrire et d'écouter les nouvelles commandes de la C2
- CLI d’accès à distance permettant aux administrateurs de botnet et aux «clients» potentiels de contrôler l’activité du botnet
Le démarrage du service C2 nécessite 3 arguments: un port d'écoute de bot, le nombre de threads et un port pour la CLI d'accès distant.
Les informations d’identité des utilisateurs distants sont stockées dans un fichier texte «login.txt» au format «nom d’utilisateur mot de passe» avec une ligne par paire d’informations d’identité.
Lors de la connexion à la CLI d'accès à distance (port 8025 dans notre configuration de démonstration) à l'aide de telnet, le botnet nous salue et demande un nom d'utilisateur suivi d'une invite de mot de passe. Si les informations d'identification fournies correspondent à l'une des lignes du fichier login.txt, l'utilisateur est autorisé à accéder à l'interface de contrôle de bot.
La commande HELP révèle les commandes de botnet qui seront discutées ci-dessous dans la section sur DemonBot lui-même.
DemonBot
DemonBot est le programme supposé fonctionner sur des serveurs infectés. Il se connecte au serveur de commande et de contrôle et écoute les nouvelles commandes.
Lorsqu'un nouveau DemonBot est démarré, il se connecte au serveur C2 qui est codé en dur avec IP et port. Si aucun port n'a été spécifié pour le serveur C2, le port par défaut 6982 est utilisé. La connexion C2 est en texte brut TCP.
Une fois la connexion établie, DemonBot envoie les informations sur le périphérique infecté au serveur C2 au format suivant:
Bot_ip
L'adresse IP publique du périphérique ou du serveur infecté par DemonBot:
Port
22 ou 23 selon la disponibilité de python ou de perl et telnetd sur le périphérique / serveur:
Construire
“Périphérique Python”, “Périphérique Perl”, “Périphérique Telnet” ou “Inconnu” en fonction de la disponibilité d'un interpréteur Python ou Perl sur le serveur de périphériques:
Cambre
L'architecture, déterminée au moment de la construction et en fonction du binaire d'exécution sur la plate-forme compromise – les valeurs prises en charge pour Arch sont les suivantes: x86_64 | x86_32 | Arm4 | Arm5 | Arm6 | Arm7 | Mips | Mipsel | Sh4 (SuperH) | Ppc (PowerPC) | spc (Sparc) | M68k | Arc
OS
Identification limitée du système d'exploitation hôte exécutant le bot en fonction des fichiers de configuration du programme d'installation du package. La valeur est “Périphérique Debian”, “Périphérique REHL” ou “Système d'exploitation inconnu”
Charges utiles malveillantes
Le bot supporte les commandes suivantes:
Si plusieurs arguments sont passés dans l'argument dans une liste séparée par des virgules, un processus d'attaque individuel est créé pour chaque adresse IP.
le
Charge utile fixe utilisée par l'attaque STD UDP:
CIO
8805830c7d28707123f96cf458c1aa41 wget
1bd637c0444328563c995d6497e2d5be tftp
a89f377fcb66b88166987ae1ab82ca61 sshd
8b0b5a6ee30def363712e32b0878a7cb sh
86741291adc03a7d6ff3413617db73f5 pftp
3e6d58小f10a6320185743d6d010c4f openssh
fc4a4608009cc24a757824ff56fd8b91 ntpd
d80d081c40be94937a164c791b660b1f ftp
b878de32a9142c19f1fface9a8d588fb cron
46a255e78d6bd3e97456b98aa4ea0228 bash
53f6451a939f9f744ab689168cc1e21a apache2
41edaeb0b52c5c7c835c4196d5fd7123 [cpu]
Lisez le «Manuel d'attaque IoT – Un guide de terrain pour comprendre les attaques IoT à partir du botnet Mirai et de ses variantes modernes» pour en savoir plus.
Télécharger maintenant
Commentaires
Laisser un commentaire