Заблокированный BCU Key в KNX: способы восстановления устройств без отправки производителю

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

KNXlock: как защита стала причиной отказа

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

В 2021 году прошла волна атак на системы умного дома KNX. Неизвестные злоумышленники получали доступ к системам автоматизации и устанавливали BCU Key на большое количество устройств. Выбирались крупные объекты.

Злоумышленники сначала удаляли конфигурации устройств, а затем устанавливали BCU Key. В результате устройства лишались не только прежней конфигурации, но и возможности штатно загрузить её заново без неизвестного ключа. Оборудование переставало нормально работать, а для восстановления необходимо было отправлять устройства производителю, что требовало значительных затрат.

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

Сейчас злоумышленники усилили блокировку. У нас на объекте был установлен уникальный BCU Key на каждое устройство. Ниже — разбор механизма BCU Key, известных способов восстановления и наш собственный опыт восстановления устройств разных производителей.

Как работает BCU Key

BCU Key — механизм ограничения доступа к программированию поддерживающих его KNX-устройств. В ETS ключ задаётся в проекте и применяется к устройствам при загрузке конфигурации.

Ключ представляет собой значение длиной до четырёх байт, то есть до восьми шестнадцатеричных символов. Если устройство защищено BCU Key, для доступа к соответствующим функциям программирования требуется правильный ключ.

У механизма нет штатного сброса ключа пользователем: единственный предусмотренный путь — обращение к производителю.

Это означает, что BCU Key защищает конфигурацию, но одновременно создаёт зависимость от сохранности самого ключа. Если ключ неизвестен, а производитель не предоставляет подходящего способа сброса, восстановление устройства становится отдельной технической задачей.

Документация KNX Association предупреждает об этом ограничении: потерянный BCU Key может потребовать возврата устройства производителю. KNX Association — BCU Key.

CVE-2023-4346: уязвимость, связанная с блокировкой устройств

В августе 2023 года была опубликована CVE-2023-4346, связанная с KNX Connection Authorization Option 1.

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

• CVE: CVE-2023-4346.

• CVSS 3.1: 7,5 — High.

• Основной риск: блокировка поддерживающих соответствующий механизм устройств и невозможность штатно восстановить доступ без текущего ключа.

Это не значит, что все устройства KNX уязвимы одинаково. Последствия зависят от реализации Connection Authorization Option 1 и конкретных механизмов защиты устройства.

Насколько велика поверхность атаки?

Проблема KNX не ограничивается BCU Key. Важную роль играет доступность интерфейсов автоматизации из сетей, которым они не должны быть доступны.

По результатам поиска с помощью Shodan: более 12 000 устройств BACnet/IP и около 130 устройств KNXnet/IP были доступны непосредственно через интернет.

Само по себе обнаружение интерфейса не равно успешной атаке. Но открытый сетевой доступ и недостаточная защита конфигурации могут в совокупности создать серьёзный риск.

Когда перебор ключа работает, а когда нет

На первый взгляд четырёхбайтовый ключ выглядит достаточно коротким. Но его пространство содержит 2^32, или 4 294 967 296, возможных значений.

Для проверки каждого кандидата необходимо взаимодействовать с устройством по KNX. Скорость такого взаимодействия ограничивает производительность намного сильнее, чем вычислительная мощность компьютера.

В открытом проекте knxunlocker автор указывает скорость порядка 9–11 проверок в секунду и оценивает полный перебор примерно в 13 лет при скорости около 10 проверок в секунду.

Это оценка для конкретного подхода и условий работы, а не универсальная характеристика каждого KNX-устройства. Но она хорошо показывает главное: даже небольшой ключ может оказаться практически невосстановимым простым перебором, если проверка каждого кандидата требует медленного обмена с устройством.

В проекте описаны три класса проверок:

• проверка известных стандартных значений;

• проверка списка возможных ключей;

• полный перебор пространства ключей.

В некоторых случаях злоумышленники сами раскрывали часть ключа, оставляя на устройстве сообщение, например: „System hacked. BCU Key: xx1234xx“. Если часть ключа известна, число кандидатов может значительно уменьшиться. Например, если известны два байта из четырёх, остаётся 2^16 = 65 536 вариантов. Это уже совершенно другой масштаб поиска.

Есть важная оговорка. Оценка в 13 лет верна для одного устройства с одним уникальным ключом, который проверяют через единственное подключение к шине. Но если один и тот же BCU Key стоит сразу на множестве устройств, перебор можно распараллелить, и тогда картина меняется принципиально.

Именно так произошло в одном из задокументированных случаев. На объекте с более чем 300 KNX-устройств был установлен единый пароль на все устройства сразу. Один из участников немецкого KNX-форума описал, как он собрал около 23 плат Arduino Mega2560 и подключил их к устройствам через более быстрый внутренний UART-интерфейс кнопочных панелей Gira (115200 бод вместо стандартных 9600 бод самой шины KNX). Пространство ключа (2^32 вариантов) он разделил на 8192 блока и раздал их платам в случайном порядке. В итоге ключ был найден примерно за 15 дней, хотя было проверено только около 37% всего пространства.

Но при этом пароль должен быть одинаковым на всех устройствах, и устройств должно быть действительно много, иначе выигрыш по времени почти не ощущается. Если на каждом устройстве стоит свой уникальный ключ, как было в нашем случае с 570 устройствами, подбор ключа одного устройства никак не приближает к ключам остальных, и перебор снова упирается в те же годы на каждое устройство по отдельности. При этом KNXunlocker не выполняет дамп памяти микроконтроллера: это программный инструмент, проверяющий кандидаты через KNX-интерфейс. Чтение памяти — отдельный аппаратный метод.

Восстановление через память

Именно этот этап делает историю KNXlock особенно интересной с технической точки зрения. По опубликованному описанию Limes Security, исследователи получили несколько пострадавших устройств. Полный перебор был быстро отвергнут из-за низкой скорости ответа устройств. Затем исследователи попробовали считать память непосредственно с процессоров. Это сработало на некоторых устройствах, где не была включена защита чтения памяти, но не на всех.

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

Такой подход позволил восстановить ключ на части исследованных устройств и вернуть доступ к системе автоматизации.

Защита чтения микроконтроллера может полностью изменить доступные варианты восстановления. Например, у некоторых микроконтроллеров STM32 есть механизм Readout Protection (RDP), ограничивающий чтение внутренней памяти.

Наш опыт: 570 устройств и несколько путей восстановления

Теория становится понятнее на практике, поэтому расскажу о собственном случае, похожем на KNXlock. Так как BCU Key — средство защиты, подробную инструкцию по восстановлению я давать не буду: это вопрос безопасности. Расскажу о своём опыте в общих чертах.

На объекте, с которым мы работали, было 570 устройств от разных производителей, в основном европейских: MDT, итальянский Electron, Schneider, Jung, Zennio, Intesis, Gira, а также российский производитель Module. После отправки нескольких устройств производителю стало понятно, что на каждом устройстве стоял уникальный BCU Key, так что подобрать один ключ для всей системы было нельзя. Совпадающие ключи на разных устройствах иногда встречались, но это было скорее исключением, чем правилом.

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

В процессе выяснилось несколько интересных деталей, которые выходят за рамки исследования Limes Security.

Не всем устройствам нужно сложное восстановление. У части оборудования, например у некоторых устройств Intesis и Module, BCU Key формально запрашивается при программировании, но при выборе «продолжить без ключа» устройство всё равно принимает новую конфигурацию. Другими словами, защита на таких устройствах не работает так, как задумывалась: проблема решается не перебором и не дампом памяти, а просто корректным поведением в интерфейсе ETS.

Часть устройств поддаётся восстановлению прямо через шину. Помимо анализа памяти, нам удалось найти способ восстановления отдельных моделей непосредственно через шину KNX, без физического вскрытия устройства и подключения программатора к чипу. Метод не универсален и работает не на всех платформах, но там, где работает, он значительно быстрее и проще, чем снятие и анализ дампа памяти.

В итоге ключи удалось восстановить на устройствах нескольких производителей, среди них MDT, Electron, Schneider, Jung, Zennio, Intesis и Gira. Результат по каждой модели зависел от её аппаратной платформы и настроек защиты чтения памяти: где-то метод сработал сразу, где-то потребовал больше времени, а на части устройств не сработал вовсе.

Согласно документации KNX Association, производитель должен иметь путь для восстановления своих устройств. Похоже, нам удалось найти такие пути.

Как не попасть в такую же историю

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