Durcissement de la sécurité des systèmes GNU/Linux

1. Isolation de processus avec les namespaces et seccomp BPF
2. Découvrez Qubes OS, un système orienté bureau et sécurité
3. Les prochaines avancées pour la sécurité de la distribution Debian

Exploit Corner

p. 06  Analyse du contournement de KTRR

Malware Corner

p. 12  Introspection et analyse de malware via LibVMI

IoT Corner

p. 20  Hacking IoT : test d’intrusion d’une caméra connectée

Dossier

p. 30  Préambule
p. 31  Namespaces et seccomp BPF : un zoom sur la conteneurisation Linux
p. 39  Qubes OS : un système d’exploitation raisonnablement sécurisé
p. 51  Sécurité de Debian Buster

Réseau

p. 58  Silent wire hacking : écouter le trafic sur les liens ethernet

Système

p. 66  L’en-tête HPKP pour sécuriser un peu plus les connexions sur Internet ?

Organisation & Juridique

p. 76  Guide de survie juridique : comment réagir en cas d’intrusion ?

La Blockchain ou les habits neufs de l’empereur

Je crois qu’aucune technologie ne m’a jamais laissé aussi circonspect que la Blockchain (ou chaîne de blocs). Une technologie dont tout le monde a entendu parler alors qu’elle est conceptuellement particulièrement complexe, que tout le monde veut utiliser alors que le champ d’application est particulièrement réduit et inadapté, ou tout du moins inefficace, pour la plupart des usages.

Nous avons d’un point de vue conceptuel une merveille d’élégance, un système réussissant à faire émerger l'harmonie au milieu du chaos. En effet, la Blockchain est une base de données réussissant le tour de force d’apporter un très haut niveau d’intégrité, de disponibilité et de preuve dans un environnement où personne ne peut se faire confiance. La perfection n’étant pas de ce monde, les performances en écriture sont très limitées et la consommation énergétique liée aux preuves de travail problématique. De plus, comme souvent lorsque les exigences de disponibilité et d’intégrité sont très fortes, la confidentialité est difficilement assurée. Ce dernier point étant d’ailleurs rayé d’un coup de plume, en effet, par conception les chaînes de blocs sont publiques. Ce n’est qu’à ce prix qu’elles peuvent être répliquées à l’infini. Elles sont ainsi toujours disponibles et l’authenticité de leur contenu est vérifiable par chacun.

Implémentée pour la première fois à grande échelle avec le Bitcoin, la viabilité du modèle théorique a été démontrée de manière particulièrement éblouissante. Dix ans après sa création, cette Blockchain évolue de manière totalement autonome, les auteurs l’ayant conçu pour qu’elle soit totalement décentralisée et coupée de ses créateurs qui ne peuvent plus la modifier. 

La flambée du Bitcoin ayant été très largement relayée par les médias, le terme de Blockchain a fini par être connu auprès du grand public et des décideurs qui se sont convaincus que c’était un truc important et qu’il fallait forcément en être. Si bizarrement aucun haut fonctionnaire ou cadre dirigeant n’a jamais convoqué son directeur informatique pour s’inquiéter de l’existence de projets intégrant des bases de données NoSQL, il en est tout autre pour la Blockchain. Combien de DSI se sont entendus dire ces derniers mois « J’espère que l’on n’est pas en train de rater le coche de la Blockchain, je veux d’ici la fin du mois un projet et on va mettre toutes les équipes de Com dessus »? Combien d’entre nous se sont retrouvés dans des réunions ubuesques où une personne, sans aucune compétence en informatique, voulait absolument utiliser la Blockchain comme base de données sans comprendre ni l'intérêt du système ni tous les inconvénients :

« Bon les gars, vous savez que nous devons développer une nouvelle application de gestion des fiches de paie ? La direction a insisté pour qu’elles soient stockées sur la Blockchain. Ils ont eu une présentation aux Assises de la sécurité et on leur a dit qu’avec cette techno les données sont infalsifiables et ne seront jamais perdues.

- Ils veulent rendre publiques les fiches de paie de toute la boite ? Qu’on les publie sur la Blockchain du Bitcoin ou d’Ethereum ?

