Comments 48
Любопытное расследование
Неужели так легко превратить НСДИ в Национальную систему DNS спуффинга?
Есть предположение, что оно по-большому счёту ради этого, собственно, и. Просто в данном случае повоевало не в ту сторону.
предположение
Ну это лицемерие.
«Некрасиво подозревать, когда вполне уверен». Станислав Ежи Лец
Но глядя на текущие векторы цифровизации — тот же повальный сбор биометрии с дальнейшим отлавливанием засветившегося на камерах народа на митингах, лично я вероятность этого оцениваю как невысокую. Зачем делать собственные ДНСы без спуфинга, если можно со спуфингом — и ничего за это не будет?
Тот факт что НСДИ существует, не означает что было именно так. Все же для подтверждения/опровержения стоило спросить напрямую у серверов НСДИ, раз уж их адреса есть в инете.
У меня провайдер иногда 8.8.8.8 блочит (перехватывает) и DoH до популярных провайдеров тоже. Но не постоянно. Видимо, какие-то "учения" периодически проходят
Как можно перехватить DoH? Там же сертификаты серверов проверяются.
Просто dns подменялся, doh - блокировался
Не факт. Например микротик по дефолту не проверяет. Чтобы проверял нужно скормить сертификат и поставить галочку.
А DoH не перехватываю и не подменяют, пакету на IP адрес сервера просто делают DROP. У меня так на ростелекоме перестал открываться сайт https://1.1.1.1/ где был DoH.
Гипотеза интересная, но сомнительная. Допустим, некто получил доступ к управлению НСДИ и... спалил контору ради сайта ВГТРК? Сомнительно, ИМХО были цели повкуснее.
Особенно автора статьи удивило то, что никто этого и не заметил
Так уже DoH везде в браузерах.
> Так мы явно безопасный рунет не построим.
Можно не надо? Все попытки государства сделать "безопасный интернет" никогда ни к чему хорошему не приводили.
Возможно всё несколько проще, и был скомпрометирован один из ns для домена. Вот показания и расходятся.
я соглашусь с тем, что наличие НСДИ и нарушенная работа перечисленных провайдеров - не означает, что это НСДИ. Может эти провайдеры брали DNS из одного места? Может они партнёры какие и пользовались быстрым "кэшем нс-записей" или типа того
п.с. А безопасный интернет делать не надо - он уже спроектирован безопасным, потому выжил и развился до таких масштабов
Тут у меня два вопроса-подозрения:
А есть ли (и вообще, возможны ли) эффективные и удобные децентрализованные решения? Вроде в тор подобная децентрализованная система, но там уродские доменные имена, которые невозможно запомнить.
А есть ли реальная проблема? Теоретически - даже в Сахаре не помешает страховка от наводнения, да. Ну мало ли. Но вот стоит ли она того, чтобы за нее платить хотя бы копейку - это уже вопрос. Мне кажется, имеющаяся DNS система (основанная на доверии к авторитету) пока что блестяще себя зарекомендовала и реальных угроз не было (может я что-то не знаю? дайте ссылку?). Именно ее безупречная репутация и есть причина того, что ею пользуются, а все альтернативы не взлетают, в первую очередь по причине своей бессмысленности и невостребованности.
Ну и даже если что-то подобное и свершится, вы же представляете как технически просто "переориентировать" DNS с имеющихся корневых серверов (которые не будут пользоваться доверием) на те, что пользуются доверием. Все дело только в доверии и репутации.
Особенно автора статьи удивило то, что никто этого и не заметил, а кто заметил предложил об этом умолчать.Думаю, и правда никто не заметил. Те же дефейсы абсолютно незаметны, и быстро устраняются.
Технология, как это может быть сделано, описана здесь: https://habr.com/ru/post/321150/
Это вполне может быть успешной атакой на резолвер НСДИ, в частности если схема работы в части кеширующего рекурсивного сервиса построена на иерархии: несколько резолверов и кучка форвардинг кешей, которые в них смотрят.
В теории это может быть и компроментация одного из авторитетных серверов на которых делегирован домен smotrim.ru. Внутри РФ задержка до обоих авторитетных серверов этого домена одинакова и маловероятно, что DNS кеши указанных провайдеров обращались только к одному из них. Гораздо более вероятно, что эти провайдеры в регионах, где они пострадали, все рекурсивные запросы отправляют в НСДИ.
Так, стоп, погодите со своей НСДИ
У атакующих был ВАЛИДНЫЙ ВГТРКшный SSL сертификат с закрытым ключем от ВАЛИДНОГО УЦ?
При наличии доступа к домену сделать сертификат совсем несложно. Через тот же let's encrypt.
Сертификат и сейчас там, по украинскому ip-адресу из топика. Выпущен больше года назад через Thawte. В аутентичности сомневаться не приходится.
testssl.sh
$ ./testssl.sh -S https://45.134.174.108/
###########################################################
testssl.sh 3.1dev from https://testssl.sh/dev/
(730c758 2022-08-02 13:28:56)
This program is free software. Distribution and
modification under GPLv2 permitted.
USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!
Please file bugs @ https://testssl.sh/bugs/
###########################################################
Using "OpenSSL 3.0.3 3 May 2022 (Library: OpenSSL 3.0.3 3 May 2022)" [~94 ciphers]
on /usr/bin/openssl
(built: "Jun 13 20:16:39 2022", platform: "debian-amd64")
Start 2022-08-04 22:38:27 -->> 45.134.174.108:443 (45.134.174.108) <<--
rDNS (45.134.174.108): dedicated.vsys.host.
Service detected: HTTP
Testing server defaults (Server Hello)
TLS extensions (standard) "renegotiation info/#65281" "EC point formats/#11" "session ticket/#35" "next protocol/#13172" "supported versions/#43"
"key share/#51" "max fragment length/#1" "application layer protocol negotiation/#16" "encrypt-then-mac/#22"
"extended master secret/#23"
Session Ticket RFC 5077 hint 300 seconds, session tickets keys seems to be rotated < daily
SSL Session ID support yes
Session Resumption Tickets: yes, ID: no
TLS clock skew Random values, no fingerprinting possible
Certificate Compression none
Client Authentication none
Signature Algorithm SHA256 with RSA
Server key size RSA 2048 bits (exponent is 65537)
Server key usage Digital Signature, Key Encipherment
Server extended key usage TLS Web Server Authentication, TLS Web Client Authentication
Serial 08E2BD0E19C7328D1E3613E1EC41562B (OK: length 16)
Fingerprints SHA1 5F4F89BE5AC82CDD669B0541936A21A7F00300DF
SHA256 11A6747AF43C7EE2AF708CC4BD68B54407DD691B27A6D3A7B8223CC7CE97070E
Common Name (CN) *.vgtrk.com
subjectAltName (SAN) *.vgtrk.com vgtrk.com
Trust (hostname) certificate does not match supplied URI
Chain of trust Ok
EV cert (experimental) no
Certificate Validity (UTC) expires < 30 days (8) (2021-07-12 00:00 --> 2022-08-12 23:59)
ETS/"eTLS", visibility info not present
Certificate Revocation List http://cdp.thawte.com/ThawteRSACA2018.crl
OCSP URI http://status.thawte.com
OCSP stapling not offered
OCSP must staple extension --
DNS CAA RR (experimental) not offered
Certificate Transparency yes (certificate extension)
Certificates provided 2
Issuer Thawte RSA CA 2018 (DigiCert Inc from US)
Intermediate cert validity #1: ok > 40 days (2027-11-06 12:23). Thawte RSA CA 2018 <-- DigiCert Global Root CA
Intermediate Bad OCSP (exp.) Ok
Done 2022-08-04 22:38:41 [ 15s] -->> 45.134.174.108:443 (45.134.174.108) <<--зы. Уже после публикации комментария заметил, что серт валиден для *.vgtrk.com, а не .ru, как писал топикстартер. Но, по большому счету, это сути не меняет - владелец домена тот же. Доступ к ключу у злоумышленника был.
Кстати, ВГТРК потрудилась перевыпустить сертификат в другом ЦС (GlobalSign), но отзывать скомпрометированный сертификат в Thawte, видимо, санкции не позволяют: https://crt.sh/?pv=4897009821
Этих ”валидных УЦ” – хоть обсертифицируйся.
Скорее всего у регистратора, днс серверы другие прописали . По всему интернету не успели записи уйти
В руках атакующих оказался валидный wildcard сертификат, но от *[.]vgtrk[.]ru. А к smotrim[.]ru он не подходил.
То есть, они подставили настоящий сертификат от другого сайта? но зачем?!
Лол. Сегодня заходил на гисметео чекнуть погоду. Но и там меня решили соскамить - адрес сайта выглядел как gismeteo[.]md
Как владельцу домена защититься от таких атак? DNSSEC помог бы в этом случае?
А проверить ответ от DNS серверов, которые за домен отвечают, почему не додумались?
Неистово плюсую за интересное расследование. [Если бы была бы карма. =-( ]
Национальная система DNS-спуффинга