Ataque cibernético em rede de energia na Ucrânia

Ataque cibernético em rede de energia na Ucrânia

Uma análise forense baseada na ISA/IEC 62443

Por Patrice Bock, com a colaboração de Jean-Pierre Hauet, Romain Françoise e Robert Foley

Três empresas de distribuição de energia sofreram um ataque cibernético no oeste da Ucrânia em 23 de dezembro de 2015. Como a informação forense é extensa do ponto de vista técnico, é uma oportunidade para considerar a norma ISA / IEC 62443-3-3 sobre segurança para sistemas de automação industrial e sistemas de controle relativa aos requisitos de segurança do sistema e níveis de segurança para o teste com um exemplo na vida real. Diversas fontes foram usadas para esse propósito que, em geral, fornecem informações incomumente detalhadas.

Este artigo:

- analisa a cinemática do ataque usando os relatórios disponíveis e suposições razoáveis com base em nossa experiência em cenários de ataques cibernéticos e em sistemas e vulnerabilidades típicas de tecnologia operacional (OT).

- introduz uma metodologia para avaliar o Nível de Segurança - Alcançado (SL-A) por um dos distribuidores ucranianos (correspondendo ao melhor caso documentado).

- aplica esta metodologia; apresenta e discute o SL-A estimado; revê este SL-A segundo o requisito fundamental (FR); e deriva conclusões e ideias.

- avalia o nível de segurança (SL-T) que deve ser direcionado para detectar e prevenir ataques semelhantes.

Cinemática do ataque

Embora o ataque em si tenha sido desencadeado em 23 de dezembro de 2015, foi cuidadosamente planejado. Redes e sistemas foram comprometidos tão cedo quanto oito meses antes. Manter esse período de tempo em mente é essencial para uma compreensão adequada das formas e meios que devem ser usados para detectar e, eventualmente, impedir um ataque semelhante.

Nossa análise do ataque cibernético é baseada em 3 pontos:

1 - Intrusão inicial da rede de tecnologia da informação (TI) usando spear phishing (ataque direcionado, focado em uma pessoa ou organização específica com o objetivo de penetrar suas defesas).

2 - Coleta de inteligência nas redes e sistemas de TI e OT usando o malware flexível BlackEnergy: varreduras de rede, pulando de um sistema para outro, identificação de vulnerabilidades de dispositivos, concepção do ataque e instalação de outros malwares (códigos maliciosos) e backdoors (recurso para garantir acesso remoto ao sistema ou rede).

3 - O ataque em si que durou 10 minutos em 23 de dezembro.

Etapa 1: Malware no e-mail!

Na primavera de 2015, uma variante do malware BlackEnergy foi acionada por um funcionário da Prykarpattya Oblenergo, que abriu o anexo do Excel de um e-mail. O BlackEnergy é um pacote de malware que apareceu pela primeira vez em 2014, quando foi usado extensivamente para se infiltrar em empresas de energia. Seu objetivo era reunir informações sobre infraestrutura e redes e ajudar a preparar futuros ataques cibernéticos.

O diagrama da figura 1 é uma visão simplificada das arquiteturas de rede (por exemplo, Internet, TI, OT) e ajudará a descrever cada etapa do ataque cibernético. O hacker é mostrado como o "cara do chapéu preto" no canto superior direito. O hacker usou a conexão da TI da área de utilidades com a Internet como o canal para preparar e, eventualmente, disparar o ataque cibernético.

Nós podemos ver que a empresa tinha firewalls adequados configurados, um entre a rede de TI e a Internet e o segundo entre a rede de TI e OT (industrial). A rede OT incluía um controle de supervisão do sistema de gerenciamento de distribuição (DMS) e aquisição de dados com servidores e estações de trabalho e um conjunto de gateways usados para enviar ordens do DMS para unidades terminais remotas que controlavam os disjuntores e outros equipamentos nas subestações elétricas. Dispositivos adicionais foram conectados à rede também (por exemplo, estações de trabalho de engenharia e servidores de historiadores), mas não são relevantes para a cinemática de ataque.

Nesta etapa, o hacker conseguiu comprometer um laptop de escritório graças ao anexo de e-mail da BlackEnergy. Isso é difícil de impedir, desde que as pessoas abram anexos de e-mails de aparência legítima.


Figura 1. Diagrama simplificado da arquitetura do Sistema de controle

Figura 2. Passo 2 do ataque

 

Etapa 2: Preparação do ataque, varredura de rede e ameaça persistente avançada (APT)

Durante vários meses no verão de 2015, o malware BlackEnergy foi controlado remotamente para coletar dados, saltar de um host para outro, detectar vulnerabilidades e até mesmo entrar na rede OT e realizar atividades similares de "reconhecimento".

A análise de dados forenses sobre essa fase é incompleta, porque o hacker fez algumas limpezas e eliminou vários discos durante o ataque real. No entanto, a análise prévia da BlackEnergy, bem como considerações razoáveis sobre o processo padrão usado para ataques cibernéticos, torna provável a seguinte reconstituição com razoável confiança.

Conforme exibido na figura 2, durante a etapa dois, uma grande quantidade de atividade de rede ocorreu. O malware controlado remotamente varreu a rede de TI, detectou uma conexão aberta de um sistema de TI a uma plataforma de supervisão OT, executou varreduras de rede OT, coletou informações de componentes OT e, por fim, instalou componentes de malware prontos para disparar tanto na TI quanto nos sistemas de OT.

Essa fase durou semanas, talvez meses, e permitiu um desenvolvimento de um explorador personalizado. Um explorador é um software desenvolvido e utilizado para explorar uma vulnerabilidade específica. Ele é incorporado como uma carga útil em malwares configurados para entregar a carga útil para execução em um destino. Na verdade, esse esforço foi um pouco limitado. A única peça original de código de malware desenvolvida foi a necessária para cancelar os gateways como parte da etapa três. E isso realmente não foi um "esforço" significativo, pois os gateways foram, durante muito tempo, apontados como dispositivos vulneráveis.

Etapa 3: Disparando o ataque cibernético

À tarde, dois dias antes do Natal, conforme indicado por um operador, o mouse se moveu na interface homem-máquina (IHM) e começou a desligar disjuntores remotamente.

Quando o operador local tentou recuperar o controle da interface de supervisão, ele foi desconectado e não pôde efetuar login novamente, porque a senha foi alterada (figura 3).

O ataque completo durou apenas alguns minutos. O hacker usou o malware pré-instalado para controlar remotamente a IHM e desligar a maioria dos painéis de distribuição das redes. Malwares adicionais, em particular o explorador personalizado, foram usados para evitar que o operador recuperasse o controle da rede, eliminando muitos discos (usando o KillDisk) e sobrescrevendo o firmware do gateway Ethernet-para-Serial com código aleatório, transformando assim os dispositivos em pedaços de sucata irrecuperáveis.

Atividades adicionais de "bônus" incluíam a execução de um ataque distribuído de negação de serviço no call center, impedindo que os clientes entrassem em contato com o distribuidor, e desligando a fonte de alimentação ininterrupta para desligar a energia do próprio centro de controle (figura 4).

Este passo foi obviamente destinado a desligar a energia de centenas de milhares de assinantes ocidentais ucranianos conectados à rede. No entanto, a maior parte do esforço foi gasta para garantir que a energia não fosse ligada novamente: todos os malwares específicos foram desenvolvidos com esse objetivo. Uma vez acionado, a única maneira de o operador evitar esse problema era interromper o ataque quando ele fosse executado.

Mas o ataque foi rápido demais para permitir qualquer reação; de fato, em um ambiente de infraestrutura crítica, as ações do operador podem causar problemas de segurança. Portanto, somente ações predefinidas são permitidas e os operadores devem seguir as diretrizes para executar qualquer ação. No caso de uma situação operacional imprevista, eles não são treinados para tomar decisões no local. Esta foi exatamente a situação no caso da Ucrânia. Ações "óbvias" poderiam ter interrompido o ataque (como puxar o cabo que conecta o TO à rede de TI), mas não se pode esperar que operadores não treinados tomassem essas medidas disruptivas por sua própria iniciativa em uma situação estressante em que os erros são bem possíveis.

