Windows Secure Time Seeding сбрасывает часы на месяцы или годы с правильного времени.Несколько месяцев назад инженер в центре обработки данных в Норвегии столкнулся с некоторыми непонятными ошибками, из-за которых сервер Windows внезапно переустанавливал свои системные часы на 55 дней вперед. Инженер полагался на сервер для поддержки таблицы маршрутизации, которая отслеживала номера сотовых телефонов в режиме реального времени, когда они перемещались от одного оператора к другому. Скачок на восемь недель имел ужасные последствия, потому что из-за него номера, которые еще не были переданы, были указаны как уже перемещенные, а номера, которые уже были переданы, были указаны как ожидающие.
«С этими обновленными таблицами маршрутизации многие люди не могли совершать звонки, так как у нас не было правильного состояния!» написал в электронном письме инженер, попросивший назвать его только по имени Симен. «Мы перенаправляли входящие и исходящие звонки не тем операторам! Это означало, например, что дети не могли связаться со своими родителями и наоборот».
Симен столкнулся с аналогичной ошибкой в августе прошлого года, когда машина под управлением Windows Server 2019 сбросила свои часы на январь 2023 года, а затем через некоторое время вернула их обратно. Устранение причины этого таинственного сброса было затруднено, потому что инженеры не обнаружили его до тех пор, пока не были очищены журналы событий. Более новый скачок в 55 дней на машине под управлением Windows Server 2016 побудил его еще раз искать причину, и на этот раз он ее нашел.
Виной тому была малоизвестная функция Windows, известная как Secure Time Seeding. Microsoft представила функцию хронометража в 2016 году, чтобы обеспечить точность системных часов. Системы Windows с часами, настроенными на неправильное время, могут привести к катастрофическим ошибкам, когда они не могут правильно проанализировать временные метки в цифровых сертификатах или выполнять задания слишком рано, слишком поздно или не в установленном порядке. По заявлению Microsoft, Secure Time Seeding является защитой от сбоев бортовых устройств с батарейным питанием, предназначенных для сохранения точного времени, даже когда машина выключена.
«Вы можете спросить, почему устройство не запрашивает у ближайшего сервера времени текущее время по сети?», написали инженеры Microsoft. «Поскольку устройство не в состоянии безопасно обмениваться данными по сети, оно также не может безопасно получать время по сети, если только вы не решите игнорировать сетевую безопасность или, по крайней мере, проделать в ней некоторые дыры, сделав исключения».
Чтобы избежать исключений безопасности, безопасное заполнение времени устанавливает время на основе данных внутри рукопожатия SSL, которое машина устанавливает с удаленными серверами. Эти рукопожатия происходят всякий раз, когда два устройства подключаются с использованием протокола Secure Sockets Layer, механизма, который обеспечивает зашифрованные сеансы HTTPS (он также известен как безопасность транспортного уровня). Поскольку безопасное заполнение времени (сокращенно STS для остальной части этой статьи) использовало сертификаты SSL, которые Windows уже хранила локально, это могло гарантировать, что машина была безопасно подключена к удаленному серверу. Этот механизм, как писали инженеры Microsoft, «помог нам разрушить циклическую зависимость между системным временем клиента и ключами безопасности, включая SSL-сертификаты».
Саймен был не единственным, кто сталкивался с дикими и спонтанными колебаниями системных часов Windows, используемых в критически важных средах. В прошлом году другой инженер по имени Кен начал замечать похожие сдвиги во времени. Они были ограничены двумя или тремя серверами и происходили каждые несколько месяцев. Иногда часы прыгали на несколько недель. В других случаях время менялось вплоть до 2159 года.
«Все больше и больше серверов страдают от этого в геометрической прогрессии», написал Кен в электронном письме. «Всего у нас есть около 20 серверов (ВМ), которые испытали это, из 5000. Так что это не огромная сумма, но значительная, особенно учитывая ущерб, который это наносит. Обычно это происходит с серверами баз данных. Когда сервер базы данных скачет во времени, это сеет хаос, и резервное копирование также не будет выполняться, пока сервер имеет такое огромное смещение во времени. Для наших клиентов это имеет решающее значение».
Саймен и Кен, которые попросили назвать их только по именам, потому что их работодатели не уполномочили их говорить под запись, вскоре обнаружили, что инженеры и администраторы сообщали об одном и том же сбросе времени с 2016 года.
Например, в 2017 году пользователь Reddit на форуме системных администраторов сообщил, что некоторые компьютеры с Windows 10, которые пользователь администрировал для университета, сообщали неточное время, в некоторых случаях на целых 31 час в прошлом. В конце концов пользователь Reddit обнаружил, что изменения времени были связаны с ключом реестра Windows в HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\SecureTimeLimits. Дополнительное расследование показало, что изменения времени также были связаны с ошибками, из-за которых сообщалось, что действительные SSL-сертификаты, используемые веб-сайтом университета, были недействительны, когда некоторые люди пытались получить к нему доступ. Админ сделал следующий вывод:
TLDR: в Windows 10 есть функция Secure Time, которая включена по умолчанию. Он сопоставляет метаданные меток времени из пакетов SSL и сопоставляет их со временем от контроллеров домена. Он обрабатывает эти различные времена с помощью черной магии и соответствующим образом устанавливает системные часы. Эта функция может перевернуться и установить системное время на случайное время в прошлом. Отключение МОЖЕТ быть вызвано проблемами с SSL-трафиком.
Другие примеры людей, сообщающих о том же поведении, относятся к 2016 году, вскоре после развертывания STS.
«Мы столкнулись с ошеломляющей проблемой, когда время на нескольких производственных системах перескочило вперед на 17 часов», написал один из пользователей Reddit. «Если вы были в игре больше недели, вы знаете, какой хаос это может вызвать».
Чтобы определить текущее время, STS извлекает набор метаданных, содержащихся в рукопожатии SSL. В частности, данные:
ServerUnixTime, представление даты и времени, показывающее количество секунд, прошедших с 00:00:00 UTC 1 января 1970 г.
Криптографически подписанные данные, полученные из SSL-сертификата удаленного сервера, показывающие, был ли он отозван с помощью механизма, известного как протокол статуса онлайн-сертификата.
Инженеры Microsoft заявили, что использовали данные ServerUnixTime, «предполагая, что они в некоторой степени точны», но в том же предложении признали, что они «также могут быть неверными». Чтобы служба STS не сбрасывала системные часы на основе данных, предоставленных одним несинхронизированным удаленным сервером, служба STS случайным образом устанавливает SSL-соединения с несколькими серверами, чтобы получить надежный диапазон для текущего времени. Затем механизм объединяет ServerUnixTime с периодом действия OCSP, чтобы получить наименьший возможный диапазон времени, и присваивает ему показатель достоверности. Когда оценка достигает достаточно высокого порога, Windows классифицирует данные как STSHC, сокращение от Secure Time Seed of High Confidence. Затем STSHC используется для мониторинга системных часов на наличие «грубых ошибок» и их исправления.
Несмотря на встроенные в STS системы сдержек и противовесов, обеспечивающие точную оценку времени, временные скачки указывают на то, что функция иногда делает неверные предположения, отличающиеся на дни, недели, месяцы или даже годы.
«На данный момент мы не совсем уверены, почему безопасный посев времени делает это», написал Кен в электронном письме. «Похоже, что это так случайно, что это трудно понять. Microsoft также не очень помогла в попытке отследить это. Я отправил журналы и информацию, но они не проследили за этим. Кажется, они больше заинтересованы в закрытии дела.
Журналы, отправленные Кеном, зафиксировали системные события, которые произошли непосредственно перед и после того, как STS изменила время.
Одна запись «Прогнозируемое безопасное время» показывает, что Windows оценивает текущую дату как 20 октября 2023 г., что более чем на четыре месяца позже времени, отображаемого на системных часах. Затем служба STS изменяет системные часы, чтобы они соответствовали неверно спроецированному безопасному времени, как показано в разделе «Целевое системное время».
Симен сообщил о сбросе времени нескольким группам в Microsoft. Сообщая о проблемах в центре отзывов Microsoft в мае, он сказал, что не получил ответа от компании. Затем он сообщил об этом через Центр реагирования Microsoft Security в июне. Представление было закрыто как «дело, не относящееся к MSRC» без каких-либо уточнений.
Затем инженер привлек третью сторону, специализирующуюся на облачной безопасности Microsoft, чтобы она выступила в качестве посредника. Посредник передал ответ от Microsoft, рекомендовавший отключить STS, когда сервер получает надежное хронометраж через сетевой протокол времени.
«К сожалению, эта рекомендация не является общедоступной, и ее все еще недостаточно, чтобы остановить неправильно разработанную функцию, которая продолжает сеять хаос во всем мире», написал Саймен в электронном письме.
Саймен сказал, что, по его мнению, дизайн STS основан на фундаментальном неправильном толковании спецификации TLS. В описании Microsoft STS признается, что некоторые реализации SSL вообще не помещают текущее системное время сервера в поле ServerUnixTime. Вместо этого эти реализации, прежде всего широко используемая библиотека кода OpenSSL, начиная с 2014 года, заполняют поле случайными значениями. Далее в описании Microsoft говорится: «Мы заметили, что большинство серверов предоставляют довольно точное значение в этом поле, а остальные предоставляют случайные значения».
«Ошибочное предположение состоит в том, что большинство реализаций SSL возвращают время сервера», сказал Саймен. «Вероятно, это было верно в экосистеме только Microsoft, когда они ее реализовали, но в то время, когда была введена STS, вместо этого OpenSSL уже отправлял случайные данные».
Представительница Microsoft подтвердила, что получила электронное письмо с подробным описанием изменений времени, а затем промолчала. Она не ответила на последующее письмо. Интересно, что Райан Райс, старшая инженер по эскалации Windows в Microsoft, не была такой сдержанной при обсуждении STS в соцсетях в прошлом году.
«Привет, люди», писала она. «Если вы управляете контроллерами домена Active Directory, я хочу дать вам НЕОФИЦИАЛЬНЫЙ совет, который является исключительно моим личным мнением: отключите безопасное заполнение времени для w32time на ваших контроллерах домена». Когда кто-то спросил, почему, Райс ответила: «Потому что это всего лишь вопрос времени (смайлик *подмигнул*), прежде чем он укусит тебя за задницу».
Как заметил Саймен ранее, неясно, что именно заставляет STS совершать ошибки иногда, но не всегда.
«Это то, что действительно кажется мне странным», написал Саймен. Microsoft «знает, что поле, на которое они смотрят, может содержать случайные данные, поэтому я предполагаю, что их реализация ломается, когда это искажено, так что большинство/все реализации, с которыми они взаимодействуют, содержат случайные данные, а не только некоторые».
HD Moore, техдиректор и соучредитель runZero, предположил, что причиной является какая-то логическая ошибка в коде Microsoft. Он писал в «Сигнале»: «Если OpenSSL устанавливал случайное время unix в ответах TLS в течение длительного периода времени, но эта ошибка проявляется нечасто, то ее, вероятно, сложнее вызвать, чем просто принудительно выполнить кучу исходящих TLS-подключений к серверу с поддельными ответами с временной меткой – если это было так просто, это случалось бы гораздо чаще.
Либо логика STS требует разных корневых сертификатов в качестве подписавшего, либо некоторого разнообразия имен хостов/IP-адресов, либо срабатывает только при определенных вариантах случайной метки времени (например, значениях, делящихся на 1024 или что-то в этом роде).
Это пахнет логической ошибкой, которая редко вызывается полностью случайными временными метками (32-разрядными) и, вероятно, просто некоторым подмножеством значений и некоторыми другими условиями (например, множественными запросами в определенный период времени к нескольким сертификатам и т. д.)».
По словам Мура, существуют и другие способы обеспечения точности часов сервера: «Настройка часов кажется чем-то, что лучше обрабатывается через NTP или, по крайней мере, через доверенное соединение TLS с известной конечной точкой, управляемой поставщиком (time.windows.com и друзья). Очень ленивый (но, возможно, более безопасный) способ получить доверенную метку времени выглядит примерно так: curl -s -vvv https://www.microsoft.com/4040 2>&1 | grep -i '<дата:'<дата: среда, 16 августа 2023 г., 04:37:31 по Гринвичу.
Вторая точность, и если вы привязываете HTTP-клиент к короткому списку доверенных корневых центров сертификации для целевого домена, с ним довольно сложно связываться. Я использовал что-то подобное много лет назад в системах Linux, где часы часто сбивались – установил hwclock на отметку времени ответа HTTP заведомо исправного сервера, затем запустил NTP, который был бы успешным, поскольку часы были достаточно близки, чтобы быть в пределах проверки границы, иначе NTP потерпел бы неудачу, так как часы были слишком далеко».
Как создатель и ведущий разработчик платформы эксплойтов Metasploit, тестер на проникновение и главный специалист по безопасности, Мур имеет большой опыт в области безопасности. Он предположил, что злоумышленники могут использовать STS для взлома систем Windows, в которых STS не отключена. Один из возможных эксплойтов будет работать с техникой атаки, известной как подделка запросов на стороне сервера.
Неоднократный отказ Microsoft взаимодействовать с клиентами, столкнувшимися с этими проблемами, означает, что в обозримом будущем Windows по умолчанию продолжит автоматически сбрасывать системные часы на основе значений, которые удаленные третьи стороны включают в рукопожатия SSL. Кроме того, это означает, что отдельные администраторы должны будут вручную отключать STS, когда это вызывает проблемы.
Это, в свою очередь, вероятно, будет продолжать разжигать критику в отношении того, что эта функция, существующая в течение последних семи лет, приносит больше вреда, чем пользы.
STS «больше похожа на вредоносное ПО, чем на реальную функцию», пишет Саймен. «Я поражен, что разработчики этого не видели, что QA этого не видел, и что они даже написали об этом публично, и никто не поднял красный флаг. И что никто в Microsoft не предпринял никаких действий, когда узнал об этом».