Compromission des postes de travail grâce à LAPS et PXE

Magazine
Marque
MISC
Numéro
103
Mois de parution
mai 2019
Spécialité(s)


Résumé

Le poste de travail reste une des cibles favorites durant des opérations Red Team. Cependant, son niveau de sécurité s’est drastiquement amélioré avec le déploiement à grande échelle de solutions de sécurité comme Bitlocker ou encore LAPS. Mais ces solutions peuvent-elles aussi introduire de nouveaux chemins de compromission ? Retour sur une combinaison explosive entre un procédé de masterisation des postes de travail et LAPS.


Body

La masterisation automatisée des postes de travail est devenue un processus standard au sein des grandes entreprises. Par ailleurs, le durcissement des postes de travail a fait de nets progrès ces dernières années, notamment à l’aide de l’outil LAPS de Microsoft qui permet la gestion des mots de passe locaux.

Toutefois, nous allons étudier dans cet article comment la combinaison de deux bonnes idées sans lien apparent l’une avec l’autre peut mener à la compromission de l’ensemble des postes de travail d’un système d’information. Le principal avantage de la technique présentée dans la suite de l’article est qu’elle est réalisable en boîte noire, c’est-à-dire sans aucune connaissance préalable de la cible.

1. Masterisation automatisée de postes de travail

Le déploiement et la configuration de postes de travail en grand nombre sont une tâche fastidieuse qui peut bénéficier d’une relative automatisation grâce à des outils comme Microsoft Deployment Toolkit (MDT) ou System Center Configuration Manager (SCCM). Ces technologies permettent par exemple d’installer simplement un master logiciel sur un poste de travail à partir d’un accès réseau et d’automatiser son intégration dans l’annuaire Active Directory de l’entreprise.

1.1 Microsoft Deployment Toolkit (MDT)

Microsoft Deployment Toolkit [MDT] est un outil Microsoft qui permet de déployer une image Windows à partir d’une configuration prédéfinie. Cela se manifeste par la création de fichiers de déploiement (au format « .wim »). Afin de faciliter la tâche de la personne déployant un nouveau poste de travail, ces fichiers sont déployés sur le réseau afin de pouvoir permettre d’amorcer le démarrage du poste de travail sur le réseau avec PXE. Ils sont par défaut accessibles publiquement (sans authentification) à l’aide du protocole Trivial FTP (TFTP).

1.2 Boot PXE

Le boot PXE (Pre-boot eXecution Environment) permet donc à une station de travail de démarrer depuis le réseau. Il s’appuie sur une réponse spécifique du serveur DHCP définie dans la RFC 4578 [DHCP & PXE]. Le client PXE envoie une requête DHCP avec des options relatives à PXE et la réponse du serveur DHCP lui indique, en complément des informations d’adressage IP habituelles, l’emplacement du fichier de pre-boot sur le réseau, accessible en TFTP.

 

LAPS_PXE_TFTP_win

 

Fig. 1 : Téléchargement de l’image « wim ».

Une fois l’image chargée, le client procède à l’installation de son contenu sur le disque local ainsi que l’intégration dans l’Active Directory au travers d’un compte de service dédié à cet usage inclus dans l’image de pre-boot PXE. Une fois l’installation terminée, le poste de travail est fonctionnel et l’enrôlement dans l’Active Directory effectif.

1.3 Extraction des données sensibles

Ces fonctionnalités de boot sur PXE ont déjà été étudiées par de nombreuses personnes [NETSPI] et se révèlent utiles pour un attaquant, car elles permettent notamment d’extraire des informations sensibles. En effet, il est notamment possible pour un attaquant de démarrer sur PXE et de profiter de ce processus automatisé pour obtenir, sans informations préalables initialement, un poste de travail standard du domaine cible.