Figura 3. Etapa 3 do ataque (1)

Figura 4. Etapa 3 do ataque (2)

Conclusões

Em retrospectiva, uma vez que conhecemos todos os detalhes sobre o ataque cibernético, parece fácil detectá-lo, considerando-se as atividades de rede bastante significativas e os níveis de atividade que ocorrem em vários sistemas .

Mas é realmente um desafio descobrir exatamente o que está acontecendo em uma rede, especialmente se você não tiver a menor ideia sobre o que é atividade de rede "normal". Uma vez que conexões com a Internet e com a rede OT são permitidas, detectar sinais de ataques cibernéticos é difícil devido ao volume de tráfego. O monitoramento contínuo com a capacidade de identificar os poucos pacotes suspeitos no meio de todos os pacotes "bons" é necessário. Várias provas de conceito de tal detecção usando detecção correlacionada de TI e OT foram realizadas e foram apresentadas nas conferências GovWare 2016 em Cingapura, Exera Cybersecurity Days 2016 em Paris e SEE Cybersecurity Week 2016 em Rennes (França).

No entanto, existem outros meios e o uso da IEC 62443-3-3 para examinar a segurança do distribuidor ucraniano ajuda a identificar todos os controles que estavam faltando e que poderiam ter impedido o ataque cibernético.

Metodologia para estimar o SL-A

A ISA/IEC 62443-3-3 lista 51 requisitos de sistema (SRs) estruturados em sete requisitos básicos (FRs). Cada SR pode ser reforçado por um ou mais aprimoramentos de requisitos (REs) selecionados com base nos níveis de segurança desejados (SL-Ts). A avaliação dos níveis de segurança alcançados (SL-As) pode, portanto, ser executada:

  • para cada SR, verificando se o requisito básico e possíveis aprimoramentos são atendidos
  • para cada FR, a SL-A sendo o nível máximo alcançado em todos SRs
  • com a avaliação global SL-A sendo o nível máximo alcançado em todos os FR.

A tabela 1 resume o resultado da avaliação de um FR que tem poucas SRs para fins de ilustração.

A matriz da tabela 1 é extraída diretamente do apêndice IEC 62443-3-3 que resume os requisitos. Quanto ao caso Prykarpattya Oblenergo e para cada requisito (básico ou RE), identificamos três casos possíveis:

  • as informações disponíveis são suficientes para considerar o requisito atendido: ✔
  • a informação disponível é suficiente para descobrir que o requisito foi perdido: ✘
  • não é possível avaliar se o requisito foi ou não atendido: ?

Tabela 1. Resultado da avaliação doSL-A para FR5

Uma vez preenchida, a tabela 1 corresponde à avaliação real do FR5 para o caso em questão (Ucrânia), levando a um SL-A de 2. Isso significa que a segmentação de rede ("fluxo de dados restrito") foi implementada para pelo menos os requisitos básicos e para algumas melhorias em outros requisitos.

Aplicação para o caso ucraniano

Esta análise foi realizada em todos os SRs, e duas situações foram identificadas:

  • O SR pode não ser aplicável (por exemplo, em requisitos sobre comunicação sem fio na ausência de tal mídia).
  • Nós podemos não ter provas diretas de que o SR foi ou não cumprido, mas a dedução baseada em instalações similares típicas e outras informações permite uma especulação razoável sobre se o requisito foi atendido ou não.

Por exemplo, podemos considerar backup não disponível, porque os discos não puderam ser restaurados várias semanas após o ataque. Considerando SR 5.2 RE (1), é razoável considerar que a conexão do shell seguro (SSH) através do firewall foi uma exceção e que todo o outro tráfego foi negado. O hacker não teria passado pelo fardo de capturar a senha se formas mais diretas de alcançar a rede OT existissem.

Dos 51 SRs, quatro foram considerados "não aplicável" (1.6, 1.8, 1.9 e 2.2), e 25 não puderam ser determinados ("?"). Esta é uma grande quantidade, o que significa que apenas metade dos SRs pode realmente ser avaliada. Isso realmente favorece um SL-A mais alto, porque somente os SRs avaliados são levados em conta, e porque, por padrão, consideramos que o SR é potencialmente atingido.

Outra decisão foi tomada em termos de apresentação de dados. Em vez de apresentar as informações com um requisito (básico e RE) por linha, como na tabela 1, decidimos ter uma linha por SR e listar o RE crescente nas várias colunas. A Tabela 2 ilustra a mesma avaliação do FR5 usando este modo de apresentação.


 Tabela 2. Estimativa do SL-A (FR5)

Tabela 3. Estimativa geral dos sete FRs

Eventualmente, uma visão mais sintetizada foi usada sem o texto RE para apresentar a imagem geral para todos os FRs, o que abrangia várias páginas de outra forma. Os SLs globais estimados são reagrupados na tabela 3.

Os resultados descritos na tabela 3 são bastante ruins. Além disso, metade dos requisitos não puderam ser avaliados e, portanto, essa visão é provavelmente otimista.

No lado direito, os SL-As estimados estão listados para os sete FR. Podemos ver que os SL-As são zero, exceto para:

  • FR5 (fluxo de dados restrito): principalmente devido ao firewall IT-IACS e ao controle rígido de fluxo. Para cumprir este requisito, significa que o tráfego entre as zonas da rede OT deve ser filtrado. O exemplo do ataque ucraniano demonstra que este requisito poderia ser revisto em futuras atualizações da norma:
    - O cumprimento do SR 5.2 não requer 1 para definir zonas. Como no caso ucraniano, todos os sistemas do OT podem interagir entre si. Observe que as recomendações sobre definições de zona estão disponíveis no ISA / IEC 62443-3-2 que devem ser usadas antes de aplicar o ISA / IEC 62443-3-3.
    - O requisito sobre filtragem de tráfego entre zonas é definido para SL = 1. O retorno sobre o investimento é questionável, já que o custo e o risco da filtragem de tráfego são altos, e a eficácia é questionável, conforme demonstrado pelo caso ucraniano. Pode fazer mais sentido exigir detecção assim que o SL-T = 1 for direcionado e exigir filtragem ativa / prevenção de SLs mais altos.
  • FR6 (resposta oportuna a eventos): A própria existência de informações forenses detalhadas é o resultado de um registro mínimo sendo realizado.

A Tabela 4 mostra uma análise detalhada para alguns dos SRs mais significativos.

Tabela 4. Análise específica para alguns dos SRs mais significativos

Conclusões

No início, olhando para os relatórios sobre os vários controles de segurança dos operadores ucranianos, parecia que eles haviam prestado atenção significativa aos problemas de segurança cibernética. De fato:

  • senhas não óbvias foram usadas
  • um firewall com rígida restrição de fluxo de dados estava em vigor
  • permissão de acesso correta foi executada

Mas, como demonstrado na avaliação do SL-A, a maioria dos níveis de segurança do FR eram nulos, porque pelo menos um dos SRs não foi endereçado. Não faz sentido configurar controles de segurança avançados quando alguns básicos estão faltando. O elo mais fraco reduz a eficácia geral da segurança. O fato de os controles de segurança avançados serem inúteis se outros controles básicos de segurança estiverem ausentes é melhor ilustrado pela configuração do firewall com um único link SSH que exige uma autenticação de senha não óbvia. Isso normalmente é uma restrição operacional dolorosa, já que permitir acesso direto a RDP (Remote Desktop Protocol) para vários sistemas, ou VNCs (Virtual Network Connections), teria sido mais fácil de usar. Infelizmente, essas restrições adicionais não levaram ao aumento da segurança, devido a:

  • A falta de supervisão da rede de TI permitiu extensas varreduras de rede, pesquisas de vulnerabilidades e descoberta do link SSH permitido.
  • A falta de autenticação forte (dois fatores) ou aprovação local (OT) de conexões remotas possibilitou a conexão frequente da TI à rede OT sem detecção ao longo de vários meses.
  • A falta de detecção de invasão de rede OT permitiu extensivas varreduras de rede OT, detecção de vulnerabilidades e restrições de transferência de código móvel (malware, exploits).

