Как я разыграл друга с помощью spoofing-а и что из этого вышло
Дисклеймер
Эта статья — про то, как работает email spoofing изнутри, а не руководство к действию. Всё описанное проводилось в учебных целях в рамках собственной инфраструктуры. Повторять на чужих серверах без разрешения — незаконно. Иван простил.
Предыстория
Я учусь со своим другом — назовём его Иван. Умный парень, но иногда бывает заносчив и резок на слова. Однажды он меня подколол, и мне тоже захотелось ответить — но я решил пойти немного дальше, чем просто ответная колкость. У меня был опыт взаимодействия с SMTP-серверами, и я решил «отправить» ему письмо о том, что его якобы отчислили...
Как работает SMTP
Общая схема
Когда ты отправляешь письмо из почтового клиента, происходит примерно следующее:
Почтовый клиент подключается к SMTP-серверу.
Проходит авторизация.
Клиент передаёт письмо серверу.
Сервер ищет MX-запись домена получателя.
SMTP-сервер отправителя подключается к SMTP-серверу получателя.
Получающий сервер проверяет SPF/DKIM/DMARC.
Письмо попадает в inbox или spam.
Давайте разберём, как воплощалась шалость на практике. Первое допущение, мы предполагаем, что вы находитесь со своей целью в какой-то структуре или организации, которая обладает своим доменом и своим почтовым сервером. И вот мы заходим на наш официальный сайт и копируем строчку в поисковой строке без "https://".
Далее мы хотим понять - какой почтовый сервер обслуживает домен. Для этого воспользуемся утилитой nslookup.
NSLOOKUP (Name Server Lookup) — это утилита командной строки, которая используется для запросов к системе DNS (Domain Name System). Она позволяет узнать, какой IP-адрес соответствует доменному имени (и наоборот), а также проверить другие параметры DNS-записей.
Нам нужен не просто IP-адрес, а адрес почтового сервера - добавим флаг -type=mx
nslookup -type=mx example.com
Давайте разберем наш ответ от nslookup. Первые строчки нам не очень интересны. "Не заслуживающий доверия ответ" — значит ответ из кэша, но для MX это надёжно. Мы видим два адреса — точнее, пока домены, а не IP. Также видим числа 10 и 15 - они указывают приоритет сервера, чем меньше, тем выше.
Далее уже приступим к непосредственному ощупыванию почвы - вооружимся telnet.
Telnet — это старый сетевой протокол и утилита командной строки. Он позволяет управлять удаленными компьютерами и оборудованием (серверами, роутерами) через текстовый интерфейс.
Чтобы подключиться к почтовому серверу через telnet, нам нужно узнать помимо IP (можно сразу использовать домен, который мы узнали выше) еще и порт. Погуглив, мы узнаем, что для почтового сервера обычно используются порты:
587 — защищенный SMTP с поддержкой STARTTLS. Рекомендуется для корпоративных почтовых систем.
25 — стандартный порт для передачи между почтовыми серверами (обычно закрыт у интернет-провайдеров для клиентов)
25 порт исторически используется для межсерверной SMTP-передачи. Многие серверы всё ещё принимают на нём почту без обязательной аутентификации, поскольку доверие строится на SPF/DKIM/DMARC и репутации узла. Наша цель — проверить, принимает ли сервер SMTP-сообщения без авторизации. Если да, появляется возможность подмены отправителя.
Мы прописали нашу командуtelnet {example}.{com} 25
и получили ответ:220 st01-ex02.{domain}.{com} ESMTP MTA
Идем дальше, но перед этим немного лексикона с SMTP серверами:
EHLO — команда приветствия клиента и запроса возможностей сервера.
MAIL FROM — указание отправителя (обратный адрес).
RCPT TO — указание получателя.
DATA — начало передачи содержимого письма.
From — заголовок: от кого (видимый адрес).
To — заголовок: кому (видимый адрес).
Subject — заголовок: тема письма.
. (точка) — сигнал окончания тела письма.
QUIT — закрытие соединения с сервером.
Теперь отправим команду EHLO и какой-либо домен либо IP - так клиент представляется серверу. Технически можно указать что угодно, но корректно — свой IP или обратное DNS-имя.
Пока ответ нас устраивает:
PIPELINING — отправка нескольких команд без ожидания ответа на каждую.
SIZE 50971520 — максимальный размер письма ≈ 48.6 МБ.
STARTTLS — возможность переключиться на шифрованное соединение.
ENHANCEDSTATUSCODES — детализированные коды ошибок (например, 5.1.1).
8BITMIME — поддержка 8-битных символов (кириллица, диакритика).
Давайте попробуем оформить уже письмо вот такого рода
EHLO [11.11.11.11]MAIL FROM:<{name}@{domain}.{com}>RCPT TO:<{name}@{domain}.{com}>DATAFrom: {name}@{domain}.{com}To: {name}@{domain}.{com}Subject: SPF spoofing testTEST .QUIT
Это минимальное сообщение, необходимое для прохождения этапа валидации полей.
Смотрим и радуемся - у нас получилось отправить сообщение, давайте посмотрим что же нам пришло (я отправлял сообщение от себя себе).
Неплохо, но мы видим, что сервер охарактеризовал наше сообщение и пометил как "[SPAM]". Но у нас все уже удалось отправить и получить сообщение. Теперь подумаем - какие есть способы проверить на SPAM наше сообщение. Будь вы на месте сервера, на что бы смотрели? Здесь важно понимать: мы пытаемся передать письмо напрямую SMTP-серверу, минуя обычный почтовый клиент. В обычной ситуации пользователь отправляет письмо через почтовый клиент после прохождения аутентификации. Как минимум, два отличия получается. Отличий здесь два: наличие аутентификации и доверенный IP-адрес отправителя. Мы можем предположить, что в таком случае, если получится отправить как-то сообщение от доверенного IP, сервер не пометит его как SPAM.
Тут есть несколько способов. Первое и самое понятное — использовать внутренние сети организаций, они часто обладают более высокой репутацией для собственных почтовых серверов. Из-за этого письмо, отправленное из доверенного сегмента сети, может проходить меньше проверок. Так мы имеем шанс того, что у нас будет доверенный адрес и все у нас получится. Пробуем и получаем:
Это практически победа. Чтобы все было более правдоподобно, можно дополнительно настроить заголовки письма и достичь практически идентичного результата!
Теперь разберем все под капотом - почему такое у нас получилось сделать. Для того, чтобы больше узнать о самом письме, мы откроем сведения о нем.
Смотрим и находим множество информации, которая нам мало что говорит. Давайте сравним наше письмо с реальным письмом
Здесь мы видим, что проверок меньше и явно другой вид авторизации - Internal vs Anonymous. Несмотря на то, что проверок было больше, мы смогли без авторизации на домене отправить письмо, которое практически не отличается от реального.
Короткий ликбез по типам проверок писем:
SPF (Sender Policy Framework)
DNS-запись домена, которая указывает список IP-адресов, с которых разрешено отправлять письма от его имени. Когда письмо приходит — принимающий сервер смотрит: «этот IP есть в списке доверенных?». Если нет — письмо помечается как подозрительное или отклоняется. В нашем случае мы отправляли с чужого IP — SPF это и поймал, отсюда пометка [SPAM].
DKIM (DomainKeys Identified Mail)
Цифровая подпись письма. Сервер отправителя подписывает каждое письмо приватным ключом, публичный ключ хранится в DNS домена. Принимающий сервер проверяет подпись — если она не совпадает или отсутствует, письмо вызывает подозрение. Подделать подпись без приватного ключа практически невозможно.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
Политика, которая объединяет SPF и DKIM и говорит серверу, что делать, если проверки не прошли. Три варианта действий:
none— только мониторинг, письмо доходитquarantine— отправить в спамreject— полностью отклонить
Также отправляет владельцу домена отчёты о подозрительных письмах.
Самое главное в сведениях о фальшивом письме:
X-MS-Exchange-Organization-AuthAs: Anonymous— сервер сам признаёт, что письмо отправлено анонимно, без авторизации.
X-KSMG-AntiSpam-Auth: dkim=none— DKIM не прошёл проверку, подписи нет. При этом письмо всё равно дошло.
X-KSMG-AntiSpam-Rate: 20— спам-рейтинг 20, порог не превышен, письмо не заблокировано.
X-KSMG-AntiSpam-Status: not_detected— Kaspersky его не поймал.
Формально причин отклонить письмо было достаточно — но оно всё равно дошло.
Почему SMTP вообще позволяет это делать
SMTP создавался в эпоху доверенного интернета, когда:
серверов было мало;
злоумышленников почти не существовало;
основной задачей была доставка почты, а не защита от фишинга.
Поэтому изначально SMTP не проверял:
кто именно отправляет письмо;
имеет ли клиент право указывать конкретный From;
совпадает ли домен отправителя с IP-адресом.
Как же защищаться?
Три механизма защиты — SPF, DKIM и DMARC — существуют давно и работают надёжно. Проблема не в их отсутствии, а в том, что none в DMARC — это не защита, это наблюдение. Пока политика стоит на none — письмо доходит несмотря ни на что. Поэтому для большей защиты достаточно будет выставить v=DMARC1; p=reject для своих доменов .
P.S. Иван, кстати, действительно поверил письму - не будьте как я, будьте добрее к своим друзьям)