La fonctionnalité Windows qui réinitialise les horloges système en fonction de données aléatoires fait des ravages

[duJambon]

Elle n’affecte cependant que les systèmes professionnels, toutefois cela peut produire des dégâts considérables.

Windows Secure Time Seeding réinitialise les horloges des mois ou des années par rapport à l’heure correcte.

Simen avait rencontré une erreur similaire en août dernier lorsqu’une machine exécutant Windows Server 2019 avait réinitialisé son horloge à janvier 2023, puis l’avait modifiée peu de temps après. Le dépannage de la cause de cette mystérieuse réinitialisation a été entravé car les ingénieurs ne l’ont découvert qu’après la purge des journaux d’événements. Le nouveau saut de 55 jours, sur une machine exécutant Windows Server 2016, l’a incité à rechercher à nouveau une cause, et cette fois, il l’a trouvée.

En 2017, par exemple, un utilisateur de Reddit dans un forum sysadmin a signalé que certaines machines Windows 10 que l’utilisateur administrait pour une université signalaient des heures inexactes, dans certains cas jusqu’à 31 heures dans le passé. L’utilisateur de Reddit a finalement découvert que les changements d’heure étaient corrélés à une clé de registre Windows dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits. Une enquête supplémentaire a montré que les changements d’heure étaient également liés à des erreurs indiquant que les certificats SSL valides utilisés par le site Web de l’université n’étaient pas valides lorsque certaines personnes tentaient d’y accéder. L’administrateur est arrivé à la conclusion suivante :

TLDR : Windows 10 a une fonctionnalité appelée Secure Time qui est activée par défaut. Il met en corrélation les métadonnées d’horodatage des paquets SSL et les compare à l’heure des DC. Il traite ces différents moments au moyen de la magie noire et règle l’horloge système en conséquence. Cette fonctionnalité a le potentiel de basculer et de régler l’heure du système sur une heure aléatoire dans le passé. Le flip out PEUT être causé par des problèmes de trafic SSL.

D’autres exemples de personnes signalant le même comportement, par exemple ici et ici , remontent à 2016, peu après le déploiement de STS. Des rapports plus récents de changements d’heure nuisibles induits par le STS sont disponibles ici , ici et ici .

“Nous avons rencontré un problème époustouflant où le temps sur un tas de systèmes de production a bondi de 17 heures”, a écrit un utilisateur de Reddit. “Si vous êtes dans le jeu depuis plus d’une semaine, vous savez les ravages que cela peut causer.”

Apprêt STS

Pour déterminer l’heure actuelle, STS extrait un ensemble de métadonnées contenues dans la poignée de main SSL. Plus précisément, les données sont :

• ServerUnixTime , une représentation de la date et de l’heure indiquant le nombre de secondes écoulées depuis 00:00:00 UTC le 1er janvier 1970
• Données signées de manière cryptographique obtenues à partir du certificat SSL du serveur distant indiquant s’il a été révoqué en vertu d’un mécanisme connu sous le nom de protocole d’état de certificat en ligne.

Les ingénieurs de Microsoft ont déclaré avoir utilisé les données ServerUnixTime “en supposant qu’elles sont quelque peu exactes”, mais ont ensuite reconnu dans la même phrase qu’elles “peuvent également être incorrectes”. Pour empêcher STS de réinitialiser les horloges système en fonction des données fournies par un seul serveur distant désynchronisé, STS établit des connexions SSL entrecoupées de manière aléatoire vers plusieurs serveurs pour arriver à une plage fiable pour l’heure actuelle. Le mécanisme fusionne ensuite ServerUnixTime avec la période de validité OCSP pour produire la plus petite plage de temps possible et lui attribue un score de confiance. Lorsque le score atteint un seuil suffisamment élevé, Windows classe les données en tant que STSHC, abréviation de Secure Time Seed of High Confidence. Le STSHC est ensuite utilisé pour surveiller les horloges système pour les “erreurs grossières” et les corriger.

Malgré les freins et contrepoids intégrés à STS pour s’assurer qu’il fournit des estimations de temps précises, les sauts de temps indiquent que la fonctionnalité fait parfois des suppositions farfelues qui sont décalées de jours, de semaines, de mois ou même d’années.

“À ce stade, nous ne savons pas exactement pourquoi l’ensemencement temporel sécurisé fait cela”, a écrit Ken dans un e-mail. "Étant si apparemment aléatoire, c’est difficile à [comprendre]. Microsoft n’a pas vraiment été utile non plus pour essayer de suivre cela. J’ai envoyé des journaux et des informations, mais ils n’ont pas vraiment suivi cela. Ils semblent plus intéressés à clore l’affaire.

Les journaux envoyés par Ken ressemblaient à ceux présentés dans les deux captures d’écran ci-dessous. Ils ont capturé les événements système qui se sont produits immédiatement avant et après que le STS ait changé les heures. La ligne sélectionnée dans la première image montre les limites de ce que STS calcule comme l’heure correcte en fonction des données des poignées de main SSL et de l’heuristique utilisée pour le corroborer.

Le coupable était une fonctionnalité peu connue de Windows connue sous le nom de Secure Time Seeding. Microsoft a introduit la fonction de chronométrage en 2016 afin de garantir l’exactitude des horloges système. Les systèmes Windows avec des horloges réglées à la mauvaise heure peuvent provoquer des erreurs désastreuses lorsqu’ils ne peuvent pas analyser correctement les horodatages dans les certificats numériques ou qu’ils exécutent des tâches trop tôt, trop tard ou dans l’ordre prescrit. Secure Time Seeding, a déclaré Microsoft, était une protection contre les pannes des appareils embarqués alimentés par batterie conçus pour conserver une heure précise même lorsque la machine est éteinte.

« Vous pouvez vous demander : pourquoi l’appareil ne demande-t-il pas l’heure actuelle au serveur de temps le plus proche sur le réseau ? » Les ingénieurs de Microsoft ont écrit. “Étant donné que l’appareil n’est pas en état de communiquer en toute sécurité sur le réseau, il ne peut pas non plus obtenir de temps en toute sécurité sur le réseau, à moins que vous ne choisissiez d’ignorer la sécurité du réseau ou au moins de percer quelques trous en faisant des exceptions.”

Pour éviter de faire des exceptions de sécurité, Secure Time Seeding définit l’heure en fonction des données contenues dans une poignée de main SSL que la machine établit avec des serveurs distants. Ces poignées de main se produisent chaque fois que deux appareils se connectent à l’aide du protocole Secure Sockets Layer, le mécanisme qui fournit des sessions HTTPS cryptées (il est également connu sous le nom de Transport Layer Security ). Étant donné que Secure Time Seeding (abrégé en STS pour le reste de cet article) utilisait des certificats SSL Windows déjà stockés localement, il pouvait garantir que la machine était connectée en toute sécurité au serveur distant. Le mécanisme, ont écrit les ingénieurs de Microsoft, “nous a aidés à briser la dépendance cyclique entre l’heure du système client et les clés de sécurité, y compris les certificats SSL”.

Simen n’était pas la seule personne à rencontrer des fluctuations sauvages et spontanées des horloges système Windows utilisées dans des environnements critiques. Au cours de l’année dernière, un ingénieur distinct nommé Ken a commencé à voir des dérives temporelles similaires. Ils étaient limités à deux ou trois serveurs et se produisaient tous les quelques mois. Parfois, les heures d’horloge sautaient de quelques semaines. D’autres fois, les temps ont changé jusqu’à l’année 2159.

“Cela a augmenté de façon exponentielle pour que de plus en plus de serveurs soient affectés par cela”, a écrit Ken dans un e-mail. « Au total, nous avons environ 20 serveurs (VM) qui ont connu cela, sur 5 000. Ce n’est donc pas énorme, mais c’est considérable, surtout compte tenu des dégâts que cela cause. Cela arrive généralement aux serveurs de base de données. Lorsqu’un serveur de base de données saute dans le temps, il fait des ravages et la sauvegarde ne s’exécute pas non plus, tant que le serveur a un tel décalage dans le temps. Pour nos clients, c’est crucial.

Simen et Ken, qui ont tous deux demandé à être identifiés uniquement par leur prénom parce qu’ils n’étaient pas autorisés par leurs employeurs à parler publiquement, ont rapidement découvert que les ingénieurs et les administrateurs signalaient les mêmes réinitialisations d’heure depuis 2016.

Capture d’écran d’un journal des événements système alors que STS fait sauter une horloge système à une date quatre mois plus tard que l’heure actuelle.

L’entrée “Projected Secure Time” immédiatement au-dessus de la ligne sélectionnée indique que Windows estime que la date actuelle est le 20 octobre 2023, plus de quatre mois plus tard que l’heure indiquée dans l’horloge système. STS modifie ensuite l’horloge système pour qu’elle corresponde à l’heure sécurisée projetée de manière incorrecte, comme indiqué dans « Heure système cible ».

La deuxième image montre un scénario similaire dans lequel STS change la date du 10 juin 2023 au 5 juillet 2023.

Simen, quant à lui, a déclaré qu’il avait également signalé les réinitialisations de l’heure à plusieurs groupes chez Microsoft. de Microsoft Lorsqu’il a signalé les problèmes sur le hub de commentaires en mai, a-t-il déclaré, il n’a reçu aucune réponse de la part de la société. Il l’a ensuite signalé via le Microsoft Security Response Center en juin. La soumission a été fermée en tant que “cas non-MSRC” sans élaboration.

