Ataque a redes industriais (Siemens)

Há uma semana, na primeira parte desta postagem, pudemos ter uma visão geral dos PLCs (linguagem e hardware) e algumas vulnerabilidades, bem como uma visão geral das redes industriais associadas, dispositivos de campo, HMIs e DTUs. Agora que já assimilamos esses conceitos sobre redes industriais e seus elementos associados, vamos entrar em detalhes sobre como elas se comunicam.

Esta postagem apresenta uma análise do ambiente do PLC da Siemens, em particular o protocolo de comunicação conhecido como S7CommPlus. Esse protocolo permite a comunicação entre os pontos de extremidade da Siemens, como o TIA Portal (o software de engenharia do fabricante), e os PLCs, como o S7 -1211C, que foi usado para os experimentos realizados por Hui, H., McLaughlin, K. e Sezer, S. A análise usa as ferramentas WinDbg e Scapy. O mecanismo anti-replay usado no protocolo é investigado, incluindo a identificação dos bytes específicos necessários para criar pacotes de rede válidos. A partir da análise experimental, novas explorações são identificadas, incluindo a manipulação de chaves criptográficas.

Em seguida, são demonstradas as explorações que permitem a personificação de uma sessão de comunicação existente, a negação da capacidade de um engenheiro de configurar um PLC, a realização de alterações não autorizadas nos estados do PLC e outras possíveis violações de integridade e disponibilidade. Várias recomendações de atenuação também serão propostas, levando em conta os conceitos vistos acima.

Introdução

A Siemens é um dos principais fornecedores do mundo e, para esta análise, o controlador S7-1211C foi investigado. Como lembramos, o ataque Stuxnet demonstrou como os PLCs comprometidos poderiam causar um impacto físico. O worm se espalhou primeiro a partir de uma unidade removível dentro de uma usina de enriquecimento de urânio no Irã e infectou uma máquina na rede "com air-gap"Em seguida, o worm se espalhou pela rede usando quatro vulnerabilidades zero day e assinaturas digitais de duas empresas legítimas. Além dos sofisticados mecanismos de infecção e propagação usados pelo Stuxnet, um aspecto importante do ponto de vista do ICS foi o fato de ele ter como alvo apenas alguns modelos específicos de PLC, ou seja, os Siemens S7 315 e 417, que eram usados para controlar as centrífugas no processo de enriquecimento. O Stuxnet determinava se o alvo era um PLC da Siemens verificando o número do modelo, os detalhes da configuração e baixando o código do programa do dispositivo. Se a verificação falhasse, o Stuxnet não realizava nenhum outro ataque, possivelmente para evitar a detecção de suas ações. Caso contrário, ele atualizava o bloco de ciclo principal do PLC com código malicioso para aumentar a frequência de rotação das centrífugas conectadas a níveis prejudiciais, enquanto enganava o operador injetando dados falsos na HMI. O ataque mudou a forma como o setor encarava a segurança.

Pesquisas relacionadas

A programação ou configuração de um PLC geralmente requer um software proprietário do fabricante. Os dispositivos em uma rede de controle de processos podem se comunicar com os PLCs por meio de conexões seriais ou, mais recentemente, via Ethernet, por meio de protocolos baseados em TCP/IP. Já os protocolos usados durante as operações normais podem ser abertamente padronizados, por exemplo, Modbus TCP, ou específicos do fornecedor.

O gráfico a seguir mostra uma linha do tempo com o lançamento de vários modelos de PLC, juntamente com as vulnerabilidades descobertas e suas exploraçõe e as versões específicas do protocolo.

Beresford demonstrou uma série de ataques ao PLC S7-1200, por exemplo, ataque de repetição, desvio de autenticação, inicialização ou parada de um PLC etc. O trabalho foi baseado no firmware v2 do PLC, que não inclui nenhum mecanismo de segurança no protocolo de comunicação.

"O PLC inject " explora o protocolo S7Comm (a última geração do protocolo da Siemens, que não inclui um mecanismo anti-replay) e tem a capacidade de adicionar códigos ao ciclo de programa principal de um PLC sem interrupção dos serviços. Também foi demonstrado que era possível introduzir um proxy de rede em um PLC Siemens S7-300 como backdoor para a rede de controle de processos.

Spenneberg demonstrou um ataque semelhante a um worm, chamado PLC Blaster, que pode se espalhar entre PLCs. O worm explora vulnerabilidades no protocolo S7CommPlus e em uma versão mais recente do protocolo com um mecanismo anti-replay. O malware é carregado em um PLC por meio de um cabo Ethernet. O carregamento também inclui bytes de pacotes de rede necessários para programar outros PLCs. Em seguida, o PLC afetado faz uma varredura automática da rede, conecta-se a outros PLCs e tenta carregar o código malicioso para eles.

Em 2017, L. Martín-Liras apresentou uma análise comparativa entre três protocolos proprietários usados por PLCs. Os três protocolos envolvidos são o protocolo S7Comm, o protocolo UMAS (usado por PLCs Modicon) e o protocolo Opto Comm (usado por PLCs Opto). As informações existentes sobre as vulnerabilidades dos protocolos foram investigadas. A análise também investigou a possibilidade de vários ataques aos PLCs, incluindo DoS, alteração de firmware e alteração do programa do usuário, etc. Uma publicação mais recente, feita em 2018 por L. Ghaleb, documentou a pesquisa sobre as vulnerabilidades do protocolo S7 especificamente, que demonstrou um ataque Man-in-the-Middle, modificação de comando e ataque de repetição em um PLC S7-400 usando o protocolo S7Comm.

Em 2018, os autores publicaram um artigo preliminar relacionado à pesquisa que foi usada como referência para esta postagem. Foi demonstrado que era possível realizar um ataque geral à rede, com base em envenenamento por ARP, no PLC S7 -1211C (firmware 4) e no Portal TIA. Os autores também demonstraram que um pacote "S7-ACK" de 7 bytes, "03 00 00 07 02 f0 00", pode ser explorado para sequestro de sessão e ataques DoS.

Em 2019, Biham pesquisou mais a fundo os protocolos S7 da Siemens e demonstrou ataques para reprogramar os PLCs S7, que foram denominados Rogue7.

Protocolo S7Commplus

O protocolo S7CommPlus facilita a transferência de informações operacionais e de configuração essenciais, como a lógica do PLC, informações de diagnóstico, detalhes de configuração e valores de blocos de dados entre PLCs e software de engenharia. A imagem a seguir mostra a pilha de protocolos dissecada de um pacote que transporta dados do S7CommPlus, conforme visualizado no Wireshark.


A porta TCP 102 é usada para todas as comunicações do S7. O protocolo é executado em ISO sobre TCP (TPKT) e Protocolo de Transporte Orientado à Conexão (COTP). Se um operador iniciar uma conexão com um PLC a partir do TIA-Portal, ele o fará pressionando o botão "Go online" (Conectar).


Após pressioná-lo internamente, ocorrem as seguintes etapas:

• O gateway TIA transmite um pacote Identify All do Discovery Protocol e Profinet Basic Configuration (PN -DCP) para a rede
• Todos os PLCs ou dispositivos respondem ao Portal TIA com um pacote PN-DCP "Identify OK".
• O TIA Portal inicializa um handshake TCP com o PLC, e o PLC responderá.
• O TIA Gateway e o PLC trocam informações de conexão COTP.
• O TIA Gateway envia o primeiro pacote S7 (solicitação de conexão do TIA).



• O PLC responde com um pacote contendo um desafio anti-replay de 1 byte e 20 bytes.



• O TIA Portal responde com um pacote que contém um byte anti-replay e um array de 132 bytes, que é a resposta anti-replay

(Representação de posições de bytes)

  •O Portal TIA envia pacotes com a ação solicitada para o PLC, juntamente com uma verificação de integridade de 20 bytes em cada pacote

As figuras nos pontos 5 a 7 mostram o TIA Gateway e o PLC trocando pacotes S7 de solicitação, desafio e resposta, nos quais bytes especiais estão envolvidos no processo. Por exemplo 1C9C381. Se algum dos pacotes do S7CommPlus não incluir os bytes anti-replay ou os valores de verificação de integridade corretos, a outra extremidade da conexão enviará um pacote TCP com a flag reset ativada e a sessão será encerrada.

Quando o botão "Go online" (Conectar) no Portal TIA for clicado, uma sessão será iniciada usando o protocolo S7, como no Portal TIA. O operador pode carregar programas personalizados, diagnosticar problemas relacionados ao PLC, visualizar dados em tempo real dos blocos de dados do PLC, configurar a comunicação entre o PLC e outros dispositivos, etc. Durante um período on-line com o PLC S7 -1211C, vários pacotes são enviados ao Portal TIA durante o tempo ocioso, especificando detalhes e o status ao vivo do PLC, por exemplo, tempo de ciclo, uso de memória etc.


Byte Anti-Replay

O protocolo S7CommPlus usa um valor de 1 byte no mecanismo anti-replay, que tem sido usado desde a versão 3 do firmware do S7-1200. Quando o Portal TIA inicia uma conexão com um PLC, o PLC envia um byte de desafio no intervalo de 0x06 a 0x7f. O Portal TIA responderá ao PLC com uma resposta que é calculada pela adição do valor 0x80 ao desafio. Por exemplo, se o desafio do PLC for 0x08, a resposta do Portal TIA seria 0x08 + 0x80 = 0x88, conforme mostrado nos pontos 6 e 7. O desafio está na posição de byte 25 e a resposta está nos bytes 24 e 29 dos respectivos pacotes.

Criptografia no pacote de resposta

Desde a versão 4 do firmware, o pacote de resposta do Portal TIA precisa incluir vários bytes, além do byte único anti-replay discutido acima. Em 2017, Cheng descobriu duas cifras de 16 bytes envolvidas no pacote, em que a segunda cifra depende da primeira. Os dois valores de 16 bytes começam nos bytes 235 e 291 do pacote de resposta S7, conforme mostrado no ponto 7. A primeira criptografia é uma operação XOR, enquanto a segunda é gerada por um algoritmo mais complexo.

Função do pacote "Encryption" (Criptografia)

