Сегодня в выпуске: security-новшества Android 11, анализ нативной версии трояна Joker, советы о хранении секретных данных в приложении, способ усовершенствовать обфускацию кода на Kotlin, а также лучшие инструменты разработчика для Android и очередная подборка полезных библиотек.
 

Почитать

 

Security-новшества Android 11 DP1

Turning it up to 11: the first Developer Preview of Android 11 — статья о новшествах Android 11 Developer Preview 1. Мы, как обычно, сконцентрируемся на приватности и безопасности.

  • Одноразовые разрешения. Начиная с Android 11 пользователь сможет дать разрешение на ту или иную операцию только на один раз. Как только приложение будет свернуто, оно потеряет разрешение, и его придется запрашивать снова.
  • Scoped Storage. Android 11 закроет приложениям прямой доступ к файлам на внутренней и внешней картах памяти, но только в том случае, если target API приложения равен 30.
  • Расширенный API биометрической аутентификации. В API BiometricPrompt, реализующем диалог биометрической аутентификации, появилась поддержка трех типов аутентификации: надежный, слабый и учетные данные устройства.
  • Новые средства защиты от эксплоитов. Разработчики расширили применение механизмов защиты, работающих на этапе компиляции: CFI (Control Flow Integrity), BoundSan, IntSan (Integer Overflow Sanitization) и ShadowCallStack. Для выявления проблем при работе с памятью в приложениях включена проверка указателей в куче на основе привязанных к ним тегов (heap pointer tagging). Также разработчики могут использовать специальный системный образ, в котором включен отладочный механизм HWAsan (Hardware-assisted AddressSanitizer).
  • API для безопасного обмена данными. Появился API BlobStoreManager для безопасного обмена бинарными данными между приложениями. Его можно использовать, например, для передачи моделей данных машинного обучения.
  • Хранилище документов. Добавилась поддержка безопасного хранения и извлечения проверяемых идентификационных документов, таких как электронные водительские удостоверения.
Одноразовые разрешения в Android 11
Одноразовые разрешения в Android 11
 

Как работают одноразовые разрешения Android 11

Exploring the Android 11 Developer Preview: Permission Changes — статья, поясняющая работу одноразовых разрешений. Основные моменты:

  • Одноразовое разрешение будет отозвано, как только запросившая разрешение активность (экран) приложения уйдет в фон (пользователь вернется на домашний экран или откроет другое приложение).
  • Если у приложения есть foreground-сервис, который был активен в момент ухода активности в фон и ее возврата, то одноразовое разрешение будет возвращено этой активности.
  • В предыдущих версиях Android пользователь мог запретить повторный показ запроса определенного разрешения с помощью чекбокса Don’t ask again. Android 11 заблокирует повторный показ запроса, если пользователь два раза откажется предоставлять разрешение.
  • Исключение из предыдущего правила: если пользователь нажмет кнопку «Назад», чтобы закрыть диалог запроса разрешения, это будет интерпретировано как отказ предоставлять разрешение, но запрос будет появляться снова. Однако это не относится к тем диалогам запроса разрешений, которые перекидывают пользователя в настройки.

Отдельно автор отмечает, как изменилась работа разрешения на доступ к местоположению в фоне. Это разрешение появилось в Android 10, но начиная с Android 11 приложение не может запросить его у пользователя. Единственный способ получить разрешение — перекинуть пользователя в окно настроек приложения и попросить включить его вручную.

Как работает отказ предоставлять разрешение
Как работает отказ предоставлять разрешение
 

Анализ нативной версии трояна Joker

A closer look at the native speaking Android Joker malware from Google Play — анализ новой версии трояна Joker, большая часть кода которого вынесена в нативную библиотеку.

Впервые Joker (или Bread в терминологии Google) обнаружили в 2017 году. Это был троян, распространяющийся через Google Play и подписывающий пользователя на разного рода платные услуги, в том числе требующие подтверждения по SMS (он умел перехватывать сообщения и анализировать их содержимое).

Со временем Joker эволюционировал настолько, что использовал практически все известные техники скрытия и обфускации, а в начале года в Google Play стали находить все больше вариантов Joker, часть компонентов которого вынесена в нативный код.

Одно из приложений, внутри которого обнаружили новую версию Joker, — VPN-клиент Fast VPN. По сути, это перепакованная версия приложения Thunder VPN, которая при старте приложения запускает в фоне зловредный код. Часть функциональности трояна при этом вынесена в нативную библиотеку libpdker.so, пропущенную через обфускатор на базе LLVM.

Нативная библиотека включает в себя базовую функциональность трояна, например функции для работы с SIM-картами и обработки SMS (которые троян получает с помощью доступа к уведомлениям). Также нативная библиотека отвечает за прием команд от управляющего сервера (C&C). Набор команд и их формат, в сущности, остался прежним, как и использование голого HTTP в качестве протокола.

Интересно, что в отличие от прошлых версий трояна эта версия не использует какой-то специальной формы обфускации имен методов. Некоторые имена просто случайны (Kanble, Yunbe, PtCher, VenNor), другие похожи на слегка измененные (QertOptor — QueryOperator, ReterString — ReturnString, WenNoti — WhenNotified, pdker — Joker?), еще одни никак не изменены (BigConfig, BleOpenSettings, HuOpenSettings). Но обфускация строк стала еще более запутанной.

В целом эта версия трояна больше похожа на эксперимент, чем на развитие.

 

Разработчику

 

Как хранить секреты

Protecting secrets in an Android project — статья о том, как правильно хранить секреты, например ключи API, в своем приложении.

Все секретные строки лучше вынести в отдельный файл, который хранится вне системы контроля версий. Это позволит избежать недоразумений, когда разработчик заливает код в открытый репозиторий и таким образом выставляет ключи на всеобщее обозрение. Также такой подход позволяет расшаривать ключи между несколькими приложениями. Секреты можно хранить, например, в файле ~/.gradle/gradle.properties:

GameCatalogueApp_UploadKeystore_KeyPassword=aaaabbbbcccc
GameCatalogueApp_AuthClientSecret=123456789
GameCatalogueApp_Pusher_APIKey=ksldjalksdjskald

Чтобы сделать их доступными в исходном коде, можно использовать приблизительно такой трюк (пример для скрипта Gradle на Kotlin):

defaultConfig {
  buildConfigField(
    "String", 
    "AUTH_CLIENT_SECRET", 
    buildConfigProperty("GameCatalogueApp_AuthClientSecret")
  )

  resValue(
    "string", 
    "pusher_key", 
    propertyOrEmpty("GameCatalogueApp_Pusher_APIKey")
  )
}

fun Project.buildConfigProperty(name: String) = "\"${propertyOrEmpty(name)}\""

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

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Оставить мнение