Возможна ли подмена заголовков электронного письма при настроенных SPF, DKIM, DMARC записях?

Question

[itshnick88]

Здравствуйте. На днях ко мне попало вот такое письмо от ФСТЭК России (в прикреплённой картинке - о ней и пойдёт речь далее). В письме, среди прочего, говорится о том, что некой хакерской группировкой осуществляется фишинговая рассылка электронных писем с домена самого ФСТЭК. Сначала я смутился... признаюсь честно, до этого я думал, что основной вектор подобной атаки заключается в том, чтобы максимально точно мимикрировать под домен организации, например, вместо fstec.ru зарегистрировать fstek.ru или fstec.gov.ru, но здесь - точное совпадение домена. Я решил погрузиться в чтение по данной проблематике и выяснил, что из-за несовершенства SMTP существует возможность подмены заголовков отправляемого пакета, как раз с целью проведения такой атаки. Но эта атака далеко не нова, поэтому, для защиты от подобного рода атак давно придумали такие ресурсные DNS записи, как: SPF, DKIM, DMARC.

Сейчас эти записи для домена fstec.ru существуют, НО... существовали ли они ДО рассылки этого письма? Скажем, по состоянию на 1 января 2025 года? Или до 2025 года они эти записи не настраивали? Каким образом стала возможна рассылка фишинговых писем от [e-mail]? У меня 3 основных вопроса:
1) Возможна ли подобная атака при существовании SPF, DKIM, DMARC записей?;
2) Если она невозможна (наличие корректно настроенных ресурсных записей исключает подобный вектор атаки), то для чего это письмо? Почему нужно точечно блокировать некоего [e-mail]?
3) Неужели у домена fstec.ru до сих пор отсутствовали ресурсные записи для защиты от фишинга почты?

Уважаемые эксперты, поделитесь, пожалуйста, знаниями по проблематике. Какой практический смысл от данного письма, кроме как лишний раз обратить внимание и перепроверить СВОИ ресурсные записи.

Answer 1

[RoundRobin]

Они пользуются почтовым хостингм стороннего провайдера (популярный российский хостер). В SPF указано значение соответствующее почтовым серверам этого провайдера.
Злоумышленник может легко обойти проверку SFP, отправив письмо с хостинга этого провайдера. IP-адрес сервера отправителя в этом случае будет "легитимный" из этого списка.

Что касается DMARC к сожалению, это не панацея, по описанным в комментариях выше причинам.

А отсутствие DKIM (самого по себе, без DMARC) не спасет. Возможно несколько повлияет на скоринг, но жесткого реджекта в подавляющем большинстве случаев на стороне получателя не будет.

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

Comments

[itshnick88]

То, что они на ник.ру, это я, конечно, глянул, но то, что можно этим воспользоваться, мне как-то в голову не пришло... мысль интересная. Тогда, получается, эта "уязвимость" SPF записи актуальна для всех, кто пользуется SaaS почтовыми серверами. Во дела

[RoundRobin]

itshnick88, конечно же хостеры на своих SaaS почтовых сервисах должны во-первых, аутентифицировать отправителя при отправке через SMTP, во-вторых, иметь отдельные блоки IP-адресов, с которых отправляется почта с хостинг-серверов например через PHP mail() и иметь для них отдельные SPF-записи. Либо разрешать отправку только через SMTP. Но на практике, это делеко не всегда так. И есть еще множество не столь очевидных подводных камней по этой теме.

Answer 2

[Василий Банников]

Некоторые организации могут использовать устаревшее ПО, которое не проверяет SPF, DKIM, DMARC

Comments

[itshnick88]

А есть примеры такого ПО? Проверка осуществляется не на почтовом сервере получателя? Сейчас есть почтовые серверы, которые не знают об этих ресурсных записях?

В таком случае... можно рассылать письма не от [e-mail], а напрямую от [e-mail] и в следующей рассылке ФСТЕК попросит заблокировать и его? И больше нельзя будет получить электронное письмо от легитимного [e-mail]? И всё это, вместо рекомендаций не использовать почтовые серверы 20-ти летней давности?

Мы так и будем блокировать [e-mail], [e-mail], ... [e-mail] и заблокируем весь домен (и ещё чёрт знает сколько других доменов) вместо того, чтобы разослать письмо не с просьбой блокировки конкретный ящиков, а о переходе на защищённые почтовые серверы без уязвимостей? Это нормально?)

[Василий Банников]

itshnick88,

А есть примеры такого ПО?

А я хз, что за древнее говно может использоваться в каких-то региональных госучреждениях)

А postin, судя по названию, предназначен только для получения почты и рассылки с него не ведут.

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

Добавить адрес в банлист гораздо легче и быстрее, чем обновлять древнюю инфраструктуру, когда у тебя в штате нет никого, кто мог бы этим заняться.

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

[itshnick88]

Василий Банников, Ну то есть, такими темпами, каждую неделю будет приходить письмо с просьбой заблокировать очередной почтовый ящик на домене fstec.ru пока не перебранят весь домен. И тогда будет дело с концом)
Неплохое решение проблемы

[Евгений Хлебников]

itshnick88, не, до вайтлиста додумаются

[Василий Банников]

itshnick88, ну я не работаю во фстэк, но видимо, логика у них именно такая)

[Владимир Дубровин]

SPF и DKIM сами по себе не защищают от подделки адреса отправителя, который видит пользователь, нужен DMARC (а ему нужны SPF и DKIM).

Microsoft Exchange (который onpremise) не поддерживает DMARC совсем (и DKIM тоже).
В остальных онпремис-решениях, в т.ч. опенсорсных как правило необходимо дополнительно настраивать/включать реджект писем по DMARC, по умолчанию письма будут приниматься.

Антиспам типа Касперского тоже умеет DMARC, но жесткого реджекта по DMARC там так же нет по умолчанию, надо настраивать.

Отсюда, поскольку большая часть администраторов которые не специализируются на почте ничего не знают про DMARC - можно считать что в онпремис-решениях он отсутствует, хоть в устаревших, хоть не в устаревших.

[Василий Банников]

Владимир Дубровин, А есть какая-то причина, почему dmarc не проверяется даже в актуальных onpremise решениях? Там техническое ограничение или просто все хотят клиентов в онлайн сервисы тащить?
Я просто как раз из тех, кто не админ и тем более не специализирующийся на почте.

[Владимир Дубровин]

Microsoft скорей всего не смог реализовать нормальный DKIM/DMARC из-за того, что внутри Exchange у письма могут нормализоваться заголовки, что делает DKIM подпись невалидной, к этой проблеме делали много подходов, но она так и не ушла.
Остальные решения это всегда более-менее конструкторы, письмо может проходить через несколько узлов, его содержимое может меняться разными фильтрами/антивирусами/DLP, может быть какой-то трафик между филиалами или смежными почтовыми системами и тп - правильно внедрить SPF/DKIM/DMARC можно только зная полную конфигурацию

[Александр Фалалеев]

Василий Банников, Даже в rfc почтового протокола чёрным по белому написано что если пришёл запрос даже без tls, то ... его надо ПРИНЯТЬ :)

Что уж говорить про DKIM/DMARC и т.д.

Так то всё уже всё придумано: домен под DNSSEC , записи TLSA/DANE на почтовые порты завязанные на сертификат tls , тот же exim умеет это всё проверять, но ... если включить эту проверку Вам ни одно письмо доходить не будет :) Ибо доменов под dnssec меньше процента, а уж с dane на почтовые порты вообще единицы в мире :)