продолжаю цикл статей о сложных взаимоотношениях хостера и клиента.
сегодня речь пойдёт о двух "уязвимостях" в кавычках, потому что как минимум одна из них - это не баг, а фича
0. кто виноват?
причина возникновения обеих "уязвимостей" состоит в том, что BMC абсолютно доверяют запущенной на сервере операционной системе, причём не обязательно установленной, достаточно загрузиться с LiveCD.
1) первая "уязвимость" позволяет добавить юзера BMC с правами администратора, не зная текущего администраторского пароля, и/или поменять его пароль на любой другой, и/или сбросить пароль на дефолтный ("ADMIN", "calvin", и так далее в разных BMC)
этой "уязвимости" подвержено подавляющее большинство всех серверов всех брендов мира, независимо от производителя чипа BMC или его прошивки.
пример команд для создания нового юзера:
где "10" = user id (проверьте сначала, чтобы этот id был не занят)
а "0x4" = права администратора.
можно просто выполнить "ipmitool user set password айди пароль" для изменения пароля или "ipmitool user priv айди привилегии" для изменения прав уже существующему юзеру, если хостер выдал вам доступ к BMC с правами юзера.
иногда нужно добавлять ещё "номер канала", например в Supermicro это "1", а в HP - "2" ("ipmitool user priv 10 0x4 1" и "ipmitool user priv 10 0x4 2" соответственно)
иногда нужно отдельно выдавать права через дополнительную утилиту, например, в Dell после создания юзера через ipmitool ещё нужно выполнить "idracadm set iDRAC.Users.10.Privilege 0x1ff" (предварительно скачав iDRACTools с сайта Dell)
2) вторая "уязвимость" позволяет сделать дамп текущей прошивки и/или залить новую прошивку.
впоследствии из этого дампа можно достать хэши юзеров, и, сбрутив эти хэши, пытаться подставить полученные пароли на других серверах в сети организации, а добавив в дамп прошивки полезный софт типа socat или plink можно продвигаться по сети организации на другие сервера.
этой "уязвимости" подвержено тоже подавляющее большинство всех серверов, но я точно уверен только насчёт серверов, использующих BMC от компании ASPEED: Supermicro, Lenovo, IBM, Tyan, AsRock, Quanta, ASUS, Gigabyte и некоторые другие бренды.
точно можно подменить прошивку на моделях BMC ASPEED до AST2400 включительно, эти модели использовались в серверах, произведённых до 2018 года.
в AST2500 скорее всего тоже можно, но я не проверял.
а вот начиная с AST2600 (в серверах, выпускавшихся где-то с 2020) - есть шанс, что залить модифицированную прошивку не получится, потому что в этой модели добавлен функционал цифровой подписи и проверки прошивок, "Silicon Root of Trust". однако сдампить текущую прошивку на AST2600 всё ещё можно.
1. при чём тут хостинг?
услуга аренды серверов - это самая очевидная цель для этих "уязвимостей", ведь хостинг провайдер даёт доступ к своему железу посторонним лицам.
опасность этих "уязвимостей" для хостинга состоит в том, что злонамеренный клиент может арендовать сервер на месяц, пробэкдорить BMC, и потом через бэкдор иметь доступ к этому серверу (и через него к другим серверам в сети хостинга) даже после окончания оплаченного периода аренды.
а с точки зрения клиента хостинга опасность состоит в том, что он может получить в аренду уже пробэкдоренный сервер, или сервер клиента могут пробэкдорить третьи лица: например, кибержулик взломает сайт клиента, через сайт порутает сервер, через рута получит доступ к BMC, и закрепится на сервере на уровне BMC, и потом как ни чисти сайт от шеллов и ни переустанавливай ОС на сервере, жулик всё равно будет восстанавливать свой доступ к сайту.
кибержулику (или злонамеренному клиенту) даже не обязательно заходить в админку хостинга, чтобы узнать данные доступа к BMC для заливки изменённой прошивки - если хостинг не предоставляет доступ к Web-интерфейсу BMC, то есть шанс залить протрояненную прошивку через какой-нибудь софт от разработчиков прошивок, такой как "Yafuflash" от AMI, "AlUpdate" от ATEN, "socflash" от ASPEED или "SUM" от Supermicro.
весь этот софт идёт без внятной документации, может работать или не работать на конкретном сервере и в зависимости от конкретной версии софта, может не работать в "большой" ОС типа Linux или Windows, но работать в DOS или UEFI короче, у меня это всё получалось с переменным успехом.
итого, в отличие от моих предыдущих статей со злым хостером, на этот раз и клиент может навредить хостингу, а то и вообще третьи лица могут навредить первым двум сразу.
2. что делать?
разоряться
от первой "уязвимости" никак не защититься - это не баг, а фича, так и задумывалось стандартом IPMI ¯\_(ツ)_/¯
от второй - использовать новые сервера, BMC которых поддерживает технологии "безопасной загрузки" и цифровой подписи прошивок "Secure Boot" и "Silicon Root of Trust":
- Supermicro 13 поколения, и некоторые модели 12го поколения с BMC ASPEED AST2600
- Lenovo вообще не пользуйтесь, это говно собачье, а не сервера
- HP начиная с 10 поколения, с BMC iLO5
- Dell начиная с 14 поколения, с BMC Nuvoton NPCM7xx
то есть для того, чтобы избежать проблем, хостерам нужно потратиться на обновление всего парка серверов (а также грамотно настроить сеть, чтобы BMC не имел доступа в Интернет и к соседним серверам), а клиентам - придётся тратить больше на аренду современных моделей, чтобы не бояться получить уже протрояненный сервер.
3. демонстрация на живом примере
на видео продемонстрированы действия злонамеренного клиента: потенциальный pwnage всего датацентра через аренду сервера и заливку на него протрояненной прошивки BMC (извините за английский язык - делал отчёт для кураторов из ФБР, а отдельное видео с каментами на русском записывать лень)
прямая ссылка на видео (100MB): https://files.catbox.moe/mtsh6w.mp4
vimeo:
4. аутро
ещё раз обращаю ваше внимание на то, что описанные уязвимости относятся не только к конкретному показанному на видео хостингу, а КО ВСЕМ хостингам, использующим сервера не самых последних поколений (старее 2020 года). я уведомил эту компанию о том, что их BMC могут не только видеть друг друга, но ещё и вылезать в Интернет, так что думаю, что сейчас это уже заблокировано на фаерволе датацентра. так что ломайте другие хостинги
автор статьи и видео: Dread Pirate Roberts https://xss.pro/members/296627/
распространять статью и/или видео разрешаю только при указании ссылки на этот топик https://xss.pro/threads/119921/
донаты на жестокое обращение с компьютерами слать сюда: 1dprEpsBVpjXfiaBtwyFp5X7Dtfs5VVR1
сегодня речь пойдёт о двух "уязвимостях" в кавычках, потому что как минимум одна из них - это не баг, а фича
0. кто виноват?
причина возникновения обеих "уязвимостей" состоит в том, что BMC абсолютно доверяют запущенной на сервере операционной системе, причём не обязательно установленной, достаточно загрузиться с LiveCD.
осторожно, 25 МБ картинок: https://xss.pro/threads/94447/
1) первая "уязвимость" позволяет добавить юзера BMC с правами администратора, не зная текущего администраторского пароля, и/или поменять его пароль на любой другой, и/или сбросить пароль на дефолтный ("ADMIN", "calvin", и так далее в разных BMC)
этой "уязвимости" подвержено подавляющее большинство всех серверов всех брендов мира, независимо от производителя чипа BMC или его прошивки.
пример команд для создания нового юзера:
Код:
ipmitool user set name 10 BACKDOOR
ipmitool user set password 10 BACKDOOR
ipmitool user priv 10 0x4
ipmitool user enable 10а "0x4" = права администратора.
можно просто выполнить "ipmitool user set password айди пароль" для изменения пароля или "ipmitool user priv айди привилегии" для изменения прав уже существующему юзеру, если хостер выдал вам доступ к BMC с правами юзера.
иногда нужно добавлять ещё "номер канала", например в Supermicro это "1", а в HP - "2" ("ipmitool user priv 10 0x4 1" и "ipmitool user priv 10 0x4 2" соответственно)
иногда нужно отдельно выдавать права через дополнительную утилиту, например, в Dell после создания юзера через ipmitool ещё нужно выполнить "idracadm set iDRAC.Users.10.Privilege 0x1ff" (предварительно скачав iDRACTools с сайта Dell)
2) вторая "уязвимость" позволяет сделать дамп текущей прошивки и/или залить новую прошивку.
впоследствии из этого дампа можно достать хэши юзеров, и, сбрутив эти хэши, пытаться подставить полученные пароли на других серверах в сети организации, а добавив в дамп прошивки полезный софт типа socat или plink можно продвигаться по сети организации на другие сервера.
этой "уязвимости" подвержено тоже подавляющее большинство всех серверов, но я точно уверен только насчёт серверов, использующих BMC от компании ASPEED: Supermicro, Lenovo, IBM, Tyan, AsRock, Quanta, ASUS, Gigabyte и некоторые другие бренды.
точно можно подменить прошивку на моделях BMC ASPEED до AST2400 включительно, эти модели использовались в серверах, произведённых до 2018 года.
в AST2500 скорее всего тоже можно, но я не проверял.
а вот начиная с AST2600 (в серверах, выпускавшихся где-то с 2020) - есть шанс, что залить модифицированную прошивку не получится, потому что в этой модели добавлен функционал цифровой подписи и проверки прошивок, "Silicon Root of Trust". однако сдампить текущую прошивку на AST2600 всё ещё можно.
как я её понимаю, могу ошибаться.
старым моделям неоткуда брать данные для проверки подлинности прошивки, поэтому они вынуждены доверять данным, полученным от пользователя. производители прошивок в свою очередь особо не парятся и делают простую "подпись" прошивки в виде специальной строки (например, "ATENs_FW" у Supermicro ( https://xss.pro/threads/94447/post-655853 ) или "$MODULE$" у Lenovo), спрятанной в особом месте внутри прошивки, а также содержащей CRC32 чексуммы разделов прошивки.
а у новых моделей BMC есть дополнительная, собственная SPI флешка или собственный чип TPM (иногда в софтовой реализации на FPGA), в которой/котором хранятся ключи, с помощью которых производится проверка подлинности прошивки. эти ключи заливаются один раз на заводе, и без физического доступа к серверу пользователь подменить эти ключи не сможет (а с физическим доступом сможет
https://github.com/google/security-research/security/advisories/GHSA-v9gx-jrwm-3f78 ), эти записанные в SPI/TPM чип ключи и есть "Silicon Root of Trust".
старым моделям неоткуда брать данные для проверки подлинности прошивки, поэтому они вынуждены доверять данным, полученным от пользователя. производители прошивок в свою очередь особо не парятся и делают простую "подпись" прошивки в виде специальной строки (например, "ATENs_FW" у Supermicro ( https://xss.pro/threads/94447/post-655853 ) или "$MODULE$" у Lenovo), спрятанной в особом месте внутри прошивки, а также содержащей CRC32 чексуммы разделов прошивки.
а у новых моделей BMC есть дополнительная, собственная SPI флешка или собственный чип TPM (иногда в софтовой реализации на FPGA), в которой/котором хранятся ключи, с помощью которых производится проверка подлинности прошивки. эти ключи заливаются один раз на заводе, и без физического доступа к серверу пользователь подменить эти ключи не сможет (а с физическим доступом сможет
https://github.com/google/security-research/security/advisories/GHSA-v9gx-jrwm-3f78 ), эти записанные в SPI/TPM чип ключи и есть "Silicon Root of Trust".1. при чём тут хостинг?
услуга аренды серверов - это самая очевидная цель для этих "уязвимостей", ведь хостинг провайдер даёт доступ к своему железу посторонним лицам.
опасность этих "уязвимостей" для хостинга состоит в том, что злонамеренный клиент может арендовать сервер на месяц, пробэкдорить BMC, и потом через бэкдор иметь доступ к этому серверу (и через него к другим серверам в сети хостинга) даже после окончания оплаченного периода аренды.
а с точки зрения клиента хостинга опасность состоит в том, что он может получить в аренду уже пробэкдоренный сервер, или сервер клиента могут пробэкдорить третьи лица: например, кибержулик взломает сайт клиента, через сайт порутает сервер, через рута получит доступ к BMC, и закрепится на сервере на уровне BMC, и потом как ни чисти сайт от шеллов и ни переустанавливай ОС на сервере, жулик всё равно будет восстанавливать свой доступ к сайту.
кибержулику (или злонамеренному клиенту) даже не обязательно заходить в админку хостинга, чтобы узнать данные доступа к BMC для заливки изменённой прошивки - если хостинг не предоставляет доступ к Web-интерфейсу BMC, то есть шанс залить протрояненную прошивку через какой-нибудь софт от разработчиков прошивок, такой как "Yafuflash" от AMI, "AlUpdate" от ATEN, "socflash" от ASPEED или "SUM" от Supermicro.
весь этот софт идёт без внятной документации, может работать или не работать на конкретном сервере и в зависимости от конкретной версии софта, может не работать в "большой" ОС типа Linux или Windows, но работать в DOS или UEFI
короче, у меня это всё получалось с переменным успехом.итого, в отличие от моих предыдущих статей со злым хостером, на этот раз и клиент может навредить хостингу, а то и вообще третьи лица могут навредить первым двум сразу.
2. что делать?
разоряться
от первой "уязвимости" никак не защититься - это не баг, а фича, так и задумывалось стандартом IPMI ¯\_(ツ)_/¯
от второй - использовать новые сервера, BMC которых поддерживает технологии "безопасной загрузки" и цифровой подписи прошивок "Secure Boot" и "Silicon Root of Trust":
- Supermicro 13 поколения, и некоторые модели 12го поколения с BMC ASPEED AST2600
- Lenovo вообще не пользуйтесь, это говно собачье, а не сервера
- HP начиная с 10 поколения, с BMC iLO5
- Dell начиная с 14 поколения, с BMC Nuvoton NPCM7xx
то есть для того, чтобы избежать проблем, хостерам нужно потратиться на обновление всего парка серверов (а также грамотно настроить сеть, чтобы BMC не имел доступа в Интернет и к соседним серверам), а клиентам - придётся тратить больше на аренду современных моделей, чтобы не бояться получить уже протрояненный сервер.
3. демонстрация на живом примере
на видео продемонстрированы действия злонамеренного клиента: потенциальный pwnage всего датацентра через аренду сервера и заливку на него протрояненной прошивки BMC (извините за английский язык - делал отчёт для кураторов из ФБР, а отдельное видео с каментами на русском записывать лень)
прямая ссылка на видео (100MB): https://files.catbox.moe/mtsh6w.mp4
vimeo:
опытным путём было выяснено, что баг в программе Peek не позволяет сохранять видео длиннее 5 минут 10 секунд, поэтому, после пролюбленного первого часа съёмок, пришлось снимать всё с самого начала, по частям длиной максимум 5 минут, а некоторые участки по несколько раз, поэтому не удивляйтесь резким переходам, юзеру "DOOR" и внезапно появившемуся файлу rootfs.bin_backup
4. аутро
ещё раз обращаю ваше внимание на то, что описанные уязвимости относятся не только к конкретному показанному на видео хостингу, а КО ВСЕМ хостингам, использующим сервера не самых последних поколений (старее 2020 года). я уведомил эту компанию о том, что их BMC могут не только видеть друг друга, но ещё и вылезать в Интернет, так что думаю, что сейчас это уже заблокировано на фаерволе датацентра. так что ломайте другие хостинги
автор статьи и видео: Dread Pirate Roberts https://xss.pro/members/296627/
распространять статью и/или видео разрешаю только при указании ссылки на этот топик https://xss.pro/threads/119921/
донаты на жестокое обращение с компьютерами слать сюда: 1dprEpsBVpjXfiaBtwyFp5X7Dtfs5VVR1
Последнее редактирование:
у него ман длиннее, чем у iptables, а в Peek мышкой повозюкал и готово 