Tout particulièrement, au travers de ce fonctionnement, il est possible :

  • d’appuyer sur la touche [F8] pendant la phase de boot PXE initial qui a pour effet de lancer une invite de commande en tant qu’administrateur sur la machine en cours de déploiement. Il est ainsi possible d’accéder au contenu du système de fichiers qui sera déployé sur le poste de travail ;
  • d’appuyer sur les touches [Maj]+[F10] pendant la configuration de l’image installée et ainsi ajouter un compte administrateur local ou extraire la valeur des bases SAM et SYSTEM pour obtenir le hash du mot de passe par défaut des comptes système avant la fin du processus de masterisation ;
  • d’analyser la mémoire du poste de travail en cours de configuration PXE afin d’en extraire des informations sensibles ;
  • récupérer directement le fichier d’image de pré-boot (fichier wim) pour accéder à l’ensemble du paramétrage (mot de passe du compte de service utilisé pour l’intégration dans le domaine, fichiers contenant des mots de passe par défaut comme unattend.xml, etc.).

C’est cette dernière option qui va nous intéresser particulièrement pour la suite de cet article.

1.4 Recherche et extraction du fichier d’image

Afin de faciliter l’obtention de l’image de pré-boot à partir d’une requête DHCP, nous avons développé un script Powershell [POWERPXE] permettant d’automatiser les étapes suivantes (des étapes supplémentaires sont présentes dans le cas de SCCM [SCCM & PXE])  :

  • initialisation de l’échange DHCP en mode «discover » ;
  • extraction de l’emplacement du fichier de configuration du démarrage .bcd dans la réponse DHCP ;
  • téléchargement du fichier bcd via le protocole TFTP ;
  • extraction de l’emplacement de l’image .wim présente dans le fichier de configuration du démarrage ;
  • téléchargement de l’image .wim via le protocole TFTP ;
  • recherche des identifiants en clair, notamment sur les fichiers de configuration Bootstrap.ini et CustomSettings.ini.

Ce script nécessite d’être lancé en tant qu’administrateur afin de permettre la modification de la configuration de l’interface réseau ainsi que l’ouverture du fichier de configuration du démarrage.

Pour permettre au lecteur de réaliser une preuve de concept, le projet AutomatedLab [AUTOMATEDLAB] peut être utilisé, à l’aide de cette configuration hébergée sur GitHub [POWERPXE]. Ce lab est constitué de :

  • un contrôleur de domaine lab.fr ;
  • un serveur possédant le rôle MDT exposant ainsi le service DHCP, les répertoires réseaux ainsi qu’une interface TFTP ;
  • un serveur pour tester l’attaque, il est possible aussi de le faire depuis un simple accès réseau.

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 pour le lecteur : si le compte utilisé pour réaliser l’intégration au domaine est « Admins du domaine », c’est votre jour de chance !!!

1.5 Aller plus loin

La suite de cet article s’intéresse aux possibilités obtenues à partir du mot de passe du compte de service utilisé pour l’intégration au domaine. Toutefois, ce compte n’étant généralement pas identifié comme sensible, il est possible que son mot de passe figure à d’autres emplacements : partages SMB, SharePoint, etc.

De même, si le boot PXE est restreint à une zone réseau précise, le fichier .wim ou les fichiers de configurations associés Bootstrap.ini et CustomSettings.ini sont en général accessibles sur des partages de fichiers avec un contrôle d’accès peu restreint. Dans ce cas, l’accès à ce fichier permet de réaliser l’attaque décrite dans la suite de cet article.

2. Compromission de l'ensemble des postes de travail

2.1 Le privilège « Domain Join »

Le privilège « Domain Join », ou de joindre une machine dans le domaine [DOMAIN-JOIN], correspond au privilège Active Directory « Ajouter une machine dans le domaine ». Dans la configuration par défaut d’un domaine, un utilisateur standard peut joindre 10 machines dans le domaine. Cependant, dans la majorité des entreprises, ce privilège est restreint via une GPO (Group Policy Object) présente dans Computer Configuration > Windows settings > Security Settings > User Rights Assignment > Add Workstations to the Domain.

Par défaut, le groupe « Opérateur de comptes » possède les privilèges nécessaires pour joindre une machine au domaine. Il n’est cependant pas recommandé de l’utiliser, car les privilèges de ce groupe sont trop élevés : ils permettent par exemple d’ouvrir une session interactive sur les contrôleurs de domaine. Pour cela, en général un compte de service est créé : il s’agit d’un compte basique du domaine n’ayant comme seuls privilèges spécifiques que de pouvoir intégrer un poste de travail au domaine.

Lors de l’intégration d’une machine dans le domaine, un objet de la classe computer est créé dans l’Active Directory. Le compte utilisateur utilisé pour créer cet objet, i.e joindre une machine, est défini comme propriétaire de cet objet.

2.2 Principe de fonctionnement de LAPS

Comme les machines sont déployées depuis un modèle unique, le mot de passe du compte local « Administrateur » (builtin, aka SID 500) est identique sur l’ensemble des machines. Cette configuration est considérée comme une vulnérabilité, car elle permet notamment en cas de compromission d’une seule machine de rebondir sur l’ensemble des autres machines. La robustesse du mot de passe du compte local n’est même pas prise en considération, car il sera possible de rebondir via une attaque Pass The Hash (PTH).

Microsoft permet ainsi via son outil « Local Administrator Password Solution », LAPS, de modifier automatiquement et gérer dans le temps les mots de passe du compte local builtin des machines présentes dans le domaine.

Lors de l’installation de la solution LAPS, deux attributs de sécurité sont ajoutés dans la classe machine :

  • ms-mcs-AdmPwd qui stocke en clair le mot de passe du compte administrateur. Une délégation de privilèges est nécessaire pour accéder en lecture à cet attribut (le groupe « Admins du domaine » possède des privilèges suffisants par défaut) ;
  • ms-mcs-AdmPwdExpirationTime qui définit la date de la prochaine rotation du mot de passe, tous les 30 jours.

La commande Find-AdmPwdExtendedRights du module Powershell de LAPS (le module AdmPwd.PS) permet d’identifier les groupes ou les utilisateurs pouvant accéder au mot de passe LAPS. En effet, ce module liste les utilisateurs possédant un accès en lecture sur l’attribut ms-mcs-AdmPwd :

PS > Import-Module AdmPwd.PS

PS > Find-AdmPwdExtendedRights | fl

ObjectDN                      : OU=COMPUTER,DC=lab,DC=fr

ExtendedRightHolders          : {LAB\LAPS_recover, LAB\Domain Admins}

console

2.3 Compromission des postes via LAPS

Le propriétaire d’un objet ainsi que les privilèges accordés aux utilisateurs (ou à un autre objet) sur cet objet sont stockés dans un descripteur de sécurité (ou SecurityDescriptor). Les droits d’accès (i.e. les privilèges) se présentent sous la forme d’une DACL (Discretionnary Access Control List) composée d’ACE (Access Control Entries), où chaque ACE décrit une ou plusieurs permissions accordées ou refusées à un utilisateur.

Le script suivant permet d’extraire les privilèges accordés par défaut (via les ACE) au propriétaire d’un objet computer :

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

## Création 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}

Le résultat de la commande contient notamment l’ACE suivante :

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

console

Le propriétaire d’un objet, héritant de la classe computer, possède donc par défaut le privilège ExtendedRight. Or le privilège ExtendedRight ou plutôt All extended rights dans l’interface graphique, permet d’accéder au mot de passe LAPS.

En effet, l’accès au mot de passe peut par exemple se faire avec 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

console

Le compte utilisé pour joindre une machine dans le domaine peut ainsi la compromettre si LAPS est utilisé. De plus, si le même compte est utilisé pour réaliser l’ensemble des intégrations, comme c’est fréquemment le cas lorsque les intégrations au domaine sont faites automatiquement à l’aide d’une masterisation avec MDT ou SCCM, il est possible de compromettre l’ensemble des postes de travail via ce compte.

Les propriétaires des objets computer peuvent être identifiés avec les commandes suivantes :

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

}

3. Protections

3.1 Protéger la séquence de boot PXE

Afin de limiter les risques pour un attaquant ayant accès au réseau d’entreprise de démarrer en PXE pour réaliser les attaques du premier chapitre, il est fortement recommandé que la capacité à démarrer en PXE soit limitée à des zones réseau bien spécifiques, telles que des salles du support informatique.

D’autre part, il est également recommandé que le démarrage en PXE nécessite un mot de passe avant de commencer l’installation. Cela peut notamment être configuré en cochant la case Require a Password when computers use PXE dans la configuration SCCM.

De manière plus générale, les recommandations Microsoft relatives au déploiement de PXE [SECURISATION PXE] sont un bon point de départ pour sécuriser toute installation PXE.

3.2 Retirer les privilèges ExtendedRights, une fausse bonne idée

Microsoft propose de réduire les privilèges du créateur propriétaire de l’objet afin qu’il ne puisse plus accéder aux attributs de sécurité relatifs à LAPS [LAPS-PERMISSION]. Cette première solution passe par le changement du defaultSecurityDescriptor de classe computer afin de retirer le privilège ExtendedRights à l’utilisateur « CREATEUR PROPRIETAIRE » (ou « Owner »). La valeur par défaut, au format SSDL, est :

(A;;RPCRLCLORCSDDT;;;CO)

Elle devient :

(A;;RPLCLORCSDDT;;;CO)

Ainsi, les propriétaires des objets de la classe computer perdent leurs attributs étendus sur chacun des objets de la classe et ne peuvent plus accéder aux attributs LAPS : le tour est joué !

Malheureusement non, ce changement de configuration n’est malheureusement pas suffisant… En effet, le propriétaire d’un objet [OWNER] possède implicitement le privilège Write-Dacl sur cet objet. Il y a de plus une subtilité : le droit Write-Dacl du propriétaire d’un objet n’est pas spécifié dans les ACL de l’objet, mais est pourtant bien présent.

Comme son nom l’indique, Write-Dacl permet d’écrire une ACE dans la DACL. Ainsi, il est possible de s’auto-accorder le contrôle total GenericAll ou de se rajouter le privilège ExtendedRights sur un objet.

Ce chemin peut notamment être visualisé avec BloodHound depuis la version 2.0 (août 2018) (Figure 2).

 

LAPS_PXE_BloodHound

 

Fig. 2 : Visualisation des chemins de compromission sous BloodHound.

Ce chemin peut être exploité avec PowerView avec la commande suivante qui rajoute le privilège GénéricAll sur la machine COMPUTER (commandes à lancer en tant que l’utilisateur propriétaire de l’objet) :

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

console

3.3 Un durcissement « en profondeur »

Le propriétaire d’un objet computer peut jusqu’à maintenant toujours lire le mot de passe LAPS. Une première solution « maison » pour remédier à cette vulnérabilité est de modifier régulièrement les propriétaires des objets.

Par exemple, il est possible de définir le groupe « Admins du domaine » :

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>", "Admins du domaine")

  $acl.SetOwner($objUser)

  Set-Acl -Path $comppath -AclObject $acl

}

Microsoft propose aussi une seconde solution en modifiant manuellement les privilèges du propriétaire d’un objet [OWNER-RIGHTS] au niveau des OU :

  • ouvrir l’onglet sécurité présent dans les propriétés d’une l’OU ;
  • cliquer sur Ajouter sous le Nom de groupe ou d'utilisateur ;
  • saisir « CREATEUR PROPRIETAIRE », ou bien « CREATOR OWNER », dans la zone de texte ;
  • définir explicitement les permissions accordées au propriétaire d’un objet.

La définition complète des privilèges de l’utilisateur « CREATEUR PROPRIETAIRE » sur l’OU, et donc la création d’ACE explicite, va prendre le dessus sur les privilèges implicites.

Cette technique doit cependant être testée sur un environnement de tests avant d’être déployée en production.

Conclusion

Pris individuellement, le démarrage PXE et LAPS est une solution apportant une forte valeur ajoutée au sein d’un système d’information. Toutefois, nous avons pu constater que la combinaison de deux solutions, même correctement configurées, peut mener à la compromission d’une grande partie du système d’information.

