Protocolos esquecidos: IPMI

Em posts anteriores, mencionamos a importância de prestar atenção especial a todos os serviços que nossos ativos de TI fornecem à nossa rede interna. Um exemplo claro foi mencionar protocolos como o NTP onde encontramos uma funcionalidade que, sob o senso de segurança atual, parece não ter tanta interferência dentro dos ativos mais críticos, mas justamente como detalhado naquele post, descobrimos que esse recurso esquecido é de vital importância para outros serviços que dependem da variável de tempo, como resultado, pudemos mostrar como vetores de ataque podem ser desenvolvidos aplicados a esse protocolo que normalmente não é observado no espectro daqueles que os administradores de sistemas levam em consideração ao monitorar a saúde deles.

Como você deve saber, esse não é o único protocolo negligenciado dentro dos serviços que estamos acostumados a proteger, já que, com uma diversidade tão grande de tecnologias dentro das empresas, encontramos não apenas uma falta de conscientização quando se trata de entender todos os protocolos, mas também uma falta de capacidade técnica para dar a eles o tratamento e a atenção que merecem. Hoje, nesta postagem, vamos falar sobre outra joia para os invasores que continua a passar despercebida, o protocolo IPMI (Intelligent Platform Management Interface), com o qual as interfaces BMC (Baseboard Management Controller) funcionam.

Para que serve o protocolo IPMI?

A Intelligent Platform Management Interface é um conjunto de especificações relacionadas a uma interface Ethernet específica associada a um subsistema que fornece recursos de gerenciamento e monitoramento independentes do host principal (como uma mamuska de computadores). Quando falamos sobre o host principal, falamos sobre seu hardware (sua "CPU"), o firmware e o sistema operacional. O IPMI permite que um conjunto de interfaces seja definido para que os administradores de sistema possam realizar a administração "out-of-band". Ele nos proporciona a capacidade de gerenciar e monitorar o estado de saúde de um computador que possa estar inativo ou que tenha um problema que impeça a resposta habitual, ou de permitir a execução de tarefas de manutenção, como a reinstalação do sistema operacional, de forma totalmente remota, sem depender da rede principal ou dos mecanismos habituais.

Sem esse protocolo, essas tarefas exigiriam que o administrador ficasse fisicamente na frente do computador, inserisse uma mídia com a ISO do sistema operacional e concluísse o processo de instalação usando um monitor e um teclado. Com a IPMI, podemos montar uma imagem remotamente, simulando uma instalação física.

Usando mensagens padronizadas, um sistema de gerenciamento baseado em IPMI pode gerenciar vários servidores que dialogam nesse nível de rede. Essas funções podem funcionar em três cenários diferentes:

 • Antes da inicialização do sistema (permitindo o monitoramento remoto ou a alteração de qualquer configuração do BIOS)
 •  Quando o sistema está sendo desligado (para determinar por que isso está acontecendo, tendo em mente que às vezes isso acontece de forma não planejada).
 •  Após uma falha no sistema operacional.

Entre os problemas a serem monitorados estão variáveis técnicas, como temperatura, ventilação, fontes de alimentação, mas também uma intrusão física no hardware (como conectar um USB) ou um registro que possa fornecer ajuda em relação a um mau funcionamento que possa ocorrer em uma instalação. Esse protocolo foi lançado pela Intel em 1998 e atualmente é suportado por mais de 200 fabricantes, incluindo Cisco, Dell, HP, Intel e muitos outros. Em geral, os sistemas usam a versão 2.0, que pode ser gerenciada por meio da porta serial pela LAN (observe este ponto para discussão posterior); para funcionar, o protocolo requer os seguintes componentes:

 •  BMC (Baseboard Management Controller, controlador de gerenciamento de placa de base): um microcontrolador alojado dentro da placa-mãe do servidor, é um pequeno computador baseado em um SoC (System on a Chip, sistema em um chip) ARM, com um controlador gráfico incluído. Alguns fabricantes usam soluções não-ARM, mas atualmente o principal SoC dedicado a isso é o AST2500. Esses SoCs são acompanhados por armazenamento flash e vários controladores de entrada e saída.
Na imagem abaixo, podemos ver como o driver BMC está conectado a uma placa-mãe Intel S1200V3

Nesta outra imagem, podemos visualizar como o BMC (AST2500) é composto internamente. Nela, podemos ver em detalhes todas as partes que interagem dentro do chip.

Ele tem várias conexões com o sistema principal, com a capacidade de monitorar o hardware, conforme discutido anteriormente. As maneiras de acessá-lo podem ser por meio de uma porta serial ou por meio de um KVM (Keyboard Video & Mouse) virtual. Para entender melhor como ele funciona, podemos fazer uma analogia desse SoC com um RaspberryPi e seu diagrama de componentes (como mostrado na imagem abaixo).

 •  Intelligent Chassis Management Bus (ICMB): Barramento de gerenciamento de chassi inteligente): é usado como uma interface de controle entre diferentes chassis (definindo chassis como a unidade dentro do rack que contém um determinado número de servidores), permitindo a comunicação por meio de uma interface serial com fio.
 •  Intelligent Platform Management Bus: (Barramento de gerenciamento da plataforma inteligente): usado para estender o BMC e interconectar diferentes placas.
 •  Memória IPMI: é a memória usada para armazenar os registros do sistema, os dados armazenados em repouso, entre outras coisas.
 •  Interfaces de comunicação: interfaces locais, portas seriais, LAN e interfaces PCI.

