Plusieurs dizaines de domaines distincts hébergés sur une classe d'adresse IP appartenant à OVH (Pologne) ont été utilisés ces dernières semaines comme relais de messagerie au sein de campagnes de spams. Les domaines présentent un contenu identique, associé au domaine "emailcloud.me" :

Dans certains cas, le formulaire abuse est directement affiché au lieu de cette interface d'administration. Ce formulaire comporte une formulation pour le moins étonnante :

Emailcloud.me ne présente de son côté depuis plusieurs semaines qu'une page d'attente pour cause de maintenance. Mais les caches des moteurs de recherche ne l'ont pas (encore) oublié :

Presque tous les domaines utilisés ont été déposés via des services d'anonymisation de l'identité du détenteur. Seul le whois du domaine "irie.hu", accessible sur la même IP que emailcloud.me, n'a pas été anonymisé. Il est probable que cette option, disponible pour des domaines enregistrés sur des extensions génériques (com, net, org, info, etc.), ne le soit pas pour les domaines avec extension hongroise.

Whois de irie.hu :

Tibor Divo
Vaci str 138C
1132 Budapest
HU
+36-205559095
iriehu@gmail.com

L'indisponibilité d'emailcloud.me provient potentiellement du fait que le site a été défacé (en décembre a priori) comme le montre ce lien et d'autres défacements revendiqués sous ce nom. La "société" a cependant été active pendant plusieurs mois et disposait d'un compte Twitter sur lequel a notamment été annoncé le lancement de son offre "ECMTA" (probablement pour Email Cloud Mail Transfer Agent) v3.

Ecmta.biz est en effet associé à emailcloud.me, puisqu'on retrouve ce domaine sur la même IP et comme enregistrement PTR des domaines identifiés auparavant. Mais l'adresse email manager@ecmta.biz est par ailleurs enregistrée comme contact pour la classe d'adresse IP : 85.25.168.191/27 détenue par :

Lovas Fruzsnica
Vaci str 138C
1132 Budapest
HU
+36-20-5559094
manager@ecmta.biz

Soient 2 identités à la même adresse, avec un numéro de téléphone consécutif…

Par ailleurs, cette adresse postale à Budapest a été utilisée par le passé pour déposer plusieurs autres domaines présentant le même contenu, mais via l'adresse e-mail: support@emailcloud.info.

Or, emailcloud.info est détenu par une société apparemment basée au Panama.

Mosa Fantan
X-PLAY INTERACTIVE Ltd.
Oho del Vidro 115
Santiago de Veraguas Jose AH3412
PA
+36.706668998
smsweb@ragesms.com

Notez que l'indicatif téléphonique du Panama est plutôt le +507 et non le +36 qui est celui de la Hongrie.

La résolution DNS du domaine emailcloud.me donne l'adresse IP 46.19.137.50, appartenant à une classe IP d'un hébergeur hongrois.

Détenteur de 46.19.137.48/29 :

Radnai Peter
Vaci str 34
1134 Budapest
Hungary
manager@ingyenpenz.com
+36204567891

Notez le pattern "manager@domaine" et que les 2 adresses postales à Budapest ne sont séparées que de quelques pâtés de maison…

Le domaine ingyenpenz.com, retombé dans le domaine public depuis le 20 octobre, avait de son côté été déposé via une identité équatorienne. Mais celle-ci est potentiellement fictive. En effet, l'adresse e-mail de contact renseignée provient d'un service de webmail hongrois, qui n'a d'ailleurs pas de version hispanophone (ni anglophone).

Whois de ingyenpenz.com :

Andrade, Francisco
mospam@ar.hu
Marin 188 y Almagro
Quito, na 346628
Ecuador
+593.22364459

L'enquête pourrait se poursuivre sur ce détenteur, qui possède plusieurs autres domaines également identifiés dans des spams, en particulier en langue hongroise. Mais "hongrois" pas que ce soit nécessaire. Pour information "Ingyen penz" signifie en Hongrois: "De l'argent gratuit"

La classe IP louée par cet équatorien magyarophone est fournie par le prestataire (suisso-)panaméen Privatelayer.com/.com.pa (AS51852/AS52288). Une coïncidence probablement...

Ca bouge au pays du .fr(omage) : l'AFNIC, registre en charge de l'extension ".fr" continue sa révolution, suite à la loi du 22 mars et son décret paru le 1er août 2011.

Pas mal de nouveautés ont ainsi été initiées ou sont en cours au 2ème semestre :

• depuis le 1/7/2011 : publication quotidienne des domaines déposés
• depuis le 1/7/2011 : examen des +8,000 dossiers relatifs aux domaines comprenant des termes jusqu'alors "soumis à examen préalable"
• 2/9/2011 : lancement d'un nouveau site, extranet et logo pour le 25ème anniversaire (NDLR: même âge que le .de par ailleurs)
• 26/10/2011 : lancement d'une gamme de services techniques pour les opérateurs des futures extensions de domaines génériques
• 3/11/2011 : nouveau système de résolution des litiges (au revoir PREDEC, hello Syreli
• 3/11/2011 : accréditation des 569 bureaux d'enregistrement existants avant la fin de l'année, et de tout nouveau bureau qui souhaitera vendre du ".fr"
• 6/12/2011 : ouverture de toutes les extensions .fr, .wf, .tf, .re, .pm et .yt aux structures localisées au sein de l'Union Européenne (+ Suisse, Islande et Norvège)

Il est possible que des cybersquatteurs "européens" cherchent à profiter de cette assouplissement des conditions d'enregistrement. L'Afnic pourrait de fait avoir une bonne occasion de tester l'efficacité et la scalabilité de la nouvelle procédure de résolution des litiges introduite au début de ce mois. Celle-ci présente en tout cas l'intérêt d'être peu onéreuse (250€HT/domaine) et rapide (décision sous 2 mois, exécution après 15 jours).

A Distributed Denial of Service technique is actively exploited in the wild by attackers since a few months.
It leverages a vulnerability in game servers running First Person Shooter games based on the Quake III model (Call of Duty, Enemy Territory, etc.) to redirect traffic response to a victim. Some of these gaming servers accept a "GetStatus" request in a small UDP/80 packet from a spoofed source IP address and the server replies by redirecting the answer to the spoofed victim's IP on port 80. Amplification is thus achieved as the packet replied can be 10, 20 or 30 times bigger than the request.

See an example of such redirected flow below :

---

|Date flow start|Proto|Src IP Addr:Port|Dst IP Addr:Port|Flags|Packets|Bytes|Flows|bps|pps|Bpp| 

|2011-10-10 15:55:48.971|UDP|66.23.233.XX:27960|A.B.C.D:80|......|10000|13.3 M|1|2.1 M|195|1329|

---

Thousands of gaming servers can be found online through specific search engines and may enable this kind of attack, but only some of them can be used to conduct such attack. Indeed, games server admins or their hosting providers can mitigate such risks for example by applying patches (when available) or firewall rules (ACL, iptables, etc.) to block or at least limit such fraudulent queries/traffic.

But for the moment, multi-Gbps DDoS attacks can still be conducted. The volume of "packet love" sent depends on the source (often compromised) machines' capacity and the number of game servers used as amplifiers...

Thanks to Daniel L. for proofreading

Les plugins SpyEye, c'est un peu comme les pokemons, il y en a beaucoup, tous ne sont pas utiles, mais on a envie de tous les collectionner.

Alors que SpyEye évolue et passe en version 1.3.48, qui ne semble apporter qu'une compatibilité avec les versions les plus récentes de Firefox, nous avons également constaté l'apparition de quelques nouveaux plugins, preuve que la "communauté" est plutôt active dans ce domaine.

datagrabber.dll

Ce plugin, comme son nom l'indique, est chargé de récupérer des données sur le poste.

La fonction d'initialisation se charge d'extraire une DLL et d'exécuter une fonction exportée. Celle-ci faisant 450 ko et étant écrite en Delphi, l'analyse du code sera succincte et on s'attardera plutôt sur la lecture des nombreuses chaînes de caractères, qui nous permettra de voir alors que les choses ne sont pas faites à moitié : le plugin récupère les identifiants stockés par une liste de logiciels clients impressionnante : clients FTP, SSH, de messagerie instantanée ou non, navigateurs ... Le tout est ensuite envoyé au serveur de collecte sous l'appellation datagrabber.

plugin.dll

Ce plugin, comme son nom ne l'indique pas, pourrait se nommer plugindelamort.dll.

Sa seule fonction se résume à la capture suivante :

Le lecteur initié constatera que le plugin se charge de supprimer quelques fichiers vitaux pour le système d'exploitation.

L'intérêt d'un tel plugin pour un bot-herder reste encore à démontrer ...

videograbber.dll

Le nom de ce plugin ne cache une fois de plus pas le rôle qu'il devra jouer. La fonctionnalité de capture d'écran pour déjouer les claviers virtuels semble ne plus suffire, et les auteurs de ce plugin ont pensé qu'une vidéo ferait beaucoup mieux l'affaire.

Dés que l'utilisateur infecté se rend sur l'une des pages du fichier de configuration, l'enregistrement d'une vidéo au format MKV, dont la durée est également spécifiée dans le fichier de configuration, est lancé. Dés que la vidéo est terminée, elle est envoyé au serveur de collecte sous l'appelation dump.

La norme Unicode permet de représenter n'importe quel caractère, en lui donnant un nom et un identifiant numérique. Très pratique pour les caractères exotiques, comme ceux de la langue Russe, Arabe, Chinoise, etc [1] A partir de la version Vista de Microsoft Windows, elle est supportée par défaut, contrairement à la version XP où il fallait activer le support des langues s'écrivant de droite à gauche et scripts complexes [2]

Il existe une ressemblance entre plusieurs caractères de différentes langues, comme la lettre "o" de l'alphabet latin (U+006F) et du cyrillique (U+043E)... Aussi, il existe des caractères spéciaux en Unicode, pour inverser le sens d'écriture, permettant ainsi l'écriture des langues s'écrivant de droite à gauche, ou de mixer les deux.

Quelques exemples de caractères :

• U+202E : [RTLO], permettant de forcer l'écriture de droite à gauche
• U+202B : [LTRO], permettant de forcer l'écriture de gauche à droite
• U+006F : caractère "o" latin, en minuscule
• U+1D0F : caractère "o" latin, en petite majuscule
• U+043E : caractère "o" cyrillique, en minuscule
• U+0069 : caractère "i" latin, en minuscule
• U+0456 : caractère "i" cyrillique, en minuscule.

Les cyber criminels l'ont très bien compris et l'exploitent depuis plusieurs années afin de tromper leurs victimes via des emails ou liens malveillants.

Voici quelques cas d'utilisations :

• Modifier visuellement l'affichage du nom de fichier d'un exécutable, afin de faire croire à un document Word ou à une image... ;
• Créer des fichiers locaux portant, visuellement, le même nom ;
• Créer des liens, visuellement légitimes, pointant vers des URLs arbitraires.

Pour manipuler les caractères Unicode, il suffit de les copier/coller depuis la table des caractères (charmap.exe) de Microsoft Windows vers la destination.

Afin de donner plus d’informations sur les cas d’utilisations cités ci-dessus, voici quelques fichiers d’exemples, sous Windows Seven. Pour faire plus réaliste, dans certains cas, nous avons utilisé notepad.exe en modifiant son nom et changeant son icône vers celle de l’extension voulue.

1- Renommer des fichiers arbitraires

Nous pouvons utiliser le caractère [RTLO] pour inverser l'écriture d'un nom de fichier comme suit, par exemple :

• le fichier nommé [RTLO]123.456, donnera 654.321 à l’affichage dans l’explorateur
• my_[RTLO]cod.exe, donnera my_exe.doc
• ann[RTLO]cod.exe, donnera annexe.doc

Exemples

Ici, on renomme le fichier en mycod.exe

Puis, après insertion du caractère [RTLO] entre le caractère y et c, nous obtenons :

Ici, nous plaçons le caractère [RTLO], exactement comme dans l'exemple précédent:

Des combinaisons plus complexes, avec des caractères comme [RTLO] et [LTRO], peuvent êtres faites comme :

[RTLO]cod.erialpm[LTRO]comportement.exe, donnera comportement.exemplaire.doc

La détection de la supercherie peut se faire de deux façons :

Via les propriétés du fichier :

Nous remarquons que seul le champ type de fichier permet de détecter que c’est une application et non pas un document Word.

Ou via l'interpréteur de commandes, car les caractères Unicode ne sont pas gérés. Par conséquent, ils sont remplacés par des points d'interrogations :

Cependant, tous les utilitaires testés supportent correctement l’Unicode, comme les gestionnaires d’archives :

7zip :

Winrar :

Nous remarquons que dans la barre d'adresse de Winrar, la chaîne de caractères est inversée à partir de l'endroit où le caractère [RTLO] est inséré

Winzip :

2- Mettre des fichiers avec le même nom, dans le même dossier :

Pour le faire, il suffit d'utiliser les différents caractères visuellement ressemblants, pour renommer deux fichiers différents.

Voici des exemples en image :

Cette technique peut être exploitée pour forger des URLs visiblement ressemblantes à celle ciblées (soit en réservant un nom de domaine internationalisé ressemblant à celui de la victime [3] ou en modifiant des caractères autres que ceux du nom de domaine).

3- Liens malveillants :

Un attaquant, peut inviter sa victime à visiter une URL arbitraire, comme nous pouvons le voir dans l'image ci dessous.

Pour le faire, l'attaquant a écrit l'URL comme suit :

[RTLO]http://www.google.com/moc.isxel.www//:ptth

qui sera affichée comme suit :

http://www.lexsi.com/moc.elgoog.www//:ptth

Dans l'image ci dessous, les deux lignes sont identiques, sauf que le caractère [RTLO] a été introduit dans la seconde ligne :

Un attaquant peut faire preuve d’ingéniosité en insérant ce genre de liens dans du code HTML/Javascript.

La pleine compatibilité avec l’Unicode n’est pas une vulnérabilité en soi, car il est tout à fait légitime de permettre dans un même nom de fichier, par exemple, l'écriture dans une langue s’écrivant de gauche à droite et une autre de droite à gauche.

Des mécanismes de vérification peuvent être instaurés, afin de forcer un certain modèle à respecter pour l’extension des fichiers, si celui-ci en a une.

Dans d’autres cas, une génération d’alertes peut se faire en se basant sur des expressions régulières.

Il est tout à fait possible d'utiliser l'Unicode spoofing pour ajouter plus de sécurité, comme dans l'utilisation des CAPTCHA par exemple [4]

Aujourd'hui, il est conseillé de rester vigilant et de vérifier que le support des IDNs est correctement paramétré dans Internet Explorer [5] et Mozilla Firefox [6]

The Htran tool has recently been used during several cyberattacks, such as Shady RAT and the attack against RSA. It is a Chinese port forwarding tool, allowing an attacker to use a compromised machine as a pivot to attack a network segment that is not directly accessible from the attacker's machine. Its full name is HUC Packet Transmit Tool. We have found this tool to be used during previous incident response missions, especially during targeted attacks against French industrial companies in 2009.

Presentation

NB: this analysis is based on the tool used in 2009, its behavior may have changed since then and doesn't necessarily reflect the exact tool that have been used in the operations mentioned above.

Htran is an interactive tool showing a usage when no command line argument is passed:

[Usage of Port Transmit:]
tran.exe   -<listen | tran | slave | remove>   <option>
[option:]
-listen <ConnectPort> <TransmitPort>
-tran  <ConnectPort> <TransmitHost> <TransmitPort>
-slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort>
-tran  <ConnectPort> <TransmitHost> <TransmitPort> -i ProcessName
-slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort> -i ProcessName
-remove

The meaning of the options is as follows:

• -listen <ConnectPort> <TransmitPort>: listen on port ConnectPort and transfer data received to the local port TransmitPort;
• -tran <ConnectPort> <TransmitHost> <TransmitPort>: listen on port ConnectPort and transfer data received to the TransmitPort on the TransmitHost machine;
• -slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort>: connect to the ConnectPort port on the ConnectHost machine and transfer data received to the TransmitPort on the TransmitHost machine
• -remove: remove evidence left when using the –i option (see below).

Indeed, it is possible to specify a –i option followed by a process name to the –tran and –slave options. The tool will then inject itself in the process to perform its network operations, to be more stealthy. For example, the following screenshot shows that the process performing network operations is notepad.exe, not tran.exe:

This –i option also adds an Error Help Service service (HKLM\SYSTEM\CurrentControlSet\Services\ErrorService registry key) pointing to C:\WINDOWS\system32\mnlbmgr.exe so that this injection will be restored on each reboot:

The C:\WINDOWS\system32\ntimfos.eng file is used to store the command line arguments. Here is an example of it:

This option also installs a rootkit as a device driver from C:\WINDOWS\system32\drivers\viapack.sys, which will persist on reboot. This rootkit hides some network operations (see below).

Detail behavior

The tran.exe binary has two resources:

• BIN\110: Windows service executable (mnlbmgr.exe), UPX compressed;
• BIN\111: device driver executable (viapack.sys).

The mnlbmgr.exe binary has itself another resource:

• BINO\101: DLL executable (usrtran.dll)

To be stealthier, the mnlbmgr.exe, viapack.sys and usrtan.dll files have their dates set to those of the legitimate C:\WINDOWS\system32\drivers\hal.dll file.

A small trick is used to load the kernel driver. The binary sends a STOP signal to the beep service, overwrites the C:\WINDOWS\system32\beep.sys file with C:\WINDOWS\system32\viapack.sys and immediately starts the beep service again. This exploits a race condition in the Windows File Protection mechanism; the modification is correctly detected by Windows and the original file restored, but this occurs after the service has started with the malicious viapack.sys image, thus loading the rootkit.

Once the driver has been loaded, it creates the HKLM\SYSTEM\CurrentControlSet\Services\viapack registry key to persist on each reboot and attaches itself to the list of devices linked to \Driver\Tcpip\Device\Tcp. On its first launch, it installed itself using the beep.sys trick described above and appears like this in GMER:

After a reboot, it becomes an autonomously loaded driver and appears like this:

According to our tests, it seems that this rootkit only masks a local port bind. Indeed, when the tool is ran with the –tran option without specifying –i, the listening port is listed by Tcpview (port 80 in this example) :

On the other hand, Tcpview no longer shows the listening port with the –tran option when the rootkit is active:

But in –slave mode, Tcpview displays the TCP connections even if the rootkit is active:

Based on the information provided by the ntimfos.eng file, the service creates in the targeted process a new thread whose base address is LoadLibrary() with a usrtran.dll argument, thus loading the malicious library in the memory of this process:

Even two years after our incident response, this malware is still hardly detected by antivirus:

• DrWeb : MULDROP.Trojan
• eTrust Antivirus : Win32/Sybuex!generic
• Sophos : Mal/Behav-160
• Trend Micro : Mal_Xed-20
• Symantec Command Line Scanner : Backdoor.Systack (rootkit uniquement)

L'outil Htran a récemment été utilisé dans plusieurs cyberattaques, dont Shady RAT et la compromission de RSA. Il s'agit d'un outil chinois réalisant de la redirection de port (« port forwarding ») entre machines, permettant ainsi d’utiliser une machine compromise comme pivot pour attaquer un segment du réseau normalement non accessible depuis la machine attaquante. Son nom complet est HUC Packet Transmit Tool. Lors de missions CERT, nous avions déjà eu l'occasion de mettre en évidence l'utilisation de cet outil, en particulier lors d'attaques ciblées contre des groupes industriels français en 2009.

Présentation

NB : cette analyse se base sur une version de l'outil utilisée en 2009, son fonctionnement a pu être modifié depuis et ne correspond pas nécessairement à la version utilisée dans les opérations mentionnées ci-dessus.

Htran est un outil interactif qui affiche un usage lorsqu’aucun paramètre n’est passé en ligne de commande :

[Usage of Port Transmit:]
tran.exe   -<listen | tran | slave | remove>   <option>
[option:]
-listen <ConnectPort> <TransmitPort>
-tran  <ConnectPort> <TransmitHost> <TransmitPort>
-slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort>
-tran  <ConnectPort> <TransmitHost> <TransmitPort> -i ProcessName
-slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort> -i ProcessName
-remove

La signification des options est la suivante :

• -listen <ConnectPort> <TransmitPort> : se mettre en écoute sur le port ConnectPort et transférer les données reçues vers le port local TransmitPort ;
• -tran <ConnectPort> <TransmitHost> <TransmitPort> : se mettre en écoute sur le port ConnectPort et transférer les données reçues vers le port TransmitPort sur la machine TransmitHost ;
• -slave <ConnectHost> <ConnectPort> <TransmitHost> <TransmitPort> : se connecter sur le port ConnectPort de la machine ConnectHost et transférer les données reçues vers le port TransmitPort sur la machine TransmitHost ;
• -remove : supprimer les traces laissées par l’outil lors de l’utilisation de l’option –i (voir ci-dessous).

En effet, il est possible de passer l’option –i suivie du nom d’un processus aux options –tran et –slave. L’outil s’injecte alors dans ce processus pour effectuer ses opérations réseau, dans un but de furtivité. Par exemple, la capture suivante montre que c’est le processus notepad.exe qui effectue des opérations réseau, et non tran.exe :

Cette option –i ajoute aussi un service Error Help Service (clé de registre HKLM\SYSTEM\CurrentControlSet\Services\ErrorService pointant vers C:\WINDOWS\system32\mnlbmgr.exe) afin d’assurer la survie de cette injection au prochain redémarrage :

Le fichier C:\WINDOWS\system32\ntimfos.eng est utilisé afin d’enregistrer les arguments fournis en ligne de commande. En voici un exemple :

Enfin, cette option a aussi pour effet d’installer un rootkit sous la forme d’un pilote de périphérique depuis C:\WINDOWS\system32\drivers\viapack.sys, persistant au redémarrage. Ce rootkit a pour but de cacher une partie des opérations réseau effectuées par l’outil (voir plus bas).

Fonctionnement détaillé

Le binaire tran.exe intègre deux ressources :

• BIN\110 : exécutable de type service Windows (mnlbmgr.exe), compressé avec UPX ;
• BIN\111 : exécutable de type pilote de périphérique (viapack.sys).

Le binaire mnlbmgr.exe contient lui-même une ressource :

• BINO\101 : exécutable de type DLL (usrtran.dll)

Pour plus de furtivité, les fichiers mnlbmgr.exe, viapack.sys et usrtan.dll ont leurs dates positionnées à celles du fichier légitime C:\WINDOWS\system32\drivers\hal.dll.

On remarque une petite astuce utilisée afin de charger le pilote noyau. Le binaire envoie un signal STOP au service beep, écrase le fichier C:\WINDOWS\system32\beep.sys par C:\WINDOWS\system32\viapack.sys et relance immédiatement le service beep. Cela exploite une condition de concurrence dans le mécanisme Windows File Protection ; la modification est bien détectée par Windows et le fichier beep.sys original bien restauré, mais ceci après que le service a démarré avec le binaire malveillant viapack.sys comme image, permettant ainsi de charger le rootkit.

Une fois chargé, le pilote crée la clé de registre HKLM\SYSTEM\CurrentControlSet\Services\viapack pour assurer son lancement à chaque démarrage du système et s’attache à la liste des périphériques liés à \Driver\Tcpip\Device\Tcp. Lors de son premier lancement, il s’installe en se substituant au pilote beep.sys (comme décrit dans le paragraphe précédent) et apparaît donc ainsi dans GMER :

Après redémarrage du système, il devient un pilote chargé de manière autonome et apparaît désormais ainsi :

D’après nos tests, il semblerait que ce rootkit ait pour but de masquer uniquement le fait qu’un port soit en écoute sur le système. En effet, quand l’outil est lancé avec l’option –tran sans l’option –i, le port mis en écoute est listé par Tcpview (port 80 dans cet exemple) :

Mais Tcpview ne montre pas le port en écoute lorsque le mode –tran est utilisé et le rootkit active :

En revanche, en mode –slave, Tcpview affiche bien les ouvertures de connexion TCP même lorsque le rootkit est active :

En se basant sur les informations du fichier ntimfos.eng, le service crée dans le processus ciblé un nouveau thread dont l’adresse de base est celle de LoadLibrary() avec en argument usrtran.dll, afin de charger la bibliothèque malveillante dans l’espace mémoire de ce processus :

Même deux ans après notre réponse à incident, ce malware et toujours mal détecté par les éditeurs antivirus :

• DrWeb : MULDROP.Trojan
• eTrust Antivirus : Win32/Sybuex!generic
• Sophos : Mal/Behav-160
• Trend Micro : Mal_Xed-20
• Symantec Command Line Scanner : Backdoor.Systack (rootkit uniquement)

Depuis maintenant près d'un an, il est apparu que certains groupes utilisant le malware bancaire ZeuS infectaient également les mobiles de leurs victimes, afin de leur dérober les SMS de confirmation envoyés par la banque en cas de tentative de virement. Les premières versions impactaient Symbian et Blackberry, puis Windows Mobile. Le malware mobile a été baptisé ZITMO, pour Zeus In The MObile.

Il y a quelques jours, une version ciblant Android a été identifiée par Fortinet.

Le système d'exploitation Android n'en est pas à son premier malware, de nombreuses applications malveillantes ayant été découvertes par le passé, avec des fonctionnalités variées :

• Vol de SMS
• Exploitation de vulnérabilités pour obtenir les droits root
• Envoi de SMS surtaxés
• Fonctionnalité de botnet

Il semble toutefois que la double infection (Windows + Android) soit une première pour la plateforme.

Une application Android se présente sous la forme d'un fichier APK (qui est une archive ZIP), contenant un fichier AndroidManifest.xml qui définit l'application, ainsi qu'un ensemble de classes Dalvik, et potentiellement des bibliothèques en code natif. Dans le cas de ce malware, seules des classes Dalvik sont utilisées.

Permissions

Nous pouvons observer que le malware demande les permissions suivantes à l'installation :

• android.permission.RECEIVE_SMS : permet d'agir sur les SMS reçus
• android.permission.INTERNET : permet d'établir des connexions réseau
• android.permission.READ_PHONE_STATE : permet d'accéder à certaines propriétés du téléphone (tel que l'IMEI)

Services

Le malware s'enregistre en tant que gestionnaire de l'évènement android.provider.Telephony.SMS_RECEIVED tel que l'on peut le voir dans le fichier Manifest :

 <receiver android:name=".SmsReceiver">
   <intent-filter android:priority="10000">
     <action android:name="android.provider.Telephony.SMS_RECEIVED" />
   </intent-filter>
 </receiver>

Fonctionnement du malware

Lorsqu'un évènement SMS_RECEIVED survient, la classe SmsReceiver de l'application est alors appelée. Celle-ci reçoit en paramètre le SMS au format PDU, et lance le service MainService qui se chargera de traiter le SMS.

Le service MainService va alors récupérer les informations suivantes sur SMS grâce à la méthode SmsMessage.createFromPdu() :

• Numéro de l'expéditeur
• Contenu du message

Ces deux informations seront alors associées respectivement aux champs f0 et b0.

Le numéro IMEI du téléphone est ensuite récupéré grâce à la méthode getDeviceID() de la classe TelephonyManager, et associé au champ pid.

Ces trois champs sont ensuite envoyés à l'aide d'une méthode POST, en clair, au serveur de contrôle du malware.

Le champ pid est ici composé de 15 0 car le malware a été exécuté sur l'émulateur.

Ingénierie sociale

Le malware n'est pas capable d'infecter lui-même un téléphone Android, il doit donc être installé par l'utilisateur. Pour cela, les auteurs l'ont déguisé en application de sécurité bancaire, et la victime dont le poste Windows est infecté est invitée à l'installer sur son téléphone Android par le biais des Web Injects (injection de code Javascript dans les sites cible du malware).

L'application est en effet présentée comme étant Trusteer Rapport (logiciel anti-fraude bien connu et combattu par les malware bancaires tels que ZeuS ou SpyEye).

Une fois lancée, celle-ci affiche une soit-disant clé d'activation à rentrer sur le site bancaire. Cette clé n'est autre que le numéro IMEI du téléphone.

Et ensuite ?

Ce malware est la première étape d'une double infection Windows+Android visant à attaquer les mécanismes d'authentification forte mis en place par les sites bancaires. Bien que simpliste (pas d'obfuscation/chiffrement, pas d'élévation de privilèges, infection via installation manuelle), celui-ci est déjà très efficace. Nul doute que ce type de malware évoluera rapidement.

Pour éviter ce type d'infection, il est recommandé de n'installer des applications que depuis l'Android Market. Cela ne dispense toutefois pas de bien vérifier les permissions demandées, certaines applications malveillantes s'étant déjà retrouvées sur le Market.

Une des différences les plus connues entre les systèmes de fichiers EXT2 et EXT3 est que ce dernier utilise un journal pour stocker ses transactions, facilitant grandement la récupération du système de fichiers en cas, par exemple, de coupure électrique. Dans le cadre de la formation SANS 508 Analyse Forensique et réponses aux incidents, que j'aurai le plaisir de donner en juillet et à laquelle vous pouvez vous inscrire dès à présent (ceci n'est pas une publicité à peine masquée :), j'ai eu l'occasion de revenir sur une autre différence moins connue : la routine d'effacement d'un fichier a été modifiée, rendant plus difficile la récupération d'un fichier effacé sous EXT3 que sous EXT2. Heureusement, le journal peut justement nous aider.

Commençons par observer ce qu'il se passe lors de la suppression d'un fichier sur EXT2 :

 $ echo contenu_du_fichier > /mnt/ext2/fichier.txt
 $ rm /mnt/ext2/fichier.txt
 $ sync

 $ ils ext2.raw
 12|f|0|0|1305735974|1305735974|1305735983|0|644|0|19

Le fichier effacé a pour inode 12 et ses statistiques sont les suivantes :

 $ istat ext2.raw 12
 inode: 12
 Not Allocated
 Group: 0
 Generation Id: 3438788226
 uid / gid: 0 / 0
 mode: rrw-r--r--
 size: 19
 num of links: 0
 
 Inode Times:
 Accessed:		Wed May 18 18:26:14 2011
 File Modified:		Wed May 18 18:26:14 2011
 Inode Modified:	Wed May 18 18:26:23 2011
 Deleted:		Wed May 18 18:26:23 2011
 
 Direct Blocks:
 447

Même si le fichier a été effacé, sa récupération sera donc immédiate car les pointeurs vers les blocs (un unique bloc direct pour notre test) ont été conservés :

 $ icat ext2.raw 12
 contenu_du_fichier

Effectuons maintenant les mêmes opérations avec EXT3 :

 $ echo contenu_du_fichier > /mnt/ext3/fichier.txt
 $ rm /mnt/ext3/fichier.txt
 $ sync

 $ ils ext3.raw
 12|f|0|0|1305790994|1305790944|1305790994|0|644|0|0

 $ istat ext3.raw 12
 inode: 12
 Not Allocated
 Group: 0
 Generation Id: 2795896987
 uid / gid: 0 / 0
 mode: rrw-r--r--
 size: 0
 num of links: 0
 
 Inode Times:
 Accessed:		Thu May 19 09:42:24 2011
 File Modified:		Thu May 19 09:43:14 2011
 Inode Modified:	Thu May 19 09:43:14 2011
 Deleted:		Thu May 19 09:43:14 2011
 
 Direct Blocks:

En plus de la mise à zéro de la taille du fichier (autre différence par rapport à EXT2), on observe que la liste des pointeurs vers les blocs de données est perdue ; la commande icat sera donc inopérante.

Les données n'ayant bien sûr pas été altérées par la suppression, il reste toujours possible d'effectuer du file carving avec des outils comme foremost, scalpel ou photorec si le type du fichier est connu (image JPG, archive ZIP, etc). Une autre solution, plus élégante, consiste à rechercher dans le journal EXT3 une sauvegarde de l'inode du fichier juste avant qu'il ne soit supprimé, dans le but de retrouver la liste originale des pointeurs.

