Attaque sur le protocole Kerberos

Magazine
Marque
MISC
Numéro
54
|
Mois de parution
mars 2011
|
Domaines


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


Sur le même sujet

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

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Cet article explique comment exploiter la CVE-2018-4193, une élévation de privilèges affectant les versions de macOS inférieures à 10.13.5, en moins de 10 secondes. Les différents prérequis nécessaires à la compréhension de l’exploit seront détaillés de sorte qu’aucune connaissance préalable de macOS ne soit nécessaire, ce qui permet d’aborder l’exploitation de vulnérabilités dans les démons macOS en général.

Auditer la sécurité d'une application iOS

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

Auditer la sécurité d'une application iOS n'est toujours pas une tâche aisée. Force est de constater que la plupart des auditeurs, amateurs de bug bounty ou autres curieux préfèrent travailler sur les applications Android malgré les récentes protections ajoutées au système d'exploitation de Google. Nous allons malgré tout essayer de présenter une méthodologie qui rend possible l'analyse orientée sécurité d'une application iOS, même sans jailbreak. Un bref rappel sera effectué pour ensuite introduire quelques outils et documentations apparues ces derniers mois.

Sondes de détection : performances, évaluations et biais

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En avril 2019, l’ANSSI a qualifié les premières sondes pour assurer la supervision de sécurité de réseaux. Les opérateurs d’importance vitale (OIV), les opérateurs de services essentiels (OSE) et, d’une manière générale, les organismes opérant des fonctions sensibles disposent ainsi de produits français de confiance : Cybels Sensor de Thales et Trackwatch Full Edition de Gatewatcher.La méthodologie d’évaluation des sondes n’est, hélas, pas publique. Les ingénieurs sécurité et réseau devant intégrer ces sondes ne disposent donc pas de guides pour effectuer la recette de leur efficacité en production. Cet article propose un retour d’expérience sur l’évaluation des sondes, notamment sous l’angle de la performance. Cet aspect est, en effet, particulièrement significatif puisque le taux de détection d’une sonde diminue si elle est submergée, quand bien même elle serait équipée des meilleurs signatures et moteurs d’analyse.

Richelieu : solution du challenge de la DGSE

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

En mai 2019, la DGSE (Direction Générale de la Sécurité Extérieure) a organisé pour la première fois un challenge de sécurité informatique ouvert au public, qu’elle a baptisé Challenge Richelieu. Je vous invite à écouter la bande originale du Bureau des Légendes en fond sonore. Imprégnez-vous de cette atmosphère pleine de tension où les secrets sont rois, puis regardons ensemble ce que nous réservait ce challenge.

Aléa et cryptanalyse de générateurs

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

La plupart des applications en cryptographie moderne nécessitent à un moment ou un autre une source d’aléa [1]. Que ce soit pour chiffrer, générer des nonces, des clés ou même des sels cryptographiques. Mais comment générer de l’aléa sur nos ordinateurs qui sont des machines déterministes ?Dans cet article, nous allons nous intéresser à la place de l’aléa dans les algorithmes de chiffrements modernes. Puis nous verrons trois CTF ou le but est de cryptanalyser des générateurs de nombres aléatoires ; cela nous permettra d’en comprendre le fonctionnement et de voir quelques attaques sur des générateurs de nombres aléatoires.

Par le même auteur

Contournement de l'API Google Play Billing

Magazine
Marque
MISC
Numéro
106
|
Mois de parution
novembre 2019
|
Domaines
Résumé

D'après le blog [INVESP], le montant global des paiements dits « in-app » représentait environ 37 milliards de dollars (USD) en 2017 pour les applications mobiles (Android et Apple). Ce montant représente quasiment la moitié des revenus générés par les applications mobiles (48,2%), dépassant les revenus générés par les régies publicitaires (14%), ainsi que l'achat d'applications (37,8%). Il est donc important que la sécurité de ces paiements soit correctement implémentée afin d'éviter un manque à gagner pour les développeurs des applications. Dans le cadre de cet article, nous avons passé en revue 50 applications Android afin d'étudier le fonctionnement de l'API Google Play Billing et d'identifier les vulnérabilités liées à une mauvaise implémentation. Nous détaillerons en exemple des applications vulnérables.

Cinq façons de devenir administrateur de domaine avec Metasploit

Magazine
Marque
MISC
HS n°
Numéro
14
|
Mois de parution
octobre 2016
|
Domaines
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.

Mise en place du SIEM Prelude en entreprise – Retour d'expérience

Magazine
Marque
MISC
Numéro
70
|
Mois de parution
novembre 2013
|
Domaines
Résumé
Prelude se présente comme une solution universelle de «  Security Information and Event Management » (SIEM). L'objectif de cet article est de vous présenter la solution Prelude, ainsi que sa mise en place en entreprise. Les avantages et les inconvénients de Prelude seront également discutés.

Utilisation avancée de Mimikatz

Magazine
Marque
MISC
Numéro
66
|
Mois de parution
mars 2013
|
Domaines
Résumé
Mimikatz est un outil permettant d’effectuer diverses actions sur un système Windows : injection de bibliothèques, manipulation de processus, extraction de hashes et de mots de passe notamment. Il devient indispensable aujourd’hui dans la boîte à outils de tout pentester. Cet article a pour objectif de vous présenter l'utilisation de l'outil lors d'un test d'intrusion, ainsi que l'extraction de mots de passe et de certificats.

Utilisation avancée de sqlmap

Magazine
Marque
MISC
Numéro
62
|
Mois de parution
juillet 2012
|
Domaines
Résumé
Sqlmap est un outil open source permettant d'identifier et d'exploiter une injection SQL sur des applications web. Outre la simple exploitation d'une injection SQL, il fournit également des fonctionnalités permettant la prise de contrôle de l'équipement hébergeant la base de données. Il est devenu aujourd'hui indispensable dans la trousse à outils de tout pentester. Cet article a pour objet de vous présenter les dernières fonctionnalités de l'outil, ainsi que son utilisation dans des cas pratiques.