|
|
|
Professor Seleznov
|
Как я разыграл друга с помощью spoofing-а и что из этого вышло
Дисклеймер
Эта статья — про то, как работает email spoofing изнутри, а не руководство к действию. Всё описанное проводилось в учебных целях в рамках собственной инфраструктуры. Повторять на чужих серверах без разрешения — незаконно. Иван простил.
Предыстория
Я учусь со своим другом — назовём его Иван. Умный парень, но иногда бывает заносчив и резок на слова. Однажды он меня подколол, и мне тоже захотелось ответить — но я решил пойти немного дальше, чем просто ответная колкость. У меня был опыт взаимодействия с SMTP-серверами, и я решил «отправить» ему письмо о том, что его якобы отчислили...
Как работает SMTP
Схема коммуникации почтовых серверов и клиентов
Общая схема
Когда ты отправляешь письмо из почтового клиента, происходит примерно следующее:
- Почтовый клиент подключается к SMTP-серверу.
- Проходит авторизация.
- Клиент передаёт письмо серверу.
- Сервер ищет MX-запись домена получателя.
- SMTP-сервер отправителя подключается к SMTP-серверу получателя.
- Получающий сервер проверяет SPF/DKIM/DMARC.
- Письмо попадает в inbox или spam.
Давайте разберём, как воплощалась шалость на практике. Первое допущение, мы предполагаем, что вы находитесь со своей целью в какой-то структуре или организации, которая обладает своим доменом и своим почтовым сервером. И вот мы заходим на наш официальный сайт и копируем строчку в поисковой строке без "https://".
URL ресурса
Далее мы хотим понять - какой почтовый сервер обслуживает домен. Для этого воспользуемся утилитой nslookup.
NSLOOKUP (Name Server Lookup) — это утилита командной строки, которая используется для запросов к системе DNS (Domain Name System). Она позволяет узнать, какой IP-адрес соответствует доменному имени (и наоборот), а также проверить другие параметры DNS-записей.
Нам нужен не просто IP-адрес, а адрес почтового сервера - добавим флаг -type=mx
nslookup -type=mxexample.com
Вывод команды telnet
Давайте разберем наш ответ от 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-имя.
Ответ SMTP сервера на приветствие
Пока ответ нас устраивает:
- 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]". Но у нас все уже удалось отправить и получить сообщение. Теперь подумаем - какие есть способы проверить на SPAM наше сообщение. Будь вы на месте сервера, на что бы смотрели? Здесь важно понимать: мы пытаемся передать письмо напрямую SMTP-серверу, минуя обычный почтовый клиент. В обычной ситуации пользователь отправляет письмо через почтовый клиент после прохождения аутентификации. Как минимум, два отличия получается. Отличий здесь два: наличие аутентификации и доверенный IP-адрес отправителя. Мы можем предположить, что в таком случае, если получится отправить как-то сообщение от доверенного IP, сервер не пометит его как SPAM.
Тут есть несколько способов. Первое и самое понятное — использовать внутренние сети организаций, они часто обладают более высокой репутацией для собственных почтовых серверов. Из-за этого письмо, отправленное из доверенного сегмента сети, может проходить меньше проверок. Так мы имеем шанс того, что у нас будет доверенный адрес и все у нас получится. Пробуем и получаем:
Пример не 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. Иван, кстати, действительно поверил письму - не будьте как я, будьте добрее к своим друзьям)-Источник
|
|
|
|