- Mais non, c’est super confidentiel, on va faire tourner ça sur notre Cloud privé.

- OK, j’ai récupéré un vieux serveur sur lequel on faisait tourner nos bases de données. On va installer VirtualBox et faire tourner trois ou quatre VM avec Ethereum ça devrait suffire.

- Super ! Avec ça on est certain de ne jamais les perdre. On va pouvoir numériser toutes les archives et libérer un bureau. »

Bonne lecture et en vous souhaitant de beaux projets Blockchain en 2019 !

Cedric Foll / cedric@miscmag.com / @follc

Pentest Windows : Outils & techniques

1. Sécurité des relations d'approbation Active Directory
2. Compromission de postes de travail avec LAPS et PXE
3. Retour sur les faiblesses de l'authentification Windows

Exploit Corner

p. 06  CVE-2019-8942 et 2019-8943 : exécution de code dans WordPress

Pentest Corner

p. 12  Fuddly : introduction de l’outil et développement d’un protocole

Forensic Corner

p. 18  Where’s my memory ?

Dossier

p. 26  Préambule
p. 27  La face cachée des relations d’approbation
p. 39  Compromission de postes de travail grâce à LAPS et PXE
p. 46  Retour sur les faiblesses de l’authentification Windows

Réseau

p. 56  Présentation de l’HIDS Wazuh

Système

p. 66  KeePass multiplateforme en authentification forte avec une YubiKey

Organisation & Juridique

p. 76  Comment concevoir son référentiel « protection de la vie privée » en cohérence avec le référentiel SSI ?

Il y a quelques semaines, apparaissait sur mon fil Twitter, le constat d’échec (™ Nicolas Ruff) quant à la progression de la proportion de femmes dans la liste des speakers d’une petite conférence sécurité de province [1]. Ce symposium étant assez ancien et les programmes avec la liste des conférenciers étant toujours en ligne, force est de constater que le nombre de femmes conférencières est resté en 15 ans relativement constant. Participant moi aussi, très modestement, à l’organisation d’une conférence sécurité [2], j’apportais ma pierre à l'édifice en exposant les difficultés d’attirer des soumissions de conférencières et que même avec toutes les bonnes volontés du monde cela restait une gageure. 

Mais, au-delà de cet aspect très émergé de l’iceberg se pose la question de notre échec collectif à faire progresser la proportion de femmes dans les métiers de l’informatique et tout particulièrement dans ceux de la sécurité.

Lorsque j’ai commencé ma carrière, peu après l’extinction des dinosaures, j’avais une chef, elle-même sous l’autorité d’une DSI et globalement il y avait un bon tiers de femmes dans les équipes informatiques. Et puis, au gré de mes affectations successives, des pots de départs en retraite et des recrutements, la proportion de collègues informaticiennes s’est petit à petit réduite jusqu’à passer sous la barre des 10%. Mon expérience pourrait sembler non représentative, mais les études montrent qu’il s’agit d’une tendance [3] générale et les femmes sont aujourd’hui surtout présentes dans les équipes fonctionnelles et UX/UI [4]. Cette évolution est d’autant plus alarmante quand les profils qualifiés deviennent une ressource rare.

Ce constat plutôt sombre amène deux questions. D’abord, où avons-nous (les vieux de ma génération) failli pour avoir fait de nos métiers un repoussoir pour cinquante pour cent de la population ?  Ensuite, quels sont les leviers pour réduire l’écart de représentativité des femmes dans nos métiers ?

Pour la première question, il faut avouer que nous avons certainement trop tardivement pris en compte ce problème et que nous sommes arrivés à une si faible représentativité de femmes qu’elles ont souvent l’impression d’être des bêtes curieuses. Pire encore, il y a encore des crétins pour considérer que lorsqu’une conférence, un article ou un projet ne leur plaît pas, le fait que le travail ait été produit par une femme est une circonstance aggravante. 

Pour la seconde, j’ai bien peur que le retard pris soit si important qu’il prendra des années à se réduire, d’autant que nous avons en France une très faible proportion de femmes dans les filières informatiques et que celle-ci semble encore reculer. Nous sommes certainement arrivés au point où, au-delà des chartes, de la mise en avant des femmes s'illustrant dans ces carrières, d'associations telles que #JamaisSansElles ne suffiront peut-être plus et qu’une politique non plus incitative, mais prescriptive ne finisse par être nécessaire. L’accès des femmes à ces métiers est un véritable enjeu pour lequel nous devons collectivement œuvrer en tant que parents, enseignants et professionnels.

