Привет, Хабр!

Каждую свою статью я начинаю с упоминания о том, что наша команда разрабатывает платформу анализа защищенности мобильных приложений. Почему? Размещая свои посты, информацию, которая мне кажется полезной, различные находки и трюки, мне хочется делиться с единомышленниками, помогать тем, кто идет по тому же пути, рассказывать об интересном. Я уверен, что не только у нас возникают трудности в процессе создания своих разработок, и здесь мы можем обменяться опытом. Сегодня мне хочется рассказать немного о том, с чем мы столкнулись в последние месяцы, работая над новым релизом нашего продукта. Возможно, это даст кому-то новый импульс, а может, кто-то даст нам совет со своей стороны. Мы открыты к общению!

Оглавление

Введение

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

Мы стремимся к тому, чтобы нашим продуктом было легко и удобно пользоваться. Все, кто работает с разными сканерами, анализаторами и прочими инструментами по ИБ (даже не в контексте анализа мобильных приложений), знает, что с ними не так-то просто иметь дело! А нам хочется, чтобы в идеале даже люди, которые никогда не занимались анализом мобилок, могли загрузить приложение, потыкать мышкой в интерфейс и получить понятный отчет с реальными уязвимостями. Чтобы даже из коробки все работало максимально просто, быстро и качественно. Но при этом не забывать и о тех, кто хочет более тонко настроить инструмент и заточить его под себя и свои приложения. Но вот эта простота для пользователя, к которой мы стремимся, создает огромные сложности при разработке и проектировании системы. И наверняка кому-то из вас будет интересно “поднять капот“ и посмотреть, как обстоит все внутри на самом деле.

Хотелось бы написать больше, но посмотрим, насколько такой формат повествования будет уместным. Если все будет хорошо, я обязательно напишу краткую историю трансформации нашего продукта и всех сложностей, с которыми мы столкнулись ( а их было достаточно). В начале нашего пути мой коллега, когда его просили описать, что из себя представляет наша система, отметил: “Можно сказать, мы собираем Python в Linux, развернутом внутри Android-эмулятора в Docker“. Так было раньше и это было весело, но сейчас все намного интереснее.

Динамический анализ iOS

Довольно долгое время мы специализировались только на Android-приложениях. Это было логично и понятно, ведь Android-устройства более доступные, для них легче получить права суперпользователя, да и в целом система более открытая, есть эмуляторы и много других аспектов. Мы долго планировали добавить полноценную динамику iOS-приложений и несколько раз подступались к ней, но не хватало то времени, то компетенций. И вот, наконец, мы реализовали этот непростой сценарий, но по пути, конечно, набили немало шишек.

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

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

Процесс подготовки устройств
Процесс подготовки устройств

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

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

В-пятых, обязательно нужно организовать мониторинг всей инфраструктуры. Нужно следить за состоянием устройств и автоматическим исправлением возникающих проблем и уведомлять администраторов, если что-то нельзя сделать удаленно (например телефон перестал заряжаться). Это позволяет всегда быть уверенными, что девайсы в любой момент времени могут принять в себя задачу на анализ приложения, и они всегда в актуальном и исправном состоянии. Также этот механизм запускается перед каждым сканированием, чтобы убедиться в актуальности конфигурации и сэкономить время пользователя. В случае возникновения проблем он сообщает, что сканирование провести на этом девайсе не получится.

Я не буду сейчас рассказывать про архитектуру решения, которое мы спроектировали и реализовали, (думаю, это тема для отдельной статьи), но отмечу, что нам тоже пришлось поломать голову, как обеспечить постоянную работоспособность, удобство конфигурирования и администрирования всего “зоопарка” и завязать мониторинг в единую систему. Скажу лишь только, что профили устройств в iOS и pfSense совместно с Radius очень нам в этом помогли.

Полноценный IAST для Android-приложений

Итак, более-менее понятно, что происходило с iOS, а как же Android? Его мы тоже не оставили в стороне. До сегодняшнего дня мы отлично умели находить любую чувствительную информацию, которую обрабатывает, хранит или передает приложение и имели в арсенале обнаружение нескольких более интересных уязвимостей, вроде потенциального выполнения кода в контексте приложения, но этого было мало.

Как вы уже знаете, мы “держим руку на пульсе“ и всегда прорабатываем все отчеты, writeup’ы, открытые баги в багбаунти-системах и еще львиную долю материалов, многие из которых я публикую, и у нас накопилось достаточно много уязвимостей, поиск которых мы хотели автоматизировать. Все это - реальные баги, которые можно реализовать на нерутованных устройствах, просто поставив рядышком приложение, а иногда и просто кликнув по ссылке. Это самые сложные и самые “вкусные“ уязвимости, поиск которых мы всегда хотели добавить. Мы наметили ближайший план по автоматизации и уже начали точечно их реализовывать.

Классическая схема IAST
Классическая схема IAST

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

Во главу угла мы поставили пользователя и то, что он вводит в приложение, поскольку все это может привести к проблемам, если в итоге попадет в потенциально опасную функцию. Таким образом, мы поняли, - если сможем точно определить, что данные, которые пришли к нам извне, попадают в неизменном виде в потенциально опасные функции, у нас получится определять практически любые уязвимости. И это то, что нам нужно! Ведь у нас уже есть полный контроль над приложением, над всеми данными внутри и любыми вызовами любого API. Оставалось лишь реализовать все это так, чтобы можно было описывать уязвимости через сигнатуры.

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

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

Обновленный дизайн

Почему-то именно с UI у нас очень интересные взаимоотношения. Если вспомнить начало нашей истории, то самый первый вариант - это просто html, который мы генерировали на стороне сервера и отдавали в браузер. Второй версией стала моя покупка темы для Angular и разработка нового интерфейса, который был отделен от сервера и представлял собой полноценный SPA. Что сказать, это была одна из самых бесполезных покупок в моей жизни. Я вооружился скачанным курсом по Angular, новой купленной темой, которая практически сразу ушла в корзину, запасом энергетика и написал свой первый SPA, который просуществовал достаточно долго, пока мы не нашли толкового и выделенного разработчика под эти задачи. Посмотрев на тот ужас, что творился в коде, было решено переписать все практически с нуля и реализовать интерфейс, используя современные технологии и правильные подходы. Это привело нас к проектированию каждой страницы (правда ввиду ограниченности ресурсов на тот момент - на листочке в клеточку, но это не важно) и к последовательной их реализации. Как итог - мы получили стабильно работающий, хороший интерфейс, который просуществовал достаточно долго.

Три версии одного экрана
Три версии одного экрана

На протяжении всей жизни этой версии мы собирали обратную связь от пользователей, подмечали различные неудобные моменты, и на основе всего этого сформировали неплохой список улучшений и пожеланий к новому интерфейсу. Изучив все фичи, которые нам хотелось бы реализовать, и взглянув на то, что есть у нас, мы решились на очередную авантюру - переписать и перерисовать “лицо” нашей системы практически полностью. По факту, единственное, что осталось неизменным, - это функционал по получению данных и работе с API. Все остальное (включая элементы интерфейса, даже кнопки, переключатели, шрифты, поля ввода, обработки файлов и картинок) переосмыслили, изменили и отрисовали вручную. Все переходы между экранами, весь “пользовательский путь” был переработан и переделан, наконец-то появилась полная адаптивность интерфейса под различные разрешения экрана. Все, чего не хватало прежде, появилось в новой версии. На самом деле, изменений столько, что в какой-то момент мы перестали их считать и записывать, а просто полностью ушли в работу.

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

Интеграции

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

Именно поэтому мы решили поразмыслить над добавлением новых способов получения приложений для анализа. Итогом стала возможность загружать и отправлять на анализ системы из Firebase, Google Play и App Store, но скольких седых волос нам это стоило.

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

Взять, к примеру, интеграцию с Firebase. Если зайти в Web-приложение, то там есть замечательная большая кнопка “Скачать дистрибутив“. Но при этом никакого внешнего API для загрузки нет, не было и не планируется. Для того, чтобы все-таки реализовать возможность скачать приложение, пришлось изрядно потрудиться, изучить строение внутренних вызовов внутри Firebase, определить, как и на чем основывается аутентификация и авторизация в сервисах Google, понять, какие внутренние вызовы нужно совершить, с какими заголовками и много-много чего еще.

Казалось бы, разобрались с аутентификацией в Google, теперь можно и Play Store безболезненно подключить. Как бы не так! Судя по всему, разрабатывают их абсолютно разные команды с разными подходами и степенью продуманности интерфейсов. И все, что мы делали для Firebase, оказалось абсолютно неприменимо для интеграции с магазином приложений. Поэтому пришлось начинать все с чистого листа: изучать API, способы регистрации устройства и дальнейший процесс получения apk-файлов. В итоге, мы реализовали это функционал, но вот незадача - буквально на днях Google изменил процесс логина в магазин приложений, и теперь нам приходится снова искать варианты для обхода ограничений. Нужно снова смотреть трафик и понять, что же сделал Гугл.

С Apple AppStore, на удивление, возникло куда как меньше проблем, потому что нам удалось найти практически готовое решение, которые мы интегрировали в наш общий скрипт. Окрыленные успехом, мы замахнулись на святая святых, на загрузку файлов из системы дистрибуции TestFlight, на данный момент известную как Apple Connect. И тут нас ждал большой облом. Раньше, еще до переименования, в консоли TestFlight была замечательная кнопка по загрузке тестовых сборок, и можно было относительно легко ей воспользоваться, но сейчас, после того, как произошла реорганизация системы дистрибуции Apple, эту возможность убрали в принципе. Потратив несколько недель на поиск решения, оплатив разработческий аккаунт, пройдя через несколько кругов ада на подтверждение своих данных, зарегистрировавшись в нескольких программах, мы поняли, что варианта скачать приложение найти не можем. Заглянув в трафик приложения TestFlight, удалось поймать интересный запрос на загрузку ipa-файла, но при попытке установить загруженное приложение ничего не получалось. По итогу, мы пока не добавили эту интеграцию, но как только появится время, я думаю, мы попробуем вернуться к этому вопросу и все-таки попробовать заставить это работать.

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

Заключение

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

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

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

Всем спасибо за время и внимание, и до новых встреч!

Комментарии (2)


  1. pavelkann
    24.05.2022 13:17
    +1

    Очень крутой инструмент! Вы молодцы, ребята!


  1. Knutov_V
    25.05.2022 10:55
    +1

    Новый релиз, практически новый инструмент