louisabricot/writeup-cve-2019-19194Разбор и теоретическая Proof-of-Concept для CVE-2019-19194
Это разбор и теоретическое доказательство концепции уязвимости CVE-2019-19194.
⚠️ Эта CVE была найдена https://asset-group.github.io/disclosures/sweyntooth/
В этом отчете описывается, как уязвимость Zero LTK Initialisation (CVE-2019-19194) позволяет атакующему получить полный контроль над связью в приложении Bluetooth Low Energy (BLE), обходя процедуру сопряжения Secure Connections.
Эта уязвимость затрагивает продукты, использующие реализации SMP от Telink, которые поддерживают процедуру сопряжения Secure Connections.
BLE — это малопотребляющая система радиосвязи малого радиуса действия. Она состоит из набора стандартизированных протоколов, которые обеспечивают удаленное соединение и безопасность между двумя устройствами.
Стек BLE распределен по двум архитектурным блокам: Host и Controller.
Такое распределение позволяет реализовать каждый блок в физически отдельных компонентах.
Стандартный логический интерфейс, называемый Host Controller Interface (HCI), обеспечивает связь между двумя блоками.
Поверх блока Host находится приложение BLE.
Физический уровень работает в промышленном, научном и медицинском (ISM) радиодиапазоне, в спектре 2,4 ГГц. Он использует 40 каналов: 3 рекламных канала и 37 каналов данных.
Канальный уровень (LL) имеет множество обязанностей, которые не будут описаны здесь. Он управляется конечным автоматом, который определяет важные роли и состояния:
Протокол управления логическим каналом и адаптации действует как уровень мультиплексирования протоколов. Он обрабатывает фрагментацию и объединение пакетов между нижележащими и вышележащими уровнями.
Общий профиль доступа касается обнаружения и подключения устройств. Другими словами, GAP определяет процедуры передачи рекламных пакетов и их приема через сканирование.
После установления соединения между двумя устройствами BLE, GATT использует модель клиент/сервер для обмена данными между ними. И клиент, и сервер используют протокол атрибутов (ATT).
SM поддерживает процедуры, связанные с безопасностью, такие как сопряжение, связывание и распределение ключей. Сопряжение устройств считается основой безопасности Bluetooth: после сопряжения два устройства могут шифровать свое общение, аутентифицировать друг друга и т.д.
Среди различных протоколов, участвующих в связи BLE, уязвимость zero LTK installation происходит во время процедуры сопряжения в режиме Secure Connections.
Режим сопряжения Secure Connections является «более безопасным подходом» и был разработан для устранения слабостей режима Legacy. Однако уязвимость zero LTK installation показала, что плохие реализации сопряжения SC позволяют обойти защиту.
Центральное устройство отправляет запрос на сопряжение, и оба устройства обмениваются информацией о своих возможностях и требованиях безопасности. Эта фаза определяет режим сопряжения.
Обмен открытыми ключами: Центральное устройство инициирует обмен открытыми ключами. Периферийное и центральное устройства проверяют, что полученный ключ находится на кривой P-256.
Вычисление DHKey: Каждое устройство использует свой собственный закрытый ключ (SK) и открытый ключ другого устройства (PK) для вычисления своего ключа Диффи-Хеллмана (DHKey). Таким образом, оба устройства владеют одним и тем же значением DHKey.
Central: DHKey = p256(SKc, PKp)
Peripheral: DHKey = p256(SKp, PKc)
Если была запрошена защита от MITM, выполняется интерактивная процедура для подтверждения подлинности сопрягаемых устройств.
Вычисление долгосрочного ключа (LTK) и взаимное подтверждение: Устройства аутентифицируют друг друга и вычисляют ключ LTK. Из LTK выводится сеансовый ключ для шифрования канала перед Фазой 3.
Через зашифрованный канал устройства могут распределять ключи.
Основная причина zero LTK installation заключается в том, что не проверяется состояние, в котором находятся два устройства в процессе сопряжения. Таким образом, атакующее центральное устройство может пропустить этап генерации ключей и аутентификации. В результате на периферийном устройстве ключ LTK устанавливается в 0, и, следовательно, сеансовый ключ легко выводится.
⚠️ Это полностью теоретическое доказательство концепции, так как мне не удалось получить pcap-файл процедур обнаружения, рекламы или сопряжения BLE, и у меня не было устройства BLE с реализацией SMP от Telink.