SecurityInsider
Le blog des experts sécurité Wavestone

Compte-rendu de la conférence RSA 2020



Wavestone était présent à l’édition 2020 de la conférence RSA à San Francisco du 24 au 28 février dernier
Deux sessions ont été présentées par Wavestone durant cette conférence :
Charles "Ibrahimous" "The Red Team Angel" IBRAHIM

  • Pentesting ICS 102, présenté par Arnaud Soullié et Alexandrine Torrents (https://www.rsaconference.com/usa/agenda/pentesting-ics-102) : un workshop de deux heures sur la sécurité des systèmes industriels et comment manipuler des protocoles industriels pour piloter de manière illégitime des automates

Le setup de la démonstration (1/2)

Le setup de la démonstration (2/2)

De nombreuses activités en parallèle étaient disponibles à la 29ème édition de la RSA conférence et pour ses 36 000 participants
  • Le salon des exposants, avec plus de 600 stands de vendeurs présentant leurs solutions
  • La RSA Sandbox avec 12 stands permettant des expériences interactives et des sessions hands-on sur des sujets comme les systèmes industriels, l’IoT, la supply chain, les systèmes de vote, l’aérospatial ou encore la sécurité des voitures
  • Des keynotes sur des sujets d’actualité et d’innovation
  • Et plus d’une quinzaine de sessions en parallèle rien que pour les présentations

Nous vous présentons ci-dessous le compte-rendu d’une sélection de présentations et activités.

RSAC Innovation Sandbox Contest

Cet événement du lundi après-midi a retenu notre attention. Il s’agit d’une compétition pour récompenser les startups les plus innovantes en cybersécurité. Dix finalistes ont été sélectionnés et chaque startup a 3 minutes pour pitcher sa solution et ensuite quelques minutes pour répondre aux questions du jury afin de les convaincre de remporter le prix du RSAC Innovation Sandbox.


La liste ci-dessous constitue la présentation des 10 startups finalistes.

Vulcan

Vulcan est une plateforme de gestion des vulnérabilités. La solution permet d’orchestrer et d’automatiser le process de correction des vulnérabilités dynamiquement, de la détection à la résolution. 
  • Des politiques de correction prédéfinies permettent l’automatisation du process. 
  • Une priorisation par niveau de risque est implémentée pour chaque vulnérabilité. 
  • La solution la plus pertinente est appliquée, que ce soit l’application d’un patch ou un changement de configuration et la solution peut être déployée automatiquement

Tala

Tala propose un WAF côté client afin de protéger les applications web contre l’injection de code malveillant et le vol de données, via des attaques côté client.

Sqreen

Sqreen est une plateforme permettant de gérer la sécurité des applications :
  • Protéger les applications en empêchant les fuites de données, en stoppant la réutilisation de comptes et en bloquant les actions illogiques d’un point de vue business
  • Améliorer la visibilité en supervisant les incidents en temps réel, rendant automatique l’inventaire des applications et en configurant la gestion des incidents
  • Sécuriser le code en identifiant des vulnérabilités critiques et en les corrigeant

Securiti.ai

Securiti.ai propose une solution permettant d’automatiser en un seul endroit toutes les principales fonctions nécessaires à la conformité sur la protection des données personnelles. Elle permet aux entreprises de donner des droits aux personnes sur leurs données, d'être les dépositaires responsables des données des personnes, de se conformer aux réglementations mondiales en matière de data privacy comme le CCPA et de renforcer leurs marques. La plateforme collecte et gère le consentement de plusieurs sources, y compris les propriétés Web, les formulaires Web et les applications SaaS.

Obsidian

Obsidian est une plateforme de détection et de réponse aux incidents Cloud, en particulier dans les environnements SaaS. Elle offre une visibilité unifiée des utilisateurs, des privilèges et de l'activité en SaaS, permettant de détecter et d'enquêter sur les incidents, de découvrir les menaces internes et de sécuriser les applications SaaS sans affecter la productivité.

Inky

Inky propose une solution de protection contre le phishing. Il s’agit d’une plateforme de protection des emails, basée dans le Cloud, utilisant le deep learning pour détecter des comportements anormaux dans les mails envoyés par des expéditeurs connus. Des classifieurs sont utilisés pour déterminer l’expéditeur apparent. En cas de suspicion, une bannière est présente dans le mail pour avertir l’utilisateur.

ForAllSecure

ForAllSecure propose la solution Mayhem, une solution de fuzzing  permettant de détecter automatiquement des vulnérabilités. Cette solution peut être utilisée directement par les développeurs tout au long du cycle de développement logiciel afin de les aider à détecter des failles rapidement et automatiser les tests, avec quasiment aucun faux positif (selon l’éditeur). 

Elevate Security

Elevate Security propose une solution innovante de sensibilisation à la cybersécurité en ajoutant une certaine forme de compétition entre les utilisateurs. En effet, chaque utilisateur a un score selon son comportement et des mails personnels sont envoyés afin de les stimuler. De nombreux tableaux de bord permettent de suivre les évolutions et de communiquer avec le management.

Bluebracket

 Bluebracket propose une solution permettant de sécuriser le code :
  • Découvrir et classifier le code : en fournissant un blueprint (une carte) des environnements de code, Bluebracket permet de comprend où le code est localisé et comment y accéder
  • Surveiller les risques : bluebracket détecte les risques associés au code afin d’éviter toute mauvaise manipulation d’information
  • Protéger les codes sensibles et appliquer des politiques de sécurité

AppOmni

AppOmni propose une solution permettant d’empêcher les fuites de données en SaaS à travers une supervision et un système d’alerte continus. Elle peut se connecter à tous les plus grands Cloud Provider via OAuth et scanner, sécuriser et surveiller les applications SaaS. La solution agit comme un pare-feu pour les données, supervise les flux, ainsi que l’utilisation des comptes et génére des alertes en temps réel.

Et le grand gagnant 2020 est 🥁 ...

Il faut avouer que l’exercice n’est pas évident ! 3 minutes pour exposer clairement sa solution et présenter ses avantages, c’est peu. Mais les start-ups ont réussi avec brio. 
Suite à la présentation des 10 finalistes, le jury a délibéré et s’est mis d’accord sur le grand gagnant de 2020 : securiti.ai, la solution de gestion de data privacy.


A few keynotes 

Le mardi matin, nous avons suivi les keynotes qui lançaient l’ouverture de la RSA conférence. Cette année, le thème de la conférence : the human element. Après une courte introduction par George Takei, l’acteur de Star Trek, nous avons pu écouter des monstres de la cybersécurité comme Rohit Ghai, le président de RSA qui nous a raconté l’histoire de la cybersécurité, en rappelant l’importance de la place de l’homme dans un monde où l’intelligence artificielle augmente les capacités des attaquants et des défenseurs. 
Suite à cette première keyote qui a donné le ton, nous avons pu écouter Steve Grobman, CTO de McAfee, Chris Krebs, directeur de la Cybersecurity and Infrastructure Security Agency ou encore des cryptographes de renom tel qu'Adi Shamir, Ron Rivest et Whitfield Diffie discuter des actualités et des challenges de 2020. 
Mais la keynote qui a le plus retenu notre attention est celle de Wendy Nather, la RSSI groupe de Cisco qui nous a parlé de la démocratisation de la cybersécurité. Et si nous donnions le pouvoir de la cybersécurité aux gens ? 3 étapes pour y arriver :
  • Changer le modèle : du contrôle à la collaboration
  • Simplifier le design afin d’augmenter le niveau d’acceptation des utilisateurs 
  • Ouvrir la culture


The emerging role of the CPSO

Speaker : Stephanie Domas, CPSO de MedSec
Objectif du talk : Présenter le rôle de Chief Product Security Officer (CPSO) : notamment, en quoi est-il différent du RSSI ? pourquoi un CPSO et quelles doivent être ses compétences ?

Tout d’abord, Stéphanie a expliqué pourquoi la sécurité produit est nécessaire : les ventes de produits représentent une part de revenue importante pour les entreprises, la perte de confiance dans un produit peut ruiner une entreprise, les clients ajoutent des clauses de sécurité pour les produits dans les contrats et la responsabilité des produits est de plus en plus mise en cause dans les incidents de sécurité.
Le CPSO doit donc superviser la sécurité des produits dans l’entreprise, ainsi qu’implémenter et piloter un programme de sécurité produit. Parmi les responsabilités du CPSO, on retrouve la sécurité dans le design, la gestion des risques cyber, la gestion des vulnérabilités, la réponse à incident et la définition et mise en œuvre de politiques et procédures et ce durant tout le cycle de vie du produit, de la conception au lancement.
Ces responsabilités peuvent paraître similaires à celles d’un RSSI, mais l’exécution de ces responsabilités est très différente pour un CPSO et la sécurité des produits est un domaine complètement différent de la sécurité d’un environnement d’entreprise.
Et Stéphanie montre ces différences en prenant l’exemple de la réponse à incident où le CPSO doit gérer une dimension toute autre puisque les incidents sont bien souvent remontés via les clients : l’équipe R&D doit donc tout d’abord recréer l’incident et une fois recréé, des aspects légaux doivent être pris en compte comme le planning de patch à respecter, du nouveau code doit être écrit, une nouvelle version du produit doit être construite, puis testée, puis publiée. 
Pour réaliser l’ensemble des activités du CPSO, le CPSO doit avoir un certain nombre d’atouts :
  • Des compétences techniques
  • Un background de R&D et une bonne connaissance du cycle de vie des produits
  • La dévotion 
  • Le changement de culture 
  • Être au niveau des C-level et non enterré dans la R&D

Le CPSO représente donc un besoin unique pour une entreprise vendant des produits et doit être différent du RSSI. 
Bien que courte (30 minutes seulement), la présentation était très intéressante, mais ce qui a rendu l’intervention encore plus intéressante était les questions posées par les participants, notamment sur le positionnement du CPSO dans l’entreprise. Bien que le côté R&D soit important, il est préférable que le N+1 du CPSO soit le RSSI ou même le CEO. Mais tout dépend de l’historique de l’entreprise !


Defending Serverless Infrastructure in the Cloud

Speaker : Eric Johnson, Principal security engineer chez Puma Security
Objectif du talk : Comprendre les attaques sur les environnements serverless (Function as a Service) i.e. Red team, afin de pouvoir les défendre i.e. Blue team 

Eric a présenté plusieurs types d’attaques en environnement serverless. Toutes partaient du prérequis qu’une première vulnérabilité applicative avait déjà été exploitée pour obtenir un shell. Exploiter les faiblesses de configuration par défaut du filtrage, exposant sur Internet les secrets ainsi que les espaces de stockage
  • Accéder aux secrets, parfois stockés en dur dans le code ou dans un fichier de configuration
  • Récupérer les variables d’environnements via une LFI ou une vulnérabilité d’injection de commande
  • Profiter de rôle d’exécution trop privilégié pour accéder à des ressources externes à la fonction
  • Utiliser des authentifiants volés pour accéder à des ressources Cloud non suffisamment cloisonnées
  • Utiliser les répertoires accessibles en écriture pour assurer la persistance 

Toutes les attaques de cette session peuvent être reproduites sur les Cloud Azure, AWS et GCP avec la solution Serverless Prey de Puma Security.
Plusieurs solutions existent pour se protéger de ce type d’attaques et pour réduire la surface d’attaque :
  • Utiliser les logs des Cloud providers pour détecter les tentatives d’accès non autorisées
  • Implémenter du contrôle d’accès réseau avec des Virtual Private Cloud afin de n’exposer aucun service sur Internet par défaut et ouvrir les flux uniquement strictement nécessaires
  • Activer les logs sur les flux VPC
  • Configurer des service endpoints privés entre la fonction et les ressources Cloud

Le chemin est relativement long avant d’utiliser les fonctions pour détecter des compromissions mais la première étape est de faire un inventaire de ses fonctions et de scanner ses répertoires à la recherche de vulnérabilités et de mauvaise pratique de stockage des secrets. Ensuite vient la mise en place de monitoring et de système d’alerte.


Serverless attack vectors

Speaker : Teri Radichel, CEO de 2nd Sight Lab
Objectif du talk : Présenter les vecteurs d’attaque possibles sur des fonctions (environnements serverless)

Contrairement à la conférence précédente, cette présentation était centrée sur les vulnérabilités applicatives et non les possibilités d’exploitation une fois qu’un reverse shell est obtenu. 
Ce qu’il faut retenir est que ces fonctions en environnement serverless utilisent toujours des softwares et sont toujours installés sur des serveurs managés par les Cloud providers. Les attaquants utilisent donc des vulnérabilités web classiques pour compromettre ces fonctions. D’ailleurs, l’OWASP a publié un Top 10 des vulnérabilités serverless et celles-ci sont très similaires au Top 10 bien connu des vulnérabilités web. On retrouve notamment toutes les familles d’injection.
La seule différence est l’environnement et les spécificités des services Cloud. Conclusion du talk : le serverless, c’est la même chose mais en différent.


The Industrial Cyberthreat Landscape: 2019 Year in Review – Keynote

Speaker : Robert Lee, CEO de Dragos
Objectif de la keynote : Présenter les nouvelles menaces sur les environnements industriels et les enseignements tirés par l’équipe Dragos au cours de l’année 2019

Dragos a publié comme chaque année son Year in Review. Voici les principaux éléments à retenir :
  • Plus de 50% des vulnérabilités identifiées ne constituent aucun risque pour les environnements industriels. En effet, il existe d’autres moyens pour arriver au même résultat. Il convient donc de patcher intelligemment.
  • Beaucoup de choses ont été dites sur l’attaque Triton de 2018 et elles ne sont pas toutes vraies mais un point important est le fait que Saudi Aramco (qui n’était pas la victime) a fait partie de l’équipe de réponse à incident. Cela montre que l’aide de la communauté est importante dans les environnements industriels.
  • Chiffres sur les vulnérabilités ICS
    • 24% des vulnérabilités sont liées aux protocoles industriels. 
    • La majeure partie des vulnérabilités sont encrées profondément dans les réseaux industriels et nécessitent un accès préalable pour les exploiter.
    • 55% des vulnérabilités ont un patch associé mais aucune solution de remédiation alternative ; 26% des vulnérabilités n’ont même pas de patchs associés 
  • 11 groupes d’attaquants sont répertoriés sur les systèmes industriels et leurs activités ont été mappées avec le framework MITRE ATT&CK for ICS
  • Ces groupes d’attaquant ciblent de plus en plus les solutions d’accès distants comme le VPN
  • Les différentes réponses à incident ont permis de tirer les leçons suivantes
    • 100% des organisations ont des périmètres faibles et avaient des connections réseaux routables depuis la bureautique et Internet
    • Les organisations ont une visibilité faible sur leur environnement et dans tous les cas incidents, une récupération manuelle des logs a été nécessaire

Ces retours montrent que les attaquants sont de plus en plus outillés pour cibler les systèmes industriels alors que le niveau de sécurité des organisations reste relativement faible.
Les recommandations de Robert sont de mettre en place un processus de réponse à incident, augmenter le niveau de visibilité sur ses systèmes, activer la double authentification pour les accès distants et appliquer une approche basée sur les risques pour la gestion des patchs. 


Advanced Persistent Threats: the future of Kubernetes attacks

Speakers : Ian Coldwater, Lead Infrastructure Security Engineer chez Salesforce et Brad Geesaman, co fondateur de Darkbit.io 
Objectif du talk : Présenter des attaques avancées sur les versions les plus récentes de Kunernetes

Kubernetes est de plus en plus populaire et les attaquants aussi se penchent sur les possibilités de Kubernetes. Le niveau de sécurité a augmenté depuis le début de Kubernetes et les évolutions vont vite avec de nouvelles versions tous les 90 jours en moyenne. Comme l’installation de nouvelles versions prend du temps, cela nous laisse la possibilité d’étudier les nouvelles fonctionnalités et en particulier la sécurité.
Que peuvent faire les attaquants ? Le but ultime n’est pas toujours d’être admin d’un cluster car certains attaquant possèdent déjà potentiellement des privilèges élevés. Ce talk est donc plus orienté post-exploitation et présente des attaques avancées et des moyens d’assurer la persistance.
Plusieurs types d’attaques sont possibles :
  • L’utilisation des validated webhooks associés à une application malveillante en dehors du cluster : une utilisation possible est de faire une application permettant de récupérer tous les secrets. Ceux-ci étant en clair et simplement encodés en base 64, il est très facile de les utiliser directement.
  • Les logs trop longs : il y a une différence de taille importante entre celle autorisée pour la création d’un pod et le journal de création du pod. Il est donc possible d’ajouter du bruit important dans la requête de création du pod afin que les actions malveillantes ne soient pas loguées
  • Un exemple particulier est la création d’un shadow serveur API afin de bypasser le serveur API principal et requêter tous les secrets sans être détecté.

Il est possible d’aller encore plus loin avec Kubernetes et d’utiliser Kubernetes comme un C2 : C2bernetes ! Une version light de Kubernetes (K3s) peut être utilisée pour créer son infrastructure C2 et se propager à travers plusieurs clusters. Ian et Brad ont démontré la possibilité de déployer le C2 et de compromettre des nodes des 3 plus grands Cloud providers sans laisser de trace : Azure, AWS et GCP.
Et ce n’est pas tout : de nouvelles fonctionnalités peuvent déjà être étudiées et les dynamic Kubelet configuration peuvent permettre de reconfigurer Kubernetes lui-même et par exemple désactiver l’authentification. Une présentation vraiment passionnante avec des démonstrations bluffantes


Cloud Threat Hunting

Speakers : Sherri Davidoff, Matt Durrin - LMG Security
Objectif du talk : Comment mettre en place une plateforme efficace d’investigation dans le cloud 

Leur approche s’appuie sur une boucle en 3 étapes : « Test, Fine-tune, Repeat ». Après avoir rappelé quelques erreurs opérationnelles à éviter (par exemple : oublier d’activer CloudWatch), les speakers ont pris un cas d’usage d’Amazon Firehose, un produit AWS permettant de créer un stream de données entre vos sources de logs et des puits comme Amazon RedShift ou Splunk. Ils ont ensuite déroulé une investigation consistant à regarder des événements AWS particuliers dans les logs (nommément : « Listbuckets, « ListFunctions, GetObject »).
Les speakers en ont profité pour critiquer Azure, très peu adapté selon eux aux investigations en raison : 
  • De résultats différents pour 2 requêtes successives identiques
  • De difficultés à télécharger de larges volumes de données
  • … et même du blocage de l’interface de téléchargement au-delà de 1500 résultats.

Une présentation intéressante sur le suivi d’une investigation mais malheureusement peu de contre-mesures proposées.


AI Security Engineering — Modelling/Detecting/Mitigating New Vulnerabilities

Speakers : Andrew Marshall, Jugal Parikh, Raul Rojas - Microsoft Corporation
Objectif du talk : Démontrer les enjeux de l’injection de données falsifiées dans des modèles d’apprentissage supervisés
Comme souvent outre-Atlantique, au lieu des bases théoriques, la présentation commence par un exemple parlant, en l’occurrence la perturbation de trajectoires de véhicules autonomes après application d’un filtre sur des panneaux de signalisation (un panneau STOP est catégorisé par l’algorithme comme un panneau de vitesse). Les applications de l’injection de données sont nombreuses et très réelles désormais (valables dans le milieu des plateformes pétrolières aussi bien que pour des contenus terroristes contournant la détection reconnaissance automatique par les outils des services de renseignement, en passant par du « bruit » ajouté à des phrases permettant de complétement changer la compréhension par OK Google.
Modifier seulement 3% des données de test permet de changer plus de 10% des résultats, rendant le modèle presque inutile.
Des méthodes de défense existent, mais ne garantissent pas 100% de robustesse
  • Définition de senseurs d’anomalie
  • Validation et assainissement des entrées, vérification d’intégrité
  • Apprentissage robuste
  • Micromodels, STRIP, Human in the loop, TRIM

En conclusion, il ne faut pas s’appuyer sur des données dont la confiance est trop faible.


Plusieurs débats sur la 5G

Coordinating a Competitive 5G Strategy among Freemarket Democracies 

Participants : 
  • Admiral Dennis Blair, Sasakawa USA
  • Michael Chertoff, Chertoff Group
  • Arthur Coviello, Rally Ventures
  • William Roth, Sasakawa USA
  • Christy Wyatt, Absolute


How to Reduce Supply Chain Risk: Lessons from Efforts to Block Huawei

Participants :
  • Katie Arrington, US Dept of Defense / OUSD for Acquisitions
  • Donald (Andy) Purdy, Huawei Technologies USA
  • Bruce Schneier, Harvard Kennedy School
  • Craig Spiezle, Agelight Advisory and Research Group
  • Kathryn Waldron, R Street Institute



Plusieurs débats autour de la 5G ont été organisés cette année, et nous vous recommandons vivement de regarder les vidéos, notamment du second débat. 
Voici les points qui ont retenu notre attention :
  • Les personnalités du département de la Défense déclarent ouvertement qu’aucune collaboration avec la Chine n’est possible, qu’aucune confiance dans les équipements Huawei n’est envisageable, et qu’il est par conséquent absolument impossible de trouver une solution à la mainmise des industriels chinois sur les équipements 5G.
  • Le second débat a fait l’objet d’échanges très intenses entre Katie Arrington et Bruce Schneier, le dernier déniant en bloc la possibilité que les USA puissent compenser les avantages de Huawei, la première priorisant certains objectifs, et avançant que le DoD y travaillait déjà d’arrache-pied, qu’il était nécessaire et possible en particulier de reconstruire une supply chain américaine. 


Nos impressions sur la conférence

L’organisation de la conférence ridiculise en importance et en rigueur la quasi-totalité des conférences auxquelles nous avons pu participer, avec pas moins de 36 000 participants, des dizaines de speakers, et des dizaines d’événements en parallèle. En tant que speaker, nous avions un speaker manager s’assurant du respect des deadlines d’envoi des supports, de la relecture de ces derniers et de l’intégration des modifications demandées par le comité de lecture… 
Le contenu des conférences était relativement peu technique, avec des thèmes très orientées sur les tendances de fond de la cybersécurité au niveau mondial, et une mise en valeur importante des enjeux fondamentaux des prochaines années (la 5G, Zero Trust, la sécurité des produits, toujours plus de solutions et produits Cloud, etc.).
De nombreuses personnalités de la cybersécurité étaient présentes, et notamment dans les Keynotes : des cryptographes de renom (Ron Rivest, Adi Shamir, Diffie, etc.), Bruce Schneier, et des personnes à des postes à hautes responsabilités (SVP Microsoft, directeur RSA, Groupe CISO de grands groupes comme CISCO)
Les échanges avec les éditeurs étaient très instructifs, une pléthore de solutions très innovantes étaient mise en lumière de façon parfois grandiose (l’Aston Martin de Sentinel One…).


Alexandrine TORRENTS
Arnaud SOULLIE
Charles IBRAHIM

CTF, un nouveau challenge pour Microsoft

Résultat de recherche d'images pour "ctfmon"

Présentation du protocole CTF

Différentes vulnérabilités affectant le protocole CTF ont été découvertes par le chercheur Tavis Ormandy de l’équipe Google Project Zero. 
Ce protocole est partie intégrante du Windows Text Services Framework. Ce dernier permet, entre autres, la gestion de la disposition du clavier, le paramétrage du traitement de texte ou encore la configuration de la méthode de saisie des caractères.
Un des rôles du protocole CTF est ainsi d’informer les différentes applications en cas d’éventuel changement de ces paramétrages. 
Ces notifications sont réalisées à l’aide du service ctfmon. Chaque application lors de son lancement va systématiquement se connecter à ce service, lui permettant alors d’être notifiée par ce dernier, ainsi que d’échanger avec les diverses applications également clientes.
Un processus ctfmon est instancié pour chaque session ou bureau créé.

Exécution du processus ctfmon.exe

Ce dernier ouvre alors un port ALPC (Asynchronous Local Inter-Process Communication) dédié nommé \BaseNamedObjects\msctf.server<DesktopName><SessionId>.

Port ALPC ouvert par un serveur CTF

Lorsqu’une nouvelle fenêtre est instanciée par un processus, le client CTF est automatiquement chargé et communique certaines de ses propriétés au serveur CTF au travers du port ALPC. Notamment, le processus client transmet son handle de fenêtre (HWND), ainsi que son identifiant et celui de son thread.

Faiblesses du protocole CTF

Le protocole CTF, implémenté à l’origine pour LPC au sein de Windows XP puis adapté à ALPC depuis Windows Vista, souffre de différentes faiblesses de conception.
D’une part, le protocole ne bénéficie d’aucun mécanisme d’authentification ni de contrôle d’accès. Ainsi, toute ressource est en mesure de se connecter à n’importe quelle session CTF. En effet, pour rappel tout processus communique ses propriétés lors de son inscription auprès d’un serveur CTF ; ces dernières peuvent alors être altérées par des valeurs arbitraires.
D’autre part, toute ressource est en mesure de se déclarer serveur, et ainsi exploiter illégitimement des connexions émanant d’applications clientes s’y connectant, privilégiées ou non.

Exploitation via ctftool

Afin de faciliter ses recherches, Tavis Ormandy a développé un outil permettant d’interagir avec le protocole CTF : ctftool. Ce dernier permet l’envoi ainsi que la réception de message au travers du protocole CTF avec un serveur ou un client CTF arbitraire.

Liste des commandes mises à disposition par l’outil ctftool

Etablissement d’une connexion à un serveur CTF

La connexion au serveur CTF se réalise au travers de la commande connect. Sans argument, la commande permet la connexion au serveur CTF de la session courante. 


Néanmoins, le protocole CTF n’assure aucune isolation des différentes sessions et bureau. Ainsi, il est possible de se connecter au serveur CTF d’une session arbitraire via le renseignement du nom du bureau ainsi que de la session souhaitée. La vidéo suivante illustre la connexion à un serveur CTF d’une session arbitraire.



Suite à l’établissement d’une connexion avec un serveur CTF, il est possible d’énumérer les différents clients connectés via la commande scan.



Communication inter-clients

L’outil ctftool permet la communication entre les différents clients connectés à un serveur CTF ; ce dernier faisant alors office de proxy.
Une telle exploitation nécessite cependant la présence d’un langage exploitant un IME (Input Message Editor) autorisant l’accès aux entrées utilisateurs par un autre processus, tel que les langages Chinois ou Japonais par exemple. En effet, ces IME autorisent l’accès aux entrées utilisateurs renseignées au travers du clavier dans le but de les convertir vers les caractères spéciaux du langage configuré.

Par ailleurs, l’absence de l’implémentation d’un mécanisme de contrôle d’accès au sein du protocole CTF permet le contournement d’un principe fondamental de la sécurité Windows : UIPI, ou User Interface Privilege Isolation. 
En effet, introduit au sein du modèle de sécurité Windows depuis Windows Vista et Windows Server 2008, ce principe de sécurité interdit notamment l’envoi de message par un processus vers un autre disposant d’un niveau de privilège plus élevé.
Les vulnérabilités affectant par nature le protocole CTF permettent le contournement de l’UIPI, et ainsi l’injection et la consultation, depuis une session non privilégiée, des données manipulées par un processus privilégié. Une telle action est grandement facilitée par l’outil ctftool, qui offre la possibilité d’attendre la connexion d’un processus arbitraire à un serveur CTF maîtrisé pour éventuellement échanger avec ce dernier. Une telle action se réalise au travers de l’action wait.
La vidéo suivante illustre l’injection de données arbitraire depuis une session non privilégiée au sein d’un processus privilégié.



Ainsi, un utilisateur malveillant est en mesure, via l’exploitation des faiblesses de contrôle d’accès du protocole CTF, d’injecter des commandes arbitraires au sein d’une invite de commande exécutée par un administrateur.

Exploitation SYSTEM

Au moment des recherches conduites par Tavis Ormandy, le protocole CTF souffrait de différentes vulnérabilités critiques de corruption de mémoire.
Le chercheur a donc développé un code d’exploitation pour l’une de ces vulnérabilités, lui permettant alors la compromission de toute session cliente connectée à un serveur CTF ; cela indépendamment de la présence d’un langage IME autorisant l’accès aux entrées utilisateur par un autre processus.
La mire de consentement UAC (consent.exe) est exécutée avec les privilèges SYSTEM et est cliente du serveur CTF privilégié Winlogon Desktop. Cette dernière peut être générée par tout utilisateur non privilégié au travers de la méthode runas.

Processus consent.exe client du serveur CTF WinLogon 1

L’exploitation d’une vulnérabilité de corruption de mémoire au sein de la session CTF de l’interface de consentement UAC permet donc l’élévation de privilège par tout utilisateur d’un système Windows, comme l’illustre la vidéo suivante :



Par ailleurs, une telle élévation de privilège peut être réalisée via la corruption de la session CTF de l’interface de connexion Windows (LogonUI.exe), elle aussi exécutée en tant que SYSTEM. 


Remédiation

Les mises à jour de sécurité Windows publiées le mardi 13 août 2019 assurent la correction des vulnérabilités de corruption de mémoires présentes au sein de l’implémentation du protocole CTF.
Néanmoins, ces correctifs ne permettent pas de se prémunir des abus liés à l’absence de contrôle d’accès ou d’authentification affectant le protocole CTF. En effet, de telles améliorations nécessiteraient une revue en profondeur de l’implémentation du protocole CTF.


François LELIEVRE

Taking over Windows Workstations thanks to LAPS and PXE


The workstation remains one of the favorite targets during Red Team operations. However, its security level has drastically increased with security solutions such as Bitlocker or LAPS. Can these improvements introduce new attack paths?

In this article we will examine how the combination of two good security solutions with no apparent connection to each other can lead to the takeover of all workstations in a Windows environment. The main advantage of this technique is that it is exploitable in black box, i.e. without any prior knowledge of the target.

Automated mastering of workstations

Deploying and configuring large numbers of workstations is a tedious task that can benefit from automation using tools such as Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager (SCCM). These technologies allow, for example, to install a Windows image on a workstation from a network access and to automate its integration into the company's Active Directory.

Microsoft Deployment Toolkit (MDT)

Microsoft Deployment Toolkit [MDT] is a Microsoft tool that allows deploying a Windows image with a predefined configuration. MDT captures a Windows image (".wim" format) and uses it to deploy Windows to new devices. To accelerate the deployment of a new device, these files are deployed on the network so that the workstation can boot on the network through PXE. By default, they are publicly accessible (without authentication) using the Trivial FTP protocol (TFTP).

Boot PXE

The PXE boot (Pre-boot eXecution Environment) allows a workstation to boot from the network. It relies on a specific DHCP server response defined in RFC 4578 [DHCP & PXE].
The PXE client sends a DHCP request with specific options related to PXE and the DHCP server response give, in addition to the usual IP addressing information, the location of the pre-boot file on the network, accessible via TFTP.

Fig. 1 : Download « wim » image

Once the image is loaded, the client installs the content on the local disk and integrates it into the Active Directory through a dedicated service account included in the PXE pre-boot image. Once the installation is completed, the workstation is functional and the enrollment in the Active Directory is effective.

Retrieval of sensitive data

These PXE boot features have already been studied by many people [NETSPI] and are useful for an attacker because they allow extracting sensitive information. Indeed, an attacker can boot on PXE and take advantage of this automated process to obtain a standard workstation in the target domain, without prior information.

In particular, it is possible to :
  • Press F8 key during the Windows PE deployment phase, which prompts an administrator console on the machine. This provides access to the contents of the file system that will be deployed to the workstation.
  • Press Shift+F10 during the setup process will bring up a system console. For example, a local administrator account could be added on the device or the SAM and SYSTEM databases could be extracted to obtain the default password hash of the local administrator account;
  • Extract and analyse the memory of the workstation during the setup in order to extract sensitive information;
  • Retrieve the pre-boot image file ".wim" to access all the settings: password of the service account used for integration in the domain, files containing default passwords such as "unattend.xml", etc.

The next section will focus on this last option.

Searching and extracting the image file

In order to make it easier to obtain the pre-boot image from a DHCP request, we developed a Powershell [POWERPXE] script to automate the following steps (additional steps are present in the case of SCCM [SCCM & PXE]):
  • Initialization of the DHCP exchange in "discover" mode;
  • Extraction of the location of the boot configuration file ".bcd" in the DHCP response;
  • Downloading the "bcd" file via TFTP;
  • Extraction of the location of the ".wim" image store in the boot configuration file;
  • Downloading the ".wim" image via TFTP;
  • Searching for plain text passwords, especially in the "Bootstrap.ini" and "CustomSettings.ini" files.

This script needs to be run as an administrator to change the network interface configuration as well as open the boot configuration file.

To test this script, the reader could use the AutomatedLab [AUTOMATEDLAB] project and a specific configuration file hosted on GitHub [POWERPXE]. This lab consists of :
  • A "lab.fr" domain controller;
  • A server with the "MDT" role exposing a DHCP service, network directories and a TFTP interface;
  • A server to test the attack, it is also possible to test the script with a simple network access.


PS > Import-Module .\PowerPXE.ps1 PS > Get-PXECreds -InterfaceAlias "lab 0" >> Get a valid IP adress >>> >>> DHCP proposal IP address: 192.168.22.101 >>> >>> DHCP Validation: DHCPACK >>> >>> IP address configured: 192.168.22.101 >> Request BCD File path >>> >>> BCD File path: \Tmp\x86x64{5AF4E332-C90A-4015-9BA2-F8A7C9FF04E6}.bcd >>> >>> TFTP IP Address: 192.168.22.3 >> Launch TFTP download >>>> Transfer succeeded. >> Parse the BCD file: conf.bcd >>>> Identify wim file : \Boot\x86\Images\LiteTouchPE_x86.wim >>>> Identify wim file : \Boot\x64\Images\LiteTouchPE_x64.wim >> Launch TFTP download >>>> Transfer succeeded. >> Open LiteTouchPE_x86.wim >>>> Finding Bootstrap.ini >>>> >>>> DeployRoot = \\LAB-MDT\DeploymentShare$ >>>> >>>> UserID = MdtService >>>> >>>> UserPassword = Somepass1 [...]
Note for the reader: if the account used to join the domain is in the "Domain Admins" group, it is your lucky day!!! #TrueStory

Going further

This account is generally not tagged as sensitive, it may be found in other locations: SMB shares, SharePoint, etc.
Also, if the PXE boot is restricted to a specific network zone, the ".wim" file or the associated configuration files "Bootstrap.ini" and "CustomSettings.ini" are generally accessible on file shares with little access control. In this case, read access to this file allows to perform the attack described in the next section.

From domain join to administrative privileges on all workstations

The privilege « Domain Join »

The "Domain Join" privilege (or joining a device in the domain) corresponds to the Active Directory privilege "Add workstation to domain" [JOIN-DOMAIN]. In the default configuration, any authenticated user can join up to 10 machines to the domain.
However, in most companies, this privilege is restricted via a GPO (Group Policy Object) present in the domain.
  • Computer Configuration
    • Windows settings
      • Security Settings
        • User Rights Assignment
          • Add Workstations to the Domain

By default, the "Account Operator" group has the necessary privilege to join a machine to the domain. However, it is not recommended to use it because the privileges of this group are too high: for example, it allows opening an interactive session on the domain controllers.
Usually a dedicated service account is created: this is a basic domain account with only specific privileges to be able to join a workstation to the domain.
When a machine is integrated into the domain, an object of the class "computer" is created in the Active Directory. The user account used to create this object, i.e. joining a machine, is defined as the owner of this object.

How LAPS works

As the machines are deployed from a single template, the password of the local "Administrator" account (builtin, aka RID 500) is the same on all machines. This configuration is a vulnerability because it allows pivoting on all the others in case of compromise of a single machine. The robustness of the local account password is not even considered because it will be possible to move laterally with Pass The Hash (PtH).
The "Local Administrator Password Solution" tool, LAPS, allows modifying and managing the passwords of one local account automatically.
When the LAPS solution is installed, two security attributes are added to the machine class:
  • The "ms-mcs-AdmPwd" a "confidential" computer attribute that stores the clear-text LAPS password. Confidential attributes can only be viewed by Domain Admins by default, and unlike other attributes, is not accessible by Authenticated Users
  • The "ms-mcs-AdmPwdExpirationTime" regular attribute computer attribute that stores the LAPS password reset date/time value.

The "Find-AdmPwdExtendedRights" command inside the LAPS PowerShell module (the AdmPwd.PS module) identifies groups or users who can access the LAPS passwords. Indeed, this module lists the users with read access on the "ms-mcs-AdmPwd" attribute:

PS > Import-Module AdmPwd.PS PS > Find-AdmPwdExtendedRights | fl ObjectDN : OU=COMPUTER,DC=lab,DC=fr ExtendedRightHolders : {LAB\LAPS_recover, LAB\Domain Admins}


Taking over workstation thanks to LAPS

The owner of an object and the privileges granted to users (or other objects) on that object are stored in a security descriptor. Access rights (i.e. privileges) take the form of a DACL (Discretionary Access Control List) composed of ACEs (Access Control Entries), where each ACE describes one or more permissions granted or denied to a user.
The following script extract the privileges granted by default (via ACEs) to the owner of a computer object:

Import-module ActiveDirectory ## Extraction de la configuration par défaut d’un objet « computer » $computerobject = Get-ADObject -SearchBase (Get-ADRootDSE).SchemaNamingContext -Filter {Name -eq "Computer" } -Properties defaultSecurityDescriptor ## Creation d’un objet permettant la gestion des ACL $sec = New-Object System.DirectoryServices.ActiveDirectorySecurity $sec.SetSecurityDescriptorSddlForm($computerobject.defaultSecurityDescriptor) ## Recherche des privilèges du propriétaire de l’objet $acc = New-Object System.Security.Principal.NTAccount("CREATEUR PROPRIETAIRE") ## ou "CREATOR OWNER" $sec.GetAccessRules($true,$false,[System.Security.Principal.NTAccount]) | Where-Object {$_.IdentityReference -eq $acc}

The result of the command contains, among other things, the following ACE:

ActiveDirectoryRights : DeleteTree, ExtendedRight, Delete, GenericRead InheritanceType : None ObjectType : 00000000-0000-0000-0000-000000000000 InheritedObjectType : 00000000-0000-0000-0000-000000000000 ObjectFlags : None AccessControlType : Allow IdentityReference : CREATEUR PROPRIETAIRE IsInherited : False InheritanceFlags : None PropagationFlags : None

The owner of an object, inherited from the class "computer", has by default the privilege "ExtendedRight". However, the "ExtendedRight" privilege, or rather "All extended rights" in the graphical interface, allows access to the LAPS password.
For example, the password can be accessed using PowerView :

PS > Import-Module .\PowerView.ps1 PS > Get-DomainComputer COMPUTER -Properties ms-mcs-AdmPwd,ComputerName,ms-mcs-AdmPwdExpirationTime ComputerName : COMPUTER ms-mcs-AdmPwd : 9g)4G+35w;2$ ms-mcs-AdmPwdExpirationTime : 08/04/2019

The account used to join a machine in the domain can compromise it if LAPS is deployed. Furthermore, if the same account is used to perform all domain join, as is often the case using MDT or SCCM, the service account can take over all workstations.
The owners of the "computer" objects can be identified with the following commands:

Import-module ActiveDirectory $computers = Get-ADComputer -Filter * foreach ($comp in $computers) { $comppath = "AD:$($comp.DistinguishedName.ToString())" $acl = Get-Acl -Path $comppath Write-Host $comp.SamAccountName $acl.Owner }

Hardening

Protect the PXE boot sequence

To avoid an attacker with access to the corporate network booting into PXE, it is strongly recommended that the ability to boot this way is limited to specific network areas, such as dedicated rooms with physical access control.
On the other hand, it is also recommended to require a password before starting the deployment. This can be configured by checking the "Require a Password when computers use PXE" checkbox in the SCCM configuration.
More generally, Microsoft's recommendations for deploying PXE [PXE SECURITY] are a good starting point to secure any PXE installation.

Removing ExtendedRights Privileges, a False Good Idea

Microsoft proposes also to reduce the privileges of the creator owner of the object so that he can no longer access the security attributes related to LAPS [LAPS-PERMISSION]. This first solution involves changing the defaultSecurityDescriptor of the "computer" class to remove the privilege "ExtendedRights" from the user "OWNER CREATOR". The default value, in SSDL format, is :
(A;;RPCRLCLORCSDDT;;;CO)
It will become:
(A;;RPLCLORCSDDT;;;CO)
Thus, every owner of an object of the "computer" class loses the extended attributes and can no longer access the LAPS attributes: that's it!
Unfortunately, this configuration change is not enough. Indeed, the owner of an object [OWNER] has implicitly the "Write-Dacl" privilege on this object. With a little subtlety: the "Write-Dacl" right of the owner is not specified in the ACL of the object but exists.
As its name indicates, "Write-Dacl" allows to write an ACE in the DACL. It is possible to auto-grant the privilege "GenericAll" or "ExtendedRights" on an object.
This path can be visualized with BloodHound since version 2.0 (August 2018):

Fig. 2 : BloodHound Path

This path can be exploited with PowerView with the following command to add the "GenericAll " privilege on the "COMPUTER" device (commands have to be run as the owner user of the object) :

PS > Import-Module .\PowerView.ps1 PS > Add-DomainObjectAcl -TargetIdentity COMPUTER -Rights All PS > Get-DomainComputer COMPUTER -Properties ms-mcs-AdmPwd,ComputerName,ms-mcs-AdmPwdExpirationTime ComputerName : COMPUTER ms-mcs-AdmPwd : 9g)4G+35w;2$ ms-mcs-AdmPwdExpirationTime : 08/04/2019

A "deep" hardening

The owner of a computer object can still read the LAPS password. A first "homemade" solution is to regularly follow and change all owner.
For example, it is possible to define the "Domain Admins" group:

Import-module ActiveDirectory $computers = Get-ADComputer -Filter * foreach ($comp in $computers) { $comppath = "AD:$($comp.DistinguishedName.ToString())" $acl = Get-Acl -Path $comppath $objUser = New-Object System.Security.Principal.NTAccount("<DOMAIN>", "Domain Admins") $acl.SetOwner($objUser) Set-Acl -Path $comppath -AclObject $acl }

Microsoft also offers a second solution by manually changing the privileges of the owner of an object [OWNER-RIGHTS] at the OU level:
  • Open the Active Directory Users and Computers snap-in
  • Right-click the OU on which you want to implement Owner Rights, and then click Properties
  • In the Properties box of the OU, click the Security tab
  • Under Group or usernames, click Add
  • Enter "OWNER CREATOR" or "CREATOR OWNER" in the text box.
  • Define the permissions granted to the owner of an object

A specific definition of the privileges of the "OWNER CREATOR" user on the OU, i.e the creation of explicit ACE, take precedence over the implicit privileges.
However, this technique must be tested on a test environment before being deployed in production.


Conclusion

Taken individually, PXE and LAPS provide high security value within an information system. However, the combination, even when properly configured, can lead to the compromise of a large part of the information system.
Today, the article has focused on windows deployment and LAPS but other solutions with high privileges on a lot of computers (WSUS, antivirus or backup agent) can allow pivoting inside the IS.


Rémi ESCOURROU
Cyprien OGER

French original publication : MISC n° 103 
https://connect.ed-diamond.com/MISC/MISC-103/Compromission-des-postes-de-travail-grace-a-LAPS-et-PXE


References



CERT-W: Cybersecurity watch of January events


You will find below our weekly report on cybersecurity news. Use this brief compilation to support your coffee break small talk!

Cybercrime watch

Jeff Bezos phone hacked: publication of the technical report

For many months, the phone of Jeff Bezos has been sending out private, sensitive and/or confidential data. After months of forensic, analysts did not found any malware installed on the phone in data extracts and iTunes backup given by J. Bezos, but a suspicious video sent through WhatsApp.
Since the reception of the video, Bezos' phone started to send more than 120MB of data per days.
The spyware has not been found in the iTunes backup because iTunes does not create a back-up for system files but only for messages, videos, etc... Thus, in order to find this malware, analysts should jailbreak Bezos iPhone in order to get a root account on the phone and then access to system files.

Half a million IOT devices passwords publicly published

An hacker has published a list of 515,000 credentials of servers, router, and IoT. The list included the device's IP and the username for the telnet service. Thus, these devices can be remotely controlled over the Internet to create a botnet for example (remember Mirai).
This list was compiled by scanning the whole internet for devices exposing their telnet port. Then, default credentials were tried as well as a list of common credentials.