L’ingénieur a ensuite fait appel à un tiers spécialisé dans la sécurité du cloud Microsoft pour agir en tant qu’intermédiaire. L’intermédiaire a relayé une réponse de Microsoft recommandant que STS soit désactivé lorsque le serveur reçoit un chronométrage fiable via le Network Time Protocol .

“Malheureusement, cette recommandation n’est pas accessible au public, et elle est encore loin d’être suffisante pour arrêter la fonctionnalité mal conçue pour continuer à faire des ravages dans le monde”, a écrit Simen dans un e-mail.

Attention : STS va “vous mordre les fesses”

Simen a déclaré qu’il pensait que la conception STS était basée sur une mauvaise interprétation fondamentale de la spécification TLS. La description de Microsoft de STS reconnaît que certaines implémentations SSL ne mettent pas du tout l’heure système actuelle du serveur dans le champ ServerUnixTime. Au lieu de cela, ces implémentations, notamment la bibliothèque de code OpenSSL largement utilisée à partir de 2014, remplissent le champ avec des valeurs aléatoires. La description de Microsoft poursuit en disant : “Nous avons observé que la plupart des serveurs fournissent une valeur assez précise dans ce champ et que les autres fournissent des valeurs aléatoires.”

“La fausse hypothèse est que la plupart des implémentations SSL renvoient l’heure du serveur”, a déclaré Simen. “C’était probablement vrai dans un écosystème réservé à Microsoft à l’époque où ils l’ont implémenté, mais à cette époque [lorsque STS a été introduit], OpenSSL envoyait déjà des données aléatoires à la place.”

Alors que les points de discussion officiels de Microsoft minimisent le manque de fiabilité de STS, Ryan Ries, dont le profil LinkedIn indique qu’il est un ingénieur principal d’escalade Windows chez Microsoft, n’était pas aussi réticent lorsqu’il a discuté de STS sur les réseaux sociaux l’année dernière.

“Salut les gens”, a-t-il écrit. “Si vous gérez des contrôleurs de domaine Active Directory, je souhaite vous donner un conseil NON OFFICIEL qui n’est que mon opinion personnelle : désactivez Secure Time Seeding pour w32time sur vos DC.” Quand quelqu’un lui a demandé pourquoi, Ries a répondu: “Parce que ce n’est qu’une question de temps - * clin d’œil * - avant qu’il ne vous morde les fesses.”

Un représentant de Microsoft a envoyé par e-mail la déclaration suivante plusieurs heures après la mise en ligne de ce message sur Ars :

La fonction Secure Time Seeding est une méthode heuristique de chronométrage qui permet également de corriger l’heure du système en cas de certaines défaillances de chronométrage logiciel/micrologiciel/matériel. La fonctionnalité a été activée par défaut dans toutes les configurations Windows par défaut et s’est avérée fonctionner comme prévu dans les configurations par défaut.

La répartition du temps est unique à chaque déploiement et les clients configurent souvent leurs machines en fonction de leurs besoins particuliers. Compte tenu de la nature heuristique de Secure Time Seeding et de la variété des déploiements possibles utilisés par nos clients, nous avons prévu la possibilité de désactiver cette fonctionnalité si elle ne répond pas à leurs besoins. Nous comprenons qu’il existe probablement des facteurs uniques, propriétaires et complexes dans les déploiements où les clients rencontrent des problèmes de Secure Time Seeding et ces clients ne bénéficient pas de cette fonctionnalité telle qu’elle est actuellement mise en œuvre. Dans ces cas isolés, le seul plan d’action que nous pouvons recommander est de désactiver cette fonctionnalité dans leurs déploiements.

Nous convenons que l’orientation générale de la technologie avec l’adaptation de TLS v1.3 et d’autres développements dans ce domaine pourrait rendre Secure Time Seeding moins efficace au fil du temps, mais nous n’avons connaissance d’aucun bogue résultant de leur utilisation. Cette orientation technologique rend également le calcul heuristique du temps utilisant SSL/TLS beaucoup moins attrayant par rapport à la synchronisation temporelle déterministe et sécurisée.

Nous continuons à étudier la meilleure façon de sécuriser la synchronisation de l’heure sur Internet et nous invitons les clients à nous faire part de leurs commentaires sur la meilleure façon de répondre à leurs besoins futurs.

Le mystère continue

Comme Simen l’a noté plus tôt, on ne sait pas précisément ce qui fait que STS fait des erreurs parfois mais pas toujours.

“C’est ce qui me semble vraiment étrange”, a écrit Simen. Microsoft “sait que le champ qu’ils examinent peut contenir des données aléatoires, donc je suppose que leur implémentation tombe en panne lorsque cela est biaisé, de sorte que la plupart/toutes les implémentations avec lesquelles ils communiquent contiennent des données aléatoires plutôt que certaines.”