En pratique, il convient de s’assurer que le fonctionnement simultané de différentes solutions n’ajoute pas de nouveau chemin de compromission dans son environnement Windows. Aujourd’hui, l’article s’est concentré sur la masterisation et LAPS, mais d’autres solutions possédant des privilèges sur un nombre élevé de machines (WSUS pour le déploiement des mises à jour, la console de l’antivirus ou encore l’agent de sauvegarde) peuvent permettre de rebondir dans le SI.

Remerciements

Un immense remerciement à l’ensemble du pool audit Wavestone et plus particulièrement à Arnaud SOULLIÉ et Nicolas DAUBRESSE pour la relecture et leurs conseils.

Références

[MDT] Documentation Microsoft, « Microsoft Deployment Toolkit » : https://docs.microsoft.com/en-us/sccm/mdt/

[DCHP & PXE] Dominik Heinz, « Client Management blog », page supprimée sur TechNet : http://web.archive.org/web/20190219161848/https://blogs.technet.microsoft.com/dominikheinz/2011/03/18/dhcp-pxe-basics/

[SCCM & PXE] Dominik Heinz, « SCCM PXE Network Boot Process » : https://www.agileit.com/news/sccm-pxe-network-boot-process-for-windows/

[NETSPI] Thomas Elling, « Attacks Against Windows PXE Boot Images » : https://blog.netspi.com/attacks-against-windows-pxe-boot-images/

[POWERPXE] Rémi Escourrou, Détection et extraction des informations sensibles d’un serveur PXE : https://github.com/wavestone-cdt/powerpxe

[AUTOMATEDLAB] Raimund Andrée et Jan-Hendrik Peters, AutomatedLab project : https://github.com/AutomatedLab/AutomatedLab

[DOMAIN-JOIN] Rafel Sosnowski, « Who can add workstation to the domaine » : https://blogs.technet.microsoft.com/dubaisec/2016/02/01/who-can-add-workstation-to-the-domain/

[SECURISATION PXE] Microsoft documentation, « Security and privary for operating system deployment » : https://docs.microsoft.com/fr-fr/sccm/osd/plan-design/security-and-privacy-for-operating-system-deployment

[LAPS-PERMISSION] Jiri Formacek, « LAPS and permission to join computer to domain » : https://blogs.msdn.microsoft.com/laps/2015/07/17/laps-and-permission-to-join-computer-to-domain/

[OWNER] Microsoft Documentation, « Owner of a New Object » : https://docs.microsoft.com/en-us/windows/desktop/secauthz/owner-of-a-new-object

[OWNER-RIGHTS] Microsoft documentation, « AD DS : Owner Rights » : https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd125370(v=ws.10)

 



Article rédigé par

Les derniers articles Premiums

Les derniers articles Premium

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Bash des temps modernes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les scripts Shell, et Bash spécifiquement, demeurent un standard, de facto, de notre industrie. Ils forment un composant primordial de toute distribution Linux, mais c’est aussi un outil de prédilection pour implémenter de nombreuses tâches d’automatisation, en particulier dans le « Cloud », par eux-mêmes ou conjointement à des solutions telles que Ansible. Pour toutes ces raisons et bien d’autres encore, savoir les concevoir de manière robuste et idempotente est crucial.

Présentation de Kafka Connect

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Un cluster Apache Kafka est déjà, à lui seul, une puissante infrastructure pour faire de l’event streaming… Et si nous pouvions, d’un coup de baguette magique, lui permettre de consommer des informations issues de systèmes de données plus traditionnels, tels que les bases de données ? C’est là qu’intervient Kafka Connect, un autre composant de l’écosystème du projet.

Le combo gagnant de la virtualisation : QEMU et KVM

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

C’est un fait : la virtualisation est partout ! Que ce soit pour la flexibilité des systèmes ou bien leur sécurité, l’adoption de la virtualisation augmente dans toutes les organisations depuis des années. Dans cet article, nous allons nous focaliser sur deux technologies : QEMU et KVM. En combinant les deux, il est possible de créer des environnements de virtualisation très robustes.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 67 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous