Les classiques de RSA

Comme vous le savez très probablement, le produit de deux nombres premiers peut servir à former un modulus de RSA. La factorisation de grand nombre est pour l’instant un exercice complexe et cette même complexité à elle seule garantit la sécurité de l’algorithme de chiffrement RSA. Cependant plusieurs choses peuvent le fragiliser.

Outre, le cas bien connu du partage d’un même nombre premier p dans plusieurs modules distincts (au quel cas, un simple calcul de pgcd suffit à extraire les nombres premiers et donc à factoriser les moduli), dont nous avons donné un exemple avec les boitiers Juniper, il est parfois possible pour un attaquant de récupérer de l’information sans avoir à factoriser ces grands nombres.

Détaillons ici deux exemples bien connus :

Rappelons que dans le cas générale, la seule contrainte pour l’exposant public e est d’être premier avec \Phi{N}, et ce afin de garantir l’existence de son inverse d : l’exposant privé utilisé pour le déchiffrement  (ou la signature).

RSA et Bezout

Un premier cas classique est celui de l’utilisation du même modulus avec des exposants publics différents. Certes, nous ne pourrons pas à l’aide de cette technique factoriser le module RSA, mais nous pourrons facilement retrouver le message en clair.

Mathématiquement, cela se démontre ainsi :

Supposons que nous avons deux clés publiques {E1,N} et {E2,N}. Nous savons que pour un message donné le chiffré se calcule comme suit :

C_1 = M^{E_1} \mod N
C_2 = M^{E_2} \mod N.

Or si E1 et E2 sont premiers entre eux, nous savons d’après Bezout qu’il existe a et b tels que aE_11 + bE_2 = 1 et donc par conséquent que :

C1^a*C2^b = M^{a*E_1+b*E_2} = M^1 = M

Ce qui conclut notre démonstration.

Multiple chiffrement et théorème du reste chinois

De même, l’utilisation de moduli différents N_i  avec le même exposant public e permet également de casser le message.
Cependant, il y a une condition nécessaire : le nombre de messages chiffrés (avec des moduli tous différents) doit être au moins égal à « e ».

Avec les hypothèses, nous avons donc le système d’équation suivant :

C_1 = m^e \mod N_1
C_2 = m^e \mod N_2
\vdots
C_e = m^e \mod N_e

Ne reste alors plus qu’à résoudre ce système d’équation, en appliquant directement le théorème des restes chinois (dont nous en avons déjà évoqué ici. pour l’optimisation des ressources lors de calcul avec la clé privée).

En pratique, ces deux attaques  bien connues n’ont que peu d’application (en dehors des challenges :)), car généralement les hyptohèses ne sont pas vérifiées, notamment car la valeur de e est quasi-systématiquement 2^{16}+1 … Mais bon, sait-on jamais ?

Publié dans Cryptographie Asymétrique, RSA, Uncategorized | Tagué , , , , , | 1 commentaire

Petya or Not Petya

Depuis le 27 mai, le grand public a un bel exemple pour mesurer notre dépendance aux sytèmes d’information et comprendre la relative fragilité de ces derniers.

Mais essayons d’y voir un peu plus clair dans cette affaire. Nous ne ferons pas ici d’analyses techniques mais reprendrons ce qui a été déjà largement traité par des personnes qui maitrisent leurs sujets.

En effet un logiciel malveillant que nous nommerons ici NotPetya a ravagé plusieurs entreprises dans un grand nombre de pays. Et afin d’éviter toute confusion sur les faits avérés et les suppositions nous allons découpé notre article en 2 parties, la première reprendra ce qui a pu être démontré et la seconde laisse plus de place à l’interprétation et aux suppositions.

Les Faits :

Mardi après midi, la température est montée d’un cran en Ukraine tout d’abord, avec plusieurs entreprises qui se sont faites défoncées (le terme nous parait assez approprié) par un logiciel malveillant s’apparantant à un rançongiciel de type Petya.

Pour les profanes, Petya est un rançongiciel : Vous savez un petit logiciel qui va chiffrer les informations sur votre disque dur et demander le paiement d’une certaine somme d’argent pour que vous puissez retrouver vos si précieuses données. Mais bon pour vous, pas de menace, car vous faites des sauvegardes régulièrement, n’est-ce pas ?

La famille Petya a cependant une particularité par rapport aux autres rançongiciels (Locky et consort). En effet a contrario d’un locky par exemple qui chiffre certains fichiers mais vous permet encore d’utiliser votre PC (naviguer le net pour aller payer la rançon), Petya chiffre vos données et en plus replace le MBR de votre disque. Précisons et ce sera important pour la suite que le MBR ou Master Boot Record est ce qui permet à votre ordinateur au démarrage de savoir où trouver votre système d’exploitation sur le disque dur. En clair, Petya bloque complétement l’utilisation de votre machine. Mais gardons en tête que les auteurs sont des businessmen qui veulent avoir bonne réputation afin d’inciter les victimes à payer : Toutes ces opérations sont parfaitement réversibles et la machine revient en état de fonctionnement dès lors que la rançon est payée… Enfin ça c’est si tout se passe bien. La revue MISC a consacré un article sur cette famille de rançongiciel.

Petya n’a rien d’un nouveau dans le petit monde des rançongiciels puisque depuis début 2015, ces auteurs lancent régulièrement des campagnes d’hameçonnage et rafinent régulièrement leur logiciel.

Le virus NotPetya qui s’est repandu cette semaine reprend effectivement la même logique pour le chiffrement :

– On écrase le MBR
– On chiffre les fichiers utilisateurs
– On planifie un reboot pour l’heure suivante

L’ANSSI détaille précisement la succession de logiciel malveillant dans son bulletin.

Et c’est ce qui lui a valu d’être confondu avec Petya. Mais il y a quelques différences.

Le chiffrement :

Tout d’abord, l’écrasement du MBR qui permet d’avoir la belle image ci-dessous contient des erreurs empéchant la récupération du disque.

petya-ransomware-attack-1
La fonction de génération de l’ID unique, permettant à l’utilisateur de s’authentifier auprès de pirate est également bancale.

Egalement, le logiciel peut chiffrer plusieurs fois les données utilisateurs. Au fur et à mesure des analyses, la liste des erreurs se rallongent.
Bref, au niveau de la qualité, les auteurs de cette campagne ont un peu baclé de le travail.

Le vecteur de propagation :

Habituellement (i.e dans l’énorme majorité des cas), ces attaques ne sont pas ciblés et se font à travers des campagnes de phishing avec des mots clés classiques dans l’objet des messages (INVOICE, PAIEMENT, ORDER, …). Ces messages prétextant donc un sujet d’ordre financier à ouvrir un pièce jointe qui ira elle même télécharger le rançongiciel sur le net et l’executera. Les types de pièce jointe varient d’une campagne à l’autre : fichier pdf contenant du JS, Document Word ou Excel avec des macros, zip de JS, RTF avec CVE-2017-0199. Si ce dernier vous ne le comprenez pas c’est pas grave, l’idée étant que tout ce fait via pièce jointe qui est un format assez générique pour l’ouvrir sur des PCs quelconques afin de toucher un maximum de victime (Les pirates sont là pour faire du chiffre).

Dans le cas de cette campagne, il n’y a pour l’instant (n’en déplaisent à certains) que 2 vecteurs de propagations avérés : Le premier vecteur de contamination à utiliser le processus de mise à jour d’un logiciel de compatibilité fiscale ukrainien MeDOC et le second est un point d’eau sur le site d’une banque ukrainienne également un seul et unique vecteur de contamination, le processus de mise à jour d’un logiciel ukrainien de comptabilité fiscale. Autrement dit, les pirates n’ont pas choisi la technique la plus simple pour distribuer leur petit gadget… Et cela semble tout de même très centré sur l’Ukraine. Mais comme dirait Bigard « …Admettons !! »

Et pour que cela soit bien clair : il n’y a à ce jour aucun cas avéré de campagne de phishing utilisant la faille CVE-2017-0199 qui soit lié à NotPetya (Ceci si vous avez des preuves, on est preneur).

« Please Insert Coin »

Le mode de paiement de la rançon est aussi un peu surprenant, une grande partie des acteurs du milieu préfére l’utilisation de portails sur le darknet pour échanger avec les victimes : preuve de paiement de la rançon contre procédure de déchiffrement. Ici, le choix s’est porté sur une adresse mail publique . Méthode plus fragile car celle-ci a rapidement été désactivée pour le fournisseur : rendant impossible le contact avec les auteurs de l’attaque.

Les mouvements latéraux :

Dans la tradition des rançongiciels, ils ne sont pas très complexes en terme de fonctionnalité qui se résument en générale aux actions suivantes : Ils sont lancés par l’utilisateur, ils communiquent avec leur tour de contrôles, ils chiffrent, ils affichent leur message et puis voilà c’est fini. Au pire, afin d’obtenir un mouvement latéral pas trop technique, les pirates proposent aux personnes infectés d’infecter leurs amis pour obtenir la clé de déchiffrement gratuitement…

Dans ce cas-ci, il y a une spécifité qui rappelle WannaCry. En effet tous les deux sont équipés d’un fonctionnalité dites de « Vers » : ils vont chercher à contaminer tous ce qu’ils peuvent dans leurs alentours. Mais a contrario de WannaCry qui scannait à tout azimut à l’aide d’une vulnérabilité Microsoft MS17-010 de son petit nom « Eternal Blue », NotPetya utilise EternalBlue, Eternal Romance, PSExec, MimiKatz-like pour se propager sur le réseau interne de la machine.

Détaillons un peu : la véritable force de NotPetya (oui à un moment faut bien que le truc fasse quelque chose correctement pour qu’on parle de lui :)) est sa faculté à se répliquer.

  • EternalBlue et EternalRomance sont des bouts de codes exploitant des vulnérabilités du service de partage réseau de Windows
  • MimiKatz est un logiciel qui permet de scanner la mémoire vive d’une machine et d’y extraire des informations tels que les mots de passe ou jetons d’authentification
  • PSExec et WMI sont des outils légitimes de microsoft pour executer des commandes à distance sur une machine

Les deux derniers et MimiKatz s’utilisent ensemble : le mimikatz-like recherche en mémoire des identifiants de comptes ayants des droits administrateurs sur plusieurs machines et ensuite utilisent ces identifiants avec psexec pour contaminer les machines voisines.

Officiellement, il est aujourd’hui impossible de dire qu’est ce qui a permis de faire le plus dégat entre les exploits EternalBlue/EternalRomance et le combo Mimikatz/PsExec…

Donc bref, mettez tous cela ensemble, secouer bien et balancer cela une vieille de jour férié en Ukraine… Et voilà c’est la catastrophe pour un grand nombre d’entreprises de ce pays.

Oui mais cela n’a pas touché que l’Ukraine, cela s’est aussi répendu dans plusieurs pays provoquant une belle pagaille sur le globe.

Une question reste en suspend : Comment cela est-il sorti du pays ? Officiellement le mystère reste entier, peu d’entreprise ont abordé le sujet (il faudra surement attendre le SSTIC 2020 pour avoir les Retex de Saint Gobain). Mais le logiciel malveillant ne se propageant que sur les réseaux internes et si aucun autre vecteur n’a été utilisé, une pièce serait à mettre sur les réseaux privés virtuels (aka VPN). Mais nous tombons dans la supposition, il est temps de passer à notre seconde partie…

