Le CERT-LEXSI a développé une plateforme d'analyse automatisée d'applications Android pour différents besoins, dont celui consistant à extraire d'un flux de milliers d'applications les quelques applications suspectes méritant une analyse manuelle plus poussée. En voici un exemple.

Aperçu de l'application

L'alerte remontée par la plateforme est la suivante :

On remarque effectivement les activités suivantes :

• de nombreuses chaines de caractères suspectes ont été extraites de l'exécution dont certaines d'entre elles peuvent être la conséquence d'une élévation de privilèges vers root, comme le remontage d'une partition read/write afin de compromettre la partition système ; l'analyse n'a cependant pas montré que les droits root avaient été effectivement acquis par l'application via l'exploitation d'une vulnérabilité
• l'utilisation de permissions liées à l'envoi de SMS (android.permission.SEND_SMS) et aux appels téléphoniques (android.permission.CALL_PHONE) utilisées par certains troyens générateurs de revenus
• le fait que l'application impose une priorité élevée sur la réception des SMS, comme le font les troyens bancaires mobiles comme Zitmo (Zeus in the mobile) ou Spitmo (Spyeye in the mobile) pour recevoir les OTP SMS avant les autres applications

A ce niveau de l'analyse, la plateforme automatisée a bien fait de générer une alerte et une étude plus poussée est nécessaire pour déterminer s'il s'agit d'une application malveillante ou simplement d'un faux positif.

Exécution manuelle

Il s'agit d'une application issue d'un market chinois permettant à première vue de personnaliser son téléphone (fonds d'écran, sonneries, etc) et d'envoyer des MMS à ses contacts :

Sans même avoir validé quoi que ce soit dans l'application, on remarque que l'écran de réception d'appel a déjà été personnalisé. Rien de bien méchant, mais un peu intrusif quand même :

L'exécution ne nous en apprendra pas plus, passons maintenant à l'analyse statique.

Analyse statique

La décompilation du bytecode Dalvik commence très fort puisqu'on y voit la présence d'une bibliothèque RootTools :

Il s'agit d'une bibliothèque exposant une API permettant de lancer des commandes en tant que root si le téléphone le permet ; en d'autres termes, elle ne roote pas le téléphone mais permet d'utiliser le root s'il est disponible. Son code source est public. Cela explique donc la présence de chaines suspectes dans l'alerte initiale sans pour autant qu'une élévation de privilèges ait eu lieu.

La version de RootTools embarquée dans notre application ne semblant pas avoir été modifiée, nous allons rechercher les appels à des fonctions de cette API. Deux classes correspondent :

• utility/My
• utility/RootUtil

Dans la classe My, seule la fonction installCcPhoneProcess() fait appel à RootTools. Elle commence par vérifier la version d'Android installée via la constante Build.VERSION.SDK_INT ; si la version n'est pas au moins la 9, soit Gingerbread (2.3), le saut n'est pas pris et la fonction retourne :

Pour les versions Gingerbread et supérieures, la fonction vérifie ensuite si le root est disponible via un appel à RootTools.isRootAvailable() (cette vérification ne se base que sur la présence du binaire su). En cas d'échec, la fonction termine en loggant le message d'erreur ERROR_CODE_ROOT_PROCESS. En cas de réussite, le tableau contenant la liste des commandes à exécuter en root est créé par l'appel à la fonction RootUtil.createCmds() (plus lisible en regardant la décompilation) :

L'appel suivant à RootUtil.execCmdsHaveResult() va donc remonter la partition système read/write et y copier l'APK cc_phone.apk (depuis les ressources de l'APK original). Cet APK sera automatiquement détecté par le Package Manager d'Android et, comme il a été copié dans la partition système, reconnu comme une application système ce qui lui permettra d'obtenir des droits supplémentaires. En effet, alors que l'installation de l'application ne génère pas d'erreur sous Android 2.2, le message suivant apparait dans les logs lors de l'installation sous Android 2.3 :

 W/PackageManager(   75): Not granting permission android.permission.MODIFY_PHONE_STATE to package xxx.xxx (protectionLevel=3 flags=0xbe44)

Par défaut, l'application n'a donc pas obtenu sur Gingerbread tous les privilèges voulus. Après une rapide recherche, on constate en effet qu'il s'agit d'un problème connu : Google a modifié l'API liée à la téléphonie et l'accès aux fonctions permettant de changer l'état d'un appel (prendre l'appel automatiquement via answerRingingCall() ou raccrocher automatiquement via endCall()) est désormais restreint aux applications système.

