как снифать запросы приложения
Начинающему QA: полезные функции снифферов на примере Charles Proxy
В этой статье я расскажу об основных функциях снифферов, которые могут быть полезны QA. Попробую не вдаваться в теорию, а сфокусироваться на практике. Наиболее популярными представителями анализаторов трафика сейчас являются WhireShark, Fiddler и Charles Proxy. Об удобстве интерфейсов и функционале каждого из них можно рассуждать долго, учитывая все плюсы и минусы. Но здесь я отдал предпочтение Charles, поскольку сам им активно пользуюсь. Буду рассказывать на его примере.
Что собой представляет Charles Proxy
Первичная настройка
При тестировании мобильного приложения
Charles Proxy необходимо запустить на компьютере, который находится в той же локальной подсети, что и мобильное устройство с тестируемым приложением.
Как правило, соединение настраивается по Wi-Fi. В настройках Wi-Fi мобильного устройства в качестве proxy-сервера надо указать IP-адрес компьютера и стандартный порт инструмента 8888 (пароль остается пустым).
Главное отличие в настройках для этой ОС в том, что с Android 6.0 и выше в Androidmanifest надо добавить специальную конфигурацию, позволяющую просматривать защищенный трафик. На продакшене эта конфигурация убирается из соображений безопасности.
При тестировании приложения на ПК
Сертификат устанавливается в доверенные корневые центры.
Два слова об интерфейсе
С помощью контекстного меню запроса можно настраивать блокировки, повторять и изменять запросы. На этом мы еще остановимся.
На вкладке Sequence запросы выведены по времени в виде настраиваемой таблицы. Видно, когда начался запрос, сколько он длился, его размер, статус и т.п. Наведя на конкретную строку, мы получим ту же информацию о теле, заголовках и т.п.
Если запросов на экране слишком много, с помощью панели инструментов их можно очистить или вообще остановить перехват. Там же есть возможность включить и выключить троттлинг (подробнее об этих функциях расскажу позже). Базовая настройка каждой из функций осуществляется через меню, а кнопки панели управления выступают своего рода тумблерами On / Off.
Фильтрация
В Charles Proxy очень много вариантов фильтрации запросов.
На вкладке Sequence есть аналогичный фильтр.
Charles Proxy умеет работать с регулярными выражениями. Для этого на вкладке Sequence выбираем Settings и отмечаем пункт Filter uses regex. И вписываем в поле поиска элементарную регулярку.
можно выбрать все запросы, в которых в начале имени хоста находится четыре буквы, а потом идет точка.
Там же можно включить Autoscroll списка запросов или указать максимальное количество строк.
Блокируемый запрос можно прервать двумя способами (подходящий надо выбрать в настройках):
вернуть ошибку 403.
От выбранного способа блокировки зависит, какой ответ мы получим.
Можно провести эксперимент. Включим наш тестовый стенд в Block list, выбрав простой сброс соединения. С помощью контекстного меню запроса повторим его (команда Repeat) и получим такой ответ:
Просмотр SSL-трафика
Если ранее мы успешно установили SSL-сертификат, для просмотра зашифрованного трафика остается только включить SSL proxying для нужного хоста в самом Charles Proxy. Это можно сделать через контекстное меню конкретного хоста.
Аналогично настройке фильтров на вкладках Include и Exclude можно добавить или исключить конкретные хосты. Если списки на этих вкладках не заполнять, по умолчанию мы будем читать трафик со всех хостов.
Брейкпоинты
Установить Breakpoint можно из контекстного меню запроса. После этого все аналогичные запросы будут перехвачены. Их можно будет просматривать и редактировать.
Чтобы проверить, как это работает можно использовать повтор запроса (Repeat из того же контекстного меню). Запрос перехватывается, его можно редактировать.
Map remote
Эта функция может быть полезна, если мы поймали ошибку на продакшене, например при загрузке таблицы, а информации в dev-контуре для полноценного тестирования не хватает. Вместо того, чтобы перезаполнять информацию в каждом контуре, мы можем скопировать ответ сервера в нужный контур и посмотреть, как он ведет себя после исправления ошибки.
Map Local
Главное отличие Map Local от предыдущей функции в том, что замена осуществляется не на ответ другого сервера, а на содержимое локального файла. Настройки выглядят точно также, но вместо второго сервера мы указываем локальный путь к файлу с ответом.
Rewrite
Функция Rewrite может быть полезна, если вам нужно переписать данные, которые отправляются в Charles Proxy. В отличие от простого редактирования Rewrite позволяет задать правила изменения и работать в автоматическом режиме. Можно изменять и добавлять заголовки, искать и заменять текст в теле запроса или ответа. Можно даже менять статус ответа.
Настроить это можно через Rewrite settings, доступные в контекстном меню. Единственный недостаток инструмента в том, что каждое правило замены прописывается отдельно.
Помимо изменения запросов и ответов мы можем запретить кэширование или cookie (функции No caching и Block cookies). Эти опции повторяют аналогичные инструменты панели разработчика в браузере. В обоих случаях настраивается список хостов, для которых действует настройка. Если же список пуст, то кэширование и cookie отключаются на всех перехваченных хостах.
Throttling
Charles Proxy помогает тестировать сервис на плохой связи, искусственно ограничив через настройки пропускную способность канала. Эта функция полезнее всего для тестирования десктопных приложений, поскольку на мобильных устройствах качеством связи можно управлять через панель разработчика.
Ограничения можно включить либо для хостов из списка, либо для всех перехваченных запросов. Из коробки есть несколько пресетов, но все параметры связи можно корректировать вручную. Мне по большей части хватает базовых настроек.
Repeat Advanced
Хотя полноценное нагрузочное тестирование лучше проводить в специальных инструментах, Charles Proxy имеет одну базовую настройку, которая помогает закрыть минимальные потребности. Функция Repeat Advanced (доступная через контекстное меню перехваченного запроса) позволяет нужное количество раз повторить тот же запрос. После настройки откроется отдельная сессия, где будут видны детали каждого из запросов.
Отмечу, что Charles Proxy платный. Можно использовать триальную версию. Но раз в 5-7 минут поверх него будет отображаться всплывающее окно с версией, а раз в 30 минут он будет выключаться, при этом сессии не сохраняются. Решайте сами, помешает ли это вашей работе.
Автор статьи: Артем Холевко, Максилект.
Текст подготовлен по материалам внутреннего семинара Максилект.
Как сниффить HTTPS-трафик iOS-устройства
Привет, меня зовут Андрей Батутин, я Senior iOS Developer в DataArt, и сегодня мы будем сниффить HTTPS-трафик твоего «Айфона».
FoodSniffer и с чем его едят
Возьмем, к примеру, очень простое iOS-приложение FoodSniffer. Оно в зависимости от времени дня показывает пользователю, что можно есть.
Приложение получает от сервера JSON вида:
Сервером в данном случае выступает Dropbox, а JSON можно посмотреть здесь.
Проблема №1
Пришел баг, что вместо двух элементов в списке разрешенной утром еды приложение показывает только один.
Один из способов проверить, что пошло не так, — увидеть JSON, который вам возвращает сервер.
Как сниффить трафик?
Предположим, что ваши MacOS-компьютер и iOS-устройство находятся в одной локальной сети, которая выглядит примерно так:
Трафик идет от iOS-устройства через роутер к серверу независимо от трафика компьютера.
Чтобы читать трафик iOS-устройства, нам нужно сделать так, чтобы он шел через наш Мac. Примерно так:
Кроме того, нам понадобится HTTP/S-прокси-сервер, с помощью которого мы бы и смотрели/модифицировали проходящий трафик iOS-устройства.
Еще одна очень важная задача — иметь возможность сниффить HTTPS-трафик. Загвоздка в том, что HTTPS-протокол и создавался, чтобы, кроме клиента и сервера, никто не мог прочесть, что передается в HTTPS-запросах. Поэтому HTTPS-прокси должен поставлять с собой еще и SSL-сертификат, который нужен для работы с HTTPS-трафиком.
Иными словами, нам нужно реализовать Man-in-the-Middle-атаку на нашу собственную сеть.
Charles Web Debugging Proxy Application
Как видим, сниффить HTTPS-трафик — задача многоэтапная, поэтому чтобы максимально упростить себе жизнь, я использую Charles Proxy.
Настройка Charles и iOS-устройства
Далее будет описана процедура первоначальной настройки iOS-устройства для работы с Charles Proxy.
1. Запустить Charles на компьютере:
2. Установить Charles Root Certificate на iOS устройстве:
Появится следующее окно:
3. В настройках сети iOS-устройства указываем IP и порт Charles Proxy:
В зависимости от архитектуры вашей сети IP-адрес, на котором работает Charles, может отличаться.
4. Открываем браузер на iOS-устройстве и переходим по ссылке — http://chls.pro/ssl.
5. Устанавливаем Charles SSL-сертификат на устройство:
6. Указываем в настройках устройства, что полностью доверяем данному сертификату:
Шестой этап нужен для устройств с iOS 10 и выше.
На 5–6-м этапах мы установили на устройство Charles SSL-сертификат и указали, что мы ему доверяем. Т. е. теперь весь HTTPS-трафик, подписанный этим сертификатом, не будет блокироваться ATS.
Как смотреть трафик iOS-устройства
Откройте приложение FoodSniffer. Если настройка прокси была сделана правильно, то вы должны увидеть такой экран:
И полностью выключите кэширование на прокси-сервере.
В приложении реализован Pull-to-refresh, после обновления списка продуктов вы должны в Charles увидеть https://www.dropbox.com в списке с левой стороны. Нажмите правой кнопкой мыши на него и выберите Enable SSL Proxing.
После этого еще раз обновите список продуктов в приложении. Теперь вы должны увидеть примерно такую картину:
Теперь мы можем свободно читать HTTPS-трафик, который идет от приложения на Dropbox за нашим JSON.
Dropbox не отдает JSON c хоста dropbox.com напрямую. Вместо этого он возвращает 302-респонс и редиректит еще на один хост, с которого и происходит загрузка данных.
Найти его можно, просмотрев Raw Response следующего запроса:
У вас, скорее всего, будет немного другой хост.
Затем включаем для него SSL Proxing: Enabled.
Обновляем FoodSniffer еще раз.
И теперь мы наконец можем увидеть реальный JSON, который и показывает приложение!
Мы видим, что у нас есть всего один тип еды на вечернее время — виски, пишем об этом нашему тимлиду и идем пить кофе, проблема не на нашей стороне.
*В проекте применяется уже исправленный JSON, с двумя типами еды на вечер: пивом и виски.
*Если вы не видите хост http://uc9c29db95802af8490afc3afda9.dl.dropboxusercontent.com или похожий на него в списке в левой части окна, попробуйте обновить список продуктов в приложении несколько раз.
Проблема № 2, или Как изменять HTTPS-трафик iOS-устройства
Бэкенд-команда исправила меню на вечер, и теперь JSON формируется правильно. Но что делать, если сейчас утро, а ждать до вечера, чтобы проверить фикс, не хочется?
Один из вариантов — с помощью Charles изменять JSON, который вам приходит в ответ от Dropbox.
В данном случае нам нужно изменить consumePeriod с evening на morning.
В появившемся окне Rewrite Settings добавляем новую категорию для перезаписи — dropbox.
Добавляем хост, указывая https-порт в Edit Location меню:
После этого добавляем правила перезаписи в Rewrite Rule меню следующим образом:
Т. е. теперь в каждом Body респонса от нашего сервера слово evening будет заменено на слово morning.
При необходимости мы можем менять любую часть HTTP-запроса/ответа, плюс использовать regex-выражение для замены текста.
Теперь, обновив список, мы должны увидеть четыре типа продуктов:
Вывод
Charles довольно простой, условно-бесплатный, обладает богатым функционалом HTTPS-прокси. С моей точки зрения, он лучше всего проявляет себя при работе с MacOS и iOS-устройствами.
Это далеко не единственный способ сниффить трафик. Для HTTP/S-трафика широко применяют и Fiddler. Если вам нужно уйти глубже в TCP/IP-стэк — есть Wireshark.
Кроме того, существует проблема certificate pinning. Если в вашем приложении он реализован, вам надо либо добавлять Charles SSL-сертификат в список разрешенных сертификатов, либо использовать такое средства, как Frida, чтобы отключить certificate pinning уже на уровне самого приложения. Об этом подробнее надеюсь рассказать в следующей статье.
Буду рад, если вы поделитесь вашим опытом в мониторинге трафика, в том числе HTTP/S, советам и лайфхаками.
Примечание. Используйте эту технику только для своих приложений, пожалуйста. Будьте белыми зайчиками хакерами!
Примечание 2. Недавно история об этом выходила на украинском, но по-русски я ее публикую впервые.
Перехват 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.
Анализ трафика 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:
Теперь осталось выровнять данные в архиве по четырехбайтной границе:
Лучшие инструменты пен-тестера: сниферы и работа с пакетами
Содержание статьи
У каждого из команды ][ свои предпочтения по части софта и утилит для
пен-теста. Посовещавшись, мы выяснили, что выбор так разнится, что можно
составить настоящий джентльменский набор из проверенных программ. На том и
решили. Чтобы не делать сборную солянку, весь список мы разбили на темы – и в
этот раз коснемся утилит для снифинга и манипулирования пакетами. Пользуйся на
здоровье.
Wireshark
TCPDump
Сайт: www.tcpdump.org
Платформа: *nix, есть порт под Windows
Название этого снифера знакомо каждому. Еще бы: до появления на сцене
Ethereal‘а (Wireshark) он считался стандартом де-факто, да и теперь
многие по привычке используют его, вполне радуясь жизни. Да, у него нет
классного GUI-интерфейса и возможности автоматически распарсить данные
популярных протоколов, но это, в любом случае, отличное средство, чтобы
отснифать в локалке трафик и получить вожделенный дамп данных. Вообще, более
неприхотливого средства, пожалуй, не найти: и это, отчасти, хорошая сторона
того, что новые возможности в нем практически не появляются. К тому же, в
отличие от того же Wireshark, TCPDump может похвастать куда меньшим
количеством проблем с безопасностью и просто багов. Многие мои знакомые админы
успешно юзают этот снифер для мониторинга активности и решения самых различных
сетевых проблем. Исходные коды TCPDump частично используются библиотеками
Libpcap/WinPcap, предназначенными для перехвата пакетов и используемыми
известным сканером nmap и другими тулзами.
Ettercap
Помнится, когда мы впервые рассказывали об ARP-спуфинге (приеме, позволяющем
снифать трафик в локальных сетях, построенных на считах), то в качестве снифера
применяли именно Ettercap. Сами разработчики продвигают свой продукт как
средство для совершения атак man-in-the-middle. Утилита поддерживает снифинг в
реальном времени, фильтрацию контента «на лету», инжекцию пакетов и многие
другие интересные трики. Учти, что по дефолту программа выполняет множество
лишних действий (например, dns-резолвинг найденных адресов). Кроме того,
активный arpoisoning и некоторые другие действия могут скомпрометировать хакера,
использующего Ettercap. Если точнее, то даже в самой программе встроена
функция обнаружения себе подобных :). В Ettercap предусмотрена возможность
проверки, находишься ли ты в локалке со свитчами или нет (сейчас это уже почти
не актуально), а также встроено средство для fingerprint’а, которое активными и
пассивными методиками может определить разные девайсы, операционки на хостах и
общую схему сети.
0x4553-Intercepter
Подробнее про 0x4553-Intercepter ты можешь прочитать в
статье Криса Касперски.
Netcat
Cain and Abel
Ngrep
Nemesis
Эта консольная тулза для разборки сетевых пакетов, их модификации и
дальнейшей инжекции в Сеть не раз выручала меня в тестировании IDS, файрволов и
сетевых демонов. Благодаря работе через консоль, Nemesis легко
приспосабливается к любым сторонним скриптам для пен-теста. Оригинальная версия
может распарсить и инжектировать произвольные пакеты ARP, DNS, ETHERNET, ICMP,
IGMP, IP, OSPF, RIP, TCP и UDP.
Hping2
Сайт: www.hping.org
Платформа: *nix, MacOS X, Windows
Вот еще одна миниатюрная утилита, позволяющая отсылать произвольные ICMP, UDP,
TCP и RAW-IP пакеты и отображать ответы на них. Отправить такой пакет не
сложнее, чем пропинговать нужный хост. Интерфейс полностью перенят у любимого
Ping’а – отсюда и название программы. Изначально тулза была разработана в
качестве замены стандартным ping/traceroute, работа которых часто обламывается
из-за файрволов. Поэтому в Hping2 по умолчанию есть продвинутый
traceroute и режим IP-фрагментации. Тулзу часто используют для проверки
настройки файрвола, fingerprint’а и сканирования портов. И, конечно же, просто
для отправки в Сеть нужного пакета.
Network Miner
Добротный снифер для Windows, который всячески пытается выведать как можно
больше инфы о локальной сети. Network Miner предназначен не столько для
перехвата данных (хотя, безусловно, он это умеет) – сколько для анализа
инфраструктуры локалки (операционки на хостах, открытые сессии, hostname’ы,
открытые порты на узлах). В отличие от многих утилит, делает он это
исключительно пассивно, т.е. без генерации трафика, по которому может быть
определен факт сканирования. Для анализа ОС на каждом из узлов используются
проверенные механизмы fingerprint’а, базы утилиты p0f (lcamtuf.coredump.cx/p0f.shtm),
а также метод анализа DHCP-пакетов из тулзы Satori (http://myweb.cableone.net/xnih).