Описанное в данной статье имеет строго ознакомительный характер. Автор не несет ответственности за возможный ущерб при неправильном использовании представленной информации, а также за неправильное ее восприятие или трактовку. Цель статьи — повышение осведомленности в части информационной безопасности.
Немного вводной информации
Понятие открытого релея появилось в сообществе ИТ и ИБ специалистов еще в далеких нулевых. Тогда большинство почтовых серверов являлись ретрансляторами и работали на пересылку почтовой корреспонденции без дополнительных ограничений, пока этим функционалом не стали злоупотреблять спамеры.
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: [email protected]
to: [email protected]
subject: TEST SMTP SERVER
После ввода команды data получим ответ
354 End data with <CR><LF>.<CR><LF> — можно вводить текст сообщения.
Заканчиваем ввод и получаем сообщение о том, что письмо отправлено в очередь с уникальным идентификатором: 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 (Подробнее)
Используем кодировку 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.
Внедрение АВЗ: По возможности обеспечить инфраструктуру средствами антивирусной защиты для реализации защиты от файловых угроз.
Ну и, конечно же, необходимо регулярно проводить мероприятия по повышению осведомленности персонала в части информационной безопасности и цифровой гигиены – это позволяет существенно повысить уровень знаний других специалистов и минимизировать вероятность успешного нелегитимного воздействия.
Заключение
В завершение хотелось бы еще раз акцентировать внимание на том, что порой даже детские недостатки или ошибки могут привести злоумышленника к успеху. Дьявол в мелочах – необходимо тщательно подходить к вопросам обеспечения безопасности и корректности конфигурации сервисов.
На этом я с вами прощаюсь, благодарю за внимание!
