В процессе подготовки статьи "Как я зарегистрировал CVE и разозлил вендора" я искал статьи с практическими результатами по подмене локального времени жертвы (при синхронизации через NTP). Это оказалось нелегко: чаще всего статьи были теоретическими. Но, я нашёл и довольно интересную статью от 07.11.2024: Quantitative Risk Analysis of Network Time Protocol (NTP) Spoofing Attacks. Часть вопросов, которые изучаются в статье:

• рассмотрены атаки на ntpd, NTPSec, chrony, и OpenNTPD;

• оценивается возможность максимального смещения времени атакой (в условиях защитных механизмов атакуемых утилит);

• рассматриваются сложности атак.

Указывается, что остаются вопросы для дальнейшего изучения. Например, в части встроенных в различные ОС механизмов синхронизации времени.

Помимо этих вопросов - вот вопросы, которые у меня остались.

• Когда именно происходит синхронизация времени через утилиты или в ОС в обычной жизни? И как часто? Т.е. сколько времени нужно ждать атакующему для возможности совершить атаку? Принудительный перезапуск утилиты не рассматриваем.

• DHCP предусматривает периодическое обновление данных - не только IP-адрес, шлюз по-умолчанию и DNS. А и NTP (пример настройки NTP для DHCP в маршрутизаторе MikroTik). И тут 2 варианта атаки: либо получен доступ к DHCP серверу, либо подмена DHCP-пакетов (при атаке "человек посередине"). Как эти варианты атаки скажутся на системное время различных ОС, сконфигурированных по-разному (в т.ч. если даже в ОС используется более безопасный вариант вроде NTPSec и др.)? Тем более, что подмена NTP-сервера через DHCP во многом лишена тех сложностей, что описываются в статье.

• UPD: другой вариант - отравить кэш локального DNS-сервера (если в качестве сервера времени прописано доменное имя). Допустим, клиенты получают время от 0.ru.pool.ntp.org. И в качестве DNS сервера у них прописан роутер MikroTik, подверженный CVE-2019-3978.

Было бы любопытно ознакомиться с существующими best practices синхронизации времени, учитывающими все вышеуказанные риски (либо хотя бы пытающиеся их учитывать).

Другие статьи на эту же тему:

• Securing NTP against MITM attacks (от 09.12.2022);

• Как синхронизация времени стала безопасной (от 09.06.2020).