{"id":5154,"date":"2023-05-02T16:35:20","date_gmt":"2023-05-02T19:35:20","guid":{"rendered":"https:\/\/base4sec.com\/nao-categorizado\/atacando-redes-industriales-siemens\/"},"modified":"2025-02-26T08:25:56","modified_gmt":"2025-02-26T11:25:56","slug":"atacando-redes-industriales-siemens","status":"publish","type":"post","link":"https:\/\/base4sec.com\/pt-br\/technical-pt-br\/atacando-redes-industriales-siemens\/2023\/05\/02\/","title":{"rendered":"Ataque a redes industriais (Siemens)"},"content":{"rendered":"
\n

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

Esta postagem apresenta uma an\u00e1lise do ambiente do PLC da Siemens, em particular o protocolo de comunica\u00e7\u00e3o conhecido como\u00a0S7CommPlus<\/b>. Esse protocolo permite a comunica\u00e7\u00e3o 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\u00e1lise usa as ferramentas\u00a0WinDbg<\/b>\u00a0e\u00a0Scapy<\/b>. O mecanismo anti-replay usado no protocolo \u00e9 investigado, incluindo a identifica\u00e7\u00e3o dos bytes espec\u00edficos necess\u00e1rios para criar pacotes de rede v\u00e1lidos. A partir da an\u00e1lise experimental, novas explora\u00e7\u00f5es s\u00e3o identificadas, incluindo a manipula\u00e7\u00e3o de chaves criptogr\u00e1ficas.<\/p>\n

Em seguida, s\u00e3o demonstradas as explora\u00e7\u00f5es que permitem a personifica\u00e7\u00e3o de uma sess\u00e3o de comunica\u00e7\u00e3o existente, a nega\u00e7\u00e3o da capacidade de um engenheiro de configurar um PLC, a realiza\u00e7\u00e3o de altera\u00e7\u00f5es n\u00e3o autorizadas nos estados do PLC e outras poss\u00edveis viola\u00e7\u00f5es de integridade e disponibilidade. V\u00e1rias recomenda\u00e7\u00f5es de atenua\u00e7\u00e3o tamb\u00e9m ser\u00e3o propostas, levando em conta os conceitos vistos acima.<\/p>\n

Introdu\u00e7\u00e3o<\/span><\/p>\n

A Siemens \u00e9 um dos principais fornecedores do mundo e, para esta an\u00e1lise, o controlador S7-1211C foi investigado. Como lembramos, o ataque\u00a0Stuxnet<\/b>\u00a0demonstrou como os PLCs comprometidos poderiam causar um impacto f\u00edsico. O worm se espalhou primeiro a partir de uma unidade remov\u00edvel dentro de uma usina de enriquecimento de ur\u00e2nio no Ir\u00e3 e infectou uma m\u00e1quina na rede “com air-gap<\/b>“Em seguida, o worm se espalhou pela rede usando quatro vulnerabilidades zero day e assinaturas digitais de duas empresas leg\u00edtimas. Al\u00e9m dos sofisticados mecanismos de infec\u00e7\u00e3o e propaga\u00e7\u00e3o usados pelo Stuxnet, um aspecto importante do ponto de vista do ICS foi o fato de ele ter como alvo apenas alguns modelos espec\u00edficos de PLC, ou seja, os Siemens S7 315 e 417, que eram usados para controlar as centr\u00edfugas no processo de enriquecimento. O Stuxnet determinava se o alvo era um PLC da Siemens verificando o n\u00famero do modelo, os detalhes da configura\u00e7\u00e3o e baixando o c\u00f3digo do programa do dispositivo. Se a verifica\u00e7\u00e3o falhasse, o Stuxnet n\u00e3o realizava nenhum outro ataque, possivelmente para evitar a detec\u00e7\u00e3o de suas a\u00e7\u00f5es. Caso contr\u00e1rio, ele atualizava o bloco de ciclo principal do PLC com c\u00f3digo malicioso para aumentar a frequ\u00eancia de rota\u00e7\u00e3o das centr\u00edfugas conectadas a n\u00edveis prejudiciais, enquanto enganava o operador injetando dados falsos na HMI. O ataque mudou a forma como o setor encarava a seguran\u00e7a.<\/p>\n

Pesquisas relacionadas<\/span><\/p>\n

A programa\u00e7\u00e3o ou configura\u00e7\u00e3o de um PLC geralmente requer um software propriet\u00e1rio do fabricante. Os dispositivos em uma rede de controle de processos podem se comunicar com os PLCs por meio de conex\u00f5es seriais ou, mais recentemente, via Ethernet, por meio de protocolos baseados em TCP\/IP. J\u00e1 os protocolos usados durante as opera\u00e7\u00f5es normais podem ser abertamente padronizados, por exemplo, Modbus TCP, ou espec\u00edficos do fornecedor.<\/p>\n

O gr\u00e1fico a seguir mostra uma linha do tempo com o lan\u00e7amento de v\u00e1rios modelos de PLC, juntamente com as\u00a0vulnerabilidades<\/b>\u00a0descobertas e suas\u00a0explora\u00e7\u00f5e<\/b>\u00a0e as vers\u00f5es espec\u00edficas do protocolo.<\/p>\n

\"imagen<\/center>Beresford<\/b>\u00a0demonstrou uma s\u00e9rie de ataques ao PLC S7-1200, por exemplo, ataque de repeti\u00e7\u00e3o, desvio de autentica\u00e7\u00e3o, inicializa\u00e7\u00e3o ou parada de um PLC etc. O trabalho foi baseado no firmware v2 do PLC, que n\u00e3o inclui nenhum mecanismo de seguran\u00e7a no protocolo de comunica\u00e7\u00e3o.<\/p>\n

“O PLC inject ”\u00a0<\/b>explora o protocolo S7Comm (a \u00faltima gera\u00e7\u00e3o do protocolo da Siemens, que n\u00e3o inclui um mecanismo anti-replay) e tem a capacidade de adicionar c\u00f3digos ao ciclo de programa principal de um PLC sem interrup\u00e7\u00e3o dos servi\u00e7os. Tamb\u00e9m foi demonstrado que era poss\u00edvel introduzir um proxy de rede em um PLC Siemens S7-300 como backdoor para a rede de controle de processos.<\/p>\n

Spenneberg demonstrou um ataque semelhante a um worm, chamado\u00a0PLC Blaster<\/b>, que pode se espalhar entre PLCs. O worm explora vulnerabilidades no protocolo S7CommPlus e em uma vers\u00e3o mais recente do protocolo com um mecanismo anti-replay. O malware \u00e9 carregado em um PLC por meio de um cabo Ethernet. O carregamento tamb\u00e9m inclui bytes de pacotes de rede necess\u00e1rios para programar outros PLCs. Em seguida, o PLC afetado faz uma varredura autom\u00e1tica da rede, conecta-se a outros PLCs e tenta carregar o c\u00f3digo malicioso para eles.<\/p>\n

Em 2017, L. Mart\u00edn-Liras apresentou uma an\u00e1lise comparativa entre tr\u00eas protocolos propriet\u00e1rios usados por PLCs. Os tr\u00eas protocolos envolvidos s\u00e3o o protocolo S7Comm, o protocolo UMAS (usado por PLCs Modicon) e o protocolo Opto Comm (usado por PLCs Opto). As informa\u00e7\u00f5es existentes sobre as vulnerabilidades dos protocolos foram investigadas. A an\u00e1lise tamb\u00e9m investigou a possibilidade de v\u00e1rios ataques aos PLCs, incluindo DoS, altera\u00e7\u00e3o de firmware e altera\u00e7\u00e3o do programa do usu\u00e1rio, etc. Uma publica\u00e7\u00e3o mais recente, feita em 2018 por L. Ghaleb, documentou a pesquisa sobre as vulnerabilidades do protocolo S7 especificamente, que demonstrou um ataque\u00a0Man-in-the-Middle, modifica\u00e7\u00e3o de comando e ataque de repeti\u00e7\u00e3o<\/b>\u00a0em um PLC S7-400 usando o protocolo S7Comm.<\/p>\n

Em 2018, os autores publicaram um artigo preliminar relacionado \u00e0 pesquisa que foi usada como refer\u00eancia para esta postagem. Foi demonstrado que era poss\u00edvel realizar um ataque geral \u00e0 rede, com base em envenenamento por ARP, no PLC S7 -1211C (firmware 4) e no Portal TIA. Os autores tamb\u00e9m demonstraram que um pacote\u00a0“S7-ACK”\u00a0<\/b>de 7 bytes, “03 00 00 07 02 f0 00”, pode ser explorado para sequestro de sess\u00e3o e ataques DoS.<\/p>\n

Em 2019, Biham pesquisou mais a fundo os protocolos S7 da Siemens e demonstrou ataques para reprogramar os PLCs S7, que foram denominados\u00a0Rogue7<\/b>.<\/p>\n

Protocolo S7Commplus<\/span><\/p>\n

O protocolo S7CommPlus facilita a transfer\u00eancia de informa\u00e7\u00f5es operacionais e de configura\u00e7\u00e3o essenciais, como a l\u00f3gica do PLC, informa\u00e7\u00f5es de diagn\u00f3stico, detalhes de configura\u00e7\u00e3o 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.<\/p>\n

\"imagen<\/center><\/p>\n

A porta TCP 102 \u00e9 usada para todas as comunica\u00e7\u00f5es do S7. O protocolo \u00e9 executado em ISO sobre TCP (TPKT) e Protocolo de Transporte Orientado \u00e0 Conex\u00e3o (COTP). Se um operador iniciar uma conex\u00e3o com um PLC a partir do TIA-Portal, ele o far\u00e1 pressionando o bot\u00e3o “Go online” (Conectar).<\/p>\n

\"imagen<\/center><\/p>\n

Ap\u00f3s pression\u00e1-lo internamente, ocorrem as seguintes etapas:<\/b><\/p>\n

    \n
  • \n
      \n
    • O gateway TIA transmite um pacote Identify All do Discovery Protocol e Profinet Basic Configuration (PN -DCP) para a rede<\/li>\n
    • Todos os PLCs ou dispositivos respondem ao Portal TIA com um pacote PN-DCP “Identify OK”.<\/li>\n
    • O TIA Portal inicializa um handshake TCP com o PLC, e o PLC responder\u00e1.<\/li>\n
    • O TIA Gateway e o PLC trocam informa\u00e7\u00f5es de conex\u00e3o COTP.<\/li>\n
    • O TIA Gateway envia o primeiro pacote S7 (solicita\u00e7\u00e3o de conex\u00e3o do TIA).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

      \"imagen<\/center><\/p>\n
        \n
      • \n
          \n
        • O PLC responde com um pacote contendo um desafio anti-replay de 1 byte e 20 bytes.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

          \"imagen<\/center><\/p>\n
            \n
          • \n
              \n
            • O TIA Portal responde com um pacote que cont\u00e9m um byte anti-replay e um array de 132 bytes, que \u00e9 a resposta anti-replay<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n

              \"imagen<\/center>
              (Representa\u00e7\u00e3o de posi\u00e7\u00f5es de bytes)<\/center>\u00a0\u00a0\u2022<\/b>O Portal TIA envia pacotes com a a\u00e7\u00e3o solicitada para o PLC, juntamente com uma verifica\u00e7\u00e3o de integridade de 20 bytes em cada pacote<\/p>\n

              \"imagen<\/center>As figuras nos pontos 5 a 7 mostram o TIA Gateway e o PLC trocando pacotes S7 de solicita\u00e7\u00e3o, desafio e resposta, nos quais bytes especiais est\u00e3o envolvidos no processo. Por exemplo\u00a01C9C381<\/b><\/mark>. Se algum dos pacotes do S7CommPlus n\u00e3o incluir os bytes anti-replay ou os valores de verifica\u00e7\u00e3o de integridade corretos, a outra extremidade da conex\u00e3o enviar\u00e1 um pacote TCP com a flag reset ativada e a sess\u00e3o ser\u00e1 encerrada.<\/p>\n

              Quando o bot\u00e3o “Go online” (Conectar) no Portal TIA for clicado, uma sess\u00e3o ser\u00e1 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\u00e7\u00e3o entre o PLC e outros dispositivos, etc. Durante um per\u00edodo on-line com o PLC S7 -1211C, v\u00e1rios pacotes s\u00e3o 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\u00f3ria etc.<\/p>\n

              \"imagen<\/center><\/p>\n

              Byte Anti-Replay<\/span><\/p>\n

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

              Criptografia no pacote de resposta<\/span><\/p>\n

              Desde a vers\u00e3o 4 do firmware, o pacote de resposta do Portal TIA precisa incluir v\u00e1rios bytes, al\u00e9m do byte \u00fanico 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\u00e7am nos bytes 235 e 291 do pacote de resposta S7, conforme mostrado no ponto 7. A primeira criptografia \u00e9 uma opera\u00e7\u00e3o XOR, enquanto a segunda \u00e9 gerada por um algoritmo mais complexo.<\/p>\n

              Fun\u00e7\u00e3o do pacote “Encryption” (Criptografia)<\/span><\/p>\n

              Depois de enviar o pacote de resposta para o PLC, o Portal TIA come\u00e7ar\u00e1 a enviar bytes relacionados \u00e0s fun\u00e7\u00f5es do Portal TIA, que s\u00e3o chamados de “pacotes de fun\u00e7\u00e3o”. Todos esses pacotes precisam incluir um valor de “criptografia” de 32 bytes, conforme mostrado no ponto 8. Descobriu-se que essa “criptografia” \u00e9 uma verifica\u00e7\u00e3o de integridade fornecida pelo Hash-based Message Authentication Code (HMAC) e est\u00e1 relacionada ao byte anti-replay. Cheng prop\u00f4s a possibilidade de iniciar e interromper um PLC explorando o protocolo, mas n\u00e3o fornece detalhes que descrevem as vulnerabilidades do protocolo e apenas aponta que a fun\u00e7\u00e3o de verifica\u00e7\u00e3o de integridade do pacote \u00e9 uma “cifra”. Biham identificou posteriormente o mecanismo subjacente usado no protocolo S7 como um HMAC e descobriu que a chave do HMAC \u00e9 trocada usando uma troca de chaves do tipo\u00a0ElGamal elliptic curve<\/b>.<\/p>\n

              No entanto, os mecanismos espec\u00edficos do protocolo n\u00e3o foram descritos, por exemplo, cada campo da resposta anti-replay \u00e9 vagamente identificado com pseudoc\u00f3digo, enquanto os detalhes da execu\u00e7\u00e3o algor\u00edtmica est\u00e3o ausentes. Da mesma forma, na fun\u00e7\u00e3o de c\u00e1lculo do pacote HMAC, dois conjuntos de HMACs s\u00e3o descobertos com duas chaves diferentes que n\u00e3o foram identificadas anteriormente.<\/p>\n

              An\u00e1lise do protocolo S7CommPlus<\/span><\/p>\n

              Foi realizada uma an\u00e1lise manual usando ferramentas como Scapy e WinDbg para examinar a comunica\u00e7\u00e3o entre o Gateway TIA e os PLCs durante v\u00e1rias sess\u00f5es de comunica\u00e7\u00e3o diferentes. No primeiro experimento, ao inspecionar manualmente os pacotes, incluindo a manipula\u00e7\u00e3o de bytes usando o Scapy, descobriu-se que os bytes rotulados nos pontos 5 a 8 serviam a v\u00e1rias finalidades espec\u00edficas, que ser\u00e3o explicadas a seguir. Como exemplo, as figuras 5-7 mostram o TIA Gateway e o PLC trocando pacotes S7 de solicita\u00e7\u00e3o, desafio e resposta, enquanto a Fig. 8 mostra um “pacote de fun\u00e7\u00e3o” subsequente. Consulte tamb\u00e9m o ponto 4, que mostra as trocas gerais em uma sess\u00e3o.<\/p>\n

              No ponto 5,\u00a01C9C381M<\/b><\/mark>\u00a0indica um n\u00famero de sess\u00e3o do servidor que \u00e9 gerado pelo TIA Portal sempre que uma sess\u00e3o de comunica\u00e7\u00e3o \u00e9 iniciada. No entanto, esse n\u00famero pode ser reutilizado e n\u00e3o \u00e9 verificado pelo PLC. Em\u00a016 2913981<\/b><\/mark>\u00a0h\u00e1 outro n\u00famero de sess\u00e3o, ou n\u00famero de sess\u00e3o “PC”, que \u00e9 gerado toda vez que o TIA Portal \u00e9 aberto (ou seja, na primeira vez que o TIA Portal \u00e9 aberto ou ap\u00f3s a reinicializa\u00e7\u00e3o do computador, da\u00ed o nome n\u00famero de sess\u00e3o “PC”). Esse n\u00famero tamb\u00e9m pode ser reutilizado.<\/p>\n

              01 c9 c3 81<\/b><\/mark>\u00a0\u00e9 o valor da sess\u00e3o do servidor repetido diretamente em hexadecimal. O segmento destacado com o ponto, em contraste com outros bytes do mesmo pacote, \u00e9 significativamente diferente para cada sess\u00e3o. Parece mais prov\u00e1vel que tenha sido gerado por uma fun\u00e7\u00e3o de hash ou pseudo-aleat\u00f3ria. O PLC verifica esses tr\u00eas blocos, os segmentos de 9 bytes e 8 bytes, respectivamente, do ponto 7, e envia imediatamente um pacote TCP com um sinalizador de redefini\u00e7\u00e3o se os blocos de bytes n\u00e3o forem os esperados pelo PLC; caso contr\u00e1rio, a comunica\u00e7\u00e3o continua. Esses bytes s\u00e3o gerados por um algoritmo espec\u00edfico. Ap\u00f3s a resposta do Portal TIA, se a conex\u00e3o for aceita, o PLC envia um pacote S7CommPlus. O pacote S7CommPlus conter\u00e1 informa\u00e7\u00f5es relacionadas \u00e0s fun\u00e7\u00f5es fornecidas pelo TIA Portal.<\/p>\n

              Atacantes sofisticados poderiam identificar esses bytes e usar essas informa\u00e7\u00f5es para explorar ainda mais o protocolo.<\/p>\n

              An\u00e1lise do TIA-Portal<\/span><\/p>\n

              O WinDbg\u00a0<\/b>foi usado para realizar uma an\u00e1lise do TIA Portal. Esta se\u00e7\u00e3o descreve em resumo o processo realizado durante os experimentos. A fun\u00e7\u00e3o que realiza uma pesquisa de dispositivos acess\u00edveis no TIA Portal foi usada para gerar o tr\u00e1fego do S7CommPlus.<\/p>\n

              \"imagen<\/center>
              Diagrama de refer\u00eancia An\u00e1lise do TIA-Portal<\/center>Para apoiar a an\u00e1lise, v\u00e1rios pontos de interrup\u00e7\u00e3o foram estabelecidos durante a comunica\u00e7\u00e3o entre o software e o PLC. Um processo de an\u00e1lise manual identificou que o array de bytes muda significativamente cada vez que o TIA Portal faz uma solicita\u00e7\u00e3o. Esse bloco de 20 bytes n\u00e3o tem rela\u00e7\u00e3o \u00f3bvia com o payload do pacote de solicita\u00e7\u00e3o de conex\u00e3o, conforme confirmado pelo envio exatamente do mesmo pacote de solicita\u00e7\u00e3o de conex\u00e3o para o PLC usando\u00a0o Scapy<\/b>.<\/p>\n

              O primeiro desafio para o analista \u00e9 identificar a parte do ecossistema a ser visada e o ponto de entrada da an\u00e1lise, para o que s\u00e3o fornecidas algumas\u00a0dicas a seguir<\/b>.<\/p>\n

              Para iniciar a an\u00e1lise, a fun\u00e7\u00e3o de pesquisa do Portal TIA \u00e9 usada uma vez sem nenhum ponto de interrup\u00e7\u00e3o e uma sess\u00e3o de comunica\u00e7\u00e3o completa \u00e9 gerada (encerrada por um pacote de reinicializa\u00e7\u00e3o TCP do PLC). Ao iniciar manualmente um ponto de interrup\u00e7\u00e3o por meio do WinDbg no software e, em seguida, usar o comando “s” para pesquisar os 20 bytes do PLC na mem\u00f3ria, o endere\u00e7o de mem\u00f3ria que cont\u00e9m esse bloco de 20 bytes pode ser identificado. Esse endere\u00e7o de mem\u00f3ria pode ser localizado com uma \u00fanica pesquisa “s” ou, muitas vezes, apenas a \u00e1rea que armazena todo o pacote de desafio S7 recebido \u00e9 localizada.<\/p>\n

              Outra pesquisa deve ser feita usando um ponto de interrup\u00e7\u00e3o de acesso e rastreando o endere\u00e7o espec\u00edfico no qual esse array de 20 bytes \u00e9 gravado. Uma vez identificado esse endere\u00e7o, ele n\u00e3o ser\u00e1 alterado at\u00e9 que o Portal TIA seja reiniciado. Um ponto de interrup\u00e7\u00e3o de acesso, “ponto de interrup\u00e7\u00e3o A”, deve ser estabelecido nesse endere\u00e7o. Depois de inicializar outra comunica\u00e7\u00e3o S7 usando o TIA Portal, verificou-se que o ponto de interrup\u00e7\u00e3o A foi acessado por dois locais diferentes, ambos fun\u00e7\u00f5es que envolvem a c\u00f3pia do bloco de 20 bytes para outro endere\u00e7o. A primeira fun\u00e7\u00e3o copia o endere\u00e7o apontado pelo ponto de interrup\u00e7\u00e3o A, enquanto a segunda fun\u00e7\u00e3o copia os bytes para um endere\u00e7o espec\u00edfico. Portanto, para uma investiga\u00e7\u00e3o mais aprofundada, dois outros pontos de interrup\u00e7\u00e3o de acesso, o ponto de interrup\u00e7\u00e3o B e o ponto de interrup\u00e7\u00e3o C, foram estabelecidos para cada um dos dois endere\u00e7os identificados.<\/p>\n

              Descobriu-se que o ponto de interrup\u00e7\u00e3o B aponta para o endere\u00e7o do 3\u00ba byte e o ponto de interrup\u00e7\u00e3o C armazena do 3\u00ba ao 18\u00ba 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\u00e7\u00e3o importante no restante do processo de gera\u00e7\u00e3o de bytes. Al\u00e9m disso, descobriu-se que os dois locais de mem\u00f3ria apontados pelos pontos de interrup\u00e7\u00e3o B e C est\u00e3o envolvidos na gera\u00e7\u00e3o de bytes para a resposta do S7CommPlus e o pacote de fun\u00e7\u00f5es, respectivamente.<\/p>\n

              \u00c9 nesse ponto que a dll “OMSp_core_managed.dll” aparece pela primeira vez e os endere\u00e7os apontados pelo ponto de interrup\u00e7\u00e3o A, B e C est\u00e3o dentro do intervalo dessa dll. Durante a an\u00e1lise, foi confirmado que esse m\u00f3dulo, ou dll, \u00e9 onde ocorre toda a gera\u00e7\u00e3o dos bytes anti-replay.<\/p>\n

              Convidamos voc\u00ea a ler\u00a0Vulnerability Analysis of S7 PLCs: Manipulating the Security Mechanism (An\u00e1lise de vulnerabilidade de PLCs S7: Manipula\u00e7\u00e3o do mecanismo de seguran\u00e7a).\u00a0<\/b>O artigo completo sobre a pesquisa na qual esta postagem se baseia e o trabalho detalhado no TIA-Portal podem ser encontrados nas refer\u00eancias.<\/p>\n

              Ele aborda em detalhes t\u00f3picos como:<\/b><\/p>\n

                \n
              • Pacote de respostas do TIA Portal S7<\/li>\n
              • Bytes manipul\u00e1veis<\/li>\n
              • Primeira criptografia<\/li>\n
              • Segunda criptografia<\/li>\n
              • Algoritmo de aumento de campo finito<\/li>\n
              • Algoritmo A480<\/li>\n
              • Pacotes de recursos do TIA-Portal<\/li>\n
              • Verifica\u00e7\u00e3o de integridade<\/li>\n<\/ul>\n

                \"imagen<\/center><\/p>\n

                HMAC<\/span><\/p>\n

                Ap\u00f3s a troca de pacotes de desafio e resposta S7, os pacotes de fun\u00e7\u00e3o S7 ser\u00e3o enviados. Esses pacotes incluem a finalidade e os detalhes da comunica\u00e7\u00e3o e, como visto no ponto 8, \u00e9 mostrado um dos pacotes que cont\u00e9m informa\u00e7\u00f5es 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\u00e1lise, descobriu-se que esse bloco de 32 bytes \u00e9, na verdade, uma verifica\u00e7\u00e3o de integridade HMAC para o pacote. Essa verifica\u00e7\u00e3o de integridade tem duas finalidades: garantir que as cargas \u00fateis n\u00e3o sejam adulteradas e autenticar o remetente (j\u00e1 que as chaves do HMAC s\u00e3o conhecidas apenas pelos hosts envolvidos na conex\u00e3o). Para gerar esse valor de 32 bytes, foram encontrados dois c\u00e1lculos de HMAC.<\/p>\n

                O primeiro \u00e9 usado para gerar a chave para todos os HMACs subsequentes. O segundo \u00e9 usado para assinar todos os pacotes de fun\u00e7\u00f5es. Ambos os HMACs s\u00e3o baseados no mesmo algoritmo de hashing do restante do mecanismo. O gr\u00e1fico a seguir mostra como os dois HMACs geram os bytes de integridade.<\/p>\n

                \"imagen<\/center><\/p>\n

                Primeiro HMAC<\/span><\/p>\n

                O c\u00e1lculo do primeiro HMAC \u00e9 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\u00e7\u00e3o C<\/p>\n

                Abaixo est\u00e1 um exemplo de pseudoc\u00f3digo para a gera\u00e7\u00e3o de 8 bytes, que \u00e9 essencial para verificar a integridade da fun\u00e7\u00e3o S7. Esse algoritmo n\u00e3o \u00e9 identificado como um algoritmo padronizado, portanto o pseudoc\u00f3digo \u00e9 gerado pela an\u00e1lise do c\u00f3digo assembler. Essa an\u00e1lise \u00e9 instrutiva do ponto de vista da seguran\u00e7a, pois o algoritmo de gera\u00e7\u00e3o de 8 bytes \u00e9 uma parte essencial da gera\u00e7\u00e3o do byte de integridade.<\/p>\n

                \"imagen<\/center><\/p>\n

                O valor combinado de 24 bytes \u00e9 ent\u00e3o assinado usando uma chave de 24 bytes gerada no setor \u24bb do diagrama de refer\u00eancia do TIA-Portal. A sa\u00edda 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.<\/p>\n

                Segundo HMAC<\/span><\/p>\n

                O segundo HMAC \u00e9 usado para gerar os bytes de verifica\u00e7\u00e3o de integridade reais, que s\u00e3o inseridos no pacote de fun\u00e7\u00e3o 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\u00e9m disso, qual parte do payload do pacote de fun\u00e7\u00e3o S7 \u00e9 usada como entrada do segundo HMAC. O comprimento do pacote de fun\u00e7\u00f5es nem sempre \u00e9 o mesmo, mas o HMAC de 32 bytes do pacote sempre come\u00e7a no 13\u00ba byte do pacote. A entrada desse HMAC compreende todos os bytes que seguem o HMAC no pacote, ou seja, do 45\u00ba byte em diante, excluindo o rodap\u00e9 do pacote, que normalmente \u00e9 os \u00faltimos quatro bytes (por exemplo, no ponto 8 \u00e9 “72 03 00 00” no final do pacote). Como o tamanho de cada pacote e as informa\u00e7\u00f5es que ele cont\u00e9m podem variar, o tamanho e o conte\u00fado do rodap\u00e9 variam de acordo. No entanto, para reproduzir o pacote, considerando que a chave \u00e9 conhecida, um m\u00e9todo simples de tentativa e erro poderia identificar qual byte \u00e9 necess\u00e1rio como entrada HMAC.<\/p>\n

                Poss\u00edveis participa\u00e7\u00f5es<\/span><\/p>\n

                A an\u00e1lise acima do protocolo S7CommPlus e do Portal TIA revela a possibilidade de explorar o protocolo e o software. V\u00e1rias explora\u00e7\u00f5es validadas s\u00e3o discutidas a seguir, bem como poss\u00edveis 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\u00e7\u00f5es maliciosas.<\/p>\n

                Altera\u00e7\u00f5es n\u00e3o autorizadas no status do PLC<\/span><\/p>\n

                Como todas as a\u00e7\u00f5es executadas no Portal TIA s\u00e3o enviadas ao PLC usando o protocolo S7, usando as descobertas desta pesquisa, pode ser poss\u00edvel causar interrup\u00e7\u00f5es em v\u00e1rios processos, incluindo: reprograma\u00e7\u00e3o de um PLC, altera\u00e7\u00e3o do valor de uma vari\u00e1vel do PLC, defini\u00e7\u00e3o da senha de um PLC e altera\u00e7\u00e3o do estado do PLC (do estado de funcionamento para o estado de parada e vice-versa). Para fins de demonstra\u00e7\u00e3o, o escopo do trabalho atual concentrou-se em verificar se \u00e9 poss\u00edvel alterar remotamente o estado de um PLC, ou seja, parar um PLC em funcionamento. As experi\u00eancias mostraram que isso pode ser feito usando dois pacotes de fun\u00e7\u00e3o S7, al\u00e9m da resposta anti-replay, que inclui os 132 bytes identificados no item 7.<\/p>\n

                \"imagen<\/center><\/p>\n

                Esta imagem mostra um dos pacotes de fun\u00e7\u00e3o falsificados necess\u00e1rios para parar um PLC. O pacote falsificado \u00e9 gerado com base nas descobertas documentadas na se\u00e7\u00e3o An\u00e1lise do TIA-Portal. Com exce\u00e7\u00e3o do byte anti-replay (ponto 6), dos bytes de verifica\u00e7\u00e3o de integridade e do n\u00famero de sequ\u00eancia, todos os outros bytes s\u00e3o iguais nos dois pacotes (um normal e um falsificado). Vale a pena mencionar novamente que, mesmo em sess\u00f5es S7 diferentes, todos os bytes anti-reprodu\u00e7\u00e3o podem ser gerados para qualquer pacote falsificado com base nas mesmas chaves de criptografia e bytes necess\u00e1rios que permanecer\u00e3o constantes com base nos hashes nas caixas \u24b9 e \u24ba e \u24bb no Diagrama de Refer\u00eancia do TIA-Portal.<\/p>\n

                Conforme mencionado, tamb\u00e9m \u00e9 poss\u00edvel reprogramar um PLC usando o protocolo S7. Embora haja um mecanismo integrado de prote\u00e7\u00e3o contra c\u00f3pia, desde que o invasor possa identificar a rela\u00e7\u00e3o entre o n\u00famero de s\u00e9rie do PLC que \u00e9 enviado pela l\u00f3gica do PLC e a pr\u00f3pria l\u00f3gica do PLC, um ataque para reprogramar a l\u00f3gica pode ser vi\u00e1vel.<\/p>\n

                Comunica\u00e7\u00e3o DoS<\/span><\/p>\n

                Al\u00e9m 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\u00eam uma nova sess\u00e3o S7 em um PLC. Isso impedir\u00e1 que o Portal TIA se conecte ao PLC. Essa explora\u00e7\u00e3o \u00e9 poss\u00edvel porque o S7-1211C n\u00e3o permitir\u00e1 que uma nova sess\u00e3o seja iniciada se j\u00e1 existir uma sess\u00e3o anterior.<\/p>\n

                Para implementar essa explora\u00e7\u00e3o, sup\u00f5e-se que n\u00e3o haja nenhuma sess\u00e3o atual entre o PLC e o Portal TIA. Um host na mesma LAN que o PLC pode iniciar uma conex\u00e3o 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\u00e3o genu\u00edna do Portal TIA. Para manter uma sess\u00e3o normal, por exemplo, para pedir \u00e0 outra extremidade que aguarde enquanto um processo est\u00e1 em execu\u00e7\u00e3o, qualquer conex\u00e3o final pode responder com esse pacote S7-ACK, aparentemente indefinidamente.<\/p>\n

                Essa explora\u00e7\u00e3o \u00e9 poss\u00edvel porque o pacote “S7-ACK”, “03 00 00 00 07 02 F0 00”, n\u00e3o tem fun\u00e7\u00f5es de verifica\u00e7\u00e3o de integridade ou anti-reprodu\u00e7\u00e3o e pode ser usado para responder a qualquer pacote S7. Portanto, a sess\u00e3o pode ser mantida viva sem que o invasor obtenha nenhuma informa\u00e7\u00e3o adicional. Embora o PLC continue a executar a l\u00f3gica pr\u00e9-programada, n\u00e3o \u00e9 poss\u00edvel interromp\u00ea-lo, reconfigur\u00e1-lo ou reprogram\u00e1-lo. Uma reinicializa\u00e7\u00e3o manual pode encerrar a sess\u00e3o existente, mas um host ou dispositivo comprometido na rede pode reiniciar uma nova sess\u00e3o do DOS. Esse ataque pode ser cr\u00edtico por si s\u00f3, mas tamb\u00e9m pode permitir um ataque em maior escala.<\/p>\n

                Sequestro de sess\u00e3o<\/span><\/p>\n

                A explora\u00e7\u00e3o descrita acima pressup\u00f5e que n\u00e3o h\u00e1 conex\u00e3o entre o Portal TI A e o PLC de destino. No entanto, essa explora\u00e7\u00e3o poderia ser combinada com um ataque de rede tradicional, usando pacotes de explora\u00e7\u00e3o criados juntamente com envenenamento de ARP, para sequestrar uma sess\u00e3o para o PLC e causar um DOS para que o Portal TIA n\u00e3o possa se reconectar. Os autores j\u00e1 documentaram anteriormente como o sequestro de sess\u00e3o 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\u00e3o S7, o que faz com que o lado do Portal TIA da conex\u00e3o seja encerrado. Ao mesmo tempo, o lado PLC da sess\u00e3o pode ser mantido vivo por um invasor que cria e envia pacotes S7-ACK. Durante esse ataque, uma op\u00e7\u00e3o \u00e9 usar respostas ARP excessivas para sobrecarregar quaisquer outros pacotes ARP depois que a sess\u00e3o for roubada. No entanto, para evitar a gera\u00e7\u00e3o de muito “ru\u00eddo” ARP, a sess\u00e3o S7 roubada poderia ser encerrada e substitu\u00edda por uma nova sess\u00e3o DOS, conforme descrito na se\u00e7\u00e3o anterior. Esse ataque consegue duas coisas:<\/p>\n

                \"imagen<\/center><\/p>\n

                1) Um “footprint” de rede menor seria gerado em compara\u00e7\u00e3o com o roubo de sess\u00e3o por meio de envenenamento de ARP.
                \n2) \u00c9 poss\u00edvel realizar o ataque DOS sem esperar que a sess\u00e3o leg\u00edtima termine, pois uma sess\u00e3o DOS n\u00e3o pode ser iniciada mesmo que exista uma leg\u00edtima.<\/p>\n

                Elimina\u00e7\u00e3o do programa principal<\/span><\/p>\n

                Foi descoberto um novo exploit baseado no protocolo S7CommPlus que pode manipular a l\u00f3gica do PLC e excluir o bloco Main Object dos PLCs S7 -1200 e, fazendo com que o TIA-Portal forne\u00e7a informa\u00e7\u00f5es incompletas ou incorretas sobre o PLC Isso pode ser causado pela reprodu\u00e7\u00e3o de pacotes S7 capturados em um caso de uso anormal.<\/p>\n

                A seguir, descrevemos as etapas de repeti\u00e7\u00e3o da explora\u00e7\u00e3o, incluindo a gera\u00e7\u00e3o de pacotes, a repeti\u00e7\u00e3o dos pacotes e o comportamento esperado da gera\u00e7\u00e3o dos pacotes que ser\u00e3o repetidos como a explora\u00e7\u00e3o:<\/p>\n