Статья Что с тобой, SMTP ?

И ещё раз здравия всем, дамы и господа. Вторая встреча, да так скоро? Чудо, не иначе. Но сейчас не об этом, а об SMTP. А при чём тут, казалось бы, smtp, ведь речь об уязвимых протоколах, а этот используется даже самыми защищёнными серверами в мире. Разумеется, при условии, что у них есть функционал почтового сервера. Да, конечно, его используют все, как и BGP, прошу не забывать (о нём была предыдущая статья).

Что ж, наш спринт продолжается, 2 статья – SMTP.

what wih you?.jpg


Это что?

Ну, я уже частично проспойлерил, что это что-то связанное с почтой, хотя уверен, вы и сами это знали. Краткий экскурс в историю и пойдём дальше.

Этот протокол почти так же стар как и сам интернет, что уж там говорить, если корнями он уходит к программам Mail Box Protocol и SNDMSG, которые работали ещё во времена арпанета, в 70-е. Потом почту пытались передавать через FTP, выходил достаточно скверно и вот, в самом начале 1980-х, когда “арпа” сменилось на “интер” на сцену выходит Джон Постел и представляет миру SMTP, который мгновенно становится популярным. Как он развивался после нас не особо волнует, можете почитать об этом где-нибудь ещё. Нас же интересует вопрос уязвимостей.

Почему так грустно?

Ну, как бы банально это не звучало, он старый. Очень старый. Его уже не обновляют, к нему делают расширения. Но видимо и к ним тоже скоро будут расширения, т.к. последнее обновление одного из них было в 2008. Конечно, большинство расширений при должной настройке шикарно работают и кажутся цитаделью. Но самая основная брешь у этой цитадели в том, что вы можете ей прикинуться. SMTP позволяет отправлять письма от его имени и хотя сейчас появились всякие проверки подлинности, но в отправителе всё равно пишется почта чья захотите, а уже после пишется, мол “ну там не факт на самом деле, я не знаю”. Подобные письма вряд ли пропустит хорошо настроенный корпоративный почтовый сервер, но во-первых, они не всегда хорошо настроены, а во-вторых, письмо может придти и на личную почту, где эта неуверенность в отправителе будет вообще, скорее всего, проигнорирована (и системой и человеком).

А что делать?

А делать можно два варианта, либо отправлять, либо проверять, а точнее spoofing или enumerating.

Спуфинг

Это как раз то, о чём я писал чуть ранее. При неправильной конфигурации SMTP-сервера будет возможность отправлять письма …

  1. От имени вашей компании на сторонние адреса
  2. От сторонних адресов на сторонние адреса
  3. От имени вашего сервера на внутрениие адреса
… Это не похоже на что-то, о чём можно мечтать, так ведь?

Для нахождения потенциальных уязвимостей можно воспользоваться утилитой nslookup

Код:
>nslookup set type=mx <целевой_сайт>

После чего производится сканирование по найденным адресам. Nmap в помощь!

Nmap <адрес> -p 25,465,587

После сканирования можно вручную подключаться к smtp, в этом нам поможет telnet или netcat. На ваше усмотрение.

Теперь можно отправлять письма. Разумеется, если сервер это позволяет.

Вводим отправителя

Код:
mail from: <имя>@<домен>

и получателя

Код:
rcpt to: <имя>@<домен>

теперь покажем, что хотим отправить какие-то данные

Код:
data

здесь вводим само письмо

Код:
some text for mail spoofing test
you can enter text in multiple lines

И чтобы закончить письмо и отправить поставьте в строке одинокую точечку

Код:
.

Кстати, если вам попался сервер с шифрованием, то подключайтесь с шифрованием :)

Код:
openssl s_client -starttls smtp -connect <SMTP-server>:587

Тут всё может пойти по нескольким вариантам развития событий.
  1. Вас просто не подключит
  2. Ваз заблокирует при попытке указать в качестве источника внутренний адрес компании
  3. Сервер будет вам рад и согласен на любой движ)
Для защиты от этого используйте троицу SPF, DKIM, DMARC

SPF – проверяет поле mail from.
DKIM – защита писем с помощью ключей.
DMARC – если сообщение всё-таки отправлено, DMARC скажет получателю, что письма должны быть отклонены и уведомит вас о случившемся.

Перечисление (enum)

В SMTP существует 3 команды, которые могут вам в этом помочь. Чтобы выяснить, получится ли у вас что-то введите HELP, когда вы подключены к SMTP по telnet/nc

Если там вы увидите команды VRFY, EXPN или RCPT TO, то поздравляю, тащите свой словарик с юзерами и почтами и енумьте на здоровье. Если пользователь есть, будет код 250 или 251 или расширение псевдонима, если нет – 550. Можете даже скриптик сбацать)

Для защиты вам нужно просто отключить VRFY и EXPN. Что делать с RCPT TO? Отключить нельзя, а если б можно было, почтовый сервер стал бы бесполезен, зато можно реализовать функции catch-all-address / catch-all-rule / catch-all-server, тогда на каждый запрос будет приходить ответ 250, а уже на следующем этапе уже решите, что делать с этими мусорными письмами. Так же можно ограничить количество неудачных выполнений RCPT TO с одного адреса (если это у вас поддерживается).

На этом рассказ про SMTP закончен, по-моему вышло неплохо, завтра будет ещё пара статей. Ждите, наш спринт продолжается, а за сим я откланяюсь.
 
Мы в соцсетях: