Пользователь
0,0
рейтинг
30 июня 2014 в 10:45

Разработка → Application Porno или как найти секреты в мобильных приложениях и вынести всё

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

То что результат их работы касался только анализа декомпилированного кода под Android, cподвиг меня написать про исследование, которое я проводил еще год назад, причем не только для Android, но и для iOS приложений, и которое, в итоге, вылилось в целый online-инструмент, о котором я расскажу в самом конце, когда станет очевиден его смысл. Часть написанного ниже была представлена на конференции ZeroNights и на страницах журнала «Хакер». (Т.к. материал не был опубликован онлайн, редакция дала на «добро», на публикацию здесь). Итак, поехали.

Цель — сторы


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

Но зачем злоумышленнику копаться с тем, как работает приложение на устройстве конкретного пользователя, если возможно попробовать напасть на серверную часть и увести данные ВСЕХ пользователей? Чем мобильное приложение может быть полезно для нападения непосредственно на облачную инфраструктуру этого приложения? И как насчет того, чтобы взять и проанализировать тысячи или, еще лучше, десятки тысяч приложений, проверив их на типичные баги — «вшитые» токены, ключи аутентификации и прочие секреты?

Поскольку по ссылке из введения исчерпывающе написано о GooglePlay, то мой рассказ, для интереса, пойдет о App Store, точнее про приложения для iOS. Как реализовать автоматическое скачивание из AppStore, тема для отдельной большой статьи, скажу только что это на порядок более трудоемкая задача, чем «качалка» для Google Play. Но со слезами, кровью, снифером и питоном, все-таки решаемая:)

В статьях, где затрагивается вопрос дистрибуции iOS приложений, пишут, что:

  • Приложение зашифровано
  • Приложение защищено DRM
  • Устанавливаемое приложение привязывается к устройству


За всеми этими утверждениями стоит факт, что в дистрибутиве приложения (которое представляет собой обычный ZIP-архив) скомпилированный код шифруется с привязкой к устройству. Все остальное содержимое существует в открытом виде.

С чего начать ?


Первое, что приходит в голову (токены авторизации, ключи и тому подобное), это инструменты strings и grep. Для автоматизации это не годится. Тупой поиск строк создает такое количество мусора, требующего ручного разбора, что автоматизация теряет всякий смысл.


Чтобы написать приемлемую систему автоматического анализа, нужно внимательно посмотреть на то, из чего состоит дистрибутив. Распаковав дистрибутивы для ~15 000 приложений и отбросив заведомый мусор (картинки, аудио, видео, ресурсы), мы получим 224 061 файл 1396 типов.




*.m и *.h (исходники ) — это, конечно, интересно, но не стоит забывать о конфигах, а если точнее, то XML-, PList- и SQLite-контейнерах. Приняв это упрощение, построим TOP интересных нам типов по популярности. Суммарное количество интересных нам файлов 94 452, что составляет 42% от изначального.




Приложение, которое мы условно назовем нормальными, состоит из:

  • медийный контент: картинки, аудио, ресурсы интерфейса;
  • скомпилированный код (который зашифрован)
  • контейнеры с данными — SQLite, XML, PList, BРList
  • всякий хлам, который попал в дистрибутив по неизвестной причине


Итого, задача сводится к двум:

  1. Рекурсивному поиску различных секретов в SQLite, XML, PList
  2. Поиску всякого «необычного» хлама и приватных ключей


Keep this token in secret


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



Важное обстоятельство, которое почему-то остается без внимания: библиотеки которые позволяют гибко управлять push-уведомлениями (например UrbanAirship). В мануалах ясно написано, что ни в коем случае master secret (с помощью которого серверная часть приложения шлет пуши), в приложении хранить нельзя. Но мастер-секреты все равно встречаются. То есть я могу отправить уведомление всем пользователям приложения.



TEST-DEV


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



Tap to enter



То, что в дистрибутивах попадается информация о тестовом окружении и информация о системах контроля версий, ожидаемо. Но некоторые вещи продолжают удивлять:

  • SQLite-база с учетными данными сервисы

  • Приложение-визитка с аутентификацей на клиенте

  • Приватный ключ для подписи транзакций



Что это делает здесь?!


Обнаружение описанного выше контента, в принципе объяснимо, но в приложениях периодически можно найти необъяснимые вещи, например PKCS-контейнер с сертификатом разработчика… и приватным ключом к нему



Или куски PHP-кода с логинами, паролями к базе данных.



… и мое любимое — рабочий клиентский конфиг OpenVPN.



А так же не зашифрованные приватные ключи «всех сортов и расцветок» (с)



Что кроме секретов?


Как бы по своей сути не был спорен вопрос лицензирования, но он нашел свое место и здесь. Многие разработчики используют в своих программах код фреймворков, которые бывают под лицензией GPL, требующей раскрытия кода. А как GPL работает с платными и бесплатными приложениями в App Store — вопрос, который может создать патентным троллям пространство для маневра.



Is There an App for That?


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

  1. Потратить силы и время на то, чтоб разобраться самому, как что работает. То есть дополнительная работа, за которую не платят
  2. Создать и поддерживать инфраструктур.
  3. Если приложений много, то нужен отдельный специалист на фултайм, который будет делать п.1 и п.2


из этого складывается ситуация, в которой безопасную разработку себе могут позволить богатые корпорации, которые сильно волнуются за свой бренд или финансовые структуры, которые крепко держатся «за жабры» регуляторами. А количество небезопасных приложений растет.

Ответом на все эти факторы стало появление HackApp, инструмента, который обеспечивает базовый анализ безопасности приложений и развивается в соответствии с принципами:
  1. Отчет не должен «грузить» разработчика техническими деталями (типа листингов и трейсов), а четко и понятно сообщать, что, где нужно исправить
  2. Не должен требовать вложений в инфраструктуру. (то есть каких-то выделенных под себя мощностей на стороне клиента)
  3. Иметь интерфейс для автоматического взаимодействия, работу с которым которым можно встроить в процесс предрелизного тестирование приложения, стать, с точки зрения интеграции в разарботку, yet another testing tool


Сейчас HackApp существует в 2х вариантах: базовый и Pro (с платной подпиской), но это уже совсем другая история.
@sandman
карма
43,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • +7
    Новый виток в теме антивирусов — система «антихакер». То есть автоматизированная система анализа безопасности… Шикарная идея! Вы — молодец.
  • +6
    Вам бы добавить какой-нибудь флажок, если у приложения нет проблем. А то скачал свое, проанализировал… и долго искал где же репорт. А сервис оказывается просто уязвимостей не нашел.
    И еще — категорически необходимо ввести подтверждение владения приложением до начала работы с ним. Мне не очень нравится, если кто-то будет с помощью вашего сервиса качать напрямую билды из гугл плея и анализировать их на проблемы, я бы предпочел, чтобы это была информация только для меня. Для подтверждения можно, например, отправлять ссылку на контактный адрес, указанный в профиле разработчика на гугл плей.
    • +2
      если ни кто не нашел проблем в вашем приложении, это еще не значит, что их там нет.
      • 0
        Это безусловно, только как это относится к моему комментарию?
        • 0
          Вам бы добавить какой-нибудь флажок, если у приложения нет проблем.
          могут быть флажки о проблемах, может не быть флажков о проблемах. флажок «нет проблем» это вранье, что уже само по себе проблема.
          • 0
            Хорошо, давайте назовем этот флажок «проблем не найдено». Все же наличие флажка в принципе — хоть какая-то индикация
            • 0
              ок, принято. спасибо.
    • 0
      а чем использование этого инструмента принципиально отличается от ситуации, когда человек скачивает опубликованное приложение и реверсит вручную?

      Pro версия, кстати, позволяет через api сканировать дистрибутив приложения перед релизом, и делать автоматическую нотификацию( с результатами анализа) по почте, по факту выхода новой версии приложения.
      • 0
        Отличается тем, что в сервисе достаточно одну кнопку нажать. Злоупотребление нельзя исключить, но можно хотя бы усложнить.
    • 0
      если я свое приложение проверяю но на google play и в appstore его нет и не будет
      (iOS версия использует Enterprise-сертификат для установки на все девайсы где нужно быть)
      то как мне быть?
      залить в гугл плей фейковое приложение с тем же id?

      кстати проверка показала что все нормально не смотря на то что вообще то пока что и ключи доступа к AWS и Parse в коде и «интересные» URL'ы… только все это — константами в коде.

      • 0
        а вы залили iOS приложение? там просто непосредственно исполняемый файл DRM защищен, который пока вне устройства никто публично не научился снимать. Так что анализатор смотрит на все, что есть помимо бинарника, plist, xml,sqlite и прочее.
        • 0
          и iOS и Android версии приложения.
  • +4
    Отслеживание в реал тайме это конечно жесть, за это можно и присесть.
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    Только позвчера задумывался над вопросом, как скачать приложение из AppStore, не имея ни одного устройства Apple. Как раз хотел из одного приложения извлечь информацию как оно к API подключается (его скорее всего токеном закрыли — хотя смысла не вижу, сайт публичный, а я хочу попробовать сделать аналог под Android).
    Способа скачать не придумал :(
    • +1
      Если нужно что-то разово качнуть без устройства, то вполне сгодится iTunes.
      • 0
        А как это сделать? Опишите, если не затруднит, в двух словах. Беглый поиск в гугле не нашел, хотя может не там искал.
        У меня просто никогда не было ничего от Apple, так что я даже примерно не представляю куда смотреть.
  • +2
    Как реализовать автоматическое скачивание из AppStore, тема для отдельной большой статьи, скажу только что это на порядок более трудоемкая задача, чем «качалка» для Google Play.

    Было бы крайне интересно прочитать про это. Ведь и правда, как вы заметили, скачать что-то с Google Play — очень просто, даже «качалка» находится в опенсорсе.
  • +4
    Мне интересна противоположная тема: как защитить взаимодействие своего приложения с сервером? То есть, к примеру, у меня есть сервер, выдающий прогноз погоды, и мобильный клиент, его показывающий. Я не хочу, чтобы кто-либо, кроме моего приложения, мог получать данные с моего сервера.

    Единственное, что приходит в голову, это добавлять какую-то чексумму в каждый запрос. Это даёт защиту от простейшего хака через сниффер запросов. Злоумышленник, перехватив запрос, сможет выполнить такой же запрос, но не сможет поменять параметры. Но покопавшись в коде, всегда можно найти алгоритм формирования чексуммы и использовать его для создания произвольного запроса. Обфускация в андроид-приложении слегка усложняет задачу взлома, но не делает ее невозможной. Под ios код шифруется, но теоретически его можно расшифровать как я понял.
    • +4
      Очевидно, что гарантированного решения нет: всё, что может сделать ваше приложение, сможет сделать и злоумышленник, расковыряв и/или изменив его.
      Если код выполняется на процессоре, значит в какой-то момент он расшифровывается, значит его возможно расшифровать.
      Возможно лишь усложнить взлом.
      • 0
        все верно, но можно сделать «расковыривание» экономически нецелесообразным, например обновляя приложение каждую неделю, используя новый алгоритм обфускации.
        • 0
          И с каждым обновлением прекращая поддержку всех пользователей предыдущих версий?
          Отличный план.
          • 0
            зачем? просто выкатывать новую версию и все. Можно новую обфускацию выкатывать с релизом нового функционала. Т.е. чтоб без реверса новый функционал было нельзя повторить.
    • 0
      Также можно при шифровании токена добавлять nonce / timestamp, т.е. привязывать к определенному времени, и если кто-то перехватит, а потом повторит запрос (replay attack), но время запроса не совпадает, то токен не валиден и сервер не ответит.

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

  • 0
    Пара моих небольших замечаний:
    1. Почему-то нет авторизации через Facebook для базового варианта (Free Scan).
    2. А где собственно Pro-версия? Не демка, а именно если я хочу заплатить денег сразу (и сколько?)?
    • +1
      1. Ей необходимость не очевидна сейчас. Что она дает, кроме возможности зайти еще одним способом?
      2. ответил в ЛС, чтоб не нарваться на бан за рекламу
      • 0
        Ну стандартно делают вход через ФБ и Твиттер. Линкед ин вместо ФБ несколько удивил, хотя это, разумеется, ваш выбор.
        • 0
          сделал вход полностью анонимным с долгоиграющей кукой
  • 0
    Имхо, HackApp — неудачное название для такого приложения.
    От такого названия веет чем-то другим, а не заявленной функциональностью…
  • +1
    Отличная идея и спасибо за полезное приложение.
    Стоит еще поработать над интерфейсом отчетов, т.к. пока что не совсем понятно, есть уязвимости или нет, и насколько они критичны.
    Например, вот анализ нашего приложения, это хорошо или плохо?
    qblx.co/1lOyH7T
    qblx.co/1mFlxWh

    Желаю успеха проекту, с удовольствием будем пользоваться, если будет развиваться.
    Хотелось бы аналогичное для iOS.
    • 0
      Спасибо на добром слове!

      >Хотелось бы аналогичное для iOS.
      ссылки с itunes тоже работают, анализ базовый тоже проводится.

      >это хорошо или плохо?

      Если нет вкладки багов, то значит лютых багов не найдено. Рекомендую заглянуть в секцию suspicious files, там частенько можно увидеть то, чего в приложении не нужно.
      • 0
        Отсутствие вкладки багов вводит в заблуждение. Я вот тоже загрузил свое андроид-приложение, а потом долго думал-ходил по другим вкладкам (и даже заглянул в help), чтобы понять все ли хорошо с моим приложением? или, может, сервис поиск уязвимостей лишь для iOS приложений делает?
        Я бы вкладку bugs показывал всегда. Но если багов не найдено — показывал бы сообщение, что с приложением все хорошо, багов не найдено.
  • 0
    Как ваш сервис приложения для Android анализирует? Используется описанный в статье, на которую вы ссылаетесь, PlayDrone? Или что-то другое, свое?
    • 0
      Свое, конечно. Моя конструкция на год раньше их исследования появилась. В playdrone «грепают» декомпилированный код, я, помимо этого, ещё изучаю содержимое sqlite баз, xml, смотрю подозрительные файлы. Но вот идея с elasticsearch мне в плане удобства понравилась, сейчас смотрю как её лучше встроить.
      • 0
        А xml перед анализом декодируете? Если на вкладке files качать xml, которые лежат в ресурсах, то они не декодированные.
        • 0
          да, иначе бы данные из manifest не были бы доступны. в Pro версии при просмотре файлов они автоматом декодируются.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.