Compression et chiffrement

L’utilisation de la cryptographie n’a pas de finalité en soi : elle sert un objectif particulier qui peut varier suivant le contexte et s’insère dans le traitement de données que l’on souhaite protéger.

Dans quel ordre est-il plus pertinent de réaliser les opérations de chiffrement et de compression de données ?

On a alors un chance sur deux de se planter :

  • Soit on répond « on compresse puis on chiffre »
  • Soit on répond « on chiffre puis on compresse »

La réponse peut paraître évidente à certains mais détaillons. Pour répondre rappelons deux choses :

Comment chiffre-t-on des données ?

Le propre du chiffrement est de décoréler un maximum le message original (en clair) de sa version chiffrée afin d’éviter que l’attaquant puisse retrouver l’original s’il intercepte le chiffré.

Comment compresse-t-on des données ?

Les algorithmes classiques de compression au contraire utilisent la réccurrence (i.e: la fréquence) de certains blops dans les données.

Voici deux exemples triviaux de compression de données sans perte :
« CCCCCCC » => 7*C
« CryptoBourrinCrypto » => Crypto1/3Bourrin2

Bien évidemment, les algorithmes modernes de compressions sont bien plus élaborés que ces deux exemples simplistes. Mais ces derniers illustrent une des logiques utilisées pour stocker des données en minisant la taille de la mémoire utilisée.

Du coup, si nos données sont chiffrées, donc avec une entropie forte. Les algorithmes de compression seront peu voir pas du tout efficaces.

Ainsi voyez-vous la réponse s’impose d’elle même : il vaut mieux commencer par compresser les données puis les chiffrer si l’on veut optimiser la taille du résultat pour des transmissions ou stockages. Car compresser du chiffrer, ça ne sert pas à grand chose sauf quand on s’appelle Microsoft et qu’on utilise des archives compressés comme fichier pour sa suite bureautique.

Le cas de Microsoft Office

En effet, Ms Office  depuis la version 2007, les extensions qui finissent en x (.docx, .xlsx, pptx, …) ne sont rien d’autres que des répertoires compressés. Nous pouvons donc les renommer en .zip et les ouvrir avec l’outils de Microsoft et comparer la version chiffrée et celle qui ne l’est pas. Regardons ce qui se passe dans le cas de l’utilisation de la fonction de confidentialité de Microsoft Word.

Nous avons rapidement créé un fichier Word et nous l’avons copié et chiffré la copie afin de comparer les tailles des deux fichiers puis nous avons ouvert l’archive de la version chiffré où on retrouve quelques méta-data et un « EncryptedPackage » faisant la même taille que le fichier originel.

Fichiers_office

On ne détaillera pas ici le mécanisme de chiffrement  d’Office qui mériterait bien un article à lui tout seul (un jour peut être). Mais nous voulions simplement voir comment il gérait le chiffrer/compresser : du coup nous avons la réponse : on compresse , on chiffre et on recompresse !

Un fichier chiffré peut-il être plus petit que sa version en clair ?

Avec de l’exemple précédent, certains nous diront que la réponse est évidente, le simple fait de chiffrer avec du symétrique par bloc c’est déjà rajouter a minima deux informations :

  • un vecteur d’initialisation (car si c’est pour faire de l’ECB, autant ne rien faire)
  • du bourrage à la fin du fichier

Ce n’est pas énorme mais cela suffit à avoir une taille strictement supérieure à l’original, suivant le mécanisme choisi on peut également avoir des entêtes (ou autre méta-données) à rajouter dans le fichier, mais parfois cela peut être un peu plus voir beaucou plus…

Le cas de S/MIME

Un grand classique pour illustrer cela est l’utilisation des messages S/MIME. En effet, le chiffrement peut poser problème en empéchant les messages de partir : Pas directement, mais par effet de bord. La plupart des systèmes de messagerie (notamment d’entreprise) ont des limites sur la taille du message qu’ils peuvent recevoir et transmettre pour des raisons tout à fait légitime de bon fonctionnement. Dans le cas contraire, imaginez les magnifiques attaques à base d’envoie de fichier de plusieurs giga, mais on s’éloigne du sujet.

Nous avons sur ce blog déjà abordé le S/MIME. Mais qu’il nous soit permis de rapidement rappeler que le S/MIME permet de chiffrer le contenu du corps d’un message MIME et ses pièces jointes. Rappelons aussi que le MIME est du pure ASCII, ainsi toutes les pièces jointes qui contiennent des caractères non imprimables sont convertis en base64 ce qui par définition multiple la taille du message par 4/3 mais si on rajoute le chiffrement qui s’applique au message en base64, le chiffrement rajoutant de l’entropie on se retrouve avec des caractères non-imprimables. On rajoute donc une nouvelle fois une conversion en base64 du chiffré soit une nouvelle augmentation de la taille du message de 4/3 : soit un total de 16/9.

 

Donc le chiffrement S/MIME multiplie la taille du message par 1,33 (1.78 par rapport aux pièces jointes) : c’est pas rien quand même !

Voilà, ce sont des petites considérations à garder en tête quand vous devez calmement expliquer au directeur financier que le chiffrement c’est bien, mais qu’il ne peut pas envoyer le bilan financier en S/MIME car le message est « tros gros » alors que tout le COMEX attend le document pour avant-hier…

Une petite image pour méditer pendant vos vacances :

rockdriving_smime

 

Publicités
Publié dans Cryptographie Symétrique, Système, Uncategorized | Tagué | Laisser un commentaire

Cher Recruteur

