ETS5 Password Recovery Tool

목차

• 소개
• 설치
• 요구 사항
• 비밀번호 복구는 어떻게 작동하나요?
• 설계 결함은 어떻게 발견되었나요?
• 위험은 어떻게 완화할 수 있나요?
• 조정된 취약점 공개
• 라이선스
• 변경 로그

소개

ETS5 프로젝트 중 하나의 비밀번호를 잊어버려 더 이상 KNX 설치의 구성을 액세스할 수 없습니까? ETS5 Password Recovery Tool을 사용하면 ETS5의 프로젝트 저장소에 저장된 프로젝트 비밀번호 및 기타 비밀 정보를 검색할 수 있습니다. 이는 ETS5에 중요한 설계 결함이 있기 때문에 가능합니다. ETS5는 하드코딩된 비밀번호와 솔트(salt)를 사용하여 프로젝트 정보를 암호화합니다 (CVE-2021-36799).

소스 코드에 암호화 비밀을 저장하는 것은 좋지 않습니다. 소프트웨어를 리버스 엔지니어링하여 복구할 수 있으므로 정보를 평문으로 저장하는 것보다 조금 나은 보호만 제공하기 때문입니다. 이는 KNX 설치의 보안에 위협이 될 수 있습니다. 공격자가 프로젝트 저장소의 파일에 접근할 수 있다면 프로젝트 비밀번호를 알지 못해도 해당 파일을 해독할 수 있습니다. 포함된 정보를 통해 KNX 장치를 도청, 사칭 및 재구성할 수 있습니다. 이는 특히 문제가 됩니다. ETS5가 사용자에게 프로젝트 비밀번호가 내보낸 프로젝트뿐만 아니라 프로젝트 정보를 암호화하는 데 사용될 것이라는 인상을 주기 때문입니다. 따라서 많은 사용자와 시스템 통합업체가 프로젝트 저장소의 기밀성을 보장하기 위한 추가 조치를 취하지 않았을 가능성이 높습니다. ETS5가 암호화를 제대로 구현하고 강력한 프로젝트 비밀번호가 선택되었다면, 공격자가 컴퓨터에 원격으로 접근하더라도 더 큰 어려움에 직면하게 될 것입니다.

다음 기밀 정보는 부적절하게 암호화됩니다:

• 프로젝트 비밀번호
• FDSK
• 백본 키
• 장치 인증 코드 및 파생 키
• 장치 관리 비밀번호 및 파생 키
• 사용자 / 터널링 비밀번호 및 파생 키
• 도구 키

ETS5 Password Recovery Tool은 민감한 정보를 해독하고 표시하여 이 문제를 입증하는 개념 증명입니다. 이 도구는 조정된 취약점 공개의 일환으로 개발되었으며 KNX Association의 허가를 받아 배포됩니다. 이 도구를 공개하는 목적은 다음과 같습니다:

1. 보안 문제를 공개적으로 문서화하여 사용자가 위험을 완화하기 위한 예방 조치를 취할 수 있게 합니다.
2. KNX Association은 현재 또는 향후 ETS 버전에서 이 문제를 해결할 계획이 없습니다. 설계 결함에 대한 인식이 높아지면 그들의 생각이 바뀔 수 있습니다. (업데이트는 조정된 취약점 공개 섹션을 참조하십시오)
3. 설계 결함을 공개함으로써 KNX Association과 이 문서를 읽는 모든 사람이 더 나은 소프트웨어 엔지니어링 관행을 채택하도록 장려되기를 바랍니다.
4. ETS5 Password Recovery Tool은 실제로 누군가 자신의 프로젝트 비밀번호를 잊어버린 경우 유용할 수 있습니다.

경고: 이 도구는 프로젝트 정보를 볼 법적 권한이 있는 경우에만 사용하십시오. 보안 조치(비효율적이더라도)를 우회하여 볼 수 없는 정보에 접근하는 것은 관할 지역에서 중범죄에 해당할 수 있습니다.

설치

실행 파일은 릴리스 섹션에서 다운로드할 수 있습니다. 설치할 필요가 없으며 원하는 디렉터리에 배치할 수 있습니다.

또는 시스템에서 신뢰할 수 없는 바이너리를 실행하고 싶지 않다면 CyberChef 웹사이트에서 프로젝트의 XML 파일에 있는 개별 속성을 해독할 수 있습니다.

요구 사항

이 소프트웨어는 .NET Framework 4.6 이상에 의존합니다. Windows 10에는 기본적으로 적합한 .NET 버전이 포함되어 있습니다. 이전 Windows 버전 사용자는 소프트웨어를 실행하려면 최신 .NET Framework 버전을 설치해야 합니다.

비밀번호 복구는 어떻게 작동하나요?

사용자 인터페이스가 시사하는 것과 달리 ETS5는 C:\ProgramData\KNX\ETS5\ProjectStore에 로컬로 저장된 프로젝트 파일을 프로젝트 비밀번호로 암호화하지 않습니다. 대신 하드코딩된 비밀번호 ETS5Password와 솔트 Ivan Medvedev를 사용하여 프로젝트의 XML 파일에서 특정 속성을 난독화합니다. 하드코딩된 암호화 비밀은 CWE-798 및 CWE-321에 설명된 대로 모범 사례에 위배됩니다.

난독화 해제 과정은 다음과 같습니다:

1. 난독화된 속성은 Base64로 인코딩되어 있으므로 디코딩해야 합니다(RFC 4648 참조).
2. Ivan Medvedev를 ASCII 또는 UTF-8 인코딩 문자열로 표현한 바이트를 가져옵니다.
3. .NET Framework에서 PasswordDeriveBytes가 구현한 키 유도 함수를 사용합니다. 이 함수는 PBKDF1을 기반으로 하지만 키 유도 알고리즘에 카운터를 추가합니다. ETS5에서는 SHA-1을 해시 함수로, 100회 반복, ETS5Password를 비밀번호로, Ivan Medvedev의 바이트 표현을 솔트로 사용합니다. 키 유도 출력의 처음 32바이트는 키로 사용되고 다음 16바이트는 IV로 사용됩니다.
4. 3단계의 키와 IV를 사용하여 디코딩된 속성을 AES-256 CBC 모드로 해독합니다.
5. PKCS#7 패딩을 제거하면 결과가 속성의 원래 값이 됩니다.

난독화 해제의 구현은 Deobfuscator.cs 파일에서 찾을 수 있습니다. 비밀번호와 솔트가 일정하므로 키와 IV를 미리 계산하여 키 유도를 건너뛸 수 있습니다. 이 소프트웨어의 구현에서는 난독화 해제의 모든 단계를 보여주기 위한 것이므로 그렇게 하지 않습니다. 그러나 키와 IV가 필요하다면 아래에 나열되어 있습니다.

내보낸 프로젝트 파일(.knxproj)은 이 설계 결함의 영향을 받지 않으므로 이 도구를 사용하여 해당 파일의 프로젝트 비밀번호를 복구할 수 없습니다. .knxproj 파일은 민감한 정보가 포함된 또 다른 ZIP 파일을 포함하는 ZIP 파일입니다. 후자는 Deflate 압축, ZipCrypto / PKWARE 암호화를 사용하며 암호화 키 유도에 프로젝트 비밀번호를 사용합니다.

설계 결함은 어떻게 발견되었나요?

제 논문 "Security Analysis of the KNXnet/IP Secure Protocol" 준비 과정에서 ETS5가 프로젝트 정보를 저장하는 방식을 조사했습니다. ETS는 KNX IP Secure 장치가 서로를 인증하고, 멀티캐스트 통신의 기밀성을 제공하며, 장치 구성을 보호하는 데 사용되는 암호화 키와 비밀번호를 생성하고 저장하므로 정보를 비밀로 유지하는 것이 중요합니다. 공격자가 ETS에 저장된 프로젝트 정보에 접근할 수 있다면 KNX 설치의 보안이 완전히 손상될 것입니다.

