Archives par mot-clé : Hide ‘N Seek

Hide’N Seek : botnet à la sauce brute force

Détection d’un nouveau botnet IoT baptisé Hide ‘N Seek, utilisant son propre système de communication peer-to-peer.

Les chercheurs des Bitdefender Labs ont détecté l’émergence d’un botnet qui utilise des techniques de communication avancées pour infecter les victimes et créer son infrastructure. Le botnet, baptisé HNS (Hide ‘N Seek), a été intercepté par notre système d’honeypots d’objets connectés suite à une attaque par force brute via le service Telnet.

Le bot a été détecté pour la première fois le 10 janvier, puis a disparu quelques jours après, avant de réapparaitre le 20 janvier sous une forme nettement améliorée.

Impact

Le botnet HNS communique d’une manière complexe et décentralisée et utilise de multiples techniques contre l’altération pour empêcher qu’un tiers puisse le détourner. Le botnet peut procéder à l’exploitation web de toute une série d’appareils via le même exploit que Reaper (CVE-2016-10401 et d’autres vulnérabilités des équipements réseau). Le botnet embarque une multitude de commandes permettant l’exfiltration des données, l’exécution de code et la perturbation du fonctionnement d’un appareil.

Fonctionnement Hide ‘N Seek

Le botnet intègre un mécanisme d’autoréplication qui génère de manière aléatoire une liste d’adresses IP pour obtenir des cibles potentielles. Il initie ensuite une connexion raw socket avec flag SYN avec chaque hôte de la liste et continue à communiquer avec ceux ayant répondu à la requête sur des ports de destination spécifiques (23 2323, 80, 8080). Une fois la connexion établie, le botnet recherche si une bannière spécifique (« buildroot login: ») est présente chez la victime. S’il détecte cette bannière de connexion, il tente de se connecter à l’aide d’un ensemble d’identifiants prédéfinis. En cas d’échec, le botnet tente une attaque par force brute en utilisant une liste codée en dur.

Une fois qu’une session est établie avec une nouvelle victime, l’échantillon exécute un automate pour identifier correctement l’appareil ciblé et sélectionne la méthode de compromission la plus adaptée. Par exemple, si la victime a le même LAN que le botnet, celui-ci crée un serveur TFTP pour permettre à la victime de télécharger le code malveillant depuis le bot. Si la victime est connectée à Internet, le bot tente d’utiliser une méthode spécifique d’installation de charge active à distance, pour que la victime télécharge et exécute l’échantillon du malware. Ces techniques d’exploitation sont préconfigurées et stockées dans une adresse mémoire signée numériquement pour empêcher les modifications. Cette liste peut être mise à jour à distance et diffusée parmi les hôtes infectés.

Les échantillons identifiés par nos honeypots le 10 janvier s’attaquent à des caméras IP fabriquées par une entreprise coréenne. Ces appareils semblent jouer un rôle majeur sur le fonctionnement du botnet, car sur les 12 adresses codées en dur dans l’échantillon, 10 appartiennent à des appareils de la marque Focus H&S. La nouvelle version, détectée le 20 janvier, n’utilise plus d’IP codées en dur.

Comme d’autres botnet, HNS n’est pas persistant, et un simple redémarrage permet de nettoyer les appareils infectés. Il s’agit du second botnet connu à ce jour, après le célèbre botnet Hajime, qui utilisait lui aussi une architecture peer-to-peer décentralisée. Néanmoins, dans le cas de Hajime, la fonctionnalité p2p était basée sur le protocole BitTorrent, tandis qu’il s’agit ici d’un système p2p conçu sur mesure.

Hide ‘N Seek : Mécanisme de communication UDP

Le botnet ouvre un port aléatoire sur la victime et ajoute des règles de pare-feu pour permettre le trafic entrant sur ce port. Il reste ensuite en écoute sur ce port ouvert et n’accepte que les commandes décrites ci-dessous. Notre analyse initiale de l’échantillon a révélé la présence d’une clé basée sur les courbes elliptiques à l’intérieur du fichier utilisé pour authentifier la commande de mise à jour de la zone mémoire où sont stockées les options de configuration afin d’empêcher les tentatives d’infiltration ou d’infection du botnet.

Une fois exécuté, le botnet reste à l’écoute des commandes transmises soit sur le port indiqué à l’exécution soit, le cas contraire, sur un port généré aléatoirement. S’il reçoit une commande, le bot répond habituellement à l’expéditeur avec un paquet qui respecte le protocole de communication pré-établi. Comme l’analyse et le traitement des données sont exactement les mêmes en mode récepteur et émetteur, nous pouvons en conclure que la communication du botnet est basée sur une architecture peer-to-peer.

Outre leurs capacités de bot, les codes analysés intègrent également un composant de serveur web qui héberge et sert des fichiers binaires à d’autres victimes potentielles.