Dans un poste depuis plusieurs années et pas franchement très heureux, nous avons souhaité en changer. Nous nous sommes donc mis à l’écoute du marché scrutant les offres à la recherche de la perle rare : Vous savez le fameux boulot qui combine une mission intéressante, des conditions correctes et le tout dans un endroit sympathique, tout cela étant vous en conviendrez très subjectif. Car comme nous disait un de nos professeurs en Résistance de Matériaux (#MyPathToInfoSec), « Il n’y a pas de bon ou mauvais matériaux, il y a un matériaux qui répond à un besoin précis ». Et chacun a ses attentes quand il cherche un emploi.

Nous avons passé un nombre certain d’entretiens et en sommes souvent sorti déçu : Rares sont les fois où les recruteurs ont su nous démontrer de l’intérêt pour le travail offert car souvent après avoir été cuisiné et harcelé de questions sur notre parcours, nos compétences, nos motivations, vient le moment pendant lequel les recruteurs nous permettent de poser quelques questions. Systématiquement nous posions la question « Et pourquoi devrais-je venir travailler chez vous ? ». Question très souvent suivie d’un échange de regard surpris entre recruteurs et presque toujours d’une réponse peu convaincante.

Ce constat fait particulièrement écho dans le contexte où beaucoup se plaignent de la pénurie de talents en sécurité des systèmes d’information, de ne pas trouver de candidat, de ne pas remplir les formations en sécurité.

Voici quelques notes en vrac fondés sur des retours d’expériences personnelles ou de connaissances :

Tout d’abord la description de poste :

  • La fiche de poste digne de l’incipit des Confessions de Jean-Jacques Rousseau : Tellement ambitieuse qu’une fois lu, même les plus vaillants membres de l’équipe se disent qu’ils n’ont pas le niveau pour postuler (par ex: Demander un doctorat pour faire de l’administration de pare-feu):  Au final les candidats retenus ne sont pas adaptés et/ou surqualifiés et ne donnent pas suite : Chers recruteurs, soyez honnêtes !
  • La fiche multifonction : on a déjà parlé de ce fameux syndrome  du couteau suisse mais il est tellement récurrent. Combien de fiches de poste peut-on lire où il est demandé au candidat d’être à la fois expert en réseau, en méthodologie EBIOS et en rétroconception x64 sur MIPS : Chers recruteurs, une fois encore soyez réalistes !
  • Les postes « carte blanche » : à la mode avec l’arrivée de ce nouveau règlement. Les entreprises prennent conscience du besoin d’avoir un(e) monsieur/madame sécurité et c’est tant mieux, et partant d’un honnête constat qu’ils n’y connaissent rien ou presque, souhaitent recruter un sachant. Mais ils veulent surtout/seulement recruter un responsable qui pourra être désigné comme coupable le moment venu. Ce RSSI se verra confier un titre honorifique mais quasiment aucune liberté d’action car pas de soutien de la hiérarchie et/ou pas de budget.  Dans la gestion de la SSI, le recrutement d’un responsable n’est pas une fin en soi mais uniquement la première étape d’un long et douloureux chemin : Chers recruteurs, soyez cohérent dans votre logique et donnez nous les moyens de vos ambitions !

Ensuite, les offres regorgent de l’expression « packages attractifs ». Même s’il est plaisant pour un candidat de savoir que son salaire sera élevé, ce n’est pas le seul critère de décision et bien souvent pour les passionnés, il ne constitue pas l’élément le plus important.  Faire la liste exhaustive de ces critères est très compliqué car les besoins évoluent au fil du temps, des profils et sont souvent très personnels. Mais citons en quelques uns qui nous paraissent parmi les plus importants:

  • Travailler sur des objectifs concrets pour une mission en laquelle on croit : On ne parle pas forcement des gens qui dorment en slip Bleu-Blanc-Rouge et qui veulent travailler à la Piscine. Mais sachez que la motivation est aussi de savoir que ce que l’on fait, ce que l’on protège est utile. La complexité des systèmes informatiques mais aussi des organisations qui les utilisent rend parfois difficile voir impossible de comprendre l’utilité de son job.  D’autres ne souhaiteront pas travailler pour les  Qosmos, Amesys ou autre Suneris solution parce que cela ne correspond pas à leurs éthiques et valeurs morales.
  • Travailler dans un environnement stimulant : Il est pour certains aussi important de savoir qu’ils seront immergés dans un milieu stimulant : challenge technique, liberté de proposer et tester des solutions novatrices. Cela peut paraitre anecdotique mais beaucoup d’entre nous sommes avant tout des gens curieux et nous aimons bidouiller, retourner un problème dans tous les sens pour en proposer la solution qui nous parait la meilleure et pas seulement nous limiter à implémenter la solution rapide, économique, temporaire (pour les dix prochaines années) mais inélégante.
  • Travailler sans stress : C’est un besoin très personnel, chacun ne ressent ni ne gère les émotions de la même façon. Mais globalement personne n’aime subir de stress de façon continue : pourtant on voit souvent dans les annonces des qualités requises « savoir gérer le stress » (Note : le nombre de retours sur une recherche sur le mot clé « stress » sur un site d’annonce est d’ailleurs assez frappant) ou des choses du genre. On a du mal à comprendre le pourquoi du comment. Si un employé en est à devoir gérer le stress, c’est que quelqu’un dans la boite ne fait pas son job (i.e n’assume pas ses décisions). On conçoit le travail sous pression ou dans l’adrénaline, et on peut même aimer cela. Mais le stress ? Faudra qu’on nous explique !
  • Travailler dans une équipe : La sécurité ne doit pas être perçue comme la cinquième roue du carosse. Nous sommes sensibles un supérieur qui sait relayer les messages entre les différentes équipes et résoudre les sources de tensions pour faire de la sécurité une démarche intégrée. Cette dernière expression peut paraître un peu bateau. Mais il faut arréter de nous faire croire que la sécurité est uniquement une affaire de spécialistes. L’émulation entre collègues (SSI ou autre) est aussi une source d’enrichissement pour compléter notre vision d’un problème.
  • Avoir la capacité de continuer à apprendre : cela est peut-être le plus important. Les technologies avancent tellement vite que c’est une nécessité absolue de se former en continu. Il est vrai que cela a un coût important et en plus récurrent (notamment quand on va chez SANS). Mais il participe aussi à montrer à vos employés que vous les valorisez. Et cette formation peut avoir différentes formes. Certes, la plus évidente reste d’envoyer régulièrement les gens en formation chez feu-hsc ou autre. Mais ce n’est pas la seule manière, citons aussi les participations à des conférences où on apprend souvent autant pendant les présentations qu’en échangeant avec différentes personnes pendant les pauses. N’oublions pas encore une fois l’émulation et l’échange entre collègues. Nous apprenons beaucoup de nos collègues et on espère modestement qu’ils apprennent aussi grâce à nous.

Bien sur, il y a aussi des aspects extra-professionnels qui peuvent entrer en ligne de compte : la situation géographique des locaux (Tout le monde n’est pas fan de Paris), la flexibilité sur les horaires, travail depuis la maison, le nombre de jour de congés, la facilité de combiner vie privée vs professionnelle, le droit à la déconnexion etc. Mais tout cela n’est pas propre à la SSI.

En conclusion, les quelques points cités ci-dessus ne sont que des exemples que nous avons pu recueillir à droite ou à gauche en échangeant sur notre vision du métier. En résumé, chers recruteurs ne demandez pas uniquement ce que votre candidat peut faire pour vous, mais plutôt ce que vous pouvez faire pour lui !

Car vous remarquerez que même s’il y a une pénurie évidente de talent en SSI, les entreprises où il fait bon travailler, elles, ne s’en plaignent pas !

 

Publié dans Sensibilisation, Uncategorized | Laisser un commentaire

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