Le 27 avril 2012

Doctor Web continue à étudier le premier botnet important crée par BackDoor.Flashback touchant Mac OS X. Nous avons notamment étudié les objets que le trojan télécharge depuis les serveurs des malfaiteurs et lance sur les Mac.

Nous vous rappelons que BackDoor.Flashback.39 utilise les vulnérabilités Java, sauvegarde un fichier exécutable et un fichier lançant l’application sur le disque dur. Ensuite, launchd reçoit un fichier de configuration, qui permet au trojan de se lancer à l’insu de l’utilisateur. BackDoor.Flashback.39 se connecte au serveur de gestion, télécharge un fichier exécutable et l’installe. Ensuite, le trojan affiche une fenêtre pour entrer le mot de passe administrateur, si l'utilisateur entre le mot de passe, le programme malveillant obtient les droits d’administrateur, mais si le mot de passe n’est pas entré, le trojan fonctionne avec les droits d’utilisateur en cours. Les droits d’utilisateur sont suffisants pour assurer le fonctionnement du trojan.

Deux types de serveurs de gestion sont utilisés. Les premiers interceptent les données SERP, dirigent l’utilisateur vers les sites des malfaiteurs, et interceptent également certaines actions de l’utilisateur. Les autres (ci-après deuxième catégorie) envoient des commandes aux bots, ils jouent le rôle de backdoor. Doctor Web a réussi à contrôler les domaines payload des serveurs de gestion BackDoor.Flashback et à analyser les demandes des bots.

Les noms de la plupart des domaines sont générés en utilisant les paramètres de configuration intégrés dans les ressources du logiciel malveillant, les autres noms sont fonction de la date courante. De plus, le nom du domaine de deuxième niveau est le même, tandis que dans les noms des domaines de haut niveau, différentes variantes sont utilisées, comme .org, .com, .co.uk, .cn, .in. Le trojan envoie successivement des requêtes aux serveurs de gestion selon les priorités préconfigurées : une requête GET /owncheck/ ou /scheck/ avec un UUID de Mac infecté dans le champ useragent est envoyé au serveur de gestion. Si le trojan reçoit en réponse SHA1 signé, le domaine correspondant est considéré comme vérifié et il est ensuite utilisé comme serveur de gestion. Les premiers domaines de cette catégorie ont été interceptés par Doctor Web le 12 avril 2012.

Lorsque le programme malveillant a vérifié le domaine de la première catégorie, il recherche les domaines de la seconde catégorie. Le trojan envoie successivement des requêtes GET /auupdate/ aux serveurs de gestion contenant dans le champ useragent des informations détaillées sur l'OS. Exemple d’une telle requête :

20|i386|9.8.0|4DE360BE-E79E-5AD6-91CF-D943761B3785|6bbbbfb49b1659ebaaadffa20215bfc787577bd8|001|007|0

Où :

1. est la version de bot
2. est l’architecture (hw.machine)
3. est la version du noyau (kern.osrelease)
4. est l’UUID
5. est SHA1 de payload
6. est un masque de navigateurs internet supplémentaires
7. est une constante
8. signifie les droits (les privilèges) du bot : 0 — utilisateur, 1 — administrateur.

Si le serveur de gestion ne répond pas correctement, le trojan crée une phrase hashtag http://mobile.twitter.com/searches?q=#<la phrase> en fonction de la date. Par exemple, pour la date du 13.04.2012 , certaines versions du trojan créent une phrase «rgdgkpshxeoa» (cette phrase dépendra de la version du bot). Si un message dans Twitter contient bumpbegin et endbump avec une adresse du serveur de gestion, cette adresse sera utilisée comme nom du domaine. Ces domaines ont été interceptés par Doctor Web le 13 avril, mais dès le 14 avril, ce compte utilisateur dans Twitter était fermé.

Au 13 avril 2012, les serveurs de gestion du premier groupe ont reçu 30 549 requêtes aves des UUID uniques, les serveurs du deuxième groupe ont reçu 28 284 requêtes avec des UUID uniques. Le nombre total de requêtes avec UUID uniques du 12 au 26 avril 2012 est de 95 563. Voici un schéma reflétant d’autres requêtes du 13 avril 2012 :