Supputations et Interprétations subjectives

Soyons clairs et transparents, tous ce qui est écrit ci-dessous est probablement invérifiable, mais pas impossible.

Rançongiciel ou logiciel destructeur ?

Les nombreuses erreurs dans la modification du MBR et la faiblesse du système retenu pour offrir le déchiffrement contre le paiement de la rançon laissent penser que ce n’était pas pour l’attaquant la motivation première. Cette dernière serait de bloquer les système distant en détruisant les partitions des machines et rendant la récupération des données complexes.

Cependant pourquoi se donner tant de mal en incluant un code de rançongiciel incomplet dans la charge, si au final elle ne sert pas. Par exemple, les attaques de Shamoon ont fait pas mal de dégat en Arabie Saoudite et cela était plutot efficace en termes d’impact sur les infrastructures industrielles du pays.

Une théorie viable est de dire que NotPetya devait être les deux à la fois, mais que pris de cours par la pandémie WannaCry qui avait largement exploitée la faille MS17-010 (beaucoup de systèmes ont été patchés depuis) et probablement d’autres événements non publics, les auteurs ont choisis de balancer leur vermine un peu précipitament, sans prendre le temps/ le soin de finaliser la partie rançongiciel.

Alors pourquoi le coupler avec un rançongiciel ?

Très certainement pour assurer une certaine « Plausible deniability » en se faisant à moitié passer pour une organisation criminelle.

Qui a fait ça ? Mafia ou Etat ?

Comme expliqué plus haut, les organisations criminels n’auraient probablement pas autant baclé le travail sur leur gagne-pains et n’ont que peu d’intérêt à cibler sur des populations ou pays particuliers. De plus, la cible principal semble être des organismes ou entreprises qui pour la plus part doivent avoir des sauvegardes et/ou des plans de continuité (enfin on l’espère), autrement dit pour qui payer la rançon n’est pas une nécessité pour récuper leurs données). A l’opposé, un état a plus d’intérêt à paralyser un état rival afin de l’affaiblir et lui faire comprendre que bon maintenant va falloir être gentil. L’effort dans le code a avant tout été porté sur la viralité du logiciel et non sa fonction final.

Du coup, le regard se tourne assez rapidement vers une attaque d’origine étatique.

Du coup, quel pays ?

On peut penser aux blagueurs de la république démocratique et populaire de Corée. Ces derniers sont probablement les auteurs de la campagne WannaCry. Mais le gap technique entre ces 2 campagnes est important, là où WannaCry tirait tout azimut ( à l’image de la Corée du Nord qui n’a pas beaucoup d’amis dans la communauté internationale), NotPetya semble bien viser les camarades ukrainiens et si on regarde un peu la carte du monde et le contexte géopolitique. On trouve assez rapidement un coupable potentiel. En effet, depuis quelques temps, les Russes ne raffolent pas des Ukrainiens (et inversement) et Petya est un rançongiciel d’origine Russe.

Et mettons cela dans une fresque chronologique :

Décembre 2015 : Première attaque majeure sur le réseau électrique de la capitale ukrainienne.
Décembre 2016 : Nouvelle Attaque sur le réseau électrique de Kiev (capital de l’Ukraine)
Janvier 2016 : The Shadow Broker met aux enchères « Eternal Blue » et « Eternal Romance » issue d’un probable pirate de ressources de la NSA
Février 2017 : Panique chez Microsoft (pas de Patch Tuesday : c’est du jamais vu) qui s’active pour corriger ces failles (probalement averti par la NSA des risques)
Février 2017 : Le développement du module de propagation de NotPetya est en cours probablement avec des infos de premier main venant de « Shadow Broker »
Avril 2017 : « The Shadow Broker » publie son arsenal
Mai 2017 : WannaCry utilise massivement « Eternal Blue » et déclenche une prise de conscience du monde sur les risques de SMB : il faut patché et vite. L’équipe de NotPetya est prise de cours et termine rapidement les développements de son programme.
30 Mai 2017 : Le renseignement ukrainien a perquisitionné l’hébergeur WNet sous l’hypothèse que c’était une antenne du FSB (espionnage russe) : WNet est l’hébergeur du serveur de mise à jour de MeDOC.
23 Juin 2017 : Il est rendu public qu’Obama a autorisé les agences américaines à s’attaquer aux infrastructures russes à la fin de son manda
27 Juin 08h15 : le Colonel Maksim Shapoval du renseigment militaire ukrainien est tué dans sa voiture piégée : il enquétait sur les implications russes dans l’Est du Pays
27 Juin 10H30 : NotPetya frappe de plein fouet l’Ukraine avec comme vecteur zéro la mise un jour d’un logiciel de comptabilité ukrainien très largement utilisé
28 Juin : Jour férié en Ukraine, compliqué de faire rester des gens au boulot.

Bref, cette chronologie n’est pas forcément cohérente mais il y a quand même une idée qui se dégage, ne croyez vous pas ?

Certes les Russes ont aussi été touchés, nous direz vous. Et c’est vrai, mais on peut assez solidement pencher pour des dommages collatéraux.

La morale de cette histoire :

Nous n’allons pas vous refaire la liste des bonnes pratiques sur les droits, les mises à jours de votre parc.

Néanmoins, cette fois c’est le processus de mis à jour de logiciel MeDOC qui pour nous est très exotique. Mais sans parler des applications spécifiques et métiers, avez vous déjà vérifié la légitimité des patchs reçus sur votre serveur WSUS ?

L’attribution dans le monde numérique est déjà une chose relativement compliquée et il semble que des réponses à ces actions de cyberterrorisme soient encore plus compliquées, n’en déplaisent à nos amis européens.