Depois de enviar o pacote de resposta para o PLC, o Portal TIA começará a enviar bytes relacionados às funções do Portal TIA, que são chamados de "pacotes de função". Todos esses pacotes precisam incluir um valor de "criptografia" de 32 bytes, conforme mostrado no ponto 8. Descobriu-se que essa "criptografia" é uma verificação de integridade fornecida pelo Hash-based Message Authentication Code (HMAC) e está relacionada ao byte anti-replay. Cheng propôs a possibilidade de iniciar e interromper um PLC explorando o protocolo, mas não fornece detalhes que descrevem as vulnerabilidades do protocolo e apenas aponta que a função de verificação de integridade do pacote é uma "cifra". Biham identificou posteriormente o mecanismo subjacente usado no protocolo S7 como um HMAC e descobriu que a chave do HMAC é trocada usando uma troca de chaves do tipo ElGamal elliptic curve.

No entanto, os mecanismos específicos do protocolo não foram descritos, por exemplo, cada campo da resposta anti-replay é vagamente identificado com pseudocódigo, enquanto os detalhes da execução algorítmica estão ausentes. Da mesma forma, na função de cálculo do pacote HMAC, dois conjuntos de HMACs são descobertos com duas chaves diferentes que não foram identificadas anteriormente.

Análise do protocolo S7CommPlus

Foi realizada uma análise manual usando ferramentas como Scapy e WinDbg para examinar a comunicação entre o Gateway TIA e os PLCs durante várias sessões de comunicação diferentes. No primeiro experimento, ao inspecionar manualmente os pacotes, incluindo a manipulação de bytes usando o Scapy, descobriu-se que os bytes rotulados nos pontos 5 a 8 serviam a várias finalidades específicas, que serão explicadas a seguir. Como exemplo, as figuras 5-7 mostram o TIA Gateway e o PLC trocando pacotes S7 de solicitação, desafio e resposta, enquanto a Fig. 8 mostra um "pacote de função" subsequente. Consulte também o ponto 4, que mostra as trocas gerais em uma sessão.

No ponto 5, 1C9C381M indica um número de sessão do servidor que é gerado pelo TIA Portal sempre que uma sessão de comunicação é iniciada. No entanto, esse número pode ser reutilizado e não é verificado pelo PLC. Em 16 2913981 há outro número de sessão, ou número de sessão "PC", que é gerado toda vez que o TIA Portal é aberto (ou seja, na primeira vez que o TIA Portal é aberto ou após a reinicialização do computador, daí o nome número de sessão "PC"). Esse número também pode ser reutilizado.

01 c9 c3 81 é o valor da sessão do servidor repetido diretamente em hexadecimal. O segmento destacado com o ponto, em contraste com outros bytes do mesmo pacote, é significativamente diferente para cada sessão. Parece mais provável que tenha sido gerado por uma função de hash ou pseudo-aleatória. O PLC verifica esses três blocos, os segmentos de 9 bytes e 8 bytes, respectivamente, do ponto 7, e envia imediatamente um pacote TCP com um sinalizador de redefinição se os blocos de bytes não forem os esperados pelo PLC; caso contrário, a comunicação continua. Esses bytes são gerados por um algoritmo específico. Após a resposta do Portal TIA, se a conexão for aceita, o PLC envia um pacote S7CommPlus. O pacote S7CommPlus conterá informações relacionadas às funções fornecidas pelo TIA Portal.

Atacantes sofisticados poderiam identificar esses bytes e usar essas informações para explorar ainda mais o protocolo.

Análise do TIA-Portal

O WinDbg foi usado para realizar uma análise do TIA Portal. Esta seção descreve em resumo o processo realizado durante os experimentos. A função que realiza uma pesquisa de dispositivos acessíveis no TIA Portal foi usada para gerar o tráfego do S7CommPlus.

Diagrama de referência Análise do TIA-Portal

Para apoiar a análise, vários pontos de interrupção foram estabelecidos durante a comunicação entre o software e o PLC. Um processo de análise manual identificou que o array de bytes muda significativamente cada vez que o TIA Portal faz uma solicitação. Esse bloco de 20 bytes não tem relação óbvia com o payload do pacote de solicitação de conexão, conforme confirmado pelo envio exatamente do mesmo pacote de solicitação de conexão para o PLC usando o Scapy.

O primeiro desafio para o analista é identificar a parte do ecossistema a ser visada e o ponto de entrada da análise, para o que são fornecidas algumas dicas a seguir.

Para iniciar a análise, a função de pesquisa do Portal TIA é usada uma vez sem nenhum ponto de interrupção e uma sessão de comunicação completa é gerada (encerrada por um pacote de reinicialização TCP do PLC). Ao iniciar manualmente um ponto de interrupção por meio do WinDbg no software e, em seguida, usar o comando "s" para pesquisar os 20 bytes do PLC na memória, o endereço de memória que contém esse bloco de 20 bytes pode ser identificado. Esse endereço de memória pode ser localizado com uma única pesquisa "s" ou, muitas vezes, apenas a área que armazena todo o pacote de desafio S7 recebido é localizada.

Outra pesquisa deve ser feita usando um ponto de interrupção de acesso e rastreando o endereço específico no qual esse array de 20 bytes é gravado. Uma vez identificado esse endereço, ele não será alterado até que o Portal TIA seja reiniciado. Um ponto de interrupção de acesso, "ponto de interrupção A", deve ser estabelecido nesse endereço. Depois de inicializar outra comunicação S7 usando o TIA Portal, verificou-se que o ponto de interrupção A foi acessado por dois locais diferentes, ambos funções que envolvem a cópia do bloco de 20 bytes para outro endereço. A primeira função copia o endereço apontado pelo ponto de interrupção A, enquanto a segunda função copia os bytes para um endereço específico. Portanto, para uma investigação mais aprofundada, dois outros pontos de interrupção de acesso, o ponto de interrupção B e o ponto de interrupção C, foram estabelecidos para cada um dos dois endereços identificados.

Descobriu-se que o ponto de interrupção B aponta para o endereço do 3º byte e o ponto de interrupção C armazena do 3º ao 18º byte do array de 20 bytes. Descobriu-se que esse valor de 16 bytes (bytes 3 a 18), ou "matriz de desafio", desempenha uma função importante no restante do processo de geração de bytes. Além disso, descobriu-se que os dois locais de memória apontados pelos pontos de interrupção B e C estão envolvidos na geração de bytes para a resposta do S7CommPlus e o pacote de funções, respectivamente.

É nesse ponto que a dll "OMSp_core_managed.dll" aparece pela primeira vez e os endereços apontados pelo ponto de interrupção A, B e C estão dentro do intervalo dessa dll. Durante a análise, foi confirmado que esse módulo, ou dll, é onde ocorre toda a geração dos bytes anti-replay.

Convidamos você a ler Vulnerability Analysis of S7 PLCs: Manipulating the Security Mechanism (Análise de vulnerabilidade de PLCs S7: Manipulação do mecanismo de segurança). O artigo completo sobre a pesquisa na qual esta postagem se baseia e o trabalho detalhado no TIA-Portal podem ser encontrados nas referências.

Ele aborda em detalhes tópicos como:

• Pacote de respostas do TIA Portal S7
• Bytes manipuláveis
• Primeira criptografia
• Segunda criptografia
• Algoritmo de aumento de campo finito
• Algoritmo A480
• Pacotes de recursos do TIA-Portal
• Verificação de integridade

HMAC

Após a troca de pacotes de desafio e resposta S7, os pacotes de função S7 serão enviados. Esses pacotes incluem a finalidade e os detalhes da comunicação e, como visto no ponto 8, é mostrado um dos pacotes que contém informações de controle enviadas pelo TIA Portal. Cada pacote deve incluir os 32 bytes de "criptografia" (como Cheng os chama) antes do payload, conforme mostrado no delineamento de bytes. Nessa análise, descobriu-se que esse bloco de 32 bytes é, na verdade, uma verificação de integridade HMAC para o pacote. Essa verificação de integridade tem duas finalidades: garantir que as cargas úteis não sejam adulteradas e autenticar o remetente (já que as chaves do HMAC são conhecidas apenas pelos hosts envolvidos na conexão). Para gerar esse valor de 32 bytes, foram encontrados dois cálculos de HMAC.

O primeiro é usado para gerar a chave para todos os HMACs subsequentes. O segundo é usado para assinar todos os pacotes de funções. Ambos os HMACs são baseados no mesmo algoritmo de hashing do restante do mecanismo. O gráfico a seguir mostra como os dois HMACs geram os bytes de integridade.


Primeiro HMAC

O cálculo do primeiro HMAC é realizado antes do envio do pacote de resposta S7 ao PLC. O texto simples do HMAC consiste em um valor de 8 bytes e na matriz de desafio de 16 bytes, lida no ponto de interrupção C

Abaixo está um exemplo de pseudocódigo para a geração de 8 bytes, que é essencial para verificar a integridade da função S7. Esse algoritmo não é identificado como um algoritmo padronizado, portanto o pseudocódigo é gerado pela análise do código assembler. Essa análise é instrutiva do ponto de vista da segurança, pois o algoritmo de geração de 8 bytes é uma parte essencial da geração do byte de integridade.


O valor combinado de 24 bytes é então assinado usando uma chave de 24 bytes gerada no setor Ⓕ do diagrama de referência do TIA-Portal. A saída de 32 bytes do HMAC deve ser reduzida a um valor de 24 bytes, que deve ser armazenado e usado como a chave do segundo HMAC.

Segundo HMAC

O segundo HMAC é usado para gerar os bytes de verificação de integridade reais, que são inseridos no pacote de função enviado por ambas as partes. Aqui foi identificado pela primeira vez como a chave do segundo HMAC pode ser o resultado do primeiro HMAC e, além disso, qual parte do payload do pacote de função S7 é usada como entrada do segundo HMAC. O comprimento do pacote de funções nem sempre é o mesmo, mas o HMAC de 32 bytes do pacote sempre começa no 13º byte do pacote. A entrada desse HMAC compreende todos os bytes que seguem o HMAC no pacote, ou seja, do 45º byte em diante, excluindo o rodapé do pacote, que normalmente é os últimos quatro bytes (por exemplo, no ponto 8 é "72 03 00 00" no final do pacote). Como o tamanho de cada pacote e as informações que ele contém podem variar, o tamanho e o conteúdo do rodapé variam de acordo. No entanto, para reproduzir o pacote, considerando que a chave é conhecida, um método simples de tentativa e erro poderia identificar qual byte é necessário como entrada HMAC.

