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

Как я разыграл друга с помощью spoofing-а и что из этого вышло

Дисклеймер
Эта статья — про то, как работает email spoofing изнутри, а не руководство к действию. Всё описанное проводилось в учебных целях в рамках собственной инфраструктуры. Повторять на чужих серверах без разрешения — незаконно. Иван простил.

Предыстория

Я учусь со своим другом — назовём его Иван. Умный парень, но иногда бывает заносчив и резок на слова. Однажды он меня подколол, и мне тоже захотелось ответить — но я решил пойти немного дальше, чем просто ответная колкость. У меня был опыт взаимодействия с SMTP-серверами, и я решил «отправить» ему письмо о том, что его якобы отчислили…

Как работает SMTP

Общая схема

Когда ты отправляешь письмо из почтового клиента, происходит примерно следующее:

1. Почтовый клиент подключается к SMTP-серверу.

2. Проходит авторизация.

3. Клиент передаёт письмо серверу.

4. Сервер ищет MX-запись домена получателя.

5. SMTP-сервер отправителя подключается к SMTP-серверу получателя.

6. Получающий сервер проверяет SPF/DKIM/DMARC.

7. Письмо попадает в 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
Это минимальное сообщение, необходимое для прохождения этапа валидации полей.

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

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