Технология защиты от угрозы подмены биометрического сканера

Технология защиты от угрозы подмены биометрического сканера

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

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

Угроза 1: кража случайного числа

Значение случайного числа, передаваемого через push-уведомление, неизвестно злоумышленнику — на этом постулате основана вся схема создания аутентификатора для мобильного приложения. В случае перехвата его на сервере или в push-сервисе защита рушится, и злоумышленник сможет акцептовать собственное мобильное приложение (рисунок 5).

Рисунок 5. Угроза кражи случайного числа на серверной части или в push-сервисе

Действительно, в данном случае злоумышленнику уже не интересно, дойдёт ли push-уведомление до какого-нибудь мобильного приложения — ему вообще не нужно использовать официальное мобильное приложение. Злоумышленник отправляет любой случайный push-идентификатор, получает сгенерированное случайное число на серверной части, передаёт его в своё приложение, подписывает на собственном закрытом ключе и отправляет на сервер, где подтверждается закрытый ключ злоумышленника. Хотя такая кража маловероятна, но в случае Сбербанка перед отправкой push-уведомление проходит большое количество внутренних систем перед тем, как попасть в push-сервис производителя операционной системы. Поэтому защитные меры необходимы. Шифрование здесь не поможет, так как мы можем зашифровать сообщение только в адрес того же самого злоумышленника, и он его легко расшифрует. Защититься от угрозы можно только при помощи организационных мер и end-to-end защитой канала от сервера к push-сервису.Это стандартные меры защиты, то и останавливаться на них мы их рассматривать не будем.

Угроза 2: кража push-идентификатора и случайного числа на устройстве

Следующая угроза — перехват злоумышленником push-идентификатора и случайного числа на своём мобильном устройстве с установленным легитимным приложением (рисунок 6).

Рисунок 6. Угроза кражи push-идентификатора и случайного числа при использовании злоумышленником легитимного мобильного приложения

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

Например, в случае Android и сервиса Firebase Cloud Messaging перехватить push-идентификатор можно при помощи простого прокси-сервера (например, Burp Suite) с подменой TLS-сертификатов, так как Android при обращении к этому облачному сервису не осуществляет TLS-пининг. Поэтому достаточно установить в хранилище доверенных сертификатов мобильного устройства сертификат прокси-сервера и найти push-идентификатор в расшифрованном трафике.

Запрос будет выглядеть примерно следующим образом (здесь он сильно сокращён):

POST /c2dm/register3 HTTP/1.1

app: ru.mfedotenko.push

Host: android.clients.google.com

X-subtype=…&X-X-subscription=…&sender=1136792233789&X-X-subtype=…&X-app_ver=1&…&X-sig=…&X-cliv=…&X-gmsv=…&X-pub2=…&X-X-kid…&X-appid=…&X-scope=*&X-subscription=…&X-gmp_app_id=1%3A1036791400789%3Aandroid%3A7e3a9140abe14d85&X-app_ver_name=…&app=ru.mfedotenko.push&device=….&cert=…&app_ver=1&info=…&gcm_ver=…

А ответ будет содержать push-идентификатор:

HTTP/1.1 200 OK

Server: GSE

token=|ID|1|:cFX2BI99kfk:APA91bGcxC7DKHlb1abcFZXvREYhonhoyBR50cAFS1pZrf6hcsQtot160PmyoSaothklhFa6R-AB--FkVe07YYvTlPlKKpvAVEAvaid6vaaIUl3thvNNo81sC-K6-LWmZfXAnTVS75RzcwNwiwiX5r7j9ivJrq0VbQ

Далее злоумышленнику необходимо получить отправленное на легитимное мобильное приложение случайное число. Для этого можно воспользоваться приложением из Google Play (например, Notification Blocker, Notification History и т.п.) или разработать собственное. Суть работы этих приложений в том, что они подключаются к системной службе Notification Listener, которая отслеживает все уведомления на устройстве. Естественно, для подключения к службе нужны соответствующие права доступа, которые нужно запросить с использованием файла манифеста, например, так:

android:name="android.service.notification.NotificationListenerService" />

