Дисклеймер

Описанное в данной статье имеет строго ознакомительный характер. Автор не несет ответственности за возможный ущерб при неправильном использовании представленной информации, а также за неправильное ее восприятие или произвольную трактовку. Цель статьи — повышение безопасности.

Всем доброго дня! Тема защиты электронной почты очень часто обсуждается как онлайн, так и офлайн. Это и неудивительно, так как в различных отчетах и источниках этот вектор атаки ставится на одно из лидирующих мест (пример).

Данная статья носит больше ознакомительный характер, нежели глубоко технический, и имеет целью осветить общественности вектор атаки, о котором, может быть, кто-то не знает или забыл. Конечно, описанное может быть выполнено только при возникновении ряда условий, например, некорректной настройки почтового сервера (здесь и далее речь будет идти именно о MTA), межсетевого экрана (МЭ), правил фильтрации, механизмов SPF, DKIM, DMARC и т.д. Итак, если Вас интересует, каким образом злоумышленник может использовать Ваш почтовый сервер в собственных целях или какие есть угрозы помимо фишинга и спама — прошу под кат.

Почему это имеет место быть

Если у обычного пользователя спросить об угрозах, связанных с электронной почтой, то многие пользователи (действия в реальных условиях — другой вопрос) расскажут о запрете перехода по ссылкам из сомнительных почтовых писем, запрете ввода паролей и т.п. Но на самом деле не только почтовые ящики, но и сам MTA может стать целью в атаке злоумышленников.

Множество отчетов сфокусировано на атаках, целью которых можно назвать именно доставку вредоносных вложений пользователям (Тренды почтовых угроз 2022 года | Блог Касперского или даже отсортировать интересующее направление и период ЗДЕСЬ). Можно сделать такой вывод из представленных данных:

Злоумышленники не стоят на месте и применяют все более разнообразные и изощренные рассылки для доставки пользователям вредоносных вложений, количество таких атак увеличивается. Итог: надо усилить защиту почты, установив/обновив/добавив средства защиты и анализа почтового трафика.

С другой стороны, если учесть такой фактор, как ошибка выжившего, то на ситуацию можно посмотреть немного иначе:

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

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

Описание цели

При написании статьи хотелось охватить как можно больше различных продуктов и решений. Сделать это нереально, но я, мечту свою лелея, решил проблему гениально — я выбираю Astra Linux!

Выбор данной ОС основан на принципе импортозамещения, который так актуален в последнее время. Внутри репозиториев ОС уже находится пакет MTA (Exim4).

Для проведения тестирования развернута виртуальная машина, на ней настроен локальный почтовый сервер (c MDA и MUA на одном хосте) c локальным доменом «test.lan».

Описание механизма атаки

Сетевые порты для обмена почтовым трафиком, например 25/tcp, должны быть доступны пользователям. Таким образом, если почтовый сервер имеет сопряжение с сетью Интернет, то данный порт будет доступен для всех пользователей Интернета (а если сервер развернут в локальной сети, то для всех пользователей данной сети, если это не ограничено МЭ). Уязвимость данного подхода заключается в том, что если MTA не настроен должным образом, то этот порт может быть использован не только почтовыми серверами, но и злоумышленниками, т.к. существует возможность «вручную» подавать команды почтовому серверу.

Данная «особенность» MTA раскрыта во многих статьях (пример 1 и пример 2), но без некоторых дополнений, которые будут описаны далее.

Проведение атаки

Для начала просканируем целевой хост.

По результатам сканирования возможно определить открытый порт, версию MTA и даже имя хоста.

После этого при помощи утилиты telnet произведем отправку простейшего письма. Для этого выполним:

telnet <адрес или имя севера> 25

Инициируем транзакцию электронной почты, введя

helo astra17.test.lan, где astra17.test.lan в данном случае — имя самого сервера, которое получено ранее. Получив ответ 250, приступаем к генерации сообщения.

mail from: smith@smith.com, где «smith@smith.com» — ящик отправителя.

rcpt to: user1@test.lan, где «user1@test.lan» — ящик получателя.

Получив 250 Accepted, продолжаем отправку. Указав data , сообщаем серверу, что будем слать тело письма. Указав другие параметры, назначаем заголовки сообщения (from: smith <smith@smith.com> — имя, как оно будет отображаться у клиента и адрес, to: user1 < user1@test.lan > — получатель,  Subject: Test subject — зададим тему письма как «Test subject»). Указав This is test message , введем текст письма и завершим отправку, введя .

Получив 250 OK id... , мы видим ответ от MTA, что наше письмо успешно отправлено.

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

В чем интерес описанного действия? В том, что пользователя smith@smith.com на тестовом почтовом сервере нет, мы указали выдуманный почтовый ящик и из-за отсутствия механизмов проверки наш почтовый сервер всё принял и обработал как «настоящее» письмо. Так же мы могли «подделать» не только почтовый ящик отправителя, но и отображаемое имя (smith).

Таким образом, при возможности неавторизованной отправки злоумышленник может использовать ЛЮБЫЕ адреса отправителя/имя. Более того, данный функционал поддерживается многими языками программирования и может быть автоматизирован. В качестве вложения можно направлять любой файл, а не только текст. В примере ниже продемонстрирована возможность замены адреса отправителя на тех. поддержку Google, а в качестве вложения использована простейшая html-страница, в которой содержится вдохновляющий текст: 

Дополнительные сценарии

Так какие могут быть способы использования данного механизма?

1. Доставка сообщений Вашим пользователям от сторонних отправителей. Примерами отправляемых писем для Ваших пользователей могут быть как вредоносные/нежелательные вложения, так и фишинг-атаки: злоумышленники могут отправлять имитацию писем от банков, онлайн-магазинов и других сервисов с просьбой в ответном сообщении указать конфиденциальную информацию, ввести свои логины, пароли и т.д. т.п. Такие письма могут быть подделаны как отправленные от сторонних ящиков (пример с smith@smith.com), так и от Ваших коллег (например, user2@test.lan для рассматриваемого примера или hr@, support@, info@ и далее).

2. Доставка вредоносных вложений Вашим пользователям, но отправленных якобы от их имени. Если при генерации письма в качестве отправителя указать Ваш почтовый ящик, а в качестве получателя несуществующий, то клиенту вернется «Ваше» письмо с ошибкой доставки. В данном случае MTA может обработать письмо по более слабым правилам проверки, т.к. отправителем письма будет «Ваш» почтовый ящик (очень грубый пример: отделу бухгалтерии разрешается отправлять документы с макросами). И да, отправленные файлы могут просто отображаться в теле письма и быть доступны пользователю.

   

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

4. Доставка вредоносных вложений Вашим пользователям, отправленных
   от сервисных учетных записей. Если настроены оповещения или другие варианты использования «технических» записей («почтовый мастер», доставка вложений из карантина, рассылка отчетов, архивов с паролями и пр.), то злоумышленники могут узнать об имени данного ящика и использовать его для того, чтобы обойти правила фильтрации. Более того, некоторые фильтры после установки начинают рассылать письма от почтового адреса, состоящего из названия сервиса, заданного по умолчанию, и доменного имени. Например, если установить условный фильтр с названием Filter, то адрес, с которого будут приходить оповещения, для используемого тестового домена будет filter@test.lan.

5. Отказ в функционировании. При отправке больших объемов писем может произойти сбой в работе почтового сервера и доставке других писем. Если даже использовать поддельных получателей (пример из п. 2), то ящик не будет найден и на Ваш MTA придет оповещение с этим же файлом. Также, если слать допустимые вложения, но большого объема и автоматизировать отправку, указав в качестве отправителей/получателей разные ящики, то можно добиться отказа MTA или вывести из строя конкретные почтовые ящики, т.к. у них возникнет огромная очередь писем, и некоторые клиенты могут не справиться с обработкой (например, из-за слабого канала связи или слабых вычислительных мощностей устройства).

Способы защиты

1. Настройка запрета неавторизованной отправки. В самом руководстве администратора, в разделе про настройку почтовой системы, приводится пример внесения изменений в конфигурацию MTA, которая позволяет ограничить указанный способ отправки. Для этого необходимо в файл /etc/exim4/conf.d/acl/30_exim4-config_check_rcpt (если выбран вариант использования множества конфигурационных файлов) в начало секции acl_check_rcpt добавить несколько строк, как в примере ниже, и перезагрузить MTA.

   acl_check_rcpt:
    deny
    message = "Auth required"
    hosts = *:+relay_from_hosts
    !authenticated = *

2. Настройка SPF, DKIM, DMARC.

3. Настройка правилами МЭ и почтового шлюза, какие клиенты (адреса) и какие почтовые ящики могут отправлять различные типы почтовых писем, например, такие группы: локальные почтовые ящики на внешние; внешние на локальные; локальные на локальные.

4. Разделение проверки почты на различные этапы, например: на почтовом шлюзе в DMZ и далее на почтовом сервере внутри периметра организации.

Дополнительные векторы атаки

Упор в данной статье сделан на неавторизованную отправку электронной почты, однако злоумышленники также могут проводить:

1. Атаки на MTA с использованием обнаруживаемых уязвимостей (в рассматриваемом случае Exim). При этом следует отметить, что атаки могут быть направлены, например, на особенности работы SMTP-сервера и не затронут этап пересылки. Таким образом, существует возможность, что даже если к почтовому серверу подключены фильтры для проверки почты — они окажутся бесполезны, т.к. у атаки другая цель.

2. Подбор паролей к веб-интерфейсам средств управления почтовых фильтров. Несмотря на то, что администрирование таких активов целесообразно выполнять из внутренней инфраструктуры организации, а не со стороны внешнего периметра (Интернет), это не всегда возможно или попросту не выполняется. Злоумышленники могут использовать данные, которые содержатся в таких поисковых системах, как Censys или Shodan, для того, чтобы быстро и без личного участия найти эти веб-формы, а затем либо вручную, либо при помощи других сервисов попытаться подобрать пароль (у некоторых отечественных почтовых фильтров логин учетной записи задан по умолчанию, что сильно облегчает перебор).

Заключение

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

Благодарю за прочтение, надеюсь, Вам было полезно и интересно!