Android: новый метод рутинга и большое исследование безопасности IPC в приложениях

Почитать

Новый метод рутинга

Kernel Assisted Superuser (KernelSU) — The Final Frontier for SafetyNet and an Essential Developer Tool — небольшая статья о KernelSU, новом способе рутинга Android путем прямого патчинга ядра.

В последнее время одним из основных методов получения прав root на Android стал Magisk. Он использует так называемый systemless-способ рутинга, когда вместо модификации раздела system поверх него подключается виртуальный раздел, содержащий бинарный файл su, необходимый приложениям для получения прав root. Такой метод позволяет избежать проблем с обновлениями, а также эффективно скрывать наличие прав root на устройстве.

Проблема, однако, в том, что Google и разработчики приложений изобретают новые методы обнаружения root, а разработчику Magisk приходится придумывать методы борьбы с ними. В долгосрочной перспективе способы скрытия могут исчерпаться.

Метод KernelSU, предложенный разработчиком zx2c4, базируется на совершенно другой идее. Вместо подключения виртуального раздела или физического размещения файла su в разделе system он использует модифицированное ядро, чтобы заставить приложения «думать», что в системе действительно есть файл /system/bin/su. Ядро перехватывает все обращения к этому файлу и, если приложение пытается с его помощью запустить команды, автоматически исполняет их с правами root.

Работая прямо в ядре, KernelSU имеет гораздо больше возможностей для скрытия и обхода различных ограничений Android, в том числе правил SELinux.

В данный момент проект KernelSU находится в зачаточной стадии развития. Доступен только патч, который энтузиасты могут использовать для сборки кастомных ядер.

Небезопасный IPC в софте для Android

Security Code Smells in Android ICC — большое исследование безопасности приложений, использующих механизмы межпроцессного взаимодействия Android. Авторы взяли около 700 открытых приложений из репозитория F-Droid и проанализировали, есть ли в их коде проблемы в использовании IPC.

Анализ был произведен с помощью специально созданного инструмента AndroidLintSecurityChecks, который показывает наличие в коде потенциальных брешей. Все проблемы скомпоновали в 12 категорий:

• SM01: Persisted Dynamic Permission. В Android есть механизм, позволяющий предоставить другому приложению временный доступ к какому-либо URI своего ContentProvider’а. Это делается с помощью метода Context.grantUriPermission(). Если приложение вызывает его, но не вызывает Context.revokeUriPermission(), чтобы отозвать доступ, — есть проблемы.
• SM02: Custom Scheme Channel. Любое приложение может зарегистрировать собственную URI-схему, такую как myapp://, вне зависимости от того, использует ли такую схему другое приложение. Как следствие, пересылать важные данные, используя кастомные URI-схемы, крайне небезопасно.
• SM03: Incorrect Protection Level. В Android есть система разрешений и любое приложение может создать свое собственное разрешение для доступа к своим данным. Но есть проблема: если указать неправильный уровень защиты разрешения (protection level), оно может не сработать. Если разработчик хочет, чтобы пользователь видел диалог запроса разрешений, он должен использовать уровень защиты dangerous или signature, если данное разрешение должно получать только приложение с той же цифровой подписью.
• SM04: Unauthorized Intent. Любое приложение в Android может зарегистрировать себя в качестве обработчика определенных типов интентов (intent). По умолчанию этот обработчик будет открыт всему миру, но его можно защитить с помощью системы разрешений и строгой валидации входных данных.
• SM05: Sticky Broadcast. Любое приложение может послать другому приложению интент. Более того, оно может послать широковещательный интент сразу всем приложениям, и он будет обработан первым приложением, способным его принять. Но есть также возможность послать широковещательный sticky-intent, который после обработки одним приложением все равно будет доставлен другим приложениям. Чтобы этого не происходило, не стоит использовать такие интенты, а от широковещательных интентов лучше отказаться вообще.
• SM06: Slack WebViewClient. Компонент WebView позволяет приложениям показывать веб-страницы внутри своего интерфейса. По умолчанию он никак не фильтрует открываемые URL, чем можно воспользоваться, например, для фишинга. Разработчикам стоит либо использовать белый список адресов, либо выполнять проверку с помощью SafetyNet API.
• SM07: Broken Service Permission. Приложения могут предоставлять доступ к своей функциональности с помощью сервисов. Злоумышленник может использовать эту возможность для запуска кода с повышенными полномочиями (полномочиями сервиса). Чтобы этого избежать, сервис должен проверять полномочия вызывающего приложения с помощью метода Context.checkCallingPermission().
• SM08: Insecure Path Permission. Некоторые приложения предоставляют доступ к своим данным с помощью ContentProvider’а, который адресует данные, используя UNIX-подобные пути: /a/b/c. Программист может открыть доступ к своему ContentProvider’у, но отрезать доступ к некоторым путям (например, к /data/secret). Но есть проблема: разработчики часто используют класс UriMatcher для сравнения путей, а он, в отличие от Android, сравнивает их без учета двойных слешей. Отсюда могут возникнуть ошибки при разрешении и запрете доступа.
• SM09: Broken Path Permission Precedence. Сходная с предыдущей проблема. При описании ContentProvider’а в манифесте разработчик может указать, какие разрешения нужны приложению для доступа к определенным путям. Но в Android есть баг, из-за чего он отдает предпочтение более глобальным путям. Например, если приложение дает доступ к /data всем подряд, но использует специальное разрешение для доступа к /data/secret, то в итоге доступ к /data/secret смогут получить все.
• SM10: Unprotected Broadcast Receiver. Фактически аналог проблемы SM04, но распространяющийся исключительно на BroadcastReceiver’ы (специальные обработчики интентов).
• SM11: Implicit Pending Intent. Кроме интентов, в Android есть сущность под названием PendingIntent. Это своего рода отложенные интенты, которые могут быть отправлены позже и даже другим приложением от имени создавшего интент приложения. Если PendingIntent широковещательный, то любое приложение сможет перехватить его и послать интент от имени этого приложения.
• SM12: Common Task Affinity. Об этой проблеме мы уже рассказывали в «Хакере». Суть в следующем: в Android все экраны приложения (activity) объединяются в таск, который представляет собой своего рода стопку экранов. В то же время в Android есть средство, которое позволяет одному приложению всунуть свой экран в стопку другого приложения. Для этого буквально достаточно указать имя этого приложения в атрибуте android:taskAffinity у активности, которую нужно внедрить. А чтобы защититься, разработчик должен указать в этом атрибуте пустую строку.

В работе также приводится множество аналитических данных. Например, согласно статистике, в новых приложениях меньше дыр, чем в старых. Больше дыр также в приложениях, которые разрабатывают более пяти человек. Ну и, сюрприз-сюрприз, большее количество кода означает большее количество уязвимостей.

Вредоносные библиотеки

A Confusing Dependency — поучительная история о том, как можно добавить в приложение зловредный код, всего лишь подключив популярную библиотеку.

Все началось с того, что автор решил подключить к проекту библиотеку AndroidAudioRecorder и обнаружил, что сразу после старта приложение крашится, выбрасывая исключение java.lang.SecurityException: Permission denied (missing INTERNET permission?). Это означает, что приложение не может получить доступ к интернету, так как отсутствует необходимое для этого разрешение.

Выходит, библиотеке для записи звука с микрофона почему-то нужен интернет? Автор взглянул в код приложения и нашел в нем метод, отсылающий на удаленный сервер модель и производителя смартфона. В попытках разобраться, зачем разработчику популярной библиотеки вставлять в свою библиотеку такой противоречивый код, он попытался найти такой же участок кода в официальном репозитории библиотеки и не нашел его.

Получалось, что разработчик намеренно обманывал пользователей библиотеки, распространяя альтернативную сборку библиотеки, которая отличается от официальных исходников. Или... кто-то залил в репозиторий фейковую библиотеку.

Суть истории. Существует репозиторий Java-пакетов jCenter, привязанный к системе дистрибуции Bintray. Android Studio использует jCenter как дефолтовый репозиторий для новых проектов: он уже включен в список репозиториев в build.gradle наряду с репозиторием Google. Однако многие разработчики предпочитают размещать свои библиотеки в репозитории JitPack, который умеет автоматически генерировать и выкладывать в репозиторий библиотеки из GitHub-репозитория (это удобно и просто).

Библиотека AndroidAudioRecorder также была выложена в JitPack, так что автор статьи перед ее использованием добавил JitPack в build.gradle. Но оказалось, что в jCenter тоже была выложена эта библиотека с внедренным в нее зловредным кодом. А так как jCenter в списке репозиториев идет первым, система сборки взяла библиотеку именно из него, а не из JitPack.

Один из способов решения этой проблемы — разместить jCenter в конце списка репозиториев в build.gradle.

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

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

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

-60% 1 год 9990 рублей 4000 р.

1 месяц 920 р.

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

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

Я уже участник «Xakep.ru»