A administração dessas interfaces ocorre por meio da rede LAN que todos nós conhecemos. Observando a ilustração a seguir, podemos ver como um administrador consegue se conectar ao BMC por meio da porta 623/UDP/TCP usando o IPMI.

Deve-se esclarecer que o sistema principal pode ser desligado, mas o módulo IPMI estará "sempre" ligado e uma conexão com a LAN estará disponível para uso, porque geralmente todos os BMCs do servidor estão interconectados entre si. Para trafegar os dados necessários para as tarefas de manutenção, é gerada uma interconexão que pode ser vista da seguinte forma:

Até o momento, não vemos nada de estranho, temos uma rede paralela à LAN que interconecta todos os BMCs e serve para monitorar o status de integridade dos dispositivos. Então, onde está o principal problema? Está na falta de conhecimento desses serviços ou na forma como eles são implementados? É muito provável que os administradores da área responsável pelos servidores estejam cientes da existência dos controladores BMC para poder monitorar suas interfaces, portanto, o problema não está tanto na aparente falta de conhecimento desse tipo de protocolo. Como o BMC é um computador dentro de outro computador e tem acesso à LAN, o problema é o "mesmo de sempre". Se não houver uma segmentação adequada para proteger esses recursos, todas as falhas que esse controlador possa ter serão expostas, ampliando a superfície de ataque dessa rede e permitindo que os invasores acessem esses recursos.

Considerando a última imagem, se um invasor tiver visibilidade sobre o endpoint que gerencia a rede do BMC (ponto 1 marcado na ilustração) ou, na falta disso, a mesma rede se comunicar sem problemas com nossa rede LAN, deixando a rede do BMC exposta (ponto 2 marcado na ilustração):

Essa é uma possível violação de segurança que expõe as interfaces IPMI e amplia a superfície de ataque, conforme mostrado no cenário a seguir:

Assim, poderíamos dizer que o invasor não só tem acesso ao monitoramento dos servidores, mas também pode se mover de chassi em chassi, alcançando servidores hospedados em áreas não autorizadas da infraestrutura, como encontramos no detalhe da imagem acima, onde vemos isso no caminho azul, a partir de uma vulnerabilidade encontrada em um BMC (correspondente a um servidor específico), o invasor acessa o CMC e, em seguida, passa de chassi em chassi até acessar o servidor desejado fora de seu raio de ação original ou segue o caminho 1 detalhado acima, em que o invasor acessa o endpoint não controlado que tem acesso ao RMC (que pode ver todos os CMCs correspondentes).

É importante mencionar que, como profissionais de segurança cibernética, devemos controlar esses pontos não apenas atenuando as possíveis vulnerabilidades, mas também limitando a visibilidade que os invasores podem ter sobre esses recursos que, à primeira vista e sem saber como funcionam, geralmente estão fora do alcance de interesse da proteção.

Para identificar se esses serviços têm visibilidade em nossa rede interna, podemos executar as seguintes etapas. Nós nos posicionamos em qualquer ponto da rede e, em seguida, podemos executar os seguintes comandos para fazer uma enumeração deles, realizando um pentesting interno orientado para determinar a viabilidade dessas possíveis exposições.

Escaneamento e enumeração:

Nesse estágio, prosseguimos com a execução de uma série de varreduras que me permitirão identificar a respectiva visibilidade associada a essas interfaces. O invasor, nesse estágio, busca ter acesso a esses recursos sem supervisão.

 •  Execute os comandos a seguir com o NMAP em um ponto da rede do servidor para verificar se essas comunicações estão operacionais (lembre-se de que o serviço pode ser feito por UDP e TCP, portanto, é recomendável enumerar os dois segmentos)
 •  Em seguida, prosseguimos para identificar qual versão do IPMI está sendo usada nos serviços encontrados anteriormente. Usando um exploit auxiliar no Metasploit e, para o UDP, um script do Nmap:

 •  É recomendável documentar todos os hosts e, em seguida, executar um teste de segmentação de todos os pontos possíveis da rede, a partir dos quais esses serviços não devem ser vistos.


Obtenção de acesso ao BMC:

Relembrando os casos vistos anteriormente, se os serviços estiverem acessíveis e identificados, devemos obter acesso por meio dessas portas que estão abertas e visíveis. Para isso, podemos realizar os seguintes testes:

 •  Bypass de autenticação IPMI via Cipher 0: essa vulnerabilidade encontrada por Dan Farmer no protocolo IPMI 2.0 refere-se ao fato de que o tipo de cifra cipher 0, que indica que o usuário usa autenticação simples, na verdade permite o acesso com qualquer senha. Provavelmente, o problema poderá afetar todas as implementações do IPMI 2.0.

- Ele pode ser identificado usando o seguinte exploit auxiliar com o metasploit: use auxiliary/scanner/ipmi/ipmi_cipher_zero

- Após a identificação, poderíamos explorar a falha usando a ferramenta ipmitool, executando os comandos detalhados na captura de tela a seguir:

 •  IPMI 2.0 RAKP Authentication Remote Password Hash: também podemos solicitar ao servidor o hash MD5 ou SHA1 de qualquer usuário e, se o usuário existir, esses hashes serão retornados (se repetirmos a etapa anterior do ataque, podemos primeiro, com o ipmitool, pesquisar os usuários existentes e depois solicitar os respectivos hashes). Para essa finalidade, há um módulo do metasploit que nos ajuda a coletá-los.
- use auxiliary/scanner/ipmi/ipmi_dumphashes
 •  Acesso anônimo ao IPMI: se, ao listar os usuários, descobrirmos que há campos vazios, eles podem ser usuários nulos; se repetirmos as etapas anteriores, poderemos configurar uma senha para cada um deles.

 •  IPMI SuperMicro - Senhas em texto simples: nesse caso, o IPMI 2.0 responde à autenticação HMAC usando SHA1 e MD5. Esse processo tem um ponto fraco, mas o acesso à senha de texto simples geralmente é necessário para calcular o respectivo Hash. Assim como as senhas da placa-mãe de uma infraestrutura, os usuários que mantêm essas instalações geralmente definem a mesma senha para todos os BMCs, portanto, muitas vezes é suficiente acessar um BMC específico e extrair as senhas do diretório /nv/PSBlock ou /nv/PSStore. A próxima etapa é calcular o hash correspondente ao valor obtido desses caminhos e executar a respectiva autenticação.
 •  Bruteforcing: todas as instalações são vulneráveis a ataques de força bruta e, em alguns casos, mantêm suas configurações padrão originais. Portanto, acessar as informações necessárias para executar esse ataque é de vital importância depois de ter realizado a enumeração correspondente. Alguns exemplos de dados podem ser os seguintes:

Obtenção de acesso ao host:

Depois de acessar a interface virtual KVM do respectivo BMC, resta acessar o host em questão. Nesse caso, depende do tipo de sistema operacional que possui o servidor principal correspondente ao BMC; nesse caso, podemos obter acesso de várias maneiras.

 •  No caso de sistemas Linux, simplesmente reiniciando o servidor a partir de nosso KVM, poderíamos, por exemplo, editar o Grub, adicionando a linha clássica init=/bin/bash, na instrução Linux e, em seguida, iniciar a sequência de inicialização, pressionando F10.

 •  Em seguida, quando recebermos o prompt do root, poderemos apagar a senha do root ou criar outro usuário com os respectivos comandos.
 •  No caso de sistemas Windows; poderíamos usar o KVM para carregar um ISO de CD de inicialização do Hirens e, em seguida, usar o NTPWEdit para clarear a chave do usuário administrador local.

Possíveis soluções

Deve-se observar que há várias maneiras de atenuar esses problemas. Entretanto, se não usarmos o IPMI, os riscos serão consideravelmente reduzidos. Não devemos deixar de prestar atenção aos BMCs correspondentes. As etapas para verificar isso seriam as seguintes:

 •  Certifique-se de que os testes de segmentação nessas interfaces sejam negativos; caso sejam positivos, teremos uma ampla superfície de ataque na qual o invasor poderá trabalhar sem nenhum inconveniente. Lembre-se de que, em qualquer KillChain, o objetivo é deter o invasor o mais rápido possível para evitar problemas maiores. Se cegarmos o invasor aplicando a segmentação correta e a segurança em profundidade, poderemos minimizar esses riscos.
 •  Atualize os controladores BMC vulneráveishá vários patches que podem ser aplicados a esses firmwares. Caso você tenha um firmware SuperMicro, deixamos um link nas referências para que você possa seguir esses guias.
 •  Para executar um patch seguro, você deve bloquear a porta 623 momentaneamente para executar a atualização corretamente.
 •  Altere os usuários e as senhas padrão; defina senhas fortes para tornar mais complexo o cálculo do hash e do salt.
 •  Implemente uma arquitetura de rede correta; nesta etapa, certifique-se de que os serviços IPMI não estejam visíveis na Internet, pois é muito comum encontrar esses serviços ativados via Shodan.
 •  Segmente a rede de gerenciamento para impedir o acesso de qualquer lugar da LAN, implementando uma DMZ interna com um firewall dedicado.

Conclusão

Acreditamos que é importante entender as tecnologias para mantê-las protegidas. Entendemos que é difícil aplicar soluções quando todas as plataformas estão em produção, quando um risco é identificado ou visto nas notícias. Tornar esses conceitos práticas rotineiras tem um impacto direto em nossa arquitetura, sejam elas novas vulnerabilidades ou não, mas não estaremos seguros se não verificarmos.