vendredi 23 décembre 2016

CSRF demystifié et enfin réglé ! http://bit.ly/2ikHu7e #appsecfr #appsec #lk


from Twitter https://twitter.com/SPoint

December 23, 2016 at 04:29PM
via IFTTT

vendredi 9 décembre 2016

BMW prend la main sur votre voiture a distance http://bit.ly/2grEGTx #appsecfr #appsec #lk


from Twitter https://twitter.com/SPoint

December 09, 2016 at 11:04AM
via IFTTT

Ahahah....on va enfin connaître les vices de @ericfreyss :) http://bit.ly/2hs2Fjh


from Twitter https://twitter.com/SPoint

December 09, 2016 at 08:34AM
via IFTTT

jeudi 8 décembre 2016

mercredi 7 décembre 2016

lundi 17 octobre 2016

AppSecFR® signe un partenariat privilégié avec EdgeScan sur la France http://bit.ly/2e01mJX #appsecfr #appsec #lk


from Twitter https://twitter.com/SPoint

October 17, 2016 at 09:51PM
via IFTTT

mercredi 5 octobre 2016

jeudi 26 mai 2016

Nuit du Hack 2016 : Réservez votre place dès maintenant ! #ndh2k16

Publié par UnderNews Actu

Une fois n’est pas coutume, voici que la Nuit du Hack 2016 approche à grand pas ! Vous pouvez achetez votre place dès maintenant pour l’événement qui aura lieu le 2 et 3 juillet 2016 à l’hôtel New York à Disney Land Paris. Planning des réjouissances !

Edit 26/05/2016 : à J-39, il reste moins de 400 places disponibles d’après le staff.

Après s’être temporairement exilé à Saint-Denis l’année dernière, la Nuit du Hack (NDH) est de retour à Disney Land pour 2016. Comme chaque année, UnderNews est l’un des partenaires médiatiques. Dès samedi 9h, la journée de conférences et de Bug Bounty battra son plein. Planning en détail ci-dessous :

  • 10h00 : Keynote : À venir.
  • 10h30 : Ouverture Bug Bounty
  • 10h45 : (FR) Windows 10 – Security and Privacy par Paul Hernault
  • 11h30 : (EN) Tails – Security, Maintainability and Usability, pick three! par Julien Vosin
  • 12h15 : (FR) Microservices hacking & security par Clad
  • 13h00 : Pause
  • 13h45 : Bounty time
  • 14h00 : (EN) A Dozen Years of Shellphish: From DEFCON to the DARPA Cyber Grand Challenge par Antonio Bianchi
  • 14h45 : (FR) Review of the ZigBee security of a famous French set-top box par Renaud Lifchitz
  • 15h30 : (EN) An In-Depth Dive into the Ethereum Protocol par Lefteris Karapetsas
  • 17h00 : Bounty Time
  • 17h15 : (FR) House intercoms attacks: when frontdoors become backdoors par Sébastien Dudek
  • 18h00 : (EN) Improvised LockPicking tools par Till Lenze et Alexandre Triffault
  • 18h45 : (FR) Turning a GPS-based dating application into a tracking system par Julien Szlamowicz et Julien Legras
  • 19h30 : (EN) Developing x64dbg par Duncan Ogilvie
  • 21h00 : Bounty Time
  • 21h15 : (FR) Mass-pwning with a small IoT spy bug par Damien Cauquil
  • 22h00 : (EN) Trust No One. ATMs and their dirty little secrets par Olga Kochetova

Déroulement de la Nuit du Hack 2016

Après cet horaire, ça sera comme d’habitude une déferlante d’activités qui vous seront proposées : CTF privé pour les meilleures équipes de hackers internationales, challenges publics (le Wargame), et de très nombreux ateliers pratiques qui vous donneront l’opportunité d’aborder tout un tas de choses plus intéressantes les unes que les autres. Que demander de plus ?

ndh_map_fr

Et ce n’est pas fini, puisqu’il faut aussi citer les divers intervenants qui, tout au long de la journée, permettront à certains une aide no négligeable. En ce sens, YesWeHack sera l’interlocuteur privilégié pour les relations entre recruteurs et chercheurs d’emploi dans le secteur de la cyber-sécurité (HACKDATING), NDH Kids permettra quant à elle d’occuper intelligemment vos enfants si ces derniers vous accompagnent, tandis que le confessionnal Zataz sera là pour ceux souhaitant se repentir en alertant sur d’éventuels vulnérabilités découvertes au seins de services en ligne.

Bref, que du bon durant ces 24 heures intenses et éprouvantes ! L’événement est toujours organisé par Hackerz Voice (HZV) en partenariat avec Sysdream.

Les workshops

20h – 06h XavDrone by XavBox
20h – 06h Lockpicking by Alexandre Triffaut & MrUbex
20h – 06h Make Your Own Arduino by DTRE
20h – 06h Hack the Tank by DTRE
20h – 06h L’horloge à LED’s by DTRE
20h – 06h Hack the ChiFouMi by DTRE
20h – 22h OWASP ZAP by Zack*
22h – 00h Practical Android Malware Analysis by PaulSec*
23h – 03h RecalMeetUp by Arnaud Velten
00h – 02h Analyzing Malicious Office Document by Didier Stevens*
02h – 04h Privacy 101 by Hackira & Deposite Pirate

Pour une description détaillée de chaque workshop, rendez-vous ici : http://bit.ly/25kRjRyworkshops.html

Côté tarifs et billetterie

Les 300 tickets « Early Bird » à 40€ sont déjà tous écoulés. Toutefois, sachez que le ticket d’entrée 2016 est encore à 50€ jusqu’au 1 juin. Après, vous n’aurez pas d’autre choix que d’opter pour un ticket « Last Minute » qui vous sera facturé 66€. Quant aux goodies, ils sont comme d’habitude très nombreux… Pour s’inscrire, ça se passe par ici. La NDH fait son grands retour à Disneyland Paris ! Centre de Congrès du Disney’s Hotel New York, Avenue René Goscinny, 77700 Chessy.

Vous pouvez suivre les actus via le hashtag Twitter #ndh2k16. Pour se rendre à la NDH, suivez les instructions détaillées sur le site officiel.

ndh2k16

Vous avez aimé cet article ? Alors partagez-le en cliquant sur les boutons ci-dessous :

1 étoile2 étoiles3 étoiles4 étoiles5 étoiles

(

1

votes, note :

5,00

sur 5)

Loading...

Mots clés : , , , , ,



via UnderNews http://bit.ly/1TEDEmf

L’évolution du modèle de sécurité : du château-fort à l’aéroport

La transformation numérique bouleverse les usages et la conception de la sécurité du système d’information. Le modèle de sécurité périmétrique historique (le château fort) n’est donc plus viable et la manière de gérer la sécurité doit s’adapter à ces nouveaux usages. Un nouveau modèle de sécurité basé sur la sensibilité des données et des traitements (l’aéroport) doit répondre à cette problématique. Il permet l’ouverture du SI vers l’extérieur pour des besoins métiers tout en protégeant les informations au juste niveau  et en gardant la maitrise des activités grâce à des moyens de détection et de réaction efficace en cas d’attaques cyber.

Un modèle de sécurité en château fort qui a atteint ses limites

Historiquement, le système d’information a été construit de manière à être isolé de l’extérieur via une muraille constituée des équipements de sécurité (pare-feu, reverse-proxy, DMZ etc.). Il repose  sur un espace de confiance quasiment unique, à l’intérieur du périmètre, avec un accès facile aux ressources de l’entreprise.

Par analogie, ce modèle historique est associé à un château-fort : entouré de murs renforcés, il dispose d’un seul point d’entrée surveillé mais ensuite le circulation est libre dans la la cité.

Ce modèle ne peut plus accompagner l’évolution des cyberattaques, plus précises et pointues. Elles savent viser directement le cœur du SI en pénétrant directement les ordinateurs des collaborateurs sans être arrêtées par la muraille, tel le cheval de Troie de la Grèce antique.

Ce modèle ne permet pas non plus de tirer tous les fruits de la transformation numérique. Celle-ci a amené les entreprises à changer fondamentalement leur conception du Système d’Information : elles sont passées d’un modèle fermé  vers l’extérieur à ouvert. D’un point de vue client et partenaires, certaines informations sont directement accessibles via Internet et les applications mobiles.  D’un point de vue du SI, l’externalisation est une réalité du quotidien, poussé encore plus aujourd’hui par le mouvement vers le cloud. D’un point de vue utilisateur, les collaborateurs utilisent de plus en plus d’outils personnels : BYOD, webmails personnels et applications personnelles sur les smartphones s’invitent dans l’environnement de travail. Toutes ces évolutions inéluctables rendent caduque la notion de périmètre.

Place à un nouveau modèle : l’aéroport

L’évolution du modèle de sécurité est donc nécessaire. Pour répondre à ces nouveaux enjeux, le modèle qui est aujourd’hui le plus adapté est celui de l’aéroport. Un aéroport est composé de zones d’accueil ouvertes au public permettant d’informer les clients ou encore de réaliser des ventes avec un niveau de contrôle minimum et adapté au contexte du pays. L’aéroport contient aussi des zones beaucoup plus sécurisées et en accès limité comme le tarmac ou les avions. Les contrôles sont de plus en plus poussés au fur et à mesure que l’on accède à des zones plus sensibles.

En sécurité de l’information, cela se traduit par des mesures de sécurité telles que des contrôles d’authentification plus ou moins élaborées (authentification forte, usage de la biométrie…), des contrôles d’intégrité et de bons usages (IDS/IPS, DLP…) afin de maitriser les accès aux zones contenant les informations sensibles de l’entreprise, et maîtriser leur manipulation.

Dans le modèle de l’aéroport, en plus des mesures de protection, il est essentiel de pouvoir détecter les éventuelles anomalies ou incidents et d’être en capacité de réagir rapidement et efficacement. C’est le rôle de la tour de contrôle, qui a pour mission de regarder au plus près (ce qui se passe dans le périmètre de l’aéroport) mais aussi au loin (les avions en approche). La tour de contrôle est capable réagir rapidement en cas de problème et d’apporter une réponse adaptée, voire d’appeler des renforts si besoin. Dans l’entreprise, ce rôle de surveillance doit être tenu par le SOC (Security Operation Center), avec si besoin le d’équipes dédiées  à la gestion de crise cyber.

Pour que ce modèle reste viable dans le temps et afin d’être efficace face à l’évolution de la menace, la revue régulière de ces mesures de sécurité est essentielle. Les avions avant de décoller subissent un contrôle de leur niveau de sécurité et les pannes sont anticipées avec la maintenance préventive, il doit en être de même pour les mesures de sécurité : habilitations, contrôles, mise à jour doivent être en continuelle évolution.

Un projet de transformation à part entière

L’enjeu majeur de cette évolution ne sera par l’acquisition de nouvelles solutions de sécurité, bien souvent les pierres du château-fort pourront être utilisées pour bâtir l’aéroport. L’enjeu sera avant tout de structurer un vrai programme de transformation pour la sécurité du SI.

Programme mêlant des évolutions technologiques (souvent principalement autour de la détection des attaques), organisationnelles (responsabilisation des équipes en particulier de maitrise d’ouvrage et de développement, intégration des nouveaux processus de contrôle…) mais aussi qui devra diffuser dans tous les projets SI les principes d’évaluation des risques et d’architectures associés. La tentation est parfois grande de mettre des systèmes sensibles mais non sécurisés directement dans le hall de l’aéroport accessibles à tous…

Le pilotage irréprochable de ce programme et la démonstration de son efficacité par la réduction des risques seront les facteur clé de la réussite de cette transformation !

Cet article L’évolution du modèle de sécurité : du château-fort à l’aéroport est apparu en premier sur SOLUCOMINSIGHT.



via SOLUCOMINSIGHTSOLUCOMINSIGHT http://bit.ly/1Z3UcCD

mercredi 25 mai 2016

Evolving the Safe Browsing API

Posted by Emily Schechter and Alex Wozniak, Safe Browsing Team 

We're excited to announce the launch of the new Safe Browsing API version 4. Version 4 replaces the existing Safe Browsing API version 3. With the launch of v4, we’re now starting the deprecation process for v2-3: please transition off of these older Safe Browsing protocol versions as soon as possible and onto protocol version 4.

Safe Browsing protects well over two billion internet-connected devices from threats like malware and phishing, and has done so for over a decade. We launched v1 of the Safe Browsing API in 2007 to give developers a simple mechanism to access Google’s lists of suspected unsafe sites.

The web has evolved since then and users are now increasingly using the web from their mobile devices. These devices have constraints less common to traditional desktop computing environments: mobile devices have very limited power and network bandwidth, and often poor quality of service. Additionally, cellular data costs our users money, so we have a responsibility to use it judiciously.

With protocol version 4, we’ve optimized for this new environment with a clear focus on maximizing protection per bit, which benefits all Safe Browsing users, mobile and desktop alike. Version 4 clients can now define constraints such as geographic location, platform type, and data caps to use bandwidth and device resources as efficiently as possible. This allows us to function well within the much stricter mobile constraints without sacrificing protection.

We’ve been using the new protocol since December via the Safe Browsing client on Android, which is part of Google Play Services. The first app to use the client is Chrome, starting with version 46: we’re already protecting hundreds of millions of Android Chrome users by default.

We’ve Done Most Of The Work For You Already

A single device should only have a single, up-to-date instance of Safe Browsing data, so we’re taking care of that for all Android developers. Please don’t implement your own Version 4 client on Android: we’re working on making a simple, device-local API available to prevent any resource waste on device. We’ll announce the availability of this new device-local API as soon as possible; in the meantime, there’s no need to develop a Version 4 client on your own. For those who operate in less resource-constrained environments, using the Safe Browsing Version 4 API directly allows you to:

  • Check pages against the Safe Browsing lists based on platform and threat types.
  • Warn users before they click links that may lead to infected pages.
  • Prevent users from posting links to known infected pages

To make Safe Browsing integration as simple as possible, we’re also releasing a reference client implementation of the new API today, written in Go. It also provides a Safe Browsing HTTP proxy server, which supports JSON.


It’s easy to start protecting users with the new Version 4 of the Safe Browsing API. Sign up for a key and let us know what you think!


via Google Online Security Blog http://bit.ly/1ONRzyU

GS Mag, de la Théorie à la Pratique : la remédiation au cœur de la SSI

Comme chaque année, l'équipe de Global Security Mag organise un séminaire « de la Théorie à la Pratique » afin que nos lecteurs bénéficient d'une approche plus pragmatique de la SSI. Pour sa 5ème édition, qui s'est tenue au Musée du Vin le 12 mai dernier, BMC, PwC, Brainwave et Forcepoint sont venus présenter leurs propres visions de la cybersécurité, avec toujours comme fil rouge la réduction des risques, mais aussi des délais de détection des incidents et de remédiation.

L'automatisation au service de la remédiation

La transformation digitale que nous connaissons actuellement pose d'importants problèmes de sécurité, et toutes les entreprises sont aujourd'hui concernées par ce phénomène, explique Nicolas Pellé, Automation Product Account Manager, BMC. L'accélération des services digitaux amène aussi beaucoup plus de challenges en interne en matière de sécurité. Le Cloud, le shadow IT... complexifient, en effet, grandement le SI, rendant la cartographie des vulnérabilités encore plus compliquée. Il faut d'ailleurs compter 193 jours en moyenne aujourd'hui entre la détection d'une vulnérabilité et la remédiation. Pourtant, 80% des attaques actuelles se font via des vulnérabilités déjà connues… BMC vise à réduire ce laps de temps entre la détection et la remédiation. L'objectif est également d'unifier la sécurité et l'opérationnel, et de déterminer de quelle manière la sécurité se décline de manière opérationnelle, afin de basculer des actions de sécurité et de mise en conformité sans impacter pour autant la production.

La démarche SecOps proposée par BMC permet d'intégrer la sécurité et d'automatiser les opérations, de manière à réduire les risques et assurer la remédiation automatique de milliers d'événements de sécurité. Elle aide les équipes en charge des opérations et de la sécurité à adopter une approche proactive de la sécurité des systèmes dans le Cloud et sur site. L'objectif est de s'inscrire dans une démarche de conformité intelligente, qui s'articule autour de quatre principales étapes : la découverte, la définition d'un nouveau système de sécurité, l'audit de ce système et la remédiation, avec une gouvernance du tout. BMC collabore également avec différents partenaires spécialistes de la sécurité afin de pouvoir enrichir cette boucle vertueuse (RAPID 7, Nessus, Qualys).

La solution BMC BladeLogic offre une conformité et une visibilité sur la santé du SI. Elle permet, de plus, une analyse précise des menaces et une remédiation en continu. BMC BladeLogic peut également être customisée, en fonction de chaque cas particulier. Le groupe vient également d'annoncer il y a quelques semaines BladeLogic Threat Director. Cette solution va venir effectuer un mapping en temps réel de tout le parc informatique de l'entreprise et établir un état des lieux du dispositif de sécurité en place. La solution définit elle-même les niveaux de sévérité de chaque faille selon la sensibilité des informations auxquelles elle donne accès en cas d'attaque, et établit automatiquement le lien avec le correctif approprié.

A l'heure actuelle, l'innovation continue repose forcément, selon lui, sur des environnements complétement sécurisés et automatisés. Même si bien évidemment tout n'est pas automatisable, on est aujourd'hui capable d'automatiser à peu près 80% des opérations, estime-t-il, et d'identifier les vulnérabilités en quelques heures contrairement à avant où il fallait plusieurs jours, voire semaines, en moyenne.

Réduire les risques avec l'Identity Analytics

Dans le contexte de la transformation digitale, on ouvre les vannes de plus en plus rapidement et les menaces s'en trouvent de plus en plus prégnantes, constate Cyril Gollain, CEO et Fondateur de Brainwave. Même si les risques liés à l'identité n'ont pas foncièrement changé, ils se sont néanmoins démultipliés. Ainsi, on observe à la fois une explosion des cyber-risques et des risques de fraude interne, mais aussi des problèmes d'agilité, sans compter l'inflation des coûts IT… Alors que la promesse initiale du numérique réside dans une plus grande agilité et une réduction des coûts.

Afin de réduire ces risques liés à l'identité, Brainwave propose aux entreprises de s'inscrire dans une démarche d'Identity Analytics, à travers sa solution de nouvelle génération : Brainwave IdentityGRC. L'Identity Analytics vise à réunir l'ensemble des informations dispersées dans l'entreprise concernant chacun des utilisateurs, leurs permissions d'accès et leurs comportements, et de structurer toutes ces informations. La solution s'articule autour de trois principales familles de fonctionnalités : l'inventaire (qui a accès à quoi), l'automatisation des contrôles et la capacité de détection des signaux faibles et de tout ce qu'on n'a pas réussi à détecter.

Voici quelques exemples de cas de grands groupes pour lesquels Brainwave est intervenu avec Brainwave IdentityGRC, afin de minimiser les risques de fuites de données et de fraude et, ainsi, améliorer la conformité :
- Du côté des cyber-risques, le groupe a détecté et corrigé chez un client une erreur de droits permettant un accès libre à tous les contrats de travail des salariés sur le réseau, exposant directement l'entreprise à des risques de sécurité et de conformité ;
- Concernant la fraude interne, la solution a permis par exemple d'identifier, chez un autre compte, 20 000 euros de transactions frauduleuses dans l'activité des utilisateurs ;
- Dans le cadre d'opérations de fusion, des migrations de données s'opèrent et le nombre de référentiels se multiplie, causant régulièrement un manque d'agilité pour l'entreprise. Pourtant, quand on arrive à corréler les informations au sein d'un système unique, on peut faciliter la remédiation ;
- Enfin, le suivi de l'affectation des ressources par utilisateur permettrait de réduire les coûts IT, d'autant que de nombreux comptes ne sont pas rattachables à une utilité particulière aujourd'hui. A titre d'exemple, Brainwave a permis à une entreprise de réduire de 300 000 euros par an ses coûts de licence Salesforce, grâce à l'optimisation de l'affectation des accès.

Brainwave IdentityGRC, via une application Web, permet entre autres aux entreprises de :
- Déterminer s'il existe des comptes encore actifs appartenant à des utilisateurs ayant quitté la structure ;
- Faire correspondre les droits d'accès des collaborateurs à leurs fonctions actuelles et de déterminer qui dispose de droits non nécessaires ;
- Croiser les droits conflictuels avec les logs d'usage ;
- Fournir aux managers des informations qui soient compréhensibles, de manière à ce qu'ils puissent prendre facilement des décisions.

A travers une analyse de processus de bout en bout, Brainwave définit les risques potentiels par rapport aux droits, et identifie les risques avérés. L'analyse du comportement des utilisateurs permet, quant à elle, d'envoyer des alertes et de fournir des solutions de remédiation. Cette démarche s'inscrit, en outre, dans un pilotage optimal de la gouvernance et de la conformité.

Votre SOC est-il efficient ?

Face à l'augmentation de la surface d'exposition aux cyber-risques et à la professionnalisation des menaces, les investissements réalisés dans les outils de sécurité sont de plus en plus importants, aussi bien en prévention, qu'en détection et réponse à incident. En effet, aucun système n'est aujourd'hui invulnérable et inviolable, souligne Fabrice Garnier de Labareyre, PwC, l'important est donc désormais de détecter au plus tôt l'attaque et d'en assurer la remédiation. Ainsi, la cybersurveillance est plus que jamais d'actualité et place le Security Operation Center (SOC) au centre des enjeux de la cybersécurité. Cependant, le fait qu'une entreprise dispose d'un SOC ne garantit pas sa sécurisation pour autant, c'est pourquoi il est nécessaire de tester ses capacités de détection et de réponse sur trois axes : humain, process et outil. PwC propose, en ce sens, une logique complète de détection et de remédiation, ainsi qu'une méthode spécifique permettant d'évaluer l'efficacité d'un SOC. Le groupe réalise, de plus, chaque année un baromètre dédié à la cybersécurité, The Global State of Information Security® Survey, lui permettant d'avoir un bon aperçu des tendances en la matière, des projets des entreprises, ainsi que leur façon de gérer et d'améliorer la cybersécurité au sein des organisations.

Pour mener à bien cette étude, PwC a envoyé un questionnaire à tous ses clients dans 127 pays et obtenu près de dix mille réponses à travers le monde. Parmi les principaux résultats du baromètre 2016, PwC a pu constater une augmentation en 2015 des menaces et des tentatives d'attaques. Le nombre de cyberattaques a, quant à lui, progressé de 38% dans le monde l'an passé. Chaque année, les entreprises déclarent aussi de plus en plus d'incidents. Concernant l'origine de ces incidents, même si ce sont les sources externes qui ont le plus progressé, l'interne reste encore le facteur le plus important. Attention, cela ne signifie pas forcément « délinquance interne »… seulement que le facteur humain reste le principal maillon faible. De plus, les incidents attribués aux partenaires ont augmenté de 30% environ. Les systèmes industriels sont également de plus en plus la cible d'attaques. On remarque ainsi une augmentation de 36% en France du nombre d'attaques visant ces systèmes et de 158% dans le monde.

Le groupe a également pu observer un changement de comportement des directions générales par rapport à la cybersécurité. Le comité exécutif s'implique davantage dans ce type de problématiques. On observe d'ailleurs une augmentation du budget alloué à la cybersécurité, de 29% en France et de 24% dans le monde. Les dirigeants et entreprises assurant la gestion de la cybersécurité ont d'ailleurs une santé économique bien meilleure, contrairement à celles qui ne s'en préoccupent pas, et qui ont beaucoup plus de mal à s'en remettre en cas de problème. Cela a amené les entreprises à prendre en compte ces aspects dans le calcul de la notation et le budget. La cybersécurité est aujourd'hui devenue un critère de robustesse de l'entreprise, explique-t-il. D'autant que les pertes financières liées à des incidents de cybersécurité sont estimées à 3,7 millions d'euros par entreprise en France.

91% des répondants ont mis en œuvre un pilotage de la cybersécurité par les risques. Il n'existe toutefois pas de modèle standard applicable à tous pour une cybersécurité efficace. Il s'agit d'un processus d'amélioration continue s'articulant autour du bon mix entre technologies, processus et compétences.

Parmi les autres mesures mises en place au sein des entreprises, la moitié des répondants disposent en moyenne d'une vraie stratégie de sécurité du SI, ainsi que d'un RSSI, conduisent des opérations de threat intelligence et sensibilisent le personnel quel qu'il soit.

Afin de renforcer ces dispositifs en place et d'améliorer les temps de détection et de remédiation, PwC propose une offre complète de cybersécurité, visant à construire la confiance dans ce monde numérique qui nous entoure. Celle-ci repose sur 4 principaux piliers : évaluer, renforcer, gérer et réagir. Le groupe propose également dans ce cadre une méthodologie d'évaluation des SOC, basée sur l'évaluation d'un certain nombre d'entre eux. Celle-ci s'articule en grande partie autour de la simulation d'attaques externes et internes, par rapport à un certain nombre de scénarios prédéterminés. Assurer la bonne gestion d'un SOC est une mission très délicate, qui nécessite de nombreuses compétences et connaissances de son environnement, des menaces et de ses actifs sensibles.

En effet, il ne suffit pas seulement de disposer d'un SOC pour en garantir l'efficience, car d'un point de vue opérationnel l'efficacité du SOC reste toujours à prouver, et donc à évaluer. La question est aussi de déterminer si les technologies choisies sont adéquates ou non. On va donc venir évaluer le niveau de protection et de pertinence de la détection.

L'évaluation d'un SOC commence tout d'abord par une supervision de son activité. Celle-ci doit se faire en lien étroit avec les différentes directions concernées. Puis, vient la phase de réalisation et d'exécution des scénarios d'attaques, qui dure de 4 à 5 semaines en moyenne. Au cours de cette étape, différents malwares seront déployés sur quelques postes de travail de l'entreprise et certaines attaques exécutées sur le SI, l'objectif étant néanmoins de laisser la production de l'entreprise continuer. Il peut s'agir, par exemple, de la simulation d'une attaque APT. Durant cette période, les détections opérées par le SOC seront également analysées. L'appréciation repose également sur une méthodologie de notation des SOC.

Parmi les principales raisons de l'inefficacité d'un SOC, il souligne la méconnaissance de l'environnement supervisé, la couverture imparfaite du SI, le manque d'implication ou encore de compétences. Enfin, « notre expérience montre que la plupart des SOC sont encore à un niveau de maturité insuffisant pour pouvoir faire face aux menaces actuelles », conclut-il.

Ransomwares : de la détection à la remédiation

Les attaques sont aujourd'hui de plus en plus avancées, et même agrégées, constate David Brillant, Senior Manager de Sales Engineering chez Forcepoint. En effet, les criminels disposent actuellement d'outils beaucoup plus avancés qui permettent quasiment d'automatiser les attaques.

Locky, un ransomware apparu l'année dernière, en est un bon exemple. Ce malware va venir chiffrer toutes les données de l'entreprise en échange d'une rançon. Ce type d'attaque passe par différentes étapes, dont la reconnaissance, qui démontre la capacité des criminels à identifier le terrain, ou celle de l'appât, visant à s'assurer que l'utilisateur clique bel et bien sur le lien ou le fichier malveillant… Le but des attaquants est de récupérer le maximum d'informations possible, car la donnée a beaucoup de valeur aujourd'hui.

N'importe qui peut devenir victime de ce type d'attaque, cependant au sein des entreprises, les personnes travaillant au service « achat » seront des cibles de choix… d'autant qu'il est facile de faire croire à l'envoi d'une « facture »... Cette étape est d'ailleurs souvent facilitée par les différents formats de fichiers envoyés. En effet, souvent l'antivirus va venir analyser les fichiers word, pas les fichiers text… De plus, le chiffrement opéré par Locky n'est pas statique, mais dynamique. On observe ainsi en moyenne 6 changements de noms de domaines par jour. Forcepoint a pu comprendre le « dynamic changement » et donc bloquer l'attaque auprès de ses utilisateurs. Toutefois, s'il n'y a pas de méthode et de solution de détection, la contamination se fera. Sur le mois de février dernier, la rançon demandée était de 256 dollars en moyenne.

D'autres ransomwares ont fait leur apparition depuis, comme Dridex par exemple, qui repose sur un mode opératoire similaire, même si la somme demandée et la finalité s'avèrent différentes. Jaku est un autre exemple de malware qui sévit ces derniers temps. Même s'il vise principalement l'Asie et plus particulièrement la Malaisie, la Thaïlande et Singapour, il a déjà fait des victimes dans près de 134 pays à l'heure actuelle.

Néanmoins, on retrouve un certain nombre de caractéristiques communes relatives aux ransomwares d'aujourd'hui. En effet, ils sont devenus extrêmement dynamiques, mais aussi de plus en plus contextuels. Les campagnes sont, en outre, extrêmement courtes, il faut donc être capable d'anticiper ce type d'attaque en amont. La grande majorité des attaques se font désormais par le biais de l'envoi d'emails malveillants, il faut donc redoubler de vigilance et mettre un certain nombre de mesures en place.

Pour David Brillant, les responsables sécurité ont aujourd'hui beaucoup trop de solutions de sécurité à gérer, rendant par là même la remédiation et la corrélation de la détection des attaques et des incidents beaucoup plus complexes. C'est pourquoi Forcepoint propose aux entreprises une gamme complète de solutions de sécurité, basées sur des briques unifiées. L'entreprise vient d'ailleurs de renforcer son offre sur la partie firewall, avec le rachat de Stonesoft. L'objectif est de permettre aux entreprises d'assembler l'ensemble des événements de sécurité au sein d'un système unique, facilitant ainsi la remédiation.

Enfin, il recommande notamment aux entreprises d'évaluer dans un premier temps leur posture en matière de sécurité, d'identifier leurs données les plus critiques, ainsi que les vulnérabilités, de s'assurer de la santé de leur réseau et de reporter toutes les activités suspectes, d'accroître le monitoring et d'améliorer la communication. Les attaques sont en grande majorité plus évoluées qu'avant, et peuvent autant être d'origine interne qu'externe, une nouvelle approche de sécurité est donc aujourd'hui nécessaire, conclut-il.



via Global Security Mag Online http://bit.ly/1OXNZI0

Renaud Deraison, CPO de Tenable : Nous souhaitons aider les entreprises dans leur transition numérique

Renaud Deraison, CPO de Tenable : Nous souhaitons aider les entreprises dans leur transition numérique

Tenable, depuis sa création, s’est donné pour objectif de donner une vision globale sur le SI en intégrant un scan de vulnérabilités et des journaux d’événements. Après avoir conquis près de 20.000 entreprises dans le monde, Tenable s’attaque au marché français. Renaud Deraison CPO de Tenable estime que sa mission est d’accompagner les entreprises dans la transition numérique.

GS Mag : Pouvez-vous nous présenter votre entreprise ?

Renaud Deraison : En 1998 j’ai créé le logiciel Nessus qui était en open source gratuit. J’ai eu un énorme retour de la communauté informatique en 2000 ce qui m’a conduit a créé une société en France : Nessus Consulting qui faisait du consulting et proposait des services autour de Nessus. A l’époque la société avait du mal à se positionner sur le marché français. Par la suite j’ai rencontré mes deux associés américains qui m’ont convaincu de créer une société aux États-Unis. C’est ainsi qu’est née Tenable dont les produits donnent une vision globale de la sécurité du SI. Nous apportons aujourd’hui un scan de vulnérabilités, des journaux des événements des machines et nous intégrons les deux pour donner une vision globale du SI.

GS Mag : Pourquoi revenir en France ?

Renaud Deraison : Nous avons pris beaucoup de temps pour revenir en France. En fait, nous nous sommes développés de façon autofinancée durant très longtemps. Nous avons procédé par étape en commençant par développer nos activités tout d’abord aux États Unis, puis dans les pays anglo-saxons Canada, Grande Bretagne, Singapour.... Aujourd’hui, nous attaquons le marché français.

