{"id":30440,"date":"2023-09-14T08:28:51","date_gmt":"2023-09-14T06:28:51","guid":{"rendered":"https:\/\/www.kaspersky.de\/blog\/?p=30440"},"modified":"2023-09-14T08:28:51","modified_gmt":"2023-09-14T06:28:51","slug":"windows-system-time-sudden-changes","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/windows-system-time-sudden-changes\/30440\/","title":{"rendered":"Falsche Systemuhrzeit und unsicheres Secure Time Seeding"},"content":{"rendered":"

Hin und wieder fragen sich<\/a> Nutzer und Administratoren von Windows 10, warum die Zeit ihres Systems pl\u00f6tzlich um mehrere Wochen, Monate oder sogar Jahre springt (entweder vorw\u00e4rts<\/a> oder r\u00fcckw\u00e4rts<\/a>).<\/p>\n

Woran k\u00f6nnten diese Spr\u00fcnge liegen? Die Journalisten von Ars Technica haben recherchiert<\/a> und herausgefunden, dass dies m\u00f6glicherweise mit der Funktion Secure Time Seeding zusammenh\u00e4ngen k\u00f6nnte. In diesem Beitrag m\u00f6chte ich die Funktionsweise dieser Funktion erl\u00e4utern und erkl\u00e4ren, was man tun kann, um solche unerwarteten Zeitspr\u00fcnge zu verhindern.<\/p>\n

\u00a0<\/p>\n

Was ist Secure Time Seeding?<\/h2>\n

Secure Time Seeding (STS)<\/a> wurde 2015 zu Windows 10 hinzugef\u00fcgt. Mit dieser Funktion sollen Diskrepanzen zwischen der im System eingestellten Zeit und der tats\u00e4chlichen Zeit korrigiert werden \u2013 in erster Linie, wenn der Akku eines Computers, der die interne Echtzeituhr<\/a> speist, leer ist und die Zeiteinstellung nichts mit der Realit\u00e4t gemein hat. Vor allem aber ist STS in der Lage, die Systemzeit zu korrigieren, ohne auf die Echtzeit-Server zuzugreifen.<\/p>\n

Doch warum ist eine solche Korrektur von Zeitdiskrepanzen \u00fcberhaupt erforderlich? Kurioserweise aus Sicherheitsgr\u00fcnden. Normalerweise wird der Client-Server-Datenaustausch (einschlie\u00dflich der Systemverbindung zu den Internet-Zeitservern<\/a>) mit SSL\/TLS-Verschl\u00fcsselungsprotokollen gesch\u00fctzt. Damit eine solche Verbindung mit dem Server zustande kommen kann, muss der Client zun\u00e4chst sein digitales Zertifikat verifizieren, wobei diese Zertifikate eine bestimmte G\u00fcltigkeitsdauer haben. Wenn die Uhrzeit im System fehlerhaft eingestellt ist, kann das Zertifikat als abgelaufen betrachtet werden, und eine sichere Verbindung kann nicht zustande kommen.<\/p>\n

So entsteht ein Teufelskreis: Damit der Computer die aktuelle Zeit herausfinden kann, muss er die aktuelle Zeit kennen. Diese muss nicht exakt sein, auch die ungef\u00e4hre Zeit kann gen\u00fcgen. Doch je gr\u00f6\u00dfer der Unterschied zwischen der Systemzeit und der tats\u00e4chlichen Zeit ist, desto gr\u00f6\u00dfer ist die Wahrscheinlichkeit, dass das Zertifikat als abgelaufen markiert wird.<\/p>\n

Warum die Systemzeit von Windows pl\u00f6tzlich springt, was das Secure Time Seeding damit zu tun hat und wie man das Problem beheben kann.<\/p>Tweet<\/a><\/blockquote>\n

STS erm\u00f6glicht es dem System (zumindest nach Ansicht der Entwickler), gr\u00f6\u00dfere Unstimmigkeiten automatisch zu erkennen und zu korrigieren, selbst dann, wenn keine sichere Verbindung mit einem Server hergestellt werden kann. Dies geschieht durch die Verwendung aktueller Zeitstempel und G\u00fcltigkeitsdaten digitaler Zertifikate, die in den Daten enthalten sind, die von den Servern w\u00e4hrend des ersten Aufbaus einer sicheren Verbindung an den Client gesendet werden (die SSL- und TLS-Handshakes).<\/p>\n

Der genaue Algorithmus von STS ist unbekannt. Der Grundgedanke ist jedoch, dass Windows Daten aus dem SSL-Handshake bezieht und anhand dieser Daten einen zuverl\u00e4ssigen Bereich f\u00fcr die aktuelle Zeit berechnet und ihm eine Wahrscheinlichkeit zuweist. Sobald neue Daten verf\u00fcgbar sind, wird der Bereich aktualisiert, und die Wahrscheinlichkeit kann schrittweise erh\u00f6ht werden. Wenn ein bestimmter Schwellenwert erreicht wird, \u00e4ndert STS die Systemzeit auf den Mittelwert des als zuverl\u00e4ssig erachteten Bereichs. In der Theorie sollte diese Genauigkeit ausreichen, um eine sichere Verbindung herzustellen, eine Verbindung zu einem aktuellen Zeitserver herzustellen und die genaue Zeit zu ermitteln.<\/p>\n

\u00a0<\/p>\n

Deshalb sollten Sie Secure Time Seeding deaktivieren<\/h2>\n

Das Hauptproblem ist, dass die Funktion in Windows 10 standardm\u00e4\u00dfig aktiviert ist und unabh\u00e4ngig davon arbeitet, ob die im Computer integrierte Uhr jemals aus dem Takt geraten ist. Folglich kann STS die Zeit jederzeit zur\u00fccksetzen, wenn Microsofts geheimer Algorithmus entscheidet, dass es gen\u00fcgend Anzeichen daf\u00fcr gibt, dass die Uhr die falsche Zeit anzeigt und angepasst werden muss.<\/p>\n

Der Grund f\u00fcr derartige Fehlfunktionen bei Secure Time Seeding ist nicht vollst\u00e4ndig bekannt. Es wird vermutet, dass die zunehmende Popularit\u00e4t von SSL\/TLS-Implementierungen, die w\u00e4hrend des Handshakes einen falschen Zeitstempel senden, eine Ursache ist. Der Hauptverd\u00e4chtige ist hier die h\u00e4ufig verwendete OpenSSL-Bibliothek (die anstelle der aktuellen Serverzeit Zufallswerte in den Zeitstempel einf\u00fcgt).<\/p>\n

Dar\u00fcber hinaus kann dieser Bug auch in Server-Versionen des Betriebssystems auftreten: Windows Server 2016, Windows Server 2019 und Windows Server 2022. Und w\u00e4hrend das Problem f\u00fcr normale Computernutzer kaum mehr als ein \u00c4rgernis ist, kann es f\u00fcr Server katastrophale Folgen haben, da deren korrekter Betrieb oft von einer genauen Zeitangabe abh\u00e4ngt.<\/p>\n

Es gibt diesbez\u00fcglich eine inoffizielle Empfehlung<\/a> von einem leitenden Mitarbeiter des technischen Supports von Microsoft f\u00fcr Active Directory-Domain-Controller-Administratoren:<\/p>\n

\u201eServus, wenn ihr Active Directory Dom\u00e4nencontroller verwaltet, m\u00f6chte ich euch einen UNOFFIZIELLEN Tipp geben, der ausschlie\u00dflich meine pers\u00f6nliche Meinung widerspiegelt: Deaktiviert Secure Time Seeding f\u00fcr den Windows-Zeitdienst w32time auf euren DCs.\u201c<\/em><\/p>\n

\"Inoffizieller<\/a>

Inoffizieller Rat eines erfahrenen Windows Escalation Engineer: Deaktivieren Sie Secure Time Seeding<\/p><\/div>\n

\u00a0<\/p>\n

Deaktivieren von der Windows-Funktion Secure Time Seeding<\/h2>\n

Zum Deaktivieren von STS suchen Sie den folgenden Key in der Windows Registrierungsdatenbank:<\/p>\n

[code] HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\W32Time\\Config [\/code]<\/span><\/p>\n

Ermitteln Sie den Wert UtilizeSslTimeData<\/span> und setzen Sie ihn auf 0.<\/p>\n

\"Deaktivieren<\/a>

Deaktivieren von Secure Time Seeding in der Registrierungsdatenbank von Windows<\/p><\/div>\n

\u00a0<\/p>\n

Alternativ k\u00f6nnen Sie den folgenden Befehl<\/a> als Administrator in der Befehlszeile von Windows (CMD) ausf\u00fchren:<\/p>\n

[code] reg add HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\w32time\\Config \/v UtilizeSslTimeData \/t REG_DWORD \/d 0 \/f [\/code]<\/span><\/p>\n

Nachdem Sie den Wert angepasst haben, m\u00fcssen Sie das System neu starten. Wenn dies schwierig oder unm\u00f6glich ist, k\u00f6nnen Sie die Aktualisierung mit diesem Befehl erzwingen:<\/p>\n

[code] W32tm.exe \/config \/update [\/code]<\/span><\/p>\n

Anschlie\u00dfend wird die STS-Funktion Sie nicht mehr bel\u00e4stigen. Jetzt m\u00fcssen Sie nur noch daf\u00fcr sorgen, dass die Systemuhr immer korrekt eingestellt ist. Zu diesem Punkt gibt dieser Artikel von Ars Technica<\/a> ein paar hilfreiche Tipps f\u00fcr Serveradministratoren.<\/p>\n

\u00a0<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Warum sich die Windows-Systemzeit pl\u00f6tzlich \u00e4ndern kann und wie man das verhindern kann. <\/p>\n","protected":false},"author":2726,"featured_media":30441,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1848,3107,3108],"tags":[1498,1653,371,33],"class_list":{"0":"post-30440","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-schwachstellen","11":"tag-security","12":"tag-ssl","13":"tag-windows"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/windows-system-time-sudden-changes\/30440\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/windows-system-time-sudden-changes\/26162\/"},{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/windows-system-time-sudden-changes\/21623\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/windows-system-time-sudden-changes\/28859\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/windows-system-time-sudden-changes\/26469\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/windows-system-time-sudden-changes\/26655\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/windows-system-time-sudden-changes\/29140\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/windows-system-time-sudden-changes\/35996\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/windows-system-time-sudden-changes\/48956\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/windows-system-time-sudden-changes\/20952\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/windows-system-time-sudden-changes\/21736\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/windows-system-time-sudden-changes\/26743\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/windows-system-time-sudden-changes\/32471\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/windows-system-time-sudden-changes\/32125\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/windows\/","name":"Windows"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30440","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/2726"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=30440"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30440\/revisions"}],"predecessor-version":[{"id":30447,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/30440\/revisions\/30447"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/30441"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=30440"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=30440"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=30440"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}