SecurityInsider
Le blog des experts sécurité Wavestone

CERT-Areva / CERT-Société Générale - L’interview croisée



Depuis quelques années, de plus en plus d’équipes «CERT» ou «CSIRT» voient le jour en France. Toutes ces équipes ne réalisent pas exactement les mêmes activités, n’agissent pas sur les mêmes périmètres et ont, par conséquent, des métiers différents bien que toujours orientés vers la défense du Système d’Information.
Nous vous proposons de rencontrer deux responsables de CERT très différents l’un de l’autre : Patrick BREHIN, responsable du CERT-Areva, et Jean-Philippe TEISSIER, responsable du CERT-Société Générale.

Quelles sont les activités menées par votre CERT, et comment les organisez-vous ?

Patrick BREHIN (CERT-Areva) : Nous menons trois activités principales au sein de notre CERT :
  • Supervision de sécurité : détection de comportements anormaux et à risques pour le Système d’Information, notamment au travers du pilotage du SOC.
  • Gestion des crises SSI.
  • Veille cyber-menace. Notre veille aide à définir les priorités en termes de détection ainsi qu’à communiquer en interne sur les menaces actuelles.
Les activités de détection assurées par le SOC et l’équipe de réaction sont en 24/7.

Jean-Philippe TEISSIER (CERT-SG) : Le CERT Société Générale assure des activités de veille, de détection et de réaction.
Tout d’abord, nous sommes les yeux et les oreilles du Groupe Société Générale sur Internet. Notre mission est de détecter au plus tôt les menaces qui ciblent le Groupe et ses clients. Ensuite, lorsqu’un incident survient, nous avons la responsabilité partielle ou complète de sa résolution. Nous mettons alors en oeuvre tous les différents savoirs faire de l’équipe (analyse de log, analyse inforensique, analyse de code malveillant, coordination voire gestion de crise). Enfin, nous fournissons une veille sécurité (actualités, menaces et vulnérabilités) à l’ensemble du Groupe.

La lutte contre la cybercriminalité est l’affaire de tous. Cela nécessite des moyens et une collaboration importante avec l’extérieur du Groupe. Pour un établissement bancaire cela va de soi et c’est un message audible et pris en compte par la Direction Générale qui est très impliquée sur ce sujet.

Quelle est la taille de votre équipe ?

Patrick BREHIN (CERT-Areva) : Notre équipe complète est composée d’un peu plus de dix personnes réparties entre :
  • notre AMOA de proximité ;
  • notre équipe de détection ;
  • notre équipe de réaction.

Jean-Philippe TEISSIER (CERT-SG) : L’équipe est composée de six "incident handlers", aussi appelés analystes. Elle est en croissance constante depuis sa création il y a bientôt dix ans.
Nous partageons pleinement les valeurs du Groupe :
  • l’esprit d’équipe : chaque membre de l’équipe sait qu’il peut compter sur les autres sans limite, chacun est plus ou moins spécialisé dans un domaine, et c’est l’ensemble qui fait la force de l’équipe. Nous apportons notre aide à toute entité qui nous sollicite dans le Groupe ;
  • l’innovation : nos activités de R&D sont le support essentiel à notre activité ;
  • la responsabilité : la nature même des sujets que nous traitons demande une déontologie et un sens des responsabilités très fort ;
  • l’engagement : nous sommes un centre de service pour nos partenaires internes et nous nous engageons pour eux au quotidien afin de les aider le plus rapidement et le plus simplement possible, de jour comme de nuit.
Enfin, même si nous avons une forte activité de R&D une certaine partie de nos moyens de détection ou de mitigation sont externalisés. Il faut savoir identifier les activités où cela a du sens de faire appel à des fournisseurs externes spécialisés qui mutualisent la R&D et les coûts de fonctionnement. La proportion dépend de chaque entité.

Quelle répartition entre les activités de BUILD et celles de RUN ?

Patrick BREHIN (CERT-Areva) : Notre activité principale de surveillance est répartie comme suit :
  • BUILD (20%) : le CERT-Areva définit les besoins et les cibles de supervision, ainsi que les règles de détection. J’ai un fort besoin de maîtriser le périmètre de supervision.
  • RUN (80%) : il s’agit de l’activité principale du CERT-Areva, elle contient les phases de collecte, de détection et de réaction.

Jean-Philippe TEISSIER (CERT-SG) : Nous consacrons près de 30% de notre charge de travail au BUILD et le reste au RUN.
Nous évoluons dans un domaine peu mature et dans lequel les technologies changent très rapidement. Cela nous demande une capacité d’adaptation très importante qui passe par des phases de BUILD dont les développements peuvent être soit ponctuels (de quelques heures à quelques jours) soit quasi récurrents.

Quels sont vos sujets prioritaires pour l’année à venir ?

Patrick BREHIN (CERT-Areva) : Les grands sujets prioritaires pour le CERT-Areva sont l’extension de la supervision des SI Industriels et l’amélioration continue de nos objectifs de supervision de sécurité au regard de la menace pour Areva.

Jean-Philippe TEISSIER (CERT-SG) : Le renseignement sur les menaces (threat intelligence) est pour nous le sujet prioritaire.
En revanche notre objectif n’est pas d’acheter tous les « feeds » techniques spécialisés qui existent. Nous réfléchissons au sujet en profondeur, de la définition même du sujet aux livrables techniques, opérationnels ou stratégiques que nous produisons. Nous n’y réfléchissons pas seuls mais en collaboration avec d’autres équipes de type CERT.
Nous travaillons également à l’industrialisation de nos systèmes afin d’optimiser au mieux leur utilisation par l’ensemble des équipes internes avec lesquelles nous sommes en contact.

Sur quels types de projets développez-vous en interne ?

Patrick BREHIN (CERT-Areva) : Les projets que nous développons en interne nous servent à assurer la maîtrise du périmètre supervisé et des objectifs de détection avec entre autres une formalisation des objectifs de détection.
Concrètement, il s’agit de :
  • Maîtriser la nature et l’information présentée par les évènements collectés.
  • Définir et décrire les règles de détection que l’on souhaite mettre en oeuvre en commençant par décrire fonctionnement le comportement recherché (ce qu’on cherche à détecter) ; et ensuite en les décrivant techniquement : quel(s) évènement(s) analysé(s) et de quelle manière.
  • Décliner opérationnellement ces règles par contexte d’application.

L’objectif de l’outil : être à tout moment capable de savoir ce qui est et ce qui n’est pas supervisé. L’objectif complémentaire est de se doter d’une capacité de contrôler l’efficacité et le périmètre d’application des règles de supervision.

Jean-Philippe TEISSIER (CERT-SG) : Jusqu’à 30% de notre temps est dédié à la R&D, que ce soit pour le développement d’outils modestes et tactiques, ou pour le développement de nos plateformes plus importantes d’analyse de code malveillants, de renseignement sur les menaces ou de gestion d’incidents.
Nous ne réinventons pas ce qui existe déjà mais nous nous assurons d’avoir un écosystème d’outils cohérents et qui préserve notre temps pour se consacrer aux vraies problématiques.
Nous nous inscrivons depuis des années dans une démarque de partage avec nos homologues et certains de nos outils sont libres et disponibles sur Github (https://github.com/certsocietegenerale/).

Comment échangez-vous avec les différentes entités métiers et techniques de votre groupe ?

Patrick BREHIN (CERT-Areva) : Le métier et les objectifs du CERT-Areva sont présentés aux interlocuteurs métiers et projets BUILD et RUN, notamment les démarches de supervision mises en oeuvre.
Le CERT-Areva est le référent de la DSI pour tout ce qui est supervision / détection et alertes. Nous travaillons avec toutes les équipes projets lors des phases de BUILD. Le rôle du CERT-Areva est d’aider à définir le besoin et la cible de supervision et s’assurer qu’elle est bien atteinte.
Les missions du CERT-Areva sont reconnues : il y a des campagnes de communication interne régulières et les missions du CERT-Areva sont intégrées dans les formations sécurité internes du Groupe.

Jean-Philippe TEISSIER (CERT-SG) : Nous avons des relations très directes avec nos différentes entités. Le CERT Société Générale est une structure de niveau Groupe, ce qui nous permet de nous adresser à toutes nos entités sans barrière organisationnelle trop contraignante.
Nous avons tissé des liens étroits avec les équipes sécurité ou fraude de nos entités au fil des années et nous nous adaptons à chaque métier. Cela nous permet de travailler efficacement avec chacune d’entre elles en respectant leurs contraintes propres. C’est un effort permanent dans une structure de la taille de notre Groupe mais c’est la clé d’une coopération efficace.
Nous sommes régulièrement sollicités par notre département de l’Innovation. Nous dépendons de la même direction. Notre présence relativement précoce sur les réseaux sociaux, nos activités de R&D et notre activité sur un sujet en constante évolution font du CERT un bon candidat aux expérimentations. C’est un axe que nous continuerons de développer dans les années à venir afin que la filière SSI s’inscrive encore plus fortement dans la démarche d’innovation et de transformation digitale du Groupe.
Enfin, aujourd’hui nous avons plusieurs SOC (ou équivalent) au sein du Groupe dans différents pays. Le CERT préexistait à leurs créations.
Nous nous positionnons à la fois comme fournisseur de solutions (qualification d’outils ou procédures, renseignement sur les menaces) et comme experts afin de les aider dans la qualification et la résolution des incidents.
Notre positionnement de niveau Groupe nous permet notamment d’agir comme un centre de « fusion de données » afin que tous les SOC profitent des renseignements émanant des autres entités. Nous attendons d’eux qu’ils démultiplient les capacités de détections et les actions de remédiation industrialisables.
Il est primordial pour moi que le CERT et le ou les SOC travaillent en étroite collaboration et nous avons des échanges quotidiens avec les différentes équipes. Un CERT sans SOC(s) est souvent trop peu informé de la situation sur son système d’information et l’efficacité des SOC(s) sans CERT est souvent décriée.

Quels liens entretenez-vous avec les autres équipes CERT/CSIRT et entités externes ?

Patrick BREHIN (CERT-Areva) : Évidemment, nous discutons avec l’ANSSI ! Néanmoins, aujourd’hui nous ne discutons pas suffisamment avec nos homologues, mais nous sommes clairement preneurs de contacts et tout à fait prêts à échanger avec nos pairs !

Jean-Philippe TEISSIER (CERT-SG) : C’est dans la nature même des CERT que d’échanger. Les sujets que nous traitons demandent néanmoins de la discrétion et il faut savoir respecter les règles du jeu.
Nous avons des liens très étroits avec nos homologues, notamment avec les entités du secteur bancaire en France comme à l’international, avec lesquelles nous échangeons au quotidien. C’est une activité à part entière que de tisser et maintenir des relations de confiance avec les bonnes équipes.

Quid des relations avec vos filiales internationales et des relations avec les organismes internationaux ?

Patrick BREHIN (CERT-Areva) : Le CERT-Areva a une portée mondiale : tout le traitement des incidents est dévolu en central au CERT-Areva et des correspondants SSI sont utilisés.
Nous tentons chaque fois que possible de mettre en place des liens de communications avec nos partenaires, fournisseurs et clients de CERT à CERT quand ils existent, ou à minima avec des équipes de réaction sur incident même non officialisé. L’objectif est de mettre en place des circuits de communication rapide en cas de découverte d’un évènement de sécurité par une des parties qui pourrait affecter l’autre partie. Ce type de circuit est en général assez difficile à mettre en place, notamment par manque d’équipe dédiée et surtout par la peur de communiquer de tels évènements s’ils ont lieu.

Jean-Philippe TEISSIER (CERT-SG) : Société Générale est présent dans 76 pays dans le monde et 25% des incidents que nous gérons sont pour les entités internationales. Toutes les entités internationales ne sont pas exposées au même modèle de menaces. Comme indiqué précédemment (au delà de la gestion d’incidents et des analyses que nous réalisons au cas par cas) nous mettons l’accent sur l’agrégation et la redistribution d’informations qualifiées entre nos entités. Si les grands Groupes peuvent parfois souffrir de leur taille, c’est dans le cas présent un atout dont nous profitons.
Nous n’avons que peu de relations directes avec les CERT nationaux étrangers. Nos entités locales nous remontent néanmoins les informations qu’elles sont autorisées à partager. Nous pouvons toujours faire appel aux CERT nationaux étrangers pour appuyer nos demandes sur des acteurs locaux.

À qui reportez-vous vos activités ?

Patrick BREHIN (CERT-Areva) : Le CERT-Areva reporte directement au DSI et au RSSI du Groupe Areva. Les objectifs du CERT-Areva sont définis par le responsable du CERT-Areva et validés par les personnes citées précédemment.

Jean-Philippe TEISSIER (CERT-SG) : Le CERT reporte directement au RSSI-Groupe, la tête de filière SSI du Groupe, et intervient en son nom. C’est l’ensemble des RSSI des lignes business et des directions centrales qui fixent les objectifs du CERT et qui valident son budget de fonctionnement.

Un dernier mot ?

Patrick BREHIN (CERT-Areva) : Formalisons et partageons !
Clairement, aujourd’hui, il est nécessaire d’avoir une meilleure maîtrise et de disposer d’une vue exhaustive de ce que nous surveillons, afin de pouvoir s’améliorer dans le temps et de partager entre pairs.

Jean-Philippe TEISSIER (CERT-SG) : Optimisme. Nous avons en France un pool d’expertise important en cyber-sécurité et le nombre d’équipes de gestion d’incidents est en très forte augmentation depuis deux ans. C’est très encourageant et nous n’avons pas à rougir de notre capacité de protection au niveau national. L’intensification des contacts entre les équipes et le passage à l’échelle des échanges opérationnels sont pour moi les deux sujets principaux que les CERT doivent traiter rapidement. Cela permettra d’augmenter significativement notre résilience globale.

Wavecrack, notre outil de cassage de mot de passe


« Cassage de mots de passe » ?

Les mots de passe ne sont pas stockés de manière générale en clair dans une application, dans un fichier, etc., mais sont stockées sous forme de hash. Les fonctions de hachage sont des fonctions permettant notamment de transformer une chaîne de caractères en une autre chaîne de caractères, avec la spécificité de ne pas être réversible. Ainsi, pour valider qu’un mot de passe saisi est valide, il suffit de comparer sa valeur hachée à la valeur hachée du mot de passe initial. En revanche, à partir du mot de passe haché, il n’existe pas de fonction pour retrouver le mot de passe initial.
Or, au cours d’audits, il est fréquent d’identifier des hash de mots de passe et d’avoir besoin de retrouver le mot de passe initial. Plusieurs techniques existent pour cela, la technique la plus simple étant une attaque par bruteforce. Cette technique consiste à essayer toutes les combinaisons de chaines de caractères possibles, de les hacher et de les comparer au hash cherché :


Figure 1 : Exemple de tentative de bruteforce pour trouver le mot de passe correspondant au hash 0b9c2625dc21ef05f6ad4ddf47c5f203837aa32c (mot de passe initial : « toto »)

Ces techniques sont appelées techniques de « cassage » de hash mots de passe. Ce cassage est coûteux en temps et requiert une grande capacité de calcul parallèle afin de réaliser le grand nombre d’opérations requis pour retrouver un mot de passe.

Comment être plus efficace ?

Sur un poste de travail standard, ces opérations sont peu performantes donc le temps nécessaire pour casser un mot de passe est long. Pour remédier à cela, il est courant d’utiliser des serveurs ayant des performances particulièrement élevées. En particulier, les cartes graphiques sont très performantes pour ce type d’opération. Il est ainsi possible en quelques clics de louer un serveur avec de grosses performances de calcul chez Amazon par exemple ou plus simplement d’acheter du matériel spécifique pour construire un serveur de cassage.
En outre, il existe de nombreux outils et techniques de cassages, mais ceux-ci ne sont pas nécessairement simples à utiliser ou difficiles à utiliser de manière performante (complexité des modes d’attaque, enchaînement de techniques, restitution des résultats, etc.).
Enfin, dans le cadre de l’offre audit Wavestone certifiée ISO 27001, la confidentialité des données étant particulièrement importante, il est nécessaire d’assurer une ségrégation entre les données de cassages des 40 auditeurs.
Pour cela, une interface web a été développée avec pour objectif de simplifier la gestion des outils de cassage de mots de passe, avec notamment une automatisation des tâches et permettre un accès multi-utilisateur avec un cloisonnement strict des tâches en cours.

Fonctionnement de Wavecrack

L’interface proposée permet à un utilisateur de saisir une liste de hash ou d’uploader un fichier de hash et de choisir des options de cassage telles que :
  • Choix du type de hash à transmettre à l’outil de cassage ou utilisation d’une reconnaissance automatique
  • Choix du type d’attaque (lancement successif des attaques sélectionnées) :
    • Utilisation de listes de mots (dictionnaires, listes de mots de passe fuités, etc.)
    • Utilisation de listes de mots avec variations sur ces mots (ajout de chiffres et caractères spéciaux, changement de la casse, etc.)
    • Attaque par masque
    • Attaque par bruteforce pur
  • Choix de la durée de cassage.


Figure 2 : Interface de saisie de hash

Lorsqu’un cassage est lancé (de manière asynchrone), il est possible de suivre en temps réel son avancement. Cette page permet également de visualiser des statistiques sur les mots de passe cassés :


Figure 3 : Statistiques sur les mots de passe cassés en temps réel

Les mots de passe cassés peuvent être exportés au format CSV.

Chaque utilisateur a accès à l’historique de ses cassages, et seul l’utilisateur qui a lancé un cassage peut visualiser son contenu. Cela permet d’assurer une ségrégation entre plusieurs utilisateurs.

L’authentification repose par défaut sur un annuaire LDAP, mais peut être adaptée afin d’utiliser un référentiel local par exemple.

Enfin, le moteur de lancement des tâches permet également d’ajouter des fonctionnalités à hashcat. Par exemple, les mots de passe associés à des hash LM sont pris en charge dans leur totalité plutôt que sous forme de demi hash LM comme les manipule hashcat.

Le code source de cette interface est publié en open-source sur le github de Wavestone CDT .



N'hésitez pas à tester cet outil et nous faire part de vos remarques ou suggestions !

Cyprien OGER

CERT-W : retour sur l'actualité de la semaine du 6 février au 10 février 2017



Comme chaque semaine, retrouvez notre revue d'actualité de la sphère cyber-sécurité. Cette compilation de brèves vous permettra d'alimenter les discussions des prochaines pauses cafés !

[Focus] Ticketbleed

Dans la famille des vulnérabilités ayant un logo et portant un nom tonitruant, la petite dernière s’appelle Ticketbleed. Comme dans Heartbleed, il s’agit d’une vulnérabilité affectant la pile TLS et révélant des données aléatoires et potentiellement sensibles. Cette vulnérabilité, publiée par Filippo Valsorda, affecte les produits F5 BIG-IP et permet d’obtenir jusqu’à 31 octets de données à chaque attaque.

Les F5, késako?

Le produit BIG-IP de F5 Networks est un répartiteur de charge (load balancer en anglais) permettant essentiellement de distribuer un nombre important de connexions sur plusieurs serveurs. Dans le cas d’une utilisation devant des serveurs web, ce sera le F5 qui fera office de terminaison ssl, c’est-à-dire que les clients établiront la connexion sécurisée avec le serveur BIG-IP et non avec les serveurs web qui sont derrière.


Schéma de l’utilisation d’un répartiteur de charge

Description de la vulnérabilité

La vulnérabilité provient de l’implémentation des tickets de session TLS dans les produits F5. Ces tickets sont utilisés pour permettre à un client de reprendre une session TLS déjà commencée, au lieu de recommencer la poignée de mains.
Selon la RFC 5077, lorsqu’un client envoie un Session ID accompagnant un ticket et que celui-ci est accepté par le serveur, ce même Session ID doit être renvoyé au client. Il se trouve que tous les navigateurs, OpenSSL, NSS et BoringSSL utilisent des Session ID de 32 octets. Les répartiteurs de charge F5 renvoient donc systématiquement, lorsque le Session ID n’est pas vide, 32 octets de données. En utilisation nominale, ceci ne pose pas d’inconvénient. Le problème se pose lorsque l’on force l’envoi d’un ticket valide accompagné d’un Session ID de longueur inférieure. Le F5 renverra bien le Session ID du client, mais cette fois-ci suivi de mémoire non-initialisée, comme c’était le cas pour Heartbleed.



Impact

Pour l’instant la mémoire récupérée semble contenir des Session ID d’autres utilisateurs. Il est néanmoins envisageable qu’elle contienne d’autres informations (plus sensibles). En effet, les identifiants de session TLS ne sont pas, à eux seuls, des données particulièrement sensibles. En revanche, le fait de divulguer le contenu de mémoire non-initialisée reste extrêmement risqué. Si des données confidentielles (comme la clé privée du serveur) peuvent être obtenues, alors la faille devient véritablement critique.

Mesures correctives

Pour corriger cette faille à très court terme, il suffit de désactiver l’utilisation des tickets de session au niveau du système affecté. Ceci forcera les clients à rétablir une session TLS à chaque connexion. Ceci devrait avoir un impact négligeable sur les performances des systèmes mis en jeu. Les éléments de configuration nécessaires pour désactiver la fonctionnalité sont présentés dans le billet consacré à Ticketbleed dans site officiel de F5 Networks.
La correction à plus long terme consiste à mettre à jour les appliances affectées. Les correctifs sont d’ores et déjà disponibles pour les versions vulnérables :

  • BIG-IP LTM versions antérieures à 12.1.0
  • BIG-IP AAM versions antérieures à 12.1.0
  • BIG-IP AFM versions antérieures à 12.1.0
  • BIG-IP Analytics versions antérieures à 12.1.0
  • BIG-IP APM versions antérieures à 12.1.0
  • BIG-IP ASM versions antérieures à 12.1.0
  • BIG-IP DNS versions antérieures à 12.1.0
  • BIG-IP Link Controller versions antérieures à 12.1.0
  • BIG-IP PEM versions antérieures à 12.1.0
  • BIG-IP WebSafe versions antérieures à 12.1.0
  • BIG-IP GTM versions antérieures à 11.5.0 à 11.6.1


Sources

https://www.theregister.co.uk/2017/02/09/f5s_bigip_leaks_lots_of_little_chunks_of_memory/
http://www.cert.ssi.gouv.fr/site/CERTFR-2017-AVI-048/CERTFR-2017-AVI-048.html
https://blog.filippo.io/finding-ticketbleed/
https://tools.ietf.org/html/rfc5077
https://filippo.io/Ticketbleed/
https://support.f5.com/csp/article/K05121675
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9244
https://www.ietf.org/rfc/rfc5077.txt
https://nmap.org/nsedoc/scripts/tls-ticketbleed.html
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9244



[Brève] Des blogs attaqués suite à la publication d’une vulnérabilité dans WordPress Core

Une faille majeure, corrigée dans la version 4.7.2 de Wordpress, permet de modifier le contenu des blogs vulnérables. À la suite de la publication des premiers exploits publics, plus de 1.5 millions de sites auraient été visés.
http://www.bbc.com/news/technology-38930428
https://make.wordpress.org/core/2017/02/01/disclosure-of-additional-security-fix-in-wordpress-4-7-2/
https://github.com/Iansus/sploits/blob/master/WordPress/
                                                                                                                                                   

[Brève] Des attaques sur les banques polonaises attribuées au groupe Lazarus

Plusieurs banques polonaises ont été infectées par des logiciels malveillants. Les infections ont eu lieu suite à des visites sur le site de l’autorité de supervision financière polonaise. Cette attaque de type watering hole contiendrait du code provenant de la suite utilisée par le même groupe responsable de l’attaque subie par Sony Pictures en 2014.
http://securityaffairs.co/wordpress/56235/apt/lazarus-group-polish-bank.html
https://www.theregister.co.uk/2017/02/13/sony_pictures_hackers_lazarus_returns/


[Brève] Un service en ligne pour analyser des captures réseau malveillantes 

À la manière de virustotal (et donc à utiliser avec les mêmes précautions), le service packettotal permet d’analyser des captures réseau en format pcap et pcapng.
http://www.packettotal.com
https://isc.sans.edu/diary/Do%2BYou%2BUse%2BVirusTotal%3F%2B%2BGive%2BPacketTotal%2Ba%2BSpin%21/22061


[Brève] Publication d’un outil de post-exploitation permettant de récolter des données et effectuer de l’administration à distance sur macOS

https://github.com/manwhoami/Bella


[Brève] Une XSS dans Steam corrigée par Valve

Un champ dans les profils utilisateur était jusqu’à présent vulnérable à de l’injection de code. Une visite vers la page de profil d’un utilisateur malveillant entrainait alors l’exécution de code dans le navigateur de la victime.
https://threatpost.com/valve-patches-trivial-xss-bug-in-steam/123647/
https://www.reddit.com/r/Steam/comments/5skfg4/warning_regarding_a_steam_profile_related_exploit/


[Brève] Une mise à jour firmware suite à des vulnérabilités critiques sur les routeurs TP-LINK

https://threatpost.com/updated-firmware-due-for-serious-tp-link-router-vulnerabilities/123702/
https://pierrekim.github.io/advisories/2017-tplink-0x00.txt


Patricio CASTRO DU PLESSIS

Compte-rendu de GreHack 2016



Introduction

Le 18 novembre dernier se déroulait la 4ème édition de la conférence GreHack à Grenoble. Cet évènement, purement axée sur la sécurité, accueillait 300 participants pour une journée entière de conférences, suivie par son traditionnel CTF se déroulant la nuit et regroupant plus de 30 équipes. En complément, des workshops sur des outils divers et variés étaient organisés dans la soirée (radare2, miasm2, scapy, IVRE, ZAP, outils de crypto en boîte blanche, de SDR, et introduction au crochetage de serrures).

KeyNote : Protecting Data on Smartphones & Tablets with Trusted Computing

Stefan Saroiu, chercheur chez Microsoft Research, présente le travail de son équipe sur la protection des données sur plateformes mobiles.
Le nombre de smartphones et tablettes est en constante expansion, et la sensibilité des applications s’y exécutant augmente également. Par exemple, des banques proposent aujourd’hui des applications permettant de prendre en photo des chèques destinés à être encaissés sur le compte de l’utilisateur de l’application. La question de la confiance dans l’authenticité et la confidentialité des données manipulées par les plateformes mobiles devient donc un fort enjeu. 
Des solutions telles que les TPM (Trusted Platform Module) permettent de garantir un certain niveau de confiance dans l’intégrité d’une plateforme. Ces puces sont aujourd’hui présentes dans de nombreux postes de travail (fixe ou portable) et serveurs. Néanmoins, à cause de contraintes d’espace, de coût et d’autonomie, les smartphones actuels ne n’embarquent pas une telle technologie.
Le projet fTPM (pour firmware TPM) de Microsoft Research vise implémenter les fonctions d’une puce TPM de manière logicielle, tout en garantissant un niveau de sécurité équivalent. Cette solution s’appuie sur des primitives de sécurité offertes par certains mécanismes introduits dans certaines architectures, telles que TrustZone dans les SoC ARM, ou SGX (Software Guard Extensions) dans les SoC Intel. Un travail poussé de conception a été également réalisé afin de garantir la réactivité du mécanisme, afin de le rendre transparent pour l’expérience utilisateur.
Dans les dernières minutes de la présentation, Stefan Saroiu présente également le projet Sentry, visant à implémenter un chiffrement total de la mémoire d’un smartphone ou d’une tablette durant son exécution, afin de le protéger contre une attaque de type coldboot par exemple. Afin de réussir cette prouesse, les pages mémoires stockées dans la RAM ne sont déchiffrées qu’au moment de leur lecture par le CPU, et chiffrées de nouveau avant leur réécriture dans la RAM. Pour cela, AES a été implémenté de telle sorte que seuls les registres du CPU et le cache L2 soit utilisé comme mémoire temporaire lors de l’exécution de l’algorithme.

BtleJuice : the Bluetooth Smart Man-In-The-Middle Framework

Damien Cauquil, chercheur senior au CERT-UBIK (Digital Security), démontre dans sa présentation les faiblesses pouvant apparaitre sur objet connectés utilisant le protocole Bluetooth Low Energy.
Le protocole Bluetooth Low Energy (ou Smart Bluetooth) et très populaire dans le monde de l’IoT, et permet les communications entre et avec des objets connectés. Il s’agit d’un sous ensemble du standard Bluetooth 4.0+, plus léger, permettant des implémentations peu consommatrices en énergie. Côté sécurité, le protocole intègre des mécanismes d’authentification et de chiffrement. 
Lors de l’appairage de deux périphériques, ceux-ci s’échangent des informations concernant les interfaces dont ils disposent (clavier/pavé numérique permettant de composer un code, écran permettant de l’afficher, etc…). Une clé temporaire est alors dérivée du code PIN échangé, puis les périphériques décident d’une clé à utiliser afin de chiffrer le reste des échanges. Cependant, lorsque les interfaces des périphériques ne disposent pas d’interface permettant d’échanger un code PIN, le protocole fonctionne en mode dégradé (« Just Works »), et l’échange des clés de chiffrement n’est pas authentifié.
Damien Cauquil présente alors qu’il est plus simple d’effectuer une attaque de type Man-In-The-Middle qu’une simple écoute du trafic, et expose BtleJuice (https://github.com/DigitalSecurity/btlejuice), un framework facilitant la mise en place de MitM sur les échanges Bluetooth Low Energy. Ecrit en Node.js, le framework dispose d’une interface Web permettant d’intercepter faciliter les communications, et permet également d’enregistrer des fonctions de callbacks écrites en Python, permettant de modifier des échanges à la volée.
La présentation termine par diverses contremesures possibles pour ce type d’attaque, dont la principale est reste la mise en place de chiffrement et d’authentification au niveau applicatif. Cependant, cette mesure casse l’interopérabilité entre différents composants qui n’aurait pas été développés par les mêmes entités.

Arybo : Make expression simplification great again

Quarkslab  présente un nouvel outil permettant de simplifier (au sens : « rendre synthétique et simple à comprendre pour un humain ») des expressions arithmético-booléennes, dans le but principal d’aider le reverse-engineering de programmes obfusqués.
Actuellement, il existe des logiciels de calcul formel permettant de simplifier aisément des expressions arithmétiques, c’est-à-dire composées d’opérateurs mathématiques classiques tels que l’addition, la multiplication, la soustraction, etc. Par exemple, l’expression « (x+7x)*3 » peut être simplifiée en « 24x ».
De même, des logiciels existent également pour simplifier des expressions booléennes, c’est-à-dire composée d’opérateurs tels que « ET », « OU », « OU EXLCUSIF » (XOR), « NON ». Par exemple, l’expression « (a ET (NON b)) OU ((NON a) ET b » peut être réécrite en « a OU EXCLUSIF b ».
Les expressions composées des deux familles d’opérateurs sont appelées « arithmético booléenne ». A l’heure actuelle, la plupart des outils permettant de simplifier ce type d’expression sont basés sur du pattern matching, c’est-à-dire en appliquant des formules de simplification connues sur des sous-parties de l’expression à simplifier. Cependant, ces outils ne peuvent simplifier des formules ne correspondant à aucun pattern. De fait, plusieurs programmes obfusqués (malware, DRMs, …) tirent parti de ce manque d’outillage pour transformer des opérations simples en des expressions arithmético-booléennes complexes équivalentes, afin de complexifier le reverse-engineering.
Quarkslab propose un nouvel outil, nommé Arybo, permettant de manipuler ce type d’expression et de les simplifier efficacement. Leur approche est basée sur le bit-blasting, c’est-à-dire que toute variable est traitée comme un vecteur de bits, et les opérations arithmétiques classiques sont donc recodées en opérations booléennes sur chaque bit. De plus, les expressions sont manipulées dans une forme canonique, ce qui permet de comparer simplement deux expressions (elles sont équivalentes ssi elles s’écrivent de la même manière dans leur forme canonique).

Interludes : {Scapy/Radare2} en 15 minutes

Guillaume Valadon et Julien Voisin présentent, en 15 minutes chacun, les fonctionnalités principales des outils scapy et radare2
Scapy est un outil permettant d’intercepter, disséquer, visualiser, modifier et rejouer des paquets réseaux via des commandes Python. Guillaume Valadon fait un tour des fonctionnalités de scapy en illustrant rapidement les applications possibles pour ce véritable couteau-suisse du réseau.
Radare2 est un framework de reverse engineering permettant de désassembler, extraire le graphe de flot de contrôle, débugger et patcher des binaires exécutables (et autres formats). Malgré son interface peu attrayante, Julien Voisin nous montre comment utiliser radare2 via la présentation d’un cas « pratique », pour reverser un shellcode polymorphique à 3h du matin.

Is Docker Secure ?

Manideep Konakandla, chercheur à l’Université Carnegie Mellon, présente une partie de ses recherches sur la sécurité de Docker, et montre les faiblesses dans la mise à disposition des images Docker et du moteur d’exécution Docker en lui-même.
En effet, Docker met à disposition une banque publique d’images, principalement maintenue par la communauté, de manière similaire à GitHub. Cependant, aucun processus de contrôle n’est en place afin de vérifier la légitimité du contenu des images hébergées. De plus, ces images ne sont pas mises à jour de manière suffisamment récurrente : lors de l’étude réalisée, 70% des images présentes sur la plateforme (et 30% des images officielles) étaient affectées par des vulnérabilités publiques.
De plus, la configuration par défaut de Docker est relativement peu sécurisée. En effet, les logiciels lancés dans les conteneurs s’exécutent avec les privilèges root. De plus, des mesures prévenant le déni de service font défaut : aucune limite de création de processus n’est en place, et la mémoire utilisable par un conteneur n’est pas limitée. Enfin, aucun cloisonnement réseau n’est en place par défaut : les conteneurs peuvent communiquer entre eux, et utilise le même pont réseau, laissant la possibilité aux conteneurs d’intercepter le trafic réseau à destination des autres conteneurs.
En conclusion, il est principalement recommandé de systématiquement appliquer un durcissement système sur les conteneurs utilisés, de n’utiliser que des images signées numériquement et de scanner régulièrement ses images à la recherche de composants vulnérables. Aussi, afin de limiter les risques en cas de compromission, il est une bonne pratique de regrouper des conteneurs par machine virtuelle en fonction de leur niveau de confiance. Enfin, des procédures de patch management, d’audit de sécurité, etc. doivent être appliquées au même titre que pour des systèmes classiques. 

Gorille : Another approach to binary analysis

Jean-Yves Marion, chercheur au LORIA (Laboratoire lorrain de recherche en informatique et ses applications) présente les résultats des recherches et outils développés par son laboratoire dans le domaine de l’analyse de binaire. 
Lors de l’analyse d’un malware, un des objectifs possibles peut être la classification, c’est-à-dire la découverte de similitudes avec des binaires connus. Cela permet par exemple de détecter le caractère malveillant d’un nouveau malware développé à partir d’une souche connue, ou bien de construire des signature plus précises en se basant sur plusieurs variantes d’un même malware.
Cependant, la plupart des codes malveillants utilisent des méthodes d’obfuscation de leur code, ou des techniques rendant complexe leur désassemblage à l’aide des outils les plus courants. Ces techniques permettent aux malwares d’éviter la détection par les solutions antivirales, et de rendre complexe leur analyse par un expert. Une technique commune d’obfuscation employée par les malwares consiste à stocker le code malveillant à exécuter sous forme chiffrée, et de le déchiffrer durant l’exécution du programme. Cette technique peut même être employée plusieurs fois pour un même programme de manière imbriquée (i.e. le code déchiffré permet de déchiffrer une autre partie code, etc…). Dès lors, il est assez évident qu’une simple analyse statique du binaire ne permet pas d’identifier le malware exécuté, ni d’en extraire un graphe de flot de contrôle (CFG).
Dans le cadre du projet CoDisasm, un outil du même nom a été développé afin de répondre entres autres à cette problématique d’obfuscation. L’outil exécute dans une sandbox et instrumente le programme à analyser, afin d’en extraire des « vagues » (« waves » dans le texte d’origine), c’est-à-dire des états du programme correspondant à chaque étape de la désobfuscation. Une extraction du CFG est alors réalisée sur chacune des variantes du binaire obtenues, en utilisant les traces d’exécution enregistrées pour guider le désassembleur.
Une fois le CFG du malware extrait, une abstraction de celui-ci est réalisée afin de pouvoir le comparer à celui d’autres binaires. En éliminant les parties CFG correspondant à des fonctionnalités inoffensives connues (ex. fonctions de la libc), l’outil Gorille est par exemple capable de détecter de manière entièrement automatisée que les vers StuxNet et Duqu partagent plus de 90% de similitude.

Improving dm-crypt performance for AES XTS mode through extended request

Levent Demir, doctorant à l’INRIA, présente les évolutions de travaux sur l’amélioration des performances de l’implémentation de l’algorithme AES-XTS.
dm-crypt est un système de chiffrement de disques inclus dans le noyau Linux depuis sa version 2.6 qui embarque des modes de chiffrement avancés tel que le XTS. Ce dernier, principalement utilisé dans des outils de chiffrement de disque, est un mode complexe incluant des opérations de XOR, chiffrements AES-ECB et multiplications dans un corps fini. Il s’agit du plus récent algorithme recommandé par le NIST pour le chiffrement de disques.
Etant un mode de chiffrement relativement récent, l’AES-XTS n’est pas supporté par les coprocesseurs cryptographiques présents dans la plupart des systèmes embarqués. C’est notamment le cas de la puce Atmel SAMA5D3, qui a servi de référence aux travaux menés. Le firmware de celle-ci a tout d’abord été modifié afin de supporter ce mode de chiffrement. 
De plus, une analyse du code source de l’outil dm-crypt a permis la découverte de limitations liées à des valeurs écrites en dur dans le code source, celles-ci n’ayant historiquement jamais été modifiées pour des raisons de compatibilité descendante. Une réimplémentation d’une partie de l’outil dm-crypt couplée à une modification du firmware Atmel ont ainsi permis une amélioration d’un facteur deux des performances de chiffrement.

Derniers mots

La conférence GreHack a de nouveau fait mentir son slogan ("New is not always better”) en réalisant une édition de qualité, en progression constante depuis son existence. Les sujets traités par les conférences étaient globalement d’un haut niveau technique, et touchaient des domaines variés de la sécurité, aussi bien pratiques que théoriques. L’aspect international de la conférence était encore une fois présent, marqué notamment par l’anglophonie des présentations et la variété des origines des speakers et intervenants.
Pour ma part, j’y ai passé une excellente journée, et serai ravi d’y retourner l’an prochain ! Merci au program committee de GreHack pour une sélection de conférences de qualité, à @commial et @serpilliere pour leur atelier épique sur Miasm (mélange très équilibré entre workshop technique et numéro de stand-up comedy), et enfin à l’association Securimag en charge l’organisation de l’évènement, et qui a réalisé un CTF de qualité (dans lequel il était notamment possible de se confronter la sécurité d’une … cabine téléphonique) !


Maxime Meignan

Focus sur les jetons JWT

Introduction

JWT (JSON Web Token) définit dans la RFC 7519 est un standard permettant la transmission d’information entre deux parties via l’utilisation d’objets JSON. JWT repose sur les standards JSON Web Signature (JWS) et JSON Web Encryption (JWE) permettant d’assurer l’intégrité et / ou la confidentialité des données transmises. En pratique, les jetons JWT sont principalement utilisés afin de sécuriser l’accès à des Web services REST ou encore comme solution de SSO.

Exemple d’utilisation des jetons JWT dans le cas d’un SSO :

L’utilisation de jetons JWT permet la mise en place d’application « stateless» et ainsi supprimer la dépendance des sessions. Ainsi la mise en place de ce type de jeton est souvent vue comme une protection contre les attaques CSRF.

Format

Les jetons JWT sont constitués de différentes parties chacune séparée par le caractère point « . ». Bien que le nombre de parties puisse varier, les jetons JWT sont souvent constitués de trois parties : 

Figure 3 : Format d’un jeton JWT
  • Entête : permet de déclarer que le format JWT est utilisé et de préciser l’algorithme (et potentiellement ses paramètres) utilisé pour la signature numérique et / ou le chiffrement.
{
  "alg": "HS256",
  "typ": "JWT"
}
  • Charge utile : représente l’objet à transmettre au format JSON. Il peut posséder différents attributs / affirmations dont certains sont définis par la RFC (iss, sub, iat, exp…) :
{
  "sub": "1234567890",
  "name": "anonymous",
  "society": "Wavestone",
  "email": "anonymous@wavestone.com",
  "isadmin": false
}
  • Signature : cette partie permet  au destinataire du jeton de pouvoir vérifier l’intégrité du message ainsi que l’identité de l’émetteur :
35cbb7559f29a26e1220983cc059965eadd005d6deeba450a05b70bcfe52eae3
La signature du message est calculée de la façon suivante :
key           = 'laclesecrete'
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)
signature     = HMAC-SHA256(key, unsignedToken)
Ensuite, l’ensemble des parties sont encodés en base64 (en mode URL compatible et sans les caractères « = » de bourrage) et concaténée (séparées par le caractère « . ») pour être transmise dans les requêtes. Pour l’exemple précédent, le jeton JWT encodé est le suivant :
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFub255bW91cyIsInNvY2lldHkiOiJXYXZlc3RvbmUiLCJlbWFpbCI6ImFub255bW91c0B3YXZlc3RvbmUuY29tIiwiaXNhZG1pbiI6ZmFsc2V9
.
Ncu3VZ8pom4SIJg8wFmWXq3QBdbe66RQoFtwvP5S6uM

Cryptographie

Afin d’assurer la sécurité (authentification, confidentialité, intégrité) des données transmises, le standard JWS s’appuie sur les standards JWS et JWE.

Signature

Le standard JWA définit les algorithmes de signature numérique et MACs pouvant être utilisés, le standard JWT n’impose que le support des suivants :
  • None
  • HS256 : HMAC-SHA-256
Cependant, les algorithmes asymétriques suivants sont supportés par les principales implémentations :
  • RS256: RSA (PKCS1-v1.5) et SHA-1
  • ES256: ECDSA (P-256) et SHA-256

Chiffrement

Le support du chiffrement pour les jetons JWT est optionnel, les algorithmes les plus souvent supportés sont les suivants :
  • RSA1_5 : RSA (PKCS1-v1_5) et AES
  • A128CBC-HS256 : AES-CBC et HMAC-SHA2

Sécurité

Algorithme « none »

Alors que les algorithmes de chiffrement et de signature supportés sont majoritairement robustes, le support de la méthode « None » par les serveurs représente un réel risque. En effet, si cette méthode est considérée comme valide par le client JWT alors un attaquant est en capacité de forger ou d’altérer le contenu d’un message.
Dans l’exemple ci-dessus, il faudrait alors modifier l’entête :
{
  "alg": "none",
  "typ": "JWT"
}
Le jeton transmis serait le suivant :
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6ImFub255bW91cyIsInNvY2lldHkiOiJXYXZlc3RvbmUiLCJlbWFpbCI6ImFub255bW91c0B3YXZlc3RvbmUuY29tIiwiaXNhZG1pbiI6ZmFsc2V9
.

Attaque par recherche exhaustive

L’ensemble de la sécurité des jetons JWT repose sur la confidentialité de la clé de chiffrement. Bien qu’aucune attaque efficace ne soit connue, un attaquant pourrait tenter de la récupérer par recherche exhaustive. Pour les modes HMAC, il est alors possible d’utiliser l’outil John jumbo afin d’effectuer ce type d’attaques en mode « hors connexion ».
Afin de faciliter ce type d’attaque, nous avons développé un script prenant en entrée un jeton JWT et fournissant en sortie un format utilisable par John jumbo.

Lors d’un test d’intrusion, nous avons également été surpris de pouvoir valider un jeton JWT obtenu auprès de l’application testée sur le site jwt.io :

Il se trouve que le secret utilisé par l’application pour signer les jetons avait une valeur par défaut, à savoir « secret »…. Importance du choix de l’algorithme de signature / chiffrement
Dans une architecture utilisant des jetons JWT, les clients ont besoins de connaitre :
  • La clé partagée : si un algorithme symétrique est utilisé (HMAC, AES…) ;
  • La clé publique : si un algorithme asymétrique est utilisé (RSA, ECDSA…).
Par conséquent, en cas d’utilisation d’un algorithme symétrique, les clients (service providers…) sont aussi en capacité de signer / chiffrer un jeton ; en cas de compromission d’un client par un attaquant, ce dernier pourrait alors tenter de compromettre la totalité de l’infrastructure (via la construction de jetons spécifiques). Ainsi, il est préférable d’utiliser des algorithmes de chiffrement asymétriques s’il n’est pas nécessaire que les clients (service providers…) puissent signer des jetons.

Vérification de la signature

La vérification de la signature est une étape sensible et doit ainsi être correctement implémentée. En 2015, une vulnérabilité permettant sur l’implémentation des mécanismes de vérification de signature affectant de nombreux composants (node.js, pyjwt, php-jwt...) a ainsi été signalée par Tim McLean. Sous certaines conditions, cette vulnérabilité permettait alors à un attaquant d’utiliser une clé publique RSA afin de signer un jeton via HMAC et ainsi de pouvoir générer des jetons acceptés par les applications clientes.

Dangers du stockage local

Certaines applications conservent les jetons localement afin de pouvoir les utiliser ultérieurement via l’utilisation de code côté client (JavaScript…) notamment pour les applications « stateless » dont la taille des jetons est importante. Alors que les cookies sont protégés par les attributs « secure » et « httpOnly », les jetons manipulés par le JavaScript ne possèdent quant à eux aucun attribut de sécurité et sont ainsi vulnérable à des attaques de type vol de session (pas d’équivalent de « httpOnly ») ou encore transmission des jetons sur des canaux non sécurisés (pas d’équivalent de l’attribut « secure »).

Conclusion

L’utilisation de jeton JWT permet d’augmenter la sécurité des Web services via la mise en place de certains mécanismes cryptographiques. Cependant, la sécurité ne pourra être assurée qu’à condition de définir les différents éléments en fonction de leurs cas d’usage. Il sera ainsi nécessaire de :
  • Utiliser des clés de taille suffisamment grande ;
  • Adapter les algorithmes cryptographiques utilisés au contexte de l’application (SSO, Web service unique…) ;
  • Mettre en place des mécanismes anti-rejeu (limiter la durée de vie des sessions…) ;
  • Prévoir des mécanismes d’invalidation de jeton ;
  • Conserver les clés de chiffrement de manière sécurisée.
Ressources :
Mahdi BRAIK

Compte-rendu de la BotConf 2016

La quatrième édition de la BotConf se tenait cette année du 30 novembre au 2 décembre, à l’université Lyon 2. Cette conférence, orientée sur la lutte contre les botnets, a regroupé une vingtaine de présentations en anglais dont voici un bref compte-rendu.

Locky, Dridex, Necurs: the evil triad

Après une introduction d’Éric Freysinnet, Jean-Michel Picot, de Google, a présenté la façon dont les malwares sont perçus du point de vue de Gmail. Une grande partie de la présentation fut dédiée aux techniques utilisés par ces malwares pour éviter la détection. La présentation étant identifiée comme confidentielle, les détails ne seront pas divulgués dans cet article.

Visiting the Bear’s Den

Jessy Campos de la société ESET, prit alors la parole pour présenter son travail, ainsi que celui de Joan Calvet et Thomas Dupuy qui étaient absents, concernant le groupe d’attaquants connu sous le nom de Sednit, ou encore APT28, Fancy Bear, Sofacy, et bien d’autres. Le groupe Sednit vise principalement des personnes impliquées dans la vie politique d’Europe de l’est. Les capacités des personnes qui composent le groupe sont très avancées, preuve en est l’utilisation de nombreuses 0-days et d’un outillage bien fourni.

Au travers de l’histoire de Serge, une cible imaginaire du groupe Sednit, Jessy Campos a présenté le déroulement d’une attaque, ainsi que les différents outils que son équipe et lui ont pu analyser.

Lundi, 9h30, Serge ouvre un email, et clique sur un lien dont l’URL ressemble fortement à une URL légitime. Malheureusement pour lui, il fait alors la rencontre de SEDKIT. SEDKIT est un Exploit Kit utilisé pour la première fois en septembre 2014, et encore actif de nos jours. Généralement transmis par le biais d’un mail de phishing, l’outil permet aux membres de Sednit de sélectionner leurs cibles.
Imitation d’URLs légitimes dans les mails de phishing
Une fois la cible choisie, SEDKIT va alors télécharger SEDUPLOADER, un outil composé de deux parties, un dropper et une charge malveillante, aperçu pour la première fois en mars 2015, et étant toujours actif. Au travers d’un workflow en quatre étapes durant lesquelles de nombreuses techniques sont utilisées, SEDUPLOADER va télécharger SEDRECO.

Workflow suivi par SEDUPLOADER
Lundi, 10h, Serge est donc infecté par SEDRECO. Cette backdoor, vu pour la première fois en 2012, et toujours active, a la capacité de charger des plugins externes. C’est la configuration de cette charge malveillante, présente dans un fichier « .msd » chiffré, qui va donc définir les actions de SEDRECO, avec toujours pour objectif l’espionnage des actions effectuées sur le terminal infecté.
Extrait des fonctionnalités proposées par SEDRECO
SEDUPLOADER va également permettre le téléchargement de l’outil XAGENT, une backdoor modulaire disposant de versions pour Windows, Linux et iOS, généralement déployée par le groupe Sednit après la phase de reconnaissance. Cet outil va alors permettre l’extraction d’informations jusqu’au serveur C&C par le biais de mails dont l’objet, le contenu, ainsi que les pièces jointes se doivent de sembler le plus légitime possible.
Schéma d’extraction des données par XAGENT
À partir de ce moment, les différentes informations et actions de Serge sont enregistrées et envoyées au serveur C&C. Différents codes malveillants permettent ainsi l’extraction des mots de passe, mais également la prise de captures d’écran à chaque déplacement de souris. De plus, l’outil XTUNNEL permet les mouvements latéraux au sein du Système d’Information de Serge.
Mouvements latéraux effectués par XTUNNEL
L’arsenal de Sednit contient également de nombreux moyens de persistance que Jessy Campos a pu détailler lors de sa conférence.
Le support de présentation, ainsi que des papiers de recherche sur le groupe, sont disponibles aux adresses suivantes pour de plus amples informations :


LURK – The story about Five Years of Activity

Vladimir Kroporov de Trend Micro a alors présenté un autre groupe d’attaquants que lui et Fyodor Yarochkin, de l’académie Sinica, ont pu étudier. Ce groupe, qui vise principalement la Russie à l’aide du banking trojan LURK, est actif depuis de nombreuses années. LURK a en effet été détecté pour la première fois en 2011, et est le premier malware à intégrer une charge malveillante directement en mémoire, ce qui rend complexe sa détection, mais implique l’absence de persistance.

Vladimir Kroporov a présenté les différents patterns permettant la détection de LURK, ainsi que l’infrastructure, les méthodes, et l’évolution du malware. Les supports de présentation peuvent être trouvés à l’adresse suivante :

Browser-based Malware: Evolution and Prevention

Ce fût ensuite au tour de Andrey Kovalev et Evgeny Sidorov, travaillant pour Yandex, d’effectuer leur présentation sur les attaques de type Man-in-the-Browser utilisées par certains malwares. Ce type d’attaques consiste à intercepter et détourner les appels entre le navigateur et ses mécanismes de sécurité. Les attaques de ce type proviennent principalement d’extensions, de proxy WFP, ou encore de VPN.
Principe de fonctionnement d’une attaque Man-in-the-Browser
La suite de la présentation fût consacrée à la présentation des malwares Eko et SmartBrowse. Eko est une extension malveillante pour Chrome. Pour parvenir à faire installer cette extension à d’autres cibles, Eko utilise la technique précédente pour envoyer aux contacts des messages privés Facebook contenant un lien vers cette extension. Une fois le navigateur infecté, Eko va récupérer les accès au compte Facebook de l’utilisateur.
Architecture du malware Eko
SmartBrowse est également une extension Chrome malveillante qui sert de plateforme pour l’installation d’autres malwares. L’une des fonctionnalités de SmartBrowse est qu’il parvient à passer outre le mécanisme de sécurité interdisant l’installation d’extensions.
Architecture du malware SmartBrowse
Concernant la détection et la protection de ce type d’attaque, les techniques sont limitées. L’utilisation de Content-Security-Policy, habituellement utilisé pour limiter les attaques de type XSS, est une première approche mais peut être contrôlé par les extensions. Une autre approche est la validation de l’intégrité du code en JavaScript. Cette méthode est plus complexe à contourner pour les malwares, étant donné que la suppression du script de détection risque de limiter les fonctionnalités de la page.
Le support de présentation est disponible à l’adresse suivante :



Language Agnostic Botnet Detection Based on ESOM and DNS

Cette présentation, effectuée par Rocco Mandrysh de RUAG, présente les travaux qu’il a effectué avec Christian Dietz, Urs Anliker et Gabi Dreo, à propos d’une méthode de détection des malwares à partir de noms de domaine. Les malwares, comme l’explique Rocco Mandrysh, utilisent souvent des algorithmes de génération de noms de domaine (DGA) qui, si leur fonctionnement peut être déduit à partir des exécutables, pourraient permettre de générer la liste des domaines possiblement utilisés par un malware donné, créant ainsi une liste d’IOC complète.
L’approche de Rocco Mandrysh et de ses collègues vient compléter cette pensée en présentant une méthode par machine learning, permettant de regrouper les malwares sur une carte en utilisant l’outil ESOM, facilitant ainsi leur identification.
Exemple de sortie d’ESOM
Le support de présentation est disponible à l’adresse suivante :

 

Vawtrak Banking Trojan: A threat to the Banking Ecosystem

Raashid Bhat et Victor Acin, de l’entreprise Blueliv, ont présenté leurs travaux d’analyse sur le malware Vawtrak. Ce malware, historiquement nommé Neverquest, a été observé pour la première fois en 2013 et a beaucoup évolué depuis. C’est un cheval de Troie à visée financière qui utilise des techniques avancées de type Man-in-the-Browser pour parvenir à récupérer les identifiants des utilisateurs infectés.
Le support de présentation, ainsi que l’analyse technique du malware, sont accessibles aux URLs suivantes :

Snoring Is Optional: The Metrics and Economics of cyber Insurance for Malware Related Claims

Wayne Crowder, travaillant chez Risk Analytics, a effectué une présentation non technique sur les botnets, en prenant le point de vue des cyber-assurances. Cette présentation, reprend les différents éléments qui composent une bonne cyber-assurance, ainsi que de nombreux exemples et chiffres d’attaques passées.
Le support de présentation est disponible à l’URL suivante :
 

Hunting Droids from the Inside

Lukasz Siewierski, également de Google, a conclu la première journée en présentant différentes méthodes utilisées par les botnets Android. Cette présentation étant également confidentielle, les détails ne seront pas présentés dans cet article


Ransomware and Beyond

Pour entamer le deuxième jour de conférence, Christiaan Beek travaillant chez Intel Security a choisi de parler de ransomwares, et notamment de leur évolution cette année. Après une brève introduction sur les différentes familles de ransomwares en 2015, ainsi que sur l’intérêt grandissant pour le terme dans les recherches Google cette même année, Christiaan s’est donc concentré sur une année qui a vu de nombreuses évolutions chez les ransomwares : 2016.
Le nombre de ransomwares, mais également les techniques utilisées par cette famille de malware a en effet grandement évolué cette année, avec des exemples comme Petya et Mamba qui réalisent respectivement un chiffrement partiel (MBR) et complet du disque.
Évolution des techniques utilisées par les ransomwares ces derniers mois
Christiaan a ensuite continué sa présentation en expliquant pourquoi les ransomwares sont tant utilisés. L’un des arguments qu’il a évoqué est notamment la « satisfaction client », qui peut paraitre étonnant pour un malware, mais s’applique parfaitement pour la sous famille des ransomwares. En effet, il n’est pas rare de voir sur les forums des messages de remerciement écrits par les victimes et à destination des attaquants, expliquant qu’ils ont bien reçu la clé de déchiffrement après avoir payé. Certains ransomwares proposent même de poser directement des questions aux attaquants, même s’il semble assez rare que des négociations aboutissent.
Exemple de page de contact provenant d’un ransomware
Enfin, Christiaan a présenté sa démarche d’utilisation du machine learning dans l’objectif d’améliorer la détection et le classement des ransomwares, pour enfin finir par la présentation de la plateforme « No more ransom ! » dont l’objectif est la mise à disposition par les professionnels de techniques de déchiffrement adaptées aux ransomwares.
Page d’accueil du site nomoreransom.org
Le support de la présentation est disponible à l’adresse suivante :


Attacking Linux/Moose 2.0 Unraveled an EGO MARKET

La seconde présentation de la journée fût celle d’Olivier Bilodeau et Masarah Paquet-Clouston travaillant chez GoSecure, qui présentaient leurs travaux de recherche sur le botnet Linux/Moose. Ce sujet, qui avait déjà été abordé en 2015, fût largement orienté sur les cibles et le marché du botnet.
Le support de présentation ainsi qu’un article complémentaire sont disponibles aux adresses suivantes :

Tracking Exploit Kits

John Bambenek, travaillant pour Fidelis Cybersecurity, a ensuite effectué une présentation sur la traque des Exploit Kits. L’objectif d’une telle traque est la mise à mal de l’écosystème qui tourne autour des Exploit Kits. John a présenté différentes techniques et outils pouvant faciliter cette démarche, comme par exemple l’outil ekdeco ou encore le site contagiodump.blogspot.fr.

Le support de présentation est accessible à l’adresse suivante :

Improve DDoS Botnet Tracking With Honeypots

La présentation suivante, effectuée par Ya Liu, du laboratoire de recherche en sécurité réseau de Qihoo 360 avait pour objet l’utilisation de honeypots dans la traque des botnets, et notamment l’identification de familles de botnets à l’aide des algorithmes de génération de paquets (PGA).
Le support de la présentation est disponible à l’adresse suivante :

Function Identification and Recovery Signature Tool

Angel Villega a conclu la matinée en présentant l’outil FIRST, un plugin IDA permettant l’identification de fonctions partagées par de multiples échantillons de malware. Les analystes pourraient donc rapidement identifier des fonctions déjà étudiées, automatisant ainsi les tâches répétitives. Le plugin se base sur une base de données qu’il est possible d’héberger sur un serveur en interne, et un serveur publique est déjà disponible : first-plugin.us.
Le support de présentation est accessible à l’adresse suivante :
 

Advanced Incident Detection and Threat Hunting using Sysmon (and Splunk)

Tom Ueltschi, qui travaille au CERT de la poste Suisse, a ensuite détaillé l’utilisation de Sysmon et Splunk comme outils de détection. Deux types de détection sont importantes sur un environnement : les détections au niveau réseau et les détections basées sur l’hôte. Pour Tom, les meilleurs outils pour effectuer ces détections sont Bro du côté réseau, et Sysmon et Splunk pour les éléments présents sur l’hôte.
L’un des avantages majeurs de Sysmon est qu’il fait partie de la suite SysInternals qui est gratuite et adaptée aux environnements de Microsoft. Son déploiement et son intégration sont alors aisés. Sysmon permet ainsi de récupérer les événements du journal d’événements Windows et, à l’aide de règles adaptées qu’a pu développer Tom (notamment pour limiter le nombre d’événements envoyés à Splunk afin de limiter le coût de licence), remonter des alertes en cas de comportement malveillant.
La difficulté majeure lors de l’installation de ces outils est la création de règles adaptées pour isoler les événements malveillants des événements légitimes. Le poster du SANS dédié à ce sujet (https://www.sans.org/security-resources/posters/dfir/dfir-find-evil-35) peut être un bon point de départ pour parvenir à un résultat cohérent.
Durant sa présentation, Tom a mis l’accent sur trois événements majeurs :
  1. La création de processus
  2. La création de connexions réseaux
  3. L’utilisation de la fonction CreateRemoteThread
Il a ainsi pu présenter différents exemples et conseils permettant une détection efficace.

How Does Dridex hide Friends

Sébastien Larinier et Alexandra Toussaint de Sekoia, ont ensuite présenté les analyses qu’ils ont effectué pour l’un de leur client. Cette analyse, qu’ils ont pu détailler, s’est soldée par la conclusion que le système était infecté par Dridex. En continuant l’analyse, ils ont cependant pu découvrir d’autres éléments suspects, notamment l’installation d’un RAT (malware permettant un accès à distance) sur le système infecté.

A Tete-a-Tete with RSA Bots

Puis, ce fût au tour de Jens Friess et Laura Fuevara de Fraunhofer de présenter une approche automatique pour l’analyse de communications chiffrées. Pour cela, ils utilisent un faux serveurs C&C muni d’un certificat adapté ainsi qu’un serveur DNS pour pouvoir analyser les requêtes et en déduire la clé de déchiffrement.

Le support de présentation est accessible à l’adresse suivante :

Takedown client-server botnets the ISP-way

Après une petite pause, ce fût au tour de Quang Tran de Viettel d’effectuer une présentation sur une méthode de lutte contre les botnets. Travaillant pour un fournisseur d’accès Internet vietnamien, Quang Tran a orienté ses recherches sur le monitoring du trafic dans l’objectif de découvrir les noms de domaine utilisés par les botnets, puis de les remplacer par de faux serveurs C&C envoyant des commandes d’arrêts aux malwares. Une remarque intéressante a cependant été levée lors de la séance de question/réponse, à savoir que cette méthode est illégale dans de nombreux pays.
Le support de présentation est disponible à l’adresse suivante :

Detecting the Behavioral Relationships of Malware Connections

Une autre approche d’automatisation pour la détection des botnets, basée sur le machine learning, a été présentée par Sebastian Garcia, de l’université CTU à Prague. L’idée de Sebastian est que les IoC ne sont souvent pas suffisant pour détecter de nouveaux malwares, ou des versions évoluées de malwares connus. Pour pallier à cela, il utilise les connexions effectuées par un utilisateur pour créer un modèle différentiant une activité suspecte d’une activité normale.
Une représentation sous forme de graphes peut alors être faite et, en fonction du nombre de nœuds, de liens, et surtout du pourcentage de liens répétitifs en fonction du nombre total, il parvient à isoler les comportements suspects.
Exemple de graphe obtenu pour le ransomware Cerber
Le support de présentation est accessible à l’adresse suivante :


Analysis of Free Movies and Series Websites Guided by Users Search Terms

La dernière présentation de cette seconde journée fût effectuée par Martin Clauß et Luis Alberto Benthin Sanguino de Fraunhofer, qui ont détaillés leurs recherches sur l’utilisation des sites proposant le téléchargement et le streaming de films et séries par les attaquants. L’idée de leurs recherches était de collecter les URLs visités lors de la navigation sur ces sites pour déterminer s’ils étaient malveillants. L’étude, qui a été faite sur des sites proposant du contenu en différentes langues, révèle que les sites proposant ce genre de contenu en allemand sont le plus rarement malveillants, alors que les sites espagnols le sont le plus souvent.
Le support de présentation est disponible à l’adresse suivante :

Nymain Origins, Revival and Reversing Tales

Pour entamer la dernière journée de la conférence, Alberto Ortega, travaillant chez Fox-IT, a choisi de partager l’analyse qu’il a pu effectuer sur le malware Nymaim. Il a ainsi pu présenter les nombreuses techniques avancées, notamment d’obfuscation et anti-analyse, utilisées par ce malware découvert en 2013 et qui utilise des attaques de type Man-in-the-Browser pour effectuer des transactions bancaires illégitimes.

Le détail de son analyse est accessible à l’adresse suivante :

Rough Diamonds in Banking Botnets

Travaillant également chez Fox-IT, Jose Miguel Esparza et Frank Ruiz ont continué en présentant leurs recherches sur les interfaces utilisées par les attaquants pour contrôler leurs malwares. Cette présentation étant classée TLP:RED, elle ne sera pas détaillée.

ISFB, Still Live and Kicking

Maciej Kotowicz du CERT polonais prit alors la parole pour présenter son analyse du malware ISFB. Ce malware découvert en 2014 est l’un des chevaux de Troie à visée financière les plus populaires de nos jours. Tout comme les autres malwares présentés, il utilise des techniques avancées qu’a pu présenter Macjej.

Le support de la présentation est accessible à l’adresse suivante :

Challenges for a cross-juridictional botnet takedown

Margarita Louca a ensuite présenté l’un des plus gros défis rencontrés par Europol ces dernières années, et ce avec une approche juridique. Sa présentation est cependant confidentielle.

Preventing File-Based Botnet Persistence and Growth

Kurtis Armour a alors parlé de méthodes efficaces de protection d’un environnement. Les malwares récents utilisant de plus en plus de scripts (JavaScript, Powershell, etc.) en tant que charge malveillante, les détections basées sur les exécutables ne sont plus suffisantes. Kurtis a ainsi présenté différentes méthodes d’implémentation de listes blanches et de configuration permettant de se protéger contre ces nouvelles menaces.

Quelle que soit sa forme, le code malveillant doit être exécuté par le système. L’objectif de Kurtis est donc d’empêcher cette exécution par les charges malveillantes. Une règle d’or pour cela étant de ne pas posséder de droits d’administration sur le système, limitant ainsi les possibilités du malware. Mais différents autres outils peuvent également être utilisés pour réduire la surface d’attaque. C’est par exemple le cas de LAPS de Microsoft qui permet la gestion des comptes administrateurs locaux sur un domaine Windows.

Différentes méthodes permettant de limiter l’utilisation de Powershell ont également été abordées, l’utilisation des Local Security Policies ou Execution Policies n’étant pas la solution. Enfin, AppLocker est un autre outil qui peut permettre de bloquer ce type de comportement, comme par exemple l’utilisation de macros en empêchant l’exécution de dll depuis le dossier VBA.

Le support de présentation est accessible à l’adresse suivante :

Dridex Gone Phishing

Pour terminer cette quatrième édition de la BotConf, Magal Baz et Gal Meiri d’IBM ont détaillé les méthodes de type Man-in-the-Browser utilisées par Dridex pour effectuer sa fraude bancaire. Pour cela, le malware intercepte en effet les appels aux fonctions d’entrée et de sorties du navigateur, afin de dupliquer les données, les envoyant à la fois au site légitime de la banque, mais également au serveur contrôlé par les attaquants. Dridex peut alors modifier les requêtes qui lui sont nécessaires, et en créer de nouvelles pour vider le compte en banque de l’utilisateur. Une manière simple de se protéger semble être de renommer l’exécutable du navigateur (firefox_renamed.exe à la place de firefox.exe par exemple), rendant ainsi inefficace le malware qui se base sur ces noms pour trouver les navigateurs à compromettre.

BotConf 2017

Eric Freysinet a conclu en annonçant la cinquième édition de la BotConf qui aura lieu à Montpellier du 5 au 8 décembre 2017.
Nicolas DAUBRESSE