5 августа 2019 / время чтения: 4 мин. / всего просмотров: 1 102

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


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

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

Угроза 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, которая отслеживает все уведомления на устройстве. Естественно, для подключения к службе нужны соответствующие права доступа, которые нужно запросить с использованием файла манифеста, например, так:

Похожие статьи

Статья

«Антифрод 3.0»: банки просят баланса между контролем и гибкостью

Статья

Сертификат НУЦ для банковского сайта: что Минцифры оставило на усмотрение самого центра

Статья

«Замена Microsoft CA — это не так страшно, как может показаться»

Статья

Вадим Уваров: В работе антифрод-систем ИИ не возбраняется

  1. 05 Стандарт для ПО с искусственным интеллектом. Что банку спрашивать у поставщика уже сейчас
  2. 06 Стандарт безопасности ФАПИ.СЕК. Детали и главное
  3. 07 С лицевого счёта похищено… Судебные экспертизы в сфере ДБО и противодействие мошенничеству
  4. 08 Как защитить цифровой рубль? Участнику платформы ЦР необходимо реализовать ряд непростых и недешёвых решений
  5. 09 Преступление без наказания. Набросок комментариев к ст. 159 УК РФ
  6. 10 По следам преступлений. Кто и как должен помочь следствию?
ИИ-ассистент BISонлайн
Привет! Я помогу разобраться в материалах журнала. Хотите, перескажу текущую статью за 20 секунд?
Рекомендую прочитать
«Как построить SOC в 2026»