Атака «человек посередине»: как перехватывают данные

В зависимости от сценария целью становятся пароли, токены доступа, cookie сессии или сами передаваемые данные.

Механизм не сводится к подключению к открытой Wi-Fi-сети. Для перехвата нужно занять подходящую позицию в сетевом обмене или заставить одну из сторон установить соединение с поддельным узлом. А если приложение некорректно проверяет сертификат сервера, защищённое на вид соединение тоже может оказаться уязвимым.

Что означает MITM-атака

MITM — сокращение от английского man-in-the-middle, «человек посередине». NIST определяет эту атаку как ситуацию, в которой злоумышленник располагается между двумя участниками связи, чтобы перехватывать или изменять передаваемые данные.

Обычный обмен выглядит так: клиент обращается к серверу, сервер отвечает клиенту. При атаке трафик проходит через контролируемую злоумышленником систему. Она может передавать сообщения дальше, поэтому соединение внешне сохраняется. В зависимости от возможностей атакующего данные можно только наблюдать, выборочно менять или блокировать.

Для атаки важны три условия:

• злоумышленник получает сетевую позицию, позволяющую видеть или перенаправлять трафик;
• устройство или пользователь доверяет ложному маршруту, точке доступа либо узлу;
• защита соединения не останавливает перехват: например, приложение не проверяет сертификат или используется устаревший протокол.

Наличие у злоумышленника позиции в сети ещё не означает, что он автоматически читает любой трафик. Современное TLS-шифрование ограничивает доступ к содержимому, если соединение настроено корректно и клиент проверяет подлинность сервера. Но это не отменяет атак на маршрутизацию, подмену узлов, ошибки реализации и кражу данных на конечных устройствах.

Для MITM критична не сама близость к сети, а возможность управлять путём трафика и обойти проверки подлинности.

Как работает перехват сетевого трафика

Сначала атакующий добивается того, чтобы сообщения между клиентом и сервером проходили через него. Затем использует положение в цепочке связи: анализирует доступные данные, пытается воздействовать на соединение или пересылает трафик дальше.

Один из вариантов — изменить разрешение сетевых адресов. Компьютеру нужно определить, куда отправить пакет. В локальной сети для этого могут использоваться ARP-запросы; для поиска узлов и имён — DNS или LLMNR. Если злоумышленнику удаётся подменить ответ или повлиять на таблицу адресов, устройство может направить трафик не туда, куда намеревалось.

Другой вариант — воздействовать на конфигурацию сети через DHCP. Клиент получает от DHCP-сервера параметры подключения, включая сетевые настройки. Подмена ответов или появление неавторизованного сервера может привести к тому, что устройства начнут использовать контролируемый атакующим маршрут или DNS-сервер.

Есть и сценарий с поддельной точкой доступа. Она может копировать название легитимной сети и принимать подключения устройств. Если пользователь или устройство выбирает её, атакующий получает возможность наблюдать за сетевым обменом. Само подключение к общественной сети не доказывает, что трафик перехватывают. Риск зависит от конфигурации, поведения клиента и защиты конкретного соединения.

MITRE ATT&CK относит подобные сценарии к технике T1557 и выделяет четыре подтипа:

1. Отравление разрешения имён и SMB relay. Атакующий влияет на разрешение имён или использует перенаправление аутентификационного обмена, чтобы получить данные либо выполнить дальнейшие действия.

2. Отравление ARP-кеша. Устройство получает неверное соответствие между сетевым адресом и физическим адресом узла и может отправлять трафик через атакующую систему.

3. Подмена DHCP. Неавторизованный DHCP-ответ влияет на сетевые параметры клиента.

4. Поддельная точка доступа, или Evil Twin. Злоумышленник создаёт точку доступа, похожую на доверенную сеть.

