Quelle est l'heure locale pour la sécurité?
J'ai récemment voulu voir ce qui se passe lorsque je change mon heure locale pour quelque chose de visiblement faux. J'ai essayé l'année 2218, donc 200 ans dans le futur. Résultat: je ne pouvais plus accéder à aucun site Web (je n'en ai pas essayé trop cependant). J'ai eu cette erreur:
J'imagine NET::ERR_CERT_DATE_INVALID signifie qu'un certificat HTTPs n'est pas valide. Mais généralement, il existe une option "avancée" qui me permet de l'ignorer. Ce n'est pas le cas ici. Aussi, je me demande pourquoi il est écrit "votre horloge est en avance" - si chrome connaît l'heure exacte, pourquoi ne prend-il pas cela pour comparer?
Venant à ma question: Quelle est l'importance de l'heure locale pour la sécurité? Si un attaquant peut modifier arbitrairement l'heure du système, quels types d'attaques le permettent? Y a-t-il des cas signalés où la manipulation du temps a été un élément crucial?
Si un attaquant peut modifier arbitrairement l'heure du système, quels types d'attaques le permettent?
Au-delà des certificats ...
RNG mal ensemencés
Ils peuvent être en mesure d'exploiter un générateur de nombres aléatoires mal ensemencé. L'utilisation de time comme graine se produisait souvent avant que de meilleures interfaces de nombres aléatoires ne réalisent que votre programmeur moyen ne peut pas faire confiance pour fournir une bonne graine. Un attaquant peut exploiter cela en définissant l'heure du système à une heure où le générateur de nombres aléatoires produira la sortie souhaitée.
Bien sûr, l'attaquant peut se sauver beaucoup de tracas en attendant simplement un moment souhaitable.
UUID
UUIDv1 et v2 dépendent tous deux de l'adresse MAC et de l'heure. L'adresse MAC peut être découverte. Être en mesure de régler l'heure signifie qu'ils peuvent désormais contrôler quel UUID est attribué ensuite. Par exemple, ils peuvent être en mesure de dupliquer l'UUID d'un compte administratif pour eux-mêmes. Bien sûr, UUIDv1 et v2 ne sont pas censés être sécurisés , ils sont juste censés être uniques . Si vous voulez sécuriser et unique, vous utilisez UUIDv4, mais il existe de nombreux logiciels qui utilisent UUIDv1 et v2 de manière inappropriée.
Emplois périodiques
De nombreux systèmes ont des processus critiques qui s'exécutent périodiquement à certains jours et à certaines heures. L'attaquant peut jouer avec le temps pour manipuler cela.
De nombreux systèmes ont des fenêtres de maintenance qui se produisent à certains moments. L'attaquant pourrait réinitialiser en permanence le temps de séjour dans cette fenêtre et maintenir le système en panne pour maintenance.
S'il existe un processus gourmand en ressources qui se produit périodiquement, ils peuvent jouer avec le temps de telle sorte que plusieurs de ces processus s'exécutent en même temps. Si le système ne limite pas le nombre de processus simultanés, cela peut submerger le système.
Ou vous pouvez aller dans l'autre sens et réinitialiser continuellement l'heure pour empêcher l'exécution d'un processus de maintenance critique.
Chiens de garde
Le système peut avoir des processus de surveillance qui recherchent trop ou trop peu d'actions se produisant dans une fenêtre de temps. Le chien de garde peut choisir de prendre action de maintenance automatique telle que le redémarrage des machines ou l'arrêt des services . Un attaquant peut manipuler l'heure pour donner l'impression que le taux est trop élevé ou trop bas, ce qui déclenche le chien de garde et l'amène à arrêter un système qui fonctionne.
Vous avez là un tas de questions.
Je suppose que NET :: ERR_CERT_DATE_INVALID signifie qu'un certificat HTTPs n'est pas valide.
Oui.
Voici le cert pour help.ubuntu.com:
Vous remarquerez qu'il a des dates Valide du et Valide jusqu'au; si vous essayez d'accéder à un site protégé par ce certificat en dehors de ces dates, votre navigateur s'en plaindra. La raison pour laquelle les certificats expirent est (entre autres raisons) de forcer les webmasters à continuer d'obtenir de nouveaux certificats en utilisant la dernière crypto et d'autres nouvelles fonctionnalités de sécurité dans les certificats.
Lorsque votre navigateur tente de décider s'il fait confiance à un certificat, il utilise l'horloge système comme source définitive de vérité pour le temps. Bien sûr, il essaiera d'utiliser NTP, mais si vous (l'utilisateur administrateur) lui avez explicitement dit que les serveurs NTP sont faux, eh bien, vous êtes le patron.
Si un attaquant peut modifier arbitrairement l'heure du système, quels types d'attaques le permettent?
Examinons séparément les ordinateurs personnels et les serveurs. Je n'ai fait aucune recherche ici, juste du haut de ma tête.
Ordinateur personnel
- Les utilisateurs jouent souvent à des jeux avec leur horloge système pour contourner les choses de type "essai de 30 jours". Si vous êtes l'entreprise dont le logiciel est utilisé illégalement de cette façon, vous considérerez que c'est un problème de sécurité.
- Sites Web usurpés. Il est beaucoup plus facile de pirater les anciens certificats expirés - peut-être a-t-il utilisé un crypto de 10 ans qui est facilement piraté, ou peut-être que le serveur a été compromis il y a 6 ans, mais les autorités de certification ne suivent pas les informations de révocation pendant aussi longtemps (crédit d'idée: réponse de @immibis ). Si un attaquant peut modifier l'horloge de votre système, vous ne verrez pas les avertissements.
Les serveurs
- Enregistrement. Lorsque vous enquêtez sur une faille de sécurité, si les horloges de vos serveurs ne sont pas synchronisées, il peut être très difficile de reconstituer tous les journaux pour déterminer exactement ce qui s'est passé et dans quel ordre.
- Connexions. Des éléments comme l'authentification par facteur OTP 2 sont généralement basés sur le temps. Si les horloges d'un serveur se trouvent derrière un autre serveur, vous pouvez regarder quelqu'un entrer un code OTP, puis l'utiliser contre le serveur qui se trouve derrière, car ce code n'a pas encore expiré.
L'une des raisons est que les enregistrements de révocation de certificats ne sont pas conservés après l'expiration du certificat.
Supposons que j'ai volé le certificat de Google il y a 10 ans. Google a immédiatement remarqué et révoqué son certificat. Étant donné que le certificat a expiré au cours des 10 dernières années, l'entrée de révocation a été supprimée. Si je remets votre horloge à 10 ans lorsqu'elle était valide, je peux usurper l'identité de Google et votre navigateur ne le remarquera pas, car il ne saura pas qu'il a été révoqué.
Votre question est large, mais si un attaquant peut changer l'horloge du système local, il peut alors empoisonner les journaux de son activité. De cette façon, ils peuvent masquer leur activité pour sembler avoir eu lieu dans le passé (et peut-être au-delà de la fenêtre que les administrateurs recherchent) ou coïncider avec l'activité d'un autre utilisateur.
Par exemple, si vous pénétrez dans un système au milieu de la nuit, vous pouvez régler l'horloge pour qu'elle soit à midi la veille, faire votre activité, puis remettre l'horloge en marche. Quiconque inspecte les journaux suppose que l'utilisateur normal a fait l'activité (ou ne la voit pas du tout parmi les activités de l'utilisateur normal).
C'est pourquoi il est important de configurer votre horloge pour qu'elle soit synchronisée avec une source externe faisant autorité. Cela, et que tous les journaux de toutes les sources peuvent être correctement corrélés.
Il y aurait deux situations possibles où un ordinateur qui pense que l'année est 2038 essaie de se connecter au monde extérieur, et tout dans le monde extérieur dit que c'est 2018:
L'horloge de l'ordinateur est incorrecte.
L'année est en fait 2038, et tout dans ce qui semble être le monde extérieur est truqué, en utilisant des certificats de 2018 qui ont été fêlés depuis 20 ans.
Bien que les attaques de cette forme soient suffisamment difficiles à réaliser, la première possibilité serait en pratique beaucoup plus probable, pour se prémunir contre la seconde, il faudrait obtenir la confirmation que l'horloge de l'ordinateur est incorrecte.
Si vous exécutez un seul contrôleur de domaine Windows ou une partie de son réseau, une différence de temps de seulement cinq ou quelques minutes peut être critique: Kerberos Time Tolerance
Une fois, j'ai dû faire face à un serveur Windows SBS 2008 en panne et j'ai dû trouver un moyen d'entrer en tant que SYSTEM pour lire le journal des événements.
Il s'est avéré qu'une surtension avait réinitialisé l'horloge du BIOS CMOS du contrôleur de domaine, de retour à la date de conception du système, quelques années auparavant. Le résultat étant que les tickets Kerberos ne pouvaient pas être émis.
Les tickets Kerberos ne sont valables que quelques minutes.
Un autre exemple (légèrement alambiqué) d'attaque contre un ordinateur dont l'heure système est en retard est de servir des enregistrements DNS obsolètes à partir d'une zone sécurisée avec DNSSEC.
Par exemple, si le client demandait l'adresse www.example.com, l'attaquant pourrait répondre avec une référence à son propre serveur DNS et une preuve (expirée) de non-existence d'un enregistrement DS pour example.com à partir du moment où example.com n'était pas encore signé, et sert ensuite des enregistrements DNS falsifiés pour quoi que ce soit dans la zone example.com.