A Team82 está publicando os detalhes de nossa pesquisa sobre os PLCs/HMIs integrados da Unitronics, que teve início após a divulgação de vários ataques a infraestruturas críticas no último outono, especialmente em instalações de tratamento de água nos Estados Unidos e em Israel.
A CyberAv3ngers, ligada ao Irã, é supostamente responsável pelos ataques.
Desenvolvemos duas ferramentas que estamos disponibilizando gratuitamente hoje. Essas ferramentas podem ser usadas para extrair informações forenses de HMIs/PLCs integrados da Unitronics.
A primeira ferramenta, PCOM2TCPpermite que os usuários convertam mensagens PCOM seriais em mensagens TCP PCOM e vice-versa. O PCOM é o protocolo de comunicação proprietário da Unitronics.
O segundo, chamado PCOMClientepermite que os usuários se conectem ao PLC da série Unitronics Vision/Samba, consultem-no e extraiam informações forenses do PLC.
Este blog descreve nossa configuração de pesquisa, o processo pelo qual descompactamos o protocolo proprietário PCOM e as necessidades que nos levaram a desenvolver as duas ferramentas para extrair informações dos dispositivos.
Como parte dessa pesquisa, descobrimos duas novas vulnerabilidades , CVE-2024-38434 e CVE-2024-38435. A Unitronics recomenda que todos os usuários atualizem para a versão 9.9.1
Os ataques em novembro passado contra os HMIs/PLCs integrados da Unitronics demonstraram que os agentes da APT, como o CyberAv3ngers, ligado ao Irã, continuam com a intenção de causar pânico e medo em relação à segurança cibernética de infraestruturas críticas e têm o desejo de espalhar propaganda para obter ganhos políticos.
Os ataques visaram dispositivos que operam em instalações de tratamento de água em Israel e nos Estados Unidos e demonstraram o acesso do grupo a esses HMI/PLCs fabricados em Israel. Embora o tratamento e a qualidade da água não tenham sido afetados, o grupo desfigurou os dispositivos da Unitronics, deixando uma mensagem que ameaçava outras tecnologias semelhantes fabricadas em Israel.
O CyberAv3ngers aproveitou o fato de que as séries de produtos Unitronics Vision e Samba não tinham proteção por senha PCOM na época. Os invasores podiam se conectar e controlar os dispositivos remotamente usando o software da estação de trabalho de engenharia VisiLogic da Unitronics para fazer o download de um projeto malicioso para o CLP, desfigurando-o.
Com ataques que afetam centenas de dispositivos em todo o mundo, decidimos pesquisar e desenvolver uma ferramenta que permite aos usuários extrair informações forenses de seus HMI/PLCs Unitronics Vision/Samba. As informações extraídas de nossa ferramenta, uma das duas que estamos disponibilizando gratuitamente hoje em nossa página do GitHub, podem ser usadas para identificar os invasores que acessam esses dispositivos, além de extrair informações críticas do dispositivo para ajudar a preservar as informações forenses durante os ataques.
O desenvolvimento de nossas ferramentas exigiu que pesquisássemos e compreendêssemos o protocolo de comunicação PCOM proprietário usado pelos HMI/PLCs Vision/Samba. A única documentação existente sobre o protocolo PCOM foi criada por um conjunto de pesquisadores que analisaram os dispositivos da Unitronics(A Comprehensive Security Analysis of a SCADA Protocol: from OSINT to Mitigation, Luis Rosa et al., 2019).
A primeira ferramenta que desenvolvemos, chamada PCOM2TCP, permite que os usuários convertam mensagens PCOM seriais em mensagens TCP PCOM e vice-versa. A segunda ferramenta, chamada PCOMClient, permite que os usuários se conectem ao seu PLC da série Unitronics Vision/Samba, consultem-no e extraiam informações forenses do PLC.
O primeiro passo para entender o protocolo PCOM e quais artefatos poderiam ser extraídos de um dispositivo Unitronics foi comprar um. Ter um dispositivo físico nos permitia conectar e nos comunicar com ele. Assim, compramos um dispositivo, enviamos para nossos escritórios e esperamos pacientemente para começar nossa pesquisa. No entanto, quando ele finalmente chegou, descobrimos que tínhamos feito uma besteira: nosso dispositivo não tinha uma porta Ethernet. Por padrão, os dispositivos da série Unitronics Vision não são fornecidos com conectividade Ethernet, apenas com conexões seriais; uma placa Ethernet é vendida separadamente. Isso significa que não tínhamos como nos conectar ao nosso dispositivo.
Para resolver esse problema, tivemos que ler a documentação da Unitronics para entender a pinagem do conector RJ11. Para permitir que o CLP se comunique usando serial, a Unitronics implementou uma porta serial usando um conector RJ11 e RS232 como padrão de comunicação. Nosso objetivo era criar um cabo personalizado, conectando o PLC Vision e nosso laptop (usando o conector DB9 do laptop). Na documentação da Unitronics, descobrimos que a porta RJ11 tem o seguinte layout:
Com essa pinagem em mente, nosso objetivo era pegar um cabo RJ11 e modificá-lo para ter uma conexão DB9 (macho) na outra extremidade, permitindo que nos conectássemos ao PLC usando o lado RJ11 e ao nosso laptop usando a conexão DB9. Mais uma vez, procuramos na Internet a documentação sobre a pinagem DB9, que tem a seguinte aparência:
Depois de observar as duas pinagens, tudo o que tivemos de fazer foi conectar o pino RX ao TX e vice-versa, bem como conectar o cabo de aterramento, que tinha a seguinte aparência:
Ao criar esse cabo personalizado, conseguimos criar uma configuração totalmente funcional, conectando o Unitronics V570 ao nosso laptop de laboratório.
Com isso, conseguimos nos conectar ao nosso CLP usando a estação de trabalho de engenharia VisiLogic (EWS) da Unitronics. Fizemos o download do EWS no site da Unitronics, o instalamos e o conectamos ao nosso CLP.
Em seguida, nosso objetivo era criar uma configuração man-in-the-middle (MiTM) entre o PLC e nosso EWS. Isso significava que poderíamos grampear todo o tráfego entre esses dois endpoints, bem como modificar qualquer pacote que escolhêssemos. No entanto, como usamos nosso cabo personalizado e não uma placa de extensão Ethernet, nosso EWS e o PLC se comunicaram por meio de uma conexão serial. Normalmente, isso não é um problema porque o Wireshark oferece a capacidade de detectar a comunicação serial. No entanto, nesse caso específico, isso não foi possível, pois o EWS abriu a porta serial em um modo exclusivo no Windows, o que significa que nenhum outro processo pode abrir essa porta. Por esse motivo, o Wireshark não conseguia se conectar e farejar essa porta. Isso nos levou a desenvolver nossa primeira ferramenta PCOM2TCP para contornar essa restrição.
O protocolo de comunicação PCOM permite que o Visilogic EWS se conecte ao PLC usando um dos dois métodos de conexão: serial ou Ethernet. Para isso, a Unitronics implementou o protocolo PCOM na versão serial ou TCP (usando TCP/20256). Em ambos os casos, a camada PCOM básica existe, a única diferença é que, na conexão TCP, o pacote PCOM básico é encapsulado com a camada PCOM/TCP.
Isso nos deu uma ideia: se não pudéssemos criar uma configuração MiTM usando uma conexão serial, talvez pudéssemos criar uma ferramenta Python que convertesse as mensagens seriais PCOM em pacotes PCOM/TCP. Dessa forma, nosso EWS se conectaria ao nosso script Python usando TCP/IP, em vez de serial, e converteríamos os pacotes em PCOM serial e os enviaríamos ao PLC. Em seguida, poderíamos farejar e monitorar o tráfego usando o Wireshark (procurando o fluxo TCP/IP TCP) e modificar determinados pacotes em nosso script Python.
Esse foi um grande marco para nossa pesquisa, pois nos permitiu finalmente começar a depurar e tentar analisar o tráfego PCOM.
Em sua essência, o protocolo PCOM é composto de solicitações enviadas pelo EWS e respostas enviadas pelo PLC. Para diferenciar os diferentes comandos/procedimentos, o PCOM implementa um amplo conjunto de códigos de função (opcodes), cada um com seus próprios recursos e parâmetros. Dessa forma, usando diferentes opcodes, o EWS pode invocar diferentes solicitações e procedimentos no PLC.
Além dos diferentes códigos de função (opcodes), a Unitronics implementou dois protocolos diferentes como parte do protocolo PCOM: PCOM ASCII e PCOM Binary. Esses dois protocolos implementam opcodes diferentes, o que significa que, para entender completamente o protocolo PCOM, será necessário pesquisar as duas implementações. Vamos analisar cada uma delas:
Primeiro, vamos dar uma olhada em uma solicitação/resposta PCOM Binary. Nesse protocolo, cada pacote deve começar com uma sequência de bytes mágica/codificada, que é a string /_OPLC seguido de um ID, alguns parâmetros reservados e o próprio opcode. A estrutura completa da mensagem PCOM binária pode ser vista aqui:
Para verificar se uma determinada mensagem é uma solicitação ou uma resposta, é preciso verificar o bit mais significativo (MSB) do código de operação; se for 0, a mensagem é uma solicitação e, se for 1, a mensagem é uma resposta.
Ao analisar o formato de mensagem ASCII do PCOM, vemos a seguinte estrutura:
Ao contrário do PCOM Binary, que, para ver se uma mensagem é uma solicitação ou uma resposta, você precisava verificar o opcode do comando (nesse caso - Código de comando), no PCOM ASCII, uma solicitação e uma resposta têm mágicas diferentes. No caso de uma solicitação, a mágica / será usado e, se a mensagem for uma resposta, a mágica /a será usado.
Depois de entender os fundamentos do protocolo PCOM, passamos a criar um cliente PCOM básico, pesquisando e descobrindo códigos operacionais desconhecidos no processo.
A próxima etapa de nossa pesquisa foi a implementação de um cliente PCOM completo, o que nos permitiu construir sobre ele quaisquer códigos/processos de função que escolhêssemos. Isso nos deu a capacidade de testar diferentes códigos operacionais, depurar o aplicativo e tentar entender códigos operacionais não documentados.
Nosso cliente permite que os usuários se conectem ao PLC da Unitronics, extraiam a versão exata, o nome e o tipo, além de ler/gravar a memória bruta. Além de toda a funcionalidade básica, acrescentamos uma interface para adicionar códigos operacionais recém-descobertos.
Nos bastidores, para se comunicar com o PLC, a Unitronics implementou dezenas de códigos de função diferentes, cada um invocando diferentes funcionalidades dentro do PLC. Por exemplo, para solicitar que o CLP repita seu nome, seria necessário enviar uma solicitação PCOM Binary usando o código 0x0C código de função. Alguns opcodes já foram pesquisados e documentados por pesquisadores que já haviam analisado o protocolo PCOM da Unitronics (Uma análise de segurança abrangente de um protocolo SCADA: do OSINT à mitigação, Luis Rosa et al., 2019).
Para criar nosso cliente, tivemos que pesquisar e entender os diferentes códigos de função implementados pela Unitronics. Esse processo foi feito usando principalmente a engenharia reversa, bem como a análise de protocolo dos pacotes do Wireshark que conseguimos capturar.
Outro opcode interessante é 0x42que permite aos usuários redefinir o Carregar senha mecanismo. No manual do usuário da Unitronics, descobrimos que os operadores podem configurar uma senha para proteger seu projeto. Os operadores podem usar essa senha para bloquear projetos e impedir que outras pessoas os leiam. Descobrimos que esse opcode pode ser usado de uma determinada maneira para redefinir o Carregar senhae relatou esse problema à Unitronics, que foi designada como CVE-2024-38434. Essa é uma das duas vulnerabilidades descobertas durante nossa pesquisa e divulgadas ao fornecedor.
Aqui está uma lista de códigos de função conhecidos no protocolo PCOM (observação importante: as descrições que escolhemos para dar a cada código de operação são simplesmente nossa interpretação do código de operação):
Código de função (solicitação/resposta) | Descrição |
0x01 / 0x81 | Ler memória |
0x02 / 0x82 | Verificar senha |
0x0C / 0x8C | Obter nome do PLC |
0x10 / 0x90 | Localizar recurso |
0x16 / 0x96 | Traduzir o índice de recursos para o endereço* |
0x1A / 0x9A | Limpar buffer de memória |
0x41 / 0xC1 | Memória de gravação |
0x42 / 0xC2 | Redefinição da senha de upload (CVE-2024-38434) |
0x4D / 0xCD | Operando de leitura |
0xFF | Erro |
ID (ASCII) | Obter ID do PLC |
UG (ASCII) | Obter o UnitID do PLC |
GF (ASCII) | Obter versão do PLC |
Depois de ter uma boa compreensão do ecossistema da série Unitronics VIsion, bem como do protocolo de comunicação PCOM, voltamos ao nosso objetivo original: permitir a extração de evidências forenses de um PLC atacado. Depois de mais algumas pesquisas, descobrimos dois métodos que permitem a extração de evidências forenses, que acreditamos que poderiam ser usadas para entender melhor o ataque, além de conter informações confidenciais sobre o dispositivo e as operações realizadas no dispositivo.
A primeira fonte de evidência que descobrimos foi o arquivo de projeto do VisiLogic. Sempre que um engenheiro usa o VisiLogic (Unitronics EWS) para se conectar ao PLC Vision, ele começa criando um projeto. Em seguida, usando esse projeto, o engenheiro pode configurar o PLC, sua operação, funções, bem como a tela HMI. Usando esse projeto, o engenheiro pode controlar totalmente o Vision PLC.
Nos bastidores, para salvar todas essas configurações, bem como o código das funções, o EWS armazena todos esses dados em um arquivo zip, contendo um banco de dados Access DB (na memória do PLC, esse arquivo é armazenado em um formato criptografado usando uma senha codificada). Ao analisar esse banco de dados (usando nosso analisador python do Access DB) e pesquisar campos específicos em tabelas específicas, é possível extrair muitos dados interessantes e informações forenses sobre o computador e a configuração do usuário, incluindo o caminho completo em que o projeto foi criado (geralmente contém o nome de usuário do computador), o layout do teclado do invasor (foi usado no passado para identificar invasores, ou seja, usado pela Mandiant para identificar o APT-1), o registro completo de todas as conexões feitas com o CLP e muito mais.
Embora o arquivo de projeto contenha uma grande quantidade de informações forenses, o arquivo em si nem sempre é armazenado no PLC. No ecossistema da Unitronics, ao fazer o download de um projeto em um PLC, é possível escolher se o arquivo de projeto deveser"gravado". No ecossistema da Unitronics, a "gravação do projeto" é uma configuração durante o procedimento de download, que determina se o arquivo do projeto será baixado para o PLC e estará disponível para upload posteriormente. Basicamente, se um projeto for baixado para o PLC sem ser gravado, os usuários não poderão executar um procedimento de upload e recuperar o projeto do PLC posteriormente. Esse mecanismo foi criado para permitir que os engenheiros "protejam" seus projetos e evitar que pessoas com acesso ao próprio CLP simplesmente façam o upload e tenham acesso ao projeto.
Outro mecanismo de proteção que a Unitronics implementou para permitir que os engenheiros protejam seus projetos é a capacidade de configurar uma "senha de upload", bloqueando a capacidade de executar um procedimento de upload somente para aqueles que conhecem a senha que foi configurada. Embora tenhamos conseguido encontrar uma maneira de contornar essa senha (contornando a exigência de senha e nos permitindo carregar o projeto sem saber a senha), se o projeto não for gravado, não haverá nada para ler no PLC. Tudo isso foi adicionado ao nosso cliente PCOM personalizado.
No caso do ataque da Unitronics, os atacantes não gravaram o projeto ao executar o procedimento de download. Isso significava que não podíamos obter o projeto do invasor, mas nossa ferramenta ainda era capaz de obter acesso ao projeto antigo que foi baixado para o PLC (antes de os invasores o substituírem), somente se ele fosse gravado.
Depois de chegar a um beco sem saída com o arquivo de projeto, passamos a procurar evidências forenses na própria memória do CLP. Foi quando descobrimos um artefato armazenado no CLP chamado Signature Log (registro de assinatura). Esse registro contém uma lista de todas as interações que os usuários realizaram com o CLP.
A extração desse registro é um processo longo e tedioso, mas conseguimos implementá-lo em nosso PCOMCliente. Usando nosso cliente, qualquer pessoa pode extrair o registro de assinatura de seu PLC.
Dentro do registro de assinatura, podemos encontrar muitas informações forenses superinteressantes, incluindo datas exatas de conexões feitas a um PLC, o caminho completo do projeto que foi baixado para ele, o nome de usuário do computador que se conectou a ele, bem como informações sobre o computador, incluindo seu sistema operacional, layout do teclado etc.
Aqui está uma lista da maioria das evidências forenses que podem ser extraídas de um PLC da série Vision da Unitronics:
Evidência forense | Está dentro da Signature Table | Está dentro do arquivo de projeto |
Caminho do projeto | Sim | Sim |
Nome de usuário do PC | Sim | Não (pode estar no caminho) |
Data de criação do projeto | Não | Sim |
Datas de conexão do PLC | Sim | Sim |
Teclados de computador | Sim | Sim |
Cadeia de conexão do PLC | Sim | Sim |
Imagens do projeto | Não | Sim |
Funções do projeto | Não | Sim |
A extensa pesquisa da Team82 sobre os HMIs/PLCs integrados da Unitronics começou após a divulgação de ataques contra várias instalações de tratamento de água e outras infraestruturas críticas no final do ano passado. Um grupo ligado ao Irã aproveitou a autenticação fraca desses dispositivos para acessá-los e desfigurá-los.
Embora não tenha sido detectado nenhum impacto na qualidade da água, os ataques serviram à intenção do grupo de espalhar o caos e o medo sobre a segurança cibernética da infraestrutura essencial nessas áreas.
Isso nos levou a examinar mais de perto esses incidentes e os sistemas de controle da Unitronics em questão. Ataques direcionados diretamente a sistemas de controle industrial permanecem relativamente raros, portanto, quando há um problema como esse, nossa equipe quer entender o motivo e fornecer soluções que tragam um ecossistema mais seguro.
Ao analisarmos o protocolo proprietário PCOM desenvolvido pela Unitronics para comunicações entre dispositivos e redes, ficou claro que tínhamos que desenvolver nossas próprias ferramentas para não apenas entender o funcionamento interno do protocolo, mas também para ajudar a extrair informações forenses no caso de ataques futuros.
Hoje, disponibilizamos nossas duas ferramentas gratuitamente. O PCOM2TCP permite que os usuários convertam mensagens PCOM seriais em mensagens TCP PCOM e vice-versa. A segunda ferramenta, chamada PCOMClient, permite que os usuários se conectem ao seu PLC da série Unitronics Vision/Samba, consultem-no e extraiam informações forenses do PLC.
As informações que você pode extrair fornecem pistas valiosas sobre o comportamento dos invasores no dispositivo, incluindo datas de conexão, layout do teclado, caminhos do sistema de arquivos e muito mais. Recomendamos aos usuários que façam o download de cada um deles e compreendam seus recursos analíticos e forenses.
