Symbiote est un rootkit Linux particulièrement méchant, et nous avons le cas intéressant de deux analyses distinctes publiées cette semaine. Le premier est [CyberMasterV] en démontant un échantillon très précoce du logiciel malveillant. L’objectif principal de Symbiote semble être de capturer les connexions SSH, et cette version le fait en connectant le système de modules d’authentification enfichables (PAM) pour capturer les utilisateurs se connectant à la machine sur laquelle il réside. Il surveille également les binaires SSH et SCP et renifle le terminal utilisé par ces binaires, capturant ainsi les informations d’identification sortantes.
Toutes ces données sont regroupées sous forme de requêtes DNS et transférées vers le serveur de commande et de contrôle. « Facile », je vous entends dire, « bloquez simplement le trafic DNS vers partout sauf un fournisseur DNS de confiance. » C’est plus malin que ça. Les données se présentent sous la forme de sous-domaines DNS valides. Dans son intégralité, il s’agit d’une requête DNS pour PacketNumber.MachineID.Data.px32.nss.atendimento-estilo[.]com, tous codés de manière appropriée pour être valides. Chaque demande concernera un nom d’hôte unique, de sorte que chaque demande est transmise au contrôleur C&C, qui fait également office de résolveur DNS faisant autorité pour ce domaine. Vous pourriez gagner du temps en bloquant (ou au moins en enregistrant) de très longues requêtes DNS.
Symbiote remplace également les fichiers et appareils typiques que vous examineriez pour trouver un problème potentiel. Par exemple, /proc/net/tcp est l’endroit où le noyau signale les connexions TCP ouvertes. Sur une machine infectée, une copie de ce fichier est conservée par le logiciel malveillant, omettant commodément les connexions résultant des infections. Symbiote a un crochet dans fopen, donc chaque fois qu’un processus essaie de lire cet emplacement, la lecture est redirigée vers la version cuite, masquant soigneusement le rootkit. Cette fonctionnalité furtive est apparemment également utilisée pour cacher d’autres logiciels malveillants aux mêmes attaquants qui peuvent se trouver sur la même machine.
Regardons maintenant la deuxième analyse, un effort conjoint de BlackBerry et Intezer. Ceci provient d’un échantillon ultérieur de Symbiote, et il y a eu une évolution intéressante. Le plus notable est qu’il utilise le filtre de paquets Berkeley (BPF) pour masquer son trafic des captures de paquets. Étant donné que les filtres BPF s’exécutent directement dans le noyau, il s’agit d’une technique furtive très puissante. Symbiote détecte même une série de ldd, qui le répertorierait comme une bibliothèque en cours d’exécution. Cela aussi est désinfecté, ce qui rend Symbiote très difficile à détecter. Il devrait être possible d’utiliser les fonctionnalités de rootkit de Symbiote contre lui, pour la détection. Par exemple, l’un des noms de fichiers masqués est apache2start. Il devrait être possible de touch ce nom de fichier, puis exécutez ls sur le répertoire qui doit le contenir. Si le nouveau fichier est répertorié, vous allez probablement bien. S’il manque, il y a de fortes chances que le rootkit soit en cours d’exécution. Nous avons contacté les chercheurs pour obtenir de l’aide afin de confirmer cette technique de détection simple, alors restez à l’écoute pour une éventuelle mise à jour.
Serrures « intelligentes »
Encore une fois, en matière d’IoT, le S signifie sécurité. Le plaisir commence par une erreur classique, ne faisant pas réellement de vérification SSL. Ainsi, le micrologiciel contacte un serveur HTTPS pour fonctionner, mais acceptera tout certificat pour cette connexion. L’homme du milieu est beaucoup plus facile dans ce cas. Et cette position MitM se marie bien avec le problème suivant que les chercheurs du groupe NCC ont trouvé, un débordement de mémoire tampon dans l’analyse JSON. Mettez ces deux éléments ensemble et, assis sur le même réseau que le verrou, votre code s’exécute dessus.
Pour la plupart d’entre nous, un attaquant sur le réseau interne, voire dédié à l’IoT, est déjà une catastrophe. Il y a une autre chaîne d’attaque qui a été découverte. La façon dont cette serrure est généralement installée est avec un «tournevis» installé dans une porte, physiquement inaccessible jusqu’à ce que la porte soit déverrouillée et ouverte. La seconde moitié est le « clavier », la pièce destinée au public où le code est saisi. En théorie, ce clavier ne devrait pas être approuvé par le matériel du tourne-clés et devrait simplement transmettre les frappes sur la liaison BLE. En pratique, le clavier peut envoyer une demande de déverrouillage sans le code, et déverrouiller la porte.
Cela conduit à l’élément final, les ports JTAG accessibles sur le clavier. JTAG est une interface de débogage pour les périphériques embarqués, extrêmement utile pour flasher le micrologiciel sur des périphériques autrement maçonnés, ainsi que pour effectuer un débogage en temps réel. C’est ce dernier qui fait le travail ici. Connectez-vous au port JTAG du clavier et récupérez les données d’authentification de la mémoire. Utilisez ensuite un appareil différent et les données d’authentification pour usurper le clavier et envoyer des commandes arbitraires via la liaison BLE. Demandez poliment au tourneur de clé de déverrouiller, et il le fera. Avec une plate-forme dédiée et un peu de pratique, l’ensemble du processus pourrait probablement être réduit à quelques secondes. Ouf !
La doublure argentée est que Nuki, le fabricant de cette serrure, a fait un travail remarquable pour gérer le rapport de vulnérabilité. Les correctifs sont sortis moins de deux mois après que les problèmes ont été signalés. Les clients actifs ont reçu des avis, puis après une période de temps appropriée, les vulnérabilités ont été divulguées publiquement.
Votre serveur est compromis
Vous recevez un appel ou un e-mail de votre société d’hébergement, Linode dans ce cas, indiquant que votre serveur hébergé participe à une attaque DoS. Vous êtes probablement Pwned.
Et après? Les chercheurs de Trunc ont quelques conseils. Tout d’abord, il est utile d’avoir quelque chose comme sysstat en cours d’exécution, un démon de collecte de statistiques système. La prochaine étape consiste à connecter SSH à la machine et à utiliser certains outils. last affiche l’historique de connexion de la machine, top répertorie l’utilisation du processeur et de la mémoire par processus, df affiche l’espace disque libre, ps répertorie les processus en cours d’exécution, et lsof affiche la liste des fichiers ouverts. À moins que vous n’ayez affaire à un rootkit vraiment méchant, comme Symbiote discuté ci-dessus, ces outils devraient révéler quelque chose d’inhabituel. Si sysstat est en cours d’exécution, sar -n DEV donne des données sur l’utilisation du réseau au fil du temps. Si cette machine envoie beaucoup de trafic, elle devrait apparaître ici, vous donnant une bonne idée du moment où les choses ont commencé.
Le système en question a montré un gros pic de trafic, et le apache le binaire exécutait une utilisation CPU très élevée. Cela semblait étrange. Les journaux contenaient quelques entrées indiquant un appel à POST //xmlrpc.php HTTP/1.1. Bien que ce point de terminaison puisse être abusé pour la réflexion DDoS, il n’y avait pas suffisamment d’entrées de journal pour suggérer ce problème. La prochaine étape consiste donc à rechercher des fichiers modifiés. Il existe des options pour cela, comme OSSEC, mais ils doivent être exécutés sur la machine dans un état correct. Alors, comment vérifiez-vous les fichiers falsifiés si vous ne l’avez pas en place ? Si vous utilisez WordPress, vous pouvez simplement télécharger et décompresser une nouvelle copie de l’archive d’installation correspondant à votre version installée. Décompressez-le et utilisez diff pour trouver d’éventuelles différences. L’une de ces différences peut être un webshell injecté dans l’un des fichiers PHP de WordPress.
REstringer désobscurcit Javascript
En tant que pirate informatique, l’un des problèmes les plus irritants est le code obscurci. Javascript est intrinsèquement ouvert, mais les techniques d’obscurcissement rendent la source totalement illisible. [Ben Baryo] travaille sur une solution, un désobfuscateur qu’il appelle REstringer. Il essaie de faire correspondre le type d’obscurcissement utilisé, puis passe en revue les méthodes de désobscurcissement sûres. Il y a là une mise en garde importante. Il peut être très difficile de désobscurcir du code sans exécuter accidentellement des parties de ce code. Il s’agit toujours d’un travail en cours, alors consultez le code ou essayez la démo en direct.
Rootkits UEFI
Il y a quelque chose d’un Boogeyman dans la sécurité informatique, le malware mythique qui s’intègre dans le micrologiciel d’un ordinateur, rendant la suppression impossible. Bien qu’il soit théoriquement possible que le micrologiciel d’une carte mère puisse être altéré de cette manière, ce n’est sûrement qu’un mythe, et peut-être utilisé par les acteurs étatiques pour leurs cibles les plus importantes.
Cette théorie a pris un coup, car un rootkit qui utilise exactement cette technique est apparu dans la nature. Les chercheurs de Kaspersky l’ont surnommé CosmicStrand et notent que des infections ont été trouvées en Chine, au Vietnam, en Iran et en Russie. Certains indices dans le code suggèrent une origine chinoise et une connexion possible à d’autres logiciels malveillants provenant également de cette région.
Techniquement, utiliser un micrologiciel malveillant pour amorcer une réinfection est tout un exploit. Tout d’abord, gardez à l’esprit que ce code s’exécute pendant l’initialisation de la machine, bien avant que le système d’exploitation Windows ne commence à s’exécuter. Comment le code du rootkit parvient-il à effectuer une infection sophistiquée alors que sa propre exécution se termine bien avant que le noyau Windows ne commence à s’exécuter ?
Il implante du code dans le gestionnaire de démarrage Windows, qui à son tour place des crochets dans le chargeur du système d’exploitation Windows. Ce chargeur fait partie du processus de démarrage de Windows et permet de cibler davantage de manipulations sur le noyau Windows lui-même. Et enfin, une fois le noyau démarré, cette charge utile déploie le shellcode réel. La sophistication de ce malware est assez surprenante.