Nous allons donc procéder à une véritable intégration sur le marché français. Avec une équipe française avec des commerciaux, des avant-ventes et une équipe de support francophone.

GS Mag : Quelle va être votre stratégie marketing sur le marché français ?

Renaud Deraison : Nous essayons de développer une base cliente conséquente. Nous serons présents aux Assises de la sécurité, au FIC en 2017 comme nous l’avons été cette année.

GS Mag : Quel est votre message à nos lecteurs ?

Renaud Deraison : Nous souhaitons élevé le débat en effet, le marché de la sécurité est très fragmenté. On a durant des années empilé des couches de sécurité. Aujourd’hui, il faut plutôt comprendre ce qui se passe sur le SI et surtout mesurer l’efficacité des solutions déployées. Nous essayons de nous centre sur les causes des vulnérabilités et nous offrons du contexte autour de la sécurité.

Nous avons pour ambition d’accompagner les entreprises à passer le cap de la transition numérique. Avec une approche dans un monde où il n’y aurait plus à terme d’administrateurs systèmes mais des ingénieurs qui vont gérer des milliers de machines. Cette période pourrait durer durant plusieurs années.



via Global Security Mag Online http://bit.ly/1WPiHWb

23 juin - Paris Conférence CLUSIF : Rapport « Menaces informatiques et pratiques de sécurité en France » Edition 2016


23 juin - Paris Conférence CLUSIF : Rapport « Menaces informatiques et pratiques de sécurité en France » Edition 2016

A travers cette nouvelle étude, le CLUSIF présentera les tendances et faits marquants des politiques de sécurité, des incidents de sécurité et des pratiques mises en place par les :
• Entreprises de plus de 200 salariés,
• Collectivités Territoriales,
• Internautes.

Cette nouvelle étude du CLUSIF s’appuie sur un sondage, réalisé par un cabinet spécialisé (GMV Conseil).

Les résultats et commentaires de l’enquête doivent permettre aux organismes des secteurs privés et publics ou à un particulier de se positionner sur des thématiques ou un secteur d’activité.

Pour les 2 premières catégories (entreprises privées et collectivités territoriales) :
• Les questionnaires suivent les thèmes de la norme ISO 27002:2013. Cette approche permet de mesurer le niveau de prise en compte de la norme au sein des entreprises et des collectivités territoriales et d’identifier les thèmes sur lesquels des progrès restent à réaliser pour son adoption,
• La personne qui a répondu au questionnaire du CLUSIF est le Responsable de la Sécurité des Systèmes d’Information (RSSI) ou son équivalent.

Concernant la troisième catégorie (les internautes), le questionnaire permet d’identifier le niveau ressenti de risque et les mécanismes de protection mis en œuvre par Monsieur et Madame « tout le monde ».

L’exploitation des résultats a été effectuée par un comité d’experts composés de membres du CLUSIF et également de personnalités reconnues du domaine de la SSI. Au travers d’analyses, de comparaisons avec les études MIPS antérieures et de commentaires, ces experts mettent en lumière le point de vue du CLUSIF sur les évolutions de la sécurité de l’information.

Cette conférence, organisée par le CLUSIF, se tiendra le jeudi 23 juin 2016 à Paris

Programme d la conférence

Les résultats de l’étude vous seront présentés par plusieurs membres du Comité d’Experts qui rédige l’étude, sous la responsabilité de :
• Lionel Mourer (ATEXIO), pour la partie Entreprises ;
• Thierry Henniart (Région Hauts-de-France), pour la partie Collectivités Territoriales :
• Colonel Eric Freyssinet (Ministère de l’Intérieur/Cybermenaces), pour la partie Internautes.

Des focus sur les éléments marquants de l’enquête 2016 vous seront présentés par des contributeurs du groupe de travail. Les détails sur les présentations vous seront communiqués courant juin.

Le rapport sera disponible pour tous (en téléchargement) après la conférence. Au terme de la conférence, un cocktail sera proposé et vous permettra d’échanger directement avec les conférenciers et vos confrères présents.

CCI Paris
2 place de la Bourse
75002 Paris

Métro Bourse ou Grands Boulevards (à 12 minutes à pied du CLUSIF)

Inscription

Inscription obligatoire en ligne : http://bit.ly/1TXjvCa... Conditions d’inscription :

Conférence gratuite pour les adhérents du CLUSIF

Les adhérents du CLUSIF peuvent se faire remplacer par un collègue ou un collaborateur en cas d’empêchement

Conférence payante pour les extérieurs (85€ HT) et les étudiants (35€ HT)



via Global Security Mag Online http://bit.ly/1NNJoHY

mardi 10 mai 2016

WordPress 4.5.2 : Mise à jour de sécurité critique

Publié par UnderNews Actu

L’équipe de WordPress vient de mettre à disposition la version 4.5.2, qui est une mise à jour de sécurité. Webmasters, il est urgent de la déployer au plus vite si vous n’avez pas activé les mises à jours automatiques de votre WordPress. Sinon, elle a déjà été appliquée.

WordPress 4.5.2 corrige deux failles de sécurité critique. En effet, la librairie Pupload utilisée pour l’upload des images comportait une faille de type SOME (Same-Origin Method Execution), tandis que la librairie MediaElement.js utilisée pour gérer l’affichage et la lecture des vidéos contenait une faille XSS. Aussi, l’équipe de développement a publié un article concernant plusieurs failles de sécurité découvertes dans la librairie ImageMagik, inclue dans WordPress pour le traitement des images lorsque l’hébergeur ne supporte pas la librairie GD standard.

Si vous avez les mises à jour automatiques des nouvelles versions de WordPress actives, le déploiement de la version 4.5.2 est déjà en cours voir terminé. Sinon, vous devez procéder à la mise à jour manuellement depuis l’administration des sites concernés.

 

Source : GeekPress, WordPress

Vous avez aimé cet article ? Alors partagez-le en cliquant sur les boutons ci-dessous :

1 étoile2 étoiles3 étoiles4 étoiles5 étoiles

(

2

votes, note :

3,50

sur 5)

Loading...

Mots clés : , , , , ,



via UnderNews http://bit.ly/1Np5oZG

MISP – Malware Information Sharing Platform

Serious ImageMagick Zero-Day Vulnerabilities – ImageTragick?

Journée thématique de l’OzSSI Sud-Est avec le CLUSIR RA le 8 juin 2016 à Lyon

’observatoire zonal de la sécurité des systèmes d’information (OzSSI) Sud-Est et le Clubs de la sécurité de l’information régionaux (CLUSIR) Rhône-Alpes vous donnent rendez-vous pour une dernière journée thématique le 8 juin à Lyon. Il s’agit en effet de l’édition finale du rendez-vous SSI en Rhône-Alpes sous ce format, qui sera amené à évoluer à l’avenir.

Cet évènement représente aussi l’occasion de saluer l’action menée sur le territoire depuis 2009 par l’OzSSI de la zone de défense Sud-Est et de marquer la passation avec le nouveau référent de l’ANSSI pour la région Auvergne Rhône-Alpes dans le cadre du déploiement de l’action territoriale de l’agence.

Animée par des experts du domaine de la cybersécurité, cette journée permettra d’aborder une large palette de thèmes :

  • Panorama cybercriminalité 2015 par le CLUSIR Rhône-Alpes
  • Etre Hacktiviste aujourd’hui : entre justicier du Net et (im)posture numérique par un conférencier intelligence économique et SSI du ministère de l’Intérieur
  • Le Darkweb par un enquêteur N’Tech de la gendarmerie nationale
  • Une approche simple pour la protection des systèmes critiques par le « Product and Solution Security Officer » de chez SIEMENS
  • le cloud par un expert de l’ANSSI
  • La sensibilisation aux risques et à la gestion des incidents SSI : retour d’expérience et exemples par un expert de LEXSI
  • Security Operating Center : quelle démarche projet pour réussir son SOC ? par un expert d’ADVENS
  • PSSI, Charte informatique : pour qui, pour quoi ? par le Cabinet DELOITTE

La participation se fait uniquement par inscription (et sous réserve de places disponibles) à l’OzSSI Sud-Est ozssi-zdse[at]interieur.gouv.fravant le 3 juin 2016 en précisant obligatoirement les noms, fonctions et coordonnées des personnes présentes.



via Agence nationale de la sécurité des systèmes d'information http://bit.ly/1rE10Mt

WAFW00F – Fingerprint & Identify Web Application Firewall (WAF) Products

Génération rapide de DGA avec Miasm

Rendus populaires par le ver Conficker, les algorithmes de génération de noms de domaine (Domain Generation Algorithm) permettent d’éviter aux cybercriminels la complexité de la mise en place d’un réseau P2P pour un canal de contrôle, sans tomber dans la trivialité des IP ou domaines codés en dur dans le binaire. La graine de ces algorithmes est généralement basée sur la date, mais on se souvient du bon vieux Torpig qui utilisait également les tendances Twitter du jour (astuce simple néanmoins très efficace pour empêcher la génération des domaines avant le jour J). Dans ce billet, nous allons montrer quelques méthodes pour automatiser la génération de noms de domaine DGA, en prenant l’exemple simple du ransomware Locky.

Méthode 1 : transcription manuelle

Voici une trace réseau d’une exécution de Locky le 01/04/2016 :

locky_pcap

Le malware contacte :

  • 4 IP codées en dur dans le binaire dépacké
  • puis, si aucune connexion n’a pu être effectuée, 8 noms de domaines faisant penser à un DGA

En analysant le code réseau, on se rend compte que l’algorithme DGA de Locky est initialisé par une graine stockée sur 4 octets et faisant partie d’une petite configuration au sein du binaire dépacké :

locky_conf

Une rapide analyse permet de comprendre le rôle de chaque élément de la configuration :

  • AffiliateId : identifiant de botnet, utilisé comme paramètre affid dans la requête GET de récupération de la clé publique
  • DGASeed : graine servant à initialiser le DGA, 0x4d dans notre échantillon
  • Sleep : nombre de secondes d’attente avant la création de la clé HKCU\Software\Locky (défaut : 0x1e = 30s)
  • Svchost : recopie ou non sous le nom svchost.exe (défaut : non)
  • Reg : persistance ou non via la clé Run de HKCU (défaut : non)
  • ExcludeRussian : exclusion ou non des systèmes en langue Russe (défaut : oui)
  • ServerIPs : liste des 4 IP à contacter

Le DGA est simple et peut se décomposer en 3 étapes :

1) initialisation par la graine ci-dessus ainsi que l’année, le mois et le jour courant, via quelques opérations arithmétiques simples. Un index incrémental est également passé à la fonction via le registre ECX

locky_dga1

2) boucle de génération des caractères un par un

locky_dga2

3) génération de l’extension par calcul d’un index dans une chaîne fixe de TLD

locky_dga3

On voit que l’algorithme est très simple et peut s’implémenter à la main en quelques lignes de Python (v32() est simplement la troncature à 32 bits) :

def dga(seed, index, year, month, day):
  c1 = 0xb11924e1
  c2 = 0x27100001
  c3 = 0x2709A354
  eax = v32(v32((year + 0x1bf5)) * c1)
  eax = v32(v32((ror(eax, 7) + seed + c2)) * c1)
  eax = v32(ror(eax, 7) + (day>>1) + c2)
  eax = v32(ror(eax*c1, 7) + month + c3)
  eax = v32(ror(eax*c1, 7) + rol(index, 0x15))
  eax = v32(eax + rol(seed, 0x11) + c2)
  eax = v32(ror(eax*c1, 7) + c2)
  out = ""
  for i in range(5 + eax%0xb):
    eax = v32(rol(eax, i) * c1)
    eax = v32(ror(eax, 7) + c2)
    out += chr(ord('a') + eax%0x19)
  eax = v32(ror(eax*c1, 7) + c2)
  eax = v32(2*(eax%0xe))
  out += "." + "rupweuinytpmusfrdeitbeuknltf"[eax:eax+2]
  return out

Exécutons cette fonction pour la journée du 01/04/2016 :

>>> for i in range(8):
...   print dga(0x4d, i, 2016, 04, 01)
...
puyyjnyqg.de
rvayxaf.be
mfedlavimoyjwhx.it
oyleagxyifobk.pw
xehxcvwmwwm.de
sgdgacta.nl
uhlbso.eu
pqpmoscxhbrabk.yt

Les 8 domaines générés pour ce jour sont bien conformes à la capture Wireshark. Mais qu’en est-il des autres jours ? On pourrait évidemment modifier la date de Windows et lancer Wireshark pour chaque jour et faire la comparaison avec notre script… Légèrement fastidieux. On préfère générer les domaines pour l’ensemble des mois d’avril et mai : l’idée est de les comparer avec une génération automatisée afin de valider notre implémentation.

$ cat dga.py
[...]
seed = 0x4d
begin = datetime.datetime(2016, 4, 1)
end   = datetime.datetime(2016, 5, 31)
domains_per_day = 8
date = begin
while date <= end:
  # Seed/date header
  print "0x%x %s" % (seed, date.strftime("%Y-%m-%d"))
 
  for i in range(domains_per_day):
    # Domain
    print dga(seed, i, date.year, date.month, date.day)
  date += datetime.timedelta(days=1)
  print ""
$ ./dga.py > dga_0x4d_method1_manual.txt
$ md5sum dga_0x4d_method1_manual.txt
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method1_manual.txt

Méthode 2 : méthode traditionnelle avec GDB/Python

Le DGA de Locky est très simple et a pu être implémenté rapidement mais s’il avait été plus complexe, il n’aurait pas été envisageable de le faire entièrement manuellement. Une méthode permettant de contourner ce problème consiste à instrumenter une machine virtuelle avec GDB et Python, comme déjà présenté dans un précédent billet sur Zeus P2P et Dyreza. On va dans ce cas utiliser deux breakpoints :

1. En début de fonction, par exemple juste après l’appel à GetSystemTime(), afin d’initialiser les registres et la pile dans l’état voulu :

  • ESI contient la graine
  • EDI contient l’index
  • une variable pointe vers une structure SYSTEMTIME dont les offsets 0, 2 et 6 contiennent respectivement l’année, le mois et le jour

2. On laisse le malware s’exécuter jusqu’à un second breakpoint où le domaine correspondant à ces paramètres est généré. On incrémente alors l’index et, en écrasant quelques instructions par un saut, on revient au premier breakpoint pour générer un autre domaine. Si l’index atteint 8, on le remet à zéro et on passe au jour suivant.

Le script GDB/Python suivant implémente cette méthode en générant automatiquement tous les domaines d’avril et mai 2016 :

#! /usr/bin/env python
# Locky DGA generator based on GDB
# Sylvain SARMEJEANNE, CERT-LEXSI 04/2016
import gdb
import datetime
SEED = 0x4d
DATE_BEGIN = datetime.datetime(2016, 4, 1)
DATE_END = datetime.datetime(2016, 5, 31)
DOMAINS_PER_DAY = 8
OUTPUT_FILE = "/home/sylvain/malwares/locky/dga_0x%x_method2_gdb.txt" % SEED
BP_BEGIN = 0x406d67
BP_END = 0x406e95
SYSTEMTIME = 0x0012f7d8
pchar = gdb.lookup_type("char").pointer()
class LockyDGA(gdb.Breakpoint):
  def __init__(self, specs):
    for spec in specs:
      super(LockyDGA, self).__init__(spec, gdb.BP_BREAKPOINT)
    self.seed = SEED
    self.idx = 0
    self.datetime = DATE_BEGIN
 
    gdb.execute("set logging file %s" % OUTPUT_FILE)
    gdb.execute("set logging overwrite on")
    gdb.execute("set logging on")
    gdb.execute("set height 0")
  def stop(self):
    eip = long(gdb.parse_and_eval("$eip").cast(gdb.lookup_type("int").pointer())) & 0xffffffff
 
    if eip == BP_BEGIN:
      # Setting up the registers
      gdb.execute("set $esi=%i" % self.seed)
      gdb.execute("set $edi=%i" % self.idx)
 
      # Setting up the stack
      gdb.execute("set *(short*)0x%x=%i" % (SYSTEMTIME, self.datetime.year))
      gdb.execute("set *(short*)(0x%x+2)=%i" % (SYSTEMTIME, self.datetime.month))
      gdb.execute("set *(short*)(0x%x+6)=%i" % (SYSTEMTIME, self.datetime.day))
      if self.idx == 0:
        # Ouput the seed/date header
        gdb.write("0x%x %s\n" % (self.seed, self.datetime.strftime("%Y-%m-%d")), gdb.STDLOG)
      return False
    elif eip == BP_END:
      # Output the domain pointed to by edx
      gdb.write("%s\n" % gdb.Value(gdb.parse_and_eval("$edx")).cast(pchar).string(), gdb.STDLOG)
 
      self.idx += 1
 
      if self.idx == DOMAINS_PER_DAY:
        self.idx = 0
        self.datetime += datetime.timedelta(days=1)
 
        if self.datetime > DATE_END:
          gdb.execute("set logging off")
          return True
 
        gdb.write("\n", gdb.STDLOG)
      # Jump back to BP_BEGIN
      gdb.execute("set *0x406e95=0xfffecde9")
      gdb.execute("set *(0x406e95+4)=0xff")
      return False
LockyDGA(["*0x%x" % BP_BEGIN, "*0x%x" % BP_END])

Le résultat est stocké dans dga_0x4d_method2_gdb.txt. Comme il s’agit de l’exécution du malware lui-même dans une machine virtuelle complète, on considère les domaines ainsi générés comme la référence. Comparons avec les domaines issus de notre implémentation manuelle (méthode 1) :

$ md5sum dga_0x4d_method1_manual.txt dga_0x4d_method2_gdb.txt
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method1_manual.txt
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method2_gdb.txt

Notre implémentation manuelle semble correcte.

Méthode 3 : sandbox légère

La méthode précédente fonctionne parfaitement mais pour un malware aussi simple que Locky, on aimerait quelquechose de plus léger à utiliser. Après tout, pourquoi devrions-nous instrumenter un système d’exploitation complet alors que nous voulons simplement exécuter quelques instructions assembleur basiques ? Miasm fournit une sandbox qui répond tout à fait à ce problème.

On commence par initialiser la sandbox Miasm :

parser = Sandbox_Win_x86_32.parser(description="PE sandbox")
parser.add_argument("filename", help="Locky binary")
options = parser.parse_args()
sb = Sandbox_Win_x86_32(options.filename, options, globals())

On ajoute un breakpoint à l’adresse où le nom de domaine est généré en mémoire :

def end(jitter):
  sb.jitter.run = False
  return True
sb.jitter.add_breakpoint(0x406e95, end)

Le premier bloc appelle memset() pour réinitialiser la zone où le domaine est généré, on va simplement émuler ce memset() en Python avec un deuxième breakpoint :

def memsetzero(jitter):
  sb.jitter.vm.set_mem(domain, "\x00"*32)
  sb.jitter.pc = BP_CALL+5
  return True
sb.jitter.add_breakpoint(0x406de6, memsetzero)

Miasm a créé une zone mémoire pour la pile à partir de l’adresse 0x130000 :

>>> sb.jitter.vm
Addr     Size    Access Comment
0x130000 0x10000 RW_    Stack

On positionne par exemple EBP à 0x13f000 :

sb.jitter.cpu.EBP = 0x13f000

Le domaine sera généré à une adresse arbitraire en mémoire et on y fait pointer var_40 comme le veut le code du DGA :

domain = 0x900000
sb.jitter.vm.add_memory_page(domain, PAGE_READ | PAGE_WRITE, "\x00"*32)
sb.jitter.vm.set_mem(EBP-0x40, pack("<I", domain))

Enfin, on initialise la graine, l’index et la date (c’est IDA qui indique que la variable stockant l’adresse vers la structure SYSTEMTIME est décalée de 0x24) :

sb.jitter.cpu.ESI = SEED
sb.jitter.cpu.EDI = idx
sb.jitter.vm.set_mem(EBP-0x24, pack("<H", 2016))
sb.jitter.vm.set_mem(EBP-0x24+2, pack("<H", 04))
sb.jitter.vm.set_mem(EBP-0x24+6, pack("<H", 01))

L’exécution sera lancée depuis l’adresse située juste après l’appel à GetSystemTime() :

sb.run(0x406d67)

IDA indique que la chaîne de caractères des TLD est présente en 0x413D5C ; elle a déjà été mappée par le parser PE de Miasm car elle est située dans la section .rdata du binaire dépacké :

>>> sb.jitter.vm
Addr     Size   Access Comment
0x411000 0x7000 R__    'locky_unpack.exe': '.rdata\x00\x00'
>>> sb.jitter.vm.get_mem(0x413D5C, 28)
'rupweuinytpmusfrdeitbeuknltf'

Si ce mapping n’avait pas été réalisé automatiquement, il aurait été possible de l’ajouter manuellement :

sb.jitter.set_str_ansi(0x413d5c, "rupweuinytpmusfrdeitbeuknltf")

L’émulation génère correctement le premier nom de domaine du 01/04/2016 :

$ python -i ./dga_miasm_sb.py locky_unpack.exe
>>> sb.jitter.vm.get_mem(0x900000, 12)
'puyyjnyqg.de'

Sur un schéma quasi-identique au script GDB de la méthode 2, le script suivant génère les noms de domaine pour les mois d’avril et mai 2016 via une sandbox Miasm :