При запуске такой программы от пользователя потребуется разрешить ей доступ к уведомлениям. После этого в ней можно будет просматривать уведомления, приходящие в наше мобильное приложение.

Как бы производители мобильных устройств ни старались, пользователи имеют возможность получить на своём устройстве полные права администратора. Если в случае со средой Apple iOS можно говорить, что Apple активно борется с jailbreak, хотя и не всегда удачно, то многие китайские смартфоны с Android продаются уже рутованными.

Однако на уровне мобильного приложения можно реализовывать определение, работает ли оно на jailbreak/root-устройстве. Существует достаточно много как нативных методов (используемых в SDK различных вендоров), так и общедоступных алгоритмов проверки. В мобильных приложениях Сбербанка такие проверки давно реализованы и постоянно совершенствуются, это одна из основных мер их защиты. Однако нужно понимать, насколько эффективно эти методы могут распознать взлом устройства. К сожалению, стопроцентного способа проверки jailbreak/root не существует.

Угроза 3: перехват push-идентификатора и случайного числа в канале

Следующая угроза— кража с блокировкой отправки push-идентификатора и подписанного случайного числа при передаче изофициального мобильного приложения на сервер (рисунок 7).

Рисунок 7. Угроза перехвата и блокировки отправки push-идентификатора и случайного числа в канале

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

Здесь способом защиты может служить защищённое соединение с шифрованием (например, TLS). Однако нельзя полностью уповать только на шифрование канала. Злоумышленник также может украсть подписанное случайное число из канала связи, осуществив атаку Man-In-The-Middle, представившись нашим сервером. Для защиты от такого рода атаки недостаточно одностороннего TLS-соединения с проверкой сертификата сервера, ведь злоумышленник может выпустить себе легитимный сертификат (а из-за проблем с некоторыми удостоверяющими центрами ещё и с привязкой к доменному имени нашего сервера). Поэтому для защиты необходимо также использовать технологию прикрепления сертификата (certificate pinning), когда в код мобильного приложения внедряется TLS-сертификат сервера либо корневой сертификат, на котором он выпущен (в случае использования приватного корневого сертификата организации).

Угроза 4: кража идентификаторов мобильного приложения

Ещё один тип угрозы — это кража идентификаторов мобильного приложения, предназначенных для регистрации мобильного приложения в push-сервисе (рисунок 8).

Рисунок 8. Угроза кражи идентификаторов мобильного приложения

На основе этих идентификаторов и закрытого ключа мобильного устройства мобильное приложение регистрируется в push-сервисе и получает push-идентификатор.При помощи реверс-инжиниринга мобильного приложения злоумышленник может получить эти идентификаторы. Например, для платформы Android и push-сервиса Firebase идентификаторы, необходимые для регистрации при разработке, хранятся в файле google-services.json (файл скачивается с сервиса Firebase), а после сборки появляются в установочном APK-файле в ресурсах (resources.arsc) и в манифесте (AndroidManifest.xml). Если же разобрать файл ресурсов, то в каталоге values можно найти файл strings.xml, где и считать значения идентификаторов. Ниже приведена таблица соответствия названия идентификаторов в файле google-services.json, strings.xml и AndroidManifest.xml (таблица 1).

Таблица 1. Названия идентификаторов для платформы Android

Таким образом, злоумышленник может «выпустить» собственное мобильное приложение.Например, подобные приложения используют некоторые пользователи, которые купили китайский смартфон с root-доступом. Они пользуются форумом 4pda.ru для получения версии мобильного приложения Сбербанка с отключённой проверкой root-доступа[6]. Теоретически злоумышленник может таким образом модифицировать код официального мобильного приложения, так что оно всё равно будет получать push-уведомления.Другими словами, он сможет создать свой аутентификатор и этим закрытым ключом будет подписывать биометрические данные, но при этом, например, в нём будут отключены механизмы liveness detection.

