Для изучения предпродакшен-версии использовалась методика «чёрного ящика». Я получил «образец» французской ID-карты (carte d'identité), которая, естественно, не была связана с реальным гражданином. Однако я не получил PIN, поэтому не мог полностью изучить всю функциональность, реализованную в системе France Identité.
Ниже я расскажу о том, что обнаружил.
Введение
Достаточно часто при проектировании экономной, удобной для пользователя системы «чип-облако» используются коммуникационные возможности мобильного телефона пользователя. Благодаря этому, не нужно снабжать пользователей смарт-устройством (например, цифровой ID-картой) со всей электроникой и ПО, необходимыми для автономной передачи и получения данных из Интернета; вместо этого разрабатывается продукт, использующий коммуникационный стек близкого действия, например, Bluetooth/NFC (которые по умолчанию поддерживаются всеми современными мобильными телефонами). Приложение в телефоне создаёт канал связи с бэкендом, работая в качестве моста между двумя мирами.
Например, такую архитектуру можно обнаружить в системах для управления арендуемыми машинами (виртуальные ключи), электронной идентификации и всевозможных IoT-устройств, в частности, электронных бирок для багажа.
Основная задача заключается в описании уязвимых паттернов, выявленных в популярных криптографических операциях. Благодаря этому, и разработчики, и исследователи, имеющие дело с подобными решениями, смогут лучше их защищать.
Знакомство с France Identité
Как говорилось выше, методика анализа этой системы была исключительно «чёрным ящиком», поэтому я решил изучить приложение для Android.
Я выполнил статический реверс-инжиниринг приложения, чтобы понять, как было реализовано решение. Обнаруженные в результате уязвимости в основном были логическими ошибками. Также я воспользовался Frida для подключения к NFC (IsoDep), Transport и Cryptographic API.
Я составил следующую диаграмму с основными элементами решения.
Граждане Франции смогут использовать свои ID-карты без наличия поблизости физического терминала, который логически реализован в бэкенде. Для этого им достаточно будет мобильного телефона.
В такой архитектуре APDU инкапсулируются и передаются по защищённому каналу E2EE Secure Channel, который устанавливается между приложением и бэкендом. Этот E2EE Secure Channel приложения также защищает APDU, используемые для создания ещё одного защищённого канала, на этот раз PACE Secure Channel, основанного на чипе (в соответствии с описанием в MRTD).
Итак, у нас есть два разных защищённых канала:
а) Установленный между приложением и бэкендом (специализированный)
б) Установленный между чипом (Integrated Smart Card) и терминалом. Этот канал не входит в рамки исследования, так как Smart Card не включена в программу баг-баунти.
Наряду с этими защищёнными каналами, приложение поддерживает обычный канал HTTP-коммуникации с бэкендом по TLS.
В результате в решении были реализованы различные границы безопасности, поэтому я сосредоточился на способе их обхода. Я посчитал, что самыми реалистичными будут следующие векторы атаки:
▍ 1. MITM
Решение пытается устранить возможность этого распространённого сценария атаки реализацией E2EE Secure Channel.
▍ 2. Стороннее приложение
Обычно в таких решениях нежелательны сторонние приложения, не связанные с исходным продуктом, которые потенциально могут взаимодействовать с бэкендом зловредным образом. Для устранения возможности такого сценария приложение France Identité использует функциональность аттестации ключей, предоставляемую Android с версии 8.0 и выше (а также iOS), в основе которой лежит TEE.
Установка защищённого канала E2EE Secure Channel
На схеме ниже показан процесс установки защищённого канала. Мы можем выявить два основных этапа, на которых обнаружены самые интересные уязвимости:
1. Handshake
2. Потоки между приложением и различными конечными точками в бэкенде после установки защищённого канала E2EE Secure Channel.
Часть Handshake — это протокол согласования взаимно идентифицируемых ключей, основанный на схеме Диффи — Хеллмана на эллиптических кривых (эфемерном ECDH). Давайте посмотрим, как он реализован:
▍ 1. Инициализация Handshake защищённого канала
Приложение отправляет бэкенду запрос, содержащий три параметра:
а) scaSuiteIds — это список ID, сообщающий бэкенду о различных группах ранее согласованных криптографических алгоритмов, поддерживаемых приложением. В данном случае это только следующий ID (0):
SCA_ECDSA_ECDSA_ECDHP256_SHA256_AES256_GCM_IVCPT_HMAC(0, «SHA256withECDSA», «SHA256withECDSA», «secp256r1», «AES», 32, «AES/GCM/NoPadding», «HmacSHA256», «Hmac», 16)
б) challenge — это 32-байтный вызов, генерируемый приложением при помощи SecureRandom.
в) trustedCA — приложение передаёт бэкенду информацию о корневом сертификате CA (issuer, subject и serialnumber), который ожидает получить. Этот сертификат жёстко прописан в приложении.
▍ 2. Возврат материалов защищённого канала
Бэкенд отвечает на предыдущий запрос пятью параметрами:
а) scaSuiteId — ID криптографических алгоритмов, которые согласился использовать бэкенд (0)
б) challenge — 32-байтный случайный вызов, сгенерированный бэкендом
в) keyExchange — публичный ключ бэкенда, который будет использоваться в схеме ECDH.
г) Signature — сигнатура, сгенерированная бэкендом (SHA256withECDSA) для буфера, содержащего следующие конкатенированные байты
[ 00000000 ]
[ — ] keyExchange бэкенда
[ — ] Challenge приложения
[ — ] Challenge бэкенда
д) certificatesChain — это цепочка сертификатов, которую приложение может использовать для верификации полученных материалов, таким образом аутентифицируя бэкенд.
▍ 3. Завершённый Handshake ECDH
Приложение начинает валидировать полученную сигнатуру и соответствующую цепочку сертификатов. Если всё в порядке, приложение отправляет следующие материалы:
а) keyExchange — публичный ключ приложения, который будет использоваться в схеме ECDH.
б) signature — сигнатура, сгенерированная приложением (SHA256withECDSA) для буфера, содержащего следующие конкатенированные байты.
[ — ] keyExchange приложения
[ — ] keyExchange бэкенда
[ — ] Challenge бэкенда
в) attestation — сгенерированные приложением материалы аттестации на основе TEE, которые бэкенд будет использовать для аутентификации приложения.
▍ 4. Завершённый Handshake ECDH
Если бэкенд может верифицировать полученные от приложения материалы, то возвращает ID, идентифицирующий установленный защищённый канал. Этот ID приложение использует в специальном заголовке (asc-Id).
▍ 5. Формирование ключа AES-GCM/IV
После успешного завершения схемы ECDH её сгенерированный общий секрет используется для формирования ключа AES-GCM и исходного ключа IV.
По сути, буфер генерируется в следующем виде:
sharedSecret + "x00x00x00x01" + appChallenge + backendChalllenge + КОНСТАНТА,
где КОНСТАНТА — это или «conf key», или «init vector key», в зависимости от генерируемого криптографического ключа.
SHA256 получившегося буфера предоставляет соответствующий ключ.
IV генерируются вычислением HMAC(Counter), а затем выполнением XOR старших 16 байт с оставшимися.
Уязвимости
С моей точки зрения, наибольшую важность имеют две описанные ниже уязвимости.
▍ 1. Реализация защищённого канала уязвима к атаке AES-GCM IV Reuse
Реализация защищённого канала подвержена атаке AES-GCM IV reuse из-за погрешности в логике при обработке значений счётчика.
Как мы видели, E2EE Secure Channel использует схему AES-GCM, у которой Key и IV формируются из общего секрета (в дополнение к прочим материалам), сгенерированного после завершения протокола согласования ключей ECDH между приложением и бэкендом.
Сообщения защищённого канала имеют следующий формат:
Counter + '.' + Ciphertext, закодированный Base64
Counter используется для генерации IV при помощи выполнения HmacSHA256 32-битного значения счётчика с использованием исходного ключа IV и последующим XOR первых 16 байт результата с оставшимися 16 байтами.
Это значение счётчика инкрементируется приложением и бэкендом каждый раз, когда один из них получает и/или обрабатывает обёрнутое (зашифрованное) сообщение. Однако без строгого контроля потоков и контекстов, связанных со значением счётчика, эта логика имеет фундаментальный изъян. Это особо опасно, поскольку злоумышленник, выполняющий MITM, может управлять тем, когда каждая из сторон получит сообщение, таким образом имея возможность ждать или принудительно отправлять конкретные запросы.
В результате этого можно принудительно создать состояние, в котором два сообщения E2EE Secure Channel, поступающие и из приложения, и из бэкенда (как показано на диаграмме выше), будут зашифрованы одним IV (одинаковый счётчик), что, по сути, ломает модель обеспечения защиты AES-GCM, позволяя нападающему расшифровать ciphertext любого сообщения, зашифрованного при помощи одинакового IV.
Давайте рассмотрим практический пример такой атаки.
1. Защищённый канал инициализируется и завершается. Приложение и бэкенд формируют одинаковый ключ AES-GCM и исходный IV.
2. Приложение отправляет запрос initEnroll, в этот момент значение счётчика (CTR) равно 0, так как этот первый запрос. Однако мы не хотим выполнять атаку при первом запросе, так как он обычно не содержит ценных данных.
3. Бэкенд получает запрос initEnroll, обрабатывает его, увеличивает CTR и возвращает OK.
4. Приложение получает запрос GET к конечной точке transactions, поэтому бэкенд не получает обёрнутое сообщение в теле. CTR не увеличивается.
5. После генерации ответа OK бэкенд увеличивает CTR на 1, то есть теперь CTR равен 2.
6. Приложение получает от бэкенда обёрнутый ответ, содержащий значение CTR = 2, которое соответствует значению CTR, хранящемуся внутри приложения. Затем приложение увеличивает CTR до 3, генерирует и отправляет запрос Transaction Start.
7. Использующий MITM злоумышленник обнаруживает этот запрос Transaction Start, не позволяет ему достичь бэкенда, а затем выполняет запросы к конечной точке /ms-lot4/attestation-oidc/api/opidc/auth, включив заголовок ID защищённого канала asc-id, перехваченный у одного из предыдущих запросов (после завершения handshake). Добавив заголовок asc-id, он заставляет сервер вернуть «обёрнутый» ответ (зашифрованный). Стоит отметить, что эта атака не ограничена указанными конечными точками, могут использоваться и другие.
Этот запрос возвращает зашифрованный ответ от бэкенда, который увеличил значение CTR до 3, чтобы сгенерировать зашифрованный ответ для приложения. У злоумышленника с MITM теперь есть два сообщения, зашифрованные с использованием одного IV ( CTR == 3 ).
Конечная точка /ms-lot4/attestation-oidc/api/opidc/auth используется для генерации запроса повторного использования CTR, ведь нападающий уже знает незашифрованный текст, возвращённый в зашифрованном ответе (меняются только поля nonce и state), потому что это то же содержимое, что и возвращённое конечной точкой /attestation-oidc/api/opidc/auth.
Поэтому для этой конечной точки тоже возможен сценарий с выбранным незашифрованным текстом, а расшифровка сообщений произвольной длины выполняется автоматически при помощи XOR выбранного незашифрованного текста, его ciphertext и целевого сообщения защищённого канала.
В качестве защищённой альтернативы для таких ситуаций можно использовать AES-GCM-SIV.
▍ 2. Во время Handshake защищённого канала бэкенд не верифицирует поля ApplicationID
Все уязвимые данные, передаваемые между приложением и бэкендом, зашифрованы схемой AES-GCM, ключ и исходный IV которой формируются из различных материалов, полученных во время протокола согласования ключей на основе ECDH.
Перед формированием ключа этот защищённый канал требует handshake, при котором для безопасной реализации фазы формирования ключа на основе ECDH требуются криптографические материалы, передаваемые между приложением и бэкендом.
Во время этого handshake бэкенд ожидает получить сертификат (цепочку), который генерируется при помощи Attestation API с аппаратной поддержкой (TEE), привязанного к запросу Attestation, ранее отправленному бэкендом. Однако бэкенд не валидирует поля сертификата, относящиеся к ApplicationId, чтобы гарантировать, что только официальное приложение FranceIdentité способно установить защищённый канал E2EE Secure Channel.
Остальные криптографические этапы, необходимые для формирования AES GCM Key/IV для установки E2EE Secure Channel, не требовали никакой дальнейшей валидации со стороны бэкенда, поэтому произвольное стороннее приложение могло потреблять Backend API FranceIdentité по защищённому каналу точно так же, как оригинальное приложение FranceIdentité.
Для проверки этого сценария я создал клонированное приложение с модифицированным appId (fr.gouv.franceidentitee.preprod, с двойной e).
Несмотря на это, бэкенд принял материалы аттестации, что позволило выполнить handshake.
В контексте FranceIdentité, системы идентификации, рассчитанной на целую страну, эта проблема может открыть возможность для реализации множества сценариев, способных упростить мошенничество, подмену пользователей и кражу личности.
▍ 3. Несогласованная логика верификации сигнатур между бэкендом и приложением во время handshake
Во время handshake E2EE Secure Channel бэкенд и приложение выполняют обмен криптографическими материалами, необходимыми для выполнения протокола согласования ключей ECDH.
Однако в логике верификации этих значений есть несогласованность: и бэкенд, и приложение некорректно валидируют длину потреблённых криптографических материалов. Эти длины чётко определены, поэтому должны верифицироваться корректно.
Во время handshake бэкенд и приложение передают свои сгенерированные сигнатуры буферу, который изначально содержит массивы конкатенированных байтов:
— Криптографические материалы от бэкенда к приложению
[ 00000000 ]
[ — ] keyExchange бэкенда
[ — ] clientChallenge
[ — ] serverChallenge
И приложение, и бэкенд просто конкатенируют эти поля и подписывают получившийся буфер. Это тоже является проблемой, так как потенциально ослабляет аутентификацию, поскольку отсутствует разделение предметных областей.
Злоумышленник может воспользоваться этим для выполнения некоторых криптографических атак, сильно зависящих от внутренней логики. Давайте рассмотрим практически безвредный пример, в котором предполагается, что злоумышленник способен выполнить MITM во время handshake E2EE Secure Challenge.
1. Злоумышленник систематично удаляет первый байт clientChallenge (Challenge приложения) из запроса приложения.
2. При получении ответа от бэкенда злоумышленник с MITM проверяет, равен ли последний байт публичного ключа бэкенда первому байту, который был удалён в clientChallenge. Если это так, он также модифицирует ответ keyExchange бэкенда, уменьшая его размер удалением последнего байта.
3. Логика приложения конкатенирует буферы, оставляя неизменным исходное значение clientChallenge (32 локально генерируемых байта). Так как последний байт keyExchange бэкенда и первый байт исходного clientChallenge равны, полученная от сервера сигнатура остаётся валидной, но приложение будет использовать модифицированное значение keyExchange (обрезанное злоумышленником с MITM до 90 байт), отличающееся от исходного значения keyExchange, подписанного бэкендом.
С точки зрения приложения сигнатура по-прежнему валидна, но значение keyExchange отличается (оно на один байт меньше). Конкретно в этом случае данная проблема не окажет реального влияния, так как реализация java EC отбрасывает неправильно сформированный ключ.
Однако этот уязвимый паттерн в других условиях может обеспечить возможность серьёзных криптографических атак.
▍ 4. Бэкенд не валидирует согласованность между полями ID и SSC в модели запроса/ответа
Приложение получает от «терминала» (бэкенда) список «команд» (APDU), который должен быть передан смарт-карте.
{«SessionID»:«d7bcb1d3-d8b4-3172-aea1-a48a36726fef»,«Commands»:[{«apdu»:«AKQADA==»,«ssc»:-1,«Id»:«SELECT_MF»,«Type»:-1,«APDU»:«AKQADA==»,«SSC»:-1},{«apdu»:«AKQCDAIBHA==»,«ssc»:-1,«Id»:«SELECT_EF_CARD_ACCESS»,«Type»:-1,«APDU»:«AKQCDAIBHA==»,«SSC»:-1},{«apdu»:«ALAAAMg=»,«ssc»:-1,«Id»:«READ_EF_CARD_ACCESS»,«Type»:-1,«APDU»:«ALAAAMg=»,«SSC»:-1},{«apdu»:«AKQCDAIvAQ==»,«ssc»:-1,«Id»:«SELECT_ATR»,«Type»:-1,«APDU»:«AKQCDAIvAQ==»,«SSC»:-1},{«apdu»:«ALAAAP8=»,«ssc»:-1,«Id»:«READ_ATR»,«Type»:-1,«APDU»:«ALAAAP8=»,«SSC»:-1}]}
Каждый APDU содержит разные поля, но мы рассмотрим всего два:
1. Id, определяющее операцию, а также задающее порядок.
2. SSC (Send Sequence Counter), передающее индекс для поддержки пакетной обработки защищённых APDU (после того, как между терминалом и смарт-картой установлен «безопасный обмен сообщениями» PACE), реализуемой приложением. Бэкенду также нужно отслеживать это значение, чтобы иметь возможность расшифровки ответов.
Приложение отправляет эти APDU смарт-карте и собирает ответы, которые затем передаются «терминалу» (бэкенду) в том же формате с кодировкой json, чтоб был использовал в запросе, но на этот раз он содержит ответы, полученные от смарт-карты.
{«SessionID»:«d7bcb1d3-d8b4-3172-aea1-a48a36726fef»,«Responses»:{«SELECT_MF»:{«SW»:26368,«Data»:«ZwA=»,«SSC»:-1},«APDULENGTH»:{«SW»:0,«Data»:«65279»,«SSC»:0},«SELECT_EF_CARD_ACCESS»:{«SW»:36864,«Data»:«kAA=»,«SSC»:-1},«READ_EF_CARD_ACCESS»:{«SW»:25218,«Data»:«MSgwEg...g==»,«SSC»:-1},«SELECT_ATR»:{«SW»:36864,«Data»:«kAA=»,«SSC»:-1},«READ_ATR»:{«SW»:25218,«Data»:«YQx...==»,«SSC»:-1}}}
Эти запросы/ответы проходят по защищённому каналу между приложением и бэкендом, поэтому нападающему необходимо получить возможность контролировать данные, передаваемые по этому защищённому каналу (при помощи MITM или уязвимостей, позволяющих выдавать себя за другого пользователя).
Уязвимость находится в бэкенде, который не валидирует согласованность полей ID и SSC между запросом и ответом. В результате этого нападающий может менять Id операций, сохраняя при этом SSC, таким образом, заставляя терминал расшифровывать и обрабатывать блоки данных, не соответствующие ожидаемой операции.
Давайте посмотрим, как это работает:
1. Терминал отправляет команды APDU, которые приложение должно передавать eID (смарт-карте).
2. Приложение декодирует эти APDU и отправляет их eID
3. Приложение собирает ответы от eID
4. Перед отправкой закодированных в json ответов нападающий заменяет Id нужных операций, но сохраняя их SSC.
5. Терминал получает неправильную модель ответа.
Для демонстрации этой проблемы я создал при помощи Frida proof of concept, заменяющий отдельные Id. В этом примере второй блок Digital Signature (SOD) становится одним из собранных DG ответов.
Это вызывает ошибку в бэкенде, которая в неотфильтрованном виде возвращается приложению, таким образом, раскрывая информацию о внутреннем устройстве терминала (JMRTD, Bouncy Castle...). Кроме того, эта ошибка раскрывает, и косвенно (по ошибкам парсинга), и явно определённые расшифрованные байты из зашифрованных блоков данных DG.
Дополнение: после моей публикации я был на связи с France Identité CISO, и эта организация предоставила мне информацию о предпринятых ею мерах в свете моих исследований
Мы бы хотели поблагодарить вас за вашу подробную исследовательскую работу над приложением France Identite, которая была запущена год назад в состоянии бета-версии и за которую вам выплатили вознаграждение. Как вы знаете, это приложение уже доступно для iOS и Android в соответствующих магазинах приложений.
Ваша работа, наряду с исследованиями агентства кибербезопасности Франции (ANSSI), позволила нам глубоко модифицировать E2EE Secure Channel, используемый между приложением и бэкендом. Теперь он по большей мере основан на TLS1.3. Эти модификации были выпущены лишь спустя несколько недель после отправки вашей работы в нашу закрытую программу баг-баунти в YesWeHack. В выпущенной версии также устранены три другие уязвимости, отправленные вами.
Ещё в самом начале программы France Identite было решено задействовать в ней сообщество исследователей кибербезопасности запуском закрытой программы баг-баунти. Мы с удовольствием сообщаем, что программа баг-баунти скоро станет доступна публично, а исходный код будет опубликован в начале 2024 года..
Автор:
ru_vds