#! /usr/bin/env python
# Locky DGA generator based on a thin Miasm sandbox
# Sylvain SARMEJEANNE, CERT-LEXSI 04/2016
from miasm2.analysis.sandbox import Sandbox_Win_x86_32
from miasm2.jitter.csts import PAGE_READ, PAGE_WRITE
from struct import pack
import datetime
SEED = 0x4d
DATE_BEGIN = datetime.datetime(2016, 4, 1)
DATE_END = datetime.datetime(2016, 5, 31)
DOMAINS_PER_DAY = 8
idx = 0
date = DATE_BEGIN
BP_BEGIN = 0x406d67
BP_CALL = 0x406de6
BP_END = 0x406e95
EBP = 0x13f000
SYSTEMTIME = EBP-0x24
domain = 0x900000
var_40 = EBP-0x40
var_2C = EBP-0x2C
def begin(jitter):
  # Setting up the registers
  sb.jitter.cpu.ESI = SEED
  sb.jitter.cpu.EDI = idx
  # Setting up the stack
  sb.jitter.vm.set_mem(SYSTEMTIME, pack("<H", date.year))
  sb.jitter.vm.set_mem(SYSTEMTIME+2, pack("<H", date.month))
  sb.jitter.vm.set_mem(SYSTEMTIME+6, pack("<H", date.day))
  if idx == 0:
    # Output the seed/date header
    print "0x%x %s" % (SEED, date.strftime("%Y-%m-%d"))
  return True
def memsetzero(jitter):
  sb.jitter.vm.set_mem(domain, "\x00"*32)
  sb.jitter.pc = BP_CALL+5
  return True
def end(jitter):
  global idx, date
  # Output the domain pointed to by edx
  print sb.jitter.get_str_ansi(sb.jitter.cpu.EDX)
 
  idx += 1
  if idx == DOMAINS_PER_DAY:
    idx = 0
    date += datetime.timedelta(days=1)
 
    if date > DATE_END:
      sb.jitter.run = False
      return True
    print ""
  # Jump back to BP_BEGIN
  sb.jitter.pc = BP_BEGIN
 
  return True
parser = Sandbox_Win_x86_32.parser(description="PE sandbox")
parser.add_argument("filename", help="Locky binary")
options = parser.parse_args()
sb = Sandbox_Win_x86_32(options.filename, options, globals())
sb.jitter.cpu.EBP = EBP
sb.jitter.vm.add_memory_page(domain, PAGE_READ | PAGE_WRITE, "\x00"*32)
sb.jitter.vm.set_mem(var_40, pack("<I", domain))
sb.jitter.vm.set_mem(var_2C, "\x11\x00\x00\x00")
sb.jitter.add_breakpoint(BP_BEGIN, begin)
sb.jitter.add_breakpoint(BP_CALL, memsetzero)
sb.jitter.add_breakpoint(BP_END, end)
sb.run(BP_BEGIN)

Les domaines ainsi générés sont conformes à notre référence :

$ ./dga_miasm_sb.py > dga_0x4d_method3_miasm_sb.txt 
$ md5sum dga_0x4d_method2_gdb.txt dga_0x4d_method3_miasm_sb.txt 
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method2_gdb.txt
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method3_miasm_sb.txt

Méthode 4 : exécution symbolique

4.1 Initialisation du DGA

Dans les méthodes automatisées 2 et 3, nous avons simplement exécuté le code de Locky sans en comprendre le fonctionnement. Lorsque l’objectif est de réimplémenter l’algorithme en C ou Python par exemple, ces méthodes ne sont pas applicables. Si la complexité du DGA est telle que la méthode manuelle (méthode 1) n’est pas réalisable en un temps raisonnable, il nous faut un outil pour générer automatiquement une version haut niveau de l’algorithme à partir des instructions assembleur. Miasm possède pour cela un moteur d’exécution symbolique.

On commence par désassembler le bloc initialisant le DGA de Locky, entre les adresses 0x406d67 et 0x406dfa (cf méthode 1 pour les trois étapes de l’algorithme) :

c = Container.from_stream(open("/home/sylvain/malwares/locky/locky_unpack.exe"))
machine = Machine('x86_32')
mdis = machine.dis_engine(c.bin_stream)
mn = machine.mn
bloc_begin = 0x406d67
mdis.dont_dis = [0x406dfa]
blocs = mdis.dis_multibloc(bloc_begin)
ira = machine.ira()
for bloc in blocs:
  ira.add_bloc(bloc)

On lance l’exécution sur ce premier bloc :

sb = symbexec(ira, mn.regs.regs_init)
sb.emul_ir_blocs(ira, bloc_begin)

Dans le code, on observe que plusieurs opérations sont effectuées sur le registre EAX et que la valeur résultante finie par être stockée dans var_14 (EBP+0xFFFFFFEC). Observons donc les zones mémoire modifiées suite à l’exécution symbolique :

>>> sb.dump_mem()
@32[(EBP_init+0xFFFFFFEC)] (((((ESI_init <<< 0x11)+((EDI_init&0x7) <<< 0x15)+(((((((((ESI_init+((({@16[(EBP_init+0xFFFFFFDC)],0,16, 0x0,16,32}+0x1BF5)*0xB11924E1) >>> 0x7)+0x27100001)*0xB11924E1) >>> 0x7)+{@16[(EBP_init+0xFFFFFFE2)][1:16],0,15, 0x0,15,32}+0x27100001)*0xB11924E1) >>> 0x7)+{@16[(EBP_init+0xFFFFFFDE)],0,16, 0x0,16,32}+0x2709A354)*0xB11924E1) >>> 0x7)+0x27100001)*0xB11924E1) >>> 0x7)+0x27100001)

L’expression peut paraître complexe à première vue mais on y reconnait tout de même les multiplications et additions avec les constantes déjà vues à l’étape 1, les rotations à gauche (<<<) et droite (>>>) ainsi que l’utilisation de différentes variables de pile. Nous allons simplifier cette expression à l’aide de Miasm. On peut déjà remplacer les lectures des registres ESI et EDI respectivement par la graine et l’index :

sb.symbols[machine.mn.regs.ESI] = ExprId("seed")
sb.symbols[machine.mn.regs.EDI] = ExprId("index")

Nous remplaçons également les lectures de la structure SYSTEMTIME sur la pile par des identifiants plus lisibles :

VAR_SYSTEMTIME = 0xFFFFFFDC
sb.symbols[ExprMem(ExprId("EBP_init") + ExprInt(VAR_SYSTEMTIME,   32), 16)] = ExprId("year", 16)
sb.symbols[ExprMem(ExprId("EBP_init") + ExprInt(VAR_SYSTEMTIME+2, 32), 16)] = ExprId("month", 16)
sb.symbols[ExprMem(ExprId("EBP_init") + ExprInt(VAR_SYSTEMTIME+6, 32), 16)] = ExprId("day", 16)

Il s’agit des mêmes initialisations que celles réalisées avec GDB ou la sandbox légère des méthodes 2 et 3. Après une nouvelle exécution, on obtient :

>>> sb.dump_mem()
@32[(EBP_init+0xFFFFFFEC)] (((((seed <<< 0x11)+((index&0x7) <<< 0x15)+(((((((((seed+((({year,0,16, 0x0,16,32}+0x1BF5)*0xB11924E1) >>> 0x7)+0x27100001)*0xB11924E1) >>> 0x7)+{day[1:16],0,15, 0x0,15,32}+0x27100001)*0xB11924E1) >>> 0x7)+{month,0,16, 0x0,16,32}+0x2709A354)*0xB11924E1) >>> 0x7)+0x27100001)*0xB11924E1) >>> 0x7)+0x27100001)

On peut encore simplifier en remplaçant les constantes par les identifiants c1, c2 et c3, en utilisant le moteur de simplification de Miasm :

def simplify_basic(expr):
  pattern1 = ExprInt(0xb11924e1, 32)
  replace1 = ExprId("c1")
  pattern2 = ExprInt(0x27100001, 32)
  replace2 = ExprId("c2")
  pattern3 = ExprInt(0x2709A354, 32)
  replace3 = ExprId("c3")
  simplifications = {
    pattern1:replace1,
    pattern2:replace2,
    pattern3:replace3,
  }
 
  return expr.replace_expr(simplifications)

Concernant les variables year et month, elles sont issues de champs de 16 bits d’une structure SYSTEMTIME et sont zéro-étendues à 32 bits par l’instruction movzx. Dans le langage intermédiaire de Miasm, cela correspond à une expression ExprCompose, notée avec des accolades. Pour plus de lisibilité, nous allons par exemple simplifier {year,0,16, 0x0,16,32} en year et idem pour month :

pattern4 = ExprCompose([(ExprId("year", 16), 0, 16), (ExprInt(0, 16), 16, 32)])
replace4 = ExprId("year", 32)
pattern5 = ExprCompose([(ExprId("month", 16), 0, 16), (ExprInt(0, 16), 16, 32)])
replace5 = ExprId("month", 32)

Concernant la variable day, Locky utilise l’instruction shr ecx, 1, ce que Miasm convertit en une composition de ecx[1:16] zéro-étendue à 32 bits. On va simplifier en day >> 1 uniquement :

pattern6 = ExprCompose([(ExprSlice(ExprId("day", 16), 1, 16), 0, 15), (ExprInt(0, 17), 15, 32)])
replace6 = ExprOp(">>", ExprId("day", 32), ExprInt(1, 32))

Avec ces 6 simplifications basiques, on obtient l’expression suivante :

>>> var_14 = simplify_basic(sb.symbols.symbols_mem[ExprId("EBP_init", 32) + ExprInt(0xFFFFFFEC, 32)][1])
>>> "var_14 = %s" % var_14
'var_14 = (((((seed <<< 0x11)+((index&0x7) <<< 0x15)+(((((((((seed+(((year+0x1BF5)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+(day >> 0x1)+c2)*c1) >>> 0x7)+month+c3)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+c2)'

On a ainsi converti le bloc d’initialisation en une ligne tout à fait lisible.

Dans les zones mémoire modifiées, on note aussi la mise à zéro de la variable var_10 :

>>> sb.dump_mem()
@32[(EBP_init+0xFFFFFFF0)] 0x0

La sortie de la boucle du DGA se fait par comparaison de var_10 avec EBX calculé dans ce premier bloc :

>>> "nb_loops = %s" % simplify_basic(sb.symbols[machine.mn.regs.EBX])
'nb_loops = (({(((((seed <<< 0x11)+((index&0x7) <<< 0x15)+(((((((((seed+(((year+0x1BF5)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+(day >> 0x1)+c2)*c1) >>> 0x7)+month+c3)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+c2),0,32, 0x0,32,64} umod 0xB)[0:32]+0x5)'

On y reconnait var_14 ; on va donc simplifier l’expression de var_14 en un identifiant var_14 pour plus de lisibilité :

>>> ebx = simplify_basic(sb.symbols[machine.mn.regs.EBX])
>>> ebx = ebx.replace_expr({var_14:ExprId("var_14")})
>>> "nb_loops = %s" % ebx
'nb_loops = (({var_14,0,32, 0x0,32,64} umod 0xB)[0:32]+0x5)'

Cette expression représente la taille du nom de domaine généré : 5 + var_14%0xB.

Dans les registres modifiés par ce bloc initial, EDI est initialisé à 0x10 :

>>> sb.dump_id()
EDI 0x10

Le premier bloc peut donc se résumer ainsi :

var_14 = (((((seed <<< 0x11)+((index&0x7) <<< 0x15)+(((((((((seed+(((year+0x1BF5)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+(day >> 0x1)+c2)*c1) >>> 0x7)+month+c3)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+c2)
nb_loops = (({var_14,0,32, 0x0,32,64} umod 0xB)[0:32]+0x5)
var_10 = 0x0
edi = 0x10

4.2 Boucle du DGA

Ce bloc d’initialisation étant compris, nous pouvons passer à la boucle du DGA. Son exécution symbolique n’atteint pas la fin du bloc :

>>> sb.symbols[machine.mn.regs.EIP]
ExprCond(<cond>, ExprInt(uint32(0x406e1bL)), ExprInt(uint32(0x406e1eL)))

Le moteur d’exécution symbolique se heurte au saut conditionnel basé sur une comparaison entre var_2C et EDI et ne sait quelle branche prendre. On sait qu’EDI est initialisé à 0x10 par le bloc précédent ; nous allons forcer la variable à zéro car le saut n’a pas d’incidence sur l’algorithme lui-même :

sb.symbols[ExprId('EDI', 32)] = ExprInt(0x10, 32)
sb.symbols[ExprMem(ExprId('EBP_init', 32) + ExprInt(0xffffffd4, 32))] = ExprInt(0, 32)

On en profite également pour initialiser les variables vues au bloc précédent :

sb.symbols[ExprMem(ExprId("EBP_init", 32) + ExprInt(0xFFFFFFEC, 32))] = ExprId("var_14", 32)
sb.symbols[ExprMem(ExprId('EBP_init', 32) + ExprInt(0xfffffff0, 32))] = ExprId("var_10", 32)

Cette fois-ci, l’exécution atteint bien la fin du bloc et les zones mémoire suivantes ont été altérées :

>>> sb.dump_mem()
@32[(EBP_init+0xFFFFFFF0)] (var_10+0x1)
@32[(EBP_init+0xFFFFFFEC)] ((((var_14 <<< ({var_10[0:8],0,8, 0x0,8,32}&0x1F))*0xB11924E1) >>> 0x7)+0x27100001)

var_10, initialisée à zéro dans le bloc précédent, est incrémentée de 1 dans la boucle et sert donc de compteur. var_14 se simplifie comme vu précédemment :

>>> var_14 = simplify_basic(sb.symbols.symbols_mem[ExprId("EBP_init", 32) + ExprInt(0xffffffec, 32)][1])
>>> "var_14 = %s" % var_14
'var_14 = ((((var_14 <<< ({var_10[0:8],0,8, 0x0,8,32}&0x1F))*c1) >>> 0x7)+c2)'

Dans cette expression, var_10 est zéro-étendue sur 32 bits, on peut simplifier :

pattern7 = ExprCompose(((ExprSlice(ExprId('var_10', 32), 0, 8), 0, 8), (ExprInt(uint24(0x0L)), 8, 32)))
replace7 = ExprId('var_10', 32)

On obtient ainsi :

>>> "var_14 = %s" % var_14
'var_14 = ((((var_14 <<< (var_10&0x1F))*c1) >>> 0x7)+c2)'

Le caractère généré par le DGA est présent dans EDX en fin de boucle :

>>> edx = simplify_basic(sb.symbols[machine.mn.regs.EDX])
>>> "char = %s" % edx
'char = {(({((((var_14 <<< ({var_10[0:8],0,8, 0x0,8,32}&0x1F))*c1) >>> 0x7)+c2),0,32, 0x0,32,64} umod 0x19)[0:8]+0x61),0,8, ({((((var_14 <<< ({var_10[0:8],0,8, 0x0,8,32}&0x1F))*c1) >>> 0x7)+c2),0,32, 0x0,32,64} umod 0x19)[8:32],8,32}'

On y reconnait l’expression de var_14 vue juste avant, d’où la simplification suivante :

>>> edx = edx.replace_expr({simplify_basic(var_14):ExprId("var_14")})
>>> "char = %s" % edx
'char = {(({var_14,0,32, 0x0,32,64} umod 0x19)[0:8]+0x61),0,8, ({var_14,0,32, 0x0,32,64} umod 0x19)[8:32],8,32}'

C’est simplement 0x61 + var_14%25, avec 0x61 = ord(‘a’). Cette boucle se résume donc ainsi :

var_14 = ((((var_14 <<< (var_10&0x1F))*c1) >>> 0x7)+c2)
char = {(({var_14,0,32, 0x0,32,64} umod 0x19)[0:8]+0x61),0,8, ({var_14,0,32, 0x0,32,64} umod 0x19)[8:32],8,32}
var_10 = (var_10+0x1)

4.3 Extension

Il ne reste plus que les quelques blocs générant l’extension. A l’adresse 0x406e74, c’est le registre EAX qui sert d’indice dans la chaîne des TLD :

>>> "eax = %s" % simplify_basic(sb.symbols[machine.mn.regs.EAX])
'eax = (({(((@32[(EBP_init+0xFFFFFFEC)]*c1) >>> 0x7)+c2),0,32, 0x0,32,64} umod 0xE)[0:32]*0x2)'

EBP_init+0xFFFFFFEC correspondant à var_14, on peut simplifier :

sb.symbols[ExprMem(ExprId("EBP_init", 32) + ExprInt(0xFFFFFFEC, 32), 32)] = ExprId("var_14", 32)

On obtient alors :

>>> "eax = %s" % simplify_basic(sb.symbols[machine.mn.regs.EAX])
'eax = (({(((var_14*c1) >>> 0x7)+c2),0,32, 0x0,32,64} umod 0xE)[0:32]*0x2)'

On a désormais tous les éléments de l’algorithme sous forme d’expressions Miasm :

# Initialisation
var_14 = (((((seed <<< 0x11)+((index&0x7) <<< 0x15)+(((((((((seed+(((year+0x1BF5)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+(day >> 0x1)+c2)*c1) >>> 0x7)+month+c3)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+c2)

nb_loops = (({var_14,0,32, 0x0,32,64} umod 0xB)[0:32]+0x5)
var_10 = 0x0
# Boucle de nb_loops iterations
var_14 = ((((var_14 <<< (var_10&0x1F))*c1) >>> 0x7)+c2)
char = {(({var_14,0,32, 0x0,32,64} umod 0x19)[0:8]+0x61),0,8, ({var_14,0,32, 0x0,32,64} umod 0x19)[8:32],8,32}
var_10 = (var_10+0x1)
# Extension
eax = (({(((var_14*c1) >>> 0x7)+c2),0,32, 0x0,32,64} umod 0xE)[0:32]*0x2)

4.4 Génération du code C

L’objectif étant de transcrire cet algorithme, et donc ces expressions Miasm, en C et Python, on va utiliser les traducteurs de Miasm. Par exemple sur l’initialisation de var_14 :

>>> "var_14 = %s" % var_14
'var_14 = (((((seed <<< 0x11)+((index&0x7) <<< 0x15)+(((((((((seed+(((year+0x1BF5)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+(day >> 0x1)+c2)*c1) >>> 0x7)+month+c3)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+c2)'
>>> "var_14 = %s" % Translator.to_language('C').from_expr(var_14)
'var_14 = ((((rot_right(32, (((((((rot_left(32, seed, 0x11) &0xffffffff)&0xffffffff)+((rot_left(32, (((index&0xffffffff)&(0x7&0xffffffff))&0xffffffff), 0x15) &0xffffffff)&0xffffffff)+((rot_right(32, (((((((rot_right(32, (((((((rot_right(32, ((((((seed&0xffffffff)+((rot_right(32, ((((((year&0xffffffff)+(0x1bf5&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(c2&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(shift_right_logic_32(day , 0x1)&0xffffffff)+(c2&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(month&0xffffffff)+(c3&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(c2&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(c2&0xffffffff))&0xffffffff)'

Pour le nombre d’itérations :

>>> "nb_loops = %s" % ebx
'nb_loops = (({var_14,0,32, 0x0,32,64} umod 0xB)[0:32]+0x5)'
>>> "nb_loops = %s" % Translator.to_language('C').from_expr(ebx)
'nb_loops = (((((umod64((vm_cpu_t*)jitcpu->cpu, ((((uint64_t)(var_14 & 0xFFFFFFFF)) << 0) | (((uint64_t)(0x0 & 0xFFFFFFFF)) << 32)), 0xb)>>0) & 0xFFFFFFFF)&0xffffffff)+(0x5&0xffffffff))&0xffffffff)'

On note que la traduction en C utilise parfois des fonctions tierces comme rot_left(), rot_right(), shift_right_logic_32() ou umod64(). Ces fonctions sont implémentées dans miasm2/jitter/vm_mngr.{c,h}. En copiant le code C ainsi généré par Miasm depuis toutes nos expressions simplifiées, on obtient le code suivant :

int dga(unsigned int seed, unsigned short index, unsigned short year, unsigned short month, unsigned short day) {
 
  unsigned char c;
  unsigned int eax;
  unsigned int c1 = 0xb11924e1;
  unsigned int c2 = 0x27100001;
  unsigned int c3 = 0x2709A354;
  char *tld = "rupweuinytpmusfrdeitbeuknltf";
  // Seed/date header
  if(index == 0)
    printf("0x%x %i-%02i-%02i\n", seed, year, month, day);
  // Initialisation
  unsigned int var_14 = ((((rot_right(32, (((((((rot_left(32, seed, 0x11) &0xffffffff)&0xffffffff)+((rot_left(32, (((index&0xffffffff)&(0x7&0xffffffff))&0xffffffff), 0x15) &0xffffffff)&0xffffffff)+((rot_right(32, (((((((rot_right(32, (((((((rot_right(32, ((((((seed&0xffffffff)+((rot_right(32, ((((((year&0xffffffff)+(0x1bf5&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(c2&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(shift_right_logic_32(day , 0x1)&0xffffffff)+(c2&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(month&0xffffffff)+(c3&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(c2&0xffffffff))&0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(c2&0xffffffff))&0xffffffff);
  unsigned int nb_loops = (((((umod64(((((uint64_t)(var_14 & 0xFFFFFFFF)) << 0) | (((uint64_t)(0x0 & 0xFFFFFFFF)) << 32)), 0xb)>>0) & 0xFFFFFFFF)&0xffffffff)+(0x5&0xffffffff))&0xffffffff);
  unsigned int var_10 = 0;
  // Loop
  while(1) {
 
    var_14 = ((((rot_right(32, ((((rot_left(32, var_14, (((var_10&0xffffffff)&(0x1f&0xffffffff))&0xffffffff)) &0xffffffff)&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(c2&0xffffffff))&0xffffffff);
    
    var_10 = (var_10+0x1);
  
    c = ((((uint32_t)((((((umod64(((((uint64_t)(var_14 & 0xFFFFFFFF)) << 0) | (((uint64_t)(0x0 & 0xFFFFFFFF)) << 32)), 0x19)>>0) & 0xFF)&0xff)+(0x61&0xff))&0xff) & 0xFF)) << 0) | (((uint32_t)(((umod64(((((uint64_t)(var_14 & 0xFFFFFFFF)) << 0) | (((uint64_t)(0x0 & 0xFFFFFFFF)) << 32)), 0x19)>>8) & 0xFFFFFF) & 0xFFFFFF)) << 8));
 
    printf("%c", c);
 
    if(var_10 >= nb_loops)
      break;
  }
  // Extension
  eax = (((((umod64(((((uint64_t)(((((rot_right(32, (((var_14&0xffffffff)*(c1&0xffffffff))&0xffffffff), 0x7) &0xffffffff)&0xffffffff)+(c2&0xffffffff))&0xffffffff) & 0xFFFFFFFF)) << 0) | (((uint64_t)(0x0 & 0xFFFFFFFF)) << 32)), 0xe)>>0) & 0xFFFFFFFF)&0xffffffff)*(0x2&0xffffffff))&0xffffffff);

  printf(".%c%c\n", tld[eax], tld[eax+1]);
  return 0;
}

Il ne reste plus qu’à tester la génération des noms de domaine d’avril et mai :

int main() {
  int d, i;
  for(d=1;d<=30;d++) {
    for(i=0;i<8;i++)
      dga(0x4d, i, 2016, 04, d);
    printf("\n");
  }
  for(d=1;d<=31;d++) {
    for(i=0;i<8;i++)
      dga(0x4d, i, 2016, 05, d);
    printf("\n");
  }
 
  return 0;
}
$ gcc -W -Wall dga.c -o dga
$ ./dga > dga_0x4d_method4_miasm_symb_c.txt
$ md5sum dga_0x4d_method2_gdb.txt dga_0x4d_method4_miasm_symb_c.txt
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method2_gdb.txt
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method4_miasm_symb_c.txt

Miasm a correctement généré l’algorithme et sa transcription en C est correcte.

4.5 Génération du code Python

La conversion en Python ne se passe malheureusement pas aussi bien :

>>> "var_14 = %s" % Translator.to_language('Python').from_expr(var_14)
NotImplementedError: Unknown operator: >>>
>>> "nb_loops = %s" % Translator.to_language('Python').from_expr(ebx)
NotImplementedError: Unknown operator: umod

Qu’à cela ne tienne, la représentation textuelle des expressions Miasm est déjà très proche du Python, donc il est possible de générer du code Python valide à l’aide de quelques substitutions par expressions régulières. L’expression Miasm représentant var_14 dans l’étape initiale est du code Python valide à l’exception des rotations gauche et droite :

>>> "var_14 = %s" % var_14
'var_14 = (((((seed <<< 0x11)+((index&0x7) <<< 0x15)+(((((((((seed+(((year+0x1BF5)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+(day >> 0x1)+c2)*c1) >>> 0x7)+month+c3)*c1) >>> 0x7)+c2)*c1) >>> 0x7)+c2)'

Nous allons remplacer dans cette représentation l’opération a <<< b par un identifiant rol(a,b) et a >>> b par ror(a,b) à l’aide du code suivant :

def expr2python_op(e_s, e):
  jok1 = ExprId("jok1", 32)
  jok2 = ExprId("jok2", 32)
  # seed <<< 0x11 => rol(seed,0x11)
  to_match = ExprOp("<<<", jok1, jok2)
  result = MatchExpr(e, to_match, [jok1, jok2])
  if result:
    return ExprId("rol(%s,%s)" % (result[jok1], result[jok2]))
  # bla >>> 0x7 => ror(bla, 0x7)
  to_match = ExprOp(">>>", jok1, jok2)
  result = MatchExpr(e, to_match, [jok1, jok2])
  if result:
    return ExprId("ror(%s,%s)" % (result[jok1], result[jok2]))
  return e

En ajoutant cette fonction au moteur de simplification de Miasm, on obtient du code Python valide pour var_14 :

>>> expr2python = {ExprOp:[expr2python_op]}
>>> expr_simp.enable_passes(expr2python)
>>> "var_14 = %s" % expr_simp(var_14.copy())
'var_14 = (c2+ror((c1*(c2+rol((index&0x7),0x15)+rol(seed,0x11)+ror((c1*(c3+month+ror((c1*(c2+ror((c1*(c2+ror((c1*(year+0x1BF5)),0x7)+seed)),0x7)+(day >> 0x1))),0x7))),0x7))),0x7))'

De la même manière pour le calcul du modulo :

>>> "nb_loops = %s" % ebx
'nb_loops = (({var_14,0,32, 0x0,32,64} umod 0xB)[0:32]+0x5)'
def expr2python_slice(e_s, e):
  jok1 = ExprId("jok1", 32)
  jok2 = ExprId("jok2", 64)
  to_match = ExprSlice(ExprOp('umod', ExprCompose(((jok1, 0, 32), (ExprInt(uint32(0x0L)), 32, 64))), jok2), 0, 32)
  result = MatchExpr(e, to_match, [jok1, jok2])
  if result:
    return ExprId("(%s%%%s)" % (result[jok1], result[jok2]))
  return e
>>> expr2python = {ExprOp:[expr2python_op], ExprSlice:[expr2python_slice]}
>>> expr_simp.enable_passes(expr2python)
>>> "nb_loops = %s" % expr_simp(ebx.copy())
'nb_loops = ((var_14%0xB)+0x5)'

Il s’agit de code Python valide et les autres expressions peuvent être converties de la même manière. Il ne reste qu’une étape, celle de l’ajout d’appels à v32() pour garantir les opérations arithmétique sur 32 bits :

def exprv32(e_s, e):
  jok1 = ExprId("jok1", 32)
  jok2 = ExprId("jok2", 32)
  jok3 = ExprId("jok3", 32)
  jok4 = ExprId("jok4", 32)
  # Apply v32 on each +
  to_match = ExprOp("+", jok1, jok2)
  result = MatchExpr(e, to_match, [jok1, jok2])
  if result:
    return ExprId("v32(%s+%s)" % (result[jok1], result[jok2]))
  # Apply v32 on each *
  to_match = ExprOp("*", jok1, jok2)
  result = MatchExpr(e, to_match, [jok1, jok2])
  if result:
    return ExprId("v32(%s*%s)" % (simplify_basic(result[jok1]), simplify_basic(result[jok2])))
  return e
>>> exprv32 = {ExprOp:[exprv32]}
>>> expr_simp.enable_passes(exprv32)

Finalement, var_14 et nb_loops ont comme expressions Python :

>>> "var_14 = %s" % expr_simp(var_14.copy())
'var_14 = v32(c2+ror(v32(c1*v32(c2+rol((index&0x7),0x15)+rol(seed,0x11)+ror(v32(c1*v32(c3+month+ror(v32(c1*v32(c2+ror(v32(c1*v32(c2+ror(v32(c1*v32(year+0x1BF5)),0x7)+seed)),0x7)+(day >> 0x1))),0x7))),0x7))),0x7))'
>>> "nb_loops = %s" % expr_simp(ebx)
'nb_loops = v32((var_14%0xB)+0x5)'

Il ne nous reste plus qu’à copier/coller dans un script toutes les expressions générées automatiquement et converties en Python :

def dga(seed, index, year, month, day):
  var_14 = v32(c2+ror((c1*(c2+rol((index&0x7),0x15)+rol(seed,0x11)+ror((c1*(c3+month+ror((c1*(c2+ror((c1*(c2+ror((c1*(year+0x1BF5)),0x7)+seed)),0x7)+(day >> 0x1))),0x7))),0x7))),0x7))
  var_10 = 0x0
  nb_loops = v32((var_14%0xB)+0x5)
  out = ''
  while True:
    var_14 = v32(c2+ror((c1*rol(var_14,var_10)),0x7))
    out += chr(v32((var_14%0x19)+0x61))
    var_10 = v32(var_10+0x1)
    if var_10 >= nb_loops:
      break
  eax = v32((v32(c2+ror(v32(c1*var_14),0x7))%0xE)*0x2)
  out += '.' + "rupweuinytpmusfrdeitbeuknltf"[eax:eax+2]
  return out

Testons sur les mois d’avril et mai 2016 si tout fonctionne :

seed = 0x4d
begin = datetime.datetime(2016, 4, 1)
end = datetime.datetime(2016, 5, 31)
domains_per_day = 8
date = begin
while date <= end:
  # Seed/date header
  print "0x%x %s" % (seed, date.strftime("%Y-%m-%d"))
  for i in range(domains_per_day):
    # Domain
    print dga(seed, i, date.year, date.month, date.day)
  date += datetime.timedelta(days=1)
  print ""
$ ./dga_miasm_symb.py > dga_0x4d_method4_miasm_symb.txt
$ md5sum dga_0x4d_method2_gdb.txt dga_0x4d_method4_miasm_symb.txt
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method2_gdb.txt
116cd7fdb273cd47f60c59841b81c769 dga_0x4d_method4_miasm_symb.txt

Parfait !

Conclusion

Les DGA utilisés par les malwares sont généralement simples et facilement traduisibles directement par un humain dans le langage de son choix. Mais en cas d’algorithme coriace ou de changements fréquents, il peut être utile d’automatiser cette tâche. Via une machine virtuelle classique, GDB permet de le faire mais si on cherche une solution plus légère, le framework Miasm s’avère très pratique. Sa sandbox permet d’émuler le code provenant d’un binaire et ainsi de générer très rapidement les domaines, sans se soucier des détails du DGA.

Si au contraire on cherche à reconstituer l’algorithme pour le réimplémenter dans un autre langage, le module d’exécution symbolique de Miasm permet de générer des expressions dans un langage intermédiaire correspondant aux zones mémoire ou registres modifiés, qu’il est possible de réduire via son moteur de simplification. La transcription en C ou Python peut alors être réalisée directement via le module Translator ou via des expressions régulières : on obtient ainsi l’algorithme lui-même et pas uniquement le résultat de son exécution.



via Lexsi Security Hub http://bit.ly/1UOVIZO
//Activation syntaxhilight