Attaque sur le protocole Kerberos

Magazine
Marque
MISC
Numéro
54
Mois de parution
mars 2011
Spécialité(s)


Résumé

Kerberos, dans la mythologie grecque et romaine, est le chien à trois têtes protégeant l'accès à la porte des enfers. En informatique, le protocole Kerberos est utilisé afin d'authentifier un utilisateur. L'intérêt de ce protocole est de pouvoir authentifier une personne via un mécanisme de tickets.Cet article a pour objectif de vous présenter les différentes faiblesses sur ce protocole, et plus particulièrement, l'attaque Pass the Ticket. Par ailleurs, nous vous présenterons une démonstration d'attaque sur un environnement Windows, ainsi que quelques pistes de protection.


Body

1. Le protocole Kerberos

Kerberos est un protocole d'authentification développé par le MIT (Massachusetts Institue of Technology) [1]. Il a été conçu afin de fournir une authentification unifiée pour les applications de type client/serveur sur des réseaux qualifiés de non sûrs à l'aide de chiffrement symétrique. L'authentification repose sur une tierce partie de confiance nommée Key Distribution Center (KDC) pour l'attribution de tickets permettant l'accès aux différents services du réseau.

Les implémentations connues de Kerberos sont les suivantes :

- Kerberos MIT : implémentation originale développée par le MIT sous la licence BSD ;

- Microsoft Kerberos V5 : implémentation fournie par Microsoft depuis les versions Windows 2000 ;

- Heimdal : une implémentation alternative du MIT développée en Suède.

Afin de bien comprendre le fonctionnement du protocole Kerberos, il est important de rappeler les différentes entités impliquées dans le processus d'authentification :

- le client (C) souhaitant obtenir un accès à un service ;

- le service d'authentification (AS), qui authentifie le client vis-à-vis du service d'émission de tickets ;

- le service d'émission de tickets (TGS), qui authentifie le client vis-à-vis du service final, à condition que l'authentification avec le serveur d'authentification ait réussi ;

- le serveur (V), qui héberge le service auquel souhaite accéder le client.

Le fonctionnement du protocole Kerberos peut être comparé au processus mis en place dans les salles de cinéma. Tout d'abord, le client (C) achète son ticket d'entrée auprès de la caisse (AS). Dans cette situation, il obtient son ticket en échange d'un moyen de paiement. Ensuite, le client doit présenter son ticket au contrôle (TGS) afin de pouvoir accéder au cinéma. Enfin, devant la salle (V), un dernier contrôle s'assure que le client possède un ticket valable pour accéder à cette salle. Il est à noter que la durée de vie du ticket est limitée à une seule séance.

Il est important de souligner que l'AS et le TGS sont des fonctions du KDC. Le fonctionnement du protocole est décrit par le schéma suivant :

 

KerberosProtocol

 

Détaillons maintenant les différentes phases [2] du processus dans le cas d'une authentification sur un poste de travail ou un serveur.

1.1 Authentication Server Request (AS_REQ)

Le processus débute lorsque l'utilisateur tape son identifiant et son mot de passe. Par la suite, un message de demande d'authentification (AS_REQ) est envoyé au service d'authentification (AS).

Ce message, transmis en clair, contient :

- l'identité de l'utilisateur (dupont@DOMAINE.FR) ;

- le nom du service auquel il souhaite accéder ;

- la durée de vie du ticket ainsi que la liste des machines où le ticket peut être utilisé.

1.2 Authentication Server Response (AS_REP)

Le service d'authentification (AS) s'assure que le nom de l'utilisateur, ainsi que le service auquel il souhaite accéder, existent. Si tel est le cas, une réponse (AS_REP) contenant les éléments suivants est envoyée :

- Un ticket nommé TGT (Ticket-Granting Ticket). Ce ticket, chiffré avec la clé secrète du TGS, contient les informations sur les limites de validité du ticket (nom d'utilisateur, nom de domaine, durée de vie, …), ainsi qu'une clé de session que nous appellerons SKtgs.

- La clé de session SKtgs chiffrée avec la clé secrète de l'utilisateur. Dans le cas d'une authentification par mot de passe, la clé secrète de l'utilisateur est un condensat de son mot de passe.

En réalité, afin d'éviter la possibilité d'attaque par bruteforce hors-ligne sur la clé secrète de l'utilisateur, la plupart des implémentations de Kerberos implémentent un mécanisme appelé pré-authentification. Il implique l'envoi d'un timestamp chiffré avec la clé de l'utilisateur. L'AS peut alors vérifier la validité de ce timestamp avant l'émission d'un TGT.

Au terme de cet échange AS_REQ/AS_REP, l'utilisateur et l'AS ont donc échangé :

- Une clé de session SKtgs connue uniquement par l'AS et l'utilisateur (car chiffrée avec la clé secrète de l'utilisateur). Cette clé de session servira pour les échanges ultérieurs avec le TGS.

- Un TGT contenant les limites de validité du ticket (nom d'utilisateur, nom de domaine, durée de vie, ...).Ce TGT est chiffré avec la clé secrète du TGS et n'est donc pas modifiable par l'utilisateur.

1.3 Ticket Granting Server Request (TGS_REQ)

Dès lors que le client reçoit le TGT, une demande (TGS_REQ) est adressée au service d'émission de tickets (TGS) pour la connexion à la station de travail.

Cette demande contient :

- Le nom d'utilisateur et un timestamp de la demande chiffrée avec la clé de session SKtgs. Cet élément est appelé authentificateur(authenticator). Il est à noter que seul un utilisateur légitime est capable de générer un tel élément.

- Le TGT précédemment obtenu.

- Le nom du service auquel l'utilisateur souhaite se connecter, ainsi que la durée de vie du ticket.

1.4 Ticket Granting Server Response (TGS_REP)

À la réception de la demande (TGS_REQ) du client, le TGS effectue les actions suivantes :

- Déchiffre le TGT avec sa clé et vérifie sa validité.

- Vérifie la validité de l'authentificateur en utilisant la clé de session SKtgs présente dans le TGT.

Si le TGS_REQ est valide, il émet alors une réponse TGS_REP contenant :

- Une clé de session (SKservice) entre le service et l'utilisateur. Cette clé est envoyée chiffrée par SKtgs.

- Un ticket de service TS chiffré avec la clé du service et contenant le nom de l'utilisateur, le nom du service, la liste des adresse IP autorisées à accéder au service, un timestamp, une durée de validité, ainsi que la clé de session SKservice.

Quand l'utilisateur reçoit cette réponse, il peut donc déchiffrer la clé SKservice, grâce à la clé SKtgs obtenue lors de l'échange AS_REQ/AS_REP.

1.5 Application Request (AP_REQ) (optionnel)

Dans le cas d'utilisation d'un service sur un équipement tiers, une autre requête (AP_REQ) est envoyée au serveur fournissant le service.

Cette requête contient :

- un nouvel authentificateur, chiffré cette fois avec SKservice ;

- le ticket de service TS.

Le fournisseur de service commence par extraire la clé SKservice présente dans le ticket de service TS. À l'aide de cette clé, il extrait le nom d'utilisateur présent dans l'authentificateur et s'assure qu'il est identique à celui contenu dans le ticket de service.

1.6 Application Response (AP_REP) (optionnel)

Ce dernier échange, qui est optionnel, est envoyé uniquement afin d'assurer une authentification mutuelle entre le client et le serveur fournissant le service (V).

Cette requête contient un timestamp généré par le serveur et est chiffrée avec la clé SKservice.

2. Historique des attaques sur Kerberos

Depuis la publication du protocole Kerberos en 1989, différentes faiblesses ont été identifiées. Dans cette section, nous vous présentons deux attaques connues : KDC Spoofing et Replay attack. Les faiblesses présentées dans ces deux attaques ont été utilisées pour réaliser l'attaque Pass the ticket.

2.1 KDC Spoofing

Comme son nom l'indique, cette attaque se base sur la possibilité d'usurper les réponses du KDC. Néanmoins, comme évoqué précédemment, le protocole Kerberos est censé être protégé contre ce type d'attaques. En effet, Kerberos a été conçu pour fonctionner sur des réseaux non sûrs, ainsi que d'assurer une authentification mutuelle.

Cependant, certaines applications n'utilisent pas le protocole Kerberos dans son ensemble. Par exemple, sur certains systèmes Linux/Unix, les premières versions du module PAM utilisaient un « raccourci ». Le client n'envoyait que les requêtes destinées à l'AS. Ainsi, lorsque l'utilisateur fournissait son mot de passe, une requête AS_REQ était envoyée au KDC, et à la réception de la réponse AS_REP, le module PAM tentait de déchiffrer une partie du message avec la clé dérivée du mot de passe de l'utilisateur.

Concrètement, un utilisateur possédant un accès physique à la machine et étant en mesure de contrôler les requêtes du client peut obtenir un accès à l'équipement avec le compte d'un utilisateur précis et un mot de passe quelconque. Pour cela, il suffit à l'attaquant d'effectuer une authentification avec un mot de passe fixé et de bloquer l'envoi de la requête AS_REQ au KDC. En effet, l'attaquant va répondre lui-même à cette requête en forgeant une requête AS_REQ avec le mot de passe précédemment utilisé. Un code d'exploitation de l'attaque a été fourni par Dug Song [7].

Afin de se protéger de cette attaque, il est nécessaire d'effectuer l'étape suivante du protocole, c'est-à-dire réaliser une demande de ticket au TGS.

2.2 Replay Attack

Comme évoqué précédemment, le serveur s'assure que le client peut accéder au service en validant uniquement la dernière requête envoyée : Application Server Request (AP_REQ).

Cette attaque par rejeu nécessite que l'attaquant mette en place un Man-In-The-Middle entre le client et le serveur. Par la suite, il y a deux possibilités :

- Soit l'attaquant effectue une écoute du réseau et renvoie la requête AP_REQ émise par le client afin d'obtenir un accès au service.

- Soit l'attaquant empêche le client d'envoyer la requête AP_REQ au serveur et l'utilise pour obtenir l'accès au service à la place du client.

Plusieurs contre-mesures ont été proposées afin de réduire l'impact de cette vulnérabilité :

- Timestamp : La durée d'utilisation de l'AP_REQ est limitée à un certain temps (en général 5 minutes).

- Cache : Le serveur (V) stocke en mémoire les requêtes (ou plus précisément les authentificateurs) effectuées par le client pendant la durée d'utilisation autorisée. Ainsi, toutes les requêtes en double sont rejetées.

- Adresse IP : Le ticket fourni par le KDC peut contenir la liste des adresses IP autorisées à utiliser ce ticket. Cette information est conservée dans la requête AP_REQ. Ainsi, le serveur est en mesure de vérifier si l'expéditeur de la requête a le droit d'utiliser ce ticket.

2.3 Kerberos et le chiffrement

Une autre catégorie d'attaque consiste à exploiter les faiblesses des algorithmes de chiffrement utilisés par Kerberos.

Historiquement, Kerberos utilisait uniquement l'algorithme DES (dont la faiblesse n'est plus à démontrer [12]). Le protocole a depuis évolué pour intégrer un mécanisme de négociation de l'algorithme de chiffrement entre le client et le KDC.

Malheureusement, cette négociation n'est pas protégée. Il est donc possible pour un attaquant ayant accès aux flux réseau entre le client et le KDC de modifier ces échanges afin de forcer l'utilisation de l'algorithme de chiffrement le plus faible [11].

La seule contre-mesure est alors de limiter les algorithmes acceptés côté client et serveur. Sous environnement Windows, les algorithmes faibles sont désactivés à partir de Windows 7 et Windows 2008 R2 [13].

3. L'attaque Pass the Ticket

La présentation originale de cette attaque date de 2008 par Emmanuel Bouillon à la conférence PacSec [3]. Une présentation à la BlackHat, ainsi qu'a la conférence Hack.lu, a été effectuée en 2009 et 2010 [4] [10].

Cette attaque permet de s'authentifier localement sur le poste client, et ce même si l'authentification Kerberos est complètement réalisée (AS_REQ/AS_REP + TGS_REQ/TGS_REP). Du côté attaquant, cela nécessite le contrôle des flux réseau échangés entre le client et le KDC, ainsi qu'un accès physique sur l'équipement.

L'attaque se déroule en deux phases :

1. Écoute d'une authentification Kerberos légitime

Durant cette phase, l'attaquant va enregistrer les échanges Kerberos effectués lors d'une connexion légitime de l'utilisateur victime. L'objectif est d'obtenir le ticket de service TS.

2. Rejeu d'un ticket valide

L'attaquant va alors tenter de se connecter physiquement sur le poste client, en utilisant un nom d'utilisateur valide, ainsi qu'un mot de passe quelconque (par exemple « password ») de la façon suivante :

A) Le poste client va alors générer un AS_REQ qui sera intercepté par l'attaquant.

B) L'attaquant répondra avec un AS_REP contenant :

