Атаки на понижение версии SMTP и MTA-STS

В этой статье я провожу аудит нескольких известных почтовых провайдеров, чтобы узнать, как они обрабатывают шифрование электронной почты, и показываю, как MTA-STS может помочь повысить безопасность электронной почты.

Когда был создан SMTP, он работал, передавая данные в открытом виде, поскольку тогда мы ещё не разработали решение для безопасной передачи данных, то, что мы называем сейчас «безопасность транспортного уровня» (transport layer security, TLS). Когда TLS наконец-то был готов, нам потребовалось придумать способ поэтапного внедрения TLS. Был создан STARTTLS, предлагающий шифрование «по возможности». По сути, почтовый сервер отправителя мог спросить почтовый сервер получателя: «Поддерживашь ли ты шифрование?», и, если ответ был положительным, устанавливалось TLS-соединение с использованием сертификата, предоставленного сервером. Если нет, использовалось SMTP-соединение с передачей данных в открытом виде.

Любой, кто знаком с темой сетевой безопасности, увидит здесь проблему. Активно действующий злоумышленник, осуществляющий атаку «атакующий посередине» (attacker-in-the-middle, AitM), может подставить свой собственный ответ, указывая, что шифрование не поддерживается, и обманом заставить отправителя использовать открытый текст, что позволит злоумышленнику перехватывать сообщения. Это классическая атака понижения версии.

Даже когда принимающий почтовый сервер представляет TLS-сертификат, проблем предостаточно. Рассмотрим варианты, которые есть у отправляющего почтового сервера, когда ему предоставляется TLS-сертификат, которому он не доверяет. Возможно, имя хоста сервера не совпадает с указанным в сертификате, а сертификат может оказаться просрочен либо подписан неизвестным центром сертификации (CA).

1. Отправить, используя недоверенный сертификат

2. Понизить версию до открытого текста

3. Отказаться от отправки сообщения.

Большинство отправителей почты выбирают первый вариант, поскольку он защищает от пассивного AitM и гарантирует доставку электронной почты.

DANE и DNSSEC

Предложенная в DANE запись TLSA предлагает одно из возможных улучшений, оно предполагает использование подписанных записей DNS.

К сожалению, внедрение DNSSEC идет медленно. Исследования показывают, что в настоящее время около 5% доменов используют DNSSEC. Несколько крупных почтовых провайдеров, таких как Gmail, не поддерживают DNSSEC. Таким образом, нам стоит рассмотреть другие варианты.

MTA-STS

MTA-STS предоставляет почтовым серверам способ указать, что они будут поддерживать шифрование с использованием TLS-сертификата, выданного доверенным центром сертификации (CA). Политика включает параметр max-age, который сообщает отправляющему почтовому серверу, как долго он должен помнить эту политику.

Я не буду вдаваться в подробности того, как работает MTA-STS, поскольку оно состоит из несколько шагов, и хорошо описано другими авторами.

Создание аудитора MTA-STS

Я развернул пару почтовых серверов Postfix и настроил их с почтовым адресом-ловушкой (catch-all) и mailbox_command, который пишет логи входящих сообщений в базу данных. Сервер A имел TLS-сертификат, выданный Let’s Encrypt, широко известным общедоступным CA. На сервере B TLS был полностью отключен.

Для обоих серверов была установлена политика MTA-STS со значением enforce.

Эти серверы помогали мне определить политику отправителя, видя, на какие почтовые серверы происходит отправка электронную почту со стороны серверов отправителя. Отправитель не может отличить преднамеренно неправильно настроенное отсутствие поддержки TLS на сервере B от атаки AitM. Отправитель, который правильно реализует MTA-STS, должен был доставлять почту на сервер A, и отказываться использовать незашифрованное соединение с сервером B.

Выбранные почтовые провайдеры

Для тестирования я выбрал шесть почтовых провайдеров. Первая группа позиционируется как поддерживающая MTA-STS:

• Gmail

• Outlook.com

• Proton Mail

• Tuta Mail

Вторая группа включает несколько других известных почтовых провайдеров, хотя они не заявляют о поддержке MTA-STS:

• Fastmail

• Yahoo

Lazy caching политики MTA-STS

В самом начале своего тестирования, я отправил электронное письмо с Gmail на свои audit-серверы, но обнаружил, что Google успешно доставлял сообщение на оба почтовых сервера. Gmail поддерживает MTA-STS, поэтому это было удивительно. После дальнейшего исследования я обнаружил, что проблемой было «ленивое кеширование» («lazy caching»), упомянутое в RFC 8461 §5.1:

attempt to fetch a new policy (perhaps asynchronously, so as not to block message delivery).

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

Это, к сожалению, означает, что первое сообщение, отправленное на домен, все еще может быть уязвимо для атак понижения версии, но это намеренно разрешено в RFC из соображений производительности.

Транзакционная почта, письма о сбросе пароля и волшебные ссылки

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

Эти типы сообщений часто отправляются с использованием провайдеров транзакционной электронной почты, но я не смог найти ни одного такого провайдера отправки писем, который бы предлагал поддержку MTA-STS. С другой стороны, можно самостоятельно установить и настроить тот же Postfix с установленным расширением MTA-STS, и заниматься отправкой самостоятельно. Вот hosted-провайдеры, которых я протестировал:

• Amazon SES

• Mailgun

• SparkPost

Большинство провайдеров транзакционной электронной почты поддерживают некоторую комбинацию включателей разных режимов работы (включения TLS и/или проверки сертификатов). Эти переключатели на практике не всегда получается перевести во включенное положение, так как некоторые почтовые серверы все еще не поддерживают TLS, а многие не используют действительные сертификаты. Google сообщает, что 2% отправляемых ими электронных писем не зашифрованы, и неясно, сколько зашифрованных соединений использовали доверенные сертификаты. Требование обязательного использования TLS и полной проверки сертификатов заблокировало бы потенциальных клиентов, поэтому многие веб-сайты избегают этих настроек по бизнес-причинам.

MTA-STS позволяет доменам выбирать проверку TLS, при этом позволяя отправителю поддерживать почтовые серверы с более слабыми настройками безопасности. Это лучшее из обоих миров.

Результаты исследований

Для полноты картины я также включил проверку входящей политики MTA-STS.

Вот что я обнаружил:

Удивительно, но Tuta Mail постоянно отправлял сообщение на оба почтовых сервера. Я не вижу никаких запросов, поступающих на сервер политики MTA-STS, поэтому нет никаких признаков того, что эта функция была реализована. В их маркетинговых материалах четко упоминается поддержка MTA-STS, и эта функция отмечена как завершенная в их системе отслеживания проблем, но, возможно, поддерживается только входящий MTA-STS.

В остальном поддержка MTA-STS соответствовала документации продукта.

Пользовательский интерфейс

Что происходит, когда вы отправляете электронное письмо, и сообщение не может быть доставлено из-за MTA-STS?

Если Вы получите подобное сообщение, это будет указывать на наличие проблемы:

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

Outlook уведомляет пользователя только о полном сбое отправки сообщения, через 24 часа. Неловко, что это письмо содержит опечатку и не упоминает, что проблема с проверкой TLS помешала доставке. Надеюсь, пользовательский интерфейс со временем улучшится.

Попробуйте сами!

Чтобы помочь другим проводить аудит MTA-STS, я открыл исходный код проекта и даю всем желающим использовать уже запущенный инструмент аудита (хотя я не планирую поддерживать его в работе в долгосрочной перспективе).

Он построен на Docker Compose и предполагает DigitalOcean в качестве хостинг-провайдера. Подставьте свои собственные доменные имена и другие настройки там, где это необходимо. Есть еще четыре postfix-сервера, о которых я не упомянул, которые помогают делать аудит некоторых других связанных проблем — подробности смотрите в коде.

Пока инфраструктура аудита находится в сети, вы можете генерировать тестовые адреса электронной почты и просматривать информацию об отправителе (не содержимое) для любой полученной электронной почты. Сообщения регистрируются, поэтому не ожидайте конфиденциальности для сообщений, которые вы отправляете сюда. Для начала работы запустите скрипт audit.sh:

$ ./audit.sh Send an email to these addresses: 8a3ca551-d2d8-4f30-9661-c5dbe7b9c18d@a.audit.alexsci.com, c611ff0c-4920-444f-9e8d-6eef1d37f8a3@b.audit.alexsci.com, 55c358c8-e979-4454-b14e-b8f10454e37b@c.audit.alexsci.com, a10c2853-40f5-4c6d-8f85-7ab38038f84e@d.audit.alexsci.com, b0d70539-2021-4194-adf1-d2585a162c34@e.audit.alexsci.com, c77b3caa-bdc7-4160-b24a-2d9646785035@f.audit.alexsci.com,  Press any key to poll for messages, q to quit  ...  { "8a3ca551-d2d8-4f30-9661-c5dbe7b9c18d": [     {     "line": "Message Received:              SENDER: mtastsaudit@yahoo.com               ORIGINAL_RECIPIENT: 8a3ca551-d2d8-4f30-9661-c5dbe7b9c18d@a.audit.alexsci.com              ...",     "service": "postfix",     "when": "2024-09-27T18:20:16Z"     } ], "c611ff0c-4920-444f-9e8d-6eef1d37f8a3": [     {     "line": "Message Received:              SENDER: mtastsaudit@yahoo.com               ORIGINAL_RECIPIENT: c611ff0c-4920-444f-9e8d-6eef1d37f8a3@b.audit.alexsci.com              ...",     "service": "postfix",     "when": "2024-09-27T18:20:16Z"     } ] } Press any key to poll for messages, q to quit

Здесь видно, что Yahoo доставил электронную почту как на сервер A, так и на сервер B.

Включите MTA-STS на вход для своего домена

Если вы получаете электронную почту на свой собственный домен, рассмотрите возможность включения MTA-STS. Более широкое внедрение MTA-STS поможет стимулировать отправителей почты добавить поддержку. Обратитесь к своему почтовому провайдеру, чтобы узнать, что нужно для этого сделать. Вот ссылки на официальную документацию для почтовых провайдеров, которых я тестировал:

• Google

• Outlook.com

Protonmail не заявляет о поддержке MTA-STS для пользовательских доменов, но кто-то предложил решение:

• Protonmail

Общий процесс включения входящего MTA-STS также хорошо задокументирован:

• Using Apache

• Using GitHub Pages

Fastmail и Yahoo используют сертификаты от DigiCert, доверенного CA, поэтому они могли бы включить входящий MTA-STS без особых усилий.

При включении MTA-STS всегда следует настраивать TLSRPT, поэтому не забудьте настроить и его.

Заключительные мысли

MTA-STS предоставляет многообещающий подход к увеличению безопасности SMTP. К сожалению, глубина внедрения основными провайдерами этого протокола невелика.

Отсутствие поддержки MTA-STS со стороны hosted-провайдеров транзакционной электронной почты делает электронные письма со сбросом пароля бесчисленных веб-сайтов весьма уязвимыми для атак понижения версии SMTP и перехвата. Клиенты должны стимулировать провайдеров транзакционной электронной почты на внедрению MTA-STS.

Google обеспечивает наилучшее взаимодействие с пользователем по поводу сообщений, которые были задержаны или не доставлены из-за MTA-STS. Быстрое уведомление пользователя о проблеме и предоставление нескольких обновлений было очень полезным. Разработчики должны обязательно учитывать, как они сообщают своим пользователям о поведении, вызванном MTA-STS.

Дополнительные примечания

HSTS — это аналогичная технология, которая помогает нам защищать веб-сайты. HSTS использует список предварительной загрузки, который позволяет веб-браузерам поставляться со списком доменных имен, которые, как известно, поддерживают HSTS. SMTP раньше использовал список политик STARTTLS, но он был закрыт в пользу MTA-STS.

Как и HSTS, RFC MTA-STS не указывает, какие центры сертификации следует использовать при проверке сертификата. Сервер, как обещается, будет использовать сертификат, которому клиент (т.е. веб-браузер или второй почтовый сервер) будет доверять. Это централизует решение о том, каким CA доверять, в руках популярных веб-браузеров (таких как Chrome) и популярных почтовых провайдеров (таких как Gmail). Веб-браузеры быстро прекратили поддержку CA после случившихся инцидентов безопасности, поэтому почтовым серверам необходимо отслеживать, каким CA доверяют отправители, и при необходимости корректировать настройки.

С помощью своей тестовой платформы я собираю массу дополнительной информации:

• TLSRPT — агрегированные отчеты от отправителей почты о недоставленных сообщениях.

• Логи HTTP-сервера, показывающие запросы файла политики MTA-STS.

• Логи указывают, что Proton Mail использует postfix-mta-sts-resolver, намекая на то, что они используют стек Postfix.

• Поддержка IPv6.

Будущие исследования могут опираться на эту основу.

Наконец, вот отчет TLSRPT от Microsoft. Здесь видно, как я попробовал пару различных конфигураций, но Microsoft правильно отклонил соединение: