Артем Азарьев, руководитель направления центра компетенций дистанционных каналов обслуживания дирекции информационных технологий МКБ
Привет, Хабр!
Меня зовут Артем Азарьев, я тимлид Android-команды Московского кредитного банка, и сегодня хочу поговорить о безопасности приложений с точки зрения библиотек для отладки. Пару лет я занимался фрилансом, затем уже 4 года занимаюсь полноценной разработкой под мобильную ОС. Так сложилось, что в годы своего фриланса ради повышения собственной квалификации я затронул тему реверс-инженеринга Android-приложений, и постепенно это превратилось в мое хобби.
Ни для кого не секрет, что долгое время Android Studio не было представлено никаких механизмов для адекватного получения данных приложения с девайса: содержимое базы данных, SharedPrefrences, сетевые запросы. Страдали все, включая таких гигантов как Facebook.
Именно они дали сообществу крайне полезную библиотеку для отладки Shetho (https://github.com/facebook/stetho) с очень простой интеграцией в проект буквально в пару строк. Про саму библиотеку рассказывать не буду, ее, скорее всего, многие и так знают, а кому интересно – почитают самостоятельно.
Интеграция данной библиотеки происходит следующим образом:
При помощи браузера Chrome мы имеем доступ и к содержимому баз данных, и к хранимым на устройстве настройкам, а если подключить плагин для okhttp3, то еще и к содержимому сетевых запросов.
«Но погодите, ведь это будет и в релизной сборке?» – спросит себя внимательный разработчик. Обратимся к описанию библиотеки – что нам советуют по этому поводу?
В sample-проекте показано, что данную библиотеку необходимо инициализировать только в debug-ветке путем перегрузки манифеста в одном из вариантов сборки.
Собираем релизную сборку с включенной минификацией (флаг minifyEnabled). Проверяем браузер, не видим никакого доступного для отладки приложения и спокойно идем спать.
Минификация – процесс, направленный на уменьшение размера исходного кода путём удаления ненужных символов без изменения его функциональности. Используемый в Android инструмент Proguard также занимается еще и чисткой проекта от неиспользуемого кода.
Любой реверс-инженеринг приложения начинается с изучения потенциальных закладок и бекдоров, которые были любезно оставлены разработчиками для себя же.
Первым делом декомпилируем приложение в Java, насколько это возможно и изучаем дерево пакетов.
Самое сладкое, что можно найти в атакуемом приложении, – это старый добрый Stetho. Настроенная по-умолчанию минификация его не убирает, и в целом вся кодовая база данной библиотеки просто тащится в продукционный билд.
Я видел очень много приложений от достаточно крутых и крупных компаний, которые оставляли подобную библиотеку в продукционных билдах на протяжении многих лет.
Кто-то спросит: «И что такого? Оно же выключено. Плюс, даже если ты включишь, попробуй потом собрать это приложение».
Верно, декомпиляция в Java почти никогда не дает 100% рабочий код. Но есть smali/backsmali.
Smali/backsmali – это ассемблер / дизассемблер для формата dex, используемого dalvik, реализацией Java VM в Android.
Дизасемблировав наше приложение, мы увидим, что действительно ничего не включено.
Но, дописав пару строк и имея в проекте весь код библиотеки, мы, не особо напрягаясь, можем включить его назад.
Для плагина okhttp3 аналогичным образом включается поддержка – добавлением Interceptor к OkhttpClient.
Собрав приложение назад (а из smali это сделать легко), мы видим, что отладка через stetho снова доступна, и все ваши данные в локальном хранилище настроек, весь ваш api полностью перед глазами хитрых хацкеров.
Есть много вариантов исключить package из финальной сборки. Лично я предпочитаю написать маленький wrapper для инициализации библиотеки Stetho и разложить разные его реализации по вариантам сборки.
release
debug
А также указать, что данная кодовая база нужна только в debug билде.
Хочется в завершении озвучить основные принципы, которые я использую в работе в контексте безопасности Android приложений:
Добавляя что-либо в свой проект, даже из лучших побуждений, подумайте, как корректнее это сделать и насколько оно вообще вам нужно.
Надеюсь, мой опыт будет вам полезен.
Привет, Хабр!
Меня зовут Артем Азарьев, я тимлид Android-команды Московского кредитного банка, и сегодня хочу поговорить о безопасности приложений с точки зрения библиотек для отладки. Пару лет я занимался фрилансом, затем уже 4 года занимаюсь полноценной разработкой под мобильную ОС. Так сложилось, что в годы своего фриланса ради повышения собственной квалификации я затронул тему реверс-инженеринга Android-приложений, и постепенно это превратилось в мое хобби.
Введение
Ни для кого не секрет, что долгое время Android Studio не было представлено никаких механизмов для адекватного получения данных приложения с девайса: содержимое базы данных, SharedPrefrences, сетевые запросы. Страдали все, включая таких гигантов как Facebook.
Именно они дали сообществу крайне полезную библиотеку для отладки Shetho (https://github.com/facebook/stetho) с очень простой интеграцией в проект буквально в пару строк. Про саму библиотеку рассказывать не буду, ее, скорее всего, многие и так знают, а кому интересно – почитают самостоятельно.
Интеграция данной библиотеки происходит следующим образом:
При помощи браузера Chrome мы имеем доступ и к содержимому баз данных, и к хранимым на устройстве настройкам, а если подключить плагин для okhttp3, то еще и к содержимому сетевых запросов.
«Но погодите, ведь это будет и в релизной сборке?» – спросит себя внимательный разработчик. Обратимся к описанию библиотеки – что нам советуют по этому поводу?
В sample-проекте показано, что данную библиотеку необходимо инициализировать только в debug-ветке путем перегрузки манифеста в одном из вариантов сборки.
Собираем релизную сборку с включенной минификацией (флаг minifyEnabled). Проверяем браузер, не видим никакого доступного для отладки приложения и спокойно идем спать.
Минификация – процесс, направленный на уменьшение размера исходного кода путём удаления ненужных символов без изменения его функциональности. Используемый в Android инструмент Proguard также занимается еще и чисткой проекта от неиспользуемого кода.
Хацкеры
Любой реверс-инженеринг приложения начинается с изучения потенциальных закладок и бекдоров, которые были любезно оставлены разработчиками для себя же.
Первым делом декомпилируем приложение в Java, насколько это возможно и изучаем дерево пакетов.
Самое сладкое, что можно найти в атакуемом приложении, – это старый добрый Stetho. Настроенная по-умолчанию минификация его не убирает, и в целом вся кодовая база данной библиотеки просто тащится в продукционный билд.
Я видел очень много приложений от достаточно крутых и крупных компаний, которые оставляли подобную библиотеку в продукционных билдах на протяжении многих лет.
Кто-то спросит: «И что такого? Оно же выключено. Плюс, даже если ты включишь, попробуй потом собрать это приложение».
Верно, декомпиляция в Java почти никогда не дает 100% рабочий код. Но есть smali/backsmali.
Smali/backsmali – это ассемблер / дизассемблер для формата dex, используемого dalvik, реализацией Java VM в Android.
Дизасемблировав наше приложение, мы увидим, что действительно ничего не включено.
Но, дописав пару строк и имея в проекте весь код библиотеки, мы, не особо напрягаясь, можем включить его назад.
Для плагина okhttp3 аналогичным образом включается поддержка – добавлением Interceptor к OkhttpClient.
Собрав приложение назад (а из smali это сделать легко), мы видим, что отладка через stetho снова доступна, и все ваши данные в локальном хранилище настроек, весь ваш api полностью перед глазами хитрых хацкеров.
Что же делать?
Есть много вариантов исключить package из финальной сборки. Лично я предпочитаю написать маленький wrapper для инициализации библиотеки Stetho и разложить разные его реализации по вариантам сборки.
release
debug
А также указать, что данная кодовая база нужна только в debug билде.
Можно выдыхать
Хочется в завершении озвучить основные принципы, которые я использую в работе в контексте безопасности Android приложений:
- Минифицируйте и по возможности обфусцируйте все до чего доберетесь.
Это в любом случае усложняет анализ декомпилированного кода. Дополнительным аргументом к созданию седины на голове хацкера будет флаг repackageclasses, который переместит минифицированные классы в один пакет. Их там будет очень много. - Исследуйте свои же приложения.
Хотя бы беглый осмотр дерева ваших пакетов очень много может рассказать об используемой в проекте структуре, фреймворках, библиотеках. То, чему там явно не место, должно беспощадно удаляться. - Любой инструмент может рано или поздно выстрелить вам же в колено.
Добавляя что-либо в свой проект, даже из лучших побуждений, подумайте, как корректнее это сделать и насколько оно вообще вам нужно.
Надеюсь, мой опыт будет вам полезен.