Features (FR)
_ _ Yoann Jonard

Exploitation du NTP

Comment exploiter le NTP pour dissimuler ses traces dans un switch ?

Introduction

Le Network Time Protocol (NTP) permet de synchroniser l’horloge de différents équipements informatiques sur un réseau. Très important dans le monde de la finance et du broadcast, avoir tous ses équipements à la même heure, et à la bonne heure, est aussi primordial pour des raisons de sécurité. Pourtant, ce protocole et son implémentation sont souvent délaissés, et son importance sous-estimée.

Voyons ensemble comment exploiter une configuration NTP basique sur un switch afin de dissimuler nos logs, compromettre les certificats et rendre les audits impossibles.

Environnement

Pour ce projet nous utiliserons un switch Extreme Networks virtuel ainsi que deux machines virtuelles sous Debian, le tout sous GNS3. La première machine agira en tant que serveur NTP légitime (NTP-Server-Legit), tandis que la deuxième sera l’attaquant (NTP-Server-Rogue). Notre cible est le switch (ntp-target).

  1. NTP-Server-Legit : 192.168.234.47
  2. NTP-Server-Rogue : 192.168.234.48
  3. ntp-target : 192.168.234.46

Le serveur NTP légitime utilisera chronyd en configuration par défaut, à l’exception du paramètre local stratum 8, qui indique que le serveur lui-même n’est pas synchronisé avec une horloge de référence, mais qu’il est tout de même digne de confiance.

NTP lab diagram

Situation nominale

Notre switch a pour serveur NTP la machine 192.168.234.47, notre serveur NTP légitime. Les horloges sont synchronisées et la communication est opérationnelle.

Un show ntp statistics confirme que le serveur est atteignable (Reachable) et synchronisé (System Peer).

Une capture de paquet sur l’uplink du switch nous montre bien les échanges entre les 2 machines : la requête du switch en 192.168.234.46 et la réponse du serveur en 192.168.234.47.

La structure d’une réponse NTP est la suivante, et nous allons nous intéresser aux 4 derniers champs dans le cadre de cet article. Je vous renvoie vers la RFC 5905 pour plus d’informations sur les autres champs.

Comme nous pouvons le voir la situation nominale est assez simple, et peut être même trop simple. Faisons entrer notre serveur NTP pirate dans l’équation.

NTP spoofing

Notre cible, le switch, ne supporte que le NTP unicast et ne s’attend à recevoir une mise a jour de la part du serveur que s’il en a fait la demande. Cela veut dire pour nous que nous ne pouvons pas simplement flooder des réponses NTP erronées sur le réseau en espérant que le switch les accepte. Nous devons donc nous faire passer pour le serveur NTP légitime auprès du switch, et nous faire passer pour le switch auprès du serveur NTP. Et pour cela, nous allons faire de l’ARP spoofing.

Dans Wireshark le spoofing se traduit comme cela: nous informons nos 2 cibles que l’adresse MAC de leur interlocuteur est la notre.

Nous interceptons le trafic, modifions les paquets en reculant le temps d’un mois et en l’avançant d’une heure, et répondons à notre cible.

Dans la première réponse, il est intéressant de noter la valeur de « origin timestamp », qui est le timestamp du client NTP lors de sa demande. On voit bien que notre switch était « à l’heure » le 4 avril 2024 lorsqu’il a demandé une mise à jour au serveur NTP, et que nous lui avons répondu que nous étions désormais en mars et avec une heure de plus.

Notre switch se croit donc en mars 2025 et la CLI nous le confirme.

Même principe si vous souhaitez prendre un peu d’avance sur votre temps. Modifions alors notre script pour nous retrouver en mars 2026 cette fois.

Très bien mais... pourquoi faire ?

Maintenant que notre switch est à l’heure qu’on souhaite bien lui donner, que peut-on en faire ?

Nous pouvons dissimuler nos actions dans les logs et rendre la chronologie des faits compliquée à comprendre.

Si vous consultez les logs sur le switch lui-même, alors vous conserverez l’ordre chronologique des commandes, car les logs sont écrits les uns à la suite des autres dans les fichiers. Vous verrez donc les commandes dans l’ordre dans lequel elles ont été tapées, avec les « fausses » dates associées. Ci-dessous les commandes dans l’ordre chronologique avec plusieurs mises a jour NTP entre temps : 4 avril 2025, 4 mars 2025, 4 mars 2026 et 4 mars 2024.