Possíveis participações

A análise acima do protocolo S7CommPlus e do Portal TIA revela a possibilidade de explorar o protocolo e o software. Várias explorações validadas são discutidas a seguir, bem como possíveis ataques adicionais que poderiam ser realizados por um invasor suficientemente motivado para analisar ainda mais as descobertas apresentadas acima e prosseguir com o desenvolvimento de explorações maliciosas.

Alterações não autorizadas no status do PLC

Como todas as ações executadas no Portal TIA são enviadas ao PLC usando o protocolo S7, usando as descobertas desta pesquisa, pode ser possível causar interrupções em vários processos, incluindo: reprogramação de um PLC, alteração do valor de uma variável do PLC, definição da senha de um PLC e alteração do estado do PLC (do estado de funcionamento para o estado de parada e vice-versa). Para fins de demonstração, o escopo do trabalho atual concentrou-se em verificar se é possível alterar remotamente o estado de um PLC, ou seja, parar um PLC em funcionamento. As experiências mostraram que isso pode ser feito usando dois pacotes de função S7, além da resposta anti-replay, que inclui os 132 bytes identificados no item 7.


Esta imagem mostra um dos pacotes de função falsificados necessários para parar um PLC. O pacote falsificado é gerado com base nas descobertas documentadas na seção Análise do TIA-Portal. Com exceção do byte anti-replay (ponto 6), dos bytes de verificação de integridade e do número de sequência, todos os outros bytes são iguais nos dois pacotes (um normal e um falsificado). Vale a pena mencionar novamente que, mesmo em sessões S7 diferentes, todos os bytes anti-reprodução podem ser gerados para qualquer pacote falsificado com base nas mesmas chaves de criptografia e bytes necessários que permanecerão constantes com base nos hashes nas caixas Ⓓ e Ⓔ e Ⓕ no Diagrama de Referência do TIA-Portal.

Conforme mencionado, também é possível reprogramar um PLC usando o protocolo S7. Embora haja um mecanismo integrado de proteção contra cópia, desde que o invasor possa identificar a relação entre o número de série do PLC que é enviado pela lógica do PLC e a própria lógica do PLC, um ataque para reprogramar a lógica pode ser viável.

Comunicação DoS

Além de explorar a funcionalidade normal fornecida pelo Portal TIA, foi demonstrado que as descobertas possibilitam um ataque DOS por meio do envio de pacotes criados que estabelecem e mantêm uma nova sessão S7 em um PLC. Isso impedirá que o Portal TIA se conecte ao PLC. Essa exploração é possível porque o S7-1211C não permitirá que uma nova sessão seja iniciada se já existir uma sessão anterior.

Para implementar essa exploração, supõe-se que não haja nenhuma sessão atual entre o PLC e o Portal TIA. Um host na mesma LAN que o PLC pode iniciar uma conexão TCP com o PLC usando o handshake usual e a troca de pacotes COTP. Ao responder ao pacote de desafio do PLC com um pacote criado contendo os bytes anti-replay apropriados, seguido por pacotes "S7-ACK", o invasor pode impedir uma conexão genuína do Portal TIA. Para manter uma sessão normal, por exemplo, para pedir à outra extremidade que aguarde enquanto um processo está em execução, qualquer conexão final pode responder com esse pacote S7-ACK, aparentemente indefinidamente.

Essa exploração é possível porque o pacote "S7-ACK", "03 00 00 00 07 02 F0 00", não tem funções de verificação de integridade ou anti-reprodução e pode ser usado para responder a qualquer pacote S7. Portanto, a sessão pode ser mantida viva sem que o invasor obtenha nenhuma informação adicional. Embora o PLC continue a executar a lógica pré-programada, não é possível interrompê-lo, reconfigurá-lo ou reprogramá-lo. Uma reinicialização manual pode encerrar a sessão existente, mas um host ou dispositivo comprometido na rede pode reiniciar uma nova sessão do DOS. Esse ataque pode ser crítico por si só, mas também pode permitir um ataque em maior escala.

Sequestro de sessão

A exploração descrita acima pressupõe que não há conexão entre o Portal TI A e o PLC de destino. No entanto, essa exploração poderia ser combinada com um ataque de rede tradicional, usando pacotes de exploração criados juntamente com envenenamento de ARP, para sequestrar uma sessão para o PLC e causar um DOS para que o Portal TIA não possa se reconectar. Os autores já documentaram anteriormente como o sequestro de sessão por meio de envenenamento de ARP pode funcionar nesse contexto. Isso pode ser feito descartando ativamente todos os pacotes do software de engenharia depois de roubar a sessão S7, o que faz com que o lado do Portal TIA da conexão seja encerrado. Ao mesmo tempo, o lado PLC da sessão pode ser mantido vivo por um invasor que cria e envia pacotes S7-ACK. Durante esse ataque, uma opção é usar respostas ARP excessivas para sobrecarregar quaisquer outros pacotes ARP depois que a sessão for roubada. No entanto, para evitar a geração de muito "ruído" ARP, a sessão S7 roubada poderia ser encerrada e substituída por uma nova sessão DOS, conforme descrito na seção anterior. Esse ataque consegue duas coisas:
1) Um "footprint" de rede menor seria gerado em comparação com o roubo de sessão por meio de envenenamento de ARP.
2) É possível realizar o ataque DOS sem esperar que a sessão legítima termine, pois uma sessão DOS não pode ser iniciada mesmo que exista uma legítima.

Eliminação do programa principal

Foi descoberto um novo exploit baseado no protocolo S7CommPlus que pode manipular a lógica do PLC e excluir o bloco Main Object dos PLCs S7 -1200 e, fazendo com que o TIA-Portal forneça informações incompletas ou incorretas sobre o PLC Isso pode ser causado pela reprodução de pacotes S7 capturados em um caso de uso anormal.

A seguir, descrevemos as etapas de repetição da exploração, incluindo a geração de pacotes, a repetição dos pacotes e o comportamento esperado da geração dos pacotes que serão repetidos como a exploração:

• Crie um novo projeto no TIA-Portal e adicione um PLC ao projeto com a versão do firmware do PLC de destino (que pode ser obtida por meio da transmissão LLDP do PLC ou fazendo login no PLC).
• Carregue um projeto padrão (com apenas um bloco de objeto Main vazio) no PLC de teste (um PLC com a mesma versão de firmware que o PLC de destino).
• Certifique-se de que o PLC esteja no estado de desligamento.
• Exclua o bloco do objeto principal no projeto e inicie uma captura de dados, ume, em seguida, carregue o projeto com a opção "Software (changes)" a captura depois que o PLC encerrar a sessão usando um pacote TCP com os sinalizadores Reset e Finish definidos .
• Extraia o pacote inteiro enviado pelo TIA-Portal para uso no script, que foi enviado na comunicação anterior

O envio (repetição) desses pacotes capturados a um PLC de destino, que tenha a mesma versão de firmware e que esteja no estado de parada, causará comportamentos anormais. Os pacotes capturados de firmware diferente causarão comportamentos diferentes em uma versão de firmware diferente. Essa exploração foi testada no S7-1211C DC/DC/DC, versões de firmware v4.1.3 e v.4.2.3.

Para a versão 4.1.3, a captura pode ser reproduzida como está, e o PLC reiniciará a conexão depois que os pacotes criados forem enviados aos PLCs. A exploração pode ter os seguintes comportamentos, dependendo da configuração e do estado do PLC:

• Ao se conectar ao PLC infectado, o PLC não pode ser colocado em um estado de execução. Se um usuário tentar fazer o download do código personalizado do TIA-Portal para o PLC, o portal indicará que o programa entre o PLC e o PLC é o mesmo, sem exibir nenhum erro. No entanto, o PLC está sendo executado sem o Main Object Block, ou seja, ele não executa nenhuma ação. Uma possível solução é desconectar e fazer o download das configurações completas para o PLC usando a opção de download "Hardware and Software (changes only)". Uma janela para sincronizar o programa será exibida antes do download, mostrando que há diferenças entre a lógica no PLC e o projeto no Portal TIA.
• Quando conectado, o PLC não pode ser colocado em estado de execução. Se um usuário tentar fazer o download do código personalizado para o PLC, uma janela de sincronização será exibida antes do download. Além disso, não será exibido nenhum erro ou um erro dizendo "O bloco do objeto principal não existe"
• Quando conectado, o PLC pode ser colocado em um estado de execução. No entanto, nenhuma lógica será de fato executada no PLC, e todos os blocos de programa serão mostrados como "só existem off-line" no TIA-Portal. É necessário sincronizar antes de fazer o download.

O usuário pode colocar o PLC no estado de execução. Entretanto, nenhuma lógica será executada no bloco de objeto principal, mas a interrupção cíclica ou a interrupção de hardware ainda poderá ser executada. Se o usuário tentar ativar o "monitoramento" no bloco de objeto principal enquanto estiver on-line (uma opção do TIA-Portal que fornece informações de diagnóstico do PLC em tempo real), o erro "Internal system error (error code:0xCF000AF0700008002)..." será exibido. Internal error: Referenced UnFunctionalObject does not exist" (Erro interno: o UnFunctionalObject referenciado não existe). ".

Uma possível solução é fazer o download do projeto para o PLC, e será necessária a sincronização manual do programa personalizado.

Durante os testes, em duas ocasiões o PLC entrou em um estado irrecuperável depois que várias capturas foram repetidamente reproduzidas no dispositivo. A única solução viável para essa situação é uma redefinição de fábrica.

Infelizmente, não foram feitas capturas de tela das sequências exatas de pacotes necessárias, pois o comportamento parece ser um tanto aleatório e imprevisível.

Recomendações

