Wavestone SecurityInsider

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

« 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

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.

Nous avons assisté à l’édition 2017 de la JSSI (Journée de la Sécurité des Systèmes d’Information), organisée par l’OSSIR (Observatoire de la Sécurité des Système d’Information et des Réseaux), qui s’est tenue le 14 Mars 2017 au FIAP Jean Monet.
Comme les années précédentes, elle était composée de huit présentations articulées autour d’un thème, cette année : « Fuites de données: s’en protéger, les détecter, les gérer».

Introduction : information/fuites d’information par Jean-Philippe GAULIER (Orange)

Jean-Philippe GAULIER, président de l’OSSIR et RSSI au sein de la DSI d’Orange, a ouvert cette JSSI. Suite à quelques mots en tant que président de l’OSSIR et un rappel des activités de l’association, il a introduit le thème de cette année.
Il nous a invités dans un premier temps à réfléchir autour des données, en insistant sur leur circulation massive aujourd’hui. L’exemple de celles que nous exposons via les réseaux sociaux auxquels nous adhérons a notamment été pris. Ces données, d’une richesse incroyable pour qui les exploite, sont convoitées et deviennent donc des cibles.
L’intervenant a appuyé son propos en citant de grands cas de fuites de données : Sony, Ashley Madison, cas de Julien Assange, Edward Snowden ou Kim Schmitz (fondateur et ancien PDG de Megaupload).
Il a enfin souligné le fait que l’Humain est au cœur de l’ensemble de ses fuites de données, qu’il en soit l’auteur, la victime ou le gestionnaire de sa résolution.

La face cachée de la XXE (XML eXternal Entity) par Charles FOL (Ambionics Security)

L’intervenant nous a présenté ici les attaques de type XXE, XML External Entity.
Ces entités sont définies dans la DTD (DOCTYPE) XML, et agissent comme des variables permettant de faire référence à des contenus locaux ou externes.
Si exploitée à ces fins, elles sont potentiellement sources de différentes attaques (lecture illicite de fichiers locaux, rebond http, déni de service…) avec extraction des données possible in-band (affichage des données) ou out-of-band (sortie en http, ftp…).
L’intervenant a alerté sur le fait que l’utilisation du XML est largement répandue :

Dans des protocoles applicatifs : XML, SVG, HTML
Mais également dans les documents bureautiques : DOCX (Office), PDF, XMP (Adobe)

Il a également insisté sur le fait que les vulnérabilités liées aux XXE sont bien réelles, en citant quelques exemples de Bug bounties en lien notamment.
Un exemple d’exploitation a été donné, puis l’intervenant a conclu sur les protections possibles :

Désactiver les DTD
Utiliser d’autres formats de données que XML

Présentation complète

Règlement RGDP, Quel impact sur la « sécurité » des données ? par Eric BARBRY (Alain Bensoussan Avocats - Lexing)

Eric BARBRY fut le troisième intervenant de cette journée, sur le sujet de la réglementation européenne GDPR (General Data Protection Regulation), visant à renforcer et unifier la protection des données à caractère personnel des citoyens européens. Elle sera mise en application le 25 Mai 2018.
Dans les débuts de son intervention, il a notamment insisté sur les impacts qu’auraient un non-respect de la réglementation. Un accent a été mis sur les pénalités financières qui seront mises en place : de 10 à 20 M€ ou 2 à 4% du chiffre d’affaire mondial pour les entreprises, selon les cas de manquement. Il a poursuivi en soulignant le fait que la mise en conformité engendrerait de nombreux chantiers, impactant notamment fortement DSI et RSSI.
C’est l’angle qu'il a choisi pour la suite de l'intervention, donnant son analyse des articles qu’il juge les plus impactants pour ces derniers, déclinés en quatre chantiers :

Sécurité des données :

Protection des données by design et by default (article 25) : ce qui implique la mise en place de mécanismes techniques ou organisationnels pour protéger les données dès le départ, et par défaut (schémas d’accès aux données, politiques d’habilitations, supervision des accès…).
Obligation de sécurisation (article 32) : cet article s’applique au responsable de traitement et à ses sous-traitants. Ce qui imposera au responsable de traitement de définir précisément ses exigences de sécurité en amont et de regarder ce qui se passe chez ses sous-traitants.
Obligation de notification (article 33) : la CNIL devant être notifiée sous 72h en cas de fuite, le processus devra être défini en amont. En particulier avec les sous-traitants qui devront informer le commanditaire en cas de fuite pour que ce dernier porte la notification à la CNIL.
Obligation de communication (article 34) : individuelle notamment, à toutes les personnes impactés.

Analyse d’impact et consultation (article 35 et 36) : une analyse d’impact devra être réalisée systématiquement dans le cadre de certaines activités (profilage, traitement à grande échelle de données sensibles…). Elle permettra entre autres d’identifier les traitements permettant de réduire les risques. Un fois réalisée, une consultation préalable à la mise en place des traitements identifiés peut être demandée à la CNIL. Celle-ci rendrait un avis « préalable » sous huit semaines.
Sous-traitance (article 28) : une définition et une maîtrise fine des contrats et activités des sous-traitants seront exigées.
Gouvernance des données : non abordé lors de l’intervention faute de temps

Présentation complète

Retour d'expérience sur la gestion d'une fuite de données majeure par Stéphane PY (Orange)

Lors de cette intervention, Stéphane PY, RSSI adjoint à la DSI d’Orange France, nous a présenté un retour d’expérience sur la gestion de la fuite de données personnelles qu’a connu Orange France en janvier 2014.
L’intervenant nous a détaillé la chronologie de la crise, depuis le constat des attaques le 12 janvier à la fin de la crise le 06 février en passant par la déclaration CNIL (25 jours au total). Il a également insisté sur la chronologie du passage en situation de crise, déterminé par l’impact dans le cas présenté, et ses conséquences (organisation, mise à disposition de compétences et moyens).
Stéphane PY a ensuite détaillé les activités traitées lors de cette crise et donné les retours tirés pour chacune :

Analyse de l’attaque et conséquences
Identification des impacts
Gestion de la relation client
Communication externe et interne
Gestion de la crise
Bilan et enseignements
Sujets connexes. Sur ce dernier point, l’intervenant a insisté sur le fait que les actions post crise peuvent se prolonger longtemps, parfois plusieurs mois après sa fin

En conclusion, Stéphane PY nous a rappelé l’importance d’une bonne préparation à la gestion de crises, que ces situations touchent toute l’entreprise et qu’elles imposent des contraintes de délais de déclaration et d’informations des clients très lourdes. Enfin, il a conclu en insistant sur l’étape du bilan, primordiale pour tirer des enseignements sur l’ensemble des aspects.

Présentation complète

Détection d'une fuite de données, Gestion de crise, et Plan d'action pour revenir à une situation normale par Marc-Frédéric GOMEZ (CERT-AG)

Conformément à la volonté de l’intervenant, les slides de cette intervention ne sont pas publiés et nous ne résumerons pas son contenu.

Bug Bounty as a Service par Guillaume VASSAULT-HOULIERE (YesWeHack)

Lors de son intervention, Guillaume VASSAULT-HOULIERE a présenté les origines du Bug Bounty et les plateformes existantes dont celle de YesWeHack, dont il est l’un des présidents fondateurs.
Il nous explique qu’à l’origine deux grandes solutions existaient pour remonter des vulnérabilités découvertes : soit directement aux Entreprises (qui pouvait très mal le prendre et attaquer le lanceur d’alerte), soit en rendant la vulnérabilité publique et en publiant l’exploit.
Netscape fut le premier à tenter l’aventure du Bug Bounty, en organisant un challenge en 1995 récompensant (par des T-shirts) les chercheurs remontant des vulnérabilités.
Il faudra attendre que les GAFAM s’y mettent, entre 2010 et 2012, pour voir le concept démocratisé, les chercheurs sont alors récompensés pour la découverte de failles. Depuis, plusieurs entreprises se sont lancées à leur tour dans le concept : Tesla (2015), Uber (2016)…
L’intervenant est ensuite passé à une présentation des plateformes de Bug Bounty as a Service existantes. Celles-ci se placent en intermédiaires entre les « White Hat» et les commanditaires. Il a souligné l’importance de la définition du cadre, et de la gestion et animation de la communauté pour que la plateforme vive. La complémentarité de cette activité par rapport aux audits a également été soulignée.

Présentation complète

Extraction hors-ligne des secrets protégés par la DPAPI par Jean-Christophe DELAUNAY (Synacktiv)

L’avant dernière conférence, animée par Jean-Christophe DELAUNAY, portait sur la DPAPI (Data Protection Application Programming Interface) qui sert à protéger les secrets sous Windows. Apparue avec Windows 2000, la structure de cette Data Protection API n’a pas subi d’évolutions majeures depuis.
Ses actions de protection sont réalisées de manière transparente pour les utilisateurs, et pour un certain nombre de leurs secrets (mots de passe Wifi, gestionnaires de mots de passe Windows, Internet Explorer, Chrome…). Son utilisation massive s’expliquerait par sa facilité d’implémentation pour les développeurs (deux fonctions à connaître pour son utilisation : CryptProtectData et CryptUnprotectData).
L’intervenant a ensuite détaillé le mode de fonctionnement de DPAPI et notamment sa cryptographie, basée entre autres sur le mot de passe de l’utilisateur.
L’intervenant a ensuite présenté les outils existants pour les tests d’intrusion et le forensic (passcape, impacket, mimikatz, dpapick, dpapilab), en faisant un focus sur son propre outil, dpapeace. L'outil présenté n'est actuellement pas publié.

Présentation complète

Big data : sécurité des environnements Hadoop par Mahdi BRAIK (Wavestone)

Mahdi BRAIK fut le dernier intervenant de cette journée, sur le sujet du modèle de sécurité des environnements Hadoop.
Il a commencé par expliquer ce qu’est Hadoop (un framework open-source permettant le traitement distribué de jeux de données volumineux au sein d’un cluster de serveurs en utilisant des modèles de programmation simples) et son principe de fonctionnement.
Il a ensuite pointé le fait que ce framework est massivement utilisé (Adobe, Yahoo!, EBay…) pour poursuivre sur son modèle de sécurité.
Par défaut, aucun mécanisme d’authentification n’est mis en place sur un cluster Hadoop. Plus exactement, le mode d’authentification « simple » qui équivaut à de l’identification est utilisé par défaut. La recommandation serait donc de déployer l’unique mécanisme d’authentification fourni par Hadoop : Kerberos.
Par défaut, les données ne sont également pas chiffrées. Des mécanismes de chiffrement sont néanmoins implémentés nativement et peuvent être activés après « kerberisation» du cluster.
Une démonstration d’attaque d’un cluster Hadoop par exécution de commandes à distance a ensuite été réalisée par Mahdi; de nombreuses infrastructures Hadoop sont exposées sur Internet et pourraient être exploitées massivement, comme ce fut le cas pour les bases MongoDB par exemple.
L’intervenant conclu en soulignant le fait que de nombreux challenges autour de la sécurité d’Hadoop restent à relever, mais que des actions de sécurisation classiques peuvent être mises en œuvre à très court terme : mettre en place Kerberos, cloisonner les flux et durcir les socles et applicatifs.

Présentation complète

Cette édition 2017 de la JSSI a donc permis de donner aux auditeurs une vision à la fois juridique, organisationnelle mais aussi technique des enjeux liés aux fuites de données.

Morgane NICOLAS

Quelques rappels sur le protocole d’authentification Kerberos

Kerberos est un protocole d’authentification réseau reposant sur un mécanisme de clés secrètes (chiffrement symétrique) et l’utilisation de tickets. Il fait partie intégrante des système d’exploitation Windows depuis la version Serveur 2000. Différents termes spécifiques sont utilisés pour détailler ce protocole :

KDC (Key Distribution Center) : Le KDC est un service installé sur les contrôleurs de domaine et permettant l’obtention des différents tickets par un utilisateur.
TGT (Ticket-Granting Ticket) : Le TGT est un ticket attribué par le KDC à un utilisateur. Ce ticket représente l’identité de l’utilisateur, et lui permet d’effectuer des demandes de TGS auprès du KDC.
TGS (Ticket-Granting Service) : Le TGS est également un ticket attribué par le KDC pour représenter un utilisateur. Il permet à l’utilisateur de s’authentifier auprès d’un service spécifique, dont le nom est inscrit dans le ticket. Un exemple d’un tel ticket est le suivant :

Le schéma d’une authentification Kerberos classique est le suivant :

Dans la première étape, l’utilisateur envoi au contrôleur de domaine un timestamp chiffré à l’aide du hash NTLM de son mot de passe. Ayant accès à ce hash, le contrôleur de domaine, et plus précisément le KDC, peut déchiffrer l’information reçue et vérifier le timestamp, ce qui prouve l’identité de l’utilisateur. Le KDC fournit alors à l’utilisateur son TGT (étape 2).

L’utilisateur peut alors fournir le TGT préalablement récupéré pour effectuer une demande de TGS (étape 3). Le TGT étant représentatif de l’utilisateur, le KDC peut valider son identité et lui fournir un TGS pour le service demandé (étape 4).

Enfin, l’utilisateur transmet ce TGS comme preuve de son identité auprès du service (étape 5).

Dans le protocole Kerberos, ce sont donc bien les tickets qui permettent d’assurer l’identité d’un utilisateur, au même titre qu’un couple nom d’utilisateur / mot de passe le fait dans une authentification classique.

Introduction aux délégations Kerberos

Microsoft a introduit les délégations Kerberos dans l’objectif de permettre à une application de réutiliser l’identité d’un utilisateur pour accéder à une ressource hébergée sur un serveur différent. Un cas d’usage est par exemple l’accès à des documents hébergés sur un serveur dédié depuis une plateforme SharePoint :

L’utilisateur n’ayant pas d’accès direct au serveur de fichiers, il s’authentifie sur la plateforme SharePoint qui doit alors transmettre l’identité de l’utilisateur au serveur de fichiers.

Cependant, les tickets de service étant délivrés pour une application spécifique, le SharePoint ne peut transmettre directement le ticket qu’il a reçu de l’utilisateur. C’est donc pour répondre à cette problématique que Microsoft a mis en place les délégations Kerberos, qui existent sous deux formes :

Les délégations non contraintes, apparues avec le système d’exploitation Windows Serveur 2000, et qui donnent l’autorisation à un compte de service de réutiliser l’identité de l’utilisateur sur n’importe quel service du domaine ou de la forêt.
Les délégations contraintes, apparues avec le système d’exploitation Windows Serveur 2003, et qui permettent un meilleur contrôle en limitant les services sur lesquels un compte de service donné peut s’authentifier en tant que l’utilisateur.

Les délégations Kerberos non contraintes

Le schéma d’authentification d’un utilisateur désirant accéder à une ressource dans le cas d’une délégation Kerberos non contrainte est le suivant :

Lors de la première étape de ce schéma, l’utilisateur effectue une demande de TGT auprès du contrôleur de domaine, en lui transmettant un timestamp chiffré avec le hash NTLM de son mot de passe. Après avoir validé son identité, le contrôleur de domaine fournit un TGT à l’utilisateur (étape 2), comme il le ferait pour une authentification Kerberos classique.

Pour s’authentifier auprès de l’application SharePoint, l’utilisateur demande alors un TGS au contrôleur de domaine, en lui fournissant le TGT précédemment récupéré (étape 3). Dans le cas d’une délégation Kerberos non contrainte, le contrôleur de domaine construit le TGS de l’utilisateur à partir de son TGT, qu’il chiffre à l’aide du hash NTLM du mot de passe du compte de service utilisé par l’application SharePoint (étape 4).

L’utilisateur s’authentifie alors sur l’application SharePoint (étape 5) en transmettant le TGS que lui a fourni le contrôleur de domaine lors de l’étape précédente.

Le compte de service de l’application SharePoint peut déchiffrer ce TGS étant donné qu’il est chiffré avec son propre hash. Il récupère ainsi le TGT de l’utilisateur, qu’il peut fournir au contrôleur de domaine pour effectuer une demande de TGS pour le serveur de fichier (étape 6). Le TGT étant celui de l’utilisateur, le TGS renvoyé par le contrôleur de domaine (étape 7) représente son identité, et non celle du compte de service.

Le compte de service de l’application SharePoint peut alors transmettre ce TGS (étape 8), que le serveur de fichiers validera comme s’il provenait de l’utilisateur lui-même, donnant accès au document demandé (étape 9). Ayant récupéré ce document, l’application SharePoint peut le fournir à l’utilisateur, pour lequel les phases d’authentification intermédiaires auront été transparentes.

Les délégations Kerberos contraintes

Dans le cas d’une délégation Kerberos contrainte, deux extensions de protocole sont utilisées pour permettre à une application de réutiliser l’identité de l’un de ses utilisateurs :

S4U2Self (Server-for-User-to-Self) qui autorise un service à obtenir un TGS pour lui-même en tant qu’un utilisateur.

S4U2Proxy (Server-for-User-to-Proxy) qui autorise un service à obtenir un TGS pour un autre service en tant qu’un utilisateur.

La cinématique d’authentification et d’accès aux ressources dans le cas d’une telle délégation est alors la suivante :

Dans la première étape de cette cinématique, l’utilisateur s’authentifie après du premier service en lui transmettant ses identifiants. L’authentification n’utilisant pas Kerberos, l’utilisateur n’a pas besoin de s’authentifier auprès du contrôleur de domaine.

Le compte de service demande alors un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès de son propre service (étape 2). Le compte de service possédant l’extension S4U2Self, le contrôleur de domaine accorde ce ticket (étape 3).

Ce même compte de service demande ensuite un TGS représentant l’identité de l’utilisateur et permettant de s’authentifier auprès du second service (étape 4). Après validation de l’extension S4U2Proxy, le contrôleur de domaine accorde ce TGS (étape 5)

Grâce à ce second ticket de service, le compte de service du SharePoint peut accéder aux ressources du serveur de fichier avec l’identité de l’utilisateur (étape 6). Le serveur de fichiers valide les privilèges de l’utilisateur, et transmet le document demandé au compte de service SharePoint (étape 7), qui le transmet à l’utilisateur (étape 8).

Contrairement au cas des délégations non contraintes, l’utilisation de l’extension de protocole S4U2Proxy permet de spécifier les services accessibles au compte de service SharePoint. Ainsi, même si l’utilisateur dispose des privilèges nécessaires pour accéder à un autre serveur, le compte de service ne pourra récupérer de TGS valide représentant l’identité de l’utilisateur. Dans le cas d’une délégation contrainte, cette restriction se fait à l’aide d’un paramètre du compte de service, appelé SPN pour Service Principal Name.

Il est à noter que depuis la version Serveur 2012 du système d’exploitation Windows, un troisième type de délégation Kerberos est proposée, les délégations Kerberos contraintes basées sur les ressources. Le fonctionnement de ces délégations est similaire à celui des délégations contraintes, mais la restriction est effectuée en spécifiant explicitement le compte ayant accès aux ressources.

Exploiter les délégations non contraintes

Les faiblesses induites par les délégations Kerberos non-contraintes sont connues depuis plusieurs années. Sean Metcalf a, par exemple, présenté les dangers de telles délégations à la Black Hat USA 2015. Dans la cinématique d’authentification présentée précédemment, il est en effet évident que le compte de service de l’application SharePoint peut, une fois que l’utilisateur lui a transmis un TGS contenant son TGT, accéder à l’ensemble des services pour lesquels l’utilisateur dispose de privilèges nécessaires.

L’objectif d’un attaquant est alors d’obtenir le TGT d’un administrateur du domaine, ce qui lui permet de se connecter au contrôleur de domaine avec les privilèges maximum pour changer le mot de passe du compte krbtgt afin de pouvoir forger ses propres tickets à la demande.

Pour parvenir à cela, il est d’abord nécessaire d’identifier les services qui disposent de délégations non contraintes. Pour cela, il suffit de filtrer les objets de l’Active Directory à la recherche de paramètres TrustedForDelegation valant True. Ce paramètre indique en effet la présence d’une délégation non contrainte, et est de plus accessible sans privilège particulier, par exemple à l’aide de la commande Get-ADComputer du module ActiveDirectory :

PS C:\> Import-Module ActiveDirectory

PS C:\> Get-ADComputer –Filter {(TrustedForDelegation –eq $True) –and (PrimaryGroupID –eq 515)}

Une fois les services disposant d’une délégation Kerberos non contrainte identifiés, il est nécessaire d’obtenir des privilèges administrateur sur l’un des serveurs sur lesquels ils sont utilisés. Les méthodes de compromission classiques peuvent alors être utilisées, mais ne seront pas abordées dans cet article.

En cas d’accès au service par un administrateur du domaine, l’attaquant sera en mesure d’extraire le TGS fourni à l’aide par exemple de l’outil mimikatz et de la commande suivante :

mimikatz # kerberos::list /export

Comme indiqué dans le scénario d’authentification, ce TGS contient le TGT de l’administrateur, que l’attaquant pourra extraire afin de réaliser une attaque Pass-The-Ticket pour se connecter au contrôleur de domaine.

Les recommandations pour protéger un domaine d’une telle attaque sont alors les suivantes :

Utiliser des délégations Kerberos contraintes qui sont plus restrictives
Configurer l’ensemble des comptes à privilèges avec le paramètre « Le compte est sensible et ne peut être délégué » qui empêche la réutilisation de l’identité du compte par une application possédant une délégation

Dans le cas d’un domaine au niveau fonctionnel supérieur à Windows Serveur 2012 R2, le groupe de sécurité « Utilisateurs protégés » peut être utilisé pour les comptes à privilèges étant donné que les délégations ne sont pas autorisées pour les comptes de ce groupe.

Qu’en est-il des délégations contraintes ?

L’utilisation de délégations contraintes semble être une alternative plus sécurisée. Cependant, différents éléments sont à noter concernant ce mécanisme d’authentification, comme l’a présenté Matan Hart lors de la Black Hat 2017. En effet, les deux extensions de protocole utilisées ont été pensées avec les principes suivants :

Les deux extensions permettent à un service Kerberos d’obtenir des TGS sans même que l’utilisateur n’ait besoin de s’authentifier auprès du contrôleur de domaine.
L’extension S4U2Self permet au service d’obtenir un TGS pour l’utilisateur sans qu’aucun mot de passe ne soit nécessaire.

De ce fait, un service qui possèderait les deux extensions pourrait obtenir un TGS pour n’importe quel autre service en se faisant passer pour un utilisateur, et ce sans nécessiter son mot de passe.

Matan Hart a publié son outil « Mystique[1] » qui permet d’identifier des configurations à risque pour les délégations. Pour cela, il liste les comptes qui disposent du paramètre TrustedToAuthForDelegation valant True, indiquant une délégation contrainte, ainsi que d’un paramètre MsDS-AllowedToDelegateTo non nul, indiquant l’utilisation d’un SPN, ce qui est obligatoire pour les comptes de délégation.

Il est également à noter que les TGS sont validés selon deux critères, le hash du mot de passe de l’utilisateur, et le SPN possédé par le compte de service qui possède la délégation contrainte. En cas de multiples SPNs associés à un même compte de service, et de mot de passe partagé entre différents comptes, les tickets pour deux services distincts seront complétement interchangeables, ce qui pourrait permettre à un service de réutiliser l’identité d’un utilisateur de manière illégitime.

Ces faiblesses ne sont pas considérées comme des vulnérabilités par Microsoft, et ne sont donc pas amenées à changer. Lors de la création d’une délégation Kerberos contrainte, il est alors nécessaire de faire attention aux points suivants pour se protéger des attaques :

Configurer les services à l’aide de comptes de service dédiés, évitant ainsi le partage des comptes qui pourrait aboutir à des tickets interchangeables. Il est également important d’assurer une bonne complexité des mots de passe, ainsi qu’une rotation régulière.
Configurer des SPNs uniques comme étant autorisés pour la délégation, en évitant les SPNs par défaut de Microsoft, et en spécifiant les ports utilisés.
Comme pour les délégations non contraintes, configurer les comptes à privilèges comme étant des comptes sensibles ne pouvant être délégués.

Conclusion

L’utilisation de délégations contraintes n’est pas totalement à proscrire. Il est cependant nécessaire de bien maitriser leur configuration et les ressources auxquelles elles permettent d’accéder afin d’éviter les travers détaillés dans cet article.

Nicolas DAUBRESSE

Sources :

[1] https://github.com/machosec/Mystique

https://adsecurity.org/?p=1667

https://www.blackhat.com/docs/asia-17/materials/asia-17-Hart-Delegate-To-The-Top-Abusing-Kerberos-For-Arbitrary-Impersonations-And-RCE.pdf

https://labs.mwrinfosecurity.com/blog/trust-years-to-earn-seconds-to-break/

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 !

Retrouvez également le focus de la semaine, la compromission de domaines Windows à l'aide des délégations Kerberos.

Veille cybercriminalité

Le reste des outils d’Equation Group rendu public

Dans une lettre ouverte au président Trump[1], le groupe « The Shadow Brokers » a publié la clé de déchiffrement de l’archive contenant le reste des outils volés au groupe de hackers « Equation Group ». Cette divulgation, qui fait suite à la précédente publication d’outils[2], intervient sans que le montant de B1.000.000 initialement demandé n’ait été payé.

Les outils ont évidemment été rapidement récupérés et mis à disposition de tous[3]. Parmi ces outils se trouvent notamment les suivants :

Un exploit de prise de contrôle à distance des systèmes Solaris
Les commandes permettant d’accéder au réseau téléphonique de l’opérateur pakistanais Mobilink
Le framework TOAST permettant de supprimer les journaux d’événements wtmp sur les systèmes Unix

Sources :

[1] https://medium.com/@shadowbrokerss/dont-forget-your-base-867d304a94b1

[2] http://www.securityinsider-solucom.fr/2016/10/7-exploits-pour-pare-feu-publies-par.html

[3] https://github.com/x0rz/EQGRP

http://securityaffairs.co/wordpress/57859/intelligence/shadow-brokers-nsa-hacking-tools.html

https://threatpost.com/shadowbrokers-dump-more-equation-group-hacks-auction-file-password/124882/

https://www.theregister.co.uk/2017/04/11/solaris_shadow_brokers_nsa_exploits/

Apache Struts 2

Le 8 mars 2017, l’entreprise Cisco Talos a reporté dans son blog[1] une nouvelle vulnérabilité sur le produit Apache Struts 2 suite à la publication d’un exploit[2] dans l’outil metasploit. Dès cette publication, différentes attaques exploitant la vulnérabilité ont été observées, avec notamment pour objectif d’infecter les cibles avec une variante du ransomware « Cerber ». La vulnérabilité permettant en effet de l’exécution de code à distance, les attaquants ont pu injecter du code permettant le téléchargement du malware.

Pour se protéger, une mise à jour de sécurité existe, ainsi que différentes solutions de contournement temporaires[3].

Sources :

[1] http://blog.talosintelligence.com/2017/03/apache-0-day-exploited.html

[2] https://github.com/rapid7/metasploit-framework/issues/8064

[3] https://cwiki.apache.org/confluence/display/WW/S2-045

http://securityaffairs.co/wordpress/57789/cyber-crime/apache-struts-cerber-ransomware.html

https://threatpost.com/apache-struts-2-exploits-installing-cerber-ransomware/124844/

Opération Cloud Hopper

Une large campagne d’attaques visant les fournisseurs de services d’infogérance dans plusieurs pays du monde, référencée sous le nom « Opération Cloud Hopper », a été rendue publique. Suite aux investigations, les experts attribueraient l’attaque au groupe d’attaquants chinois APT10, notamment aux vues des horaires auxquels ont eu lieues les attaques.

Les attaques ont consisté en des messages de spear-phishing, c’est-à-dire des emails dont l’émetteur cherche à se faire passer pour une entreprise connue. À l’aide de cette méthode, les attaquants auraient réussi à obtenir des identifiants légitimes pour accéder au réseau des fournisseurs de services, exfiltrant alors une grande quantité d’informations.

Sources :

https://www.schneier.com/blog/archives/2017/04/apt10_and_cloud.html

http://securityaffairs.co/wordpress/57781/apt/operation-cloud-hopper-apt10.html

Le botnet Brickerbot met en péril vos objets connectés

Depuis la publication du code du botnet Mirai, de nombreux botnets visant les objets connectés ont été observés. Un nouveau botnet voit maintenant le jour sous le nom de « Brickerbot ». Cependant ce dernier va plus loin que son prédécesseur, qui était utilisé pour causer du Déni de Service temporaire, puisqu’il rend inutilisable les objets connectés n’étant pas sécurisés, et ce de manière permanente.

Pour compromettre les objets connectés, Brickerbot utilise un brute force via le protocole Telnet, tout comme le permettait Mirai. Une fois connecté sur un équipement vulnérable, le malware exécute la commande « rm -rf /* » qui permet de supprimer l’ensemble des fichiers présents sur le système. Le malware désactive également les timestamps TCP, réduit le nombre de thread noyau à 1, et remplace les règles iptables par une règle bloquant toute communication avec l’extérieur, laissant l’objet connecté complétement inutilisable.

Sources :
https://www.theregister.co.uk/2017/04/08/brickerbot_malware_kills_iot_devices/
http://securityaffairs.co/wordpress/57839/malware/brickerbot-botnet-iot.html

ATMitch – un malware sans fichier visant les distributeurs de billets

L’entreprise de sécurité Kaspersky Lab a reporté une attaque ayant touché huit distributeurs de billets aux États-Unis en une seule nuit, aboutissant à plus de 800 000 dollars volés. Aucun malware n’a été retrouvé sur les distributeurs, mais leurs journaux contenaient des lignes inhabituelles telles que « Take the Money Bitch! ».

Le code malveillant serait donc directement injecté et exécuté en mémoire. Cette technique n’est pas nouvelle, et permet dans ce cas d’utiliser des scripts PowerShell pour injecter un meterpreter permettant aux attaquants de se connecter à la machine et de lancer les commandes distribuant l’argent, alors récupéré par un complice.

Sources :
http://securityaffairs.co/wordpress/57881/cyber-crime/atmitch-fileless-malaware.html

Veille vulnérabilité

Une vulnérabilité dans Word permet de prendre le contrôle à distance d’un poste

Des chercheurs des entreprises de sécurité McAfee et FireEye ont remonté une nouvelle vulnérabilité sur le logiciel Microsoft Word. Cette vulnérabilité, qui affecterait toutes les versions jusqu’à Office 2016 tournant sur un système d’exploitation Windows 10, pourrait permettre à un attaquant de prendre le contrôle à distance du poste. La particularité de cette vulnérabilité est que, contrairement à la plupart des attaques sur le logiciel Word, elle ne nécessite pas l’activation des macros par la victime.

FireEye et McAfee remontent déjà des cas d’attaques utilisant cette vulnérabilité, dont le vecteur d’attaque serait un mail contenant un document Word dans lequel est présent un objet OLE2link. Cet objet utiliserait l’exécutable winword.exe pour contacter un serveur distant à l’aide de requêtes HTTP. Un fichier .hta malveillant déguisé en RTF est ainsi récupéré puis, une fois chargé et exécuté, met un terme au processus lancé par winword.exe pour cacher une fenêtre de dialogue levée par l’objet OLE2link.

Cependant, cette attaque n’est pas applicable sur le mode protégé d’Office, ce qui semble être la seule protection en attendant une mise à jour de Microsoft.

Sources :
https://www.theregister.co.uk/2017/04/09/microsoft_word_ole_bug/
http://securityaffairs.co/wordpress/57892/hacking/windows-zero-day-attack.html
https://www.fireeye.com/blog/threat-research/2017/04/acknowledgement_ofa.html

Des millions de téléphones vulnérables

Le chercheur Ralph-Phillip Weinmann, travaillant pour la compagnie Comsecuris, a dévoilé une vulnérabilité sur le firmware Baseband des puces 4G LTE qui pourrait affecter des millions de téléphones portables Huawei. Cette vulnérabilité pourrait permettre à un attaquant d’espionner les communications mobiles, exfiltrer des informations, envoyer des SMS ou passer des appels à l’insu de l’utilisateur, ou encore causer un Déni de Service à l’aide d’une corruption de la mémoire.

L’attaque requiert cependant de nombreux prérequis relativement complexes à mettre en place, réduisant ainsi le risque d’attaque.

Sources :
https://threatpost.com/baseband-zero-day-exposes-millions-of-mobile-phones-to-attack/124833/
http://securityaffairs.co/wordpress/57867/hacking/mobile-baseband-zero-day.html

Exécution de code sur des systèmes SCADA

Une vulnérabilité dans les systèmes SCADA Schneider Electric IGSS a été rendue publique par l’éditeur le 31 mars 2017. Cette vulnérabilité, qui affecte les systèmes utilisant les versions V12 et antérieures s’exécutant sur des systèmes d’exploitation Microsoft antérieur à Windows 10, permettrait à un attaquant de provoquer une exécution de code arbitraire. Cette vulnérabilité est due à la gestion non sécurisée des fichiers DLL et OCX par le système d’exploitation Windows.

En effet, les versions des systèmes d’exploitation de Microsoft antérieures à Windows 10 enregistrent les fichiers OCX à l’aide de chemins relatifs à une variable d’environnement, ce qui pourrait permettre à un attaquant d’exécuter une version contrefaite d’un fichier légitime. De plus, pour ces mêmes versions du système d’exploitation, la recherche de fichier autorise l’utilisation de chemins relatifs pour les DLL, ce qui l’expose à du DLL hijacking.

La recommandation associée à cette vulnérabilité est la montée de version vers le système d’exploitation Microsoft Windows 10.

Sources :
http://download.schneider-electric.com/files

Indicateurs de la semaine

Le leak de la semaine – GrassHopper

Wikileaks continue de rendre publique[1] différents documents de l’archive Vault 7 récupérée à la CIA, avec cette fois un ensemble de 27 documents détaillant le framework nommé « GrassHopper ». Ce framework permet aux opérateurs de la CIA de construire, exécuter, et visualiser le résultat de l’exécution de charges malveillantes.

Dans le manuel d’utilisation est spécifié que différents installeurs sont créés pour différentes architectures et systèmes d’exploitation. Certaines techniques aperçues dans diverses attaques sont de plus reprises par le framework, comme c’est par exemple le cas de la méthode de persistance utilisée par le rootkit Carberp spécialement réadaptée dans ce framework.

Sources :
[1] https://www.wikileaks.org/vault7/#Grasshopper
http://securityaffairs.co/wordpress/57822/intelligence/cia-grasshopper-framework.html
https://www.schneier.com/blog/archives/2017/04/fourth_wikileak.html

L’exploit de la semaine – MS16-135

La vulnérabilité connue sous le nom de « MS16-135 » permet à un attaquant une élévation de privilèges locale jusqu’au compte « NT AUTHORITY\System ». Cette vulnérabilité affecte l’ensemble des systèmes d’exploitation de Microsoft, jusqu’à Windows 10. Un premier POC écrit en C par @tinysec avait été rendu public[1] pour exploiter cette vulnérabilité, et @FuzzySecurity a adapté l’exploit en PowerShell[2].

Sources :
[1] https://github.com/tinysec/public/tree/master/CVE-2016-7255
[2] https://github.com/FuzzySecurity/PSKernel-Primitives/tree/master/Sample-Exploits/MS16-135
https://technet.microsoft.com/en-us/library/security/ms16-135.aspx

L’attaque de la semaine – RensenWare

Les ransomwares sont monnaie courante de nos jours, et il n’est plus rare de voir de nouvelles versions apparaitre de manière régulière. RensenWare est cependant un ransomware un peu particulier puisque, plutôt que de demander une rançon monétaire, il requiert d’atteindre un certain score sur un jeu vidéo nommé TH12. Le malware semble en effet fournir la clé de déchiffrement une fois le score atteint, ce qu’il parvient à déterminer en observant un processus nommé « th12 ».

À noter que le malware ne met aucune protection en place pour empêcher la récupération des fichiers chiffrés, comme c’est par exemple souvent le cas avec la suppression des shadow volumes.

Sources :
http://securityaffairs.co/wordpress/57850/malware/rensenware-ransomware.html

Suivi des versions

Produits	Version actuelle
Flash Player	25.0.0.127
Adobe Reader	2015.023.20070
Java	Version 8 update 121
Mozilla Firefox	52.0.2
Google chrome	55.0.2883.75
Virtual Box	5.1.18

Nicolas DAUBRESSE

Wavestone était présent à l’édition 2017 de la conférence Hack-in-the-box (HITB) à Amsterdam où un consultant de la practice Cybersecurity & Digital Trust, Ayoub Elaassal, a pu présenter des travaux autour de la sécurité des Mainframe, via le talk « Hacking Customer Information System ».

Nous vous proposons ci-dessous un compte-rendu des talks les plus marquants de cette édition, les supports de présentations étant d’ores et déjà disponibles à l’adresse suivante tandis que les vidéos seront bientôt publiées sur la chaine Youtube de la conférence.

Michele Spagnuolo and Lukas Wilschelbaum - We Broke All CSPS and You Won’t Believe What Happened Next!

Derrière ce titre à l’allure de clickbait les ingénieurs de chez Google ont présenté :

Le concept de la protection « Content Security Policy» : pour rappel cette protection vise à réduire les possibilités d’exploitation d’une faille de type Cross-Site Scripting (XSS) dans une application Web vulnérable
Comment établir une politique simple, générique et efficace, en rappelant que les politiques basées sur les listes blanches sont aisément contournables
Les challenges autour du déploiement d’une politique générique sur les services Google, historiques ou nouveaux : pour certains services, ils ont obtenu un volume de plus de 50 millions de violations de la politique par jour représentant ainsi une quantité considérable d’information qu’il faut trier selon deux possibilités : les problèmes liés au service en lui-même ou des problèmes liés aux extensions de navigateur utilisées (99% des rapports reçus) par la population de test (1 milliard d’utilisateurs Chrome)
Des outils développés :

CSP Mitigator, permettant d’identifier visuellement les violations de CSP au sein d’une page
CSP Evaluator, permettant d’identifier les contournements possibles de la politique
CSP Frontend, outil interne à Google permettant de concentrer les rapports de violations

Les différentes techniques de contournement, démontrant ainsi que la protection CSP n’est pas une réponse sans faille mais un élément de défense en profondeur.

Cette protection est assurément efficace, mais ne constitue qu’un rempart supplémentaire pour des applications Web disposant déjà d’un niveau de sécurité minimal. La complexité technique non négligeable nécessaire à sa mise en place joue en sa défaveur pour une prise en compte massive par les développeurs Web… pour lesquels il nous est souhaitable de sécuriser en premier lieu leurs développements face à la vulnérabilité applicative triviale XSS, malheureusement trop commune.

Patrick Wardle - Meet and Greet with the MacOS Malware Class of 2016

Patrick Wardle tord le cou à la pensée historique et commune, que le système Mac OS n’est pas la cible de virus en proposant une revue des principaux malwares ayant visé cette plateforme sur l’année 2016. Du ransomware « KERANGER », à la backdoor « ELEANOR » espionnant les flux audio et vidéo du poste de travail, en passant par le faux antivirus « FAKEFILEOPENER » jusqu’à l’implant « KOMPLEX » supposément lié au groupe APT18 « Fancy Bear », tous partagent la même méthode d’infection : l’exécution par la victime d’un fichier malveillant caché dans un programme légitime (par ex. le client bittorrent Transmission) ou reçu en pièce-jointe.

Le malware « KEYDNAP » est probablement le plus insolent de par sa méthode d’élévation de privilèges simple et efficace : demander à l’utilisateur de saisir les authentifiants d’un compte avec les privilèges d’administration. La plupart des malwares partagent également la caractéristique de ne pas être protégés (packing, chiffrement/déchiffrement du payload à l’exécution etc.) facilitant ainsi l’analyse.

Face à ces malwares et à l’absence de solution antivirale efficace pour Mac OS, la plupart étant principalement basées sur des signatures, Patrick Wardle a développé une suite d’outils open-source et gratuits mettant en œuvre des méthodes génériques de détection, dont notamment l’outil OverSight, permettant de détecter l’écoute des flux de caméra par un processus illégitime : https://objective-see.com

George Chatzisofroniou - Exploiting Windows Automatic Wireless Association Algorithm

“Wi-Fi Sense"était une des nouvelles fonctionnalités de Windows 10 qui permettait de partager les mots de passe des réseaux WiFid’un utilisateur à ses contacts et ainsi permettre la connexion automatique et transparente d’un poste de travail à proximité d’un réseau. Ce partage des authentifiants ayant été supprimé lors d’une mise à jour suite au mécontentement des utilisateurs, l’auteur a néanmoins identifié une vulnérabilité qui permet à un attaquant de forcer la connexion d’un utilisateur à un point d’accès Wi-Fi, celui-ci étant de préférence maitrisé par l’attaquant afin d’intercepter les flux.

A chaque connexion à réseau Wi-Fi par un poste de travail Windows 10, celui remonte automatiquement des informations à Microsoft sur la localisation de ce réseau et la qualité de celui-ci, avec comme objectif pour Microsoft de construire une gigantesque base de donnée.

L’auteur tire parti de cette « fonctionnalité » afin de piéger sa victime en tentant de se faire passer pour un réseau « Wi-Fi Sense » sur lequel la victime s’est déjà connectée. La séquence de l’attaque nommée « Lure10 » est la suivante :

L’attaquant envoie des trames de désauthentification de la victime au point d’accès initial, cette technique n’est pas nouvelle et tire parti de l’absence d’authentification cryptographique de ces flux dans le protocole 802.11
L’attaquant émet des trames « beacons » de multiples réseaux Wi-Fi qui sont présents physiquement aux alentours du « Wi-Fi Sense » ciblé. La proximité géographique de ces réseaux est nécessaire pour duper le service de géolocalisation Windows utilisant une triangulation des réseaux Wi-Fi pour déterminer la position géographique du poste de travail
L’attaquant émet des trames « beacons » du réseau « Wi-Fi Sense » ciblé : le poste de travail, croyant que le poste est dans une zone géographique proche du réseau ciblé, se connecte alors automatiquement à ce réseau.

Averti de cette attaque, Microsoft a informé l’auteur que le risque associé était accepté et qu’aucun patch ne serait développé. Les utilisateurs peuvent toutefois se prémunir de cette attaque en désactivant simplement la fonctionnalité« Wi-Fi Sense » :

Marc Newlin and Matt Knight - So You Want to Hack Radios

Les auteurs ont eu pour objectif de démontrer la facilité d’attaque de protocoles radio via l’utilisation d’outils open-source de radio logicielle dont notamment le framework GNU radio. Une méthode générique de rétro-ingénierie a été détaillée puis appliquée à 3 exemples différents :

Un flash manuel d’appareil photo
Une guirlande de LEDs contrôlée par une télécommande
Un clavier sans-fil

Dans tous les exemples les auteurs sont parvenus facilement à analyser les signaux radio en rétro-concevant la modulation, le débit de symbole et le protocole d’échange d’information au moyen de ressources open-source et d’astuces communes pour tenter d’obtenir de la documentation technique sur les composants, et in-fine pouvoir contrôler de manière programmatique ces équipements.

Steven Seeley and Roberto Suggi Liverani - I Got 99 Trends and a # Is All Of Them

De nombreuses solutions de l’éditeur de sécurité Trend Micro ont été passées au crible par les auteurs, qui ont pour chacune pu trouver des dizaines voire des centaines de vulnérabilités applicatives critiques triviales entrainant la compromission de la solution et du socle système sous-jacent. Ces nombres considérables de vulnérabilités ont pour principales causes l’absence de sensibilisation et de prise en compte de mesures de développement sécurisé par l’éditeur et la réutilisation massive de composants vulnérables.

Les auteurs ont détaillé leur méthodologie et les écueils rencontrés puis ont tenu à indiquer la bonne coopération de l’éditeur et la diffusion rapide de patchs, pas forcément toujours efficaces.

Yingtao Zeng, Qing Yang and Jun Li – Chasing Cars: Keyless Entry System Attacks

Les auteurs ont démontré la possibilité d’attaque par relai pour la séquence de déverrouillage des portes de voitures utilisant un modèle spécifique de micro-contrôleur NXP pour la clé sans-fil. Pour un montant total de 20 euros en composants électroniques, les chercheurs ont démontré la possibilité d’une telle attaque, nécessitant 2 protagonistes :

Un premier qui doit s’approcher à 2m minimum de la clé sans-fil détenue par le propriétaire
Un second qui doit se positionner vers la voiture et relayer les demandes d’authentification issues de la voiture vers la clé sans-fil vers le premier attaquant.

Cette attaque est réalisable à une distance maximum de 300m entre le premier attaquant et le second. Aucune liste exhaustive des voitures vulnérables n’a été communiquée par les chercheurs, le constructeur General Motor a cependant été évoqué.

S. Huber, S. Artz and S. Rasthofer – Extracting All Your Secrets: Vulnerabilities in Android Password Managers

Les principales applications Android de gestion centralisée des mots de passe ont été évaluées par les chercheurs, qui ont eu pour objectif d’identifier des scénarios d’attaque ne nécessitant pas le root préalable du terminal mobile. Les principales vulnérabilités sont les suivantes :

Pour les fonctionnalités de remplissage manuel de formulaire, le presse-papier Android n’étant pas cloisonné par application, une application malveillante peut le surveiller en fond de tâche et copier ce qui s’y trouve entrainant ainsi la fuite du mot de passe pour cet usage.
Pour les fonctionnalités de remplissage automatique de formulaire, les Services d’Accessibilités Android sont communément utilisés. Ceux permettent à une application A de transmettre des informations à une application B, basé sur le nom de package (unique par application) de l’application B.
Dans l’exemple évoqué, l’utilisateur stocke dans son application de gestion de mot de passe une entrée pour son compte Twitter, valide ainsi sur le domaine « twitter.com». Ce mot de passe est en théorie uniquement transmis à l’application officielle Twitter, dont le nom de package officiel est « com.twitter.android». Un mapping inverse est effectué entre le nom de domaine (« twitter.com») et le nom de package (« com.twitter»).
Une vulnérabilité au sein de mécanisme existait dans la mesure où seul le préfixe, et non la valeur entière du nom de package était recherché : ainsi en créant une application avec un nom de package débutant par « com.twitter» (par exemple « com.twitter.twitterleak»), le mot de passe pouvait être récupéré par cette dernière.
Pour les applications utilisant l’API Android « AccountManager», consistant en une base de données globale à tout le terminal ; une attaque par « résidu » a été mise en évidence et permet à une application malveillante utilisant le même nom de package de l’application légitime de récupérer les valeurs stockées par cette dernière après sa désinstallation.

Diverses autres vulnérabilités ont été identifiées dont entre autres des clés de chiffrement inscrites en dur dans le code, des secrets stockés en clair, l’utilisation du mode non sécurisé ECB d’AES et des applications réinventant leur propre protocole de transport au lieu d’utiliser SSL/TLS :

Il a été évoqué en conclusion que toutes les vulnérabilités ont été corrigées par les éditeurs.
A la question « Quelle solution nous conseillez-vous d’utiliser ? » les auteurs ont simplement évoqué que toutes sont plutôt robustes tant que l’utilisateur n’utilise pas les fonctionnalités de confort (remplissage automatique, simple PIN pour clé maitre etc.).

Antonios Atlasis - An Attack-in-Depth Analysis of Multicast DNS and DNS Service Discovery

Le chercheur a analysé la sécurité de ces protocoles sous 2 angles : les spécifications au sein des RFC et les implémentations rencontrées, notamment face aux directives ambiguës de type « SHOULD » au sein des spécifications : par exemple « mDNS responses SHOULD be sent with IP TTL := 255 ».

Pour rappel, ces protocoles sont utilisés pour la fourniture de services de nommage au sein d’un réseau IP sans configuration préalable (famille de protocoles « zeroconf ») :

mDNS vise à fournir des services similaires au protocole DNS sur le lien local en multicast via le port 5353
DNS-SD permet aux clients de découvrir des services sur un lien local, avec la convention « <Instance>.<Service>.<Domain>», par exemple « _http._tcp.local»

L’absence d’authentification couplée à l’utilisation du protocole non connecté UDP rend ces standards vulnérables de nombreuses attaques dont entre autres :

La reconnaissance : des informations verbeuses fuitent et facilitent la cartographie des services disponible sur les hôtes présents sur le lien local, sans besoin de scan de port

L’usurpation de services et la réalisation d’attaques de type Man-in-The-Middle, simplement en annonçant un service précis et en demandant préalablement aux hôtes de vider leur cache, par exemple en annonçant le service « _googlecast._tcp» utilisé pour la diffusion de contenu sur Chromecast.
Des dénis de service : ces protocoles prévoient en théorie des tailles maximum de message, cependant les implémentations ne respectent pas toujours la RFC et il est souvent possible de crasher un service en lui envoyant un message volumineux. Il est également possible de rendre inopérant un service annoncé en envoyant, plus rapidement que le service légitime sur le lien local, une réponse avec un TTL égal à 0.
Des dénis de service distribués : en envoyant une requête DNS directe sur le port 5353 d’un hôte, ce qui n’est pas un cas d’usage spécifié dans la RFC, celui-ci va envoyer une réponse à l’émetteur. En usurpant l’adresse IP source d’une requête, il est ainsi possible de provoquer une attaque par amplification visant à submerger l’initiateur.

Bien que ces protocoles aient été conçus pour un usage limité au lien local, de nombreux services sont accessibles sur Internet (1 millions de services accessibles sur le port 5353 recensé par Shodan). De plus, le chercheur a observé que les vulnérabilités évoquées précédemment peuvent être corrigée pour IPv4 mais non pour IPv6.

L’outil « pholus » (https://www.secfu.net/app/download/10929157197/pholus.tar.gz), développé par l’auteur, permet la réalisation des attaques présentées.

Emmanuel Gadaix – A Surprise Encounter With A Telco APT

En 2005 la presse révèle qu’une attaque informatique d’ampleur a été menée contre l’opérateur téléphonique Vodafone en Grèce pendant les Jeux Olympiques de 2004. Les détails techniques ne sont pas publiés mais le niveau technique semble avoir été relativement élevé et laisse peu de doute quant à l’implication d’un acteur étatique. Cette attaque à visé à altérer le fonctionnement de l’intercepteur légal des communications, dans le but de masquer l’écoute de certains terminaux mobiles précis dont notamment ceux d’acteurs politiques locaux, d’ambassadeurs, de militaires et d’ONG.

Le code PLEX (propriétaire Ericsson) de l’équipement a été modifié afin de masquer les numéros surveillés, les fonctions de journalisation ont été contournées et un utilisateur système a été ajouté.

L’auteur raconte qu’en 2015 et par le plus grand des hasards lors d’un audit de sécurité pour un opérateur téléphonique, il a pu observer que ce même attaquant était en train d’opérer sur une infrastructure similaire à celle attaquée en 2005. Dès lors, il a tenté de récupérer un maximum d’informations, notamment des scripts utilisés par l’attaquant afin de les analyser et in-fine confirmer le haut niveau technique de ce groupe étatique ayant agi 10 ans plus tôt.

Anirudh Duggal - Hacking Medical Devices and Healthcare Infrastructure

L’auteur a présenté le protocole de communications HL7 utilisé couramment dans les appareils médicaux. Ce protocole transporte toutes les informations liées au dossier médical des patients à savoir :

Les coordonnées personnelles
Les allergies et diagnostics
Les médications
Les valeurs de pouls, d’oxygène et autres mesures temps-réel

Ce protocole est vulnérable aux interceptions actives et passives dans la mesure où il n’est ni chiffré ni authentifié. Enfin, l’auteur a pu mettre en évidence des crashs d’équipements suite à l’envoi de messages volumineux ou mal formés, témoignant ainsi de problème d’analyse syntaxique et potentiellement de vulnérabilités de type « buffer overflow ».

Thomas DEBIZE

Société Générale et Wavestone lancent les « Banking CyberSecurity Innovation Awards », premier trophée dédié à la cybersécurité dans le domaine bancaire. Les Startups et PME innovantes sont invitées à concourir jusqu’au 21 mai pour proposer leur solution dans trois catégories.

La cybersécurité au cœur des préoccupations de Société Générale et de Wavestone

Les « Banking Cybersecurity Innovation Awards » s’adressent aux startups et PME innovantes européennes pour qu’elles fassent découvrir et qu’elles mettent en valeur leurs solutions en matière de cybersécurité, en particulier sur les thématiques de la sécurité de la Blockchain, des services FinTech, du paiement mobile, etc. Cette initiative fait appel aux esprits les plus créatifs des entrepreneurs européens pour construire la cybersécurité de la banque de demain et assurer la confiance numérique de la banque et de ses clients.

Les candidats pourront concourir dans trois catégories :

Confiance numérique pour la banque : pour les solutions visant à sécuriser les systèmes internes de la banque, aussi bien métiers que liés aux infrastructures informatiques.
Confiance numérique pour les clients : pour les solutions visant à sécuriser les échanges entre la banque et les clients, il s‘agit de solutions visibles des clients ou mise en œuvre sur leurs terminaux.
Spécial France : pour une startup dont le siège social est basé en France et dont le capital est majoritairement détenu par des personnes, morales ou physiques, françaises.

Un jury d’envergure

Les lauréats seront départagés d’abord sur dossier puis en soutenance orale, le 6 juin 2017 dans les locaux de Wavestone, par un jury composé de membres reconnus pour leur expertise à la fois technique et stratégique dans le domaine de la cybersécurité et de la banque :

Françoise Mercadal-Delasalles, Directrice des Ressources et de l’Innovation, Société Générale
Laurent Goutard, Directeur de la Banque de Détail en France, Société Générale
Thierry Olivier, RSSI, Société Générale
Pascal Imbert, CEO Wavestone
Reza Maghsoudnia, Strategic Devlopement Director Wavetone
Gérôme Billois, Senior Manager Cybersecurité Wavestone
Guillaume Poupard, Directeur Général ANSSI
Patrick Duvaut, Directeur de la recherche au sein de l’école Télécom ParisTech
Sébastien Couasnon, Journaliste et présentateur de Tech & Co sur BFM Business

Les collaborateurs Société Générale et Wavestone auront également l’opportunité de voter pour le candidat de leur choix, lui octroyant ainsi une voix supplémentaire par société.

Les 3 lauréats remporteront alors la possibilité de tester leur solution au sein du Système d’Information de la Société Générale et d’intégrer « Shake’Up », le programme d’accélération de Startup de Wavestone.

Enfin, la cérémonie de remise des prix se déroulera le 05 juillet 2017 après midi, sur le nouveau technopôle de la Société Générale, « Les Dunes », à Val de Fontenay.

Visitez https://www.banking-cybersecurity-innovation.com/ pour plus de renseignement ou pour proposer votre candidature.

Une nouvelle divulgation fatale

Le week-end dernier, le groupe « The Shadow brokers» a publié une nouvelle archive contenant les outils volés au groupe de hackers « Equation group ». Cette nouvelle divulgation, après celle du 8 avril [1] pour les systèmes UNIX, concerne principalement :

Le système d’exploitation Windows ;
Le réseau bancaire SWIFT.

Comme pour les précédentes publications, l’ensemble des outils et des données sont accessibles librement sur internet [2]. Un référentiel des différents exploits [3] est actuellement tenu à jour par la communauté.

La suite de cet article se concentrera sur l’exploitation de la vulnérabilité MS17-010.

MS17-010, digne successeur de MS08-067

Petit retour en 2008, Microsoft déployait le patch MS08-067 destiné à corriger une vulnérabilité critique sur ces systèmes permettant d’exécuter du code à distance sans authentification. Le ver « Conficker » avait notamment exploité cette vulnérabilité pour compromettre plusieurs millions d’ordinateurs.

Le bulletin de sécurité MS17-010 s’annonce tout aussi intéressant et permet la prise de contrôle à distance d’un poste de travail ou d’un serveur utilisant le système d’exploitation Windows. La vulnérabilité est déjà exploitée par des ransomwares.

Identification des systèmes vulnérables

A ce jour, l’exploitation de MS17-010 concerne les versions suivantes exposant le protocole SMB :

Windows XP et Windows Server 2003;
Windows Seven et Windows Server 2008 R2.

Il est cependant nécessaire de noter que le patch déployé par Microsoft [4] concerne l’ensemble des versions de Windows. Il ne serait pas étonnant de voir apparaitre dans les semaines à venir une exploitation concernant Windows 8 et Windows 10.

Un système vulnérable peut être identifié sur le réseau grâce à l’intégration d’un scanner dans le framework metasploit « smb_ms17_010 » [5] :

Exploitation avec EternalBlue et DoublePulsar

L’exploitation est d’une facilité déconcertante grâce au framework FuzzyBunch, présent lui aussi dans les outils publiés. En effet, l’étape la plus complexe est de trouver une machine Windows XP ou 7 en 32 bits et une version obsolète de Python et PyWin (2.6) pour le lancer.

L’exploitation est composée de deux étapes :

Déploiement d’une backdoor avec le module EternalBlue ;
Injection d’une dll malveillante avec le module DoublePulsar.

Après l’installation des prérequis, FuzzyBunch est situé dans le répertoire Windows et se lance avec la commande suivante « python fb.py ». Suite à la configuration d’un projet et de la cible (ici le p, le framework d’exploitation se rapproche très fortement de metasploit :

Comme énoncé précédemment, le déploiement de la backdoor se réalise via le module EternalBlue sélectionnable avec la fonction use :

La configuration par défaut est amplement suffisante pour une première prise en main, une description des différentes options peut être trouvée ici [6]. Il est maintenant possible d’admirer le travail :

Le déploiement de la backdoor s’effectue via la version 1 et 2 du protocole SMB [7]. L’utilisation de la backdoor est ensuite effectuée avec le module DoublePulsar qui permet d’injecter une dll malveillante dans un processus prédéfini :

La dll injectée a été préalablement générée avec msfvenom pour ouvrir une session meterpreter sur un metasploit en écoute :

L’injection de la dll a été accomplie avec succès et il est possible de le confirmer avec l’ouverture de la session meterpreter vers la cible :

La session meterpreter permet ainsi d’exécuter des commandes sur la cible vulnérable avec les droits « NT AUTHORITY\SYSTEM», le plus haut niveau de privilège sur Windows.

Remédiation

La solution la plus efficace est de déployer immédiatement le patch MS17-10 et de désactiver la version 1 du protocole SMB sur l’ensemble de votre parc. Il peut même s’avérer souhaitable de vérifier qu’aucune backdoor n’est pas déjà présente sur les systèmes les plus sensibles [8].

Conclusion

Cette dernière divulgation par le groupe « The Shadow Brokers » rend triviale l’exploitation d’une vulnérabilité critique sur l’environnement Windows. Cette vulnérabilité n’est cependant pas une 0-day car elle a été corrigée il y a un tout juste un mois par Microsoft. L’importance de déployer régulièrement les patchs sur ses environnements est encore une fois démontrer !

Rémi ESCOURROU

Sources

[1] http://www.securityinsider-solucom.fr/2017/04/cert-w-actualite-10-14-avril-2017.html

[2] https://github.com/x0rz/EQGRP_Lost_in_Translation

[3] https://docs.google.com/spreadsheets/d/1sD4rebofrkO9Rectt5S3Bzw6RnPpbJrMV-L1mS10HQc/

[4] https://technet.microsoft.com/fr-fr/library/security/ms17-010.aspx

[5] https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/smb/smb_ms17_010.rb

[6] http://www.pwn3d.org/

[7] https://zerosum0x0.blogspot.fr/2017/04/doublepulsar-initial-smb-backdoor-ring.html?m=1

[8] https://nmap.org/nsedoc/scripts/smb-double-pulsar-backdoor.html

Cette présentation courte (30 minutes) était assurée par Vladimir KATALOV, CEO de l’entreprise ElcomSoft basée à Moscou (Russie) et spécialisée dans la récupération de mots de passe ainsi que de l’analyse et de la restauration de systèmes protégés par chiffrement. La société ElcomSoft travaille notamment pour les entités suivantes :

NSA (National Security Agency);
EUROPOL ;
INTERPOL ;
...

Durant cette demi-heure, Vladimir KATALOV a présenté le modèle de chiffrement implémenté sur les équipements Apple en effectuant un focus particulier sur la récupération des secrets via les mécanismes iCloud.

Introduction

Alors que de nombreuses données sont présentent sur les smartphones (contacts, calendrier, historiques des appels…), il est parfois nécessaire de pouvoir les récupérer, notamment en cas d’investigation.

Pour cela, l'acquisition de données (chiffrées ou non) est systématiquement la première étape avant l'extraction des secrets. Pour cela, différentes méthodes peuvent être utilisées:

Acquisition via JTAG / Chip-Off / Hex dump : ces procédures permettent d'extraire la mémoire des équipements via un accès physique ; elles ne s’avèrent pas exploitable lorsque les données sont chiffrées. Par ailleurs, des erreurs peuvent survenir lors la capture et provoquer la récupération d’une image corrompue voir causer des dommages sur la mémoire à extraire.
Acquisition logicielle : ces procédures visent à utiliser un outil logiciel permettant d’extraire la mémoire d’un équipement. En plus d’offrir des possibilités plus limitées que l’extraction physique, les compatibilités logicielles sont souvent limitées. Par ailleurs, l’utilisation d’un logiciel implique le contournement de la mire de verrouillage de l’écran.
Utilisation des fonctionnalités « Cloud » : cette méthode permet de récupérer les données sans nécessité d'accès physique à l'équipement via la récupération des données sauvegardées sur les interfaces de type « cloud » (ex. : iCloud, Google Drive…).

Données sauvegardées dans les Cloud

De plus en plus de données présentent sur les smartphones et autres équipements mobiles sont synchronisées sur des plateformes Cloud (proposées par les éditeurs leader tels due Google, Apple et Microsoft). Les données transmises peuvent être de différentes natures :

Les données de sauvegardes (« backups ») : ces données correspondent aux éléments sauvegardés pour la restauration d’un système complet. Ainsi, pour ce type de sauvegarde, la quasi-totalité des données sont transmises vers plateforme Cloud.
Les données de synchronisation : ces données correspondent à certaines informations partagées entre les différents appareils synchronisés sur le compte Cloud. Elles peuvent être de différentes natures (détaillés dans les sections suivantes).
Les données partagées : ces données correspondent aux fichiers partagés sur le Cloud ; seuls les fichiers définis par l’utilisateur sont sauvegardés (type Google Drive…).

Données de sauvegardes (backup)

Les données de sauvegardes contiennent principalement les images complètes systèmes des équipements (notamment sur Apple). En revanche, les données suivantes ne sont pas communément accessibles :

Données des applications tierces ;
Mots de passe (où alors sur des parties additionnelles chiffrées).

Cependant, dans la majorité des cas, aucune fonctionnalité native ne permet la récupération des images sauvegardées (notamment via les interfaces Web de type iCloud) ; des outils tiers (comme celui développé par la société ElcomSoft) peuvent alors être nécessaires.

Données synchronisées

En dehors des sauvegardes, d’autres données sont automatiquement sauvegardées sur les systèmes de type Cloud via les fonctions de synchronisation, notamment:

Les contacts;
L’historique des appels;
Les messages (SMS, iMessage, Hangout…);
Les mails ;
Les activités Internet (historique de navigation…) ;
Les mots de passe ;
…

Bien que les données sauvegardées par cette méthode soient plus restreintes que celles relatives aux backups complets, de nombreuses données sensibles et potentiellement intéressantes peuvent être récupérées. Par ailleurs, ces données sont bien souvent répliquées sur les autres équipements qui peuvent alors constituer un autre vecteur d’attaque.

Protection du « porte-clés » Apple

La fonctionnalité de porte-clés Apple (ou Keychain) permet la conservation des secrets de l’utilisateur de manière sécurisée ; elle permet en particulier de limiter la saisie des mots de passe applicatifs (Safari, Wi-Fi…). Les mots de passe et secrets sont alors conservés dans le porte-clés et accessibles à la demande de l’utilisateur. Les méthodes de gestion des porte-clés diffèrent légèrement entre les OS :

Protection du porte-clés Apple en fonction des plateformes

Porte-clés iOS

Sur la plateforme iOS, le porte-clés est un fichier de type XML et il possède la structure suivante :

Différentes classes de protection peuvent être implémentées, notamment :

Attributs de protection des données

Note: L’attribut _ThisDeviceOnly permet de chiffrer les donnéesà l'aide d'une clé matérielle spécifique à l’équipement. Celle-ci peut être extraite sur les périphériques 32 bits uniquement.

Fichiers de sauvegardes iTunes

L’outil iTunes développé par Apple permet d’effectuer des sauvegardes locales (sur un poste) des données présentes sur les équipements mobiles de type iPhone, iPod et iPad. De nombreuses données sont ainsi sauvegardées, notamment les certains secrets des utilisateurs (keychain).

Afin de limiter les risques de récupération des données, les secrets sont sauvegardés de façon chiffrée (via le mécanisme de chiffrement AES) et conservés dans les fichiers nommés « manifest.plist» ; la clé de chiffrement est quant à elle présente dans l’attribut « BackupKeyBag » lui-même protégé par une clé dérivée du mot de passe mis en place par l’utilisateur.

La génération de la clé de chiffrement / déchiffrement du « keyBag » est générée de la manière suivante :

Mécanismes cryptographiques implémentés en fonction des OS

Note : Une faiblesse introduite sur iOS 10.0 permettait le stockage du condensat cryptographique (sha256) du mot de passe de chiffrement dans une base de données non protégée.

Protection des données iCloud

La majorité des données transmises vers la plateforme iCloud sont protégées via le mécanisme de chiffrement AES utilisant une clé de 128 bits. Le trousseau iCloud utilise quant à lui une clé de 256 bits afin de conserver les informations plus sensibles (données de bancaires, mots de passe…). La clé de chiffrement est conservée non chiffrée dans le bloc contenant les données sauvegardées.

Afin de sécuriser les données conservées, certaines mesures de sécurité sont mises en place, notamment :

Des notifications par email sont envoyées lors d’un accès aux données (à l’exception d’un accès via un jeton d’authentification) ;
Un mécanisme de verrouillage des comptes est mis en place afin de limiter les accès frauduleux (blocage en cas d’activités suspectes) ;
Un mode d’authentification à deux facteurs est proposé ;
…

Note : Le jeton d’authentification peut notamment être récupéré sur un autre équipement sur lequel le même compte a été utilisé.

Protection des données sans activation de l’authentification deux facteurs

Apple propose le mode d’authentification deux facteurs mais il est possible de le désactiver ; un mot de passe d’accès au compte peut alors être défini. Le code de sécurité est en effet facultatif, cependant, si aucun code n’est défini l’utilisateur doit confirmer chaque ajout de nouvel équipement via un équipement déjà enrôlé.

L’avantage principal d’utiliser un code de sécurité réside essentiellement de l’envoi du porte-clés vers le service « Apple Escrow » (détaillé dans la section suivante), permettant la récupération des données en cas de perte des équipements (voir des numéros de téléphone associés…) avec l’aide du service Apple.

Note : Bien qu’aucune vulnérabilité n’impacte directement ce mode de fonctionnement, cette méthode n’est pas recommandée par Vladimir KATALOV en raison des erreurs fréquentes lors de la phase de paramétrage.

Protection des données avec activation de l’authentification deux facteurs

La mise en place du mode d’authentification deux facteurs est plus aisée que la méthode précédente, il est simplement nécessaire de choisir un numéro de téléphone sur lequel l’utilisateur recevra les notifications de confirmation. Cette manipulation ne peut pas être effectuée depuis l’interface Web du service iCloud mais uniquement depuis un équipement Apple.

Par ailleurs, afin d’ajouter un équipement sur un même compte iCloud, il est nécessaire d’entrer le code de déverrouillage de l’un des équipements précédemment enrôlés.

Fonctionnement du porte-clés iCloud

Le porte-clés iCloud offre la possibilité aux utilisateurs de synchroniser de manière sécurisée leurs mots de passeentre plusieurs appareils iOS et ordinateurs Mac (sans divulguer ces informations à Apple). Le protocole a été conçu afin de permettre une protection vis-à-vis des scénarios suivants :

Compromission du compte iCloud de l’utilisateur ;
Compromission du service iCloud (par un employé ou une attaque externe) ;
Accès d’un tiers aux comptes de l’utilisateur.

Cercle de confiance

Afin de permettre le partage des données entre les différents équipements, un cercle de confiance est établit entre les différents équipements (lorsque l’authentification deux facteurs est activée). Pour cela, le mécanisme suivant est utilisé :

Initialisation du cercle de confiance :

Le premier appareil établit un cercle de confiance ;
Le premier appareil crée une identité de synchronisation (couple clé publique / privée) ;
La clé publique de l’identité de synchronisation est placée dans le cercle et signée par :

La clé privée de l’autorisation de synchronisation elle-même ;
Une clé asymétrique sur courbe elliptique (via P256) générée à partir du mot de passe du compte iCloud (les paramètres utilisés pour la génération sont également stockés dans le cercle).

Le cercle signé est placé dans une zone de stockage (KVS) sur iCloud.

Activation du cercle sur un autre appareil :

L’appareil crée sa paire de clé d’identification de synchronisation ;
L’appareil crée un ticket de candidature (constitué de la clé publique de l’identité de synchronisation de l’appareil) ;
L’utilisateur s’authentifie via la soumission de son mot de passe iCloud ;
En cas de succès de l’authentification, le ticket est placé dans iCloud.
Lorsque le premier appareil constate la présence du ticket, il affiche un message à l’utilisateur afin de confirmer qu’une demande a été effectuée ;
Suite à la confirmation, l’utilisateur doit entrer sont mot de passe iCloud afin d’effectuer la vérification du ticket de candidature ;
En cas de succès de l’étape précédent, le premier équipement ajoute la clé du nouveau membre au cercle de confiance en la signant avec :

Sa clé de synchronisation
La clé secrète générée à partir du mot de passe iCloud.

Ajout d’un n-ième membre :

La même procédure que pour l’ajout du deuxième équipement est rejouée (la validation peut être effectuée sur l’ensemble des équipements précédemment enrôlés).

En revanche, seuls les éléments possédant l’attribut kSecAttrSyncronizable sont synchronisés par ce mécanisme afin de limiter la réplication de certaines informations possédant un besoin de confidentialité plus élevé. La mise en place de ce protocole permet ensuite le transfert des secrets entre appareils sans possibilité pour Apple de récupérer les données (au moins d’une façon directe).

Service « Escrow proxy »

Le service « Escrow proxy» permet la récupération des mots de passe par l’utilisateur, il n’est cependant disponible que suite à de la mise en place d’un code de sécurité (par défaut une série de quatre chiffres). La clé de chiffrement du trousseau est transmise vers le service « escrow » chiffrée avec le code de sécurité définit :

Transmission de la clé de chiffrement vers le service « escrow »

L’API du service « escrow » permet ensuite d’effectuer différentes actions telles que :

Ajouter un enregistrement ;
Récupérer un enregistrement ;
Récupérer la liste des numéros de téléphone de confiance ;
Récupérer les données (en cas de perte) ;
...

Lorsqu’un utilisateur souhaite récupérer les données sauvegardées, la procédure suivante est mise en place :

L’utilisateur (authentifié) récupère un jeton via l’appel GetAccountSettings ;
L’utilisateur utilise le jeton récupéré afin d’effectuer une synchronisation avec le service (afin de ne récupérer que les données nécessaires) ;
L’utilisateur s’authentifie via le protocole SRP : cette étape est complexe mais ne provoque pas de notification et ne requière pas les éléments suivants :

Un équipement enrôlé (le code de sécurité d’un des équipements enrôlé est cependant nécessaire) ;
Le code de sécurité iCloud ;

L’utilisateur récupère les données et effectue les étapes de déchiffrement nécessaires.

Ainsi, un attaquant en capacité de récupérer un jeton d’accès au service iCloud peut récupérer les données stockées sans provoquer de notification chez l’utilisateur légitime.

Conclusion

Actuellement différentes méthodes peuvent être utilisée afin de récupérer les données conservées :

Ajouter un nouvel équipement au « cercle de confiance » ; il est alors nécessaire de contourner valider l’étape de d‘authentification à deux facteurs provoquant ainsi des notifications sur les autres équipements.
Récupérer les sauvegardes iCloud (sous réserve d’existence), il est alors nécessaire de :

Passer l’authentification deux facteurs (comme ci-dessus) ;
Récupérer la clé de chiffrement d’un équipement (récupérable uniquement sur les mobiles 32 bits).

Accéder à une sauvegarde locale, cependant, il alors nécessaire de :

Posséder un accès physique à un équipement (PC / Mac) ;
Posséder la clé de déchiffrement (si la sauvegarde est protégée).

Trouver une vulnérabilité dans le protocole de gestion du cercle de confiance ; la façon dont était présenté ce dernier point laisse a pensé que le protocole pourrait être vulnérable mais aucune information supplémentaire n’a été divulguée durant la conférence.

Mahdi BRAIK

Sources

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 !

Retrouvez également le focus de la semaine, le compte-rendu par Mahdi Braik de la conférence "When Two-Factor Authentication is a Foe: Breaking Apple’s iCloud Keychain" présentée à la Hack-In-The-Box 2017 Amsterdam.

Veille cybercriminalité

Un nouveau malware écrit en Lua infecte des hôtes Linux sur de multiples architectures

Baptisé Linux/Shishiga, ce malware infecte des machines Linux de multiples architectures (MIPS, ARM, SPARC, SH-4, M68k, PowerPC et x86) ayant un service SSH ou Telnet accessible. Le malware embarque des dictionnaires d’authentifiants faibles, et infecte d’autres machines en scannant des plages aléatoire d’IP sur Internet et en tentant de s’authentifier sur les hôtes exposant les services cités.

Une fois installé, le malware expose plusieurs backdoors, contacte son C&C afin de récupérer sa liste de tâches, et maintient à jour ses fichiers de configuration via le protocole BitTorrent.

Sources :

https://www.welivesecurity.com/2017/04/25/linux-shishiga-malware-using-lua-scripts/

Les exploits publiés par ShadowBrokers sont utilisés activement sur Internet

Les exploits publiés il y a quelques semaines par le groupe ShadowBrokers sont actuellement utilisés sur Internet par de nombreux hackers opportunistes. Intégrés dans un framework proche de Metasploit nommé FuzzBunch, ces exploits sont aisément utilisables et ont été activement utilisés depuis leur parution. Selon la société below0day[1], plus de 50 000 machines Windows exposées sur Internet présentent une installation de la backdoor DoublePulsar, installée par les exploits susmentionnés.

Un script de détection d’infection[2], développé par la société Countercept, est actuellement disponible sur GitHub.

Sources :
[1] https://below0day.com/2017/04/23/doublepulsar-global-implants/
[2] https://github.com/countercept/doublepulsar-detection-script/
https://threatpost.com/nsas-doublepulsar-kernel-exploit-in-use-internet-wide/125165/

Les exploits publiés par ShadowBrokers sont utilisés activement sur Internet

Un script de détection d’infection[2], développé par la société Countercept, est actuellement disponible sur GitHub.

Une nouvelle vague de propagation du ransomware Locky

Une recrudescence significative du ransomware Locky et du botnet Necurs a été signalée, avec plus de 35 000 emails envoyés en quelques heures. Ces derniers contiennent un fichier PDF joint (ou un lien vers ce fichier), qui contient lui-même un document Word incluant des macros malveillantes.

Cette technique d’infection en « poupée russe », nécessitant plusieurs interactions de l’utilisateur pour être effective, a pu contourner les détections des moteurs d’analyse en sandbox effectuées par de nombreux filtres anti-spam.

Sources :
https://threatpost.com/locky-ransomware-roars-back-to-life-via-necurs-botnet/125156/
https://nakedsecurity.sophos.com/2017/04/24/ransomware-hidden-inside-a-word-document-thats-hidden-inside-a-pdf/

Le groupe APT28 (ou Pawn Storm, Fancy Bears, etc…) prend pour cible la campagne de Emmanuel Macron

Le groupe APT28 serait à l’origine d’une campagne de phishing visant à récupérer des authentifiants des membres du groupe politique En Marche, notamment via l’enregistrement de domaines tels que « onedrive-en-marche.fr » ou « mail-en-marche.fr ».

Sources :
https://www.theregister.co.uk/2017/04/25/apt28_macron_hack/
http://blog.trendmicro.com/pawn-storm-power-social-engineering/

Veille vulnérabilité

Une vulnérabilité dans l’application Hyundai Blue Link permet à un attaquant de géolocaliser, déverrouiller et démarrer la voiture de sa victime

L’application mobile Hyundai Blue Link dans ses versions 3.9.4 et 3.9.5 utilise une clé de chiffrement symétrique codée en dur afin de protéger des informations utilisateurs avant de les transmettre en HTTP à un serveur de Hyundai pour journalisation.

Un attaquant ayant extrait la clé symétrique d’une instance de l’application est donc en mesure de déchiffrer ces communications, en écoutant par exemple le trafic effectué par l’application de sa victime sur un réseau ouvert (Wi-Fi public). Les informations déchiffrées contiennent entre autres le login, le code PIN, ainsi que l’historique des positions GPS du véhicule de la victime : l’attaquant pourrait alors retrouver ce véhicule, le déverrouiller et le démarrer, en utilisant les authentifiants usurpés.

Sources :
https://community.rapid7.com/community/infosec/blog/2017/04/25/r7-2017-02-hyundai-blue-link-potential-info-disclosure-fixed

Suite à un faux positif, l’antivirus WebRoot supprime des fichiers systèmes Windows

A la suite d’une mise à jour des signatures de virus le 25 avril dernier, l’antivirus WebRoot s’est mis à considérer des fichiers du système Windows comme des chevaux de Troie, et mettre ceux-ci en quarantaine, rendant les systèmes instables. Ces fichiers étaient néanmoins signés cryptographiquement par Microsoft.

L’éditeur dispose de 30 millions d’utilisateurs, et travaille actuellement au déploiement d’un correctif permettant de réparer les dommages causés.

Sources :
https://www.theregister.co.uk/2017/04/25/webroot_windows_wipeout/
https://www.webroot.com/blog/2017/04/25/critical-service-announcement/

Zimperium publie les deux premiers exploits issus de son programme d’acquisition d’exploits « n-days » pour mobiles

La société israélienne Zimperium, dans le cadre de son programme de rachat d’exploits « n-days » (i.e. exploitant des vulnérabilités déjà connues et corrigées) a publié cette semaine ses deux premiers exploits. Ceux-ci permettent l’élévation de privilèges sur Nexus 9/Android 6.0, et la désactivation de SELinux sur Nexus 5x/Android 6.0.1.

Sources :
https://blog.zimperium.com/nday-2017-0102-elevation-of-privilege-vulnerability-in-nvidia-video-driver/
https://blog.zimperium.com/nday-2017-0105-elevation-of-privilege-vulnerability-in-msm-thermal-driver/

Retour d’expérience d’un auditeur sur les 10 erreurs de développement les plus fréquentes en matière de cryptographie

https://littlemaninmyhead.wordpress.com/2017/04/22/top-10-developer-crypto-mistakes/

Indicateurs de la semaine

Le leak de la semaine – Manuel d’utilisation de Weeping Angel

Dans sa série de leaks « Vault7 » sur les outils de hacking prétendument utilisés par la CIA, WikiLeaks avait dévoilé l’existence d’un outil permettant de transformer une Smart TV Samsung Série F en dispositif de mise sur écoute microphonique, nommé Weeping Angel.
WikiLeaks a publié en début de semaine le manuel d’utilisation complet de l’outil. D’après le document, celui-ci aurait été réalisé par le MI5 avant d’être partagé avec la CIA.

Sources :
https://wikileaks.org/vault7/releases/#Weeping%20Angel
http://securityaffairs.co/wordpress/58210/intelligence/cia-weeping-angel-guide.html

L’exploit de la semaine - CVE-2017-0199

Une vulnérabilité affectant quasiment toutes les versions de Microsoft Office a été publié il y a quelques semaines. Cette vulnérabilité affecte le composant Microsoft Word, et permet l’exécution de code arbitraire sur simple ouverture d’un fichier RTF, sans action supplémentaire de l’utilisateur (aucune macros à activer manuellement par l’utilisateur).
Des outils ont depuis été publiés afin d’automatiser la génération de document RTF malveillant, rendant l’exploitation aisée.

Sources :
https://github.com/bhdresh/CVE-2017-0199

Suivi des versions

Produits	Version actuelle
Flash Player	25.0.0.148
Adobe Reader	2017.009.20044
Java	Version 8 update 131
Mozilla Firefox	52.0.2
Google chrome	58.0.3029.81
Virtual Box	5.1.20

Maxime MEIGNAN

Depuis 1 an, le groupe « The Shadow Brokers » fait parler de lui au travers la publication de méthodes d’exploitation de vulnérabilités de type 0-day appartenant à d’autres groupes de hackeurs. Cet article a pour but de relier les différentes informations que nous avons pu déjà commenter dans d’autres articles du blog.

Qui est derrière « The Shadow Brokers » ?

The Shadow Brokers est un groupe de hackeurs apparu en 2016 qui a publié de nombreux exploits de vulnérabilités notamment certaines 0-day.

Les outils publiés sont utilisés par le groupe de hackeur « Equation Group » et par la NSA. Ils ciblent particulièrement les équipements réseau (pare-feu Cisco, …) et les systèmes d’exploitation Windows et Solaris.

L’identité de(s) la personne(s) derrière le groupe n’est pas connue, les deux théories les plus répondues sont :

Un ancien prestataire de la NSA aurait volé les documents et les publie ;
Edward Snowden [7] pense que les données proviennent d’une puissance (Russe) afin de pouvoir avertir la NSA qu’ils sont en mesure de prouver leur responsabilité dans certaines attaques informatiques.

Retours sur les moments clefs

Première fuite de données – Equation Group

Le 13 Août 2016, le compte Twitter « @theshadowbrokerss » publie un tweet indiquant deux archives :

Une première archive qui contient des exploits ciblant principalement les équipements réseaux de type « Pare-feu » ;
Une deuxième archive chiffrée, mise aux enchères pour 1 million de Bitcoin [6], qui contient des exploits utilisés par « Equation Group » [2].

Deuxième fuite de données – TrickOrTreat

Le 31 Octobre 2016, un message sur le forum Reddit [3] indique la liste de serveurs compromis par « Equation Group » et fait référence à 7 outils : DEWDROP, INCISION, JACKLADDER, ORANGUTAN, PATCHICILLIN, RETICULUM, SIDETRACK et STOCSURGEON.

Troisième fuite de données

Afin de remonter le niveau de l’enchère, le groupe publie une liste d’une soixantaine de nom de dossiers contenu dans l’archive chiffrée.

Quatrième fuite de données – Don’t forget your base

Le 8 Avril 2017, le groupe publie le mot de passe de l’archive publiée en Aout 2016 sur son compte Medium [4]. Ce message agit comme protestation envers l’administration Trump, en réponse au dernier bombardement en date en Syrie :

Les exploits ciblent principalement le système d’exploitation Solaris, l’opérateur pakistanais Mobilink et les journaux d’évènements wtmp du système Unix.

Cinquième fuite de données – Lost in translation

Le 14 Avril 2017, le groupe a posté un lien vers le site Steemit [1] au travers de son compte Twitter :

Cette archive contient trois dossiers : « oddjob », « swift » et « « windows ». Parmi les données sont inclus différents outils et méthodes d’exploitation de vulnérabilités donc notamment un exploit pour la vulnérabilité MS17-010 [5].

Les outils publiés

Au travers de leurs publications, The Shadow Brokers ont apporté un grand nombre d’exploit. La communauté ([8] et [9]) a pu relier les exploits et vulnérabilités suivants :

Ces exploits ciblent de nombreux systèmes, notamment le système d’exploitation Windows sur plusieurs versions. Dès la publication de la 5ème fuite de données, Microsoft a publié un article [10] détaillant les vulnérabilités et les corrections associées.

Conclusion

À ce jour, le groupe The Shadow Brokers a publié gratuitement des outils qu’il estimait à 1 million de Bitcoin. La motivation derrière leurs actions n’est pas encore bien identifiée mais il est clair que ce collectif souhaite exposer au public les attaques réalisés par les puissances telles que la NSA.

Vincent DEPERIERS

Sources :

[1] https://steemit.com/shadowbrokers/@theshadowbrokers/lost-in-translation

[2] http://www.securityinsider-solucom.fr/2016/10/7-exploits-pour-pare-feu-publies-par.html

[3] https://www.reddit.com/r/DarkNetMarkets/comments/5a9wnc/message_5_trick_or_treat/

[4] http://www.securityinsider-solucom.fr/2017/04/cert-w-actualite-10-14-avril-2017.html

[5] http://www.securityinsider-solucom.fr/2017/04/hacking-like-nsa-ms17-10.html

[6] https://blockchain.info/address/19BY2XCgbDe6WtTVbTyzM9eR3LYr6VitWK

[7] https://twitter.com/Snowden/status/765513662597623808

[8] https://github.com/misterch0c/shadowbroker

[9] https://github.com/x0rz/EQGRP

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 !

Retrouvez également le focus de la semaine, sur "The Shadow Brokers".

Veille cybercriminalité

Orange is the new black

En 2015, les 4 premiers épisodes de la saison 5 de Game of Thrones étaient disponibles sur Internet avant leur sortie, cette semaine une demande de rançon a été envoyée à Netflixpour la série « Orange is the New Black ». Le hackeur, « thedarkoverlord », prétend qu’il a aussi récupérer des séries des chaines Fox, National Geographic et ABC et souhaite réaliser le même type de délit avec ces chaines télévisées.

Le 29 Avril après que Netflix n'ait pas voulu payer la rançon, l'attaquant a posté un lien torrent pointant vers les épisodes 2 à 10.

Sources :

Exploitation de la CVE-2017-0199 dans des campagnes de phishing

Comme nous l’évoquions la semaine dernière [1], une vulnérabilité critique permet l’exécution de code lors de l’ouverture d’un document Word piégé. Il n’aura fallu que quelques jours pour que les groupes d’attaquant exploite cette vulnérabilité dans leur campagne de mails malveillants.

ProofPoint [2] a observé l’utilisation de cette faille et en particulier par le groupe Chinois TA459 qui cible des entreprises financières Russe.

Sources :

Malware-Hunter, le service permettant de lister les serveurs de C&C

Le projet Malware-Hunter[1], né de la fusion entre Shodanet Recorded Future, permet de scanner Internet à la recherche des serveurs de Command and Control (C&C). Pour cela, l’outil prétend être un hôte infecté qui demande de nouveaux ordres en s’adressant à chaque adresse IP comme si elle était un serveur de C&C. Ainsi, lorsque l’application reçoit une réponse positive, le serveur est alors taggé en tant que C&C.

Les résultats préliminaires [2] indiquent déjà des centaines d’adresses IP répondant aux malwares tels que Gh0st RAT, Dark Comet ou encore njRAT. De plus, ils sont aussi accessibles sur le moteur de recherche Shodan [3].

Sources :

Veille vulnérabilité

Vulnérabilité exploitable à distance sur les plateformes Intel depuis 2008

Une vulnérabilité critique (CVE-2017-5689 [1]) a été découverte sur les outils de gestion d'Intelreposants sur Management Engine (ME), Active Management Technology (AMT) et Standard Manageability (ISM). L’exploitation de cette vulnérabilité permet à un attaquant de prendre le contrôle de ces outils de gestions à distance.

Ces outils offre aux administrateurs un moyen de gérer leur parc uniquement sur un réseau d’entreprise, les vulnérabilités ne sont donc pas présentes sur les puces Intel des ordinateurs personnels.

Selon Intel, la vulnérabilité est présente dans les versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5 et 11.6 des systèmes de gestion AMT, ISM et SBT. Les versions avant la 6 et après la 11.6 ne sont pas affectées.

Intel a mis à disposition un guide pour déterminer si la machine est vulnérable [2] et un guide de sécurisation [3].

Sources :

Indicateurs de la semaine

Le leak de la semaine – Scribbles

Cette semaine Wikileaks a publié le code source du programme de la NSA appelé « Scribbles ». L’objectif de cet outil est de pouvoir générer un filigrane unique pour chaque copie d’un document afin de savoir si un document aurait fuité. Cette mesure permettrait donc d’identifier les potentiels lanceurs d’alertes qui sont en possession de documents confidentiels.
Le filigrane consiste en une image transparente insérée dans le document pointant vers une URL unique. Ce système a été testé avec succès les versions de Microsoft Office 1997 à 2016, mais sur les versions de Libre Office et OpenOffice, le filigrane apparait sous forme d’une image et d’une URL.

Sources :

https://wikileaks.org/vault7/#Scribbles

L’exploit de la semaine – Compromettre un DC depuis DNSAdmin

Cet article présente comment des comptes non administrateurs de domaine peuvent être utilisés pour compromettre des contrôleurs de domaine, en exploitant des fonctionnalités liées à l’administration des rôles portés par les DC.
Ici, le rôle utilisé est celui de serveur DNS, pour lequel les comptes « DNSAdmin » peuvent réaliser une injection arbitraire de DLL.

Sources :

https://medium.com/@esnesenon/feature-not-bug-dnsadmin-to-dc-compromise-in-one-line-a0f779b8dc83

L'attaque de la semaine – Bug Bounty sur Flickr pour 7,000$

Michael Reizelman a remonté à Yahoo trois vulnérabilités mineures qui, une fois enchainées, permettent de prendre le contrôle d’un compte Flickr [1]. Ce scénario d’exploitation lui a permis de toucher une prime de 7,000$ de la part de Yahoo via le site de Bug Bounty HackerOne.
Les vulnérabilités ne semblent pas critiques lorsqu’elles sont présentées unitairement :

Mauvais contrôle du paramètre de redirection de l’utilisateur après l’authentification de celui-ci, ce qui permet à l’attaquant de contrôler la redirection sur une page de la forme https://www.flickr.com/*
Chargement d’une image dont l’URL est contrôlé par l’attaquant sur les pages des forums de Flickr
Absence de contrôle du paramètres « Content Security Policy » sur les pages du forum « https://www.flickr.com/help/forum/en-us/ »

Ainsi, lorsque l’utilisateur clique sur un lien d’authentification malveillant, ses jetons de connexions sont envoyés à l’attaquant au travers de l’en-tête HTTP « Referer ».

Sources :

http://blog.mish.re/index.php/2017/04/29/yahoo-bug-bounty-chaining-3-minor-issues-to-takeover-flickr-accounts/

Suivi des versions

Produits	Version actuelle
Flash Player	25.0.0.171
Adobe Reader	2017.009.20044
Java	Version 8 update 131
Mozilla Firefox	53.0.2
Google chrome	58.0.3029.96
Virtual Box	5.1.22

Vincent DEPERIERS

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 !

Retrouvez également le focus de la semaine, compte-rendu d'une conférence présentée à HITB 2017 sur les injections de fautes.

Veille cybercriminalité

HP supprime un keylogger sur plusieurs de ses modèles

Hewlett-Packard a émis une mise à jour de sécurité sur plusieurs des modèles d’ordinateurs portables, dont les Elitebook, ProBook et Zbook, afin de retirer un composant (MicTray64.exe) agissant comme keylogger au sein du driver audio Conexant HD. Ce composant enregistrait les frappes utilisateurs dans un fichier (C:\Users\Public\MicTray.log) présent sur le poste, exposant des informations sensibles (mots de passe, numéros de cartes bancaire, etc) pour quiconque dispose d’un accès au système de fichiers.
Cette fonctionnalité était utilisée à des fins de débogage et aurait été déployée par erreur sur les postes destinés aux utilisateurs.

Sources :

Jaff, le dernier ransomware de la famille Locky

Des chercheurs ont découvert un nouveau ransomware, baptisé « Jaff », dont le comportement et le portail de paiement sont très similaires à ceux des ransomwares Dridex, Locky et Bart. La campagne de contamination actuelle consiste en un email dont la pièce jointe est un fichier PDF. Ce dernier contient un fichier DOCM attaché, qui une fois ouvert demande l’activation des macros.
S’en suit le chiffrement des fichiers de la victime et la demande de rançon de 1.79 bitcoins (environ 3300$).

Sources :

Un malware WordPress vole les sessions des utilisateurs

Le malware dont il est question ajoute du code JavaScript à la fin d’un fichier légitime utilisé par WordPress. Cette portion de code filtre les requêtes effectuées par les robots des moteurs de recherche, puis envoie les cookies de l’utilisateur actuel sur un site externe. Ce dernier utilise la technique de typosquatting pour ressembler à l’un des noms de domaines WordPress officiels, code.wordpr(e)ssapi.com.

Sources :

https://threatpost.com/session-hijacking-cookie-stealing-wordpress-malware-spotted/125586/

Veille vulnérabilité

WordPress password reset – CVE-2017-8295

Une vulnérabilité affecte la fonctionnalité de remise à zéro du mot de passe des versions de WordPress avant 4.7.4 (comprise). L’attaquant, via l’écrasement d’une variable serveur, usurpe l’adresse email d’expéditeur du mail de remise à zéro. Trois scenarii ont été imaginés pour profiter de cette vulnérabilité :

Un déni de service préalable de la boîte aux lettres de la victime, provoquant un renvoi de l’email à l’expéditeur ;
Une réponse automatique, incluant le mail d’origine ;
Répéter l’attaque afin de provoquer une réponse manuelle de l’utilisateur auprès de l’expéditeur.

Sources :

https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html

Cisco WebEx – Fuite d’informations – CVE-2017-6651

Une vulnérabilité présente dans le générateur de fichiers « robots.txt », et exploitable sous certaines conditions, peut permettre à un attaquant de récupérer les URL de meetings programmés à l’avance. Il lui serait alors possible de participer de manière non autorisée à ces réunions.

Sources :

https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170510-cwms

Indicateurs de la semaine

Le leak de la semaine – #MacronLeaks

Le 5 mai 2017, 9 Go de données liées à la campagne électorale d’Emmanuel Macron ont été publiées[1] sur 4Chan, puis Wikileaks. Les métadonnées liées aux fichiers semblent indiquer que l’entreprise « Evrika ZAO », d’origine russe, est derrière ce piratage[2]. Des informations semblent indiquer que le piratage pourrait également être relié au groupe APT28 (Pawn Storm), et que les techniques utilisées sont similaires à celles qui ont pu être mises en œuvre à l’encontre d’un parti allemand[3] et pendant les élections présidentielles aux USA.
Il semblerait cependant que les données récupérées consistent en une stratégie « écran de fumée » mise en place par Mounir Mahjoubi, responsable du numérique de l’équipe « En Marche », afin de pallier ce type de campagne de piratage pré-élections[4].

Sources :

[1]http://archive.is/eQtrm

[2] https://arstechnica.com/security/2017/05/evidence-suggests-russia...

[3] http://blog.trendmicro.com/trendlabs-security-intelligence/pawn...

[4] http://www.zdnet.fr/actualites/en-marche-la-strategie-de-l-ecran-de-fum...

L’exploit de la semaine – CVE-2017-0290 – “Crazy bad vuln”

Deux chercheurs de l’équipe Project Zero (Google) ont découvert une vulnérabilité[1][2] permettant l’exécution arbitraire de code au sein du Malware Protection Engine de Microsoft (MMPE). Les chercheurs ont qualifié cette vulnérabilité de « wormable ».
La vulnérabilité exploite une faille dans la gestion des types du moteur de contrôle des fichiers, permettant l’exécution de code JavaScript. L’un des exploits de cette CVE rentre dans un unique tweet[3] et permet de réaliser un déni de service sur le serveur cible.
Microsoft a immédiatement produit un patch pour corriger la vulnérabilité[4].

Sources :

[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=1252&desc=5

[2] https://twitter.com/taviso/status/860679110728622080

[3] https://twitter.com/natashenka/status/861748397409058816

[4] https://technet.microsoft.com/en-us/library/security/4022344.aspx

L’attaque de la semaine – Google Docs

Le 3 mai, les utilisateurs du service Gmail ont été victimes d’une attaque de type phishing, conduite à large échelle[1]. L’attaque a duré pendant près d’une heure et a ciblé environ un million d’utilisateurs (0.1% du total), pour lesquels seules les informations de contact ont été accédées[2].
Elle se déroule en deux étapes :

La victime reçoit un email de phishing imitant une demande de partage Google Docs, de la part d’un contact potentiellement connu ;
Elle est redirigée vers une fenêtre d’autorisation OAuth, demandant à la victime d’autoriser l’application « Google Docs » pour la gestion des emails.

Les victimes de cette attaque ont été leurrés par la fiabilité du service d’autorisation OAuth utilisé par Google, et par le nom et logo de l’application malveillante. Des réflexions sont en cours sur les possibilités dont dispose Google pour prévenir ce type d’attaque sur le long terme, dont l’utilisation de certificats X.509 pour les utilisateurs de l’API OAuth.

Sources :

[1] https://threatpost.com/google-shuts-down-docs-phishing-spree/125414/

[2] https://threatpost.com/1-million-gmail-users-impacted-by-google-docs-phishing-attack/125436/

Suivi des versions

Produits	Version actuelle
Flash Player	25.0.0.171
Adobe Reader	2017.009.20044
Java	Version 8 update 131
Mozilla Firefox	53.0.2
Google chrome	58.0.3029.110
Virtual Box	5.1.22

Jean MARSAULT

Durant cette intervention Niek Timmers et Albert Spruyt de la société Riscure ont présenté les possibilités d’attaques par injection de fautes et leurs utilisations afin de contourner les mécanismes de secure boot.

Présentation des attaques par injection de fautes

Les attaques par injections de fautes consistent à modifier l’état de la mémoire afin de provoquer un changement du chemin d’exécution vers un chemin souhaité. Au cours du fonctionnement d’un système informatique des fautes peuvent survenir de manière occasionnelle et non contrôlée ; ces fautes provoquent en général le bug des applications ou sont simplement invisibles pour l’utilisateur. Cependant, dans certains cas, l’injection d’une faute peut permettre à un attaquant de provoquer un comportement inattendu pouvant être exploité en sa faveur. Dans l’exemple si dessous, la fonction secure_boot n’est normalement (d’un point de vue logiciel) appelée que si le test d’intégrité (effectué via l’appel à la fonction check_integrity) a réussi :

Néanmoins, si un attaquant est en capacité de modifier la valeur de la variable « test » directement en mémoire, la fonction secure_boot sera exécutée et l’attaquant aura réussi à contourner les vérifications effectuées en amont.

Afin de permettre l’injection de fautes, différentes méthodes peuvent être utilisées et sont présentées dans la suite de l’article.

Avantage des attaques par injection de fautes

Les attaques sur le matériel possèdent de nombreux avantages sur les attaques logicielles, notamment :

L’absence de maturité dans ce domaine : alors que depuis de nombreuses années, les éditeurs sont sensibilisés aux dangers des attaques logicielles (débordement de tampon, injection SQL…) et prennent en compte ce type de vulnérabilités, peu d’attention est actuellement portée à la sécurité contre les attaques matérielles ; ainsi, les cibles sont en général moins bien protégées contre ce type d’attaques.
Aucune vulnérabilité logicielle n’est nécessaire : les attaques par injection de fautes ne nécessitent pas la présence de vulnérabilités liées au développement logiciel des solutions.

En revanche, ces attaques sont généralement plus complexes à mettre en œuvre pour les raisons suivantes :

Les attaques matérielles sont plus intrusives (que les attaques logicielles) : les attaques étant directement mises en place sur le socle matériel, elles sont naturellement plus intrusives que les attaques logicielles ; elles peuvent notamment nécessiter / provoquer l’altération / la destruction des composants.
Un accès physique à l’équipement ciblé est nécessaire : afin de pouvoir injecter des fautes sur le composant, il est en effet nécessaire de pouvoir le manipuler.
Des outils (matériels) peuvent être nécessaires : comme expliqué dans la section suivante, de nombreuses méthodes d’attaques requièrent l’utilisation de composants et outils dédiés à l’analyse matérielle et à l’injection de fautes.

Méthodes d’injection de fautes matérielles

Modification d’horloge

Ces attaques consistent en la modification de la fréquence de l’horloge permettant de définir la fréquence d’exécution des instructions du processeur. En effet, l’horloge permet de cadencer l’exécution des instructions ; à chaque réception du signal, le processeur exécute l’instruction qu’il reçoit. Cependant, si le processeur reçoit un nouveau signal sans avoir pu exécuter l’instruction précédente, il abandonne l’exécution courante et commence à exécuter l’instruction suivante. De cette manière, une augmentation temporaire de la fréquence d’horloge peut permettre le « saut » d’une instruction.

Modification de la tension

Cette méthode consiste à diminuer la tension appliquée au module de lecture / écriture (mémoire) afin de provoquer l’apparition d’une faute. En effet, afin de lire ou d’écrire une valeur en mémoire un niveau de tension minimum est requis par le module ; si la tension n’est pas suffisante l’action n’est pas réalisée :

Figure 3 : Exemple d’injection de faute via la diminution de la tension d’alimentation d’un composant

Ainsi, si un attaquant réussi à suffisamment diminuer la tension (au moment de la lecture d’une valeur souhaitée en mémoire) une valeur erronée sera renvoyée et le flot d’exécution normal pourrait être alors contourné.

Injections électromagnétiques

Cette méthode consiste à injecter des fautes via la production d’un champ électromagnétique à proximité des composants afin d’altérer les valeurs stockées ou transmises (registres, bus…) :

Figure 3 : Exemple d’installation visant à injecter des fautes via l’utilisation d’un champ électromagnétique

Injections au laser

Cette méthode consiste à injecter des fautes via l’utilisation d’un laser pointé sur le matériel. En effet, l’éclairage d’un laser a le même effet que plusieurs types de radiations et peuvent ainsi être utilisés afin de modifier directement l’état physique des composants (registres, mémoire…) :

Figure 3 : Utilisation d’un laser afin de provoquer des fautes matérielles

Injection de fautes en pratique

Où injecter les fautes ?

Les méthodes présentées précédemment permettent ainsi de provoquer des fautes matérielles. De façon générale, ces fautes peuvent être injectées :

Via les bus de communication ;
Directement dans les registres ;
…

Les fautes sur le matériel peuvent ensuite affecter le flot d’exécution ou la logique mise en place par le développeur. Le code assembleur de l’exemple donné en introduction pourrait être le suivant :

L’instruction « mov ecx, eax » s’écrit avec la séquence d’octets suivante :

Si le second bit de poids le plus faible est modifié la séquence devient :

Cette séquence correspond à l’instruction « mov ebx, eax », le flow d’exécution altéré est alors :

Si une faute est injectée et que l’instruction « mov ecx, eax » est modifiée par l’instruction « mov ebx, eax » la valeur de retour de la fonction check_integrity ne sera pas placée dans le registre ecx (qui contiendra alors une valeur dépendante des instructions exécutée en amont). Ainsi, la comparaison effectuée n’est plus dépendante du résultat de l’appel à la fonction check_integrity et la fonction secure_boot pourrait alors exécutée de façon malveillante (contournement du mécanisme de vérification d’intégrité).

Remarque : il est à noter que dans le cas si dessus, une modification de la fréquence de l’horloge au moment de l’exécution de l’instruction « jz loc_exit » pourrait permettre de sauter cette instruction et ainsi de provoquer l’appel à la fonction secure_boot.

Cas pratique - Mécanismes de secure boot

Le mécanisme de « secure boot » permet d’assurer l’intégrité et l’authenticité d’un système démarrant sur un équipement. Ainsi, l’utilisation de fonctions cryptographiques permettant d’assurer ces fonctions est nécessaire à la mise en place d’un « secure boot ». Les éléments constituant ainsi que les étapes de démarrage d’un système de type secure boot peuvent être schématisés de la façon suivante :

Figure 3 : Éléments et étapes de démarrage d’un système de secure boot

Différentes méthodes utilisées afin de contourner des mécanismes de type secure boot ont ensuite été présentées :

Erreurs lors de la comparaison des condensats cryptographiques

Le package « mbeb TLS » offre différentes routines cryptographiques afin de simplifier la tâche des développeurs sur plateforme ARM. Le code suivant est un extrait d’une fonction de vérification de condensat cryptographique (RSASSA-PKCS1-v1_5) :

Le code assembleur une fois décompilé est le suivant:

Figure 3 : Code assembleur de la fonction « mbedtls_rsa_rsassa_pkcs1_v15_verify »

L’analyse du code ci-dessus permet d’identifier rapidement différents registres dont une modification du contenu pourrait affecter le résultat de la vérification finale, notamment :

Registres R2 et R7 (offset 0x132DA) : La modification de R7 en amont ou celle de R2 suite à cette instruction peut permettre de changer le flow d’exécution via la modification de la longueur sur laquelle s’effectue la comparaison en mémoire.
Registres R1, R2 et R5 (offsets 0x132E0 & 0x132E2) : la modification de ces registres contenant les adresses des chaines à comparer peut permettre de contourner la vérification effectuée par la fonction memcmp (en particulier si un attaquant peut modifier l’instruction « mov R0, R5 » vers l’instruction « mov R0, R1 » car dans ce cas R1 et R2 pointeront vers la même adresse).
Registre R0 (offset 0x132E6) : la valeur présente dans R0 lors de cette instruction influe directement sur le saut effectué.

Exploitation des boucles infinies pour l’injection de fautes

Les boucles infinies peuvent parfois être utilisées afin d’éviter le démarrage des modules comme dans l’exemple ci-dessous :

Le code désassemblé est le suivant :

Figure 3 : Code assembleur de la fonction utilisant une boucle infinie

Suite à la comparaison « cmp R0, #9 », une instruction de branchement est exécutée afin d’entrer ou non dans la boucle infinie. L’analyse des adresses des instructions montre que le bloc relatif à la boucle infinie est placé juste avant (en termes d’adresses et de bloc d’exécution) le bloc exécutant la fonction de boot. Ainsi, l’injection d’une faute sur l’instruction de branchement à l’offset 0x854 peut permettre à un attaquant de continuer l’exécution et de démarrer sur une partition malveillante. Par ailleurs, aucune contrainte de temps n’est imposée à l’attaquant grâce à la présence de la boucle infinie.

Attaques combinées

Les attaques matérielles peuvent être combinées aux attaques logicielles afin d’augmenter les possibilités d’exploitation. Un attaquant peut notamment injecter des fautes afin de construire son propre exploit. En effet, le code suivant n’est pas vulnérable à des attaques de type débordement de tampon :

Le code assembleur est alors :

Si l’attaquant est en capacité d’injecter une faute et de modifier (pour une valeur supérieure) le contenu du registre R2, il est alors possible d’exploiter une vulnérabilité de type débordement de tampon (dans le tas) :

Conclusion

Les possibilités d’exploitation de ces attaques sont variées et peuvent notamment permettre de :

Contourner les mécanismes de type secure boot ;
Extraire les clés cryptographiques des équipements de type HSM (Hardware Security Module) ;
etc

De plus, peu de technologies résistent actuellement ; certains mécanismes peuvent cependant être utilisés afin de limiter la surface d’attaque ou de diminuer leur probabilité de réussite :

Mettre en place des mécanismes d’authentification de code : cette méthode permet de détecter les erreurs et la modification du firmware, il est à noter que ce mécanisme pourrait lui-même faire l’objet d’une attaque par injection de fautes.
Diminuer la surface de code : la diminution du nombre d’instructions exécutées permet de réduite la probabilité de réussite des attaques par injection de fautes via la limitation du temps et du nombre de possibilités d’exploitation.
Diminuer les privilèges des exécutables : cette pratique permet de limiter les conséquences de l’exploitation d’une faute via la diminution des privilèges d’exécution.

Bien que ce type d’attaques soit souvent efficace, il est cependant important de mitiger leur probabilité. En effet, leur mise en place nécessite souvent des compétences spécifiques, de nombreuses heures d’études et de tests ainsi que du matériel actuellement relativement onéreux.

Mahdi BRAIK

Sources

Vous avez certainement pu le voir dans les médias ce week-end, une attaque de très large ampleur s’est produite à partir de vendredi midi dernier : Renault ferme des sites industriels, FedEx coupe ses serveurs, le National Health Service des UK fait la une de la BBC, Téléfonica est down… bref, près de 100 pays en sont victimes !
Le CERT-W est sur le pont depuis les premières heures de l’attaque et plusieurs de nos analystes sont intervenus ce week-end.

Cette attaque vise à la distribution du ransomware « Wannacry » (a.k.a wcry, wannacrypt, etc. [1]).

Pourquoi tant de bruit autour d’un ransomware ?

Ce n’est pas tant le ransomware qui est intéressant d’étudier dans cette affaire : il s’agit ni plus ni moins d’un ransomware classique.
En revanche, c’est sa méthode de diffusion et de propagation qui est intéressante : elle s’appuie sur ETERNALBLUE, l’exploit de MS17-010 développé par la NSA et rendu publique par The Shadow Brokers il y a quelques mois déjà (le patch est disponible depuis 2 mois).

Comment se prémunir ?

Les pratiques suivantes permettent de bloquer la propagation :

Mettre à jour les systèmes Windows (comme dit précédemment, le patch pour MS17-010 est disponible depuis plusieurs semaines).
Mettre à jour les signatures anti-virales (tous les éditeurs d’antivirus ont à date réagi et publié une signature pour détecter Wannacry).
Interdire les flux SMB entrants sur le SI (ou pouvant se propager au travers des différents VPN --> nous avons pu voir le cas chez certaines victimes).
S’assurer que les URL de diffusion du malware [2] NE SONT PAS bloquées : en effet, des chercheurs en sécurité ont pu rapidement déployer des sinkholes sur ces URL et notamment embarquer un killswitch empêchant l’infection des postes si et seulement si ces URL sont joignables.

Ajouter une entrée DNS et la faire pointer vers l'IP d'une application interne (le portail interne par exemple) car le malware ne passe pas par les proxies…

Si le réseau est segmenté, utiliser les points de coupure pour éviter une propagation généralisée (via les IPS en particulier). Même si à ce jour le malware n’est capable de se propager que dans la zone réseau dans laquelle il est connecté, cela reste une couche protection supplémentaire. Plusieurs victimes n’ont eu que leurs postes de travail impactés grâce à leur simple segmentation du réseau.
Enfin, préparer les sauvegardes !

Si vous découvrez des fichiers dont l’extension est en « .wncry », votre poste est alors infecté et le ransomware est déjà en cours d’exécution.
Prévenez votre équipe sécurité et n’hésitez pas à contacter le CERT-W (cert@wavestone.com) pour vous aider.

En cas d’infection, suivez les bonnes pratiques de réaction présentées ici : http://www.securityinsider-solucom.fr/2015/04/cert-solucom-retour-sur-lactualite-de_1.html

[1] Lors des premiers instants de l’attaque, plusieurs communications se sont confondues avec Jaff, un autre ransomware « simple » et également en cours de distribution par différents Exploit Kits (Necurs notamment).
[2] Ne pas bloquer : iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com et ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com

You have undoubtedly seen across the media this weekend an attack taking place on an extremely large scale last Friday lunchtime. Renault has closed some industrial sites, FedEx has shut down its servers, the UK National Health Service has made the front page and even Telefonica went down. Overall, around 100 countries fell victim to the attack!

CERT-W has been on the case since the early hours of the attack and several of us have worked on it over the weekend.

This attack aims to distribute the "Wannacry" ransomware (aka wcry, wannacrypt, etc. [1]).

Why has the ransomware gained so much exposure?

It is not so much the ransomware itself which is at stake here; it is more or less a classic ransomware.

Rather, it is the diffusion and propagation method which is the point of focus, leveraging ETERNALBLUE, the MS17-010 exploit [2] developed by the NSA and which has already been made public by The Shadow Brokers several months ago (the corresponding patch has been available for 2 months to date).

How can I protect myself?

The following steps help to limit the propagation of the attack:

Update Windows systems (as described earlier, the patch for MS17-010 has been available for several weeks now [2]). Several companies have realised afterwards that their WSUS infrastructure was not entirely operational, explaining why this patch was not rolled-out.
Update anti-viral signatures (all anti-virus vendors have reacted and published a signature to detect Wannacry)
Block incoming SMB flows (or flows that can propagate through various VPNs --> we have seen this occur for certain victims).
Ensure malware distribution URLs [3] ARE NOT blocked: indeed, security researchers have been able to quickly deploy sinkholes on these URLs and embark a killswitch, preventing infection of endpoints if, and only if, these URLs are accessible [4].

Because the malware does not cover the management of web proxies, a DNS entry must be added locally (internal DNS servers). This entry must point towards the IP address of an internal application (business application, intranet, etc.) in order to render the killswitch functional.

If the network is segmented, use segmentation cut off points to prevent a general propagation (particularly via IPS devices). Even if the malware is only able to propagate through the network layer in which it is connected for now, this creates an additional protection layer. Several victims have witnessed an impact to their workstations thanks to simple network segmentation.
Finally, prepare backups!

If you find files with the “.wncry” extension then your endpoint is infected and the ransomware is already being executed.

Alert the CERT-W (cert@wavestone.com) and the Wavestone security team (#Security).

Do not hesitate to forward this article to your clients.

[1] In its first communication, the ANSSI also spoke of Jam, another "simple" ransomware that has been distributed in the last few days by different exploit kits (Necurs in particular).

[2] https://support.microsoft.com/fr-fr/help/4013389/title

[3] Do NOT block: iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com, ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com and ayylmaotjhsstasdfasdfasdfasdfasdfasdfasdf[.]com

[4] https://www.theguardian.com/technology/2017/may/13/accidental-hero-finds-kill-switch-to-stop-spread-of-ransomware-cyber-attack

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 !

Retrouvez également le focus de la semaine, l'analyse des #MacronLeaks par Mahdi BRAIK.

Veille cybercriminalité

WannaCrypt n’est que le premier

WannaCrypt, la rançongiciel ayant compromis plusieurs centaines de milliers de machines, n’est que le premier à tirer parti des vulnérabilités rendues publique par le groupe ShadowBrokers. Actuellement, à minima deux autres logiciels malveillants exploitent la même faille de sécurité :

Adylkuzz, un logiciel malveillant qui exploite les ressources matérielles des machines infectées pour « miner » une crypto-monnaie nommée Monero.
UIWIX, un rançongiciel qui ne se propage pas de lui-même.
EternalRocks, qui embarquerait de nombreux exploits des ShadowBrokers en plus d’ETERNALBLUE

Le site Zomato piraté

Le site de recherche de restaurants Zomato a été victime d’une attaque qui a permis aux attaquants de voler notamment 17 millions de comptes, avec un mot de passe stocké en MD5.

Sources :
http://blog.zomato.com/post/160791675411/security-notice

YahooBleed

En envoyant un email contenant une pièce-jointe spécialement créée, un chercheur en sécurité a réussi à prouver qu’il pouvait obtenir partiellement des images appartenant à d’autres emails, y compris dans d’autres boîtes aux lettres.
La vulnérabilité réside dans la bibliothèque de manipulation d’image ImageMagick. En envoyant une image au format RLE spécialement formatée, l’attaquant récupère alors des données provenant de mémoire non-initialisée, et qui pourrait permettre de récupérer le contenu d’autres images étant traitées par les serveurs Yahoo.

Sources :

https://scarybeastsecurity.blogspot.fr/2017/05/bleed-continues-18-byte-file-14k-bounty.html

Veille Outillage

Intégration des ACLs dans BloodHound

BloodHound est un logiciel permettant permettant d’identifier des chemins d’attaque dans un environnement Active Directory, inspiré des travaux d’Emmanuel Gras et Lucas Bouillot d’Alsid.
La dernière version intègre certaines vérifications sur les ACLs et permet ainsi d’identifier de nouveau chemins permettant la compromission de l’Active Directory.

Sources :

https://wald0.com/?p=112

Déchiffrement des fichiers WannaCrypt

En cas d’infection d’une machine Windows XP ou Windows 7 par le rançongiciel WannaCrypt, il est parfois possible de récupérer la clé privée utilisée pour chiffrer les clés de chiffrement de fichiers, et ainsi de récupérer ses fichiers.

Sources :

Désactiver la journalisation d’événements Windows

Lors d’un test d’intrusion, il peut être utilise de désactiver la journalisation d’événements de la cible afin d’éviter que les équipes du SOC ne détectent l’intrusion. Le projet Invoke-Phantom permet de supprimer tous les fils d’exécution du processus de journalisation Windows. Ainsi, le service apparaît actif mais les éléments ne sont pas journalisés.

Sources :

https://github.com/hlldz/Invoke-Phant0m

Indicateurs de la semaine

Le leak de la semaine – Travis CI

Une vulnérabilité a été identifiée dans la manière dont Travis CI, une solution hébergée d’intégration continue, gère la journalisation des commandes Git.
Certains tokens d’authentification OAuth pour Github pouvait se retrouver journalisés dans des logs accessibles publiquement.
Ces informations sont désormais remplacées par la chaîne de caractères « [secure ] » dans les logs.
Travis CI et Github ont collaboré pour révoquer les tokens d’authentification présents dans les logs.

Sources :

https://blog.travis-ci.com/2017-05-08-security-advisory

L’exploit de la semaine – CVE-2017-0148

L’exploit de la semaine est évidemment celui correspondant au bulletin MS17-010, aussi connu sous le nom de code ETERNALBLUE. Faisant partie des exploits publiés par les ShadowBrokers il permet l’exécution de code à distance via le protocole SMB v1.
Originellement fonctionnel uniquement sur Windows 7 et Windows Server 2008, il vient d’être intégré au framework Metasploit, et une version ciblant Windows 8 et Windows Server 2012 vient également d’être publiée.

Sources :

L’attaque de la semaine – Google Docs

Difficile cette semaine de ne pas mentionner le cas du rançongiciel WCry.
Très classique dans son fonctionnement, il se distingue par sa capacité à se répliquer via l’exploitation d’une faille dans le protocole SMB (MS17-010). Les entreprises et institutions publiques sont fortement touchées, de par le fonctionnement de type « vers » : un poste infecté tentera d’infecter tous les postes vulnérables du réseau.

Sources :

http://www.securityinsider-solucom.fr/2017/05/wcry-quand-les-outils-de-la-nsa-force.html

Suivi des versions

Produits	Version actuelle
Flash Player	25.0.0.171
Adobe Reader	2017.009.20044
Java	Version 8 update 131
Mozilla Firefox	53.0.3
Google chrome	58.0.3029.140
Virtual Box	5.1.22

Arnaud SOULLIE

Peu avant le second tour des élections présidentielles française, des données de campagnes du parti « En Marche » ont été publiées. D’où vient l’attaque ? Des faux documents ont-ils réellement été publiés par l’équipe du candidat en amont ?

Voici quelques éléments qui vous permettrons de vous y retrouver !

La publication

Le vendredi 5 mai 2017, juste avant le silence médiatique imposé le code électoral, un message publié sur le site 4chan (« /pol/ » forum) fait état de plusieurs archives concernant des documents extraits des boites mails de différents cadres du mouvement« En Marche ». Ainsi, de nombreux liens permettant de les télécharger sont mis à disposition via le site de partage de fichiers Pastebin sous le nom « EMLEAKS ». Alors que depuis quelques jours différents liens faisant apparaitre des fichiers relatifs au mouvement « En Marche » sur le Forum « /pol/ » c’est le journaliste et militant d’extrême droite Jack POSOBIEC qui met en lumière les différents documents via Twitter et le hashtag « #MacronLeaks » :

Tweet du militant d’extrême droite Jack Posobiec faisant apparaitre le hashtag « MacronLeaks »

Le message est ensuite relayé par plusieurs comptes « robots » ainsi que par de nombreux militants avant d’être de nouveau mis en valeur via une publication – cette fois encore sur Twitter – émise par le compte officiel du site d’information WikiLeaks :

Tweet sur compte officiel du journal Wikileaks faisant état des archives de l’équipe d’En Marche

Suite à ce tweet, le hashtag « #MacronLeaks» sera ensuite repris par de nombreux internautes et notamment par les membres et dirigeant du Front National.

Le contenu des données

Ces révélations, effectuées juste avant la période de réserve font état de plus de 15Go de données volées (70 663 mails et documents) concernant la campagne d’Emmanuel Macron. Celles-ci concernent différents membres proches du président actuel (Emmanuel Macron) ; les personnalités politiques Anne-Christine Lang et Alain Tourret, le trésorier Cédric O, la chargé de communication Quentin Lafay, ainsi que le conseiller politique Pierre Person.

À la suite de cette publication de nombreux faux documents ont ensuite été publiés, comme le montre la capture ci-dessous dénonçant un faux mail :

Tweet faisant apparaitre un faux-mail

(non extrait des documents disponibles dans les archives publiées)

L’analyse des documents (mails, factures…) n’a pour l’instant pas permis d’identifier de données compromettantes pour l’actuel Président de la République. Ces données ont cependant été utilisées afin de comprendre les rouages du financement de la campagne « En Marche ».

Par ailleurs, selon Mounir Mahjoubi, directeur de la campagne numérique du parti « En Marche » et actuel Secrétaire d’État chargé du Numérique, les équipes de M. Macron auraient procédé en amont à la diffusion de faux documents, emails, etc. L’objectif de cette manœuvre est alors de créer un « flou » autour du candidat, afin de ralentir d’éventuels pirates dans leur travail de recherche de données compromettantes.

La source de l’attaque

Si ces données n’apportent pas de révélations concernant l’actuel Président de la République, la question de la sécurité informatique se pose réellement. En effet, alors que l’ANSSI (Agence Nationale de la Sécurité des Systèmes d’Information) était directement responsable de la bonne tenue des élections présidentielles, cinq boites mails ont tout de même été piratées.

Ce piratage faisant directement écho avec les attaques informatiques réalisées durant la campagne présidentielle Américaine, la piste Russe a rapidement été évoquée. De plus, de nombreuses métadonnées des documents piratés font apparaitre des données des mots cyrilliques comme le montrent les tweets suivants :

Tweet du chercheur en sécurité de l'information Matthieu SUICHE décrivant la présence de métadonnées en cyrillique dans les documents piratés

Tweet décrivant la présente du nom d’un employé d’une société Russe dans les documents piratés

En effet, la société Evrika est une entreprise Russe basée à Saint Petersburg est connue pour sa collaboration avec le gouvernement Russe ainsi qu’avec le FSB (Service de Sécurité Fédéral Russe). Ainsi certains experts accusent le groupe APT28 d’avoir édité les documents et de les avoir ensuite diffusés via les médias sociaux, comme pour l’action menée contre le parti de Clinton pendant l'élection présidentielle de 2016.

Il est cependant à noter qu’il s’agit à l’heure actuelle de suppositions. En effet, ce type de données reste relativement simple à modifier / supprimer et elles pourraient tout à fait avoir été ajoutées / falsifiées par un autre groupe de hackers en vue de brouiller les pistes vers le réel attaquant.

Une enquête à venir

Alors que le président sortant François HOLLANDE avait annoncé que « Rien ne sera laissé sans réponse», les autorités sont bien déterminées à remonter la piste vers l’origine de l’attaque. Alors que M. Macron avait saisi la CNCCEP (Commission Nationale de Contrôle de la Campagne), le parquet de Paris a ouvert une enquête pour atteinte au secret de correspondance ; le dossier sera traité par la BEFTI (Brigade d’Enquête sur les Fraudes aux Technologies de l’Information).

Mahdi BRAIK

Sources

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 !

Retrouvez également le focus de la semaine, le compte-rendu des PHDays 2017 par Thomas DEBIZE.

Veille cybercriminalité

La chaine de restaurants Chipotle piratée

La chaine de restaurant Chipotle a notifié ses utilisateurs d'une compromission de ses terminaux de paiements entre les 24 mars et 18 avril. Le code malveillant aurait infecté des terminaux de 47 états différents, la liste des restaurants affectés étant accessible ici.
La compagnie affirme avoir assaini l'ensemble de ses systèmes, mais les utilisateurs ayant utilisé leur carte bancaire dans l'un des restaurants durant cette période doivent rester vigilant concernant toute transaction illégitime effectuée depuis leur compte en banque.

Sources :

Le système de reconnaissance biométrique du Galaxy S8 facilement contourné

Une caméra infrarouge, une lentille de contact, et une imprimante, c'est tout ce qu'il a fallu au groupe de chercheurs "Chaos Computer Club" pour contourner le scanner oculaire du Samsung Galaxy S8.
Pour tromper le capteur, les attaquants ont simplement pris une photo du propriétaire à quelques mètres de distances, imprimé celle-ci et déposé la lentille de contact au niveau de l'œil pour imiter sa courbure.

Sources :

Les auteurs du ransomware WannaCry semblent parler couramment chinois

Des chercheurs de l’entreprise Flashpoint ont analysé les différentes demandes de rançons proposées par le ransomware WannaCry et ont découvert que les notes de rançons chinoises sont significativement plus développées que celles des autres langages, ce qui laisserait penser que les auteurs du ransomware parlent couramment cette langue.
Cette nouvelle information intervient après l'attribution du malware à la Corée du Nord qu'ont pu faire certains experts.

Sources :

Veille Vulnérabilité

Des millions de terminaux Android exposés à la vulnérabilité "Cloak and Dagger"

Cette attaque, découverte par des chercheurs du Georgia Institute of Technology, pourrait permettre une prise de contrôle totale des terminaux Android allant jusqu'à la version 7.1.2. La vulnérabilité ne se situe pas au niveau du système d'exploitation Android, mais plutôt au niveau de deux permissions utilisées par de nombreuses applications :

SYSTEM_ALERT_WINDOW (“draw on top”) – qui donne le droit à l'application de se mettre au premier plan
BIND_ACCESSIBILITY_SERVICE (“a11y”) – qui permet la saisie à l'aide de commandes vocales et la fonctionnalité de description vocale.

Sources :

Une "nouvelle" vulnérabilité critique dans le logiciel Samba

Sources :

Un nouveau patch de sécurité pour le système de protection antiviral de Microsoft

Microsoft a corrigé une nouvelle vulnérabilité critique dans son système de protection antiviral qui pourrait permettre l'exécution de code à distance à l'aide d'un exécutable spécialement formé.

Sources :

Indicateurs de la semaine

Le leak de la semaine – Crysis

Le leak de la semaine est un peu particulier puisqu'il ne s'agit pas d'informations ou d'outils récupérés lors d'une attaque mais plutôt de plus de 200 clés de déchiffrement des dernières versions du ransomware Crysis.
Pour rappel les fichiers chiffrés par ce ransomware portent les extensions .wallet ou .onion. Un outil permettant le déchiffrement a déjà été proposé par la compagnie d'antivirus ESET et est disponible ici.

Sources :

L’exploit de la semaine – Hacked in translation

L'exploit de la semaine concerne une preuve de concept rendue publique par une équipe de chercheurs de l'entreprise Check Point, et qui vise à utiliser des sous-titres malveillants pour permettre l'exécution de code à distance. Les chercheurs ont controlés différents lecteurs vidéos tels que VLC media Player, Kodi, Stremio ou Popcorn Time et ont trouvé différentes vulnérabilités spécifiques à chacun permettant cette exécution de code.
Seules les vulnérabilités affectant le logiciel VLC media player ont pour le moment été rendue publique puisque l'éditeur a proposé des mises à jour de sécurité.

Sources :

Le hack de la semaine

Le hack de la semaine concerne le projet de Tavis Ormandy, chercheur de vulnérabilités Windows pour le Project Zero de Google, et qui a tout simplement décidé de porter Windows Defender sur Linux, ce qui lui permet de faire des tests en ayant le moins d'effets de bord possible, et de disposer des outils de la plateforme Linux qui d'après lui sont plus performants.

Sources :

https://www.theregister.co.uk/2017/05/24/windows_defender_linux_port/

Suivi des versions

Produits	Version actuelle
Flash Player	25.0.0.171
Adobe Reader	2017.009.20044
Java	Version 8 update 131
Mozilla Firefox	53.0.3
Google chrome	58.0.3029.140
Virtual Box	5.1.22

Nicolas DAUBRESSE