В новостной ленте я недавно обнаружил любопытное исследование, где ребята скачали и распарсили 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
- всякий хлам, который попал в дистрибутив по неизвестной причине
Итого, задача сводится к двум:
- Рекурсивному поиску различных секретов в SQLite, XML, PList
- Поиску всякого «необычного» хлама и приватных ключей
Keep this token in secret
?
По-видимому, для многих разработчиков не является очевидным, что опубликованное приложение становится публичным. Так, периодически встречаются Oauth-токены твиттера и прочих популярных сервисов. Показательным случаем было приложение, которое собирало контакты, фотки, геолокацию и deviceID пользователей и сохраняло их в амазоновском облаке, и да — используя при этом токен, зашитый в одном из PList-файлов. Используя этот токен, без особого труда можно слить данные по всем пользователям (подробнее про этот случай здесь) и наблюдать за передвижением устройств в реальном времени.
Важное обстоятельство, которое почему-то остается без внимания: библиотеки которые позволяют гибко управлять push-уведомлениями (например UrbanAirship). В мануалах ясно написано, что ни в коем случае master secret (с помощью которого серверная часть приложения шлет пуши), в приложении хранить нельзя. Но мастер-секреты все равно встречаются. То есть я могу отправить уведомление всем пользователям приложения.
TEST-DEV
Не стоит обделять вниманием различные артефакты процесса тестирования и разработки, то есть ссылки на отладочные интерфейсы, системы контроля версий и ссылки на dev-окружения. Эта информация может быть крайне интересна злоумышленникам, так как в ней попадаются SQL-дампы баз с реально существующими пользователями. Разработчики, как правило, не занимаются безопасностью тестового окружения (оставляя, к примеру, пароли по умолчанию), при этом часто используют реальные данные пользователей для более качественного тестирования. Выдающейся находкой стал скрипт, через которой (без аутентификации) можно было рассылать push уведомления все пользователям приложения. 
Tap to enter
?То, что в дистрибутивах попадается информация о тестовом окружении и информация о системах контроля версий, ожидаемо. Но некоторые вещи продолжают удивлять:
- SQLite-база с учетными данными сервисы
- Приложение-визитка с аутентификацей на клиенте
- Приватный ключ для подписи транзакций
Что это делает здесь?!
?
Обнаружение описанного выше контента, в принципе объяснимо, но в приложениях периодически можно найти необъяснимые вещи, например PKCS-контейнер с сертификатом разработчика… и приватным ключом к нему
Или куски PHP-кода с логинами, паролями к базе данных. 
… и мое любимое — рабочий клиентский конфиг OpenVPN.
Нет отзывов к этой записи