Notes en vrac sur IPSec

Travaillant régulièrement avec des tunnels IPSec, nous jetons là quelques éléments pour éclaircir leur fonctionnement.

IPSec est à la fois un nom de protocole et un terme générique pour désigner les réseaux privés virtuels (et tous ce qui va avec) qui utilisent ce protocole.

En effet dans le langage courant IPSec englobe IKE qui permet d’authentifier deux parties distantes l’une par rapport à l’autre et de définir des Security Associations (SA) et tous les paramètres nécessaires à des échanges en IPSec ESP ou AH.

Nous ne détaillerons pas ici une n-ième fois les notions de transport, tunnel, ESP, AH. Nous allons plutôt tenter de nous focaliser principalement sur l’aspect pratique des choses.

IKE et IKEv2 se décomposent en 2 étapes successives appelées phase :

La Phase 1 (généralement UDP 500).
Elle permet d’authentifier les 2 entités l’une par rapport à l’autre. L’authentification se fait par rapport à une méthode pré-définie (PSK ou certificat) : la méthode doit être la même pour les deux entités. La phase 1 négocie les IKE Phase 1 SAs utilisées dans la phase 2.

Main mode : Il protège l’identité des 2 hôtes distants mais nécessite que chacun ait une adresse ip fixe.
Aggressive mode : Il est plus rapide mais moins sécurisé que le main mode. C’est le seul mode possible lorsqu’on utilise des hôtes nomades.

C’est dans la phase 1 qu’on définit si l’on veut ou non utiliser le NAT-Transversal ou le DPD (voir plus bas).

Phase 2 : (généralement UDP 500 ou UDP 4500 en cas de NAT Transversal)
L’objectif principal de la phase 2 est de négocier les IKE Phase 2 SAs (ou IPSec SAs ou simplement SAs.). Il n’existe (pour l’instant) qu’un seul mode :
Quick mode  : il permet de définir les options sur le VPN notamment en définissant les Security Assocations (IPSec SAs). le mode du tunnel : ESP ou AH ? Mécanismes cryptographiques utilisés ? Clés ?

Pour les phase 1 et 2, il faut définir des mécanismes de sécurité  :
– Condition d’expiration et de renouvellement : soit une durée soit une quantité de données.
– Diffie-Hellman : 2, 5, 14, 16, …
– Algorithme de hash: MD5 / SHA1 /SHA2-256 / SHA2-512 / …
– Algorithme de chiffrement (et mode) : DES, 3DES, Blowfish AES,…

Ainsi  nous pouvons définir pour la phase 1 : AES-256-CBC/sha2-256/ DH-16 à renouveler toutes les  28800 sec (8h) et pour la phase 2 : AES-256-GCM/HMAC-SHA2-256/DH-16 à renouveler tous les 500 Mo.
Cependant ces recommandations sur ces valeurs ne peuvent être génériques et dépendent à la fois du matériel et des utilisations faites des tunnels. L’ANSSI est visiblement du même avis.

Une fois nos tunnels montés et opérationnels, la SAD (Security Association Database) est complétér avec les SAs. La SAD est composée de deux listes :
– les politiques pour le trafic entrant;
– les politiques pour le trafic sortant.

Chaque trafic IPSec est identifié par un Security Parameter Index (SPI) qui permet de rechercher dans les SADs le SA correspondant et ainsi de déchiffrer les données (et également d’en vérifier l’intégrité et l’authenticité). Le SPI est codé sur 32 bits pour IPSec (à noter que les SPI d’IKE sont sur 64 bits).

La commande setkey est très utile notamment avec les arguments suivants : -D (dump des SAs), -F (flush des SAs : tous les tunnels vont devoir être renégociés). Nous pouvons alors nous poser la question suivante :

Si nous faisons un setkey -F, nous supprimons toutes les SAs de la SAD et les tunnels sont donc à renégocier : oui mais devons-nous renégocier seulement la phase 2 ou bien la phase 1 + phase 2 ?

DPD : Le Dead Peer Detection (DPD) est basé sur des messages de notifications IKE et permet de vérifier qu’un correspondant est toujours opérationnel. Quand le DPD est activé sur un correspondant, des requêtes de test de disponibilité (R-U-there) sont envoyées à l’autre correspondant. Ce dernier devra acquitter la requête pour valider sa disponibilité (R-U-there-ACK). Ces échanges sont sécurisés via les SAs de la phase 1 IKE. Si on détecte qu’un correspondant ne répond plus, les SAs négociées sont alors détruites.

Le moteur IKE a trois états pour le  DPD, il peut être soit  :
– Inactif : les requêtes DPD provenant du correspondant sont simplement ignorées.
– Passif : les requêtes DPD émises par le correspondant obtiennent une réponse du serveur. En revanche, il n’en n’envoie pas.
– Actif : des requêtes sont envoyées. Il est alors possible de jouer sur la tolérance à la réception des paquets retour (R-U-there-ACK) : La fréquence d’émission, le temps d’attente de la réponse avant de considérer que le boitier ne répond plus, le nombre de tentatives d’envoi sans réponse avant de supprimer les SAs correspondant à cet hôte distant.

Keep-Alive : Enfin, il existe le Keep-Alive. Ce système permet de maintenir les tunnels montés de façon artificielle. Cette mécanique envoie des paquets UDP forçant le maintien du tunnel.

Mais revenons un peu en arrière, pour identifier l’hôte distant, il n’y a que deux mécanismes : l’utilisation d’une PSK ou d’un certificat X.509 (bon en fait, en lisant les RFCs, y en a un peu plus, mais ces deux là sont utilisables dans à peu près toutes les implémentations).

La PSK présente l’avantage d’être très facilement mise en place mais elle est vulnérable dans au moins une configuration.

La PSK peut permettre à un attaquant de réaliser une attaque par force brute ou dictionnaire. En effet, dans le mode agressif utilisé par les « Road Warriors« , le client s’authentifiant par PSK transmet le condensat de cette dernière en clair sur le réseau. Un attaquant n’a plus qu’à tendre l’oreille sur le réseau et tenter de casser le condensat.

Une démonstration valant mieux qu’un long discours, nous avons utilisé l’outil ike-scan pour réaliser une attaque :

IKE

Alors il y a plusieurs façons de se prémunir contre cet outil, tout d’abord utiliser du sha2 car d’après le code, le logiciel ne supporte que du md5 et sha1:

/*
 *      Calculate HASH_R
 */
   if (psk_params->hash_type == HASH_TYPE_MD5) {
      hmac_md5(psk_params->hash_r_data, psk_params->hash_r_data_len, skeyid,
               psk_params->hash_r_len, hash_r);
   } else {     /* SHA1 */
      hmac_sha1(psk_params->hash_r_data, psk_params->hash_r_data_len, skeyid,
                psk_params->hash_r_len, hash_r);
   }
   return hash_r;

Cependant gageons qu’en bon gros bourrin que nous sommes, il n’est pas bien compliqué avec notre bon vieux WireShark de récupérer les informations nécessaires (ne restera plus ensuite qu’à utiliser Cain ou John The Ripper pour retrouver le mot de passe). Nous illustrons tous cela par l’image suivante que seuls les lecteurs de la page 10 de la RFC 2409 pourront comprendre.

IKE_WiresShark

Du coup, un coup de python et nous voilà avec un code qui supporte d’autres fonctions de hash :

import hashlib
import hmac

def make_digest(psk,message,h):
    "Return a digest for the message."
    return hmac.new(psk, message, h).hexdigest()

NiNr = ""
KeyEch = ""
hash_r=""
#Chose the hash md5,sha1,sha224,sha256,sha512
h = hashlib.sha1

# The psk you want to test :
psk = "orangina"

skeyid = make_digest(psk,NiNr.decode("hex"),h)
res = make_digest(skeyid.decode("hex"),KeyEch.decode("hex"),h)

if hash_r == res:
    print "Bingo"
else:
    print "Try again"

Une fois que l’on sait cela : What could possibly go wrong ?

La configuration de tunnel est une action délicate et il est possible que cela ne marche pas du premier coup : Pourquoi notre tunnel ne monte-t-il pas ?
Erreur en Phase 1:
– Problème de routage : les 2 hôtes ne parviennent pas à communiquer
– Filtrage du port 500 en UDP
– Filtrage du port 4500 en UDP si le NAT Transversal est utilisé
– Erreur d’authentification
=> PSK erronée
=> Validation des certificats (confiance ou keyUsage ou ExtentedKeyUsage ou …)
– Pas de compatibilité entre les propositions de mécanismes cryptographiques de phase 1

Erreur en Phase 2:
– Mauvaise configuration des réseaux distants (ou de leurs masques)
– Pas de compatibilité entre les propositions de mécanismes cryptographiques de phase 2

Rappelons qu’une fois les tunnels montés, nous pouvons via wireshark en déchiffrer le contenu pour investiguer davantage.

Voilà en espérant que cela aide certains à un peu mieux appréhender les tunnels IPSec.

Publicités

A propos JoMendes

Amateur de mathématiques et d'hexadécimal. Je m'intéresse de près ou de loin suivant mon niveau à tous les sujets de sécurité de l'information.
Cet article, publié dans Uncategorized, est tagué , , , . Ajoutez ce permalien à vos favoris.

Un commentaire pour Notes en vrac sur IPSec

  1. Mike Rogers dit :

    Si je peux me permettre, dans tous les cas :
    – laissez tomber la PSK (douloureux si le nombre de SA croit et sujet à erreur et attaque)
    – n’utilisez que le mode tunnel
    – utilisez AES 256, SHA 512, DH >= 3 (4 ou 5 de préférence)
    – activez la DPD

    et tant pis pour l’interopérabilité avec des configurations faibles.

    Globalement, ce protocole n’est pas au niveau.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s