Ryuk's last strike: Tampa Bay Times

The Ryuk crypto-locking malware has strike a great number of major US newspaper since December 2018. After the Chicago Tribunes or the Los Angeles Times, it is the turn of the Tampa Bay Times to suffer a loss from this ransomware. The attack did not success to compromised payment data and the online publications were not interrupted. Thank to their well thought recovery plan, the newspaper is actively restoring its information system.
The Ryuk ransomware start to weaponize Microsoft Office documents with the injection of malicious macro designed to run powershell commands. Those commands will download the Emotet banking trojan which will download another malicious payload as a TrickBot.

Vulnerability watch

CVE-2020-0601

The first security patch of the decade released by Microsoft for Windows 10 shows a vulnerability in the cryptography library handling elliptical curve cryptography. This vulnerability allows attackers to spoof a legit certification authority (CA) in order to signed malicious windows executable files as well as TLS certificates. This vulnerability affects all version of Windows 10 but can only be applied on CA using elliptical curve cryptography.

CVE-2020-0609

RDP Gateway are servers used as a RDP protocol router. Indeed, all RDP connections from the outside will target the RDP Gateway server which will redirect the connection to the correct computer. This allows reducing the attack area of the information system. However, the CVE-2020-0609, known as BlueGate, shows that RDP Gateway servers are affected by a memory corruption bug allowing remote execution code without authentication.
The code responsible for this vulnerability located in the section handling UDP request. Therefore, only UDP implementations of RDS Gateway are vulnerable.

