перехват трафика android приложения
Перехват HTTPS-траффика между Android-устройством и внешним сервером
Иногда бывает любопытно подсмотреть, что пересылают туда-сюда разные Android-приложения по HTTP и HTTPS протоколам. Иногда даже при разработке собственного ПО удобно видеть весь трафик в реальном времени. Для реализации этих задач давно придумано много хороших программ, таких, к примеру, как Charles или Fiddler2. На самом деле их намного больше, вот только две вышеуказанные дают возможность нормально просматривать не только HTTP, но и HTTPS.
Трудности начинаются тогда, когда речь заходит о перехвате трафика между Андроид-устройством и внешним сервером. В случае незашифрованного (HTTP-протокол) трафика всё весьма тривиально (вот и инструкция есть) — разрешаем Fiddler2 внешние соединения, в Андроиде устанавливаем прокси сервером адрес нашей машины с Fiddler2 — и вуаля, всё работает. А вот на настройку перехвата HTTPS-трафика у меня ушло чуть больше времени.
Теория
Итак, в чём же сложность? В том, что при использовании протокола HTTPS клиент по-умолчанию проверяет, а действительно ли тот сервер, к которому он подключился, является нужным. Для этого используются сертификаты. И вот у настоящего сервера этот сертификат, понятное дело, тоже настоящий и соответствует открытому URL, а вот у нашего прокси — нет. Для решения этой проблемы в десктопных операционных системах в таких случаях есть возможность сгенирировать в Fiddler2 поддельный сертификат, импортировать его в доверенные — и теперь клиент всегда будет верить, что соединение с Fiddler2 вполне безопасно. К сожалению, с мобильным устройством такой легкий финт ушами не прошел.
Во-первых, возможности импортировать внешний сертификат в Андроиде версий младше 4.0 нет. Есть какие-то не внушающие доверия варианты с рутоваными девайсами — но это не наш путь.
Во-вторых, в Андроид даже версии 4.0 импортировать сертификат Fiddler2 не получается. Дело в том, что генерируемый по-умолчанию сертификат не соответствует каким-то там Андроидовским критериям безопасности и не устанавливается. Его нужно генерировать специальным образом.
В-третьих, совсем даже не факт, что все подряд программы сразу поверят поддельному сертификату. Есть нюансы.
Практика
Итак, с браузером получилось. К сожалению, не все программы столь доверчивы, как браузер. К примеру, в моей собственной софтине, где я использую Apache HTTP Client, способ не прокатил — плевал апачевский клиент на доверенные сертификаты операционки. В этом случае мне пришлось отключить эту проверку вручную, таким вот образом:
где EasySSLProtocolSocketFactory взят отсюда и разрешает доверие к любым сертификатам.
Не безопасно, только для отладки!
После этого трафик моей программы стал также успешно отображаться в Fiddler2.
Перехват и анализ трафика со смартфона при помощи Wireshark
Этот вид мониторинга может показаться агрессивным, однако имейте ввиду, что ваш провайдер также хранит эти данные в логах и имеет право продавать информацию на сторону.
Допустим, нужно узнать, какие приложения используются на телефоне. Если вы находитесь в одной Wi-Fi сети с целевым устройством, задача решается очень просто. Достаточно запустить Wireshark и сконфигурировать несколько параметров. Мы будем использовать эту утилиту для расшифровки трафика, зашифрованного при помощи WPA2, и после анализа выясним, какие приложения запущены на телефоне.
Хотя сеть с шифрованием лучше, чем без, разница исчезает, когда злоумышленник и вы находитесь в одной сети. Если кто-то еще знает пароль к Wi-Fi сети, которую вы используете, при помощи WireShark легко выяснить, чем вы занимаетесь сию секунду. Кроме того, злоумышленник может узнать все приложения, запущенные на телефоне, и сосредоточиться на тех, которые потенциально могут быть уязвимыми.
Дешифровка зашифрованных пакетов
Когда в вашей Wi-Fi сети используется шифрование при помощи технологии WPA2, безопасность сессии основана на двух составляющих. Во-первых, пароль, используемый для генерации гораздо более длинного числа (PSK или pre-shared key). Во-вторых, собственно само рукопожатие, происходящее во время установки соединения. Если злоумышленник получает PSK к Wi-Fi и наблюдает, как вы подключаетесь к сети (или на некоторое время сбрасывает ваше соединение), то впоследствии сможет расшифровать ваш Wi-Fi трафик и узнать, чем вы занимаетесь.
Содержимое HTTPS сайтов будет недоступно, однако HTTP сайты и другие небезопасные HTTP запросы приложений на вашем телефоне будут в открытом виде. Вроде на первый взгляд не такая большая удача, однако очень быстро можно узнать многое о типе устройства, и какие приложения запущены. Кроме того, будут видны DNS запросы для резолвинга доменов, что поможет в идентификации активных приложений и сервисов.
Как работает схема
Для реализации атаки необходимо выполнение нескольких условий. Во-первых, нужен пароль. Кроме того, нужно быть рядом с жертвой для перехвата трафика и уметь отключить целевое устройство от сети для повторного подключения. Мы запустим Wireshark, выполним настройки, связанные с дешифровкой Wi-Fi пакетов, добавим PSK и дождемся EAPOL пакетов с целевого устройства, пытающегося подключиться к сети.
Для анализа поведения целевого устройства будем использовать фильтры с целью выделения искомых DNS и HTTP пакетов. Полный список доменов, для которых устройство выполняет резолвинг, также будет доступен после завершения перехвата. Эта информация пригодится для выяснения, какие службы используются даже в фоновом режиме.
Что понадобится
Вам понадобится карта беспроводного сетевого адаптера с режимом мониторинга (беспроводной сети) и смартфон с iOS или Android, подключенный к Wi-Fi, которую вы собираетесь мониторить. Вы можете попрактиковаться на открытой сети, чтобы примерно понимать, какие результаты вы получите, поскольку вначале расшифровка может не сработать. Кроме того, вам нужно знать пароль и имя сети, которую вы хотите мониторить. В этом случае вы сможете вычислить ключ PSK, позволяющий дешифровать трафик в режиме реального времени.
Шаг 1. Загрузка Wireshark и подключение к Wi-Fi сети
Загрузите и установите Wireshark, после чего подключитесь к целевой Wi-Fi сети. Если вы планируете использовать PSK, а не сетевой ключ, нужно сделать вычисления при помощи WPA PSK Generator, поскольку во время перехвата у вас может не быть доступа к интернету (зависит от используемой карты).
После установки откройте Wireshark и взгляните на перечень сетевых интерфейсов. Перед началом перехвата нам понадобится настроить некоторые опции, чтобы карта перехватывала в нужном режиме.
Рисунок 1: Перечень сетевых интерфейсов
Шаг 2. Настройка перехвата в Wireshark
В меню Wireshark кликните иконку в виде шестеренки, чтобы зайти в раздел «Capture options»
Рисунок 2: Интерфейс Wireshark
Появится окно Capture Interfaces (Интерфейсы перехвата), как показано на рисунке ниже.
Рисунок 3: Перечень интерфейсов
Шаг 3. Перехват и сканирование EAPOL пакетов
Если вы не подключены к сети, где находится цель, то не увидите ни одного пакета, поскольку можете оказаться в другом случайном канале. Причина заключается в неспособности Wireshark на переключение канала, в котором находится беспроводной сетевой адаптер.
Рисунок 4: Перехваченные пакеты
Шаг 4. Дешифровка трафика при помощи PSK
Теперь, когда у нас появились рукопожатия, можно приступать к расшифровке трафика. Вначале нужно добавить сетевой пароль или PSK. Зайдите в выпадающее меню «Wireshark» и выберите раздел «Preferences». Затем кликните на «Protocols».
Рисунок 5: Настройки, связанные с протоколами
В разделе Protocols выберите «IEEE 802.11» и кликните на флажок «Enable decryption». Для добавления сетевого ключа кликните на «Edit», рядом с надписью «Decryption keys». В открывшемся окне добавьте пароли и PSK.
Рисунок 6: Активация дешифровки
В меню выберите «wpa-psk» и скопируйте ваш ключ. Нажмите кнопку Tab и сохраните изменения, кликнув на «OK».
Рисунок 7: Добавление ключа
По завершению процедуры кликните на «OK» в разделе Preferences. Теперь Wireshark должен пересканировать и попробовать дешифровать все перехваченные пакеты. По некоторым причинам эта схема может не сработать. У меня практически всегда работало при наличии качественного рукопожатия (EAPOL) и при переключении между сетевым паролем и PSK. В случае успешной расшифровки мы можем перейти к следующему шагу и проанализировать трафик для выяснения, какие приложения работают на устройстве.
Шаг 5. Сканирование DNS и HTTP пакетов
После снятия защиты с трафика, можно приступать к расшифровке пакетов и выяснению, чем занимаются устройства в Wi-Fi сети, по которым получены рукопожатия, в режиме реального времени.
1. DNS запросы
Просмотр интересных пакетов начнем с DNS запросов, используемых приложением для проверки неизменности IP-адресов, к которым происходит подключение. Обычно происходит обращение к именам доменов, содержащих имена приложений, что значительно упрощает идентификацию программы, которая работает на iPhone и Android и выполняет запросы.
Для отображения этих запросов воспользуемся фильтрами dns и http, позволяющих выявить наиболее явные следы, оставляемые приложениями в сети. Вначале в поле фильтра введите dns и нажмите Enter. Если не сработает, попробуйте переключаться между PSK и паролем несколько раз. Иногда помогает.
Рисунок 8: Перечень DNS запросов
Если ваша цель любит бывать на сайтах знакомств, вы можете увидеть ответ ниже. Например, Tinder обращается к домену Tindersparks.com. Этот запрос – один из наиболее очевидных. Кроме того, могут быть подключения ко многим другим похожим сервисам.
Рисунок 9: Пример обращения к домену Tindersparks.com
Использование приложения Signal – хорошая идея, но в связке с VPN еще лучше. Причины? Даже при открытии Signal происходит взаимообмен, показанный ниже, что свидетельствует о коммуникации через мессенджер с шифрованием.
Рисунок 10: Пример запроса мессенджера Signal
Во время прослушивания песен в приложении Shazam создаются следующие запросы:
Рисунок 11: Пример запроса во время прослушивания песен в Shazam
При открытии Uber создаются запросы следующего содержания:
Рисунок 12: Пример запроса при открытии приложения Uber
Ниже виден эффект, возникающий при открытии Venmo (приложение для перевода денежных средств). Удачный момент для перенаправления запроса куда-нибудь в другое место.
Рисунок 13: Пример запроса, отправляемый приложением Venmo
2. HTTP пакеты
Далее мы можем наблюдать несколько небезопасных web-запросов, используя фильтр http, которые содержат параметры навроде useragent, позволяющих опознать тип устройства. Эту информацию можно посмотреть, кликнув на пакете и зайдя во вкладку «Hypertext Transfer Protocol».
Рисунок 14: Пример содержимого раздела Hypertext Transfer Protocol у пакета
В этом примере видны небезопасные HTTP запросы к серверу чата. Что же получается? Простое изучение содержимого пакета и резолвинг имени домена говорит об использовании приложения WeChat, установленного на телефоне. Более того, исходящие сообщения шифруются не полностью.
Рисунок 15: Сайт приложения WeChat
Если мы хотим увидеть всю историю резолвинга, то можем зайти во вкладку «Statistics» и выбрать «Resolved Addresses» для просмотра всех доменов, которые были преобразованы во время перехвата. Здесь должен быть полный список служб, к которым подключалось устройство через запущенные приложения.
Рисунок 16: Список доменов, к которым проходило подключение
Вышеуказанный список позволяет еще быстрее понять, что представляет собой целевое устройство.
Заключение
Этот вид мониторинга может показаться агрессивным, однако имейте ввиду, что ваш провайдер также хранит эти данные в логах и имеет право продавать информацию на сторону. Если вы хотите защититься от слежки подобного рода, начните пользоваться VPN, что позволяет скрыть даже локальный трафик при помощи надежного шифрования. В других местах, где вы, вероятно, можете делать что-то конфиденциальное через ненадежное соединение, используйте сотовую систему передачи данных для предотвращения подобного рода атак.
Надеюсь, это руководство, посвященное перехвату Wi-Fi трафика при помощи Wireshark, вам понравилось.
Анализ трафика Android-приложений: обход certificate pinning без реверс-инжиниринга
Иногда нужно исследовать работу бэкенда мобильного приложения. Хорошо, если создатели приложения не заморачивались и все запросы уходят по «голому» HTTP. А что, если приложение для запросов использует HTTPS, и отказывается принимать сертификат вашего корневого удостоверяющего центра, который вы заботливо внедрили в хранилище операционной системы? Конечно, можно поискать запросы в декомпилированом приложении или с помощью реверс-инжиниринга вообще отключить применение шифрования, но хотелось бы способ попроще.
Что такое certificate pinning?
Даже при использовании HTTPS пользователь не защищен от атак «Человек посередине», потому что при инициализации соединения злоумышленник может подменить сертификат сервера на свой. Трафик при этом будет доступен злоумышленнику.
Справиться с такой атакой поможет certificate pinning. Эта защитная мера заключается в том, что разработчик «зашивает» в приложение доверенный сертификат. При установке защищенного соединения приложение проверяет, что сертификат, посылаемый сервером, совпадает с (или подписан) сертификатом из хранилища приложения.
Обход certificate pinning
В качестве подопытного выберем приложение Uber. Для анализа HTTP-трафика будем использовать Burp Suite. Также нам понадобится JDK и Android SDK (я использую все последней версии). Из Android SDK нам понадобится только утилита zipalign, так что при желании можно не скачивать весь SDK, а найти ее на просторах интернета.
Заранее облегчим себе жизнь, добавив следующие пути к нужным утилитам в переменную окружения PATH:
Открываем Burp, заходим в Proxy – Options – Add и добавляем Proxy Listener на интерфейсе, который будет доступен подопытному Android-устройству (или эмулятору). На устройстве в свою очередь настраиваем используемую Wi-Fi сеть на использование только что включенного прокси.
Скачаем apk-файл через apkpure.com, установим приложение на устройство и попытаемся войти в свой аккаунт – приложение зависнет на этапе аутентификации.
В логах Burp Suite (вкладка Alerts) при этом мы увидим множественные отчеты о неудачных SSL-рукопожатиях. Обратите внимание на первую строчку – именно через сервер cn-geo1.uber.com в моем случае осуществляется аутентификация, поэтому и не удается войти в приложение.
Дело в том, что Burp Suite при перехвате HTTPS-соединений (а мы помним, что все соединения устройства проксируются через него) подменяет сертификат веб-сервера на свой, который, естественно, не входит в список доверенных. Чтобы устройство доверяло сертификату, выполняем следующие действия. В Burp заходим в Proxy – Options и нажимаем Import/export CA certificate. Далее в диалоге выбираем Export Certificate. Копируем сертификат на устройство, переходим в Настройки – Безопасность – Установить сертификаты и устанавливаем наш сертификат в качестве сертификата для VPN и приложений.
Опять пытаемся войти в свой аккаунт. Сейчас приложение Uber сообщит нам только о неудачной попытке аутентификации – значит прогресс есть, осталось только обойти certificate pinning.
Откроем приложение в вашем любимом архиваторе как zip-архив. В папке res/raw можно заметить файл с говорящим названием ssl_pinning_certs_bk146.bks.
По его расширению можно понять, что Uber использует хранилище ключей в формате BouncyCastle (BKS). Из-за этого нельзя просто заменить сертификат в приложении. Сначала нужно сгенерировать BKS-хранилище. Для этого качаем jar для работы с BKS.
Теперь генерируем BKS-хранилище, которое будет содержать наш сертификат:
На вопрос о доверии сертификату отвечаем «yes». Опять открываем apk в архиваторе и заменяем оригинальное хранилище на наше (сохраняем при этом оригинальное название).
Но на этом все не заканчивается. Каждый apk должен быть подписан сертификатом разработчика. К счастью, это делается не для обеспечения безопасности, а для идентификации приложений, поэтому для наших исследовательских целей мы вполне можем использовать и недоверенный сертификат.
Удаляем из apk папку META-INF со старой подписью приложения и приступаем к генерации новой.
Создаем хранилище ключей и генерируем в нем ключ для подписи apk:
Подписываем только что сгенерированным ключом наш APK:
Теперь осталось выровнять данные в архиве по четырехбайтной границе:
Fiddler-инструмент для анализа трафика мобильных приложений. Выявляем уязвимости
Разработчики большое внимание уделяют удобству и внешнему виду, однако вопросам безопасности не всегда уделяется должное внимание. Недостаточная защищенность приложения увеличивает репутационные риски для компании-разработчика, а утечка конфиденциальных пользовательских данных негативно сказывается на его деловой репутации.
Большинство современных мобильных приложений построены на клиент-серверной архитектуре. Как правило, клиент функционирует под управлением одной из популярных мобильных ОС – Android или iOS, и обменивается данными с сервером. Использование открытых незащищенных протоколов передачи данных многократно увеличивают риски компрометации передаваемого трафика. Но даже защищенные соединения не всегда дают 100% гарантию надежности сохранности данных.
В данной статье мы познакомимся с инструментом Fiddler, позволяющим перехватывать и анализировать весь трафик между клиентом и сервером. Данный инструмент может помочь выявить уязвимости в процессе клиент-серверного взаимодействия мобильного приложения.
(Если вы уже работали с этим инструментом, делитесь опытом в комментариях)
Для начала установите Fiddler на ПК или ноутбук. Убедитесь, что ПК/ноутбук и смартфон находятся в одной сети (например, подключив устройства к одному wifi-роутеру). Это условие является обязательным, т.к. устройства не увидят друг друга. Проверить связь между устройствами можно через команду ping.
Далее, убедитесь, что Fiddler может принимать входящие соединения:
Настройка устройства на базе Android
Убедитесь, что Fiddler запущен и брандмауэр Windows отключен, далее на Android-устройстве выполните шаги:
После нажатия на кнопку «Сохранить» весь трафик смартфона должен быть виден в окне Fiddler.
Настройка устройств на базе iOS
Убедитесь, что Fiddler запущен и брандмауэр Windows отключен, далее на iOS-устройстве выполните шаги:
После нажатия на кнопку «Сохранить» весь трафик смартфона должен быть виден в окне Fiddler.
С этими настройками возможен перехват только незащищенного HTTP-трафика. Для работы с защищенным HTTPS-трафиком потребуется установка корневого сертификата на устройствах, а также дополнительная настройка Fiddler.
Для Android: скачайте FiddlerRoot certificate, откройте его, установите и задайте имя.
Для iOS: скачайте FiddlerRoot certificate, откройте его, нажмите «разрешить», после чего перейдите в Настройки → Профиль загружен → Установить. Далее в Настройках → Основные → Об этом устройстве → Доверие сертификатам → найдите сертификат и сделайте его доверенным.
После этого вы сможете работать и анализировать защищенный HTTPS-трафик в Fiddler.
Почувствуйте себя хакером с этими приложениями для Android
Android является, пожалуй, самой популярной операционной системой в мире. По всей видимости, именно это вдохновило различных разработчиков на создание ряда хакерских приложений для этой ОС. Скажем сразу, что мы против взломов и разного рода проникновения в частную жизнь пользователей. Однако знать о наличии такого рода программ определенно стоит. В крайнем случае вы сможете разыграть своих друзей. А лучше — приглашайте друзей в наш новостной канал в Телеграм.
Android-смартфон — это не просто удобный гаджет, но еще и инструмент для взлома
AndroRAT — Для начинающих хакеров
Название AndroRAT состоит из двух слов Android и RAT (Remote Administrative Tools). Приложение может дать вам контроль над системой Android удаленно и позволяет получить информацию об ОС. Это приложение для Android работает сразу после загрузки. Таким образом, пользователю не нужно взаимодействовать с сервисом. Приложение предоставляет вам возможность инициировать подключение с помощью звонка на телефон или СМС. AndroRAT может собрать данные о контактах, сообщениях и местоположении. А еще можно, например, удаленно делать снимки и записывать видео с камеры.
zANTI — Сканируем безопасность сетей
zANTI — это пакет программного обеспечения для сканирования сетей. Этот инструментарий позволяет имитировать среду взлома для обнаружения уязвимостей, открытых портов и так далее. По факту zANTI — это, можно сказать, антихакерский инструмент и лишь вам решать, что делать с обнаруженными «дырами» в системе безопасности после того, как вы их найдете.
FaceNiff — Перехват сетевого трафика
FaceNiff — это приложение для взлома на Android, которое позволяет вам перехватывать и перенаправлять сетевой трафик Wi-Fi. Зачем это нужно? Ну, например, таким образом очень часто воруют пароли от почтовых ящиков и социальных сетей. Причем зачастую программы наподобие FaceNiff работают в открытых сетях, так что будьте осторожны, когда подключаетесь к неизвестной точке доступа в, скажем, торговом центре.
Shark for Root — Поиск уязвимостей и не только
Shark for Root — это, можно сказать, продвинутый вариант FaceNiff. Он позволяет нe только перехватывать трафик Wi-Fi сетей, но и умеет работать с 3G. Опять же, Shark for Root — это изначально программа для поиска уязвимостей, а не для взлома устройств. Подобными функциями обладает и приложение Droidsheep.
DroidBox — Изучаем приложения изнутри
DroidBox — это приложение, которое предлагает динамический анализ приложений для Android. Используя DroidBox, можно получить данные, спрятанные внутри APK любого приложения. АРК — это формат файлов приложений для Android, в который упакованы все данные о программе. Так что если вам требуется «посмотреть, что внутри» программы, DroidBox — ваш выбор.
Wi-Fi Kill — Перекрыть доступ в интернет? Не проблема!
Wi-Fi Kill — это отличный инструмент для взлома устройств под управлением Андроид. С помощью этого приложения можно отключить устройства от интернета. Есть лишь одно условие: устройство, которое вы хотите отключить, должно находиться в той же сети, что и смартфон. Работает Wi-Fi Kill довольно просто: оно блокирует пакеты данных входящего трафика и чисто технически гаджет будет находиться в сети и посылать туда запросы. Только вот в ответ не будет получать ничего.
Новости, статьи и анонсы публикаций
Свободное общение и обсуждение материалов
На этой неделе было не так много новостей из мира Android, как нам хотелось бы. Не было знаковых презентаций или громких скандалов, которые перевернули бы все в отрасли своим влиянием. Зато были «обычные» новости, способные изменить что-то в мире технологий. К ним можно отнести попытки Xiaomi сделать так, чтобы украсть ее телефоны было сложнее. Или, например, трудности, возникшие в Google у Сундара Пичаи. Поговаривают, что в компании перестали ему доверять и это может быть концом его карьеры в компании. А еще были новости про OneDrive, Google Play и многое другое. Давайте вспомним их.
Android 12 уже совсем близко и можно только порадоваться тому, что скоро пользователи относительно новых устройств получат обновление. Правда, как всегда есть небольшая ложка дегтя в огромной бочке меда. Как обычно обновление придет не сразу и не всем. Сначала обновятся телефоны одной марки, потом другой и так далее. А еще ведь и не все модели получат долгожданный номерной релиз. Связано это с тем, что не все разработчики являются по-настоящему расторопными. А иногда тут есть и маркетинговый интерес, вроде выхода новых моделей. Впрочем, это существенно более редкая причина. Давайте же разберемся, что мы имеем на данный момент. Что мы можем сказать сейчас о сроках и моделях, владельцам которых стоит ждать появления заветной кнопки ”обновить” в настройках их телефонов?
До того, как телефоны стали умными, находить мобильники было круто: считай, надежды, что его кто-то уже сможет вернуть не было. Да и возвращать его в полицию тоже не очень хотелось. У меня была похожая история, когда под ногами оказался Sony Ericsson K750. Естественно, возвращать его не стал, правда, позже милиционеры на улице его проверили и забрали, а меня заставили давать показания. С тех пор находить технику совершенно не хочется, хотя иногда это все-таки случается. Уверен, у вас похожие ситуации тоже бывали. Разобрались, что нужно делать, если вы нашли чужой телефон.