Egalement, dans des cas de crises de ce type, il est appréciable et apprécié de se limiter au fait en ne confondant pas vitesse et précipitation. Notamment sur les vecteurs de contamination dans les premières 24h certains experts ou CSIRTs (parfois nationaux) se sont un peu emballés sur telles ou telles capacités de logiciels et/ou des attaquants. Certains voient ces attaques comme du pain bénit pour vendre plus de sécu, certes, mais soyons raisonables et ne racontons pas n’importe quoi non plus.

Et revient encore la question, y-a-t-il des experts cyber en France ? On pose la question parce qu’on a vu la vidéo du figaro… Du coup on se demande si c’était vraiment nécessaire de demander à des Russes ce genre d’infos alors que des boites de Sécu française et même l’ANSSI (si si ils parlent à la presse) pourraient faire de même et cela vous ferait économiser des frais de traduction…

Dans la catégorie troll, pour ceux qui en société pensent que c’est de bon ton de balancer : « Oh vous avez vu, c’est encore une vulnérabilité de la NSA, c’est pas bien, c’est la faute de la NSA, c’est à eux de payer ! » Du coup avec ce genre de logique débile, doit-on aussi s’insurger contre les travaux de @gentilKiwi ? Dites le vite au parquet (non pas celui-là, le judiciaire) car une enquête est en cours… Curieux de voir sur quoi cela aboutira.

Allez pour la fin, une petite touche de légereté :
Pour ceux qui ont besoin de se convaincre que le groupe « The Shadow Broker » est bien d’origine russe, nous vous invitons à lire un de leurs textes avec l’accent russe… Vous allez voir c’est radical !

Publié dans Analyse, Malware, Sensibilisation | Tagué , , , | Laisser un commentaire

Base de clé

Nous avons trouvé (enfin reçu dans notre boite) une menace qui nous change des désormais fades rançongiciels : Dans ce cas, l’habituelle macro dropper n’existe pas : le fichier Microsoft Word est le dropper.

Ceci se veut être le résumé de notre présentation lors du premier rendez-vous SecParis mi décembre.

Sans plus tarder, regardons tout cela de façon progressive :

Et commençons par le message en lui même : Toujours basé sur un prétexte fallacieux, nous sommes invités à ouvrir une pièce jointe au nom évocateur.

mail

La pièce jointe est un fichier Word banale sans métadata intéressante, la taille fait un peu sourciller.  Dans le contexte actuel, le contenu du fichier ne choque pas plus que cela : Une image indiquant qu’il est nécessaire d’activer les macros pour accéder au « vrai » contenu :

doc

On remarque cependant que le fichier est anormalement long : Plus de neuf cents pages (qui par ailleurs semblent blanches) et la langue par défaut est le polonais.

Pour notre plus grand bonheur (ou pas), l’accès aux macros n’est pas protégé par mot de passe : nous n’aurons pas besoin cette fois d’avoir recours à OleDump et OleTools. Un simple Alt-F8 nous conduit à pouvoir accéder au code. Là, nous constatons de l’obfuscation avec des noms de variables barbares et un lot de fonctions inutiles.  Nous faisons un rapide tri et nous nous rendons rapidement compte que les 900 pages blanches ne sont pas si vides qu’elles laissent à penser : simplement le texte est en blanc sur fond blanc. Le rôle de la fonction principale est d’extraire de ce texte en le « xorant », un premier binaire et de l’exécuter dans l’environnement utilisateur.

macro

La charge extraite est alors renommer en ID.exe. Une fois ce premier binaire extrait, il est bien évidemment exécuté. Cacher le binaire dans le corps du fichier texte n’est pas nouveau, nous avions déjà rencontré ce mode de dissimulation en début d’année lors d’une campagne « Petya ».

Essayons maintenant de voir ce qu’on peut y trouver en analyse statique. Nous commençons par les habituels file, strings et hexdump -C.

idfile
Le strings ne donne rien d’intéressant. A contrario lors du parcours rapide du fichier avec le hexdump, nous remarquons ce qui semblent être des caractères encodés sur 16 bits : « strings -e l » vous connaissez ? Cela peut être utile parfois…

iddump

Directement dans le code hexadécimal, nous remarquons un marqueur MSCF, ce qui ressemble fort au numéro magique des fichiers cabinets de Microsoft : Et si nos attaquants avaient utilisés ce format pour dissimuler leur charge ?

Nous pouvons essayer d’extraire ce cabinet file à l’aide de la technique du « File Carving » (technique qui consiste à rechercher des structures de formats connus pour extraire/reconstruire des fichiers à partir de données brutes (une copie de disque dur par exemple) : c’est typiquement ce qui est utilisé pour récupérer les fichiers effacés d’un disque). Nous utilisons l’outil foremost disponible sur la majorité des grandes distributions Linux.

Cependant, petit problème : par défaut foremost ne recherche pas les fichiers CAB, mais bon comme on vient de l’écrire, c’est un « petit » problème : on édite rapidement le fichier /etc/foremost pour y rajouter la ligne suivante et le tour est joué.

foremost_conf

Voici alors le résultat de notre recherche :

foremost

Nous avons bien récupéré un fichier png et cab. Reste à vérifier que ce dernier est bien un fichier Microsoft Cabinet valide :

cabextract

Cela semble tout à fait correct : Nous pouvons donc poursuivre notre analyse avec ce fichier fraichement extrait. Pour ce nouveau binaire nous adoptons la même stratégie : file, strings et hexdump.

mefile
Nous avons bien un fichier PE32 valide. Mais le plus intéressant vient du résultat de la commande strings. En effet le fichier contient une chaîne très longue (plus d’un million de caractères) et qui ressemble fortement à du base64. En particulier, on note en fin de la chaîne la présence de bourrage XPADDINGX. Après un rapide petit nettoyage, on décode la chaîne et on récupère non pas un mais deux fichiers.

Le premier est un fichier binaire et en consultant les propriétés du fichier, nous apprenons que  c’est un interpréteur du langage de script autoIT (Lien vers autoIT) et il semble tout à fait légitime : Les recherches de son condensat sur VirusTotal n’indiquent rien de malveillant. Nous avons donc affaire à l’interpréteur officiel du langage AutoIT.

clll
Le second est un fichier texte et n’est autre que le script qui sera exécuté grâce à cette interpréteur.

script

Vous noterez au passage la concordance des temps (de modification) entre ces deux fichiers.

Le binaire étant légitime, concentrons-nous sur le script !

En aparté, sachez qu’AutoIT est très puissant et visiblement les auteurs de logiciel malveillant l’apprecient comme en témoigne ce lien.

Ce script est particulièrement intéressant et c’est d’ailleurs sur ce dernier que nous avons passé la plus longue partie de notre analyse, d’abord parce qu’il utilise un langage qui nous était certes inconnu, mais ça reste du langage scripté donc pas de décompilation. Ensuite il fait des choses assez originales : Comprendre que c’est la première fois que dans notre très jeune expérience d’analyse de virus, nous rencontrons un truc autant tiré par les cheveux.

L’avantage d’un script est qu’on peut le lire sans décompilation. Mais cela se révèle sensiblement plus compliqué que prévu : Les attaquants redoublent d’effort pour rendre le code le moins intelligible possible et ralentir l’analyse.

Tout d’abord nous constatons quelques petites mesures de détection d’antivirus et de sandboxing

testav_vm

Notons tout de même que les trois derniers tests ne sont jamais vrais : la $var1 est initialisée à 0.
Ensuite, le virus cherche à passer sous le radar des antivirus et autres possibilités de détection fortuite en créant un sous-répertoire dans le répertoire utilisateur et en s’y copiant lui-même ainsi que cLLL.exe (l’interpréteur).

hide_files

L’option « +SH » donne les attributs System et Hidden au répertoire et ses fichiers : permettant de rendre ce sous-répertoire quasi-invisible. Notons que dans ces conditions, ce répertoire n’est par exemple plus scanné par défaut par Avast. Les éditeurs d’antivirus n’aiment pas trop scanner les fichiers systèmes : cela garantit un certain niveau de persistance sur le poste.

Ensuite, le code est truffé de tests conditionnels sur des variables statiques : cela rend la lecture difficile mais des CTRL-F et autre chercher/remplacer nous permettent rapidement de faire le ménage dans le code.

Nous tombons sur des morceaux de code comme celui-ci que nous pourrions qualifier de « Third layer of Inception » :

inception

On vous laisse apprécier : Avez vous noté le « TVq » en base64 ?

Bref au final, nous découvrons que le script contient encore un binaire caché dans les commentaires : le 3eme depuis le début, ça commence à devenir une habitude.

Ce binaire que nous appellerons pudiquement charge.exe est un executable PE32 valide, mais il n’est jamais exécuté directement par le script. Et c’est là que ça devient un peu ésotérique pour nous. En effet, au lieu d’extraire charge.exe et de l’exécuter directement, le script préfère se lancer dans une entreprise beaucoup plus complexe :

Notons l’utilisation de code compilé directement dans le script :

"0xC81000005356578365F800E8500000003EFFFFFF3F3435363738393A3B3C3DFFFFFF00FFFFFF000102030405060708090A0B0C0D0E0F10111213141516171819FFFFFFFFFFFF1A1B1C1D1E1F202122232425262728292A2B2C2D2E2F303132338F45F08B7D0C8B5D0831D2E9910000008365FC00837DFC047D548A034384C0750383EA033C3D75094A803B3D75014AB00084C0751A837DFC047D0D8B75FCC64435F400FF45FCEBED6A018F45F8EB1F3C2B72193C7A77150FB6F083EE2B0375F08A068B75FC884435F4FF45FCEBA68D75F4668B06C0E002C0EC0408E08807668B4601C0E004C0EC0208E08847018A4602C0E00624C00A46038847028D7F038D5203837DF8000F8465FFFFFF89D05F5E5BC9C21000"

Une fois la chaîne décompilée en assembleur, cela ressemble à un « base64 -d »  qui permettra de décoder le commentaire/charge en mémoire.

Parser le contenu du binaire pour en extraire les différentes fonctions et les charger via des appels à des DLL  (entre autre kernel32.dll, user32.dll, avdapi32.dll) et  ainsi les injecter dans un process qui semble légitime : RegSvcs.exe est ici visé en priorité.

Ainsi, alors que les premières variables ont des noms très aléatoires, ici on observe une certaine « rigueur » dans le nommage des variables

dllstruct

Ces noms de variables ne sont pas sans rappeler les sections d’un fichier exécutable.

Résultat des courses : ce code est injecté en mémoire et se lance alors dans l’espionnage de l’activité sur le poste.

Lorsque nous nous penchons plus attentivement sur cette charge, nous nous apercevons qu’elle n’est pas packé et est semble-t-il codé en « Microsoft Visual C# / Basic .Net » si on en croit PEiD. Le résultat de la commande file nous met aussi sur la piste d’un fichier .NET.

charge

Aussi pour une fois, le code binaire ne sonne pas le glas de notre analyse. Nous pouvons utiliser l’outil de RedGate Reflector pour décompiler. Nous découvrons alors le coeur du logiciel malveillant.

Il y a quelques fonctions au nom plus qu’évocateur:

functionnames

On retrouve aussi des informations intéressantes :

Il communique avec un CC via des requêtes HTTP : les communications ne sont pas chiffrées, le canal de communication passe sur de l’http simple (sans surcouche SSL/TLS) et les requêtes HTTP sont globalement explicites.

L’objectif de ce malware semble surtout de voler des identifiants de messageries et de comptes internet ; il se concentre en effet sur les navigateurs et les clients lourds de messagerie.

Nous remarquons enfin qu’il contient encore trois blops binaires. A la lecture du code, on se rend compte que ces données sont chiffrées en AES mais avec une fonction assez simple.

Outre son nom étrange « RSMDecrypt », elle utilise la fonction de dérivation Rfc2898DeriveBytes avec une itération au lieu des mille recommandées.

public static byte[] RSMDecrypt(byte[] ƈƖƻƨÔ, byte[] ƄƏƵÉ)
{
    Rfc2898DeriveBytes bytes = new Rfc2898DeriveBytes(ƄƏƵÉ, new byte[8], 1);
    RijndaelManaged managed = new RijndaelManaged {
        Key = bytes.GetBytes(0x10),
        IV = bytes.GetBytes(0x10)
    };
    byte[] src = managed.CreateDecryptor().TransformFinalBlock(ƈƖƻƨÔ, 0, ƈƖƻƨÔ.Length);
    byte[] dst = new byte[(src.Length - 0x11) + 1];
    Buffer.BlockCopy(src, 0x10, dst, 0, src.Length - 0x10);
    return dst;
}

Bref, une fois déchiffrés, les blops se révelent être des nouveaux binaires ; Ils confirment notre première analyse de code. Ainsi le premier n’est autre que « WebBrowserPassView » et le second se revèle être « Email Password-Recovery ».

webrecover

Enfin le dernier blop binaire n’est semble-t-il jamais utilisé dans le code et ressemble à ce qui pourrait être du chinois… Un début d’attribution ?

Et voici un petit schéma qui récapitule tout cela à regarder en écoutant Fred Kal (qui a inspiré le nom d’une des charges.)

resume

Mais prenons un peu de recul par rapport à ce démontage et concentrons nous sur ce que nous avons pu apprendre des attaquants :

Tout d’abords les technologies utilisées : on remarque pour quasiment toutes les étapes une forte adhérence à l’écosystème Microsoft : Macro, Cabinet Files, Script AutoIT et binaire .Net.

Ensuite, il n’y a pas de métadonnées intéressantes dans les différents niveaux excepté dans la charge finale où nous trouvons des métadonnés probablement forgées par les attaquants mais qui donnent une idée de l’origine géographique.

Sur l’origine géographique des attaquants, on remarque la présence récurrente d’encode en UTF-16. De plus bien que la langue par défaut du binaire final ait été écrasée (langID=0), certains noms de variable ou fonction paraissent très abscons en alphabet latin.

Un troisième point aiguise notre curiosité : la fameuse fonction RSMDecrypt. Ce nom de fonction semble sortir de nulle part et ne fait pas référence a priori à un chiffrement particulier. Après avoir creusé le sujet sur internet, on se rend compte qu’il y a 3 types de ref à cette fonction :

  • Des dumps de la fonctions sur divers forums et blogs
  • PasteBin avec du code malveillant
  • Des sites d’analyse de code malveillant

Il est par contre intéressant de regarder la chronologie de ces diverses apparitions : la première d’entre elle date de 2012 sur un forum francophone.

Nous sommes dans un cul de sac : on appelle alors un ami qui nous parle d’une protection contre les attaques par canaux cachés : Rotating S-box Masking. Bref, il semble bien que les attaquants s’inspirent de truc qu’ils ne comprennent pas forcément.

Enfin, une autre fonction de chiffrement (cette fois-ci un simple XOR) est présente dans le code. Mais c’est la clé qui pour ainsi dire nous donnera la clé pour avancer.

xor.png

Ainsi déchiffrés nous obtenons :

  • CreateProcessA             ‘ĈőŘĝŏŒįķŎŖġŎŠĠz’
  • GetThreadContext         ‘ŝƕƸšƔưƕŷƔƇżƚƲƕƎƤË’
  • GetThreadContext        ‘ķůƒĻŮƊůőŮšŖŴƌůŨž¥’
  • SetThreadContext         ‘ńŰƓļůƋŰŒůŢŗŵƍŰũſ¦’
  • Wow64SetThreadContext     ‘ŨƚƶľśƌƐƅſƧźƌƚƏŔƚƭżƌƱƟÆ’
  • ReadProcessMemory         ‘ĴšűĽňżūŅšƃŌŅůũőŮƉ\x97’
  • WriteProcessMemory         ‘ŇżƇśūŨżşŭƃŚŹťůŝŹƐŠ¥’
  • NtUnmapViewOfSection     ‘ıűŦňŦŬŭĹŦŶőňűŐňŠƅŃŨŹ\x98’
  • VirtualAllocEx             ‘ńűƎřŹŷŴįŴƈŔŧśƀ£’
  • ResumeThread             ‘ŵƢDŽƏƦưƑƋƯƶŻƝØ’

La clé de chiffrement est « KeyBase » et cela nous fait vite faire le lien avec cette mire d’authentification trouvée sur le site compromis :

mire.png

A partir de là, nous obtenons beaucoup d’information sur notre logiciel malveillant. Notamment Palo Alto a fait une analyse très intéressante sur le sujet

Publié dans Analyse, Malware, Sensibilisation | Tagué , , , | Laisser un commentaire

Certains ne devraient pas dire ça

Annonce préalable : Il y a un peu de mauvaise foi dans ce qui suit !

Ca y est : nous sommes le deuxième mardi du mois et autrement dit le jour où Microsoft sort ses correctifs mensuels. Un de ces correctifs a une saveur particulière. Techniquement, l’affaire n’a rien d’exceptionnel. Mais c’est plutôt sur la forme.

En effet la semaine passée, les équipes sécurité de Google ont publié des informations techniques et très précises sur cette vulnérabilité. Normalement, Google donne une période de 90 jours à l’éditeur pour corriger la vulnérabilité avant de la rendre publique. Cependant ici ce ne fut pas le cas : sous prétexte que la faille est « activement exploitée », ils ont décidé unilatéralement de rendre publique la vulnérabilité avant que l’éditeur ne soit en mesure de sortir un correctif 7 jours après la notification.

Sans vouloir tomber dans le manichéisme primaire, il y a de quoi trouver la démarche cavalière :

  • L’équipe sécurité de Google semble en vouloir à Microsoft : c’est au moins la troisième fois que Google publie un avis avant la sortie d’un patch : On notera qu’il semble y avoir deux vitesses en fonction d’où se trouve la vulnérabilité : Pas plus tard que le mois dernier, ils ont étendu la période des 90 jours pour une vulnérabilité Apple.
  • Dans un article de blog ironiquement appelé « disclosing vulnerabilities to protect users », rendre publique une faille aussi critique n’est pas si bénéfique. Cela est à nos yeux d’autant plus contre-productif que les pirates sont d’excellents techniciens et s’approprient très vite ces nouvelles attaques alors que la majorité des défenseurs sont à la traine. A titre d’illustration, prenons par exemple un des domaines utilisés pour l’envoi massif de spam implémente SPF et DKIM, quand la majorité des serveurs légitimes ne proposent pas encore de StartTLS : Voyez-vous le problème ?

On ne veut pas jouer les vierges effarouchées : mais à un moment donné, il faut prendre du recul et avoir une vision globale du problème. Tout le monde n’est pas un expert en détection d’intrusion ni même un utilisateur averti : Google le premier devrait être au courant : c’est bien eux qui ont rencontrés des utilisateurs qui confondaient le symbole du cadena des pages en HTTPs avec un sac à main.

En effet jusqu’il y a encore quelques années, il était encore permis de prendre les attaques informatiques avec une certaine philosophie : « Y a pas mort d’hommes » avons-nous entendu maintes et maintes fois lorsqu’un utilisateur cliquait sur une pièce jointe ou un lien malveillant.

Aujourd’hui nous ne pouvons plus l’ignorer : l’informatique gère de plus en plus de systèmes critiques et un simple rançongiciel (ie: attaque non-ciblée) peut rapidement avoir des conséquences sur des vies humaines en témoigne l’incident dans cet hôpital britannique.

Quels bénéfices peuvent en tirer les majorités des équipes informatiques des révélations de Google ? Notez que nous n’osons même pas parler des équipes de sécurité, elles sont parfois  inexistantes ou mal dimensionnées : Prenons le cas de l’ANTS. Vous savez l’agence qui gère en autre l’édition des passeports français (un truc que d’aucun pourrait qualifier de sensible) et aussi le fameux fichier sur les soixante millions de compatriotes au sujet duquel tout le monde s’écharpe : l’équipe de sécurité se résume à un gars.  On veut bien parler de démarche de sécurité intégré mais bon y a un minimum ! Pour mémoire on a déjà vu ce que ça pouvait donner de n’avoir qu’un seul membre dans une équipe sécurité.

Avant d’aller plus loin, on attire l’attention sur l’absence totale de réactions des états souverains sur le sujet mise à part l’alerte du CERT-FR.  D’ailleurs à la lecture des recommandations laconiques (i.e: ne surfez plus en attendant la mise à jour), on sent bien que l’ANSSI est plus qu’impuissante sur le sujet.

A contrario, on se rappelle de la réplique administrative à la publication d’un post sur la sécurité du Wifi et plus récemment si un petit jeune en panne d’inspiration renomme son réseau Wifi : le mec passe au tribunal directement. Mais dans le cas de Google qui potentiellement balance une arme d’infiltration massive sur tous les postes utilisant Windows : Silence radio ! On rappelle que jusque très récemment la divulgation de vulnérabilités était passible de poursuite en France. M. Poupard, où est notre souveraineté face aux géants du net ?

Fin de l’aparté. Le problème principal est que la sécurité est encore et toujours perçue par beaucoup comme une source de contrainte mais aussi et surtout de coût. « Emprunter de l’argent coute aussi de l’argent » disent-ils dans le slogan. Nous avons un scoop pour vous les gars : Avec la sécurité  qu’elle soit incendie, routière, informatique : même combat ! Cela va couter du pognon : pour recruter, pour former, pour sensibiliser, pour implémenter, pour auditer, pour analyser, pour investiguer … Et oui cela va empiéter sur la si précieuse rentabilité de vos équipes et vos bénefs et cela risque de contrarier le comité de direction : L’argent reste encore le nerf de la guerre !

Mais n’oubliez pas : c’est aussi ce qui pourrait permettre de sauver votre boite. Et ce n’est pas qu’un fantasme des paranos de la sécurité :  60% des PME mettent la clé sous la porte après une attaque.

L’histoire de TV5 Monde est assez éloquente en la matière : Malheureusement tout le monde n’a pas la chance d’avoir l’ANSSI à son chevet et des subventions en perfusion !  De son coté,  le FBI le résume aussi assez bien dans sa campagne de sensibilisation.

Alors une grande partie des entreprises commencent à intégrer ces risques et comprennent qu’il est préférable d’anticiper que de subir et recrutent ardemment des RSSIs (il parait que cela a la côte). Parfois, cela fait suite à un incident parfois, cela est anticipé, voir dans certain cas imposé…  Mais malheureusement, on finit par tomber sur des articles comme celui-ci. Avec ce genre de discours, il ne faut s’étonner que les budgets soient en bernes.

Rappelons qu’il y a deux types de RSSI : ceux dont l’entreprise a été piratée et ceux qui savent que leur entreprise a été piratée.

Il y a fort à parier que les équipes des RSSIs interviewés dans cette étude sont confortés dans leur idée d’invincibilité par les cohortes de firewalls, HIPS et SIEM déployés sur leurs systèmes. Rappelez vous comment la DSI d’Areva était fière de ses systèmes et de sa certification ISO 27001.  On ne va pas revenir aux fondamentaux mais Bruce le dit très bien : “If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.”

Et parions que ce sont probablement les même RSSI qui accusent l’ANSSI de piller le marché des compétences sécurités…

En effet, n’oublions pas qu’avant tout il faut des femmes et des hommes pour mettre en place de la sécurité et faire évoluer les mesures organisationnelles et techniques. Ces compétences ne s’inventent pas : l’ANSSI propose pléthores de postes et ce de façon continue. Nous invitons d’ailleurs tout le monde à aller faire un tour sur cette page afin de bien mesurer l’étendu et la diversité des métiers de la sécurité de l’information.

Donc arrêtons avec la politique de l’autruche, arrêtons avec les fiches de poste couteau suisse « Expert en Reverse, en Gestion Incident, en Analyse de Risque, en Aspect juridique et en Architecture », arrêtons avec les « j’ai une équipe de sécurité : bon c’est 1 gars mais je vous assure il est balaise ! » (cf l’incident TV5Monde et bientôt peut-être celui de l’ANTS ?). Parce que oui, dire qu’on fait aussi bien que le voisin revient à dire qu’on fait les choses aussi mal que lui.

« Wake up, Neo » comme dirait l’autre !

Allez une soupe et au lit : en espérant que cela aille mieux demain… ou pas !

Publié dans Sensibilisation | Tagué , | 3 commentaires

Anodin Odin

Depuis quelques jours, les serveurs de messageries sont sous le joux d’une campagne massive de messages malveillants.

Encore un nouveau rançongiciel ! Décidément, ils sont à la mode : cela fait plus d’un an qu’on se prend vague sur vague des Locky et consort. Le principe est quasiment toujours le même : un message avec une pièce jointe qui va téléchargé une charge qui chiffre les données sur votre poste et ses partages réseaux…

Cependant la dernière campagne est intéressante pour deux raisons :

Premièrement,  même si le vecteur de contamination reste le même : fichier office avec des macro. Le code de ces dernières n’est pas aussi obfusqué que d’habitude. Preuve que les pirates se lassent peut-être : en tous les cas, la puissance olevba ou oledump peut s’exprimer pleinement pour en extraire rapidement des informations pertinentes à l’analyse et la recherche d’IOC.

 | IOC        | http://juyinggroup.c | URL                                     |
 |            | om/g76ub76           |                                         |
 | IOC        | ll32.exe             | Executable file name                    |
 | IOC        | P.dll                | Executable file name                    |
 | IOC        | rundll32.exe         | Executable file name (obfuscation: VBA  |
 |            |                      | expression)

Le code VBA des macros laisse aussi paraitre que les auteurs seraient hispaniques. En effet, bon nombre de variables et noms de fonction sont directement pris de l’Espagnol. Voici quelques exemples :

For i = 1 To Len(permiso)
 letra = Mid(permiso, i, 1)
 If letra = "A" Then
  Alta = True
 End If

 If letra = "B" Then
  Baja = True
 End If

 If letra = "M" Then
  modi = True
 End If

 If letra = "C" Then
  Consu = True
 End If
Next i
If Len(permiso) = 0 Then
 Consu = False
 modi = False
 Alta = False
 Baja = False
End If

Info ou intox de la part des attaquants ?

La seconde nouveauté concerne l’exécution de la charge:
Notons que le code de la macro ne télécharge plus directement un exécutable mais un blop binaire qui est par la suite déchiffré (XOR avec une clé de 32 caractères). Ce stratagème permet à la charge de passer inaperçue même au travers d’un proxy HTTP. Une fois déchiffrée cette charge est toujours un fichier PE mais ce n’est pas un exécutable EXE mais une bibliothèque de liens dynamiques (ie : une DLL).

jshmendes@cb:~$ file charge.bin
 charge.bin: PE32 executable (DLL) (console) Intel 80386 (stripped to external PDB), for MS Windows

Cette DLL est alors exécutée à l’aide de rundll32.exe avec la commande suivante :

Call Shell("rund" & "ll32.exe " & moyaMANUNAUUUKA & ",qwerty", vbHide)

Cet appel à travers rundll32.exe présente l’avantage de contourner les éventuelles restrictions AppLocker présentes sur le poste ciblé : Non seulement la charge s’exécute même s’il y a un filtrage sur les fichiers DLL, mais en plus les journaux d’événements ne voient rien, rendant l’investigation moins triviale.

Notons qu’il s’agit ici d’une limitation connue d’AppLocker (Et non ce n’est pas une vulnérabilité d’après Microsoft). Rajoutons que ce n’est pas la seule technique pour contourner une politique de restriction d’exécution sous Windows, mais que c’est probablement la plus efficace et la plus simple à mettre en oeuvre.

Cette limitation laisse donc les postes vulnérables à cette nouvelle campagne de rançongiciel qui prend le doux nom d’Odin (en référence à l’extension utilisée pour renommer les fichiers chiffrés). Après Locky, voici donc une autre divinité de la mythologie nordique qui met à mal la sécurité des données.

Publié dans Outils, Uncategorized | Tagué , , , , | Laisser un commentaire