В новостной ленте я недавно обнаружил любопытное исследование, где ребята скачали и распарсили 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.
А так же не зашифрованные приватные ключи «всех сортов и расцветок» (с)
Что кроме секретов?
Как бы по своей сути не был спорен вопрос лицензирования, но он нашел свое место и здесь. Многие разработчики используют в своих программах код фреймворков, которые бывают под лицензией GPL, требующей раскрытия кода. А как GPL работает с платными и бесплатными приложениями в App Store — вопрос, который может создать патентным троллям пространство для маневра.
Is There an App for That?
Итого, у нас есть тысячи приложений, в которых находятся описанные «косяки», но разработчики не особо спешат что-то с этим делать. В чем же здесь проблема? На гитхабе есть множество всяких супер-конструкций для аудита безопасности приложений, но для того чтоб с ними работать, разработчику нужно:
- Потратить силы и время на то, чтоб разобраться самому, как что работает. То есть дополнительная работа, за которую не платят
- Создать и поддерживать инфраструктур.
- Если приложений много, то нужен отдельный специалист на фултайм, который будет делать п.1 и п.2
из этого складывается ситуация, в которой безопасную разработку себе могут позволить богатые корпорации, которые сильно волнуются за свой бренд или финансовые структуры, которые крепко держатся «за жабры» регуляторами. А количество небезопасных приложений растет.
Ответом на все эти факторы стало появление HackApp, инструмента, который обеспечивает базовый анализ безопасности приложений…
… и развивается в соответствии с принципами:
- Отчет не должно «грузить» разработчика техническими деталями (типа листингов и трейсов), а четко и понятно сообщать, что, где нужно исправить
- Не должен требовать вложений в инфраструктуру. (то есть каких-то выделенных под себя мощностей на стороне клиента)
- Иметь интерфейс для автоматического взаимодействия, работу с которым которым можно встроить в процесс предрелизного тестирование приложения, стать, с точки зрения интеграции в разарботку, yet another testing tool
Сейчас HackApp существует в 2х вариантах: базовый и Pro (с платной подпиской). Различаются они тем, что в Pro есть некоторые дополнительные «вкусняшки» типа автоматическое уведомление о релизах и API для автоматизации анализа. Поскольку Хабр не рекламный блог, то подробнее про инструмент и исследования читайте в нашем блоге и твиттере.
Автор: sandman