HD Moore, CTO et co-fondateur de runZero, a émis l’hypothèse que la cause est une sorte de bogue logique dans le code Microsoft. Sur Signal, il écrit :

Si OpenSSL a défini des heures Unix aléatoires dans les réponses TLS pendant une longue période, mais que ce bogue apparaît rarement, il est probablement plus difficile à déclencher que de simplement forcer un tas de connexions TLS sortantes vers un serveur avec de fausses réponses d’horodatage - si c’était aussi simple que cela, cela arriverait beaucoup plus fréquemment.

Soit la logique STS nécessite des certificats racine différents en tant que signataire, soit une certaine variété dans les noms d’hôte/adresses IP, soit ne se déclenche que sur certaines saveurs d’horodatage aléatoire (comme des valeurs divisibles par 1024 ou quelque chose).

Cela ressemble à un bogue logique qui est déclenché rarement par des horodatages entièrement aléatoires (32 bits) et probablement juste un sous-ensemble de valeurs et avec d’autres conditions (comme plusieurs demandes dans une certaine période de temps à plusieurs certificats, etc.).

Il existe d’autres moyens de s’assurer que les horloges des serveurs restent précises, a déclaré Moore :

[Clock-setting] semble être quelque chose de mieux géré via NTP, ou au moins via une connexion TLS de confiance à un point de terminaison connu exploité par le fournisseur (time.windows.com et amis). Le moyen super paresseux (mais sans doute plus sûr) d’obtenir un horodatage de confiance est quelque chose comme : ❯ curl -s -vvv https://www.microsoft.com/4040 2>&1 | grep -i ‘< date:’< date: Wed, 16 Aug 2023 04:37:31 GMT.

Une seconde précision, et si vous verrouillez le client HTTP sur une courte liste de racines CA de confiance pour le domaine cible, il est assez difficile de jouer avec. J’ai utilisé quelque chose de similaire il y a une éternité sur les systèmes Linux où l’horloge tournait souvent mal - réglez hwclock sur l’horodatage de réponse HTTP d’un bon serveur connu, puis exécutez NTP, ce qui réussirait puisque l’horloge était suffisamment proche pour être dans la vérification des limites - sinon NTP échouerait car l’horloge était trop éloignée.

En tant que créateur et développeur principal du framework d’exploitation Metasploit, testeur d’intrusion et responsable de la sécurité, Moore possède une solide expérience en matière de sécurité. Il a émis l’hypothèse qu’il pourrait être possible pour des acteurs malveillants d’exploiter STS pour violer les systèmes Windows qui n’ont pas STS désactivé. Un exploit possible fonctionnerait avec une technique d’attaque connue sous le nom de Server Side Request Forgery .

Le refus répété de Microsoft de dialoguer avec les clients rencontrant ces problèmes signifie que dans un avenir prévisible, Windows continuera par défaut à réinitialiser automatiquement les horloges système en fonction des valeurs que les tiers distants incluent dans les poignées de main SSL. De plus, cela signifie qu’il incombera aux administrateurs individuels de désactiver manuellement STS lorsqu’il cause des problèmes.

Cela, à son tour, est susceptible de continuer à alimenter les critiques selon lesquelles la fonctionnalité telle qu’elle existe depuis sept ans fait plus de mal que de bien.

STS “ressemble plus à un logiciel malveillant qu’à une fonctionnalité réelle”, a écrit Simen. "Je suis étonné que les développeurs ne l’aient pas vu, que l’assurance qualité ne l’ait pas vu et qu’ils aient même écrit à ce sujet publiquement sans que personne ne lève un drapeau rouge. Et que personne chez Microsoft n’a agi lorsqu’il en a été informé.

Source: https://arstechnica.com/security/2023/08/windows-feature-that-resets-system-clocks-based-on-random-data-is-wreaking-havoc/

[Raccoon]

@duJambon a dit dans La fonctionnalité Windows qui réinitialise les horloges système en fonction de données aléatoires fait des ravages :

TLDR : Windows 10 a une fonctionnalité appelée Secure Time qui est activée par défaut. Il met en corrélation les métadonnées d’horodatage des paquets SSL et les compare à l’heure des DC. Il traite ces différents moments au moyen de la magie noire et règle l’horloge système en conséquence. Cette fonctionnalité a le potentiel de basculer et de régler l’heure du système sur une heure aléatoire dans le passé. Le flip out PEUT être causé par des problèmes de trafic SSL.

J’aime bien quand on m’explique l’origine d’un bug de cette manière. L’origine a beau être “de la magie noire” ça reste bien moins obscure que la doc Microsoft.