Cédric FOLL / cedric@miscmag.com / @follc

[1] https://www.sstic.org/

[2] https://2019.pass-the-salt.org/

[3] https://www.lemonde.fr/campus/article/2017/10/03/dans-les-filieres-high-tech-la-part-des-etudiantes-diminue_5195651_4401467.html

[4] https://www.ovh.com/fr/blog/parite-dans-la-tech-ou-sont-les-femmes/

Masquez vos attaques

pour bien réussir vos missions Red Team

1. De la reconnaissance à la post-exploitation : comment rester furtif
2. Techniques pour déjouer les mécanismes de sécurité PowerShell
3. Scripts malveillants sur Windows 10 : fonctionnement et contournements d'AMSI

Exploit Corner

p. 06  Exploitation du CVE-2018-0977 dans le noyau Windows

Pentest Corner

p. 15  Fuddly : évaluation de la robustesse d’une cible

IoT Corner

p. 20  Dis, c’est quoi là haut dans le ciel ? - C’est un Linux, mon petit

Dossier

p. 24  Préambule
p. 25  Furtivité des opérations Red Team ou comment suivre une Kill Chain sans se faire voir
p. 32  Évolution de la sécurité de PowerShell et techniques de contournement
p. 40  AMSI : fonctionnement et contournements

Système

p. 48  ModSecurity : mise en place d’un WAF et configurations avancées
p. 58  Méthodologie d’OSINT orientée réseaux sociaux

Réseau

p. 66  Analyse et interception de flux des téléphones par satellite Iridium

Organisation & Juridique

p. 74  La gestion des incidents de sécurité : un cadre de gouvernance globale

Après s’être régalé des premières asperges généreusement arrosées de muscat alsacien, l'esthète de la sécurité a pu savourer les débats enflammés accompagnant la sortie de Tchap, la messagerie instantanée de l’État. Passée l’agitation probablement accrue par un printemps pluvieux, il n’est pas inintéressant de revenir brièvement sur cet évènement.

Tout d’abord, il convient de s'interroger sur la pertinence, voire au regard de certains commentateurs, la légitimité de l’État de mettre à disposition un système de messagerie instantanée pour ses agents. Partant du constat de l’engouement pour ce mode de communication, il semble plutôt opportun de proposer un tel service à ses agents si l’on souhaite éviter l'explosion du Shadow IT et les problèmes de sécurité associés. En premier lieu, l’usage de dispositifs de communication grand public pose le problème de la gestion des identités. Il est par exemple impossible lorsque l’on s’adresse à « Cédric Foll » sur un dispositif grand public de savoir s’il ne s’agit pas d’un compte créé par un tiers souhaitant usurper mon identité. Cette situation ne doit évidemment pas pouvoir exister dans un environnement professionnel s’appuyant sur des processus formalisés par les ressources humaines pour la gestion des identités. Le second problème est le niveau de confiance tout relatif pouvant être exigé de systèmes gratuits sans accord contractuel.

Aussi, pour une DSI, il semble tout à fait légitime de chercher à fournir ce service au même titre que la messagerie électronique. Cela pourrait sembler aussi naturel que la gestion des e-mails, mais si la plupart des fournisseurs de messagerie électronique libres ou propriétaires proposent une messagerie instantanée, elles sont généralement plus limitées fonctionnellement que celles grand public. De plus, XMPP n’ayant jamais connu le succès de SMTP, elles sont incapables de communiquer avec un système concurrent. Magie de l’industrie logicielle qui n’a pas adopté un standard ouvert, il est aujourd’hui nécessaire de jongler entre une dizaine de clients sur son smartphone pour échanger avec ses différents interlocuteurs. Comble de la fragmentation, Facebook propose aujourd’hui trois clients distincts incapables d’échanger entre eux.