Como vimos, pelo menos dois hashes desempenham uma função importante no mecanismo anti-replay. Foi descoberto que a entrada desses hashes poderia ser manipulada modificando a memória usada pelo software. Essa vulnerabilidade permite que um invasor gere uma sessão S7 que exija apenas 17 dos 150 bytes "anti-replay" do pacote de resposta do S7CommPlus, em vez de 150 bytes (os blocos de 132 bytes, 8 bytes e 9 bytes, mais o byte anti-replay). Além disso, todas as chaves envolvidas, seja para a primeira cifra e a segunda cifra, seja para os HMACs nos pacotes de funções, permanecem constantes em relação aos hashes de entrada. Esses dois problemas reduzem significativamente a possível segurança fornecida pelo algoritmo, bem como o aparente desperdício de recursos. Em curto prazo, a adoção das medidas de segurança propostas abaixo poderia limitar a capacidade de um invasor de realizar explorações semelhantes sem alterações significativas no projeto.

Alterar a entrada do algoritmo de hash

Alguns bytes trocados entre o TIA Gateway e um PLC não são usados, nem há um impacto óbvio desses bytes na comunicação. Considere as seguintes constatações:

• A sessão do servidor e a sessão do PC, identificadas no item 5, parecem não ter nenhuma finalidade no protocolo e podem ser reutilizadas em sessões diferentes, o que anula a finalidade de um número de sessão.
• Foi demonstrado que a "matriz de desafio" de 16 bytes no desafio de 20 bytes enviado pelo PLC desempenha uma função importante no mecanismo anti-replay. Entretanto, não se descobriu que os 4 bytes restantes influenciam o mecanismo anti-replay.
• No pacote de resposta do TIA-Portal S7, os bytes marcados no ponto 7 são gerados antes do valor de 132 bytes No entanto, eles permanecem constantes com relação aos dois valores de hash e não foi descoberta nenhuma relação com o mecanismo anti-replay.

Dessa forma, propõe-se que uma opção para limitar a capacidade de um invasor de gerar um pacote S7 viável seja incluir alguns dos bytes acima no mecanismo anti-replay. Por exemplo, sugere-se incluir a sessão do servidor e os quatro bytes restantes do array de desafio no algoritmo de hash que gera as chaves de criptografia, juntamente com um breve histórico do array de desafio como parte da entrada para gerar os bytes anti-replay. Isso não resolverá a ameaça de um invasor que use técnicas de engenharia reversa no software para obter a entrada e o algoritmo usados no mecanismo anti-replay, mas qualquer pessoa que tente fazer isso precisará gerar os 150 bytes anti-replay completos, incluindo a determinação das chaves em cada ataque, e conseguirá obter sessões de comunicação anteriores do Portal TIA.

Limite a duração da sessão

Durante a análise, verificou-se que uma sessão TCP permanecerá ativa até que o Portal TIA encerre a comunicação, não reconheça os pacotes TCP keep alive ou os pacotes S7 enviados pelo PLC ou envie os bytes anti-replay errados. Por exemplo, se um ponto de interrupção for definido no TIA Portal durante a comunicação com o PLC, os pacotes legítimos do S7CommPlus não serão mais enviados.

Nesse meio tempo, o PLC enviará periodicamente pacotes TCP keep alive e não encerrará a comunicação enquanto o Portal TIA responder com o pacote TCP keep alive. Isso aumenta o tempo disponível para qualquer possível invasor realizar uma análise mais profunda em cada estágio da comunicação.

Além disso, o pacote S7 -ACK pode ser explorado para realizar um ataque de negação de serviço, por meio da exaustão de recursos, pois a quantidade de recursos dedicados à comunicação em um PLC é limitada.

Uma possível atenuação seria uma atualização do firmware do PLC para garantir que os PLCs se desconectem de uma sessão S7 inativa (uma sessão que contém apenas pacotes S7 -ACK) ou depois de não receberem nenhum pacote S7 legítimo após um determinado período de tempo, a menos que o operador configure o PLC de outra forma.

Outras recomendações

A seguir, algumas recomendações para manter o PLC protegido contra ameaças ou, pelo menos, mitigar os riscos, levando em conta o que vimos neste post e em sua primeira parte:

