Как я разыграл друга с помощью 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}>
DATA
From: {name}@{domain}.{com}
To: {name}@{domain}.{com}
Subject: SPF spoofing test
TEST
.
QUIT
Это минимальное сообщение, необходимое для прохождения этапа валидации полей.

Процесс отправки сообщения с помощью telnet

Смотрим и радуемся - у нас получилось отправить сообщение, давайте посмотрим что же нам пришло (я отправлял сообщение от себя себе).

Неплохо, но мы видим, что сервер охарактеризовал наше сообщение и пометил как "[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. Иван, кстати, действительно поверил письму - не будьте как я, будьте добрее к своим друзьям)

Дорогая, давай займемся spoofing-ом