Автор Тема: Обсуждение взломов KNX инсталляций, последствий и методов защиты  (Прочитано 529 раз)

Оффлайн Mycraft

  • Специалист KNX
  • ***
  • Репутация: +16/-0
  • Пол: Мужской
  • Умный дом на KNX
Во второй половине 2021 года участились случаи несанкционированных подключений к KNX инсталляция и выгрузки аппликационных программ из устройств, с последующей установки ключа BCU.
После выгрузки аппликации и установки на устройство BCU Key, KNX устройство становится "кирпичем", и не возможно его реанимировать штатными методами, загрузив из имеющегося ETS проекта, если известен BCU Key. Исправить ситуацию возможно силами производителя, но по большинству брендов придётся устройства отправлять на завод и, как показывает практика, далеко не все производители могут помочь в данной ситуации.

Взломы можно разделить на три большие категории. Это взломы с целью получить выгоду. И при этом практика показывает, что реальной защиты технической нет, так как здесь применяются методы социальной инженерии, подкупа сотрудников организации и сотрудников спецслужб и т.п. Защита от таких взломов - система безопасности в виде непрерывного процесса, и техническая безопасность при этом только одна из составляющих, и наверное, - не самая важная.
Второй - это взлом ради тренировки или технического интереса специалистами по технической безопасности. Большого ущерба и вреда при этом обычно не наносится.
И третий - это взлом подростками и хакерами, который делается ради самоутверждения, тренировки и иногда желания заработать шантажом. 90% атак делается не особо квалифицированными спецами с помощью софта и методик, найденных в интернете или в даркнете. Третий вариант самый массовый, и от него можно реально защититься, соблюдая небольшой набор не сложных правил.
Самый простой способ не решить задачу — это усложнить её условие. Обеспечение безопасности — это многоуровневый и непрерывный процесс. Но если выполнить простой первый порог процедур, доступных по уровню бюджета и квалификации большинству инсталляторов, то это в разы снизит вероятность взлома третьего типа.

Оффлайн knxtrade

  • Специалист KNX
  • ***
  • Репутация: +5/-0
  • Пол: Мужской
  • Мне нравиться KNX
    • KNX·TRADE
  • Сертификат KNX: (подтверждение)
Во второй половине 2021 года участились случаи несанкционированных подключений к KNX инсталляция и выгрузки аппликационных программ из устройств, с последующей установки ключа BCU.
После выгрузки аппликации и установки на устройство BCU Key, KNX устройство становится "кирпичОм"...

Очень важная тема сегодня. У некоторых наших коллег по цеху такое произошло.

Первоначально, чтобы это не случилось достаточно установить BCU Key (Password) через ETS.
На все устройства проекта ставится один и всё закрыто от шалостей.
Только запишите устанавливаемый пароль (ну хоть карандашиком на заднюю сторону устройства, например IP-интерфейса, а то сами себя закроете)))

И напомню, хулиганы делают вход через стандартный IP-порт 3671.

Оффлайн Mycraft

  • Специалист KNX
  • ***
  • Репутация: +16/-0
  • Пол: Мужской
  • Умный дом на KNX
Немецкий подход к проблемме...

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


Оффлайн Mycraft

  • Специалист KNX
  • ***
  • Репутация: +16/-0
  • Пол: Мужской
  • Умный дом на KNX
И румынский подход:

Я хочу поделиться своим (полностью дилетантским) взглядом на эту проблему; У меня
есть друг, который знает кого-то, кто столкнулся с точно такой же проблемой, описанной
в этой теме: где-то в конце декабря злоумышленник получил доступ к системе и
заблокировал все устройства с помощью пароля BCU, и было невозможно вернуть
контроль над система.

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

