SecurityInsider
Le blog des experts sécurité Wavestone

Société Générale et Wavestone lancent les « Banking CyberSecurity Innovation Awards »



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.

Compte-rendu de la conférence Hack-in-the-box Amsterdam – 13 et 14 avril 2017


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 WiFi d’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 :
  1. 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
  2. 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
  3. 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

CERT-W : retour sur l'actualité de la semaine du 10 au 14 avril


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 !

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 :

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 : 

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 : 
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
Adobe Reader
Java
Mozilla Firefox
Google chrome
Virtual Box

Nicolas DAUBRESSE

Compromission d’un domaine Windows à l’aide des délégations Kerberos

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 :