L’édition 2018 de la Black Alps, une conférence suisse de référence en matière de sécurité des Systèmes d’Information, s’est déroulée à Yverdon-les-Bains les 8 et 9 novembre derniers.
Cet événement offrait un éventail d’activités destiné aussi bien aux professionnels qu’aux amateurs passionnés par la Sécurité des Systèmes d’Information.
L’équipe organisatrice de la conférence a mis à disposition sur YouTube certaines conférences filmées, accessibles à l’adresse suivante : https://www.youtube.com/channel/UCkCV_HJUkI8PsFrX4wpPX4A/videos. De plus, certains supports de présentations sont consultables sur le site officiel de la conférence : https://www.blackalps.ch/ba-18/talks.php.
Cet article présente les résumés de quelques conférences qui nous ont marqués. Un compte rendu sera également disponible au sein d’un prochain numéro de notre ActuSécu.
Let’s create a RedTeam mission, par Alex Kouzmine
Le chercheur du CERT Societé Générale a présenté son approche pour la création d’une mission de type redteam. Ce concept de « Red team », de plus en plus utilisé, provient de l’armée américaine qui en tirait partie pour mieux comprendre et anticiper d’éventuelles attaques russes. L’idée était de mettre une équipe dans la peau d’attaquants, de s’appuyer sur les méthodes d’attaques connues de la Russie et de préparer au mieux la « Blue team », l’équipe de défense, en cas d’attaque.
Après avoir défini les objectifs de la mission, il a pu préparer et réaliser les différentes étapes de son attaque en se basant sur le modèle ATT&CK du MITRE. Sur la base de ce dernier, il s’est appuyé sur des méthodes d’attaque de groupes ciblant la Société Générale (à partir de résultats de leur activité interne de threat intelligence) pour établir le mode opératoire qu’il allait utiliser. L’objectif étant de se protéger le plus efficacement possible contre les méthodes des groupes d’attaquant cherchant à impacter l’entreprise.
Il est revenu sur chacune des étapes pour évoquer les stratégies qu’il avait adopté et proposer quelques conseils.
Une fois la mission ayant atteint ses objectifs, il a rappelé l’importance de réaliser un feedback entre les équipes. Cette étape a pour but de comprendre et résoudre l’origine des problématiques en ayant permis le succès.
Il a conclu sa présentation à partir de quelques conseils :
- être humble dans le choix des méthodes d’attaques ;
- être sexy est la clé lors de campagnes de phishing ;
- être en capacité de s’adapter aux différentes problématiques techniques que l’on va rencontrer durant la mission ;
- éviter l’utilisation de techniques ou d’outils « overkill » ;
- « Less is More » : la simplicité doit être privilégiée face à la complexité.
Application Level DDOS, the rise of CDNs and the end of the free Internet, par Christian Folini
Lors de cette présentation, le chercheur a d’abord présenté différentes actualités, puis des techniques et des moyens mis en oeuvre afin de réaliser un déni de service distribué.
Il a ainsi évoqué l’exploitation de vulnérabilités sur des objets connectés par des botnets, et notamment du botnet Mirai qui a exploité des caméras IP mal configurées. Il a également présenté les dénis de service tirant leurs sources de vulnérabilités applicatives. C’est le cas, par exemple, de l’amplification DNS, permettant de générer des requêtes très lourdes pour les victimes.
Face à ces différentes méthodes et à partir de citations de géants du web, il a évoqué l’avenir des dénis de service. Ainsi, d’ici plusieurs années, seuls très peu d’hébergeurs (Amazon, Google par exemple) seront en mesure de résister aux plus grandes attaques par déni de service. Dès lors, les entreprises auront le choix entre payer ces hébergeurs ou payer des rançons auprès d’attaquants pour ne pas être attaquées et maintenir leur business.
« Within 2-3 years, there will be only 2-3 players in the world that are able to withstand the biggest DDoS attacks and protect websites on a global scale. », Damian Menscher (Google)
“I think we are going to see a future where people will accept to pay money in extortion. It will be part of the costs of doing business. As an alternative, there will be a handful of expensive services that can protect you from DDoS attacks and these services effectively control what new startups will be allowed to operate on the internet.”, Dr. Paul Vixie (Farsight)
Bien que difficile de limiter cette prévision, il a conclu en proposant l’utilisation d’un paramétrage BGP (No Route Export) consistant à ne plus annoncer la route internationalement, mais de se concentrer sur des partenaires locaux. Cela permettrait alors à un service de rester en ligne dans la région dans laquelle il se trouve (en supposant que l’attaque provienne d’une zone géographique différente).
Dilemmas everywhere! Get it right or get pwned, par Ethan Schorer
Le chercheur a proposé de partager sa vision du développement sécurisé.
Sur la base d’une étude réalisée par IBM, il a présenté l’évolution du coût de correction de vulnérabilités, qui augmente très fortement en fonction de l’état de développent d’une application. Il a alors évoqué la nécessité de sécuriser chaque maillon de la chaine de développement :
- développement sécurisé du design de l’application ;
- développement sécurisé du code ;
- tests sécurisés de l’application.
En déroulant ces trois piliers, il est revenu sur quelques fondamentaux d’un développement sécurisé :
- la formation à la sécurité des développements ;
- le style du code ;
- la validation des entrées.
Afin de mettre en lumière son propos, il a pris l’exemple du développement d’un outil permettant l’identification de malwares et a parcouru les différentes étapes de son développement pour s’assurer que chacune incluait des aspects sécurité.
Il a alors mis en valeur des dilemmes pour lesquels il est nécessaire de choisir par exemple entre facilité d’utilisation et sécurité. Voici quelques exemples de choix ou questions importantes pour la sécurité du produit :
- le choix du langage de programmation pour une interface front-end / back-end ;
- l’utilisation de bibliothèques logicielles tierces ;
- l’utilisation de composants open source ;
- le besoin en maintenance (mises à jour de sécurité) ;
- etc.
Il a conclu sur le fait qu’il était vital que chaque étape d’un développement bénéficie d’une attention à la sécurité. Enfin, il a mis en valeur l’importance de l’existence de lignes directrices claires dans les entreprises pour la bonne mise en place des développements sécurisés.
3 years lated: a crossed look at Swisscom bounty, par Florian Badertscher et Nicolas Heiniger
Cette présentation a été réalisée par un analyste du CSIRT de Swisscom et par un chercheur de l’entreprise Compass Security.
Ensemble, ils ont montré l’évolution du programme de Bug Bounty mis en place par Swisscom il y a 3 ans.
Ils ont parcouru ensemble les difficultés rencontrées au fil du temps :
- du côté de Swisscom : le recrutement, la prise en compte de toutes les demandes par rapport à la taille de l’équipe, etc. ;
- du côté des chercheurs : la frustration du temps de réaction/correction de Swisscom, etc.
Cette conférence a donné ainsi une vision interne et externe de ce programme et de son évolution pendant ces 3 années.
Ils ont présenté de cette manière comment l’amélioration du fonctionnement de ce programme a été réalisée grâce à la collaboration et la communication entre chercheurs et internes de Swisscom.
Par la suite, les deux ingénieurs ont révélé quelques vulnérabilités importantes qui avaient pu être identifiées :
- une injection SQL menant à une prise de contrôle d’un équipement utilisé pour la diffusion contenu vidéo ;
- un mot de passe par défaut sur l’interface d’une imprimante exposée sur Internet permettant de récupérer l’intégralité des documents imprimés via l’authentification sur la solution messagerie de l’entreprise ;
- une vulnérabilité XSS stockée sur un portail client ;
- etc.
Build your own hardware implant, par Nicolas Oberli
Cette présentation est revenu sur la publication par Bloomberg le 4 octobre d’un article choc indiquant qu’un implant hardware avait été incorporé au sein de serveurs de la société SuperMicro à son insu. Celui-ci aurais permis de compromettre le système d’exploitation utilisé une fois démarré.
Plus précisément, l’article contenait la mention suivante qui avait alors suscité l’intérêt du chercheur :
[…] The legitimate server was communicating one way, and the implant another, but all the traffic appeared to be coming from the same trusted server […]
Il a donc essayé de mettre en place son propre implant hardware qui pourrait reproduire ce comportement.
Il a pu identifier un composant vendu par Intel contenant certaines interfaces (IPMI / BMC / SMBus), qui sont utilisées pour surveiller des composants mais également contrôler l’ordinateur à distance.
En creusant et après lecture répétée de la documentation fournie par le constructeur, le chercheur a pu être en mesure de réaliser diverses actions grâce à cet implant :
- lire le trafic reçu par l’hôte ;
- recevoir des commandes depuis le réseau, sans que l’hôte ne s’en rende compte ;
- transmettre des données sur le réseau, sans que l’hôte ne s’en rende compte également.
Il conclut en indiquant que d’une part la vitesse de téléchargement était trop faible pour être en mesure de faire de l’inspection de paquets, et qu’il n’a pas identifié de moyen de compromettre le système d’exploitation de l’hôte. Il a toutefois ouvert sa conclusion sur la possibilité de compromettre l’hôte via le BIOS/UEFI (l’interface SMBus ne peut pas accéder au CPU/RAM mais sur certaines cartes mères elle peut accéder au BIOS/UEFI).
Group123: Korea in the crosshairs, par Paul Rascagneres
Ce chercheur travaillant parmi le groupe de chercheur Cisco Talos a présenté durant cette conférence les différentes activités du groupe d’attaquant Group123 entre 2017 et 2018.
Il a ainsi développé les différentes campagnes sur lesquelles il avait pu travailler, qui ont ciblé des sud-coréens et des institutions financières non coréennes.
Ces campagnes étaient basées sur l’utilisation de Hangul Word Processor (suite bureautique incluant les caractères de la langue locale) ou de documents Office forgés pour l’infection des cibles. Elles étaient réalisées à des fins d’espionnage ou de destruction.
Le chercheur a également mentionné une augmentation des capacités du groupe en 2 ans et notamment :
- l’utilisation d’une vulnérabilité de type 0-day (CVE-2018-4878) pour Adobe Flash Player pendant plusieurs mois ;
- l’utilisation d’un malware pour Android, sous la forme d’une application.