Потратив несколько дней на разборку (кнопки Gira 5133/5131/5142, 8- и 16-канальные
актуаторы Gira и даже метеостанцию Gira), стало ясно, что в данном случае метод,
который использовал Лаймс, неприменим, так как у меня были только Устройства Gira, и
хотя все они питаются от микроконтроллеров Atmel (с которыми я хорошо знаком и с
которыми мне удобно щупать и тыкать), все устройства имеют установленные замки-
предохранители, поэтому нет возможности получить доступ к областям flash/eeprom и
получить более ограниченное пространство для атаки грубой силы.
Действительно, попытка перебора всего 32-битного пространства кажется на первый
взгляд невозможной, и на это уйдет несколько лет на одном устройстве при низкой
скорости 9600 бит/с шины KNX. Но наличие десятков или сотен устройств с (как
предполагается!) одним и тем же паролем дает проблеск надежды, тем более, если
можно найти какой-то способ хотя бы немного ускорить процесс.

При исследовании содержимого flash/eeprom стало очевидно, что кнопки могут помочь,
когда дело доходит до скорости атаки: кнопки (потерпите меня, я ничего не знал о
системе knx в то время) не напрямую подключен к шине, но используйте шинный
соединитель 3, и связь здесь фактически использует UART 115200 бит/с: в шинном
соединителе 3 есть микроконтроллер, который обменивается данными с шиной KNX на
ограниченной скорости 9600 бод и с самими кнопками на гораздо более высокой
скорости. Скорость 115200 бод. Более того, микроконтроллер в шинном соединителе
действует только как шлюз, а фактический пароль находится на кнопках
микроконтроллера. Проверка этой шины 115200 (это легко сделать с помощью любого
логического анализатора или, в моем случае, с помощью осциллографа Rygol) показала,
что используемый протокол похож на knx;

Итак, в этот момент я как бы решил, что параллельная отправка нескольких запросов на
аутентификацию на несколько устройств по этой более быстрой шине может помочь.
Следующим шагом будет выбор хоста (или хостов), которые будут использоваться для
форматирования и отправки пакетов на устройства. Первая идея (как обычно, та,
которая не работает) заключалась в том, чтобы использовать кучу недорогих плат
разработчика esp32, поскольку они имеют 2 (может быть, даже 3, если я смогу обойти
журнал загрузчика на UART0) аппаратных UART (на 115200 скорость передачи данных,
я правильно предположил, что можно использовать только аппаратные UART). Кроме
того, Wi-Fi можно использовать для организации атаки более высокого уровня.
Я уже знал, что, несмотря на скорость 115200 бод, у шины есть некоторые требования к
времени: хост не может отправлять как можно быстрее, и устройство будет задерживать
довольно много времени, прежде чем ответить, поэтому, возможно, некоторое
мультиплексирование может быть сделано программно (некоторое аппаратное
обеспечение). соображения должны быть приняты во внимание при подключении
большего количества устройств к UART, но, в конце концов, я так и не зашел так далеко
с этой идеей), чтобы соединить два устройства через порт UART esp32.Для этого
потребуется около 10 esps для подключения 60 устройств (10 esp x 3 UART x 2
устройства)... и при скорости 30 попыток в секунду (ага, на тот момент это было
желаемое за действительное) общее время на полное 32 битное пространство будет не
более 30 дней; хотя это и не очень хорошо, такое количество времени кажется чем-то,
что могло бы сработать, не так ли?

К сожалению, это не сработало, потому что, когда я исследовал шину со скоростью
115200 бод, я полностью упустил тот факт, что шина на самом деле использовала
формат последовательного кадра 9E1, что, как я полагаю, является просто причудой
реализации Atmel, поскольку это совсем не так. стандартный формат кадра (9N1 - это
ближайший стандарт, который я смог найти, который, возможно, использовался когда-то
в далеком прошлом на устройствах, отличных от Atmel, через странное соотношение
пробела / метки, которое, в свою очередь, на самом деле не является стандартным). В
любом случае, этот формат определенно не поддерживается аппаратными UART esp32.
После еще нескольких дней возни с некоторыми библиотеками SoftwareSerial для esp32,
которые поддерживали требуемый формат кадра, это определенно был тупик (именно
этого можно было бы ожидать от нескольких последовательных программ, работающих
на одном микроконтроллере).
Что требовалось, какой хост на базе Atmel для форматирования, отправки и получения
фреймов; Arduino Mega2560 (я обещал вам любительские решения, не так ли?) имеет 4
хороших аппаратных UART, которые только и ждут, чтобы их использовали.
Профессиональный подход состоял бы в том, чтобы, возможно, использовать одну (или,
может быть, больше) FPGA для реализации более 4 UART на хост, но у меня не было ни
одного из них, поэтому это был Arduino (в итоге у меня было 23!! Arduino, работающие
вместе ... Я позаимствовал каждый Arduino, который я смог найти у всех своих друзей, а
затем также купил довольно много из них ... к счастью, если вы покупаете небрендовые -
да здравствует открытое оборудование! - они довольно дешевы в ~ 10 евро здесь, в
Румынии).

Установка, которая в конечном итоге заработала, заключалась в подключении 3
устройств к 3 портам UART Arduino (я также отказался от мусора с
мультиплексированием), при этом четвертый UART был подключен к esp32 для
оркестровки. Этот 4-й порт мог быть программным последовательным портом, так как я
решил, что 9600 бит/с достаточно, чтобы просто получать задачи и сообщать о статусе,
но я точно знал, что программные последовательные порты искажают временные
прерывания в Arduino, и я был уже более чем сыт по горло. с программной реализацией,
поэтому я решил просто использовать для этой цели один из аппаратных. В esp32 я
использовал серийные номера, реализованные программно, так как у меня не было
требований по времени (но в итоге я использовал контрольные суммы для кадров
задачи/состояния, потому что это было несколько ненадежно, но недостаточно, чтобы
быть проблемой), потому что я хотел подключить четыре Arduino к одному esp32 (я мог
бы подключить больше, но у меня уже был лишний esp). В итоге я также напечатал на
3D-принтере небольшие стойки для хранения устройств и их Arduino вместе; даже в
этом случае с проводкой полный бардак... Эта настройка дала мне ~ 18 попыток в
секунду на устройство (некоторые устройства - 5133/5131 были на самом деле быстрее
~ 19+ попыток в секунду, а некоторые были медленнее - 5142 отвечали достаточно
быстро только для 8-9 попыток в секунду) ; Думаю, микроконтроллер был больше
загружен управлением маленьким дисплеем, и поэтому его ответы задерживались
больше).

Имея теперь 6 esp32, каждая из которых имеет 4 стойки (у шестой оказалось только три,
потому что я получал убывающую отдачу от более медленных 5142, которые у меня
были в наличии), каждая стойка имеет, в свою очередь, один Arduino и 3 устройства, я
разделил весь 32-битный домен. в 8192 "фрагментах" по 524288 ключей каждый (2^13
фрагментов x 2^19 ключей для удобства управления). Затем каждому устройству будет
назначен один случайный (в конечном итоге это очень помогло!) фрагмент, и он будет
пробовать каждый ключ в фрагменте (один фрагмент — это число от 0 до 8191:
сдвиньте число на 19 бит влево и начните увеличивать 2 ^ 19 раз; потом повторять, и
повторять, и повторять... довольно простая задача для реализации в Arduino, после
того, как я разобрался, какие кадры отправлять на устройство и как парсить ответы).
Затем esp32 будут пересылать данные в Arduino и обратно в php-скрипт с небольшой
базой данных sqlite, чтобы отслеживать прогресс. С такой настройкой один 5133/5131
закончит свой назначенный фрагмент примерно за 7:30-8:00; один 5142 финиширует
примерно в два раза быстрее.
Расчетное время в худшем случае оказалось ближе к 45 дням, но в итоге ключ был
найден примерно через 15 дней; Система проверила только ~ 37% всего 32-битного
пространства, а ключ, взятый в последовательном порядке от 0x00000000 до
0xFFFFFFFF, занимал ~ 73% пространства (так что, выполнив поиск случайным
образом, я получил 2-кратное ускорение, хотя это конечно не было никакой гарантии на
старте... Я не знаю достаточно статистики, чтобы сделать вывод, что рандом лучше, чем
последовательный, но в моем случае это очень помогло).
В любом случае, это то, чем я хотел поделиться с вами о своем первом опыте работы с
устройствами KNX

С уважением,
Джон



« Последнее редактирование: 2022-02-15, 16:59:16, Вторник от Aville »