• Segurança em primeiro lugar: como os setores consideram a segurança como um fator importante ao projetar, atualizar ou operar qualquer PLC, a segurança deve ser primordial. Isso deve levar em conta o hardware, o software e as redes. As empresas devem desenvolver uma avaliação de risco, respostas e padronizações mais detalhadas antes de implementar qualquer projeto de PLC. Um exemplo pode ser: não considerar uma atualização de firmware de um PLC antigo porque não há parada planejada da linha de produção.
• A segurança cibernética é responsabilidade de todos. Todos os funcionários devem estar sempre atentos e preocupados com a segurança. Os funcionários devem relatar imediatamente qualquer prática insegura, dispositivo inseguro ou comportamento suspeito.
• Funções e autenticação: os privilégios de acesso a informações e dispositivos devem ser adequadamente restritos e bem considerados antes de serem atribuídos aos funcionários. Os privilégios devem ser bem validados, controlados, registrados e monitorados (use IDs exclusivos ou credenciais de acesso). As atividades não autorizadas ou não monitoradas devem ser evitadas ou, pelo menos, minimizadas. Os usuários devem ter acesso apenas ao seu trabalho e às tarefas diárias relacionadas. A revisão automática de registros e o monitoramento de usuários também podem ajudar.
• Revisão e comparação diárias: como as empresas estão tão preocupadas com a segurança antes e durante a operação das linhas de produção, elas precisam se preocupar mais com a integridade dos arquivos executados nos PLCs e HMIs. Isso deve ser feito usando uma ferramenta de software que compare a lógica ladder com o arquivo mestre original confiável antes de iniciar novas linhas de produção. Sempre existe a possibilidade de alguém sabotar a lógica ou criar um malware inativo no código da lógica ladder que não é detectado.
• Acesso remoto e IoT (Internet das Coisas): deve ser restrito a determinados dispositivos, áreas ou, às vezes, desativado. Se necessário, deve ser ativado apenas por um tempo limitado e usado por pessoal interno treinado a partir de um dispositivo aprovado, monitorado e controlado; todas as comunicações devem ser filtradas e verificadas. Os sistemas ou dispositivos que não precisam ser conectados a outras redes, inclusive à Internet, devem ser adequadamente segregados e isolados para evitar qualquer ameaça.
• As portas USB devem ser fisicamente desativadas nas HMIs (interfaces homem-máquina) e em todos os PCs associados. Somente USBs autenticados e aprovados devem poder ser usados pelos administradores. Malwares como o Stuxnet se espalham por uma rede SCADA por meio de dispositivos de armazenamento USB infectados.
• Registro do sistema: deve ser gerado e mantido por um período razoável, caso seja necessário se algo der errado.
• Auditoria periódica do sistema e testes periódicos de penetração.
• Detecção de intrusão do sistema: que também deve incluir a proteção "tradicional" do perímetro (por exemplo, antivírus, firewalls etc.). Eles devem ser mantidos sempre atualizados e ativados.
• Os PLCs em geral devem ser fisicamente robustos e seguros. Não se concentre apenas na proteção de determinados dispositivos de campo. A proteção de todo o sistema é fundamental e obrigatória.

Conclusão

Nesta série de postagens, apresentamos uma visão geral dos PLCs: suas linguagens e hardware, bem como uma visão geral das redes industriais associadas a eles, HMIs e DTUs. Resumimos as principais vulnerabilidades dos dispositivos baseados nesses dispositivos e também demos exemplos baseados em outras pesquisas sobre como aplicar explorações a essas vulnerabilidades. Usando o protocolo S7CommPlus, foi demonstrado que um invasor com acesso à rede pode enviar pacotes a um PLC, ler um desafio, calcular a resposta e criar verificações de integridade nos pacotes subsequentes para manter uma sessão válida. Isso permite que um invasor crie pacotes que serão aceitos pelo PLC, por exemplo, para fazer com que um PLC pare, inicie a lógica da CPU que tenha sido interrompida anteriormente por um usuário legítimo, sequestre uma sessão legítima existente entre um PLC e o Portal TIA (mostrado para causar um DOS) e, potencialmente, outros problemas, como reprogramar a CPU.

Em comparação com o artigo de Cheng “The spear to break the security wall of S7CommPlus" (A lança para quebrar a barreira de segurança do S7CommPlus), ”esta pesquisa fornece uma análise mais detalhada que descreve o mecanismo anti-replay do protocolo S7CommPlus, incluindo novas informações sobre as duas criptografias de chave simétrica envolvidas no bloco de 132 bytes e o HMAC nos pacotes de funções.
Além disso, são fornecidos novos conhecimentos sobre a geração de bytes anti-replay, incluindo detalhes dos algoritmos usados e como manipular as chaves geradas.
Enquanto isso, os autores desses artigos propuseram uma série de novas etapas de atenuação que não haviam sido propostas anteriormente em pesquisas relacionadas. Essas etapas podem ser adotadas para tornar essas explorações mais difíceis de serem descobertas e executadas por um invasor determinado, ou seja, adotando uma abordagem de tempo limite para atenuar o potencial DOS e alterando a maneira como o algoritmo de hash é implementado para garantir que a manipulação das funções do Portal TIA seja mais difícil de ser realizada por um invasor. Assim como ocorre com a pesquisa de segurança cibernética em outros campos, os autores esperam que as informações fornecidas sobre a realização dessa varredura de vulnerabilidades forneçam à comunidade de pesquisa uma visão mais profunda sobre a compreensão das abordagens dos invasores e estratégias viáveis de atenuação.

Lecturas de Interés:

• https://claroty.com/team82/research/white-papers/evil-plc-attack-weaponizing-plcs
• Peter M. D. Scully Mark J. Neal “Positional: A Collaborative Host-based Architecture for Securing Industrial Networks” Department of Computer Science, Aberystwyth University, Wales, United Kingdom
• Yong Wang, Jinyong Liu, Can Yang, Lin Zhou, Shuangfei Li, Zhaoyan Xu “Access Control Attacks on PLC Vulnerabilities”Department of Information Security, Shanghai University of Electric Power, Shanghai, China & Palo Alto Networks, California, CA, USA
• https://www.youtube.com/watch?v=93lyRgZYxKw
• https://youtu.be/ocOEiNp-8K0