SMTP как открытая дверь для фишинга. Популярный недостаток почтовых серверов и меры предосторожности29.01.2024 11:15

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

Немного вводной информации

Понятие открытого релея появилось в сообществе ИТ и ИБ специалистов еще в далеких нулевых. Тогда большинство почтовых серверов являлись ретрансляторами и работали на пересылку почтовой корреспонденции без дополнительных ограничений, пока этим функционалом не стали злоупотреблять спамеры.

Open Relay — SMTP сервер, поддерживающий соединения без авторизации от любого устройства для отправки электронной корреспонденции. Очевидно, что данный недостаток представляет собой серьезную угрозу для безопасности электронной почты и инфраструктуры в целом.

Более подробно об истории с открытым перенаправлением можно прочитать здесь — https://practical365.com/what-is-an-open-relay. Ну, а мы двинемся дальше.

Общий подход к тестированию smtp

Порт 25/tcp является основным каналом связи для передачи электронной почты по протоколу SMTP. Небрежное отношение к конфигурации почтовых серверов делает систему уязвимой к различным видам деструктивного воздействия. Конечно же, у этого могут быть серьезные последствия, начиная от несанкционированной рассылки спама и заканчивая проведением таргетированных атак на инфраструктуру и компрометацией узла.

Обратившись к популярным методичкам по наступательной безопасности (например, Hacktricks), можно сделать вывод, что специалисты выделяют несколько контрольных точек:

Открытое перенаправление (Open Relay)
Перечисление пользователей (Username Enumeration) при использовании конструкций rcpt to, vrfy, expn
Mail Spoofing (опционально)

Казалось бы — ничего нового, тем не менее…

Вектор воздействия

В 2023 году разновидность smtp relay можно было обнаружить буквально у каждой четвертой компании в финансовой или промышленной сфере (в качестве подтверждения всегда можно использовать shodan и проверить первые 20 адресов — результат может сильно удивить). Сами недостатки были выявлены в ходе работ по анализу защищенности и, конечно же, оперативно устранены. Эта череда событий в очередной раз наталкивает на мысль, что, несмотря на древность Relay технологий, администраторы ресурсов все еще довольно небрежно относятся к исполнению собственных обязанностей.

Первым делом удостоверимся в том, что удаленный почтовый сервер имеет открытый smtp порт (по умолчанию 25, 587).

На следующем этапе запускаем поиск доменных почтовых адресов (это могут быть автоматизированные утилиты и сервисы такие как: hunter, leakcheck, также не лишним будет использовать автоматизацию, в том числе, при помощи Burp) — для начала будет достаточно получить хотя бы 5–7 почтовых адресов (валидными могут оказаться далеко не все).

Приступаем к активной фазе. Выполняем подключение посредством telnet, после чего инициируем SMTP-диалог командой HELO (более подробно о командах SMTP здесь).

Клиент отправляет эту команду SMTP-серверу, чтобы идентифицировать себя и инициировать SMTP-диалог. Доменное имя или IP-адрес SMTP-клиента обычно отправляется в качестве аргумента вместе с командой (например, «HELO client.example.com»). EHLO (Расширенный привет)- то же, что и HELO, но сообщает серверу, что клиент может захотеть использовать расширенный протокол SMTP.

В природе существует несколько вариантов подключений (подробнее здесь).

После расширенного приветствия Сервер вернет список возможностей и поддерживаемые типы аутентификации.

Существует несколько сценариев, использующих принцип SMTP Relay, но наибольший интерес для нас представляет отправка писем внутри корпоративного контура. Сценарий user1@corp → user2@corp. Именно сейчас пригодится собранная информация по доменным почтовым адресам.

Используя стандартные команды SMTP (более подробно о командах SMTP здесь) зададим почтовый адрес отправителя и получателя письма.

Конфигурация у каждого сервера отличается, это влечет за собой различные подводные камни. Например, можно столкнуться с разного рода сообщениями об ошибках:

Стоит также отметить, что существуют узлы, которые все входящие подключения на порт 25 по протоколу telnet сбрасывают без доп. информации:

Как только получаем код 250 2.1.0 Ok, переходим к содержимому самого письма:

Указываем отправителя, адресата, тему (отображается в почтовом клиенте):

From: tester@ces.ru
to: user@ces.ru
subject: TEST SMTP SERVER

После ввода команды data получим ответ

354 End data with . — можно вводить текст сообщения.

Заканчиваем ввод и получаем сообщение о том, что письмо отправлено в очередь с уникальным идентификатором: 250 2.0.0 Ok: queued as A340FC4B70C.

Пользователь из rcpt to получил это письмо:

Как видно из примера — внешний пользователь, не имеющий отношения к организации, рассылает email между сотрудниками от их имени. Чем не повод задуматься о безопасности?

Использование SMTP Relay для отправки HTML и документов

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

Отправка сообщений с вложениями происходит в соответствии с почтовым стандартом MIME (Подробнее). Использование стандарта позволяет отправлять электронные письма с обычным текстом и версиями text/HTML, встроенными изображениями и вложениями. Расширения MIME могут быть добавлены к сообщению в стандартном формате RFC/822, что обеспечивает обратную совместимость со старыми почтовыми системами.

Отправка HTML в целом довольно проста — для этого необходимо определить тип содержимого как multipart (смешанный) и указать уникальную строку, используемую для обозначения границ MIME. Важно специфицировать составную часть MIME и указать собственный Content-Type заголовок — text/plain или text/html для html части, после чего передать строку-содержимое.

Для отправки полноценного вложения (docx, pdf, jpg и тд) порядок действий идентичен. Указав информацию для полей клиента (по необходимости) переходим к стандарту MIME:

После успешного определения содержимого необходимо добавить заголовки, позволяющие правильно интерпретировать вложение:

Content-Disposition (Подробнее)

Transfer Encoding (Подробнее)

Content Type (Подробнее)

Используем кодировку base64. Content-Type заголовок в соответствии со стандартом для docx документа: application/vnd.openxmlformats-officedocument.wordprocessingml.document.

Далее указывается непосредственно содержимое вложения, которое заканчивается уникальной строкой — границей MIME. Отправляем письмо и видим заветное — queued!

Соответственно, само письмо:

data
354 Start mail input; end with . (это строка – ответ сервера)
from: test
to: ait
subject: Corp DMS
Mime-Version: 1.0
Content-Type:multipart/mixed;boundary="=====PHISH"
=====PHISH
Content-Disposition: attachment; filename="corp.docx"
Content-Transfer-Encoding: base64
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="corp.docx"

UEsDBBQABgAIAAAAIQDnIQddcAEAANcFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 
. . . .
bGVzLnhtbFBLAQItABQABgAIAAAAIQDs+WgaigEAAA0DAAARAAAAAAAAAAAAAAAAADtxAABkb2NQ
cm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQCRkmQ0EAMAAH8QAAASAAAAAAAAAAAAAAAAAPxz
AAB3b3JkL251bWJlcmluZy54bWxQSwECLQAUAAYACAAAACEAVHU3HhgCAABcCAAAEgAAAAAAAAAA
AAAAAAA8dwAAd29yZC9mb250VGFibGUueG1sUEsBAi0AFAAGAAgAAAAhAFYVQhB+AQAAzwIAABAA
AAAAAAAAAAAAAAAAhHkAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAA0ADQBEAwAAOHwAAAAA
=====PHISH

.

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

И на десерт: KSMG (почтовый шлюз безопасности) не идентифицирует отправленное сообщение как спам или вредоносное — как легко банальная ошибка администратора сервиса может привести к иммунитету от Kaspersky.

Как не быть атакованным?

В первую очередь, необходимо обеспечить запрет неавторизованной рассылки сообщений — принудительную аутентификацию. Это позволит использовать PLAIN, LOGIN, CRAM-MD5, SCRAM-SHA-1 или NTLM.

Аутентификация всегда должна идти рука об руку с шифрованной связью (SSL/TLS), поскольку учетные данные не должны передаваться в открытом виде по незащищенным сетям.

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

Ограничение доступа: если позволительно, ограничивать доступность устройства извне посредством указания доверенных сетей.

Мониторинг и журналирование: конечно, же обеспечивать журналирование событий на SMTP-сервере. Это позволит оперативно отслеживать активность и выявлять подозрительные действия (в том числе при использовании SIEM).

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

Алгоритмы блокировки: реализовать систему блокировки по превышении количества неудачных попыток аутентификации. Позволит предотвратить атаки с использованием методов грубой силы.

Настройка записей DNS: использовать записи DNS для защиты от нежелательной почты, спама и спуфинга: spf, dkim, а также применять подпись dmark.

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

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

Заключение

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

На этом я с вами прощаюсь, благодарю за внимание!