Reste maintenant à savoir à quel moment la fonction My.installCcPhoneProcess() est appelée. On obtient les références suivantes :

La première référence ne donne rien de pertinent ; la fonction onClick() de l'activité Settings appelle cette fonction lors de l'interaction avec le contrôle cb_to_obtain :

La fonction initView() nous informe que ce contrôle a pour identifiant 2131361991 (0x7f0a00c7) et qu'une zone est justement rendue invisible pour les versions avant 2.3 :

On observe effectivement une différence entre l'écran Settings entre Android 2.2 et 2.3 où un bouton apparait :

Voici la traduction des labels :

• 授权设置 : Authorization settings
• 2.3获取授权 : 2.3 to obtain authorization
• 设置 : install

Un clic sur ce bouton nous confirme via les logs qu'il s'agit bien du contrôle cb_to_obtain. Toujours dans l'écran Settings, l'un des contrôles se nomme sp_ChoiceAutoAnswer et on fait alors le lien avec le changement d'API dans Gingerbread mentionné ci-dessus. Ce contrôle a pour label 来电自动接听 ("Call Auto Answer") et en le changeant à une autre valeur que celle par défaut et en émettant un appel entrant, on ne remarque aucun problème dans les logs sous Android 2.2 alors que la version 2.3 émet le message suivant :

 W/System.err(  398): java.lang.SecurityException: Neither user 10034 nor current process has android.permission.MODIFY_PHONE_STATE.

Cette fois-ci, la boucle est bouclée : l'application utilise bien les droits root, s'ils sont disponibles, mais simplement afin de contourner une protection présente à partir d'Android 2.3 dans l'API de téléphonie, afin de maintenir la fonctionnalité de répondeur automatique. L'application n'est donc pas malveillante et on peut même la trouver sur le market officiel

Nous nous sommes récemment intéressés au dernier venu dans le monde des malwares bancaires : Citadel. La publication du code source du malware Zeus a rendu possible la création de nouveaux malwares bancaires, et Citadel fait partie de ceux-ci. L'une de ses particularités est la possibilité pour les clients (au sens commercial du terme) de demander et/ou proposer l'implémentation de nouvelles fonctionnalités, afin que le malware soit le plus proche possible de leurs attentes.

Ce billet présente les étapes effectuées afin de pouvoir déchiffrer le fichier de configuration d'une souche spécifique, qui contient l'ensemble des cibles, injections et autres paramètres du malware.

Flux réseau

La première étape consiste à observer les flux réseau du malware, qui va vraisemblablement chercher à récupérer son fichier de configuration et ainsi nous donner une première piste pour orienter nos recherches.

Nous observons deux requêtes de type POST vers le C&C du malware :

Les données envoyées ont une taille respective de 128 et 123 octets, mais sont malheureusement chiffrées.

Le C&C répond alors en renvoyant des données également chiffrées, de 15ko et 408ko, mais ajoute un en-tête HTTP intéressant :

Content-Disposition: attachment; filename="%2e/files/cfgkass.bin"
Content-Disposition: attachment; filename="%2e/files/cit_video.module"

La première requête envoyée renvoit un fichier cfgkass.bin. En fins limiers, nous estimons qu'il s'agit du fichier de configuration. Le second fichier, plus conséquent, doit être un plugin chargé de la capture vidéo, comme nous en avons déjà vus pour SpyEye.

La curiosité nous pousse maintenant à étudier le fonctionnement du malware une fois ces données réceptionnées.

Mécanismes de chiffrement mis en oeuvre

Si l'on suit la progression des données téléchargées dans le code du malware, nous tombons rapidement sur une fonction de chiffrement complexe dont le nombre de tours et la taille de clé nous rappellent certains algorithmes de chiffrement par bloc.

Une recherche Google de certaines des constantes utilisées nous oriente rapidement vers AES avec une taille de clé de 128 bits.

Une fois ce déchiffrement AES effectué, une boucle XOR basique, déjà présente dans Zeus mais également dans SpyEye, se charge de rendre les données lisibles :

Nous nous retrouvons alors face à un fichier de configuration en clair dont la structure est en tous points identique à celle d'un fichier de configuration de Zeus, ce qui confirme la réutilisation de son code source. Nous notons au passage que la section renseignant la version indique la 1.3.1.0.

Si nous essayons de déchiffrer le contenu des requêtes envoyées par le malware avec ce même algorithme, nous n'obtenons rien de lisible, ce qui indique que d'autres algorithmes sont également utilisés. En effet, si l'on remonte le flot d'exécution à la recherche de la source des données envoyées par le malware, nous remarquons une fonction de chiffrement RC4.

En utilisant la même clé de chiffrement et en remplaçant l'AES par du RC4, nous pouvons déchiffrer les données envoyées :

Encore une fois, cette structure était également utilisée par Zeus lors de ses communications avec le C&C :

• 0x14 : tailles de données
• 0x1C : nombre de sections
• 0x20 : MD5 des données qui suivent

Puis pour chaque section :

• 0x0 : Type (4 octets)
• 0x8 et 0xC : taille (4 octets)
• 0x10 : données

Cherchons maintenant la provenance de la clé de chiffrement, afin de déterminer si celle-ci est stockée "en dur" dans le binaire, ou générée dynamiquement.

Si nous remontons de quelques fonctions depuis le déchiffrement AES, nous arrivons au code suivant :

• La fonction affectueusement nommée get_rc4_blob "déchiffre" (au sens XOR du terme) une zone du binaire contenant, entre autres, une table de permutation RC4 (ce qui n'est pas sans rappeler Zeus, une fois de plus) ;
• Le condensé MD5 d'une chaîne KEY est ensuite calculé. Cette chaîne est également présente dans le binaire, et représente une suite de 32 caractères hexadécimaux, en majuscules (cette fois-ci, c'est SpyEye qui nous vient à l'esprit) ;
• Le condensé MD5 est alors chiffré à l'aide de la table RC4 précédemment extraite, et le résultat est utilisé comme clé de (dé)chiffrement AES.

Ayant déjà à notre disposition des outils pour récupérer dynamiquement les clés de chiffrement de Zeus (table de permutation RC4) et SpyEye (chaîne de 32 caractères hexadécimaux en majuscule), il nous suffit de combiner les deux pour récupérer les clés de la Citadel

DERNIERE MINUTE :

La justice américaine a accédé à la requête du FBI demandant une prolongation de l'autorisation de mener des actions pour mitiger les postes infectés par le cheval de Troie DNSChanger.

Un délai de 4 mois supplémentaires a été accordé par le juge hier, ce qui repousse de facto la date butoir de l'extinction des serveurs DNS "sains" de remplacement opérés par l'ISC pour le compte du FBI du 8 mars prochain au 9 juillet 2012. Il n'y aura donc pas de coupure d'accès à Internet pour les machines encore infectées après le 8 mars 2012.

Extrait 1 :

Extrait 2 :

Il faut néanmoins accélérer le processus de nettoyage des machines compromises, car il n'y aura vraisemblablement pas de prolongation supplémentaire au delà du 9 juillet. Nous vous invitons dès lors à vous rendre sur http://dns-ok.fr pour vérifier simplement et immédiatement que votre ordinateur n'est pas compromis par ce code malicieux.

--

9 février 2012 :

Nous avons lancé aujourd'hui un site Web de test pour vérifier automatiquement et simplement l'éventuelle compromission de votre machine par un cheval de Troie connu sous le nom de DNSChanger.

A l'instar du test en ligne créé pour vérifier une infection éventuelle par le malware Conficker, chaque internaute peut se rendre sur le site dns-ok.fr pour vérifier "visuellement" si sa machine est compromise par DNSChanger.

Le test ne requiert aucune manipulation de la part de l'utilisateur et n'est pas intrusif. En effet, un ordinateur compromis aura par défaut sa configuration DNS normale modifiée par le malware et remplacée par une configuration DNS opérée par les pirates. Ceci leur permettait de contrôler intégralement la navigation sur Internet de la machine et au passage de générer des millions de $$ de profits via :

• des publicités non sollicitées,
  
• des commissions sur de la génération ou redirection de trafic vers des sites spécifiques,
  
• la "location" du botnet pour téléchargement de nouveaux malwares,
  
• etc.
  

Ces ordinateurs "zombies" étaient ainsi pilotés jusqu'au 9 novembre dernier, date à laquelle la justice américaine lança une opération de grande envergure contre les cybercriminels opérant ce réseau de machines infectées. L'opération baptisée "Ghost Click" fut l'aboutissement d'une investigation de plus de deux ans. Elle a permis d'arrêter la plus grande partie du gang opérant ce botnet géant.
La justice a aussi ordonné :

• que les classes d'adresses IP attribuées et utilisées par les pirates soient gelées,
• que l'ISC opère un serveur DNS sain "de remplacement" pour ces classes d'adresses.
  

Cette précaution était nécessaire afin d'éviter que les nombreuses machines encore infectées au 9 novembre ne soient plus en mesure de se connecter à Internet (c'est à dire de résoudre des noms de domaine). L'ISC identifie donc en temps réel les machines émettant des requêtes via les DNS sur lesquels ils ont désormais la main. Dans ce cadre, l'ISC redirigera une requête en direction de "dns-ok.fr" vers une adresse IP spécifique, via une fonctionnalité de BIND appelée DNS RPZ comme le montre les résolutions différentes de "dns-ok.fr" selon qu'on passe par un serveur DNS spécifique de type DNSChanger.

Ainsi, avec un serveur DNS dont l'adresse IP était attribuée à un serveur DNS opéré par DNSChanger :

dig +short dns-ok.fr. A @213.109.64.149
88.191.224.XXX

Dès lors, une page présentant le message d'alerte suivant sera affichée, signalant une probable compromission :

Alors que le serveur DNS publique de Google renvoie :

dig +short dns-ok.fr. A @8.8.8.8
88.191.223.145

Dans ce cas, l'internaute sera redirigé vers le contenu suivant :

Pour être fonctionnel, le test impose qu'aucun proxy Web ne soit configuré, ce qui limite les tests depuis les réseaux internes des entreprises au sein desquels un proxy pour la navigation de l'ensemble des employés est souvent configuré.

Ce test fait partie des stratégies initiées pour nettoyer un maximum de machines compromises par DNSChanger. Cet effort international est coordonné par le DNSChanger Working Group, un groupe de travail composé notamment de forces de l'ordre, éditeurs anti-virus et équipes de réponse à incident informatique (CERT).

Les actions menées comprennent notamment la sensibilisation à cette menace par :

• la création de sites de test multilingues tels que www.dns-ok.fr pour permettre aux internautes de vérifier s'ils sont infectés ou non :
  

- http://dns-ok.be
- http://dns-ok.de
- http://dns-ok.us
- http://dns-ok.fi
- ...

• l'envoi de notifications directes aux détenteurs des adresses IP (opérateur télécom, entreprise, administration, etc.) identifiées par le serveur DNS de remplacement l'ISC.

Au 10 février, plus de 400,000 adresses IP uniques étaient toujours recensées par l'ISC chaque 24h, dont plus de 10,000 en France. Il est donc urgent de "finir le travail" pour que ce troyen ne soit plus qu'un mauvais souvenir. Et que le jeudi 8 mars ne soit pas un "Jeudi Noir" pour des milliers d'internautes victimes de DNSChanger...

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).

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]

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