Эти подтипы описывают разные способы занять позицию между участниками. Один механизм не объясняет все MITM-атаки: методы зависят от сети, протоколов и цели. В частности, перехват может применяться для сбора учётных данных, токенов доступа и cookie сессии. Если атакующий получает действующий токен, одного факта смены пароля может быть недостаточно: потребуется завершить активные сессии и проверить связанные учётные записи.

Почему HTTPS не закрывает все сценарии

HTTPS использует TLS для защиты данных при передаче между браузером и сервером. Клиенту при этом нужно убедиться, что он установил соединение именно с нужным сервером. Для этого браузер и приложение проверяют сертификат и его соответствие адресу.

Если проверка работает корректно, подставить собственный сертификат незаметно для клиента сложно. Браузер может показать предупреждение о недоверенном или недействительном сертификате. Такое предупреждение требует проверки, но само по себе не доказывает, что идёт атака: причиной могут быть ошибки настройки, неверные дата и время на устройстве или проблемы в инфраструктуре сертификатов.

В сценарии с перехватом могут возникнуть два отдельных TLS-соединения. Браузер устанавливает одно соединение с системой злоумышленника, а та — другое, с веб-сервером. Если клиент принимает сертификат атакующего или приложение не проверяет его должным образом, посредник может получить доступ к данным до их повторного шифрования для сервера.

Особенно значима проверка сертификата в мобильных и настольных приложениях. NIST Mobile Threat Catalogue указывает: если приложение не проверяет сертификат сервера, атакующий может выдать себя за сервер. Это способно открыть доступ к незашифрованным данным в передаче и дать возможность менять их по пути.

Наконец, MITM может опираться на понижение версии SSL/TLS или алгоритма шифрования. Смысл такого воздействия — добиться использования более слабого варианта защиты, если конфигурация клиента и сервера это допускает. Поэтому спецификация TLS должна исключать устаревшие протоколы и слабые наборы шифров, а приложение — отклонять недействительную цепочку сертификатов.

Что может попасть к атакующему

Объём доступных данных зависит от сценария. Нельзя заранее назвать универсальную величину ущерба: она определяется тем, какой трафик проходит через контролируемый узел и какие проверки выполняют клиент и сервер.

При удачном перехвате в поле зрения могут оказаться:

• учётные данные, если они передаются без надлежащего шифрования или попали в доступный атакующему обмен;
• токены доступа, которыми приложение подтверждает права пользователя;
• cookie сессии, позволяющие поддерживать авторизованное состояние;
• содержимое запросов и ответов, если соединение не защищено корректно;
• изменённые данные, если атакующий может вмешаться в обмен, а клиент не обнаруживает подмену.

Шифрование трафика защищает его содержимое в пути, но не исправляет компрометацию самого устройства, ошибку в приложении или кражу токена после его использования. Поэтому защита строится на нескольких уровнях: сетевой сегмент, защищённый транспорт, корректная проверка сертификата, контроль сессий и защита конечных устройств.

Как снизить риск MITM-атаки

Защитные меры должны закрывать и сетевую подмену, и ошибки проверки подлинности. На уровне сети задача состоит в том, чтобы затруднить несанкционированное перенаправление трафика. На уровне приложений — не позволить принять чужой сервер за настоящий.

Для организации последовательность действий может выглядеть так:

1. Зашифровать веб-трафик с учётными данными. Использовать актуальную конфигурацию TLS для сервисов и не допускать передачи паролей по незашифрованным соединениям.

2. Отключить ненужные устаревшие протоколы. Старые механизмы расширяют поверхность атаки и могут облегчить понижение уровня защиты.

3. Проверять сертификаты в приложениях. Клиент должен валидировать сертификат сервера и корректно обрабатывать ошибки. Отключение этой проверки ради обхода ошибки создаёт прямой риск перехвата.

4. Защитить беспроводную инфраструктуру. Управлять доступом к точкам, контролировать появление посторонних узлов и использовать защищённые настройки Wi-Fi.

5. Контролировать сетевые параметры. Неавторизованные DHCP- и DNS-ответы, аномальные изменения маршрутов и неожиданные ARP-соответствия требуют расследования.

6. Сократить срок жизни сессий и защищать токены. Для обнаруженного инцидента предусмотреть отзыв токенов и завершение активных сессий, а не только смену пароля.

7. Обучить пользователей реагировать на предупреждения сертификата. В корпоративной среде инструкции должны запрещать обход таких сообщений без проверки причины.

Для персональной защиты базовая дисциплина та же. Подключаться к известным сетям, не игнорировать предупреждения браузера, обновлять операционную систему и приложения. Если публичная сеть требует входа через веб-страницу, не следует считать само наличие страницы подтверждением её подлинности. Проверяйте адрес и избегайте передачи чувствительных данных в соединениях, которые вызывают ошибки безопасности.

Проверка сертификата и шифрование особенно важны для приложений, которые обрабатывают персональные данные или платежи. Ошибка здесь сопоставима с другими дефектами на стыке клиента и сервера: например, в цифровой упаковке продукта защита данных должна согласовываться с тем, как устроены маркировка и упаковка уходовой косметики. В обоих случаях спецификация задаёт требования, а реализация определяет, закрывает ли система реальные риски.

Ошибка сертификата — сигнал остановиться и разобраться. Нажатие кнопки «продолжить» превращает предупреждение в обход контроля.

Как распознать возможную подмену

Пользователь редко может доказать MITM-атаку по одному признаку. Прикладная диагностика требует сопоставить события на устройстве, в сети и на серверной стороне. Но есть сигналы, которые нельзя игнорировать:

• браузер сообщает о недействительном, просроченном или недоверенном сертификате;
• приложение внезапно перестаёт подключаться после обновления сети или сертификатов;
• устройство подключено к точке доступа с неожиданным именем, похожим на корпоративную или публичную сеть;
• меняются сетевые параметры, DNS-серверы или маршрут без понятной причины;
• сервис фиксирует входы или действия, которых пользователь не совершал;
• сессии завершаются неожиданно, а повторная авторизация происходит на подозрительной странице.

Ни один пункт сам по себе не устанавливает причину. Например, ошибка сертификата может появиться из-за неверных часов или ошибки конфигурации сервера. А необычный DNS-адрес может быть штатной частью корпоративной сети. Для анализа нужны журналы клиентских устройств, сетевого оборудования и серверов, а также сведения о времени и месте события.

Если подозрение связано с учётной записью, действовать следует с доверенного устройства и через проверенный канал. Сменить пароль, отозвать активные сессии и токены, проверить методы восстановления доступа и связанные приложения. При инциденте в организации следует сохранить журналы и сведения о сетевой конфигурации до того, как перезагрузка или изменение настроек затруднит анализ.

Ограничения защиты

TLS не защищает данные после расшифрования на конечном устройстве. Если устройство заражено вредоносным ПО, атакующий может получать информацию уже на стороне клиента. Аналогично, защищённое соединение не спасает от фишингового сайта с действительным сертификатом: шифрование подтверждает соединение с конкретным доменом, но не доказывает, что пользователь выбрал правильный домен.

Многофакторная аутентификация снижает риск использования одного украденного пароля, но не является универсальным барьером. Токены и активные сессии остаются отдельной целью. Защиту нужно проектировать по всей цепочке: от ввода данных до управления сессией и журналирования действий.

Для системного контроля в инфраструктуре фиксируют конфигурацию TLS, список разрешённых точек доступа, сетевые параметры, события аутентификации и изменения сертификатов. Такой бенчмарк помогает выявлять отклонения от спецификации. При этом отсутствие срабатываний не доказывает отсутствия перехвата: мониторинг зависит от охвата сети и качества телеметрии.

Атака «человек посередине» использует слабое место в маршруте, доверии или проверке сертификата. Защита держится на трёх технических условиях: трафик шифруется, клиент проверяет подлинность сервера, устаревшие протоколы отключены. Если хотя бы одно условие не выполнено, риск перехвата и подмены данных остаётся.