Работают ли SPF, DKIM и DMARC?
Появилась вчера на Хабре такая вот статья. Когда компания, занимающаяся ИТ-безопасностью заявляет, что spf/dkim/dmarc не работают и существует минимум 18 способов подменить адрес на (вашем!) почтовом сервере, это вызывает озабоченность и желание разобраться в вопросе. Я прочитал оригинальную статью и кратко изложил свое понимание вопроса. Если тема для вас актуальна рекомендую непременно прочитать оригинал.
Основная идея статьи в том, что любая современная система состоит из компонентов, и проблемы чаще всего возникают при их взаимодействии. Всего описано 18 проблем разбитых примерно на 6 категорий, а техники обозначены A1-A18.
Путаница с адресом в helo/mail from
В протоколе smtp адрес отправителя используется в двух командах helo и mail from. Требования к SPF (RFC 7208) гласят, что проверка значения из mail from обязательна, из helo — рекомендуется. Требования к DMARC (RFC 4789) гласит что проверка должна выполняться по значению из mail from, а если значение пустое, то нужно взят значение из helo. В некоторых случаях это может привести к тому, что spf и dmarc будут проверять разные значения.
А1 — несуществующие поддомены. Если указать несуществующий поддомен существующего домена в mail from, то SPF вернет пустое значение. Некоторые реализации SPF не выполняют проверку домена, а сразу берет значение из helo, где злоумышленник может указать нужное ему значение. Но некоторые реализации DMARC все равно используют значение из mail from и могут вернуть положительный результат при проверке домена отправителя.
А2 — «пустой» адрес в mail from. Скобки в почтовом адресе могут использоваться как комментарии (RFC 5322). И некоторые реализации SPF ошибочно трактуют адрес (any@legitimate.com (непарная левая круглая скобка использована умышленно) как пустой. Но некоторые реализации DMARC считают это корректным адресом и используют для проверки.
Неправильная интерпретация доменного имени
А3 — NULL-неоднозначность. Для обхода проверки dkim используется символ 0×00 в доменном имени, который считается концом строки в некоторых языках, а в некоторых не считается. Для эксплуатации ошибки в подписи dkim в качестве домена отправителя используется, например, legitimate.com, а в качестве адреса для получения публичного ключа используется attacker.com.\x00.anything. Если dkim сочтет такой адрес корректным, то для получения публичного ключа будет запрошен dns-адрес attack.com.\x00.any._domainkey.legitimate.com. DNS сервер интерпретирует 0×00 как конец строки и вернет результат для attack.com. Данная ошибка была обнаружена на gmail.com и уже исправлена.
Ошибки при разборе заголовков аутентификации
Использование символов » (@ в адресе может приводить к его ошибочному разбору и неверным результатам проверки.
А4 — атакующий использует в dkim подписи адрес legitimate.com(.attacker.com, а в качестве адреса получателя admin@legitimate.com. Если на сервере получателя домен в dkim-подписи распарсится неверно (т. е. до скобки, т. к. текст в скобках является комментарием, согласно RFC), то адрес отправителя будет признан верным
А5 — атакующий использует в качестве адреса получателя адрес legitimate.com(.attacker.com или any@legitimate.com’@a.attacker.com, подобные адреса получателя могут быть по-разному интерпретированы smtp сервером и при проверке .spf и dmarc. SPF использует legitimate.com(.attacker.com или legitimate.com@a.attack.com, DMARC — egitimate.com.
Авторы статьи приводят список серверов на которых удалось эксплуатировать описанные уязвимости.
Ошибки несоответствия интерфейсов
Самый богатый на ошибки раздел, описано шесть ошибок в трёх категориях.
Неправильная интерпретация заголовка from.
А6 — Использование нескольких заголовков from. RFC требует наличие ровно одного заголовка, но разное ПО может использовать либо первый, либо последний заголовок.
A7 — Использование пробелов в поле from. Противоречит RFC, но разное ПО обрабатывает ситуацию по-разному.
А8 — использование альтернативных заголовков. Некоторое ПО при отсутствии или ошибочном заголовке from может использовать схожие по назначению заголовки, например sender или recent-from.
Неправильная интерпретация адреса.
Поле адреса в заголовке From может иметь достаточно сложный синтаксис, и извлечение действительного адреса непростая задача, которую разное ПО решает по-разному. В частности, адрес может состоять из отображаемого имени, строки с указанием маршрута, собственно адреса и комментариев.
Примеры корректных заголовков: From: "a@a.com” <@b.com, @c.com:d@d.com> (e@e.com) From: Pete(A nice \) chap)
Информация о маршруте была определена в RFC 822, в настоящее время признана устаревшей. RFC 5322 запрещает генерировать это поле, но требует правивльно его обрабатывать.
Кроме того, в заголовке from может быть указан список адресов авторов, и тогда требуется заголовок sender. Некоторые символы (запятые и кавычки) интерпретируются специальным образом, и при использовании в качестве обычных символов перед ними необходимо ставить обратный слэш. Кроме того символы non-ascii могут быть закодированы в quoted-printable или base64.
В статье приведены примеры, как разное ПО по-разному извлекает адрес из заголовка from и описаны 5 типов (A9-A13) атак построенных на этом. Наглядные изображения атак и ошибок отображения адресов приведены на картинках ниже.
Ошибки отображения адресов на серверах и почтовых клиентах. Tutanota и Protonmail имеют только веб-интерфейс.
Spoofing писем с корректными dkim подписями
Если атакующий имеет письмо с корректными dkim подписями, в некоторых случаях возможна подмена заголовков или содержимого письма при его пересылке.
А14. Добавление заголовков, которые не защищены dkim. RFC описывает 19 заголовков, которые следует защищать, но, к примеру Citibank защищает только заголовки from и subject, American Express — from и reply-to. В случае Gmail атакующий может скрыть тело своего сообщения установив заголовок Content-Disposition: attachment;filename=ticket.jpg
Пример пересылки письма American Airlines получателю Gmail. Тема письма подделана, а тело скрыто во вложение.
А15. Добавление дублирующих заголовков (from, subject, content-type). DKIM защищает подписью только последний заголовок, но 9 из 19 почтовых программ используют первый.
А16. Подмена тела письма. DKIM подпись может указывать длинну подписываемого сообщения. Это используется, например, в Google Groups: к подписанному сообщению может быть добавлена информация о возможности отписаться и при этом подпись останется корректной. Аналогичным образом, атакующий может добавить вредоносные данные в конец письма, сохранив корректность подписи. Кроме того, если не защищен заголовок content-type, атакующий может изменить структуру письма так, чтобы отображалось вредоносное содержимое.
Пример использования незащищенных заголовков. Получатель на Gmail увидит корректную подпись discover.com
A17. При наличии учетной записи на сервере атакующий может авторизоваться под своей учетной записью, но в заголовке from указать другого пользователя (например, admin). Некоторые почтовые сервера не выполняют проверку и позволяют подобные действия.
А18. Двух-ходовая схема. Атакующий отправляет письмо себе указывая корректный заголовок from, получает письмо с корректной подписью dkim, добавляет второй заголовок from и отправляет жертве. В некоторых случаях возможна ситуация, при которой подпись будет проверена и подтверждена для первого заголовка, но в почтовой программе отобразится второй.
В статье также предложены методы по защите от подобного рода атак (кратко — rtfm, как обычно).
Авторы уведомили CERT/CC и всех вендоров о найденных проблемах и получили позитивную реакцию (Gmail, Zoho, Protonmail и Mail.ru выплатили вознаграждение за каждую из найденных уязвимостей) ото всех кроме Microsof и Yahoo. Microsoft расценил проблему, как относящуюся к социальной инженерии и не имеющей отношения к проблемам ПО. Yahoo ответил что ошибка состоит в настройке DNS авторов.
Спасибо GlobalSign за мотивацию прочитать оригинальную статью.
