CVE-2023-4346

Falha de design no protocolo KNX (não um bug de implementação): o mecanismo de autorização de conexão 'Option 1', quando não há uma BCU Key (chave de dispositivo) previamente configurada, permite que qualquer parte com acesso à instalação KNX apague a configuração de todos os dispositivos sem opções de segurança adicionais e defina uma BCU Key própria, trancando os legítimos operadores fora do dispositivo. O impacto é só de disponibilidade (sabotagem/DoS físico em automação predial), sem leitura ou alteração de dados — mas em prédios comerciais e infraestrutura crítica isso significa perda de controle sobre iluminação, HVAC, controle de acesso e alarmes.

CWE-645 (Overly Restrictive Account Lockout Mechanism). O KNX Connection Authorization define métodos para autenticar quem pode configurar dispositivos no barramento. No 'Option 1 Style', a BCU Key funciona como senha do dispositivo, mas várias implementações não oferecem via de reset dessa chave sem informar a chave atual — não há procedimento de recuperação físico (jumper, botão de reset de fábrica) documentado como padrão do protocolo para esse cenário. Isso significa que a própria trava de segurança, pensada para impedir reconfiguração não autorizada, se torna irreversível quando mal usada.

O problema de fundo é que dispositivos KNX sem BCU Key definida aceitam comandos de gerenciamento de qualquer parte com acesso ao barramento — não há autenticação por padrão nesse estado. Um atacante controla apenas duas coisas: acesso ao meio (rede IP que faz bridge para o barramento KNX, ou acesso físico ao próprio barramento/instalação elétrica) e o comando de 'purge' seguido da definição de uma nova BCU Key. Não há exploração de memória, injeção ou lógica de autenticação quebrada no sentido clássico — é abuso de uma funcionalidade legítima de administração contra um dispositivo que nunca foi protegido com senha.

O advisory da CISA classifica isso como falha do próprio Standard KNX quando implementado sem BCU Key, e não aponta uma versão de firmware ou software específica como o componente vulnerável — a superfície afetada é qualquer dispositivo em conformidade com KNX Connection Authorization Option 1 que não teve a BCU Key configurada durante o comissionamento.

Pré-condição real: o dispositivo precisa estar operando sem BCU Key definida — se o integrador já configurou a chave no comissionamento, o vetor descrito não se aplica da mesma forma (a chave já limita quem pode enviar esses comandos). Dado esse estado, existem dois vetores de acesso: (1) rede — se a instalação KNX está conectada a uma rede IP (KNX/IP, gateway, interface de acesso remoto) alcançável pelo atacante, ele interage remotamente com a instalação sem autenticação prévia; (2) físico — acesso ao próprio barramento KNX/EIB do prédio (quadro elétrico, tomada de bus exposta) permite o mesmo ataque mesmo sem conectividade de rede.

A exploração em si é de baixa complexidade técnica: o atacante usa as próprias primitivas do protocolo de gerenciamento KNX para apagar a configuração de dispositivos sem segurança adicional habilitada e, em seguida, define uma BCU Key arbitrária. Não é necessário quebrar criptografia nem escalar privilégios — o estado 'sem chave' já concede a permissão administrativa. O resultado final é bloqueio administrativo do dispositivo: os operadores legítimos perdem a capacidade de reconfigurá-lo via ETS (ferramenta de engenharia KNX) porque não conhecem a nova BCU Key, exigindo reset de hardware quando disponível ou substituição do dispositivo.

O caso está no catálogo KEV da CISA com exploração confirmada em campo ("CISA has received reports of this vulnerability being actively exploited"), mas as fontes não detalham campanhas, atores ou setores específicos atingidos — apenas confirmam ocorrência real, não hipotética.

Não existe patch de firmware ou atualização de versão que corrija isso — é uma característica de design do protocolo/mecanismo de autorização, não um bug corrigível por release. A KNX Association recomenda que integradores e instaladores sempre definam a BCU Key em todo projeto KNX comissionado (existente ou futuro) e documentem essa chave como parte da documentação entregue ao proprietário do edifício, seguindo o 'KNX Secure Checklist' do fornecedor. Sem BCU Key definida, o dispositivo permanece administrativamente aberto a qualquer parte com acesso ao barramento.

Como controle compensatório de rede, a CISA recomenda isolar redes de sistemas de controle (incluindo gateways KNX/IP) do acesso direto à internet, colocá-las detrás de firewall segregadas de redes corporativas, e usar VPN quando acesso remoto for necessário — isso reduz a superfície de ataque remoto, mas não elimina o vetor físico via barramento KNX exposto (quadros elétricos, tomadas de bus acessíveis) nem substitui a definição da BCU Key.

O que não funciona: assumir que a ausência de conectividade IP protege o dispositivo — o próprio advisory afirma que acesso físico ao barramento basta para o mesmo ataque. Também não há 'versão corrigida' a se buscar; qualquer expectativa de atualizar firmware para resolver definitivamente é equivocada — a mitigação é operacional (configurar a chave, documentar, restringir acesso físico e de rede ao barramento).

As fontes não descrevem assinatura de detecção, log específico ou padrão de tráfego confiável para identificar tentativa de exploração — o advisory apenas confirma exploração ativa reportada à CISA, sem detalhar indicadores de comprometimento. Na prática, o que pode ser monitorado é a ocorrência de comandos de 'purge'/reset de configuração e definição de BCU Key no tráfego KNX/IP ou nas ferramentas de engenharia (ETS) vindos de endereços ou dispositivos não autorizados, e alertas de perda de acesso administrativo reportados por operadores — mas isso não constitui uma detecção validada pelas fontes consultadas.