Защита от реверс-инжиниринга мобильного приложения — крайне сложная задача, которая не может быть выполнена на 100%. В этом случае необходимо производить обфускацию кода или шифрование публикуемого в магазине приложения, а также заложить в мобильное приложение методы защиты от манипуляций со средой выполнения (runtime) при помощи отладчика. Для платформы Apple iOS шифрование производится автоматически средствами App Store с использованием DRM-технологии FairPlay, а для платформы Android имеет смысл воспользоваться обфускатором (например, бесплатным офускатором ProGuard, распространяющимся с Android Studio).

Угроза 5: кража закрытого ключа

Угроза связана с получением собственно аутентификатора (закрытого ключа) мобильного приложения. Злоумышленнику достаточно получить закрытый ключ и использовать его в дальнейшем для подтверждения биометрических данных со своего нелегитимного приложения, которое, например, всегда отправляет одну и ту же фотографию и не использует методы защиты типа liveness detection. Причём получить закрытый ключ он должен на своём мобильном устройстве с использованием официального мобильного приложения, а использовать потом может в любом приложении на любой платформе, в том числе немобильной (рисунок 9).

Рисунок 9. Угроза кражи закрытого ключа мобильного приложения

Получить закрытый ключ можно разными путями:например, при помощи резервной копии. При создании резервной копии iOS с использованием iTunes, если использовать защиту резервной копии при помощи пароля, то все данные, в том числе данные keychain, шифруются на этом ключе и могут быть легко расшифрованы злоумышленником (который сам и вводил пароль на резервную копию). Поэтому для защиты keychain от резервного копирования необходимо применять специальные атрибуты при его создании:

Аттрибут kSecAttrSynchronizable, отвечающий за возможность синхронизации keychain с другими устройствами, в том числе в рамках резервного копирования, необходимо установить в значение kCFBooleanFalse, то есть запретить синхронизацию.

Аттрибут kSecAttrAccessible, отвечающий за доступ в программе к keychain, необходимо установить в любое значение, оканчивающееся на:

ThisDeviceOnly (kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly, kSecAttrAccessibleAlwaysThisDeviceOnly).

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

Ещё один вариант — это атака, связанная с получением полных прав (jailbreak/root) на своём устройстве. А в старых версиях Android, например, данные в keychain сохранялись шифрованными на PIN-коде разблокировке устройства, а в случае его отсутствия — в открытом виде. О мерах защиты в этом случае мы говорили, когда разбирали угрозу 2.

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

Угроза 6:угроза кражи подписанного фото/видео и его переиспользование

Мы подошли к последнему шагу процесса — аутентификации пользователя (или подтверждения операции) при помощи биометрии. На нём возможен перехват подписанных биометрических признаков (выше были показаны возможности такого перехвата) и их повторного использования для аутентификации (рисунок 10).

Рисунок 10. Угроза кражи подписанного фото/видео и переиспользование

Возможности защиты от такого вида угроз показаны на рисунке 11.

Рисунок 11. Методы защиты от угрозы переиспользования

Во-первых, для того чтобы нельзя было перехватить подписанную фотографию, необходимо использовать шифрованный TLS-канал с проверкой сертификата сервера по прикреплённому сертификату, о чем мы говорили выше. Во-вторых, можно подписывать не просто фотографию, а некоторый пакет данных, включающий в себя дополнительную информацию о текущей аутентификации. Например, можно использовать алгоритмы генерации одноразовых паролей на основе счётчика (RFC 4226. HOTP: An HMAC-Based One-Time Password Algorithm) и/или времени (RFC 6238. TOTP: Time-Based One-Time Password Algorithm). Однако нужно не забывать, что клиентские и серверные значения счётчика и времени должны быть синхронизированы, что бывает затруднительно выполнить.

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

АНАЛИЗ РИСКОВ

Выше мы рассмотрели некоторые угрозы, применимые к предложенному методу аутентификации мобильного приложения с использованием открытого API. Теперь же необходимо понять, насколько они актуальны в преломлении тех атак, которые мы затронули в начале этой части статьи, —целенаправленной атаки и фишинга (таблица 2).

Таблица 2. Анализ рисков

Кража случайного числа на серверной части (угроза 1) позволяет зарегистрировать любое приложение сколько угодно раз, что даёт возможность использовать его как для целенаправленной атаки, так и в целях фишинга. Однако организационные меры и end-to-end защита канала с push-сервисом позволяют нивелировать эти риски.

