Explorando o Honeywell ControlEdge VirtualUOC

Resumo executivo

A Team82 pesquisou o Centro de Operações de Unidade Virtual (UOC) da Honeywell ControlEdge e encontrou várias vulnerabilidades na implementação do protocolo EpicMo nas instâncias do ControlEdge Virtual UOC. Essas vulnerabilidades são exploráveis e podem levar à execução de código remoto não autenticado.

As vulnerabilidades que encontramos residem no protocolo EpicMo (porta TCP 55565), um protocolo proprietário desenvolvido pela Honeywell que é usado para a comunicação entre os servidores e controladores Honeywell Experion. Esse protocolo continha uma função não documentada e perigosa que nos permitia gravar arquivos nos controladores Virtual UOC sem saneamento, o que expunha os dispositivos à execução de código não autorizado. Um invasor que já estivesse em uma rede OT usaria um pacote de rede malicioso para explorar essa vulnerabilidade e comprometer o controlador virtual. Esse ataque poderia ser realizado remotamente para modificar arquivos, resultando no controle total do controlador e na execução de código malicioso. 

A Honeywell atualizou o Virtual UOC e os usuários devem migrar para as versões atuais. A Cybersecurity Infrastructure & Security Agency (CISA) publicou um comunicado sobre o CVE-2023-5389 (pontuação CVSS v3: 9.1) e o CVE-2023-5390 (5.3). A Honeywell também publicou um aviso.

O que é o Honeywell Virtual UOC?

A Honeywell é um participante importante no mercado de sistemas de controle industrial (ICS), oferecendo uma ampla gama de controladores para automação industrial. Um produto é o ControlEdge Unit Operations Controller (UOC) da Honeywell, um controlador físico modular que amplia o ambiente DCS de controle Experion. O ControlEdge UOC inclui Ethernet, ModbusTCP e EtherNet/IP incorporados e tolerantes a falhas. O UOC também é oferecido como um controlador virtual. O UOC virtual reduz o espaço ocupado pelo hardware de uma empresa, pois não requer um controlador físico. Trata-se essencialmente de uma máquina virtual baseada em Linux que pode ser instalada em um ambiente virtual.

Vários protocolos de comunicação de UOC virtual

Os controladores da Honeywell usam vários protocolos para comunicações. Um serviço chamado Servidor de nomes é responsável pelo roteamento e pela abertura de comunicações para todos os protocolos. Para iniciar a comunicação em um protocolo específico, primeiro precisamos enviar uma mensagem UDP para o Servidor de nomes (pela porta UDP 12321), especificando o protocolo que será usado.

Depois de enviar a mensagem de inicialização UDP, é possível iniciar a comunicação por TCP. Cada sessão começa com uma mensagem de inicialização TCP que especifica o protocolo novamente.

Protocolo EpicMo

O protocolo EpicMo (porta TCP 55565) é usado para depuração e diagnóstico dos controladores Honeywell. Ele inclui códigos de função como ReadMemory, WriteMemory, Reinicialização e ReadCrashBlockque permitem a detecção e a depuração de erros.

Estrutura do protocolo

Número de sequência	Comprimento do pacote	Número de pacotes Recebidos	Número de pacotes enviados	Código de função
2 bytes	2 bytes	2 bytes	2 bytes	1 byte

• Número de sequência: Um número sequencial para o pacote.

• Comprimento do pacote: Comprimento do pacote.

• Número de pacotes recebidos: Contador do número de pacotes recebidos.

• Number Packet Sent: Contador do número de pacotes enviados.

• Código da função: O código da função que o cliente deseja invocar.

Ao pesquisar o protocolo EpicMo, descobrimos que o Virtual UOC implementa códigos de função EpicMo diferentes dos do controlador C300.

Dois comandos que chamaram nossa atenção são LoadFileFromModule e LoadFileToModule. Depois de pesquisar essas funções, chegamos à conclusão de que elas permitem a gravação e a leitura arbitrárias de arquivos no controlador virtual.

CVE-2023-5389:

De File Write para preauth RCE via LoadFileToModule

(Comando 0x51)

LoadFileToModule permite que os usuários gravem arquivos no controlador. Um dos parâmetros que essa função recebe é um Caminho_Destinoque é o caminho no qual o arquivo fornecido será gravado. 

Descobrimos que essa funcionalidade permite que os usuários forneçam um caminho e dados arbitrários, e não há validação ou limitação no caminho fornecido. Isso significa que os usuários podem gravar arquivos em todos os locais graváveis no controlador, o que é uma preocupação de segurança. Aproveitando essa funcionalidade, os invasores podem obter a execução remota de código no controlador, gravando arquivos executáveis, por exemplo.

Para fazer upload de um arquivo usando o LoadFileToModule precisamos enviar pelo menos três pacotes (iniciar gravação, gravar dados, terminar gravação). Cada pacote começa com o cabeçalho regular do EpicMo.

LoadFileToModule iniciar comando de gravação

Tipo de arquivo	Número do pacote de upload	Desconhecido	Checksum de dados do arquivo	Comprimento dos dados do arquivo	Caminho de destino
1 byte	4 bytes	2 bytes	4 bytes	4 bytes	Cordas

• Tipo de arquivo: Arquivo de firmware ou arquivo genérico. 0x05 é usado para arquivo genérico

• Número do pacote de upload: Número do pacote na sequência de upload. O primeiro pacote é 0.

• Checksum de dados do arquivo: Checksum para todos os dados do arquivo

• Comprimento dos dados do arquivo: Comprimento de todos os dados

• Caminho de destino: O nome do arquivo a ser salvo no controlador

LoadFileToModule comando de dados 

O comprimento máximo dos dados do arquivo em um comando de dados é 0x7F. Se o comprimento dos dados for superior a 0x7F, ele será dividido em vários pacotes, e o número do pacote de upload será atualizado de acordo.

Tipo de arquivo	Número do pacote de upload	Comprimento dos dados (0x7f máx.)	Dados
1 byte	4 bytes	2 bytes	n-Bytes

LoadFileToModule comando final 

O comando Final é usado para sinalizar que o upload foi concluído.

Tipo de arquivo	Número do pacote de upload	Comprimento dos dados: Deve ser 0
1 byte	4 bytes	2 bytes

Quando o número do pacote de upload não é 0 e o comprimento dos dados é 0, ele é considerado como o pacote de upload final.

Para enviar um LoadFileToModule start, precisamos incluir uma soma de verificação do arquivo. Para calcular a soma de verificação de um arquivo, implementamos a seguinte função que retorna a soma de verificação correta para um determinado arquivo, abaixo.

Para demonstrar como um invasor pode aproveitar essa vulnerabilidade para obter a execução remota de código, procuramos locais graváveis no controlador virtual. No entanto, havia algumas limitações:

1. Arquivos carregados usando LoadFileToModule não têm o atributo de execução do UNIX

2. Todos os arquivos que estão montados em /usr/honeywell são montados como somente leitura e esse diretório não pode ser gravado.

Por fim, decidimos substituir um arquivo .so do sistema; os arquivos .so não precisam ter o atributo execute, e podemos criar um objeto compartilhado que executará nosso código quando for carregado. Escolhemos o /lib/libcap.so.2 como o objeto compartilhado que substituímos, pois ele é carregado na inicialização, mas substituí-lo não afeta o tempo de execução de nenhuma forma importante e permite um RCE pré-autenticação estável. 

Nosso fluxo de execução de código tem a seguinte aparência:

1. Compilar libcap.so.2 com nosso payload definido para ser executado na inicialização

2. Use o LoadFilefromModule para gravar o arquivo em /lib/libpcap.so.2 no controlador

3. Chame o comando Reboot para garantir o recarregamento do libcap.so.2

Por fim, conseguimos demonstrar um RCE preauth em um UOC virtual remoto usando o CVE-2023-5389.

Conclusão 

Protocolos proprietários, como o EpicMo da Honeywell, usado para comunicação entre os servidores e controladores Honeywell Experion, geralmente contêm vulnerabilidades que podem colocar os processos industriais em risco de manipulação ou interrupção. 

Encontramos mecanismos com uma função que permite a execução remota de código ao gravar arquivos em controladores UOC virtuais sem sanitização.

Encontramos uma função não documentada e perigosa que nos permitiu gravar arquivos nos controladores do Virtual UOC sem saneamento. Um invasor na rede OT poderia enviar pacotes maliciosos para o controlador e gravar arquivos sem autenticar o controlador. 

A Team82 divulgou de forma privada essas vulnerabilidades, CVE-2023-5389 e CVE-2023-5390, para a Honeywell, que as corrigiu em uma atualização.