Понимание атак «человек посередине» — часть 4: перехват SSL

Опубликовано: 9 Апреля, 2023

подпишитесь на нашу рассылку новостей о статьях WindowSecurity.com в режиме реального времени

Введение

До сих пор мы обсуждали отравление кэша ARP, спуфинг DNS и перехват сеанса в нашем обзоре распространенных атак «человек посередине». В этой статье мы собираемся изучить спуфинг SSL, который по своей сути является одной из самых мощных атак MITM, поскольку он позволяет использовать службы, которые люди считают безопасными. Я начну с обсуждения некоторых теорий SSL-соединений и того, что делает их безопасными, а затем покажу, как это можно использовать. Как всегда, последний раздел статьи предназначен для советов по обнаружению и предотвращению.

SSL и HTTPS

Secure Socket Layers (SSL) или Transport Layer Security (TLS) в его более современной реализации — это протоколы, предназначенные для обеспечения безопасности сетевого взаимодействия посредством шифрования. Этот протокол чаще всего ассоциируется с другими протоколами, чтобы обеспечить безопасную реализацию службы, предоставляемой протоколом. Примеры этого включают SMTPS, IMAPS и чаще всего HTTPS. Конечной целью является создание безопасных каналов в незащищенных сетях.

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

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

Рисунок 1: Процесс связи HTTPS

Процесс, показанный на рисунке 1, ни в коем случае не детализирован, но в основном работает следующим образом:

Браузер клиента подключается к http://mail.google.com через порт 80, используя HTTP.
Сервер перенаправляет клиентскую HTTPS-версию этого сайта с помощью перенаправления HTTP-кода 302.
Клиент подключается к https://mail.google.com через порт 443.
Сервер предоставляет клиенту сертификат, содержащий его цифровую подпись. Этот сертификат используется для проверки подлинности сайта.
Клиент берет этот сертификат и сверяет его со своим списком доверенных центров сертификации.
Происходит зашифрованное общение.

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

Победа над HTTPS

Этот процесс считался очень безопасным до тех пор, пока несколько лет назад не была опубликована атака, позволившая успешно перехватить процесс связи. Этот процесс включает в себя не уничтожение самого SSL, а скорее устранение «моста» между незашифрованными и зашифрованными коммуникациями.

Мокси Марлинспайк, известный исследователь безопасности, предположил, что в большинстве случаев SSL никогда не встречается напрямую. То есть в большинстве случаев SSL-соединение инициируется через HTTPS, потому что кто-то был перенаправлен на HTTPS с помощью кода ответа HTTP 302 или щелкнул ссылку, которая направляет его на сайт HTTPS, например кнопку входа. Идея состоит в том, что если вы атакуете переход от незащищенного соединения к безопасному, в данном случае с HTTP на HTTPS, вы атакуете мост и можете взломать SSL-соединение еще до того, как оно произойдет. Чтобы сделать это эффективно, Moxie создал инструмент SSLstrip, который мы будем использовать здесь.

Этот процесс довольно прост и напоминает некоторые из атак, которые мы описывали в предыдущих статьях. Он показан на рисунке 2.

Рисунок 2: Перехват соединения HTTPS

Процесс, показанный на рисунке 2, работает следующим образом:

Трафик между клиентом и веб-сервером перехватывается.
Когда встречается URL-адрес HTTPS, sslstrip заменяет его ссылкой HTTP и сохраняет сопоставление изменений.
Атакующая машина предоставляет сертификаты веб-серверу и выдает себя за клиента.
Трафик возвращается с защищенного веб-сайта и возвращается клиенту.

Этот процесс работает довольно хорошо, и, поскольку сервер все еще получает тот SSL-трафик, который ему нужен, он не видит разницы. Единственная видимая разница в пользовательском опыте заключается в том, что трафик не будет помечен как HTTPS в браузере, поэтому осведомленный пользователь сможет заметить, что что-то не так.

Использование SSLStrip

Программа, которая делает все это, называется SSLstrip и доступна здесь. Эта программа работает только в Linux, поэтому вы можете загрузить и установить ее самостоятельно, или, если вы не хотите возиться с ее установкой самостоятельно, вы можете загрузить и запустить Backtrack 4, в которой она предустановлена.

Получив доступ к SSLstrip, необходимо выполнить несколько необходимых задач. Прежде всего, используемый вами дистрибутив Linux должен быть настроен для переадресации IP. Для этого введите команду echo «1» > /proc/sys/net/ipv4/ip_forward в оболочку.

Рисунок 3: Включение IP-переадресации

Как только это будет сделано, мы должны принудительно направить весь перехваченный HTTP-трафик на порт, который будет прослушивать SSLstrip. Это делается путем изменения конфигурации брандмауэра iptables. Это делается с помощью команды iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port <listenPort>.

Рисунок 4. Настройка IPTables для правильной маршрутизации HTTP-трафика

Конечно, вы замените <listenPort> случайным портом по вашему выбору. После настройки этих элементов мы можем запустить sslstrip и настроить его для прослушивания порта, указанного с помощью команды sslstrip -l <listenPort>.

Рисунок 5: Использование sslstrip

Последним шагом в этом процессе является настройка спуфинга ARP для перехвата трафика целевого хоста. Ранее мы делали это с помощью Cain и Abel в Windows, но в данном случае воспользуемся утилитой arpspoof, встроенной в Backtrack 4. Для этого используется команда arpspoof -i <interface> -t <targetIP> <gatewayIP>.

Рисунок 6: Настройка спуфинга ARP

Используя эту команду, вы замените <interface> на сетевой интерфейс, на котором вы выполняете эти действия (eth0, eth1 и т. д.), <targetIP> на IP-адрес целевого клиента и <gatewayIP> на IP-адрес шлюза. маршрутизатор, который использует цель.

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

Защита от перехвата SSL

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

Убедитесь, что безопасные соединения используют HTTPS. Когда вы выполняете описанную здесь атаку, она удаляет безопасный аспект соединения, который виден в браузере. Это означает, что если вы войдете в свой онлайн-банкинг и заметите, что это просто стандартное HTTP-соединение, есть большая вероятность, что что-то не так. Какой бы браузер вы ни выбрали, вы должны убедиться, что знаете, как отличить безопасные соединения от небезопасных.
Сохраните онлайн-банкинг для дома. Вероятность того, что кто-то перехватит ваш трафик в вашей домашней сети, намного меньше, чем в вашей рабочей сети. Это не потому, что ваш домашний компьютер более безопасен (скажем прямо, он, вероятно, менее безопасен), но простой факт заключается в том, что если у вас есть только один или два компьютера дома, больше всего вам нужно беспокоиться с точки зрения перехвата сеанса, если ваш 14-летний сын начинает смотреть видео о взломе на YouTube. В корпоративной сети вы не знаете, что происходит дальше по коридору или в филиале на расстоянии 200 миль, поэтому количество потенциальных источников атак увеличивается. Одной из самых больших целей для перехвата сеанса является онлайн-банкинг, но этот принцип применим ко всему.
Защитите свои внутренние машины. Не для того, чтобы бить дохлую лошадь, но, повторюсь, подобные атаки чаще всего выполняются изнутри сети. Если ваши сетевые устройства защищены, то меньше шансов, что эти скомпрометированные хосты будут использованы для запуска атаки с перехватом сеанса.

Заворачивать

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