2025-04-04T12:23:14.529Z ntp-target CP1 [...] rwa show clock                     
2025-03-04T13:25:15.021Z ntp-target CP1 [...] rwa show clock                     
2026-03-04T13:37:40.853Z ntp-target CP1 [...] rwa show clock                     
2026-03-04T13:39:41.580Z ntp-target CP1 [...] rwa a very dangerous command in 2026
2024-03-04T13:41:14.454Z ntp-target CP1 [...] rwa show clock                     
2024-03-04T13:41:18.062Z ntp-target CP1 [...] rwa a very dangerous command in 2024
2024-03-04T13:41:22.246Z ntp-target CP1 [...] rwa show logging file module CLILOG

Dans un SIEM, la situation se corse, car les logs vont probablement être reclassés selon leur timestamp et non pas selon leur ordre d’arrivée. Vous perdez donc l’ordre chronologique des actions et la recherche dans les logs sera quasiment impossible, avec les impacts que l’on connait sur les audits.

Est-ce que logger les logs NTP est utile et permettrait de reconstituer l’ordre des actions ? Oui… et non.

Oui : Logger les logs NTP est utile, et vous devez prêter attention aux événements de type « NTP synchronization failed » car ceux-ci peuvent être le signe d’une compromission de vos serveurs NTP ou d’une désynchronisation de vos équipements.

Non: Logger les logs NTP ne vous permettra pas de reconstruire l’ordre des événements. Le hic est que le timestamp du log va être le timestamp du switch une fois celui-ci mis a jour par le NTP. Si vous etes le 4 avril 2025 et qu’un serveur NTP pirate change l’heure de votre switch pour le 4 mars 2025, votre log « NTP synchronization succeeded » sera en date du 4 mars 2025.

Et les certificats ?

Les certificats peuvent être échus prématurément si votre attaquant a décidé de placer votre switch dans le futur. Ou pas encore valides, s’il a décidé de se placer dans le passé avant la date de validité du certificat.

Mieux encore, en modifiant le temps dans le passé, vous pouvez « revalider » un certificat échus et continuer à l’utiliser.

D'autres impacts ?

Les impacts peuvent être nombreux sur les serveurs, notamment pour Kerberos, et le DNSSEC qui ne fonctionneront plus non plus.

À propos du DNS, bien qu’il soit pratique d’utiliser des noms de domaine pour ses serveurs NTP, attention à la résolution de nom avec des équipements désynchronisés. Si votre équipement n’est pas à l’heure, le DNSSEC ne fonctionnera pas, vous ne pourrez donc pas faire de résolution DNS pour connaître l’IP de votre serveur NTP, vous ne pourrez donc pas le joindre pour vous mettre à jour, et donc votre DNSSEC ne fonctionnera pas, et donc vous ne pourrez pas vous mettre à jour…

Je conseille de ne pas avoir de dépendance entre vos services critiques.

Votre NTP doit pouvoir fonctionner tout le temps, même sans DNS. Tout comme vos serveurs Radius, TACACS, OCSP…

Comment se protéger ?

Si l’attaque ci-dessus a été possible, c’est sous certaines conditions : nous étions dans le même sous-réseau que notre cible, l’ARP spoofing était possible, il n’y avait pas d’authentification NTP. Les deux premiers points sont d’ordre de sécurité générale en dehors du cadre de cet article, nous ne parlerons donc que de l’authentification NTP.

Authentification NTP

Vous pouvez authentifier vos paquets NTP en utilisant une clé symétrique entre le client et le serveur. Cette clé servira à calculer le « digest » des paquets NTP (le Message Authentication Code ou MAC), qui sera ajouté à la fin de chaque paquet. Lorsqu’un paquet NTP est reçu, aussi bien sur le serveur que sur le switch, ce MAC est recalculé avec la clé locale. Si celui-ci correspond à celui présent dans le paquet, cela veut dire que c’est la même clé qui a été utilisée à l’émission du paquet, le paquet est donc authentifié.

Dans notre exemple, mettons en place l’authentification des paquets NTP avec SHA1.

Dans chronyd, il suffit de créer un fichier chrony.keys avec notre clé en précisant l’algorithme de hash utilisé, et de redémarrer le daemon chronyd. Dans notre exemple nous utilisons l’ID de clé 100, l’algorithme de hash SHA1, et la clé « ntp ».

echo "100 SHA1 ntp" >> /etc/chrony/chrony.keys
systemctl restart chronyd

Dans le switch, il faut créer la clé et lier la clé au serveur NTP. Vous pouvez ainsi avoir des clés différentes pour différents serveurs.

ntp authentication-key 100 type sha1
ntp
ntp
ntp server 192.168.234.47 authentication-key 100
ntp server 192.168.234.47 auth-enable

Un show ntp statistics nous indique cette fois que l’authentification est activée (Auth Enabled : Enabled)

Dans Wireshark, nous voyons que les paquets NTP font désormais 114 octets de long au lieu de 90 sans l’authentification.

L’ID de la clé (100 en décimal, 64 en hexa), et le MAC sont présents à la fin de chaque paquet.

Si on essaie de spoofer notre serveur NTP, nos réponses ne seront pas acceptées par le switch. En effet, nous n’avons pas connaissance de la clé sur notre serveur d’attaque. Même si nous interceptons les requêtes et les réponses, le MAC est calculé sur la base de la clé et des champs du paquet. Comme nous modifions les paquets pour changer le temps, mais que nous ne pouvons pas modifier le MAC, le switch, à la réception d’un paquet altéré, va recalculer le MAC et constater que celui-ci ne correspond pas. La réponse sera donc ignorée et le switch ne mettra pas à jour son horloge.

Ci-dessous la réponse légitime du serveur NTP que nous interceptons.

Et la réponse que nous renvoyons au client.

Le MAC est le même (dernier champ du paquet), tandis que les timestamps ont changé. Comme nous ne pouvons pas recalculer le MAC sans la clé, nous conservons celui renvoyé par le serveur et nous renvoyons cette réponse au client.

Côté client, ce paquet est simplement ignoré car le MAC ne correspond pas. Notre spoofing n’a donc aucun impact.

Les mauvaises idées à avoir pour se protéger

Synchroniser directement à l’extérieur

Vous ne maîtrisez pas ces serveurs ni leur sécurité, et si tous vos équipements se synchronisent à l’extérieur, vous augmentez inutilement l’utilisation de votre ligne Internet. Si vous utilisez différents serveurs externes, vous pouvez observer des différences de synchronisation sur vos équipements.

Synchroniser sur plusieurs sources internes...

… sans que celles-ci ne soient synchronisées ensemble ! Vous risquez d’avoir des difficultés de corrélation de logs si vos équipements sont synchronisés avec des serveurs qui présentent un léger décalage de temps entre eux.

Les bonnes idées à avoir

Penser à la sécurité de vos serveurs

  1. Synchronisez vos serveurs entre eux et depuis des sources externes fiables, ou depuis vos propres horloges de référence si vous le pouvez.

  2. Configurer l’authentification NTP, ou mieux, le NTS.

  3. Configurer le max drift sur vos serveurs pour que ceux-ci ne puissent pas trop dévier du temps initial.

  4. N’acceptez des requêtes NTP que depuis vos équipements.

ARP inspection

Cette attaque aurait été impossible si le switch avait été correctement configuré avec de l’ARP inspection.

Vérifier vos logs

Ne négligez pas un log « NTP synchronization failed »…

Conclusion

NTP seul ne suffit plus. Si quelques prérequis sont remplis, un attaquant peut altérer l’horloge de vos équipements pour dissimuler ses traces ou simplement les rendre inaccessibles. Dans un contexte financier, un équipement désynchronisé peut être utilisé pour des fraudes, et dans un contexte industriel, les lignes de production peuvent être affectées par des équipements désynchronisés.

Le minimum est donc d’ajouter de l’authentification sur NTP comme nous l’avons vu plus haut, ou d’utiliser NTS sur les équipements compatibles (actuellement, seuls les switches Juniper semblent compatibles) qui chiffrent complètement les communications NTP grâce à l’utilisation de clés asymétriques.

Enfin si le NTP n’est pas assez précis pour vos besoins, le PTP (Precision Time Protocol) est une alternative supportée par la plupart des constructeurs de switches et propose une précision à la nanoseconde.

Contactez-nous pour savoir comment mettre en place ces fonctionnalités.

Suivez-nous sur LinkedIn pour ne pas manquer nos prochaines vidéos.

Sources