Ao implantar controles de segurança, é essencial aplicar os requisitos de maneira consistente em todos os aspectos de segurança: detecção, prevenção e reação. É melhor usar um padrão bem projetado, como o IEC 62443-3-3. Não aponte para SL-T = 2 ou 3 em alguns FRs se o SL-A ainda for zero em outros FRs, pois isso provavelmente seria inútil.

Qual SL teria sido requerido para prevenir o ataque?

Olhando para os problemas listados anteriormente, parece que elevar o SL-A para o nível 2 teria permitido a detecção da atividade durante a etapa dois, evitando assim o ataque cibernético. Muito tempo estava disponível para a reação pós-detecção. Controles adicionais, como autenticação forte / local, antimalware e requisitos de SL 2, na verdade, teriam impedido a cinemática do ataque específico.

O fato de que definir o SL-T no nível 2 teria sido suficiente para detectar e impedir o ataque com várias camadas de defesa pode parecer surpreendente para o leitor, já que foi (certamente) um ataque cibernético patrocinado por algum grupo, que normalmente exige SL-T = 3 ou até 4 para evitar.

Na verdade, é provável que o hacker tenha alcançado o SL-A = 2 desenvolvendo explorações mais avançadas e usando vetores de ataque além da Internet, como mídias móveis ou equipamentos móveis introduzidos por funcionários mal-intencionados ou por terceiros. No entanto, essas etapas adicionais são mais complexas e caras e, por não serem necessárias, foram utilizados meios menos avançados.

Para resumir as conclusões desse ataque cibernético usando a orientação IEC 62443-3-3:

  • Como uma primeira etapa obrigatória, as concessionárias de distribuição de energia devem ter como objetivo o SL-T = 2, garantindo que pelo menos os requisitos mínimos de detecção (SR 6.2) sejam atendidos.
  • Para ter várias camadas de defesa, prevenção, detecção e tempo para reações em antecipação aos ataques mais sofisticados, é melhor direcionar para SL-T = 3.
  • Em qualquer caso, é essencial configurar controles de segurança de maneira consistente para assegurar que todos os FRs tenham alcançado o mesmo SL-A antes de buscar um SL-T mais alto. Caso contrário, os esforços são inúteis, conforme demonstrado pelo exemplo em questão.
     

Considerações:

- As sementes para o ataque foram plantadas na primavera de 2015 com uma variante do malware BlackEnergy, acionada quando um funcionário abriu o anexo do excel de um e-mail.

- O atacante controlou remotamente o mouse IHM do operador para desligar os disjuntores.

- Como o operador local tentou recuperar o controle da interface de supervisão, ele foi desconectado e não pôde efetuar login novamente porque a senha foi alterada.


Sobre o Autor:

Patrice Bock, da Sentryo, é o Líder Técnico da ISA França. O colaborador Jean-Pierre Hauet é Presidente da ISA França e membro votante do Comitê ISA99. Romain Françoise, da Sentryo e Robert Foley, da MatrixGP, também contribuíram neste artigo.
 


Artigo traduzido por Tomé Guerra para a ISA São Paulo Section e republicado com permissão da ISA, Copyright © 2018, Todos os direitos reservados. Este artigo foi escrito pelo autor acima e publicado originalmente na revista InTech Online de Mar-Abr / 2017 em https://www.isa.org/intech/20170406/A ISA não se responsabiliza por erros de tradução neste artigo. 

voltar para Revista InTech

left show tsN fwR uppercase b01n bsd|left tsN fwR uppercase b01ns bsd|left show fwR uppercase b01ns bsd|bnull||image-wrap|news login uppercase bsd b01|fsN fwR uppercase b01 bsd|fwR uppercase b01 bsd|login news fwR uppercase b01 bsd|tsN fwR uppercase b01 bsd|fwR uppercase bsd b01|content-inner||