Network Time Security

[seccraze]

Обычный NTP не защищен и может быть модифицирован человеком посередине, что позволяет получить контроль над системным временем. Аккуратное время критично, например, для проверки TLS сертификатов.

NTS добавляет шифрование к NTP. Поддержка есть в chrony или в ntpd-rs; последний написан на Rust. Пример конфигурации для chrony есть в GrapheneOS Infrastructure repository: https://github.com/GrapheneOS/infrastructure/blob/main/etc/chrony.conf (миграция на ntpd-rs была предложена в issues: https://github.com/GrapheneOS/infrastructure/issues/25).

Детали конфигурации chrony: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/configuring_time_synchronization/overview-of-network-time-security-nts-in-chrony.

Список серверов поддерживающих NTS: https://github.com/jauderho/nts-servers.

[seccraze]

Пример использования: https://privsec.dev/posts/macos/secure-time-synchronization-on-macos/.

Поддержка NTS есть только под Linux. Для Windows и macOS, NTS можно получить только запустив Linux в виртуальной машине и настроив встроенный NTP клиент на синхронизацию с VM, как по ссылке выше.

Keenetic роутеры уже имеют NTP сервер, дающий возможность синхронизировать время устройствам в локальной сети (локально можно и без шифрования). Но самому Keenetic'у лучше синхронизировать время зашифрованным образом.

[Denis P]

30 минут назад, seccraze сказал:

Но самому Keenetic'у лучше синхронизировать время зашифрованным образом.

зачем?

[keenet07]

Если служба синхронизации времени может быть подвержена MITM атаке, то как часть общей системы безопасности было бы не плохо иметь защищенный канал синхронизации на любом этапе загрузки устройства. И закрыть этот вектор атаки.

Чтоб исключить возможности атаки на TLS или на срыв открытых сессий и прочего функционала опирающегося на точное время.

Изменено 13 часов назад пользователем keenet07

[Denis P]

8 минут назад, keenet07 сказал:

Если служба синхронизации времени может быть подвержена MITM атаке, то как часть общей системы безопасности было бы не плохо иметь защищенный канал синхронизации на любом этапе загрузки устройства. И закрыть этот вектор атаки.

Чтоб исключить возможности атаки на TLS или на срыв открытых сессий и прочего функционала опирающегося на реальное время.

точно может? 
в каких осях из коробки используется nts?
пока что выглядит как поиск проблемы на ровном месте
 

[keenet07]

11 минут назад, Denis P сказал:

точно может?

Вы не можете представить как это можно сделать?

Если допустить возможность подмены всех ответов по NTP, установив в систему некорректное время или время сдвинутое на необходимый период, то уже это может вызвать нежелательные последствия. Сделать недоступными какие-либо сервисы.

На текущем этапе данная проблема решается в крупных системах другими методами. Но точно не в роутере. 

Изменено 13 часов назад пользователем keenet07

[seccraze]

41 minutes ago, Denis P said:

зачем?

Например, отзыв сертификатов требует аккуратного системного времени https://security.stackexchange.com/questions/72866/what-role-does-clock-synchronization-play-in-ssl-communcation (в моём вольном переводе):

Quote

Если атакующий украдёт приватный ключ сервера, он сможет выдать себя за этот сервер сколь угодно долго. Отзыв сертификата позволяет восстановиться после такой компрометации; срок годности самого сертификата позволяет ограничить размер Certificate Revocation LIst. Если клиент игнорирует отзыв или срок годности [по причине того что для клиента обе даты в будущем времени], то атакующий может пользоваться украденным приватным ключом до бесконечности.

12 minutes ago, Denis P said:

в каких осях из коробки используется nts?

Под Ubunt'ой chrony синхронизируется с Ubunt'овскими серверами по NTS. Плюс securebue. Плюс GrapheneOS.

Изменено 13 часов назад пользователем seccraze
добавил securebue и GrapheneOS

[Denis P]

7 минут назад, keenet07 сказал:

Вы не можете представить как это можно сделать?

Если допустить возможность подмены всех ответов по NTP, установив в систему некорректное время или время сдвинутое на необходимый период, то уже это может вызвать нежелательные последствия. Сделать недоступными какие-либо сервисы.

 

ещё раз, может или сделает? попробуйте воспроизвести этот кейс на кинетике
если получится - признаю свою недалёкость 

[seccraze]

2 minutes ago, Denis P said:

ещё раз, может или сделает? попробуйте воспроизвести этот кейс на кинетике

NTP ответ может быть модифицирован любым узлом на пути от Keenetic'а до настроенного сервера времени. Будет ли этим кто-то заниматься конкретно с вашим Keenetic'ом не имеет значения: нормальная безопастность устраняет возможность эксплуатации вместо того чтобы надеяться что уязвимость эксплуатировать никто не будет.

[keenet07]

30 минут назад, Denis P сказал:

ещё раз, может или сделает? попробуйте воспроизвести этот кейс на кинетике

Я не пентестер.

Нет, ну если вы что-то знаете, и есть какие-то механизмы помимо обычной синхронизации времени по указанным в системе NTP серверам. Или почему это не сработает именно на кинетике. То прямо и скажите.

Понятно, что вероятность подобной атаки низка, просто потому-что это должно происходить чуть ли не на уровне провайдера или на устройстве до него. Но тем не менее это возможно.

Вот эти товарищи (cloudflare) применяют в своей инфраструктуре. Этого мало? Или фигней страдают? Зря ресурсы тратят?

https://developers.cloudflare.com/time-services/nts/

Повсеместное внедрение дело времени.

Изменено 12 часов назад пользователем keenet07

[sergeyk]

2 часа назад, seccraze сказал:

Обычный NTP не защищен и может быть модифицирован человеком посередине, что позволяет получить контроль над системным временем. Аккуратное время критично, например, для проверки TLS сертификатов.

NTS для обмена с NTP-сервером использует TLS-соединение, которое осуществляет проверку сертификата сервера, требующую, в свою очередь, синхронизированное время для проверки срока действия сертификата.

[Mamay]

Сугубо ИМХО пахнет даже не паранойей, а местами шизофренией. У разработчиков ndms и так хватает актуальных и реальных задач, а не заниматься "сферическими конями в вакууме".

[keenet07]

6 минут назад, sergeyk сказал:

NTS для обмена с NTP-сервером использует TLS-соединение, которое осуществляет проверку сертификата сервера, требующую, в свою очередь, синхронизированное время для проверки срока действия сертификата.

Ну т.е. сначала всё-равно необходимо синхронизироваться открытым способом по NTP. А потом уже свериться с помощью TLS по NTS. И все дальнейшие проверки проводить уже по NTS. Метод конечно не идеальный получится, но защитит от дальнейшей возможной подмены времени пока устройство активно и не перезагружается.

В общем понятно.

[seccraze]

24 minutes ago, sergeyk said:

NTS для обмена с NTP-сервером использует TLS-соединение, которое осуществляет проверку сертификата сервера, требующую, в свою очередь, синхронизированное время для проверки срока действия сертификата.

https://security.stackexchange.com/a/231539 (вольный перевод основных моментов):

Quote

TLS 1.3 не требует согласованного времени для рукопожатия. … Даже TLS 1.1/1.2 не требовал аккуратного времени, поле gmt_unix_time в основном использовалось для рандомизации. … Поле gmt_unix_time было удалено из Client Handshake в TLS 1.3.

Сертификаты безопасности имееют срок службы больше пары секунд. Выставить время с точностью ± минута можно и руками при первом включении Keenetic'а.

Для тяжёлых случаев автоматизации, когда ручное вмешательство не является возможным, используется bootstrap сервер, как например в Ubunt'е https://git.launchpad.net/ubuntu/+source/chrony/tree/debian/conf.d/ubuntu-nts.conf (вольный перевод остновных моментов):

Quote

# Этот корневой сертификат нужен для старта Ubuntu NTS серверов. Он имеет очень большой срок службы (десятилетия вперёд/назад во времени), что позволяет системам с очень большим отклонением времени использовать NTS.

ntstrustedcerts 1 /etc/chrony/nts-bootstrap-ubuntu.crt

NTS не дураки делали; про проблему курицы или яица они прекрасно слышали.

Изменено 11 часов назад пользователем seccraze
опечатки