Кража push-идентификатора и случайного числа на устройстве (угроза 2) и их перехват в канале (угроза 3), а также кража закрытого ключа (угроза 5) в связи с необходимостью использования оригинального приложения для целей фишинга достаточно затруднительны, если на сервере осуществлять контроль соответствия аутентификатора (открытого ключа) мобильного приложения и аутентифицированного при помощи биометрии пользователя. Поэтому злоумышленнику придётся каждый раз использовать новое мобильное устройство. В случае канала связи защититься от целенаправленной атаки можно соответствующими настройками TLS. В первом и третьем случаях технические меры не могут стать панацеей, и приходится констатировать, что угроза актуальна при целенаправленной атаке.

В случае кражи идентификаторов мобильного приложения (угроза 4) злоумышленник имеет возможность создать приложение-клон, которое может распространяться в случае Android просто установочным файлом. В официальном магазине опубликовать такое приложение не получится, так как его наименование будет совпадать с официальным. По этой же причине невозможно на одном устройстве установить официальное приложение и его клон.Уменьшить риск централизованного фишинга можно при помощи контроля соответствия аутентификатора мобильного приложения и пользователя. Злоумышленнику будет проблематично заставить пользователей установить нелегитимное приложение в массовом порядке. В случае же целенаправленной атаки любые предлагаемые меры неэффективны. Такие рода угрозы мы сможем отслеживать только стохастическими средствами, такими как антифрод.

С кражей и переиспользованием подписанных биометрических данных (угроза 6) легко бороться при помощи технических средств, таких как добавление номеров посылок и/или времени, а также идентификаторов документов в случае подтверждения.

Итак, актуальными угрозами можно считать:

• кражу push-идентификатора и случайного числа на устройстве и кражу закрытого ключа, которые ведут к возможности злоумышленником зарегистрировать собственное приложение, обладая доступом к официальному;
• кражу идентификаторов мобильного приложения, которое позволяет злоумышленнику создать собственное мобильное приложение и распространять его.

Очевидно, чтобы защититься от целенаправленных атак, реализуемых на основе актуальных угроз, необходимо использовать многофакторную аутентификацию, которая включает в себя не только аутентификацию по биометрическим признакам, но и основанную на знании (knowledge base). Например, в случае Сбербанк Онлайн регистрация мобильного приложения только при помощи биометрии — рискованное занятие. Другое дело —в уже зарегистрированном по стандартному процессу при помощи одноразового пароля, отправляемого в SMS-сообщении, мобильном приложении использовать дополнительную аутентификацию и подтверждение операций в случае подозрения на мошенничество.

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

ЗАКЛЮЧЕНИЕ

В статье освещена общая модель киберугроз для процесса биометрической аутентификации в целом, а также на примере лицевой модальности и мобильного канала. Были рассмотрены различные модели биометрического процесса, а также выделена характерная угроза для биометрического процесса в мобильном канале — подмена биометрического сканера (мобильного приложения) и/или биометрических данных, отсылаемых на сервер для целей аутентификации, а также метод защиты от этой угрозы.

В качестве метода защиты предложена схема создания аутентификатора (закрытого ключа) мобильного приложения и подтверждения им используемых биометрических данных. Метод создания аутентификатора предполагает использование нативной push-нотификации, предлагаемой мобильными операционными системами Apple iOS и Google Android, и применяет средства ассиметричной криптографии — шифрование и электронную подпись.Были рассмотрены возможные атаки на такую схему подтверждения и меры защиты от них.

К сожалению, предложенная схема аутентификации не может в полной мере противостоять целенаправленным атакам, однако является достаточно эффективным инструментом аутентификации мобильного приложения, использующего открытые интерфейсы взаимодействия с серверными приложениями. В сочетании с такими вероятностными инструментами, как адаптивная аутентификация и антифрод, а также методами двухфакторной аутентификации, основанной на знании (knowledge base), можно получить хорошую защиту биометрических процессов в мобильном приложении.