Эволюция Email спуфинга

Что такое SPF, DKIM, DMARC?

Все эти 3 политики работают вместе с общей целью — аутентифицировать Email письма и предотвратить спуфинг, фишинг и другие атаки с подменой личности.

SPF (Sender Policy Framework)

Данная политика позволяет владельцу домена указать какие Email сервера могут отправлять почту от лица этого домена. Когда почта приходит, принимающий сервер проверяет SPF запись для подтверждения легитимности отправителя.

Выглядит следующим образом (DNS TXT запись):

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all

• v=spf1 - версия SPF
• Список IP адресов или доменов с которых может поступать почта
• Политика завершется опциями: ~all (soft fail) или -all (hard fail) или +all (не рекомендуется).

DKIM (DomainKeys Identified Mail)

Данная запись добавляет цифровую подпись в заголовки Email используя криптографические ключи. Отправляющий сервер подписывает исходящую почту с приватным ключом, а получающие сервера верифицируют подпись используя публичный ключ в DNS записи.

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

TXT DNS запись для DKIM выглядит следующим образом (где p = публичный ключ):

default._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Для работы данного метода необходимо сгенерировать пару публичный/приватный ключ и настроить на сервере отправителе подпись писем.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

Данная запись основывается на предыдущих двух записях - SPF и DKIM. Предназначена для оповещения серверов-получателей писем в тех случаях, когда аутентификация не удалась и содержит инструкции куда отправлять отчет о неудачных попытках аутентификации.

• Указывает политику при неудачной аутентификации (карантин, отклонение или бездействие)
• Позволяет увидеть кто пытается отправлять письма с домена владельца
• Предотвращает подделку домена в поле "От" который видят пользователи
• Гибкая настройка позволяет укреплять политику постепенно

TXT DNS запись для DMARC выглядит следующим образом:

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100; adkim=s; aspf=s

• p=устанавливает политику: none (мониторинг), quarantine (спам) или reject (отклонение)
• rua= указывает куда отправлять отчеты
• pct= к какому проценту писем применять политику
• adkim= и aspf= указывают на режим работы по существующим записям (strict или relaxed)

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

Использование в современных атаках

Несмотря на то, что многие не отдают особого внимания данным записям, за последние 2 года происходили крупные атаки которые в том или ином объеме использовали слабости в проверках отправляемой почты.

В недавнем исследовании PayPal в 2024 году были обнаружены недостатки которые позволяли атакующим воспользоваться SMTP Smuggling атаками для обхода SPF, DKIM и DMARC политик в результате использования очень мягких правил в SPF записях.

Массовая компроментация бизнес Email через использование очень похожих доменов позволила хакерам обойти проверки DMARC, что привело к потере $2.3 миллионов.

Заключение

В Метаскан поддерживается проверка SPF записей в автоматическом режиме на любом объеме ресурсов с градацией по критичности. При наличии MX записи, но отсутствующей SPF записи, будет создана сработка со средним уровнем критичности предупреждая о наличии мисконфигурации. Подобные ошибки могут привести к успешной фишинговой кампании, которая может закончится пошифрованной инфраструктурой и большими потерями для бизнеса.