Nous recherchons donc les sauvegardes de l'inode 12. Via fsstat, nous déterminons que cet inode appartient au groupe 0 :

 Group: 0:
   Inode Range: 1 - 1832
   Block Range: 1 - 8192
   Layout:
     Super Block: 1 - 1
     Group Descriptor Table: 2 - 2
     Data bitmap: 202 - 202
     Inode bitmap: 203 - 203
     Inode Table: 204 - 432

Pour ce groupe d'inodes :

• le 1er bloc de stockage des inodes est le 204
• la table d'inode contient 432-204+1=229 blocs
• il y a 1832-1+1=1832 inodes

Soit 1832/229 = 8 inodes par bloc. Notre inode 12 se situe ainsi dans le 2ème bloc associé à ce groupe, soit le bloc 205, à la position 4. L'outil jls nous permet de lister les entrées du journal concernant ce bloc :

 $ jls ext3.raw | grep "FS Block 205"
 4:	Allocated FS Block 205
 13:	Allocated FS Block 205

Les blocs de journal 4 et 13 contiennent donc chacun une copie de notre inode à deux instants distincts de son cycle de vie. L'inode 12 étant le 4ème inode du bloc, les commandes suivantes permettent de récupérer les sauvegardes de cet inode (un inode a pour taille 128 octets par défaut) :

 $ jcat ext3.raw 4 | dd bs=128 skip=3 count=1 | xxd
 0000020: 0000 0000 0000 0000 011a 0000 0000 0000

 $ jcat ext3.raw 13 | dd bs=128 skip=3 count=1 | xxd
 0000020: 0000 0000 0000 0000 0000 0000 0000 0000

On observe ainsi que, contrairement au bloc 13 où les pointeurs ont été remis à zéro, le bloc de journal 4 contient bien le pointeur original vers le bloc de données : 0x1a01, soit 6657. Un simple blkcat suffit alors à retrouver le contenu du fichier :

 $ blkcat ext3.raw 6657
 contenu_du_fichier

Si les calculs précédents vous rebutent, sachez que ext3grep peut les faire à votre place et vous permettre de récupérer l'historique d'un inode en un clin d'oeil :

 $ ext3grep --show-journal-inodes 12 ext3.raw
 Inode 12 (transaction 3)
 [...] 
 Direct Blocks: 0
 
 Inode 12 (transaction 2)
 [...]
 Direct Blocks: 6657

Since last year, Microsoft is distributing the KB976002 update, prompting the user to choose among the 5 main browsers. While the two leading Internet Explorer and Firefox have been the targets of banking malware for a long, Chrome, Safari and Opera still seemed to resist the invader.

As recently announced Brian Krebs, two new features have appeared in version 1.3.34 of the SpyEye builder.

SpyEye is able to capture the data sent using Chrome or Opera. The study of a version 1.3.39 sample shows how this capture is performed.

Opera

• Check that the process name contains the string opera
• Hook on TranslateMessage to intercept keystrokes
• Hook on RtlFreeHeap to intercept POST requests when the buffer containing them is freed

Chrome

• Check that the process name contains the string chrome
• Hook on TranslateMessage to intercept keystrokes
• Hook on ZwReadFile to intercept POST requests

In both cases the data are sent to the collector server in the POST requests interception hook, the captured keystrokes are stored in a memory area in the meantime.