Атака на протокол SMTP. Тестирование на взлом (ПЕНТЕСТ)
Дисклеймер
В статье далее рассматривается почтовый протокол с точки зрения тестирования безопасности. Цель — повышение безопасности сетей, администрирование.
Разбор протокола SMTP с точки зрения возможных атак и мер противодействия, все с точки зрения внешнего злоумышленника.
Что меня часто действительно сбивало с толку, так это то, что я не знал, какую часть почтового потока использовал, когда применял telnet для ручного подключения к SMTP-серверу во время взаимодействия. Я выступаю в роли SMTP-сервера или клиента? Почему он не блокирует мою попытку подделать электронные письма на определенном этапе?
Итак, я установил небольшой hMailServer и немного погуглил, чтобы начать работу.
На самом деле позже мне пришлось схитрить, так как hMailServer вообще не поддерживал VRFY, и поэтому настроил другой SMTP-сервер → mercury .
Вся статья рассматривает внешние атаки, и поэтому вы не найдете предложений по внутренним мерам защиты.
Введение в SMTP
Simple Mail Transfer Protocolпредназначен для SEND писем из одной системы в другую.
Это могут быть почтовые клиенты, такие как Outlook, почтовые серверы, такие как Microsoft Exchange, межсетевой экран и т. д.
Связь по умолчанию осуществляется в виде открытого текста. Но в настоящее время вы, скорее всего, увидите, как почтовые серверы переключаются с обычного текста на защищенный канал с помощью SSL / TLS .
Порты по умолчанию — 25, 465 (устарело) и 587, где 25 предназначен для использования для отправки от вашего почтового клиента на почтовый сервер, а более высокие порты для ретрансляции между SMTP-сервером.
SMTP-сервер может действовать как клиент и как сервер, так как он должен отправлять и получать электронные письма одновременно. Рассмотрим брандмауэр, который обрабатывает все ваши электронные письма, как исходящие, так и входящие — в обоих случаях задействован SMTP.
Некоторые термины, используемые вместе с SMTP :
Почтовый пользовательский агент (MUA) : это программа (часть), подключающаяся к SMTP-серверу для отправки электронной почты. Скорее всего, это ваш Outlook, Thunderbird или что угодно.
Агент пересылки почты (MTA) : транспортная часть программы. Они получают и передают электронные письма. Это может быть сервер Exchange, шлюз с выходом в Интернет и так далее.
Соответствующий RFC5321 упоминает только эти два термина.
Однако, если вы начнете спрашивать Интернет о SMTP, вы наверняка наткнетесь на агента отправки почты (MSA) и агента доставки почты (MDA) и некоторые другие.
Это также особые функции программы, участвующей в рабочем процессе электронной почты, которые позволяют описать процесс более точно и детально. MSA является частью получающую электронную почту от MUA и MDA, и передающей письмо к конечному принимающему MUA. Скорее всего, все эти функции будут найдены в одном или двух продуктах в вашей среде, которые могут позаботиться обо всех этих шагах.
Таким образом, рабочий процесс передачи электронного письма от одного пользователя к другому может выглядеть так:
MUA → MSA → MTA → Интернет → MTA → MDA → MUA
Термины relay и gateway четко определены в RFC5321.
Пример конфигурации
Чтобы упростить работу, давайте рассмотрим следующий сценарий настройки электронной почты компании: у
нас есть среда Microsoft с клиентами Windows и Outlook, выступающим в качестве MUA .
У нас есть сервер Exchange, доступный только изнутри сети. Он получает электронные письма, которые пользователь хочет отправить, и при необходимости пересылает их.
Существует также DMZ с выходом в Интернет, в которой находится межсетевой экран, который также действует как почтовый шлюз. Таким образом, сервер Exchange отправляет электронные письма получателям за пределами доменов, за которые он отвечает, на этот брандмауэр.
Почтовый поток будет выглядеть так:
Outlook → Exchange → firewall → internet → SMTP-Server of the receiving side → mail-server of the receiving side → Outlook of receiver
Атака на SMTP-серверы — спуфинг почты
Теперь самое интересное.
Когда вы находитесь во внешнем взаимодействии и обнаруживаете устройство с открытым SMTP-портом, вы, скорее всего, нашли систему, которая в первую очередь обрабатывает входящие электронные письма из Интернета — в нашем случае это брандмауэр.
Мой личный рабочий процесс состоит в том, что я сначала перечисляю записи MX компании, чтобы определить поверхность их атаки относительно SMTP. Это можно сделать с помощью простого nslookup :
nslookup
set type=mx
<target>
Результатом является список всех систем, ответственных за входящую почту для этого домена.
Далее идет сканирование nmap для определения открытых портов:
nmap <target> -p 25,465,587
Результат должен выглядеть примерно так:
Дальше вручную подключаюсь к серверу с помощью telnet или netcat и проверяю, могу ли я отправлять поддельные электронные письма (из их домена в их домен, как если бы я сидел внутри их сети):
Сначала открываем подключение к порту 25 на SMTP-сервере.
Мы представляемся как действующие от имени домена company.com с EHLO .
Далее укажите email-адрес отправителя pentester@company.com .
Определите, кто является адресатом электронной почты boss@company.com .
Укажите, что мы хотим отправить DATA по электронной почте. SUBJECT нашей электронной почты является набором. Набиваем тело текстом. Заключительный знак завершения SMTP-коммуникации, чтобы показать, что мы закончили и готовы к отправке — это <.> В одной строке.
Если вам нужно подключиться к серверу, который разрешает только шифрованную связь, вы можете использовать openssl:
openssl s_client -starttls smtp -connect <SMTP-server>:587
На этом этапе SMTP-сервер может по-разному реагировать от случая к случаю:
- Возможно, вы даже не сможете подключиться к серверу. Поскольку он выполняет несколько проверок, которые вы не прошли.
- Или вас могут заблокировать, когда вы скажете, что хотите отправить с @ company.com, поскольку вам не разрешено отправлять сообщения из-за пределов сети, или выполняется SPF-проверка (подробнее об этом позже), или требуется аутентификация (подробнее об этом позже ).
- Сервер также может сказать: « Хороший приятель, спасибо за письмо». Я переведу это.
Когда происходит последнее, я впервые подумал: черт возьми, они ошиблись. Мне удалось отправить электронное письмо от их имени. Давайте рассылаем им легальные фишинговые письма.
Но в основном это оказалось ошибочным предположением. Он только сообщает вам, что (в данном случае) брандмауэр принял ваш запрос в первую очередь. Если после этого он сделает другие проверки, это будет для вас вне поля зрения. Обычно заказчик сообщал мне, что письмо было заблокировано брандмауэром или что оно было помечено как вредоносное внутри их Outlook. Оба сценария не подвергают их риску.
Это также момент, когда становится ясно, что клиенту нужна какая-то аутентификация. Но как именно и в каких случаях?
Что ж, здесь может быть несколько сценариев:
1. Кто-то подключается к вашему SMTP-серверу и хочет отправить с внешнего IP и домена на ваш домен.
Это «нормальный» случай, который, как можно предположить, происходит ежедневно.
С точки зрения клиентов, мы хотим убедиться, что проверили (SPF, DKIM, DMARC), законна ли отправляющая сторона для этого. Если все проверки пройдены, электронное письмо может быть отправлено в Exchange.
2. Кто-то подключается с внешнего IP к вашему SMTP-серверу и хочет отправить с вашего домена.
Я считаю это по крайней мере необычным, поскольку никто из вашей организации не будет напрямую передавать свои электронные письма на брандмауэр при нормальных обстоятельствах. Предполагаемый способ: Outlook → Exchange, а не Outlook → брандмауэр.
Здесь в игру вступает аутентификация. Обычно Outlook отправляет вашу электронную почту в Exchange, и ваш Exchange будет проходить проверку подлинности на брандмауэре, чтобы отправлять электронные письма за пределы вашей организации.
Если вы обнаружите внешние электронные письма, отправляющий IP и MAIL FROM будут извне вашего домена.
Поэтому, если внешний IP-адрес хочет отправить из вашего домена и, что еще хуже, в ваш домен, вы должны принудительно выполнить аутентификацию или иным образом отклонить сообщение.
В моей тестовой лаборатории соответствующий запрос потерпит неудачу следующим образом:
Сама аутентификация может быть принудительно реализована с помощью SMTP-Auth / SMTP. Это позволит войти в систему с помощью PLAIN, LOGIN, CRAM-MD5, SCRAM-SHA-1 или NTLM.
Аутентификация всегда должна идти рука об руку с шифрованной связью (SSL / TLS), поскольку учетные данные не должны передаваться в открытом виде по незащищенным сетям.
Для hMailServer вы можете детально установить, когда требуется аутентификация:
а также для обеспечения зашифрованного обмена данными или нет:
3. Кто-то подключается к вашему SMTP-серверу и хочет отправить с внешнего домена на внешний домен.
Это будет считаться открытым почтовым ретранслятором, если это разрешено, и вы не хотите попасть в черные списки для спамеров.
Этот сценарий представляет собой тип неправильной конфигурации, при которой каждый сможет использовать ваш SMTP-сервер для рассылки своего СПАМА другим пользователям по всему миру.
Здесь вы хотите убедиться в следующем:
ваш SMTP-сервер не должен принимать и пересылать электронные письма с нелокальных IP-адресов в нелокальные почтовые ящики неаутентифицированным или неавторизованным пользователем.
SPF, DKIM, DMARC
Есть три контрмеры, которые были введены, чтобы уменьшить злоупотребление электронной почтой.
Я просто коснусь поверхности и попытаюсь вкратце объяснить, что делает каждый из них.
SPF
Sender Policy Framework проверяет , если система отправки уполномочена отправлять сообщения электронной почты для домена , указанного в MAIL FROM поля. Для этого он проверяет, содержат ли записи DNS домена отправителя запись TXT с определенной записью SPF :
v=spf1 ip4:1.2.3.4 -all
Если IP-часть содержит сервер, который отправил электронное письмо, принимающая сторона знает, что этой системе разрешено отправлять электронные письма для соответствующего домена.
Чтобы узнать больше об этой проверке: https://postmarkapp.com/blog/explaining-spf
DKIM
Domain Keys Identified Mail является стандартом безопасности , разработанным , чтобы убедиться , что никакая фальсификация на электронную почту произошла во время перехода от отправителя к получателю.
Это достигается с помощью криптографии с открытым ключом, когда компания помещает часть открытого ключа в DNS-запись своего домена, а закрытый ключ находится в системе, которая подписывает исходящие электронные письма.
Эти письма будут содержать в заголовках DKIM-подпись, которая создается с помощью закрытого ключа.
Принимающая сторона проверит подпись с помощью DNS-записи, и если это пройдет, сообщение считается подлинным.
Чтобы узнать больше об этой проверке: https://postmarkapp.com/guides/dkim
DMARC
Domain-based Message Authentication, Reporting & Conformance еще один стандарт, который предотвращает спамер от использования своего домена , чтобы отправить электронную почту без вашего разрешения. Он построен на основе SPF и DKIM . Короче говоря, DMARC позволяет вам решить, что должна делать другая компания при получении электронных писем из вашего домена, которые не проходят проверки SPF и DKIM . Это также достигается с помощью DNS-записей для вашего домена, которые могут выглядеть так:
_dmarc.company.com TXT v=DMARC1\; p=reject\; pct=100\; rua=mailto:dmarc-reports@company.com\;
Эта запись будет определять, что 100% = все электронные письма, которые не проходят SPF или DKIM, должны быть отклонены, а отчет должен быть отправлен на dmarc-reports@company.com.
Чтобы узнать больше об этой проверке: https://postmarkapp.com/guides/dmarc
Многие почтовые системы в наши дни будут действовать на основе репутации. Это происходит в том случае, если компании не удается внедрить SPF , DKIM или DMARC или если она по какой-то причине находится в черном списке спама, ее репутация будет снижена, и общение будет с меньшей вероятностью разрешено.
Как правило, следующие пункты заставят ваши SMTP-серверы работать безопасным образом (внешний вид):
- разрешить электронную почту с локальных IP-адресов в локальные почтовые ящики
- разрешить электронную почту с локальных IP-адресов в нелокальные почтовые ящики
- разрешить электронную почту с нелокальных IP-адресов в локальные почтовые ящики
- разрешить электронную почту от клиентов, которые аутентифицированы и авторизованы, если ни одно из трех выше не соответствует действительности
- использовать SPF, DKIM и DMARC и не разрешать обмен данными, если один из тестов не прошел
- использовать репутацию и разрешать только надежным источникам связываться с вашей почтовой инфраструктурой
- использовать черные списки
- обеспечить зашифрованную связь
Атака SMTP-серверов — перечисление пользователей
Перечисление пользователей — это второй тип атак, от которых вы хотите избавиться.
Плохие парни могут легко собрать список адресов электронной почты, принадлежащих вашей компании, с помощью социальной инженерии и проверить их действительность с помощью SMTP.
После успешной проверки их можно затем использовать для атак с использованием паролей и тому подобного — например, против вашего OWA / EWS, O365, VPN или чего-либо еще.
Существует как минимум три метода / команды, позволяющие перечислять пользователей:
VRFY : используется для проверки того, известен ли определенный пользователь SMTP-серверу.
EXPN : используется для раскрытия фактического адреса (а) электронной почты псевдонима
RCPT TO : необходимая команда для указания того, кому следует отправить электронное письмо.
Вы можете проверить, доступны ли команды с помощью команды HELP (если таковая имеется).
VRFY и EXPN работают одинаково. Вы вводите команду вместе с учетной записью, именем, псевдонимом или адресом электронной почты, которые хотите проверить. В ответ будет либо 250/251, сообщающее о существовании учетной записи, либо расширение псевдонима, либо 550 , сообщающее о недействительной учетной записи.
Хорошая новость заключается в том, что вы можете без проблем отключить VRFY и EXPN , и, вероятно, вам следует это сделать.
Тогда ответ сервера должен выглядеть так:
Напротив, RCPT TO необходим для того, чтобы все работало.
Интересный факт: когда я проводил исследование для этого сообщения в блоге, в самой первой записи Google, касающейся SMTP и тестирования на проникновение, предлагалось отключить RCPT TO. Если бы это было возможно, вы сделали бы свой SMTP-сервер бесполезным.
Однако вы можете усложнить злоумышленникам подсчет ваших пользователей следующими способами:
- Реализация функции catch-all-address / catch-all-rule / catch-all-server
Это ответит на каждый запрос 250 Receipient OK . Это может сказать злоумышленнику, что вы используете универсальный вариант, но не выявит реально существующих пользователей. На более позднем этапе, невидимом для злоумышленника, вы можете решить, что делать с электронными письмами, отправленными на неизвестные адреса. - Ограничение максимального количества неудачных попыток RCPT TO.
Если возможно и поддерживается, добавьте правило, которое запускает соединения, если слишком много неудачных попыток RCPT TO было сделано одним и тем же исходным IP.
Заключение
При небезопасной настройке SMTP-серверы могут подвергнуть вашу компанию высокому риску. Вы не хотите, чтобы внешние стороны отправляли электронные письма из вашего домена в ваш домен без аутентификации, и вы не хотите, чтобы ваш SMTP-сервер действовал как открытый почтовый ретранслятор.
Используйте имеющиеся механизмы безопасности для максимальной защиты вашей среды.
С точки зрения злоумышленников всегда полезно проверить эти низко висящие плоды, чтобы получить первоначальную точку опоры с помощью поддельных фишинговых писем или, по крайней мере, провести некоторую разведку действительных пользователей и адресов электронной почты. Это может пригодиться для дальнейших атак, таких как взлом пароля.
Источник luemmelsec.github.io/Pentest-Everything-SMTP/ (Перевод)