Hackers descongelam supermercados: lições de segurança OT

Imagine que é o gerente do turno da noite de um supermercado em Lyon. Às 3 da manhã, a equipa nota gelo a derreter das vitrines de congelados. Depois, os alarmes dos compressores começam a disparar — não num só corredor, mas em toda a loja. Quando alguém percebe o que se passa, as câmaras frigoríficas já foram colocadas remotamente em modo de descongelação, e milhares de euros em stock congelado estão a aquecer discretamente em direção ao limite legal de descarte. Foi mais ou menos o que aconteceu quando atacantes atingiram controladores de refrigeração de cadeias de supermercados franceses este ano, e é um bom alerta para quem acha que a segurança da tecnologia operacional é problema de outra pessoa.

O ataque não foi nenhuma cadeia de exploits de cinema. Segundo relatos, os atacantes ativaram ciclos automáticos de descongelação em controladores de refrigeração expostos à internet — unidades comerciais de um grande fornecedor industrial — e os danos espalharam-se por lojas em vários países. Na mesma altura, um incidente separado obrigou um grupo belgo-holandês de retalho alimentar a retirar partes da sua infraestrutura de TI, perturbando a distribuição e as entregas. Coincidência ou coordenação, o resultado foi o mesmo: o mundo físico foi hackeado através do digital.

Afinal, porque é que um congelador está na internet?

A reação mais comum a esta história — e que inundou os comentários por todo o lado — foi alguma variante de «porque é que alguém ligaria um frigorífico à internet?». Parece retórico, mas há uma resposta real, e fingir o contrário é a forma como voltamos a ter esta conversa de poucos em poucos anos.

A refrigeração comercial não é um frigorífico. Um supermercado de dimensão média opera um sistema térmico distribuído: dezenas de vitrines, câmaras frigoríficas e congeladores, bastidores de compressores e condensadores, tudo orquestrado por controladores que equilibram temperatura e custo energético. O argumento de negócio para a conectividade remota é genuíno:

• Diagnóstico remoto. Um prestador de serviços de refrigeração que dê assistência a centenas de lojas consegue ver a assinatura de um compressor a falhar dias antes de uma avaria. Mandar um técnico carregar num botão físico para uma descongelação de rotina custa dinheiro a sério; um comando remoto não custa nada.
• Otimização energética. Os supermercados estão entre os edifícios que mais energia consomem por metro quadrado. As cadeias ajustam temperaturas das vitrines e calendários de descongelação em todo o parque, e algumas participam em programas de resposta à procura em que a distribuidora lhes paga para reduzir carga em momentos de stress da rede.
• Registo para conformidade. As regras de segurança alimentar exigem registos contínuos de temperatura. Controladores em rede produzem uma trilha de auditoria automática — sem papel de registo, sem registos em papel falsificados.
• Comparação entre frotas. Quando gere 2.000 lojas, detetar que os compressores de uma loja consomem mais 15% de energia do que as outras é a forma de encontrar fugas de fluido refrigerante antes de se transformarem em reparações de cinco dígitos.

Portanto, a conectividade não é estúpida. O que é estúpido é a implementação. Os primeiros relatos sugerem que muitos destes controladores eram acessíveis diretamente pela internet — alguns com modems celulares e cartões SIM próprios, em espaço de IP público, sem VPN, sem gateway e sem lista de permissões. E a história da autenticação, segundo um relato muito partilhado, era um utilizador admin com uma palavra-passe derivada da data do dia. Isso não é uma superfície de ataque; é uma porta aberta com tapete de boas-vindas.

É assim que um ataque OT se parece na realidade

Os engenheiros de software tendem a imaginar os ciberataques como roubo de dados: bases de dados exfiltradas, credenciais vazadas, notas de ransomware. Os ataques OT são diferentes em natureza, não apenas em grau. O alvo não é a informação — é um processo físico. A carga não é a cifragem; é um comando com ar legítimo enviado a um dispositivo que confia em quem aparecer.

Repare como o ataque de descongelação é elegante. Os atacantes não precisaram de escrever malware, escalar privilégios, nem sequer perceber totalmente o protocolo. Um ciclo de descongelação é uma função normal e autorizada do controlador — existe porque o gelo se acumula nas serpentinas do evaporador e tem de ser derretido periodicamente. O atacante limitou-se a invocá-la fora de horário, em escala. Nenhum intertravamento de segurança disparou, porque, do ponto de vista do controlador, nada anormal foi pedido. Este é o equivalente OT do problema do «deputado confuso»: o dispositivo executa fielmente comandos que nunca deveria ter recebido.

Esse padrão generaliza-se de forma deprimente. Estações de tratamento de água já foram «atacadas» por alguém que mexeu num cursor de dosagem química. Sistemas de gestão de edifícios foram tomados através do acesso remoto do fornecedor de AVAC. Quase sempre, a capacidade perigosa não é um bug — é uma funcionalidade, acessível a pessoas que nunca deveriam chegar lá. Por isso, a solução não é uma revisão de código melhor. É arquitetura.

As vulnerabilidades OT mais perigosas não são bugs de corrupção de memória. São funções legítimas expostas a chamadores ilegítimos.

O patch que ninguém aplicou

Eis o detalhe que devia fazer estremecer qualquer engenheiro de segurança: a vulnerabilidade subjacente a estes controladores tinha sido divulgada publicamente meses antes, num processo coordenado com o fornecedor. Investigadores de segurança publicaram uma análise detalhada. Existiam correções para pelo menos alguns modelos. E o ataque aconteceu na mesma.

Este é o segredo sujo do patching industrial. Em TI empresarial, estamos mimados: sai um CVE crítico e, em poucos dias, as ferramentas de gestão de frota já avisaram, prepararam e instalaram a correção. A OT não funciona assim. O controlador de uma vitrine de congelados pode funcionar durante quinze anos. É propriedade da loja, mantido por um prestador externo de refrigeração, fabricado por um fornecedor e configurado por um instalador que saiu da empresa há seis anos. Quem, exatamente, é responsável por aplicar uma atualização de firmware em 2.400 locais em nove países? Na prática: ninguém.

Pior ainda, o fornecedor aparentemente lançou a correção sem a assinalar claramente como crítica para a segurança. Para um prestador de manutenção com uma lista de equipamentos avariados à espera, «atualização de firmware disponível» soa a trabalho opcional. Isto é tanto uma falha de comunicação como técnica. Se lançar um patch para uma vulnerabilidade que permite a desconhecidos descongelar os alimentos de um país, as notas de versão devem dizê-lo em palavras que um responsável de instalações não consiga ignorar. A distância entre especificação e implementação não cria apenas bugs — cria frotas inteiras de dispositivos sem correção cujos operadores não sabem que estão vulneráveis.

Falhas seguras por omissão: projetar para o pior dia

Vamos falar sobre o que é o bom, porque os princípios aqui não são exóticos. São as mesmas ideias de design defensivo que aplicamos em software crítico para a segurança, apenas raramente impostas no mundo OT. Já escrevi antes sobre engenharia defensiva que resiste à catástrofe, e os controladores de refrigeração são um caso de manual para isso.

Limitar a taxa de alterações de estado perigosas

Um ciclo de descongelação é fisicamente seguro se executado ocasionalmente e destrutivo se executado constantemente. Por isso, imponha a física no firmware: depois de concluir uma descongelação, recuse outra durante um intervalo mínimo, independentemente do que qualquer comando remoto disser. O atacante que consegue enviar um pedido de descongelação consegue enviar mil; o dispositivo não deve aceitar mais do que a física permite. Isto custa algumas linhas de código e um temporizador, e limita o raio de impacto de qualquer comprometimento do plano de controlo.

Intertravamentos locais valem mais do que autoridade remota

Se a temperatura da câmara já estiver acima de um limiar, ou os sensores do produto indicarem calor, um comando remoto de descongelação deve ser rejeitado e registado de forma bem visível. O controlador tem os dados dos sensores para saber que um comando é absurdo. Faça-o usar esses dados. Um comando que empurraria o sistema para um estado conhecidamente mau não é um comando; é um erro.

Comandos assinados, não palavras-passe

As palavras-passe em dispositivos embebidos são uma causa perdida — serão predefinidas, partilhadas, escritas num post-it ou derivadas da data. O modelo mais forte é assimétrico: os controladores verificam uma assinatura em cada comando remoto contra uma chave pública do fornecedor ou do operador gravada na altura do provisionamento. Assim, roubar uma palavra-passe não ajuda; é preciso a chave de assinatura, que vive num HSM no centro de operações, e não em 2.400 vitrines de congelados. Sim, isto implica infraestrutura de gestão, rotação e revogação de chaves. Sim, vale a pena. Resolvemos este problema para atualizações de software há uma década; os canais de comando merecem o mesmo tratamento.

Assumir que a rede é hostil

Se um dispositivo sai de fábrica com modem celular e credencial predefinida, acabará num motor de pesquisa de dispositivos expostos poucas semanas após a instalação. A única correção duradoura é projetar como se isso fosse garantido: ligações de entrada recusadas por defeito, telemetria apenas de saída para um broker e plano de gestão acessível só através de um túnel com autenticação mútua. «Não o exponha à internet» é um conselho; «tornar a exposição sobrevivível» é engenharia.

O isolamento não é opcional: segmentação bem feita

Todos os frameworks de segurança OT — IEC 62443, as orientações do NIST, o clássico modelo de Purdue — dizem a mesma coisa: mantenha os sistemas de controlo fora de redes planas. E, no entanto, o modem celular na vitrine é o anti-padrão em estado puro. Contorna completamente a firewall corporativa, criando milhares de pontos de entrada não monitorizados e endereçáveis individualmente, que a equipa de segurança talvez nem saiba que existem.

A arquitetura que realmente funciona tem este aspeto:

1. Os controladores vivem numa VLAN OT dedicada sem rota para a internet e sem rota para a TI corporativa. Apenas um gateway pode comunicar com eles.
2. O gateway aplica listas de permissões de protocolo — o controlador fala Modbus ou o protocolo do fornecedor com o gateway e mais nada. Anomalias aqui são alertas de alto sinal, porque o tráfego legítimo é monótono e previsível.
3. O acesso remoto passa por um jump host com MFA, gravação de sessões e credenciais com prazo. O prestador de refrigeração recebe uma janela de quatro horas para uma loja específica, não uma VPN permanente para todo o parque.
4. Telemetria apenas de saída. Se a cloud do fornecedor precisar de dados de temperatura, é o gateway que os envia. Nada puxa de dentro.
5. Inventarie tudo. Não se consegue segmentar aquilo que não se conhece. Aquela conectividade celular na vitrine é exatamente o tipo de ligação-sombra que os inventários deixam passar — até o Shodan a encontrar por si.

Nada disto é hipotético nem caro, comparado com a alternativa. A parte difícil é organizacional, não técnica: exige que a equipa de instalações, a equipa de segurança de TI e os fornecedores concordem sobre quem é dono de quê. Na maioria das organizações de retalho, a OT cai na fresta entre essas equipas — física demais para a TI, em rede demais para as instalações. Essa ambiguidade é a verdadeira vulnerabilidade, e é a mesma que transforma lacunas de autenticação na cloud em violações invisíveis, como vimos em os pontos cegos do registo de autenticação na cloud: se ninguém for dono da telemetria, ninguém vê o ataque.

O que os engenheiros de software devem retirar disto

Pode nunca tocar num controlador de refrigeração, mas os modos de falha aqui são os de qualquer sistema conectado, e cada vez mais são problema seu. A fronteira entre TI e OT continua a dissolver-se: os seus robôs de armazém, o AVAC do escritório, os instrumentos do laboratório e o edifício inteligente correm todos Linux embebido e falam com clouds. Alguns equipamentos de laboratórios hospitalares já recusam correr testes se a conta de subscrição não estiver carregada — o que significa que uma falha de faturação ou uma violação ligada à internet pode parar diagnósticos médicos. Construímos esse mundo, uma funcionalidade de conveniência de cada vez.

Por isso, as lições transferem-se diretamente. Inventarie a sua exposição — se não sabe o que está à escuta, outra pessoa vai descobri-lo. Trate operações perigosas como privilegiadas, mesmo quando são «funcionalidades normais», porque o atacante que chega ao seu plano de controlo vai usar as suas funcionalidades contra si. Assine o que importa e faça expirar tudo o resto. Desenhe o estado de falha para ser o estado seguro: um controlador que perde conectividade deve continuar a arrefecer, e não assumir que cada comando em fila é fiável. E quando lançar uma correção de segurança, diga-o em voz alta — um patch que ninguém aplica é indistinguível de não haver patch nenhum.

O ataque de descongelação aos supermercados será lembrado sobretudo pelo absurdo — hackers contra ervilhas congeladas. Mas o próximo não vai visar gelados. Vai visar a mesma classe de controladores expostos, sem correções e com autenticação fraca, num armazém farmacêutico de frio, na central de arrefecimento de um centro de dados ou num sistema municipal de água. O hardware é o mesmo. As credenciais são igualmente más. A única variável é o que aquece, inunda ou desliga quando alguém escreve a palavra-passe do dia.