CVE-2020-0674

The script engine of Internet Explorer allows an attacker to remotely execute commands on the underlying computer.
This vulnerability is due to a bug in the jscript.dll file used to parse JavaScript objects stored in memory.
This CVE echoes back to the RCE identified as CVE 2018-8653 which also affected Internet Explorer.

Weekly top

The top leak - Microsoft data breach: 250 million records exposed

A database used for "support case analytics" was available in the cloud to anyone. This database was used to store logs of conversation between Microsoft support agents and customers from all over the world.
Majority of data was anonymized but many of them still contain personal data. The data exposed include:
- Customer email addresses
- IP addresses
- Locations
- Descriptions of CSS claims and cases
- Microsoft support agents emails
- Case numbers, resolutions, and remarks
- Internal notes marked as “confidential”
Even if the data was publicly exposed for almost three weeks, there is no proof of malicious use. However those data could be used later by scammers in order to impersonate call center agents.

The top exploit - Malwares deployed on unpatched Citrix servers

The Revil ransomware gang is using CVE-2019-19781 to deploy ransomware on unpatched Citrix servers. These attacks began in January 11 when a proof of concept for the related CVE was published.
Many companies were not able to update their Citrix because of a lack of official patch for their Citrix kernel. However, the number of unpatched servers goes down from 80 000 in mid december to 11 000 in mid January.
Moreover, Citrix and FireEye have developed together a script that Citrix owners can run in order to verify if their appliances had been already hacked using the CVE.

The top attack - Hackers target European energy firm

The security firm Recorded Future has found a group of hackers (who have been using open source tools as the trojan Pupy) targeting an European energy firm network. The Recorded Future firm suspects the APT33 hacker team. This team is suspected to have links with the Iranian intelligence and is known to have used the same open-source tools than those used to attack the European energy firm.
In the last few years, energy firm have been more and more targeted by advanced persistent threat. Thus, these companies are advised to harden their security with simple mechanisms such as multiple factor authentication and to monitor connections coming from outside of their networks.

Software version watch

Software
Current version
Adobe Flash Player
Adobe Acrobat Reader DC
Java
Mozilla Firefox
Google Chrome
VirtualBox
CCleaner

Yoann DEQUEKER