The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Компрометация шлюзов Barracuda ESG, требующая замены оборудования, opennews (?), 11-Июн-23, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


4. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +6 +/
Сообщение от Аноним (4), 11-Июн-23, 10:32 
Убрать эту компанию из списка поставщиков, бекдор оказалась слишком аппаратным.
Ответить | Правка | Наверх | Cообщить модератору

14. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +3 +/
Сообщение от Аноним (14), 11-Июн-23, 11:08 
новое железо с обновленным бекдором
Ответить | Правка | Наверх | Cообщить модератору

22. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +6 +/
Сообщение от Аноним (22), 11-Июн-23, 12:04 
На самом деле это достаточно просто устроить, имхо: если апдейт на фирмвару от хаксора откажется потом грузить фирменнные апдейты, а бутлоадер заменит на свой, отказывающийся шить вендорскую фирмвару... это все не так уж сложно сделать как можно себе представить.

И тут вендор такой - опа! Его выперли с его же девайса. Жытаг осваивайте, там свое всегда отспорить можно :)

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

37. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +3 +/
Сообщение от anodymus (?), 11-Июн-23, 14:49 
> Жытаг осваивайте, там свое всегда отспорить можно :)

Не всегда. Иногда предохранители выжигаются при записи софта для защиты от аппаратной отладки. Тот же народный STM32, например. И уже не перезальёшь ничего. Только чип перепаивать.

Ответить | Правка | Наверх | Cообщить модератору

86. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +1 +/
Сообщение от Тот_ещё_аноним (ok), 12-Июн-23, 09:01 
На колодку ставить)
Ответить | Правка | Наверх | Cообщить модератору

114. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +/
Сообщение от Аноним (114), 12-Июн-23, 22:47 
1) STM32 F1xx и тому подобные - можно "вернуть себе" как раз всегда. Там лишь 1 уровень защиты от чтения - и он не запрещает дебаг или ROM loader насовсем, лишь ограничивает операции. Такой чип всегда можно вернуть в "девственный" вид, но, правда, только, после полного стирания - так что фирмвару из него вы не получите. Как минимум официально и удобно.
2) Де факто есть атака с использованием этого дебажного доступа, позволяющая большую часть фирмвары все-таки выковырять. Очень креативным обходом STшных защит через I-bus. Но это не полная копия и стопроцентно спиратить-забэкапить все же не получится.
3) F0/L0/L1/etc сделали 2-й уровень защиты, он более мерзкий и отключает жытаг и ROM лоадер. И вот тут чипак уже делает только то что хочет его встроенная фирмвара. И если "юзерский" бутлоадер и фирмвара - и вас к себе пускать не хотят - вот тут уже неудобненько получается, потому что красивого и официального способа нет, replace MCU and press any key.
4) Менее официально, это состояние врубается только если фуз профлешен в вполне конкнетное состояние. И его инверсная копия - тоже. Если поймать момент когда чип читает состояние фузов и сбить вот это вот, вы все правильно поняли: чип вывалится в fallback-режим с защитой уровня 1. После этого станет доступен JTAG и бутлоадер. Далее см. пункт 1.

И это работает в обе стороны. Атакующий сменивший "юзерский" бутлоадер в флехе на свой и быренько вырубающий JTAG при старте может сделать довольно неудобно легитимному обладателю системы, если апдейтилось через их кастомный бут а не STшный ROM (довольно дурной и специфичный). Жытагом/swd правда все равно зацепиться можно - если оно RESET# умеет зажимать, так что запрет жытага в коде (например рекрнфигом пинов) обломается.

Физически как вы уже поняли там ничего и никогда не выжигается. Там даже "boot ROM" - отдельная секция в модуле флеша, рядом с секцией фузов. ST шьет его на фабе, видимо, через JTAG или SWD. Потом сегмент, вероятно, лочится в readonly, а процедура программирования этого сегмента вообще не документирована. Можно и свои сегменты в readonly loчить, сделав этакий эквивалент ROM-loader в фирмваре - потом его стереть станет достаточно канительно.

И фузы - лишь байтики в отдельной секции массива флеша. Они как бы стирабельны - и если F0/L0/L1 выбить из level 2 lock заскоками с питанием сбивающими чтение фузов, потом его можно стереть и вернуть в фабричный вид как обычно с level 1 защитой.

Есть и еще несколько забавных исследований - например из F0 при определенных условиях исследователи вообще всю прощивку выдергивать научились.

p.s. а китайские клоны вообще позорники: чаще всего забывают даже "детские" веши заткнуть, типа попросить DMA читануть флеху -> RAM (mem2mem xfer), опа, ололо, можно забрать буфер из RAM (level 1 не блочит работу с SRAM, но вырубает доступ в флеш для всего что не I-bus проца). И так за несколько итераций можно DMA понакидать себе флеху -> SRAM и слить ее дебагером. Копипастеры из китая такие вещи забывают учесть.

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

83. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +/
Сообщение от Аноним (83), 12-Июн-23, 08:00 
Intel Boot Guard должен запрещать загрузку вирусных прошивок BIOS/UEFI, а они уже вирусных BootLoader-ов и далее по цепочке верифицированной загрузки.

Это не снимает проблему окерпичивания устройства при заражении.

Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

72. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +/
Сообщение от igaiLie7 (?), 11-Июн-23, 23:44 
Не смешно, когда собственные устройства работают против вас. Прогресс, а что поделать? Жизнь полна неожиданностей.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

118. "Компрометация шлюзов Barracuda ESG, требующая замены оборудо..."  +1 +/
Сообщение от Аноним (114), 12-Июн-23, 22:56 
> Не смешно, когда собственные устройства работают против вас.
> Прогресс, а что поделать? Жизнь полна неожиданностей.

Вы sci-fi когда-нибудь смотрели? Перехват инженерных систем более-менее крупных (или массовых) кораблей - невероятно злой, эффективный и нахальный вид диверсий, ведущих к жирным факапам у адресата атаки. Как вы уже поняли если в большой системе управляемой компьютерами обосновался кто-то другой, вы основательно залетаете. А еще, как вы догадались, все это реализуемо и уже в общем то начинает иметь определенный смысл. Уже были очень интересные атаки когда хацкеры с информационно-развлекательной системы самолета влезали в куда более интересный сегмент сети. Где вон те компьютеры общаются как раз. Ведь нынче в моде fly by wire. Это как раз доисторический прототип тех звездных крейсеров, первобытная и кривая пока еще версия. Знакомьтесь.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру