Обнаружение root и jailbreak: зачем нужно и как внедрить

Когда мобильное приложение нашего собственного продукта проходило экспертизу, первой находкой высокого уровня в отчёте было: «Не реализовано обнаружение root» (MASWE-0097, OWASP Mobile Top 10 2024 M7). Для iOS-приложения была такая же находка — не обнаруживается jailbreak. Многие разработчики считают это второстепенным вопросом. Экспертиза же оценивает его как высокий риск. Разберёмся, почему так и как это закрыть.

Что такое root и jailbreak

Android и iOS запускают каждое приложение в отдельной «песочнице» (sandbox). Одно приложение не может читать файлы другого и менять системные файлы. На этой изоляции держится значительная часть мобильной безопасности.

Root (Android) и jailbreak (iOS) — это снятие этих ограничений. Пользователь или другой человек, получивший доступ к устройству, получает максимальные права и может открыть папку любого приложения, перехватывать системные вызовы, читать память.

Почему это проблема для приложения

Рутованное устройство само по себе не преступление, чаще всего его делают просто любопытные пользователи. Проблема в том, что на таком устройстве ослабевают и остальные защитные слои приложения:

• Сохранённые данные становятся доступными. Файлы во внутреннем хранилище, база данных и настройки становятся читаемыми для других процессов.
• Динамический анализ упрощается. Frida и подобные инструменты проще всего работают именно на рутованном устройстве.
• Проверку сертификатов можно обойти. Появляется возможность установить сторонний CA на системном уровне или отключить функцию проверки через хук.
• Вредоносные программы становятся сильнее. Если на устройстве есть вредоносное приложение с правами root, оно доберётся и до данных вашего приложения.

Для приложения, работающего с финансовыми, налоговыми или медицинскими данными, такая среда недопустимо рискованна. Поэтому группа RESILIENCE в MASVS требует, чтобы приложение проверяло окружение.

Обнаружение root само по себе данные не защищает. Оно даёт приложению сигнал: «в этой среде на остальные защиты полагаться нельзя».

Как работает обнаружение

Одной надёжной проверки нет, поэтому проверяется сразу несколько признаков.

Android

• Наличие файла su в типичных местах: /system/bin/su, /system/xbin/su, /sbin/su.
• Пакеты или файлы менеджеров root, таких как Magisk и SuperSU.
• Системная сборка подписана test-keys (ro.build.tags).
• Раздел /system доступен на запись.
• Опасные системные свойства, например ro.debuggable=1.
• Аттестация устройства с проверкой на сервере — Google Play Integrity API. Это самый сильный признак, потому что результат подписывается не в приложении, а на сервере Google и проверяется вашим бэкендом.

iOS

• Приложения и файлы джейлбрейка: Cydia, Sileo, /Applications/Cydia.app, /private/var/lib/apt.
• Попытка записи за пределы песочницы: обычное приложение не должно иметь возможности записать файл в /private.
• Сторонние динамические библиотеки, загруженные в процесс приложения (например, MobileSubstrate).
• Возможность открыть URL-схемы вроде cydia://.

Как мы внедрили это на практике

Эти проверки можно написать самостоятельно, но средства скрытия root (например, модули скрытия Magisk) постоянно обновляются, и самописные проверки быстро устаревают. Поэтому в нашем Flutter-приложении использована RASP-библиотека freeRASP. Она в одном месте проверяет root, jailbreak, эмулятор, хуки, отладчик и целостность приложения и выдаёт отдельный сигнал для каждого случая.

На что мы обратили внимание при внедрении:

1. Проверка запускается при старте приложения, до экрана входа. Чувствительные данные к этому моменту ещё не должны быть загружены.
2. При обнаружении угрозы показывается блокирующий экран. Пользователю понятным языком объясняется, что произошло: приложение не может работать в небезопасной среде. Пугающие формулировки не используются.
3. Проверка не одноразовая. RASP следит и во время работы, потому что права root можно получить и после открытия приложения.
4. Release и debug сборки разделены. При разработке нужны эмулятор и отладчик, поэтому блокировка включается только в release-сборке. Проверьте, что эта настройка случайно не попадёт в релиз в отключённом виде.

Блокировать или предупреждать?

Это бизнес-решение. Есть два подхода:

• Блокировка — приложение вообще не работает на рутованном устройстве. Типичный выбор для финансовых и государственных приложений, экспертиза его хорошо принимает.
• Ограничение — приложение открывается, но важные действия, такие как оплата или просмотр чувствительных данных, отключаются, а сервер получает уведомление.

Просто показать предупреждение и разрешить всё — с точки зрения экспертизы недостаточно.

Ещё один важный момент: не держите результат обнаружения только внутри приложения. По возможности передавайте его и серверу (например, через токен Play Integrity). Проверку внутри приложения можно отключить хуком, а серверную проверку обойти так значительно сложнее.

Проверьте сами

После внедрения протестируйте результат на практике:

1. Запустите release-сборку на рутованном Android-устройстве (или на эмуляторе с Magisk).
2. Повторите тест с включённым модулем скрытия root.
3. Проверьте на iOS-устройстве с джейлбрейком.
4. Убедитесь, что на обычном устройстве нет ложных блокировок (false positive) — для пользователей это самый неприятный сценарий.

Вывод

Обнаружение root и jailbreak — не единственная защита приложения, но необходимое условие, чтобы все остальные защиты работали надёжно. Вместе с RASP, закреплением сертификатов и безопасным хранением оно отвечает требованиям экспертизы.

Если хотите узнать, насколько корректно в вашем приложении работает обнаружение root и jailbreak, оставьте заявку на сканирование. Мы проверим APK или IPA и поможем подготовить приложение к экспертизе.