Déchiffrer un flux IPsec IKEv2 de Racoon2

IPsec, pour « Internet Protocol Security » est un des standards en termes de protocoles sécurisés. Très déployé dans le monde de l’entreprise, ce protocole permet d’assurer des communications sécurisés (intègres, authentifiées et confidentielles) au travers de réseaux jugés non-sécurisés tel l’Internet.

Cet article n’a pas la vocation de présenter finement le fonctionnement d’IPsec ni de ses multiples configurations, mais de s’attarder sur le déchiffrement de tels flux, notamment au travers du très célèbre analyseur réseau Wireshark.

Le protocole IPsec se compose de plusieurs sous-protocoles. Le protocole de négociation IKE pour « Internet Key eXchange », fondé sur le framework protocolaire ISAKMP (« Internet Security Association and Key Management Protocol »). IKE existe en deux versions dont les spécificités et fonctionnalités sont très différentes. La première version est jugée beaucoup plus complexe à mettre en place que la seconde notamment via ses modes de fonctionnement (« main », « agressive », « quick mode »…). Ce protocole de négociation sert à accorder les deux partis d’une liaison sécurisée autour des algorithmes cryptographiques à employer (symétrique, asymétrique, de hachage…), du type de lien à établir (« tunnel » ou « transport ») et du protocole d’acheminement de données à utiliser (AH pour « Authentification header » qui assure l’authentification des échanges, et/ou ESP pour « Encapsulated Security Payload » qui ajoute la confidentialité).

Au niveau de la pile OSI, IPsec évolue à divers niveaux. La négociation via IKE/ISAKMP s’effectue au niveau de la couche 4 applicative, via un transport UDP alors que l’acheminement des données en tant que telles se fait via la couche 3 réseau, protégeant ainsi toutes les couches supérieures (dont TCP et UDP).

Lors d’analyse réseau, de mise en place d’architecture sécurisée, de troubleshooting, de pentest, de fuzzing ou d’audit d’intrusion, il est souvent nécessaire de s’attarder sur des flux chiffrés via IPsec. Le déchiffrement de flux IPsec dépend du sous-protocole ciblé. Est-ce l’acheminement de données qui doit être déchiffré pour de l’analyse? Ou la négociation des paramètres de sécurité? Pour chacun de ces cas, diverses difficultés interviennent. L’outil de référence de visualisation des flux chiffrés et déchiffrés est Wireshark. Celui-ci dispose des facultés de :

• Déchiffrer des flux d’acheminement de données ESP. Une méthode générique est disponible.
• Déchiffrer des flux de négociation IKEv2. Une méthode générique est disponible.
• Déchiffrer des flux de négociation IKEv1. La méthode générique n’est disponible qu’à partir de la très récente version 1.8 de Wireshark.

• Racoon version 1 pour IKEv1, dont le démon de négociation se nomme Charon (Linux).
• Racoon version 2 pour IKEv1 et IKEv2, dont le démon de négociation se nomme « iked » et celui de gestion des SA (« Security Association ») « spmd » (Linux).
• FreeS/Wan et OpenS/Wan, basé sur le démon « Pluto » (Linux).
• Les systèmes Windows intègrent nativement la gestion d’IPsec au niveau noyau.

Récemment, il m’a été nécessaire d’effectuer de l’analyse post-mortem de flux de négociation IKEv2 pour des liaisons IPsec établies via Racoon2. Autrement dit, il fallait disposer de la possibilité de déchiffrer les flux IKEv2 de Racoon2. Certains démons IPsec fournissent d’emblée dans leurs fichiers de journalisation les valeurs hexadécimales nécessaires au déchiffrement de tels flux via Wireshark. Ces valeurs sont à renseigner dans l’analyseur réseau sous le menu « Edit/Preferences », puis dans la liste des protocoles rechercher « ISAKMP », éditer la table de déchiffrement IKEv2 et ajouter une nouvelle entrée, comme indiqué sur la capture suivante.

Les valeurs hexadécimales à renseigner sont:

• Initiator’s SPI : La valeur du cookie IKEv2 du côté de l’initiateur de la négociation. Cette valeur est visible dans les en-têtes de tous les échanges, en clair.
• Responder’s SPI : La valeur du cookie IKEv2 du côté de répondeur de la négociation. Cette valeur est visible à partir de la première réponse du serveur.
• SK_ei : Le vecteur hexadécimal de chiffrement de l’initiateur, qui sert à la dérivation de la clé symétrique partagée (Shared Key). Ce vecteur est généré au cours de l’appel des fonctions de création du secret partagé de chaque côté des pairs.
• SK_er : Le vecteur hexadécimal de chiffrement du répondeur, qui sert à la dérivation de la clé symétrique partagée (Shared Key). Ce vecteur est généré au cours de l’appel des fonctions de création du secret partagé de chaque côté des pairs.
• Encryption Algorithm : L’algorithme de chiffrement symétrique qui a été négocié au cours des deux premiers échanges, en clair.
• SK_ai : Le vecteur hexadécimal d’authentification de l’initiateur. Ce vecteur est généré au cours de l’appel des fonctions de création du secret partagé de chaque côté des pairs.
• SK_ar : Le vecteur hexadécimal d’authentification du répondeur. Ce vecteur est généré au cours de l’appel des fonctions de création du secret partagé de chaque côté des pairs.
• Integrity Algorithm : L’algorithme d’intégrité négocié au cours des deux premiers messages, en clair.

Toutefois, dans le cas de Racoon2, celui-ci ne fourni pas ces vecteurs malgré une forte verbosité. C’est pourquoi il a été nécessaire de recompiler les sources de Racoon2 en ajoutant quelques lignes de code pour visualiser les vecteurs hexadécimaux nécessaires. Pour déchiffrer la négociation IKEv2 de Racoon2, il faut donc dans un premier temps télécharger les sources du projet et les modifier avant l’installation du démon. Certaines dépendances sont aussi à installer:

wget http://ftp.racoon2.wide.ad.jp/pub/racoon2/racoon2-20100526a.tgz
tar zxvf racoon2-20100526a.tgz
cd racoon2-20100526a/
apt-get update
apt-get install libc6-dev bison flex libssl-dev libpcap-dev
apt-get install libkrb5-dev
apt-get install heimdal-dev
apt-get install heimdal-clients

Une fois téléchargées et extraites, le fichier à modifier est « racoon2-20100526a/iked/ikev2.c ». En ajoutant entre la ligne 5383 :

ike_sa->sk_p_r = sk_pr;

et 5384:

retval = 0;

le code suivant :

int i;
printf("\n############################### sk_ei : ");
for(i = 0 ; i < sk_e_len ; i++) printf("%02x", (unsigned char)sk_ei->v[i]);
printf("\n############################### sk_er : ");
for(i = 0 ; i < sk_e_len ; i++) printf("%02x", (unsigned char)sk_er->v[i]);
printf("\n############################### sk_ai : ");
for(i = 0 ; i < sk_a_len ; i++) printf("%02x", (unsigned char)sk_ai->v[i]);
printf("\n############################### sk_ar : ");
for(i = 0 ; i < sk_a_len ; i++) printf("%02x", (unsigned char)sk_ar->v[i]);
printf("\n\n");

Les modifications effectuées, une recompilation de Racoon2 est nécessaire. Sachant que le Makefile dispose de l’attribut « -Werror » et que de nombreuses variables sont déclarées sans être utilisées, la compilation ne s’achève pas. Il est donc d’intérêt de supprimer ce flag (environnement Ubuntu server).

CFLAGS=-D_GNU_SOURCE ./configure
#nano lib/Makefile # delete -Werror flag
sed -i 's/-Werror //g' lib/Makefile
make && make install

Après cette étape le démon est installé. Il suffit de configurer celui-ci au travers de ses divers fichiers dans « /usr/local/racoon2/etc/racoon2/ » puis de lancer le démon au premier plan :

cd /usr/local/racoon2/sbin
./spmd && ./iked -ddd -D 10 -F

Le démon de négociation « iked » est lancé avec une forte verbosité et au premier plan. Une fois Racoon2 de déployé sur les deux pairs de la communication sécurisée à mettre en place, ceux-ci afficheront dans le terminal les vecteurs hexadécimaux nécessaires au déchiffrement des flux IKEv2 :

Les vecteurs hexadécimaux, les SPI et les algorithmes de la négociation identifiés, il ne reste plus qu’à les renseigner au sein de Wireshark :

Enfin, après validation de l’ajout de ces renseignements, et un nouveau bloc « Decrypted Data » fait son apparition dans l’arborescence de l’analyseur de paquet avec le contenu en clair :

En espérant que ça puisse dépanner et faire gagner du temps à certains !

[Edit] Suite à un échange avec un membre du projet Racoon2, il s’avère qu’une alternative est présente au sein de ce projet. Il est en effet possible d’indiquer au démon « iked » d’enregistrer tous les échanges IKEv2 au sein d’un fichier PCAP sans aucun chiffrement. Cet enregistrement se fait donc en amont de l’envoi du paquet, puisque sur le médium le paquet est bien protégé. Cela peut être une solution.

Pour utiliser cette fonctionnalité, Racoon2 doit être compilé avec la prise en compte de la bibliothèque PCAP :

./configure --enable-pcap

Puis, comme l’indique le manuel/l’aide d’iked, l’option « -P » est utilisable :

-P outfile
Record unencrypted IKE communication packets to the file.This option is available only if was compiled with --enable-pcap configuration option.

Merci à Shoichi pour l’information !