И ещё раз здравия всем, дамы и господа. Вторая встреча, да так скоро? Чудо, не иначе. Но сейчас не об этом, а об SMTP. А при чём тут, казалось бы, smtp, ведь речь об уязвимых протоколах, а этот используется даже самыми защищёнными серверами в мире. Разумеется, при условии, что у них есть функционал почтового сервера. Да, конечно, его используют все, как и BGP, прошу не забывать (о нём была предыдущая статья).
Что ж, наш спринт продолжается, 2 статья – SMTP.
Ну, я уже частично проспойлерил, что это что-то связанное с почтой, хотя уверен, вы и сами это знали. Краткий экскурс в историю и пойдём дальше.
Этот протокол почти так же стар как и сам интернет, что уж там говорить, если корнями он уходит к программам Mail Box Protocol и SNDMSG, которые работали ещё во времена арпанета, в 70-е. Потом почту пытались передавать через FTP, выходил достаточно скверно и вот, в самом начале 1980-х, когда “арпа” сменилось на “интер” на сцену выходит Джон Постел и представляет миру SMTP, который мгновенно становится популярным. Как он развивался после нас не особо волнует, можете почитать об этом где-нибудь ещё. Нас же интересует вопрос уязвимостей.
Ну, как бы банально это не звучало, он старый. Очень старый. Его уже не обновляют, к нему делают расширения. Но видимо и к ним тоже скоро будут расширения, т.к. последнее обновление одного из них было в 2008. Конечно, большинство расширений при должной настройке шикарно работают и кажутся цитаделью. Но самая основная брешь у этой цитадели в том, что вы можете ей прикинуться. SMTP позволяет отправлять письма от его имени и хотя сейчас появились всякие проверки подлинности, но в отправителе всё равно пишется почта чья захотите, а уже после пишется, мол “ну там не факт на самом деле, я не знаю”. Подобные письма вряд ли пропустит хорошо настроенный корпоративный почтовый сервер, но во-первых, они не всегда хорошо настроены, а во-вторых, письмо может придти и на личную почту, где эта неуверенность в отправителе будет вообще, скорее всего, проигнорирована (и системой и человеком).
А делать можно два варианта, либо отправлять, либо проверять, а точнее spoofing или enumerating.
Спуфинг
Это как раз то, о чём я писал чуть ранее. При неправильной конфигурации SMTP-сервера будет возможность отправлять письма …
Для нахождения потенциальных уязвимостей можно воспользоваться утилитой nslookup
После чего производится сканирование по найденным адресам. Nmap в помощь!
Nmap <адрес> -p 25,465,587
После сканирования можно вручную подключаться к smtp, в этом нам поможет telnet или netcat. На ваше усмотрение.
Теперь можно отправлять письма. Разумеется, если сервер это позволяет.
Вводим отправителя
и получателя
теперь покажем, что хотим отправить какие-то данные
здесь вводим само письмо
И чтобы закончить письмо и отправить поставьте в строке одинокую точечку
Кстати, если вам попался сервер с шифрованием, то подключайтесь с шифрованием
Тут всё может пойти по нескольким вариантам развития событий.
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 закончен, по-моему вышло неплохо, завтра будет ещё пара статей. Ждите, наш спринт продолжается, а за сим я откланяюсь.
Что ж, наш спринт продолжается, 2 статья – SMTP.
Это что?
Ну, я уже частично проспойлерил, что это что-то связанное с почтой, хотя уверен, вы и сами это знали. Краткий экскурс в историю и пойдём дальше.
Этот протокол почти так же стар как и сам интернет, что уж там говорить, если корнями он уходит к программам Mail Box Protocol и SNDMSG, которые работали ещё во времена арпанета, в 70-е. Потом почту пытались передавать через FTP, выходил достаточно скверно и вот, в самом начале 1980-х, когда “арпа” сменилось на “интер” на сцену выходит Джон Постел и представляет миру SMTP, который мгновенно становится популярным. Как он развивался после нас не особо волнует, можете почитать об этом где-нибудь ещё. Нас же интересует вопрос уязвимостей.
Почему так грустно?
Ну, как бы банально это не звучало, он старый. Очень старый. Его уже не обновляют, к нему делают расширения. Но видимо и к ним тоже скоро будут расширения, т.к. последнее обновление одного из них было в 2008. Конечно, большинство расширений при должной настройке шикарно работают и кажутся цитаделью. Но самая основная брешь у этой цитадели в том, что вы можете ей прикинуться. SMTP позволяет отправлять письма от его имени и хотя сейчас появились всякие проверки подлинности, но в отправителе всё равно пишется почта чья захотите, а уже после пишется, мол “ну там не факт на самом деле, я не знаю”. Подобные письма вряд ли пропустит хорошо настроенный корпоративный почтовый сервер, но во-первых, они не всегда хорошо настроены, а во-вторых, письмо может придти и на личную почту, где эта неуверенность в отправителе будет вообще, скорее всего, проигнорирована (и системой и человеком).
А что делать?
А делать можно два варианта, либо отправлять, либо проверять, а точнее spoofing или enumerating.
Спуфинг
Это как раз то, о чём я писал чуть ранее. При неправильной конфигурации SMTP-сервера будет возможность отправлять письма …
- От имени вашей компании на сторонние адреса
- От сторонних адресов на сторонние адреса
- От имени вашего сервера на внутрениие адреса
Для нахождения потенциальных уязвимостей можно воспользоваться утилитой 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Тут всё может пойти по нескольким вариантам развития событий.
- Вас просто не подключит
- Ваз заблокирует при попытке указать в качестве источника внутренний адрес компании
- Сервер будет вам рад и согласен на любой движ)
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 закончен, по-моему вышло неплохо, завтра будет ещё пара статей. Ждите, наш спринт продолжается, а за сим я откланяюсь.
