Ferramenta de Recuperação de Senha do ETS5

Sumário

• Introdução
• Instalação
• Requisitos
• Como funciona a recuperação de senha?
• Como a falha de design foi descoberta?
• Como o risco pode ser mitigado?
• Divulgação coordenada de vulnerabilidades
• Licença
• Registro de alterações

Introdução

Você esqueceu a senha de um dos seus projetos ETS5 e não consegue mais acessar a configuração da instalação KNX? A Ferramenta de Recuperação de Senha do ETS5 permite que você recupere a senha do projeto e outros segredos salvos no armazenamento de projetos do ETS5. Isso é possível porque o ETS5 tem uma falha de design significativa: ele usa uma senha e um sal fixos no código para criptografar as informações do projeto (CVE-2021-36799).

Armazenar segredos criptográficos no código-fonte é desaconselhável porque eles podem ser recuperados por engenharia reversa do software, oferecendo assim pouco mais proteção do que armazenar as informações como texto claro. Isso pode representar uma ameaça à segurança das instalações KNX. Se um invasor conseguir obter acesso aos arquivos no armazenamento de projetos, ele poderá descriptografá-los mesmo sem conhecer a senha do projeto. As informações contidas nesses arquivos permitem espionar, personificar e reconfigurar dispositivos KNX. Isso é particularmente problemático porque o ETS5 dá aos usuários a impressão de que a senha do projeto seria usada para criptografar as informações do projeto, não apenas para projetos exportados. Portanto, é provável que muitos usuários e integradores de sistemas não tenham tomado medidas adicionais para garantir a confidencialidade do armazenamento de projetos. Se o ETS5 implementasse a criptografia corretamente e uma senha de projeto forte fosse escolhida, isso representaria um desafio muito maior para um invasor, mesmo que ele conseguisse obter acesso remoto ao computador.

As seguintes informações confidenciais são criptografadas de forma inadequada:

• Senhas de projetos
• FDSKs
• Chaves backbone
• Códigos de autenticação de dispositivos e chaves derivadas
• Senhas de gerenciamento de dispositivos e chaves derivadas
• Senhas de usuário / tunelamento e chaves derivadas
• Chaves de ferramenta

A Ferramenta de Recuperação de Senha do ETS5 é uma prova de conceito que demonstra o problema descriptografando e exibindo as informações confidenciais. Ela foi desenvolvida como parte da divulgação coordenada de vulnerabilidades e é lançada com permissão da Associação KNX. A publicação da ferramenta serve aos seguintes propósitos:

1. Documenta publicamente o problema de segurança, permitindo assim que os usuários tomem precauções para mitigar os riscos.
2. A Associação KNX não planeja corrigir o problema nas versões atuais ou futuras do ETS. Aumentar a conscientização sobre a falha de design pode fazê-los mudar de ideia. (veja a seção divulgação coordenada de vulnerabilidades para uma atualização)
3. Divulgar a falha de design esperançosamente incentiva a Associação KNX e qualquer pessoa que leia este documento a adotar melhores práticas de engenharia de software.
4. A Ferramenta de Recuperação de Senha do ETS5 pode ser realmente útil caso alguém tenha esquecido a senha do próprio projeto.

AVISO: Use esta ferramenta somente se você estiver legalmente autorizado a visualizar as informações do projeto. Contornar medidas de segurança, mesmo as ineficazes, para obter acesso a informações que você não tem permissão para ver, pode ser crime em sua jurisdição.

Instalação

O executável pode ser baixado da seção de releases. Ele não precisa ser instalado e pode ser colocado em qualquer diretório de sua escolha.

Alternativamente, se você não quiser executar um binário não confiável em seu sistema, pode descriptografar atributos individuais dos arquivos XML do projeto no site CyberChef website.

Requisitos

O software depende do .NET Framework 4.6 ou posterior. O Windows 10 já inclui uma versão adequada do .NET por padrão. Usuários de versões anteriores do Windows terão que instalar uma versão atual do .NET Framework para executar o software.

Como funciona a recuperação de senha?

Ao contrário do que a interface do usuário sugere, o ETS5 não criptografa seus arquivos de projeto armazenados localmente em C:\ProgramData\KNX\ETS5\ProjectStore com a senha do projeto. Em vez disso, ele usa a senha fixa no código ETS5Password e o sal Ivan Medvedev para ofuscar atributos específicos nos arquivos XML do projeto. Segredos criptográficos fixos no código são contra as boas práticas, conforme explicado em CWE-798 e CWE-321.

O processo para a desofuscação é:

1. O atributo ofuscado é codificado em Base64 e precisa ser decodificado, veja a RFC 4648.
2. Obtenha a representação em bytes de Ivan Medvedev como string ASCII ou UTF-8.
3. Use a função de derivação de chave implementada por PasswordDeriveBytes no .NET Framework. Ela é baseada em PBKDF1, mas adiciona um contador ao algoritmo de derivação de chave. No ETS5, ela é usada com SHA-1 como função hash, 100 iterações, ETS5Password como senha e a representação em bytes de Ivan Medvedev como sal. Os primeiros 32 bytes da saída da derivação de chave serão usados como chave e os 16 bytes seguintes como IV.
4. Descriptografe o atributo decodificado usando AES-256 no modo CBC com a chave e o IV do passo 3.
5. Remova o preenchimento PKCS#7 e o resultado é o valor original do atributo.

Uma implementação da desofuscação pode ser encontrada no arquivo Deobfuscator.cs. Como a senha e o sal são constantes, seria possível pré-calcular a chave e o IV para pular a derivação de chave. Isso não é feito na implementação deste software, pois a intenção é mostrar todas as etapas da desofuscação. No entanto, se você precisar da chave e do IV, eles estão listados abaixo.

Os arquivos de projeto exportados (.knxproj) não são afetados por essa falha de design e, portanto, esta ferramenta não pode ser usada para recuperar a senha do projeto nesses arquivos. O arquivo .knxproj é um arquivo ZIP que contém outro arquivo ZIP com as informações confidenciais. Este último usa compactação Deflate, criptografia ZipCrypto / PKWARE e a senha do projeto para a derivação da chave de criptografia.

Como a falha de design foi descoberta?

Durante a preparação da minha tese "Security Analysis of the KNXnet/IP Secure Protocol", investiguei como o ETS5 armazena as informações do projeto. Como o ETS gera e armazena chaves criptográficas e senhas que são usadas pelos dispositivos KNX IP Secure para autenticar uns aos outros, fornecer confidencialidade para comunicações multicast e proteger a configuração dos dispositivos, é importante manter essas informações em segredo. Se um invasor obtivesse acesso às informações do projeto armazenadas pelo ETS, isso comprometeria totalmente a segurança da instalação KNX.

Por esse motivo, o armazenamento de projetos do ETS5 foi inspecionado para verificar se os dados são armazenados de uma forma que garanta a confidencialidade. Os arquivos de projeto em C:\ProgramData\KNX\ETS5\ProjectStore são legíveis por qualquer conta de usuário, sem necessidade de direitos de administrador. Os seguintes indicadores foram encontrados e levantaram a suspeita de que os dados não estão devidamente criptografados:

1. Os arquivos de configuração XML não são criptografados como um todo. Apenas os atributos confidenciais, como códigos de autenticação de dispositivos, senhas de gerenciamento de dispositivos, FDSKs e chaves de ferramenta, foram modificados para não conterem seu valor em texto claro.
2. Um atributo para a senha do projeto é armazenado em um dos arquivos XML. Isso parecia um pouco estranho, pois com uma implementação correta a criptografia derivaria a chave da senha do projeto e, portanto, armazená-la não seria estritamente necessário. No entanto, hipoteticamente, isso poderia ter sido usado para verificar se a senha inserida está correta antes de tentar descriptografar outros atributos.
3. Dois projetos com senhas de projeto diferentes, mas dispositivos idênticos, tinham os mesmos valores para alguns atributos específicos de dispositivo, como o FDSK.

O último ponto indicou claramente que a senha do projeto não era usada no algoritmo que modifica os valores dos atributos. Um exemplo pode ser visto abaixo, onde os códigos de autenticação de dispositivos em dois projetos P-02FB e P-0117 foram definidos com valores idênticos. As saídas ofuscadas também são as mesmas, apesar de senhas de projeto diferentes serem usadas. Como não há solicitação para inserir nada além da senha do projeto ao abrir o projeto no ETS5, isso significava que a chave tinha que estar armazenada em algum lugar ou que seria um algoritmo de ofuscação simples que não exige nenhuma chave. Parecia provável que a solução não fosse ideal para garantir a confidencialidade e potencialmente colocasse as instalações KNX em risco.

Os arquivos de configuração não são criptografados em sua totalidade.```xml

``` #### Uma senha de projeto diferente não altera a saída se os valores de atributo originais forem idênticos```xml ``` Como as observações indicavam fortemente o uso de uma abordagem insegura, possivelmente devido ao uso de uma chave criptográfica embutida no código, foi necessário investigar como os valores dos atributos eram modificados. A intenção era identificar uma possível falha de segurança, que pudesse então ser relatada ao fornecedor e corrigida, melhorando a segurança para todos os usuários. Avaliar se a implementação fornece confidencialidade adequada significou que o ETS5 teve que passar por engenharia reversa.

Como o ETS5 é baseado no framework .NET, o que ficou imediatamente evidente pelas DLLs utilizadas, a descompilação pôde ser facilmente realizada por meio do ILSpy. O binário havia sido ofuscado com Dotfuscator, presumivelmente para dificultar os esforços de engenharia reversa. No entanto, os nomes de classes e funções foram surpreendentemente mantidos em sua maioria intactos. Portanto, a abordagem escolhida foi procurar por classes e funções que parecessem relacionadas ao processamento dos arquivos XML, criptografia, descriptografia, ofuscação, desofuscação, chaves ou senhas. Isso levou à descoberta de Knx.Ets.ObjectModel.Import.PasswordDescrambler.Scramble e Knx.Ets.ObjectModel.Import.Encryption.EncryptString, que são chamadas nos valores ofuscados dos atributos armazenados nos arquivos XML. Nenhum material de chave era passado para as funções; elas apenas usavam valores constantes para derivar uma chave que então era utilizada para criptografar/descriptografar os atributos usando AES-256 no modo CBC. Era evidente que credenciais embutidas no código eram usadas para derivar uma chave. O Dotfuscator alterou o fluxo de controle e inseriu operações supérfluas, mas as chamadas às funções do framework .NET não puderam ser ocultadas. Assim, foi possível escrever uma especificação para a (des)ofuscação nesta fase, para uma abordagem semi-clean-room. A única parte que faltava era a string utilizada na derivação da chave, que havia sido obscurecida pelo dotfuscator. O De4dot foi escolhido para reverter a ofuscação da string, o que revelou a senha ETS5Password. O IV já era legível antes da aplicação do De4dot, pois havia sido definido como uma sequência de bytes. Por curiosidade pessoal, descobriu-se que esses bytes não eram aleatórios, mas na verdade a representação em bytes ASCII / UTF-8 da string Ivan Medvedev.

Como a falha de projeto representa um risco para as instalações KNX, o problema teve que ser relatado à KNX Association. Era necessária uma implementação de prova de conceito para garantir que o problema pudesse ser demonstrado, se solicitado. Para evitar quaisquer violações de direitos autorais, a prova de conceito foi implementada com base na especificação que havia sido anotada. Isso foi feito para evitar qualquer reutilização de código do software original. A aplicação do Dotfuscator também garantiu que o código original, e até mesmo o código não ofuscado, fosse inutilizável para uma implementação limpa, o que assegurava que mesmo uma cópia não intencional do original fosse improvável.

Para detalhes sobre a divulgação coordenada após o desenvolvimento da prova de conceito, consulte a seção Divulgação Coordenada de Vulnerabilidades.

Como o risco pode ser mitigado?

Infelizmente, até 2021-07-18, não há uma versão corrigida do ETS disponível. Portanto, medidas adicionais fora do ETS5 são necessárias para lidar com os riscos. As subseções abaixo explicam diferentes abordagens que podem ser adotadas dependendo do modelo de ameaça que você está considerando e contra o qual tenta se proteger.

Criptografia completa do disco

• Solução:
  • Criptografe todo o disco rígido com o BitLocker do Windows ou um software de terceiros como o VeraCrypt.
• Prós:
  • Todos os dados no disco rígido são criptografados e inacessíveis a atacantes enquanto o dispositivo estiver desligado. Isso pressupõe que uma senha complexa tenha sido usada.
  • O Windows já fornece uma solução fácil de usar com o BitLocker em determinadas versões do Windows, e soluções de software de código aberto também estão prontamente disponíveis.
• Contras:
  • Não fornece confidencialidade enquanto o computador está em execução. Se um atacante conseguir obter acesso a uma das contas de usuário / explorar uma RCE, ele poderá acessar as informações do projeto como texto simples.

Criptografia de arquivos / pastas

• Solução:
  • Criptografe o diretório C:\ProgramData\KNX\ETS5\ProjectStore e todos os arquivos contidos nele usando o Sistema de Arquivos Criptografados (EFS) do Windows.
• Prós:
  • As informações do projeto são criptografadas e inacessíveis a atacantes enquanto o dispositivo estiver desligado.
  • Se o EFS for configurado pela conta de administrador ou por uma conta dedicada para executar o ETS, outras contas de usuário não conseguirão acessar os arquivos. Isso deve fornecer proteção se um atacante obtiver acesso a uma conta de usuário no computador, mas não àquela que configurou o EFS. É necessária uma senha forte para a conta de administrador ou para a conta do ETS, pois ela é usada para proteger o material de chave.
• Contras:
  • Nem sempre fornece confidencialidade enquanto o computador está em execução. Se um atacante conseguir obter acesso à conta de usuário que configurou o EFS ou conseguir executar código no contexto desse usuário, ele ainda poderá acessar as informações do projeto como texto simples.

Volume criptografado

• Solução:
  • Crie um volume criptografado com um software de terceiros como o VeraCrypt e armazene somente as informações do projeto nele.
• Prós:
  • As informações do projeto são criptografadas e inacessíveis a atacantes enquanto o volume não estiver montado. Isso pressupõe que uma senha complexa ou token de hardware tenha sido usado para a criptografia do volume.
  • Fornece proteção limitada mesmo no caso de o atacante conseguir obter direitos de administrador. Enquanto o volume não estiver montado enquanto o atacante tiver acesso ao sistema, os dados no volume criptografado devem permanecer confidenciais.
• Contras:
  • Os arquivos de projeto originais precisam ser transferidos para o volume criptografado e então excluídos com segurança, para que os arquivos originais não criptografados não possam ser recuperados.
  • Um link simbólico precisa ser criado para fazer o volume montado aparecer em C:\ProgramData\KNX\ETS5\ProjectStore.
  • Em geral, é mais complicado de configurar.

Divulgação Coordenada de Vulnerabilidades

• 2021-06-26 - Problema relatado à KNX Association
• 2021-07-09 - KNX Association confirmou o problema
• 2021-07-12 - KNX Association permitiu a divulgação imediata
• 2021-07-18 - Divulgação pública
• 2021-07-19 - CVE-2021-36799 atribuído

De acordo com Joost Demarest, CTO e CFO da KNX Association, o ETS5 não receberá nenhuma correção, pois o desenvolvimento dessa versão já foi concluído. Ele permitiu a publicação imediata do problema em 2021-07-12, abrindo mão do atraso de 90 dias oferecido para a divulgação.

Atualização 2021-11-08

Devido a um mal-entendido, o README anteriormente afirmava que a KNX Association planejava resolver o problema no ETS6. Não é esse o caso. A KNX Association esclareceu em 2021-10-25 que não planeja corrigir este problema, pois não considera responsabilidade do ETS armazenar com segurança o material de chave criptográfica quando ele não está sendo exportado.

Atualização 2021-11-10

A KNX Association entrou em contato comigo e explicou que revisou seus planos. Eles agora pretendem documentar as deficiências da versão atual do ETS e criptografar adequadamente o armazenamento de projetos em uma versão futura do ETS6.

Licença

O projeto é distribuído sob a licença MIT.

Registro de alterações

1.0.0 - 2021-07-18

Hash do commit:

• c6a3750cefa74d84c5886097cdd0f30dc1bd0dd1

Download:

• Código-fonte
• Executável

Alterações:

• Versão inicial