Мошенникам даже не нужно ничего взламывать: я проверил 284 крупных сайта Рунета

Почти любой взлом компании, о котором потом пишут в новостях, начинается не с хитрой атаки, а с какой‑нибудь ерунды. Забыли настроить почту. Не обновляли библиотеку на сайте лет десять. Удалили сервер, а запись в DNS оставили. Ломать ничего не надо: дверь уже открыта, нужно только её найти.

В прошлой статье я проверил 50 сайтов на зависимость от иностранных сервисов. С тех пор утилита научилась проверять почту, 152-ФЗ и безопасность, и я решил посмотреть шире: прогнал через неё 284 сайта крупных российских компаний. Банки, магазины, вузы, клиники, застройщики, медиа, госсайты.

Спойлер: у каждого четвёртого сайта можно отправить письмо от имени компании так, что оно придёт во «Входящие». У каждого четвёртого на страницах висят библиотеки с известными уязвимостями. Половина сайтов отдаёт ваш IP иностранным сервисам, как только вы открыли страницу, хотя в политике у многих написано, что ничего никуда не передаётся. А госсайты, на которые я рассчитывал как на пример строгости, оказались не лучше остальных.

Названия компаний, как и в прошлый раз, приводить не буду. Проверка автоматическая и может ошибаться, и цель не в том, чтобы кого‑то пристыдить.

Зачем это вообще кому‑то нужно

Если вы владелец сайта, то самый понятный аргумент — штрафы. Почти всё, что нашлось по 152-ФЗ, ложится на конкретные статьи КоАП. Для юрлица выходит примерно так:

Если вы посетитель, то вас это касается ещё сильнее, просто вы об этом не знаете. Поддельное письмо от вашего банка с его настоящим адресом, фальшивая страница на настоящем поддомене магазина, перехваченный вход в личный кабинет через Wi‑Fi в кафе. Пострадает не компания, а вы.

И что обидно, почти ничего из этого не стоит денег. Большинство проблем закрывается одной строчкой в DNS или в конфиге nginx. Их просто никто не ищет: проверять всё руками долго и скучно.

Письмо «от банка», которое отправил не банк

Начну с почты, потому что это касается вообще всех.

Когда вам приходит письмо от support@bank.ru, почтовый сервис понятия не имеет, правда ли его отправил банк. Поэтому он идёт в DNS банка и смотрит две записи. SPF говорит, каким серверам можно отправлять почту от имени домена. DMARC говорит, что делать, если письмо пришло с чужого сервера: пропустить, положить в спам или выкинуть.

Вот так выглядит ответ, при котором подделка проходит:

$ dig +short TXT _dmarc.example.ru
"v=DMARC1; p=none; rua=mailto:dmarc@example.ru"

p=none означает «ничего не делай, просто пришли мне отчёт». Его ставят, пока настраивают почту, чтобы случайно не порезать свои же рассылки. А потом про него забывают. В итоге письмо от мошенника с адресом director@example.ru спокойно доходит до получателя, и ни Яндекс, ни Gmail его ничем не помечают.

Из 284 доменов записи удалось прочитать у 275. Получилось так:

То есть у 66 доменов (24%) подделка проходит без вопросов. Ещё у 125 частично: письмо уйдёт в спам (где его кто‑нибудь всё равно откроет), либо основной домен закрыт, а поддомены нет. Последнее, кстати, встретилось у 42 доменов: у них в записи стоит sp=none, и письмо от example.ru отклонят, а от noreply@mail.example.ru пропустят. Нормально защищена меньше трети.

Хуже всего с этим у вузов, 26 из 28. Представьте письмо «от деканата» с «новым расписанием» в начале сентября. Банки и медиа выглядят получше, но и у них проблема примерно у каждого второго.

Свой банк можно проверить прямо сейчас, это секунд десять. В Windows:

nslookup -type=TXT _dmarc.имя-банка.ru

В Linux и macOS: dig +short TXT _dmarc.имя-банка.ru. Смотрите на p=. Если там reject, всё хорошо. quarantine терпимо. А если none или ответа нет вообще, письмо от имени этого банка может прислать кто угодно, и смотреть на адрес отправителя бессмысленно.

jQuery 2013 года и готовые эксплойты

Страницы удалось прочитать у 170 сайтов (остальные встречают робота заглушкой «подтвердите, что вы не робот»). У 24% из них подключены старые версии JavaScript‑библиотек с известными уязвимостями. Чемпион, конечно, jQuery: версии 1.10, 1.11, 1.12 и 2.2, то есть 2013–2016 годы.

Почему это не мелочь. У каждой такой уязвимости есть публичное описание, а часто и готовый пример атаки. Искать дыру не нужно, она уже описана в базе CVE. Насколько опасно на конкретном сайте, зависит от того, как библиотеку используют, поэтому утилита пишет «возможно уязвимы», а не «взломан». Но если библиотеку не трогали десять лет, за сайтом, скорее всего, вообще никто не следит.

Забавный момент: на 11 сайтах утилита нашла в коде ключи Google API. Выглядит как утечка, но это не она. Такие ключи по задумке лежат в открытом виде и ограничиваются настройками на стороне Google. Утилита так и пишет и в проблемы их не записывает. Мне было важно, чтобы она не пугала там, где пугаться нечего.

Поддомены в никуда

Эта находка мне понравилась больше всего, хотя случаев немного.

Типичная история: компания когда‑то подняла блог на blog.example.ru в облаке. Проект закрыли, сервер удалили, а запись в DNS никто не убрал. Поддомен теперь смотрит на облачный адрес, который никому не принадлежит. Если кто‑то займёт этот адрес или создаст в облаке проект с тем же именем, его страница откроется по адресу компании. Со всеми вытекающими для фишинга.

Нашлось пять таких поддоменов. Четыре смотрят на пустые адреса в AWS и DigitalOcean. Пятый ведёт в облачное хранилище, которое отвечает, что такого проекта у него нет, и принадлежит он финансовой компании. Сам я, разумеется, ничего занимать не пробовал, утилита только смотрит снаружи и пишет «возможен захват, проверьте вручную».

Перехват по дороге

Тут всё скучно, но массово.

У 57% сайтов нет HSTS. Это заголовок, который говорит браузеру «ко мне только по HTTPS». Без него первый заход по старой ссылке http:// уходит открытым, и в публичном Wi‑Fi его можно подменить.

31% серверов до сих пор соглашаются на TLS 1.0 и 1.1, которые стандарт запретил ещё в 2021 году. Браузеры по ним уже не ходят, но сам факт значит, что конфиг не трогали очень давно.

У 12 сайтов сертификат кончается в ближайшие две недели. Может, автопродление сработает в последний день. А может, однажды утром сайт откроется с красным экраном.

И политика безопасности контента (CSP), которая мешает чужому скрипту утащить данные из формы оплаты, нормально настроена у двух сайтов из 184. Двух.

Ваш IP уходит раньше, чем вы что‑то нажали

Если открыть главную среднего сайта из выборки, ваш браузер тут же отдаёт IP‑адрес, а часто и cookies, пяти сторонним сервисам. У 19 сайтов таких сервисов десять и больше, у рекордсмена 27. Большинство российские: Метрика, VK, рекламные сети. Но у 51% сайтов среди них есть иностранные, и чаще всего это Google Analytics.

С 1 марта 2023 года о трансграничной передаче персональных данных нужно уведомлять Роскомнадзор заранее. IP и cookies, которые ушли в Google, это она самая.

Самое интересное началось, когда я научил утилиту сравнивать политику конфиденциальности с тем, что на сайте реально происходит. Расхождение нашлось у 31% сайтов. Пара цитат (без названий):

«Компания не осуществляет трансграничную передачу данных, обрабатываемых с использованием Сайта, Мобильного приложения, Мессенджеров»

На этом сайте стоит Google Analytics.

«Данные не передаются третьим лицам»

А на странице Meta Pixel, рекламная сеть и ещё несколько счётчиков.

Я не думаю, что кто‑то врёт нарочно. Политику пишет юрист по шаблону, счётчики ставит маркетолог, и между собой они, похоже, не разговаривают. Но объяснять это Роскомнадзору будет неприятно.

Один рубильник на всех

Тема прошлой статьи тоже никуда не делась. Серверы за границей остались всего у четырёх сайтов из 284, тут крупный бизнес молодец. Но иностранный сертификат у 74% (GlobalSign у 126, Let's Encrypt у 72), почта в Google Workspace у 20, DNS в Cloudflare у 13. Если кто‑то из этих провайдеров завтра решит отключить российских клиентов, у компании разом встанет почта или сайт.

С блокировками отдельная ирония. Шесть сайтов подключают у себя домены из реестра блокировок, в основном виджеты Facebook, и у посетителей без VPN эти куски страницы просто не грузятся. А у восьми сайтов IP оказался в реестре из‑за соседа по хостингу или CDN.

Ещё на 13 сайтах есть ссылки на Instagram и Facebook без пометки, что Meta признана в России экстремистской организацией. Практика по таким ссылкам пока мутная, поэтому утилита пишет «внимание», а не «нарушение».

Госсайты

Честно, я ждал, что тут будет строже всего. Не угадал. Из 18 доменов почту можно подделать (полностью или частично) у 10. Из 14 сайтов, где удалось прочитать заголовки, нормальной CSP нет ни у одного, защитных заголовков не хватает у восьми, HSTS у половины. Три сервера ещё принимают TLS 1.0. Справедливости ради, с иностранными сервисами у госсайтов полный порядок: Google Analytics нашёлся только у одного.

Что с этим делать

Почти всё чинится за вечер.

С почтой главное не ставить сразу p=reject, иначе можно отрезать собственные рассылки. Нормальный путь такой: сначала p=none с отчётами, неделю смотрите, кто отправляет письма от вашего имени, добавляете эти сервисы в SPF, потом переходите на p=quarantine и в конце на p=reject. И не забудьте про поддомены:

_dmarc.example.ru.  TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.ru"

HSTS и старый TLS в nginx закрываются двумя строчками:

ssl_protocols TLSv1.2 TLSv1.3;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Поддомены стоит раз в полгода пролистать и удалить всё, что ведёт на закрытые проекты. Список поддоменов, которые видит весь интернет, лежит в журналах сертификатов на crt.sh. jQuery и прочее из времён первой версии сайта пора обновить. А с Google Analytics решение простое: либо уведомить Роскомнадзор и написать о передаче в политике, либо убрать счётчик. Его часто ставили давно и благополучно забыли.

Почему этой утилите можно доверять

Понимаю скепсис: очередной сканер от одного человека. Поэтому пару слов о том, как он устроен.

Каждая проверка сделана по стандарту, а не по ощущениям. Почта по RFC 7208 (SPF), 7489 (DMARC) и 8461 (MTA‑STS), TLS по RFC 8996, заголовки по OWASP Secure Headers, 152-ФЗ по тексту закона и КоАП. И у каждого вывода в отчёте лежит доказательство: DNS‑запись, заголовок ответа, адрес скрипта, цитата из политики. Всё можно перепроверить руками, если не верите.

У проверок постоянные ID, как в нормальных сканерах (SUV-MAIL-003 это всегда DMARC), чтобы находку можно было отслеживать и сравнивать между прогонами. Тестов больше тысячи, и ни один не ходит в сеть. Есть ещё полигон из 158 синтетических сайтов с заранее известным правильным ответом: если какая‑то проверка начинает отвечать иначе, сборка падает. А каждую ночь утилита сама прогоняет те же 297 реальных сайтов и разбирает, что изменилось: сайты или её собственный код.

Отчёт выдаётся в HTML, PDF и Word, есть сводка на одну страницу для руководителя, SARIF для GitHub, GitLab и DefectDojo, коды выхода для CI. Можно воткнуть проверку в конвейер и не выпускать релиз, если на сайте появилась новая дыра.

Сама утилита тоже не дырявая. Сайты она открывает в браузере с песочницей и без доступа к вашей локальной сети. Код открыт под AGPL. Exe собирается в GitHub Actions, подписан через Sigstore, к нему лежат SBOM и контрольные суммы, и проверить, что он собран именно из этого кода, можно командой gh attestation verify.

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

Где я сам наступил на грабли

Пара историй из этого исследования, потому что гладко ничего не прошло.

Первая сводка, которую выдала моя же утилита, сообщила, что фишинг от имени компании возможен у 100% сайтов. Для заголовка было бы бомбически, но это неправда. Доля считалась только среди сайтов, где сценарий нашёлся, а не среди всех. Так что все цифры в статье я пересчитал вручную из сырых отчётов.

Дальше прогон упал на первой же минуте. Сайты проверялись по четыре одновременно, и всем четырём сразу понадобился реестр блокировок. Они бросились скачивать его в один и тот же временный файл, и Windows не дал второму процессу его тронуть. На Linux я бы этого, скорее всего, вообще не заметил. Теперь файл качается один раз, а остальные ждут.

Ещё одна: проверка компаний по перечню Росфинмониторинга на fedsfm.ru у меня всегда отвечала «не удалось установить защищённое соединение». Я долго думал, что сайт лежит. А у него просто сертификат Минцифры, которому не доверяет ни Windows, ни Python, да ещё и без промежуточного сертификата. Пришлось положить сертификаты Минцифры в утилиту и доверять им только для этого одного сайта, а не для всего интернета.

И спасибо комментаторам прошлой статьи. Мне подсказали базу IP2Location, и это было в точку: страну сервиса утилита определяла по владельцу сети, а для 152-ФЗ важно, где сервер стоит физически. Теперь она смотрит ещё и открытую базу DB‑IP.

Ограничения

Проверялись главная и несколько внутренних страниц, без браузера, так что всё, что дорисовывает JavaScript, могло пройти мимо. Страницы прочитаны у 170 сайтов из 284, и всё про 152-ФЗ, скрипты и библиотеки посчитано только по ним; «не проверено» я нигде не смешивал ни с «хорошо», ни с «плохо». Часть прогона шла через зарубежный канал. Почту, DNS и сертификаты это не трогает, а вот страницы части банков и госсайтов из‑за границы не открываются. Ну и 152-ФЗ утилита проверяет по признакам на страницах, юриста она не заменяет.

Попробовать

Код открыт: https://github.com/marsilid/suveren

Для Windows в Releases лежит готовый Suveren.exe, двойной клик открывает меню. На других системах:

pip install "suveren[browser]"
suveren scan example.ru --browser

Отчёт покажет по вашему сайту всё то же самое: можно ли подделать почту, какие библиотеки устарели, нет ли брошенных поддоменов, куда уходят данные посетителей и что чинить первым.

Если утилита на вашем сайте ошиблась, напишите в комментариях. Одна из новых проверок появилась как раз из комментария к прошлой статье.