Вы прикладываете палец к смартфону, экран разблокируется, банковское приложение открывается. Кажется, что обе операции защищает один и тот же сканер отпечатков. Но представьте ситуацию, когда датчик исправен, Android правильно распознаёт владельца, а злоумышленник всё равно получает доступ к защищённому разделу приложения.
Для такой атаки необязательно подделывать палец или взламывать алгоритм распознавания. Достаточно найти ошибку в программе, которая получает результат биометрической проверки. Иногда приложение доверяет обычному программному сообщению об успешной аутентификации, хотя должно требовать криптографическое подтверждение.
Уязвимости встречаются и глубже, в системных службах Android, прошивках сканеров и защищённых аппаратных компонентах. Реальные исследования показывают, насколько различаются последствия таких ошибок. В одном случае посторонний получает доступ к конкретному приложению, в другом удаётся обойти экран блокировки, а в третьем требуется уже взломанная операционная система.
Главный вопрос заключается не только в том, насколько хорошо смартфон распознаёт отпечаток или лицо, но и в том, что происходит после успешной проверки.
Материал посвящён принципам работы защиты, известным уязвимостям и безопасной диагностике. Проверять обход аутентификации допустимо на собственных устройствах, в тестовых приложениях или с разрешения владельца.
Как Android проверяет биометрию и где можно обойти защиту
Современный Android разделяет обычную операционную систему и компоненты, которым доверяет проверку личности. Обработка отпечатков и их сопоставление с сохранёнными образцами в корректно реализованной системе выполняются в защищённой среде Trusted Execution Environment (TEE).
Для криптографических операций Android использует Android Keystore и аппаратные механизмы KeyMint. На некоторых устройствах доступен отдельный защищённый компонент StrongBox. При этом StrongBox не является обязательным местом хранения биометрических шаблонов. Его основная роль связана с защитой криптографических ключей и выполнением операций с ними.
Проверка отпечатка проходит несколько этапов.
- Пользователь прикладывает палец к датчику.
- Биометрическая подсистема сравнивает полученные характеристики с зарегистрированным шаблоном.
- Защищённый компонент подтверждает успешное распознавание.
- Системные службы Android обрабатывают результат.
- Приложение получает ответ через BiometricPrompt и решает, какие действия разрешить.
Ключевая граница безопасности проходит между распознаванием владельца и разрешением на доступ к данным. Защищённый компонент может правильно выполнить свою работу, но приложение всё равно допустит ошибку.
Предположим, разработчик добавил вход по отпечатку и после вызова onAuthenticationSucceeded() просто открывает закрытый раздел программы. Если атакующий уже контролирует выполнение приложения, он может попытаться подменить обработку результата проверки.
Такой сценарий не означает, что обычное приложение способно отправить Android фальшивый аппаратный ответ. Для вмешательства в код чужой программы обычно нужны дополнительные возможности, например внедрение инструментов в её процесс, изменённая версия приложения или повышенные привилегии.
Для чувствительных операций Android предлагает более надёжную схему. BiometricPrompt работает совместно с CryptoObject и ключом Android Keystore, использование которого требует аутентификации. Тогда приложение должно не просто получить сообщение об успехе, а выполнить разрешённую криптографическую операцию.
Подделка программного сообщения уже не заменяет действительное разрешение на использование аппаратно защищённого ключа.
Однако криптографическая привязка зависит от правильной настройки самого ключа. Если ключ доступен без аутентификации или программа позволяет выполнить действие альтернативным путём, наличие CryptoObject не решит проблему.
Почему не всякая биометрия Android одинаково надёжна
Android делит биометрические механизмы на три класса. Классификация зависит от устойчивости к подделкам и архитектуры защиты, а не просто от наличия сканера отпечатков или камеры.
| Класс | Назначение | Возможности |
|---|---|---|
| Class 3, Strong | Сильная биометрическая проверка | Поддерживает BiometricPrompt и подтверждение использования криптографических ключей Android Keystore. |
| Class 2, Weak | Биометрическая проверка с меньшими требованиями к стойкости | Может использоваться приложениями через BiometricPrompt, но не разрешает операции с ключами Keystore на основании такой биометрии. |
| Class 1, Convenience | Удобная разблокировка | Может работать на экране блокировки, но не используется приложениями через стандартный BiometricPrompt. |
Поэтому разблокировка лицом на одном Android-смартфоне может подходить для банковского приложения, а на другом использоваться только для открытия экрана. Даже одинаковое название функции не гарантирует одинаковый уровень защиты.
Реальные атаки. Когда сканер работает правильно, а защита ломается
Почти 97% исследованных приложений с ошибками биометрической защиты
В 2025 году на конференции NDSS представили масштабное исследование безопасности биометрии в Android-приложениях.
Из 65 086 изученных программ специалисты выделили 1333 приложения, использовавших аутентификацию по отпечатку пальца. В 1295 программах, или 97,15% выбранной группы, автоматический анализ обнаружил хотя бы один из четырёх типов ошибок. Причём 251 приложение содержало признаки всех четырёх проблем.
Авторы выделили следующие недостатки.
- Устаревшие интерфейсы. Приложение использует старые механизмы работы с отпечатками вместо более современных средств защиты.
- Недостаточная криптографическая проверка. Программа доверяет результату аутентификации, не связывая его надёжно с защищённой операцией.
- Незащищённое отключение биометрии. Настройки дополнительной защиты можно изменить без должного подтверждения полномочий.
- Неправильная обработка новых отпечатков. После изменения зарегистрированных биометрических данных приложение продолжает доверять прежней авторизации.
После раскрытия обнаруженных проблем были присвоены 184 идентификатора CVE и 19 идентификаторов китайской базы CNVD.
Впечатляющая статистика требует осторожной интерпретации. Исследование не доказывает, что почти 97% всех Android-приложений можно взломать. Результат относится к определённой выборке и четырём категориям ошибок, выявленным в том числе автоматическим анализом. Для практической эксплуатации могут потребоваться специальные условия, повышенные привилегии или доступ к разблокированному устройству.
Тем не менее исследование выявило системную проблему. Разработчики нередко уделяют больше внимания самому появлению окна биометрической проверки, чем полноценной защите операции, ради которой окно показывают.
Binance. Новый отпечаток вместо взлома старого
Показательный пример обнаружили в Android-приложении Binance версии 2.85.4. Уязвимость получила идентификатор CVE-2024-31695.
После регистрации нового отпечатка на устройстве приложение не отменяло прежнюю биометрическую авторизацию должным образом. Человек, которому удалось добавить собственный палец, мог использовать его для прохождения биометрической проверки в приложении.
Злоумышленнику не требовалось восстанавливать отпечаток владельца, вмешиваться в работу датчика или подбирать биометрический шаблон. Основная слабость заключалась в том, что программа продолжала доверять изменённому набору зарегистрированных отпечатков.
Но добавить палец на обычном защищённом Android-смартфоне без подтверждения основным способом разблокировки, как правило, нельзя. Поэтому атака предполагает дополнительные условия, например знание PIN-кода устройства или возможность изменить биометрические настройки после получения доступа.
Проблема относилась к указанной версии Binance. Оснований считать актуальные версии приложения уязвимыми тем же способом нет.
Android позволяет защищать ключи от подобной ситуации. Для ключей, требующих биометрического подтверждения при каждом использовании, изменение набора отпечатков по умолчанию может приводить к необратимой утрате действительности ключа. Разработчик способен изменить такое поведение, а при разрешённой проверке через PIN-код действуют дополнительные условия.
Поэтому отсутствие выхода из приложения после добавления нового отпечатка само по себе ещё не доказывает уязвимость. Нужно проверить, как программа защищает ключи, сессии и критичные действия.
PHYjacking. Когда пользователь сам подтверждает чужую операцию
В исследовании PHYjacking, представленном на NDSS в 2022 году, продемонстрировали другой способ атаки. Вместо взлома сканера злоумышленник пытается обмануть человека, который проходит настоящую биометрическую проверку.
Вредоносное приложение создаёт ложный интерфейс или скрывает контекст подтверждения. Пользователь видит привычное предложение приложить палец и выполняет действие, не подозревая, что настоящая проверка связана с другой операцией.
В экспериментальных сценариях исследователи смогли добиться несанкционированного денежного перевода, доступа к закрытой информации и изменения разрешений. Для отдельных вариантов атаки не требовалось запрашивать опасные разрешения Android.
Главное отличие от поддельного отпечатка заключается в том, что смартфон действительно распознаёт зарегистрированного владельца. Ошибка возникает при связывании результата проверки с действием, которое пользователь не собирался подтверждать.
Проблемы с наложением интерфейсов встречались и позднее. В Android 15 и 16 уязвимость CVE-2025-48528 позволяла при определённых условиях использовать наложения поверх биометрических элементов и приводила к риску локального повышения привилегий.
Исправление вошло в сентябрьское обновление безопасности Android 2025 года. Публичное описание не позволяет утверждать, что уязвимость предоставляла универсальный обход экрана блокировки или работала на любом устройстве.
Оба случая показывают ограничение биометрии как средства подтверждения действий. Система способна надёжно установить факт распознавания владельца, но безопасность платежа дополнительно зависит от того, какие сведения пользователь видел и что именно приложение разрешило.
InfinityGauntlet. Перебор отпечатков на аппаратном уровне
Не все атаки ограничиваются программной логикой. В 2023 году исследователи представили InfinityGauntlet, способ перебора отпечатков с использованием специального оборудования.
В ходе экспериментов специалисты обнаружили недостатки реализации ограничений на число попыток распознавания. Атака использовала взаимодействие с аппаратными интерфейсами сканера, позволяла автоматизировать попытки проверки и обходить отдельные защитные механизмы.
Для одного из экспериментальных сценариев удалось продемонстрировать успешную атаку менее чем за час без предварительного знания отпечатка владельца.
Результат не означает, что любой Android-смартфон можно разблокировать за час. Эксплуатация зависела от конкретного оборудования, реализации датчика и ошибок устройства. Атакующему требовались физический доступ и специальная аппаратная подготовка.
InfinityGauntlet интересна другим. Защищённое хранение биометрического шаблона не гарантирует безопасность, если производитель неправильно реализовал ограничения попыток или взаимодействие между датчиком и доверенной средой.
Уязвимости самой Android и защищённого оборудования
Самая серьёзная категория ошибок затрагивает не отдельное приложение, а системные компоненты смартфона.
Samsung. Ошибки в доверенной среде
В июне 2025 года Samsung выпустила исправления нескольких уязвимостей компонентов, обслуживающих биометрическую аутентификацию.
CVE-2025-20987 затрагивала контроль доступа в защищённом компоненте сканера отпечатков и позволяла локальному атакующему с повышенными привилегиями получить токен аутентификации.
Другая уязвимость, CVE-2025-20989, была связана с некорректным журналированием и могла раскрыть криптографический ключ HMAC. Ошибка CVE-2025-20988 допускала чтение памяти за пределами разрешённой области.
Перечисленные проблемы относились к уязвимым реализациям Samsung с Android 13, 14 и 15 до соответствующих исправлений. Для эксплуатации требовались повышенные локальные привилегии.
Следовательно, речь не о возможности установить обычную программу из магазина и немедленно получить доступ к чужим отпечаткам. Но такие уязвимости показывают, что доверенная среда TEE тоже содержит программный код, в котором могут возникать ошибки.
TEE защищает данные от обычной операционной системы, пока соблюдаются аппаратные и программные границы изоляции. При обнаружении уязвимости в самом доверенном компоненте уровень защиты меняется.
Google Pixel. Обход экрана без взлома биометрии
В 2022 году уязвимость CVE-2022-20465 позволяла обойти экран блокировки Google Pixel при физическом доступе к устройству и определённой последовательности действий с SIM-картой.
Ошибка находилась в логике обработки экрана блокировки после операции с PIN- и PUK-кодами SIM-карты. Система могла ошибочно закрыть защитный экран и предоставить доступ без ввода основного пароля смартфона.
Уязвимость исправили в ноябре 2022 года.
Сканер отпечатков в таком сценарии вообще не требовался. Пример хорошо иллюстрирует разницу между взломом биометрического распознавания и обходом другого компонента системы безопасности, который должен ограничивать доступ к устройству.
Что происходит, если Android уже скомпрометирована
После получения контроля над системными процессами возможности атакующего расширяются. В зависимости от глубины компрометации он может вмешиваться в работу приложений, менять их поведение, перехватывать доступные данные и использовать действующие пользовательские сессии.
Однако права суперпользователя не означают автоматического доступа ко всем биометрическим шаблонам и криптографическим ключам. Исправная аппаратная изоляция продолжает ограничивать возможности основной операционной системы.
Здесь полезно различать несколько сценариев.
| Ситуация | Что может получить атакующий | Что не следует предполагать автоматически |
|---|---|---|
| Физический доступ к заблокированному смартфону | Возможность использовать известный PIN-код или конкретную системную уязвимость | Что любой биометрический сканер можно обойти |
| Ошибка приложения | Доступ к отдельной функции, данным или уже открытой сессии | Что взломана защита всего смартфона |
| Компрометация Android | Контроль над доступными процессами, интерфейсами и частью пользовательских данных | Что аппаратные ключи и шаблоны обязательно раскрыты |
| Уязвимость в TEE или биометрической подсистеме | Нарушение изоляции, раскрытие чувствительных данных или токенов при подходящих условиях | Что существует универсальный способ эксплуатации всех устройств |
Особенно опасна ситуация, когда приложение защищает только интерфейс, а сервер продолжает принимать запросы по ранее выданному токену доступа. Злоумышленнику может вообще не понадобиться проходить новую биометрическую проверку.
Надёжная защита чувствительной операции требует не только проверки пользователя на смартфоне, но и контроля полномочий на сервере. Для платежей полезна криптографическая подпись конкретной операции с привязкой к её содержимому и одноразовому запросу, чтобы подтверждение нельзя было использовать повторно или перенести на другую транзакцию.
Как проверить защиту своего смартфона и приложения
Проверить внутреннюю реализацию TEE без специализированных инструментов пользователь не сможет. Но самые распространённые риски можно существенно снизить обычными настройками Android.
Что проверить владельцу смартфона
- Установите обновления безопасности. Откройте настройки Android и найдите раздел обновления системы и исправлений безопасности. Проверьте также обновления компонентов Google Play, если устройство поддерживает такой механизм. Отдельные исправления производителя могут выпускаться независимо от общего бюллетеня Android.
- Используйте длинный PIN-код или пароль. Основной код защищает не только разблокировку экрана, но и изменение настроек биометрии. Если посторонний знает PIN-код, надёжный сканер отпечатков уже не обеспечивает прежний уровень защиты.
- Проверьте список отпечатков и лиц. Удалите неизвестные или ненужные записи. Не добавляйте биометрию других людей ради удобства.
- Ограничьте опасные разрешения. Проверьте доступ приложений к специальным возможностям Android и разрешению показывать окна поверх других приложений. Такие возможности полезны для некоторых программ, но требуют доверия к разработчику.
- Защитите финансовые операции отдельно. Включите доступные дополнительные проверки, уведомления о платежах и ограничения на операции. Биометрический вход в приложение не должен оставаться единственным препятствием перед крупным переводом.
При риске принудительной разблокировки можно использовать режим блокировки Android, который временно отключает биометрический вход и требует основной код. О работе такой защиты и её ограничениях мы подробнее рассказывали в материале о режиме Lockdown.
Для проверки установленного уровня исправлений через ADB выполните команду на собственном устройстве с разрешённой отладкой по USB.
adb shell getprop ro.build.version.security_patch
Команда показывает заявленную устройством дату обновления безопасности Android. Результат сам по себе не подтверждает наличие каждого исправления производителя или отсутствие уязвимостей в драйверах и защищённых компонентах.
После диагностики отключите отладку по USB, если больше не используете ADB.
Что проверить разработчику Android-приложения
Главная ошибка разработчика заключается в предположении, что успешный вызов BiometricPrompt автоматически защищает все операции приложения.
Для входа в защищённый раздел или работы с локальным секретом нужно проверить, что именно предотвращает доступ без биометрии.
- Используйте актуальный BiometricPrompt и совместимую библиотеку AndroidX Biometric вместо самодельных окон проверки.
- Для чувствительных действий применяйте криптографическую привязку через Android Keystore, а не только программный ответ onAuthenticationSucceeded().
- Проверьте параметры setUserAuthenticationRequired(true) и setUserAuthenticationParameters(). Для операций, требующих отдельного подтверждения, срок действия разрешения можно установить равным нулю.
- Проверьте поведение ключей после регистрации нового отпечатка, удаления биометрии, отключения блокировки экрана и смены основного способа аутентификации.
- Не храните токены доступа в открытом виде и не считайте локальную биометрию заменой серверной авторизации.
Для ключей с подтверждением при каждом использовании принципиальна разница между простым сообщением об успехе и настоящей криптографической операцией. Практический разбор такого подхода с примерами настроек доступен в рекомендациях OWASP.
Надёжный сценарий можно построить следующим образом. Приложение получает от сервера одноразовый запрос, связывает его с конкретным действием, после биометрической проверки подписывает данные ключом из Android Keystore, а сервер проверяет подпись и полномочия пользователя.
Для криптографического подтверждения при каждом использовании ключа на Android требуется подходящий аутентификатор, например биометрия класса Strong. Если приложение допускает обычный PIN-код как альтернативу, параметры ключа и логика подтверждения должны явно учитывать такой вариант.
Даже при правильном использовании Keystore нельзя считать защищённым весь пользовательский сеанс. Следует отдельно проверять хранение данных, обработку ошибок, срок жизни токенов и возможность выполнить операцию через другие интерфейсы приложения.
Частые вопросы
Можно ли обойти биометрию Android без поддельного отпечатка?
Да, при наличии подходящей уязвимости в приложении, системе или механизме управления доступом. Например, программа может неправильно обрабатывать результат проверки или сохранять действующую авторизацию после изменения отпечатков. Но универсального программного способа разблокировать любой современный Android-смартфон без пароля не существует.
Может ли вредоносная программа подделать успешную биометрическую проверку?
При достаточном контроле над выполнением приложения атакующий может вмешаться в обработку результата проверки. Если приложение полагается только на программное сообщение об успехе, возникает риск обхода. Аппаратно защищённая криптографическая операция существенно затрудняет такую атаку, поскольку поддельный результат не предоставляет права использовать ключ.
Можно ли украсть отпечаток пальца после получения root-доступа?
Root-доступ не означает автоматического получения биометрических шаблонов. В корректно реализованной системе шаблоны защищены аппаратной изоляцией. Однако в истории Android встречались ошибки доверенных компонентов и отладочных интерфейсов, позволявшие при дополнительных условиях раскрывать чувствительные данные. Поэтому стойкость зависит от конкретной реализации и установленных исправлений.
Почему банковское приложение может оказаться менее защищённым, чем экран блокировки?
Экран блокировки контролируют системные механизмы Android. Банковское приложение самостоятельно управляет сессиями и определяет действия после биометрической проверки. Ошибка приложения может позволить обойти дополнительную локальную защиту, не затрагивая системную разблокировку смартфона. При этом банковский сервер может сохранять собственные ограничения на вход и проведение операций.
Если добавить новый отпечаток, все приложения должны потребовать пароль?
Нет, поведение зависит от настроек ключей, разрешённых способов аутентификации и правил конкретного приложения. Некоторые ключи Android Keystore автоматически становятся недействительными после изменения зарегистрированной биометрии. Но приложения могут использовать другие механизмы защиты, поэтому отсутствие запроса пароля не всегда указывает на уязвимость.
Достаточно ли обновлять Android, чтобы защититься от обхода биометрии?
Нет. Обновления Android закрывают известные системные уязвимости, но не обязательно исправляют ошибки банковских приложений, сторонних библиотек и серверной авторизации. Нужны также обновления приложений, надёжный код разблокировки и дополнительные проверки критичных операций.
Вывод. Биометрическая защита смартфона представляет собой цепочку из нескольких компонентов. Сканер распознаёт владельца, защищённая среда обрабатывает чувствительные данные, Android передаёт результат, а приложение определяет дальнейшие действия.
Реальные атаки показывают, что взламывать сам отпечаток требуется далеко не всегда. Ошибки программной логики, недостаточная криптографическая привязка, неправильная обработка новых отпечатков и уязвимости системных компонентов способны нарушить защиту без подделки пальца.
Для владельца смартфона разумный минимум состоит из надёжного PIN-кода, актуальных исправлений, контроля зарегистрированной биометрии и дополнительного подтверждения важных операций. Разработчикам следует защищать не только окно входа, но и сам доступ к данным и действиям. Биометрия действительно полезна, когда успешное распознавание связано с криптографическим разрешением и проверкой полномочий. В противном случае даже самый дорогой сканер может оказаться лишь красивой кнопкой перед недостаточно защищённым приложением.