이러한 이유로 ETS5의 프로젝트 저장소를 검사하여 데이터가 기밀성을 보장하는 방식으로 저장되는지 확인했습니다. C:\ProgramData\KNX\ETS5\ProjectStore의 프로젝트 파일은 모든 사용자 계정이 읽을 수 있으며 관리자 권한이 필요하지 않습니다. 데이터가 제대로 암호화되지 않았다는 의심을 불러일으키는 다음과 같은 지표가 발견되었습니다:

1. XML 구성 파일은 전체가 암호화되지 않습니다. 장치 인증 코드, 장치 관리 비밀번호, FDSK 및 도구 키와 같은 민감한 속성만 평문 값을 포함하지 않도록 수정되었습니다.
2. 프로젝트 비밀번호에 대한 속성이 XML 파일 중 하나에 저장됩니다. 이는 약간 이상해 보였습니다. 제대로 구현된 경우 암호화가 프로젝트 비밀번호에서 키를 유도하므로 저장할 필요가 없었기 때문입니다. 그러나 가상으로는 다른 속성을 해독하기 전에 입력한 비밀번호가 올바른지 확인하는 데 사용될 수 있었을 것입니다.
3. 서로 다른 프로젝트 비밀번호를 가진 두 프로젝트가 동일한 장치를 가진 경우 FDSK와 같은 일부 장치별 속성 값이 동일했습니다.

마지막 요점은 프로젝트 비밀번호가 속성 값을 수정하는 알고리즘에 사용되지 않았음을 명확히 나타냈습니다. 아래에서 두 프로젝트 P-02FB와 P-0117의 장치 인증 코드가 동일한 값으로 설정된 예를 볼 수 있습니다. 서로 다른 프로젝트 비밀번호가 사용되었음에도 난독화된 출력도 동일합니다. ETS5에서 프로젝트를 열 때 프로젝트 비밀번호 외에 입력하라는 프롬프트가 없기 때문에 키가 어딘가에 저장되어 있거나 키가 필요 없는 단순한 난독화 알고리즘일 것임을 의미했습니다. 이 솔루션은 기밀성을 보장하기에 이상적이지 않으며 잠재적으로 KNX 설치를 위험에 빠뜨릴 수 있다고 보였습니다.

구성 파일은 전체가 암호화되지 않습니다.```xml

``` #### 원본 속성 값이 동일하면 다른 프로젝트 비밀번호가 출력을 변경하지 않습니다.```xml ``` As the observations strongly hinted at the use of an insecure approach, possibly due to the use of a hard-coded cryptographic key, it was necessary to investigate how the attribute values were modified. The intention was to identify a potential security flaw, which could then be reported to the vendor and have it fixed, improving the security for all users. Assessing whether the implementation provides adequate confidentiality meant the ETS5 had to be reverse engineered.

Since the ETS5 is based on the .NET framework, which was immediately apparent from the DLLs used, decompiling could be easily accomplished through ILSpy. The binary had been obfuscated with Dotfuscator, presumably to make reverse engineering efforts more difficult. However, class and function names were surprisingly left mostly intact. Hence, the chosen approach was to search for classes and functions which seemed related to processing the XML files, encryption, decryption, obfuscation, deobfuscation, keys or passwords. This led to the discovery of Knx.Ets.ObjectModel.Import.PasswordDescrambler.Scramble and Knx.Ets.ObjectModel.Import.Encryption.EncryptString, that are called on the obfuscated values of attributes stored in the XML files. There was no key material being passed into the functions, it only used constant values to derive a key which was then utilized to encrypt / decrypt the attributes using AES-256 in CBC mode. It was apparent that hard-coded credentials were used to derive a key. The Dotfuscator changed the control flow and inserted superfluous operations, but the calls to the functions from the .NET framework could not be hidden. Thus, it was possible to write a specification for the (de-)obfuscation at this stage for a semi-clean-room approach. The only missing part was the string used in the key derivation that had been obscured by dotfuscator. De4dot was chosen to reverse the string obfuscation, which revealed the ETS5Password password. The IV was already readable prior to applying De4dot as it had been defined as a byte sequence. Due to personal curiosity, it was discovered that those were not random bytes, but actually the ASCII / UTF-8 byte representation of the string Ivan Medvedev.

As the design flaw poses a risk to KNX installations, the issue had to be reported to the KNX Association. A proof of concept implementation was needed to ensure that the issue could be demonstrated, if asked for. To avoid any copyright violations, the proof of concept was implemented based on the specification that had been noted. This was done to avoid any reuse of code from the original software. The application of Dotfuscator also made sure that the original and even unobfuscated code were unusable for a clean implementation anyway, which ensured that even unintentional copying of the original was unlikely.

For details on the coordinated disclosure following the development of the proof of concept, see the section Coordinated Vulnerability Disclosure.

How can the risk be mitigated?

Unfortunately, as of 2021-07-18, there is no patched ETS version available. Therefore, additional measurements outside the ETS5 are necessary to address the risks. The subsections below explain different approaches that can be taken depending on the threat model you are assuming and trying to protect against.

Full disk encryption

• Solution:
  • Encrypt the entire hard drive with Windows BitLocker or a third-party software like VeraCrypt.
• Pros:
  • All data on the hard drive is encrypted and inaccessible to attackers as long as the device is turned off. This assumes that a complex password was used.
  • Windows already provides an easy-to-use solution with BitLocker on certain Windows versions, and open source software solutions are also readily available.
• Cons:
  • It does not provide confidentiality while the computer is running. If an attacker is able to gain access to one of the user accounts / exploit an RCE, they are able to access the project information as plaintext.

File / folder encryption

• Solution:
  • Encrypt the C:\ProgramData\KNX\ETS5\ProjectStore directory and all files contained within using Windows Encrypted File System (EFS).
• Pros:
  • The project information are encrypted and inaccessible to attackers as long as the device is turned off.
  • If the EFS is set up by the administrator account or a dedicated account for running the ETS, other user accounts are unable to access the files. This should provide protection if an attacker gains access to a user account on the computer but not the one that configured the EFS. A strong password for the administrator or ETS account is needed, as it is used to protect the key material.
• Cons:
  • It does not always provide confidentiality while the computer is running. If an attacker is able to gain access to the user account that set up the EFS or is able to run code in that user's context, then they are still able to access the project information as plaintext.

Encrypted volume

• Solution:
  • Create an encrypted volume with a third-party software like VeraCrypt and only store the project information there.
• Pros:
  • The project information are encrypted and inaccessible to attackers as long as the volume is not mounted. This assumes that a complex password or hardware token was used for the volume encryption.
  • Provides limited protection even in the case that the attacker is able to gain administrator rights. As long as the volume is not mounted while the attacker has access to the system, the data in the encrypted volume should stay confidential.
• Cons:
  • The original project files need to be transferred into the encrypted volume and then securely deleted, so that the original unencrypted files cannot be recovered.
  • A symbolic link needs to be created in order to make the mounted volume appear under C:\ProgramData\KNX\ETS5\ProjectStore.
  • In general, it is more complicated to set up.

Coordinated Vulnerability Disclosure

• 2021-06-26 - Issue reported to the KNX Association
• 2021-07-09 - KNX Association confirmed issue
• 2021-07-12 - KNX Association permitted immediate disclosure
• 2021-07-18 - Public disclosure
• 2021-07-19 - CVE-2021-36799 assigned

According to Joost Demarest, CTO and CFO of the KNX Association, ETS5 will not receive any patches as development for that version has already been concluded. He permitted immediate publication of the issue on 2021-07-12, forgoing the offered 90 days delay for the disclosure.

Update 2021-11-08

Due to a misunderstanding the README previously claimed that the KNX Association plans to address the issue in ETS6. This is not the case. The KNX Association has clarified on 2021-10-25 that they do not plan to fix this issue, as they do not consider it the responsibility of the ETS to securely store cryptographic key material when it is not being exported.

Update 2021-11-10

The KNX Association has contacted me and explained that they have revised their plans. They now intend to document the shortcomings of the current ETS version and properly encrypt the project store in a future version of ETS6.

License

The project is distributed under the MIT license.

Change log

1.0.0 - 2021-07-18

Commit hash:

• c6a3750cefa74d84c5886097cdd0f30dc1bd0dd1

Download:

• Source code
• Executable

Changes:

• Initial version