9,90 € TTC
p. 06 Antivirus Avira (CVE-2019-18568) : quand l’authentification d’un PE mène à une LPE
p. 14 Extraction des secrets de lsass à distance
p. 22 Analyse UEFI avec Windbg
p. 32 Introduction
p. 33 Classification des vulnérabilités dans les navigateurs
p. 42 Mécanismes de défense en profondeur de Safari sur iOS
p. 50 JsItBad : détecter du JavaScript malveillant sans l’exécuter
p. 59 De l’audit de code pendant un Red Team ?
p. 68 KeeRest : mettez du DevOps dans votre KeePass
p. 76 Un œil technique sur les sanctions de la CNIL
Si pour le domaine de la sécurité, la décennie 2010 a été marquée par la prise de conscience par le grand public de la surveillance de masse au niveau étatique, le début de la nouvelle décennie semble être celle du développement exponentiel des capacités offensives aux mains d’acteurs étatiques, privés, voire mafieux. Si nous avions pu commencer à nous sentir globalement en sécurité depuis quelques années, bien au chaud derrière nos couches de protection périmétriques, le modèle commence à montrer de sérieuses limites. Un des enjeux sera donc de monter rapidement en maturité du côté défensif alors que les outils offensifs semblent avoir pris une longueur d’avance.
Plusieurs événements récents démontrent ce brusque changement du rapport de force et de l'inadéquation à la fois des outils techniques, des architectures de sécurité et des pratiques. On pense bien sûr aux vagues de ransomwares qui ont rythmé l’année 2019 et qui perdurent en 2020 démontrant la fragilité des architectures Active Directory sur lesquelles reposent la grande majorité des parcs informatiques. On peut également citer les attaques sur les supply chains et le risque qu’elles font peser sur nos systèmes d’information à cause de la fragilité, voire de la négligence de certains de nos sous-traitants.
Un autre de ces événements montrant le développement et la généralisation des capacités offensives est le piratage du téléphone de Jeff Bezos à des fins de chantage. L’attaque semble avoir été rendue possible grâce à un 0day sur WhatsApp, le type d’exploit qui se monnaie, à l’heure où j'écris ces lignes, à 1.500.000$ sur Zerodium. Cette attaque nous permet plusieurs enseignements.
Le premier est l’extraordinaire homogénéité des technologies actuelles. De l’homme le plus riche du monde à l’Occidental moyen, chacun dispose d’un téléphone sous Android ou iOS avec globalement les mêmes applications présentes développées par trois principaux éditeurs : Facebook, Apple et Google. Un RCE zéro clic sur WhatAapp/Telegram/iMessage/... permet ainsi de prendre le contrôle et d’exfiltrer tout ou partie des données sur à peu près n’importe quel terminal de la planète y compris sur celui de dirigeants politiques ou du patron d’un GAFA. Si les failles sur les briques logicielles ont existé en tout temps, il y a plusieurs éléments qui rendent la portée de celles-ci sur mobile différente. Outre l’homogénéité des briques logicielles, le modèle de sécurité des systèmes d’exploitation et fermeture rend complexe leur sécurisation. Si nous devions déployer une brique logicielle sensible avec une surface d’attaque importante sur les postes de travail ou serveurs de notre structure nous aurions beaucoup de solutions de durcissement pour réduire l’impact d’une compromission : segmentation réseau, IPS, durcissement de l’OS via du Mandatory Access Control, virtualisation ou conteneurisation, antivirus et EDR, règles sur les SIEM pour détecter les prémices de l’attaque… Force est de constater que sur les terminaux mobiles, le niveau de contrôle des mécanismes de protection pour l’ingénieur sécurité est bien plus réduit et que les OS ne peuvent pas être administrés et durcis comme pourraient l’être un poste de travail ou un serveur. Il est d’ailleurs intéressant de voir des responsables de Facebook rejeter la faute sur Apple suite à la compromission du téléphone de Jeff Bezos considérant que si l’application était bien vulnérable, c’est à cause de l’absence de mécanismes de sécurité suffisante sur iOS que le téléphone a pu être compromis.
Le second enseignement est le faux sentiment de sécurité, voire la naïveté, des utilisateurs qui pensent encore que ce qui se trouve dans leur téléphone pourra être gardé secret. Cet épisode, comme d'autres qui ne manqueront probablement pas de suivre, aura certainement au moins le mérite de sensibiliser au niveau de confiance que nous pouvons avoir dans ces nouveaux doudous numériques qui détiennent nos secrets les plus intimes.
Cedric Foll / cedric@miscmag.com / @follc
Face à la transformation digitale de notre société et l’augmentation des cybermenaces, la cybersécurité doit être aujourd’hui une priorité pour bon nombre d’organisations. Après plus de 20 années de publications et de retours d’expérience, MISC apporte un vivier d’informations techniques incontournable pour mieux appréhender ce domaine. Précurseur sur ce terrain, MISC a été fondé dès 2002 et s’est peu à peu imposé dans la presse française comme la publication de référence technique en matière de sécurité informatique. Tous les deux mois, ses articles rédigés par des experts du milieu vous permettront de mieux cerner la complexité des systèmes d’information et les problèmes de sécurité qui l’accompagne.
Il y a maintenant 5 ans, MISC dédiait un dossier complet à la sécurité des navigateurs web [1]. Il y était traité de sandboxing sous Firefox, de JIT, de cloisonnement JavaScript, d’exploitation du navigateur Chrome sous Android. Une grande partie de ce qui a été écrit à l’époque est encore en partie valide et je vous invite à y jeter un œil si vous ne connaissez pas déjà ce dossier.
C’est théoriquement impossible, et pourtant c’est faisable en pratique. En s’inspirant d’une technique d’apprentissage statistique (Machine Learning) habituellement réservée au traitement du langage naturel, il est possible de déterminer avec une très grande précision si un bout de code en JavaScript est malveillant. Ces résultats s’étendent naturellement à tout langage interprété, mais sont mis en défaut par l’arrivée du WebAssembly.
Nous avions vu dans MISC n°103 comment déployer une base KeePass en mode SaaS ciblant les particuliers ou de petits périmètres professionnels. Dans un autre monde, les pratiques DevOps se démocratisent et demandent d’augmenter l’agilité des développements tout en réduisant les délais de mise en production. Cet article est le fruit d’une collaboration entre un DevOps et un ingénieur SSI pour voir de quelle manière il est possible de tirer profit de KeePass dans ces environnements.