- Un ticket TGT forgé. Ce ticket sera chiffré avec une clé choisie par l'attaquant en lieu et place de la clé secrète du TGS.

- Une clé de session SKtgs* choisie par l'attaquant et chiffrée avec une clé dérivée du mot de passe « password ».

C) Le client génère alors une requête TGS_REQ. Celui-ci contient alors le TGT forgé précédemment reçu, ainsi qu'un authentificateur chiffré avec la clé de session SKtgs et choisie par l'attaquant. Ce TGS_REQ est également intercepté par l'attaquant.

D) L'attaquant envoie alors un TGS_REP au poste client, contenant :

- Le ticket de service TS intercepté lors de l'étape 1. Ce TS contient la clé de session SKservice utilisée lors de l'échange original.

- L'attaquant envoie également une clé de session forgée (appelons la SKservice*), chiffrée avec la clé de session SKtgs*.

Les vérifications effectuées du côté du poste client pour l'authentification de l'utilisateur sont :

- Vérification que la clé de service légitime du poste client est capable de déchiffrer le ticket TS.

- Vérification que la clé de session SKtgs* est capable de déchiffrer SKservice*.

- Vérifie les limites de validité contenues dans le ticket de service TS.

Dans notre attaque, toutes ces conditions sont remplies.

Pour récapituler, cette attaque permet de se connecter localement à un ordinateur membre d'un domaine Active Directory si :

- L'attaquant est capable d'écouter et de modifier les flux réseau entre l'ordinateur cible et le contrôleur de domaine.

- Un utilisateur légitime se connecte sur le poste.

- L'attaquant dispose par la suite d'un accès au poste client cible (physiquement ou par un accès type VNC/terminal server).

L'attaquant disposera alors des privilèges de l'utilisateur dont l'authentification Kerberos a été capturée sur l'ordinateur cible.

4. Démonstration

Passons maintenant à la phase pratique. Cette démonstration se base sur les travaux effectués par Secgroup [5]. Notre environnement de test se compose d'un contrôleur de domaine Active Directory 2003 et d'un poste victime, membre du domaine, sous Windows XP.

Les éléments dont nous aurons besoin pour réaliser cette attaque sont :

- une machine Unix ;

- la bibliothèque de manipulation de paquets Scapy ;

- le code d'exploitation [6] et la bibliothèque cryptographique [7] Kerberos développés par Secgroup.

Si la version de Scapy installée sur votre système n'a pas été mise à jour récemment, il vous sera nécessaire d'appliquer le patch suivant :

% cd /usr/lib/python2.5/site-packages/scapy

% patch -p0 < ~/kdcreplay-10272010/scapy-asnfields.patch

Comme nous l'avons vu précédemment, cette attaque nécessite comme pré-requis le contrôle des flux réseau transitant entre le poste client et le contrôleur de domaine.

Nous commençons donc par nous mettre en situation en déclenchant une attaque de type ARP Poisoning et en prenant soin au préalable d'activer le routage, ainsi que de bloquer l'envoi des messages de type ICMP Redirect avec une règle iptables.

% echo 1 > /proc/sys/net/ipv4/ip_forward

% iptables -A OUTPUT -p icmp --icmp-type redirect -j DROP

% ettercap -T -i eth0 -o -M arp /$IP_VICTIME/ /$IP_KDC/

[...]

ARP poisoning victims: GROUP 1 : 192.168.0.210 GROUP 2 : 192.168.0.211 Activated the mitm attack only... (press 'q' to exit)

Nous lançons ensuite l'outil kdcreplay en fournissant les options suivantes :

- d : sauvegarde les requêtes TGS_REP dans le fichier spécifié ;

- k : l'adresse IP du KDC ;

- t : l'adresse IP du poste victime ;

- e : spécifie le chiffrement à utiliser (3des, rc4win ou aes) ;

- r : le nom du domaine Active Directory ;

- u : le nom d'utilisateur de notre victime ;

- p : le mot de passe à utiliser.

Dans notre exemple, l'utilisateur se nomme « victime » et le nom du domaine est « SECURITE ».

% ./kdcreplay.py -d dumpticket.pcap -k $IP_KDC -t $IP_VICTIME -e rc4win -r SECURITE -u victime -p password