La DINSIC [1] s’est donc engagée dans la conception d’un système basé sur le protocole Matrix en s’appuyant sur des briques de logiciels libres afin de proposer un système utilisable entre les administrations. Certains choix d’implémentation peuvent paraître étonnants comme la possibilité de déchiffrer les pièces jointes [2] au niveau des serveurs afin qu’elles puissent être analysées par un antivirus centralisé. Mais si ce choix peut paraître discutable, il est documenté et c’est bien aux maîtrises d’ouvrage d’arbitrer les risques.

Annoncé début 2018, le système est officiellement publié en version bêta mi-avril et accessible pour tous les agents disposant d’une adresse e-mail d’un sous-domaine de gouv.fr. Malheureusement, dès le lendemain de l’annonce, une faille de sécurité exploitant un bug dans le parsing des adresses e-mail est publiée permettant de créer un compte sur le système, d'interagir avec les usagers légitimes et d’accéder aux salons de discussion publics. Ces révélations ont déchaîné les trolls se gaussant de l’incapacité de l’État à fournir une solution fiable et affirmant qu’il était bien plus sûr d’utiliser un système gratuit grand public… Ce qui rétrospectivement peut faire sourire quand une faille dans WhatsApp permettant l’injection de code arbitraire était découverte quelques semaines plus tard après avoir été utilisée contre des activistes [3].

D’ailleurs, pouvoir interagir avec des agents de l’État, comme il est déjà possible de le faire par e-mail, ou accéder aux données des salons publics visibles par un bon million de personnes ne devrait pas inquiéter outre mesure les ministères utilisant le logiciel. Les conséquences ont plutôt été au niveau de l’image de marque et ont certainement causé quelques nuits blanches aux équipes de communication de la DINSIC qui ont eu à gérer le bad buzz, ce qu’ils ont d’ailleurs plutôt bien fait.

Cédric FOLL / cedric@miscmag.com / @follc

[1] https://www.numerique.gouv.fr/dinsic/ 

[2] https://www.tchap.gouv.fr/faq/ 

[3] https://korii.slate.fr/tech/mettez-jour-whatsapp-vite-pegasus-nso-group-faille-spyware

Sécurité des environnements cloud

Amazon Web Services

1. Introduction aux environnements AWS
2. Compromission des services exposés
3. Post-exploitation et élévation de privilèges

Malware Corner

p. 06 Where’s my happy hook ?

Pentest Corner

p. 14 Et si on bashait Windows ?

IoT Corner

p. 20 Les FSEvents d’Apple

Dossier

p. 28 Introduction au dossier
p. 29 Introduction à la sécurité des environnements AWS
p. 32 Compromission des services exposés d’AWS
p. 44 Élévation de privilèges et post-exploitation au sein d’un environnement AWS
p. 50 Présentation et préparation de la réponse aux incidents sur AWS

Réseau

p. 58 RFC 8446 - TLS 1.3 : que faut-il attendre de cette nouvelle version ?

Système

p. 68 L’UEFI, au cœur du système

Organisation & Juridique

p. 76 L’audit de sous-traitants

Cet été, en toute discrétion, Orange annonçait la fin de Cloudwatt par un simple mail à ses derniers clients.

Si l’on revient rapidement à la genèse du projet, en 2009 le gouvernement français souhaitait lancer un partenariat public privé pour la création d’un acteur français de Cloud dont l’État serait actionnaire pour concurrencer le géant américain Amazon. L’idée de s’appuyer sur une société française pour héberger les données sensibles des entreprises et des administrations semble frappée au coin du bon sens. Tout particulièrement au moment où le Cloud est en pleine expansion, que les opérateurs sont déjà très majoritairement américains et que les dérives possibles du Patriot Act commencent à inquiéter les Européens. Ainsi, disposer d’une offre soumise au droit français et dont l’État actionnaire, en s’appuyant sur l’expertise de l’ANSSI, pourrait assurer un niveau de sécurité satisfaisant avait tout pour séduire. Les esprits chagrins s’étaient émus de la création subventionnée par l’État d’un nouvel acteur alors que plusieurs sociétés françaises proposaient déjà ce type d’offre. Faisant fi de ces critiques, l’appel à projets est lancé en 2011. Mais, premier problème, plutôt que de cofinancer la création d’un acteur, l’État se retrouve en 2012 à en financer deux, Cloudwatt et Numergy. Il devient donc actionnaire de deux offres concurrentes sur un marché déjà largement dominé par des entreprises disposant d’une importante force commerciale ainsi que des moyens humains et techniques bien supérieurs.

D’un point de vue technique, Cloudwatt avait de quoi séduire par des choix (trop ?) ambitieux. En effet, la société a décidé de s’appuyer lors de son lancement sur un projet open source très récent, OpenStack, alors que le marché de la virtualisation professionnel était largement dominé par HyperV et plus encore par VMWare. L’idée de partir sur un projet open source émergent permettait de s’affranchir du coût des licences éditeurs et rendait l’offre financièrement concurrentielle face à AWS... mais sans offrir le même niveau de service [1]. En effet, pour qui a fait de la virtualisation au début des années 2010, le niveau de maturité des solutions open source était bien en deçà de ce que proposaient les éditeurs propriétaires en matière de performances, de stabilité et de fonctionnalités. Aussi, à moins de disposer de la force de frappe technique d’Amazon ou de Google, concevoir une offre de service basée sur ces outils était un pari pour le moins risqué. Risques auxquels CloudWatt devait également faire adhérer ses potentiels clients...

L’affaire Snowden, en 2013, aurait pu donner le coup de pouce qu’il manquait pour faire décoller ces acteurs. Malheureusement, les grandes administrations françaises étaient plutôt réticentes à l’idée de faire sortir leurs VMs de leurs datacenters. Lorsqu’elles l’ont fait, cela a été plutôt en mode housing avec leurs propres infrastructures, ou en mutualisant les datacenters existants entre ministères [2]. Et du côté des entreprises, en l’absence de cadre réglementaire contraignant, ces offres n’étaient pas concurrentielles face aux acteurs en place. Ainsi, faute de succès, la Caisse des Dépôts a rapidement revendu ses parts avant que les deux offres ne soient supprimées du catalogue de SFR en 2016 pour Numergy puis de celui d’Orange en 2019 pour CloudWatt.

Espérons que les leçons seront tirées de ces échecs et que l’annonce de Bruno Le Maire en début d’année d’un « Cloud National Stratégique » [3] n’augure pas la création d’une nouvelle société partant d’une page blanche, mais aille plutôt vers un système de labellisation comme celui mis en place par l’ANSSI avec SecNumCloud [4].

Cédric FOLL / cedric@miscmag.com / @follc

[1] https://www.journaldunet.com/solutions/cloud-computing/1145280-numergy-vs-cloudwatt-le-match/1145286-l-avis-des-brokers-de-cloud

[2] https://www.silicon.fr/depense-it-gouvernement-us-vote-cloud-france-138736.html

[3] https://www.lesechos.fr/tech-medias/hightech/une-page-se-tourne-pour-le-cloud-souverain-francais-1118112

[4] https://www.ssi.gouv.fr/entreprise/qualifications/prestataires-de-services-de-confiance-qualifies/prestataires-de-service-dinformatique-en-nuage-secnumcloud/

Éprouver la sécurité des applications mobiles

1. Auditer la sécurité d'une application iOS
2. Contournement de l'API Google Play Billing
3. Présentation de l'OWASP Mobile Security Testing Guide

Exploit Corner

p. 06 Élévation de privilèges sur macOS avec CVE-2018-4193

IoT Corner

p. 12 Capteur de glucose connecté : comment ça marche ?

Forensic Corner

p. 19 Richelieu : solution du challenge de la DGSE

Dossier

p. 28 Introduction au dossier
p. 29 Auditer la sécurité d’une application iOS
p. 38 Contournement de l’API Google Play Billing
p. 47 Présentation de l’OWASP Mobile Security Testing Guide

Réseau

p. 56 Sondes de détection : performances, évaluations et biais

Cryptographie

p. 64 Aléa et cryptanalyse de générateurs

Organisation & Juridique

p. 74 L’intégration du « Privacy by Design » et de la SSI dans la gestion de projets en mode V ou Agile

Lorsque l’on voulait débuter la sécurité il y a une vingtaine d’années, que ce soit sous l’angle offensif ou défensif, il était bien difficile d’expérimenter ses connaissances sauf à réaliser des pentests sauvages. La possibilité de disposer anonymement de connectivité réseau dans les chaînes de fastfood était de la science-fiction et c’est le plus souvent sur les bancs des écoles ou des universités que beaucoup ont fait leurs armes. La première cible était souvent le réseau interne de son établissement (le bon temps du ypcat pour dumper à distance /etc/passwd sur les architectures d’annuaires NIS...). Puis, après avoir fait le tour du propriétaire, la tentation d’aller un peu plus loin se faisait sentir. Malheureusement pour nos apprentis hackers, les responsables des infrastructures visées appréciaient généralement assez peu de devenir le terrain d'expérimentation des jeunes padawans de la SSI. Les solutions techniques de VPN anonymisant telles que Tor étant inexistantes, quelques vocations se sont trop rapidement vues refroidies suite à un rappel à la loi plus ou moins amical (ce n’est évidemment pas autobiographique…).

En effet, à part quelques crackme un peu retors prenant la poussière, il était relativement malaisé de s'entraîner sur des cas un peu réalistes d’exploitation de vulnérabilités. Si le reverse de binaires n’était pas votre tasse de thé, ou que vous aviez envie de passer à autre chose, vous risquiez de rester un peu sur votre faim (ou brocouille, comme on dit dans le Bouchonnois).

Au début des années 2000, à l’initiative d’étudiants de l’ESIEA, le challenge SecuriTech voyait le jour et proposait des épreuves de sécurité particulièrement réalistes sur une durée d’une semaine, permettant de s’exercer non seulement en reverse et cryptanalyse, mais aussi à attaquer des applications web ou des binaires vulnérables à une exécution de code à distance. Bref, tout ce qu’il fallait pour apprendre et se mesurer aux autres passionnés croisés sur fr.comp.securite.

Puis, sur le modèle de la DefCon, les compétitions de type CTF commencèrent à se généraliser pendant les conférences, attirant apprentis hackers, étudiants ou compétiteurs chevronnés. C’est par exemple, et pour n’en citer que certains à venir, ph0wn (https://ph0wn.org/) ou le FIC (https://www.forum-fic.com/), pour lequel il y aura d’ailleurs des abonnements MISC à gagner lors de la prochaine édition. Ces challenges, le plus souvent par équipe, donnent l’occasion pour les entreprises de démontrer leurs compétences internes en constituant des équipes concourant sous les couleurs de la société.

D’autres compétitions, sur le modèle de celui du SSTIC, proposent un casse-tête à résoudre à distance avant les autres concurrents. L’ANSSI avait à ce titre mis la barre extrêmement haut en proposant en février 2012 un challenge qui ne sera résolu qu’en janvier 2014 et dont le gagnant, Pierre Bienaimé, avait fait un article dans le numéro 73 de MISC. Vous trouverez d’ailleurs dans ce numéro la résolution, par Pierre encore, du challenge Richelieu publié par la DGSE cette année.

Ainsi, outre l’aspect ludique et extrêmement pédagogique, l’enjeu de ces compétitions est aussi devenu pour les employeurs l’occasion de démontrer leur niveau d’expertise au travers de la conception de challenge et de repérer des talents. Côté compétiteurs, si les prix habituellement proposés font encore un peu pâle figure à côté de ceux remportés dans les compétitions Fortnite, ils sont devenus l’occasion d’enrichir leur CV pour le mercato des experts SSI.

Et si vous préférez vous initier à votre rythme, beaucoup de ressources de très grande qualité sont maintenant disponibles sous forme de machines virtuelles ou d’applications en mode SaaS telles que https://pentesterlab.com/, https://hack.me ou encore https://www.root-me.org/.

Ces compétitions sont en tout cas un formidable terrain d’exploration, et sans vouloir jouer les vieux cons, une bien meilleure manière d’apprendre la sécurité que de s’amuser à réaliser des pentests clandestins au risque d’hypothéquer votre avenir professionnel dans le domaine. Pour paraphraser un conseil amical, et ô combien utile, qui m’a été fait il y a une vingtaine d’années : « on ne peut pas faire de la sécurité le jour et être underground la nuit, il faut être un Jedi ! ».

Cédric FOLL / cedric@miscmag.com / @follc