Содержание статьи
Почитать
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
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»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Я уже участник «Xakep.ru»