Pour un poste client victime sous Windows XP supportant seulement l'algorithme RC4, il vous faudra modifier la variable rc4key dans le script kdcreplay.py avec le condensat NTLM du mot de passe désiré.

La commande suivante permet de générer un condensat NTLM :

echo -n "password" | iconv -f ASCII -t UTF-16LE | openssl md4

Sur Windows Vista/Seven, aucune modification du script n'est requise. En revanche, les échanges Kerberos sont effectués par défaut via TCP, ce qui n'est pas supporté par l'outil actuellement (même si le principe de l'attaque reste valide).

Pour forcer l'utilisation de UDP sur ces systèmes, il vous faudra modifier la clé registre suivante à une valeur élevée (1500) [6] [9] :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\ Kerberos\Parameters\MaxPacketSize

L'outil se met alors en mode écoute du trafic pour extraire les tickets envoyés lors d'une authentification légitime :

[...]

grepped ticket for krbtgt/SECURITE.LAN

grepped ticket for host/demo3.securite.lan

grepped ticket for LDAP/serveur-demo.securite.lan

grepped ticket for ldap/serveur-demo.securite.lan/securite.lan

grepped ticket for cifs/serveur-demo.securite.lan

En appuyant sur Ctrl-C, nous passons l'outil en mode rejeu :

^Csniffing terminated

sniffed 5 tickets, starting replay

Nous ajoutons alors une règle iptables pour bloquer la transmission des paquets vers le contrôleur de domaine afin d'éviter toute interférence lors de notre attaque :

iptables -A FORWARD -s $IP_KDC -p udp --dport 88 -j DROP ; iptables -A FORWARD -d $IP_KDC -p udp --dport 88 -j DROP

Nous pouvons alors nous connecter sur le poste client avec le mot de passe « password ». Le poste client Windows va alors générer la séquence d'authentification AS_REQ/ TGS_REQ. Ces deux requêtes vont alors être interceptées par notre outil en Man-In-The-Middle :

AS_REQ seen

cname setted to victime

Sent 1 packets.

TGS_REQ seen for krbtgt/SECURITE.LAN

tgs_rep ready

.

Sent 1 packets.

TGS_REQ seen for host/demo3.securite.lan

tgs_rep ready

.

Sent 1 packets.

Nous obtenons alors un accès sur l'équipement.

5. Moyens de protection

Comme évoqué précédemment, seule l'implémentation du protocole Kerberos par Microsoft est vulnérable à l'attaque Pass the Ticket. À l'heure actuelle, aucun correctif n'a été fourni par Microsoft.

En revanche, l'implémentation Kerberos fournie par le MIT n'est pas vulnérable en raison du respect des spécifications du protocole. En effet, l'implémentation de Microsoft n'effectue que les deux premiers échanges pour authentifier un utilisateur (AS_REQ/AS_REP et TGS_REQ/TGS_REP), tandis que celle du MIT ajoute l'envoi de la requête AP_REQ. Pour rappel, cette requête contient un authentificateur chiffré avec la clé SKservice et le ticket de service (TS). Le service (V), qui est simulé en interne dans le cas d'une authentification sur le poste local, va s'assurer que le nom d'utilisateur présent dans l'authentificateur et le TS sont identiques. Or, lors de l'attaque, le TS fourni par l'attaquant provient d'une précédente session, ce qui implique que le service ne sera pas en mesure de déchiffrer l'authentificateur chiffré par la clé SKservice* forgée par l'attaquant et, par conséquent, refusera l'authentification de l'utilisateur.

Pour les administrateurs ne souhaitant pas attendre la sortie du correctif de Microsoft, il leur est nécessaire d'empêcher un attaquant d'obtenir un accès physique aux postes de travail utilisateur (badge, restriction des interfaces d'administration, ...) et/ou la possibilité de manipuler le trafic réseau (protection ARP poisoning, 802.1X, etc.). Bien entendu, la mise en place de ces solutions est beaucoup plus complexe.

Conclusion

Le protocole Kerberos assure une authentification unifiée sur des réseaux non sûrs et jouit d'une bonne réputation de par les travaux de durcissement réalisés depuis 20 ans par la communauté.

Toutefois, l'implémentation de Microsoft (disponible dans toutes les versions de Windows depuis Windows 2000) souffre actuellement d'un défaut non corrigé, qui permet à un attaquant contrôlant le trafic réseau de pouvoir ouvrir une session localement sous l'identité de n'importe quel utilisateur et sans connaître son mot de passe.

Cette faille ne permet toutefois pas de s'authentifier à distance sur d'autres ressources réseau, ni de déchiffrer les secrets locaux protégés par le mot de passe de l'utilisateur (ex. DPAPI) – c'est probablement pourquoi Microsoft a décidé de repousser la correction à un futur Service Pack.

L'exploitation des faiblesses présentes sur ce protocole n'est pas encore monnaie courante, la plupart des outils d'attaque s'étant focalisés sur les faiblesses d'autres protocoles d'authentification Windows (LM, NTLM). Nous espérons que cet article vous aura donné envie de vous y intéresser.

REMERCIEMENTS

Nous tenons à remercier Nicolas Ruff pour ses relectures, ainsi que l'opportunité offerte d'écrire dans MISC.

Enfin, nous tenons à remercier Nicolas Grenèche pour son aide et ses conseils avisés.

RÉFÉRENCES

[1] http://web.mit.edu/Kerberos/

[2] http://www.zeroshell.net/eng/kerberos/

Découverte originale de l'attaque :

[3] E. Bouillon : Gaining access through Kerberos, PacSec 2008

[4]http://www.blackhat.com/presentations/bh-europe-09/Bouillon/BlackHat-Europe-09-Bouillon-Taming-the-Beast-Kerberous-whitepaper.pdf

Implémentation originale de l'attaque :

[5] http://secgroup.ext.dsi.unive.it/wp-content/uploads/2010/08/m0t-krb5-08-2010.pdf

[6] http://secgroup.ext.dsi.unive.it/wp-content/uploads/2010/08/kdcreplay-08062010.tar.gz

[7] http://secgroup.ext.dsi.unive.it/wp-content/uploads/2010/08/Krb5Crypto-0.4.tar.gz

[8] http://www.monkey.org/~dugsong/kdcspoof.tar.gz

[9] KB244474 : http://support.microsoft.com/kb/244474/en-us

[10] http://archive.hack.lu/2010/Bouillon-Stealing-credentials-for-impersonation.pdf

[11] https://media.blackhat.com/bh-us-10/whitepapers/Stender_Engel_Hill/BlackHat-USA-2010-Stender-Engel-Hill-Attacking-Kerberos-Deployments-wp.pdf

[12] http://w2.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/HTML/19980716_eff_des_faq.html

[13] http://technet.microsoft.com/fr-fr/library/dd560670%28WS.10%29.aspx

 



Article rédigé par

Par le(s) même(s) auteur(s)

Présentation de l'OWASP Mobile Security Testing Guide

Magazine
Marque
MISC
Numéro
106
Mois de parution
novembre 2019
Spécialité(s)
Résumé

Paru en juin 2018, l'OWASP Mobile Security Testing Guide (MSTG) est devenu une référence pour appréhender et auditer la sécurité des applications mobiles (Android et iOS). Dans cet article, nous allons passer en revue le guide et présenter quelques exemples d'utilisation.

Quels outils pour l'audit d'intrusions d'applications web ?

Magazine
Marque
GNU/Linux Magazine
HS n°
Numéro
97
Mois de parution
juillet 2018
Spécialité(s)
Résumé

L'évaluation de la sécurité d'une application web n'est pas chose aisée. Les technologies et frameworks se multiplient et la pression sur la mise en production des applications augmente. Dans cet environnement actuel, il devient de plus en plus difficile de s'assurer qu'aucun défaut de sécurité ne sera présent lors de la mise en production. Cet article a pour but de présenter les différents outils (libres et gratuits), ainsi que les techniques pouvant être utilisées pour identifier les faiblesses de sécurité que l'on rencontre fréquemment en audit.

Cinq façons de devenir administrateur de domaine avec Metasploit

Magazine
Marque
MISC
HS n°
Numéro
14
Mois de parution
octobre 2016
Spécialité(s)
Résumé

En test d'intrusion interne, la compromission d'un domaine Windows est quasi-systématique. Les différentes protections mises en place ne font que ralentir la progression de l'attaquant ou l'auditeur. Dans cet article, nous n'allons pas vous apprendre à effectuer un test d'intrusion, mais vous présenter 5 scénarios d'attaques qui vous permettront de compromettre un domaine Windows rapidement et quasiment à coup sûr à l'aide de Metasploit.

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

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

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

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

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

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

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

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 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous