ETS5 Password Recovery Tool

Inhaltsverzeichnis

• Einleitung
• Installation
• Voraussetzungen
• Wie funktioniert die Passwortwiederherstellung?
• Wie wurde der Designfehler entdeckt?
• Wie kann das Risiko gemindert werden?
• Koordinierte Offenlegung von Sicherheitslücken
• Lizenz
• Änderungsprotokoll

Einleitung

Haben Sie das Passwort für eines Ihrer ETS5-Projekte vergessen und können nicht mehr auf die Konfiguration der KNX-Installation zugreifen? Das ETS5 Password Recovery Tool ermöglicht es Ihnen, das Projektpasswort und andere im Projektverzeichnis der ETS5 gespeicherte Geheimnisse wiederherzustellen. Dies ist möglich, weil die ETS5 einen erheblichen Designfehler aufweist: Sie verwendet ein fest codiertes Passwort und einen fest codierten Salt, um die Projektinformationen zu verschlüsseln (CVE-2021-36799).

Das Speichern kryptografischer Geheimnisse im Quellcode ist nicht empfehlenswert, da sie durch Reverse Engineering der Software wiederhergestellt werden können und somit kaum mehr Schutz bieten, als die Informationen im Klartext zu speichern. Dies kann eine Gefahr für die Sicherheit der KNX-Installationen darstellen. Wenn ein Angreifer Zugriff auf die Dateien im Projektverzeichnis erlangt, kann er diese entschlüsseln, ohne das Projektpasswort zu kennen. Die darin enthaltenen Informationen ermöglichen es, KNX-Geräte abzuhören, sich als solche auszugeben und neu zu konfigurieren. Dies ist besonders problematisch, da die ETS5 den Benutzern den Eindruck vermittelt, das Projektpasswort würde zur Verschlüsselung der Projektinformationen verwendet, nicht nur für exportierte Projekte. Daher haben viele Benutzer und Systemintegratoren wahrscheinlich keine zusätzlichen Maßnahmen ergriffen, um die Vertraulichkeit des Projektverzeichnisses zu gewährleisten. Wenn die ETS5 die Verschlüsselung korrekt implementieren würde und ein starkes Projektpasswort gewählt würde, wäre es für einen Angreifer deutlich schwieriger, selbst wenn er Fernzugriff auf den Computer erlangt hätte.

Die folgenden vertraulichen Informationen werden nicht ordnungsgemäß verschlüsselt:

• Projektpasswörter
• FDSKs
• Backbone-Schlüssel
• Geräteauthentifizierungscodes und abgeleitete Schlüssel
• Geräteverwaltungspasswörter und abgeleitete Schlüssel
• Benutzer-/Tunnelpasswörter und abgeleitete Schlüssel
• Werkzeugschlüssel

Das ETS5 Password Recovery Tool ist ein Machbarkeitsnachweis, der das Problem demonstriert, indem es die sensiblen Informationen entschlüsselt und anzeigt. Es wurde im Rahmen der koordinierten Offenlegung von Sicherheitslücken entwickelt und mit Genehmigung der KNX Association veröffentlicht. Die Veröffentlichung des Tools dient den folgenden Zwecken:

1. Es dokumentiert das Sicherheitsproblem öffentlich, sodass Benutzer Vorsichtsmaßnahmen zur Risikominderung ergreifen können.
2. Die KNX Association plant nicht, das Problem in aktuellen oder zukünftigen Versionen der ETS zu beheben. Die Sensibilisierung für den Designfehler könnte ihre Meinung ändern. (siehe Abschnitt koordinierte Offenlegung von Sicherheitslücken für ein Update)
3. Die Offenlegung des Designfehlers hoffentlich ermutigt die KNX Association und alle, die dieses Dokument lesen, bessere Software-Engineering-Praktiken zu übernehmen.
4. Das ETS5 Password Recovery Tool könnte tatsächlich nützlich sein, falls jemand das Passwort für sein eigenes Projekt vergessen hat.

WARNUNG: Verwenden Sie dieses Tool nur, wenn Sie rechtlich dazu befugt sind, die Projektinformationen einzusehen. Das Umgehen von Sicherheitsmaßnahmen, selbst von ineffektiven, um Zugang zu Informationen zu erhalten, die Sie nicht sehen dürfen, kann in Ihrem Rechtsgebiet eine Straftat darstellen.

Installation

Die ausführbare Datei kann aus dem Release-Bereich heruntergeladen werden. Sie muss nicht installiert werden und kann in einem beliebigen Verzeichnis abgelegt werden.

Alternativ, wenn Sie keine nicht vertrauenswürdige Binärdatei auf Ihrem System ausführen möchten, können Sie einzelne Attribute aus den Projekt-XML-Dateien auf der CyberChef Website entschlüsseln.

Voraussetzungen

Die Software benötigt .NET Framework 4.6 oder höher. Windows 10 enthält standardmäßig bereits eine geeignete .NET-Version. Benutzer älterer Windows-Versionen müssen eine aktuelle .NET Framework-Version installieren, um die Software auszuführen.

Wie funktioniert die Passwortwiederherstellung?

Entgegen der Darstellung in der Benutzeroberfläche verschlüsselt die ETS5 Ihre lokal gespeicherten Projektdateien in C:\ProgramData\KNX\ETS5\ProjectStore nicht mit dem Projektpasswort. Stattdessen verwendet sie das fest codierte Passwort ETS5Password und den Salt Ivan Medvedev, um bestimmte Attribute in den Projekt-XML-Dateien zu verschleiern. Fest codierte kryptografische Geheimnisse widersprechen den Best Practices, wie in CWE-798 und CWE-321 erläutert.

Der Prozess für die Entschleierung ist:

1. Das verschleierte Attribut ist Base64-kodiert und muss dekodiert werden, siehe RFC 4648.
2. Ermitteln Sie die Byterepräsentation von Ivan Medvedev als ASCII- oder UTF-8-kodierten String.
3. Verwenden Sie die vom PasswordDeriveBytes im .NET Framework implementierte Schlüsselableitungsfunktion. Sie basiert auf PBKDF1, fügt jedoch einen Zähler zum Schlüsselableitungsalgorithmus hinzu. In der ETS5 wird sie mit SHA-1 als Hash-Funktion, 100 Iterationen, ETS5Password als Passwort und der Byterepräsentation von Ivan Medvedev als Salt verwendet. Die ersten 32 Bytes der Schlüsselableitungsausgabe werden als Schlüssel und die folgenden 16 Bytes als IV verwendet.
4. Entschlüsseln Sie das dekodierte Attribut mit AES-256 im CBC-Modus mit dem Schlüssel und der IV aus Schritt 3.
5. Entfernen Sie die PKCS#7-Padding, und das Ergebnis ist der ursprüngliche Wert des Attributs.

Eine Implementierung der Entschleierung befindet sich in der Datei Deobfuscator.cs. Da Passwort und Salt konstant sind, wäre es möglich, den Schlüssel und die IV vorab zu berechnen, um die Schlüsselableitung zu überspringen. Dies wird in der Implementierung dieser Software nicht getan, da sie alle Schritte der Entschleierung zeigen soll. Falls Sie jedoch den Schlüssel und die IV benötigen, sind diese unten aufgeführt.

Exportierte Projektdateien (.knxproj) sind von diesem Designfehler nicht betroffen, daher kann dieses Tool nicht verwendet werden, um das Projektpasswort für diese wiederherzustellen. Die .knxproj-Datei ist eine ZIP-Datei, die eine weitere ZIP-Datei mit den sensiblen Informationen enthält. Letztere verwendet Deflate-Kompression, ZipCrypto/PKWARE-Verschlüsselung und das Projektpasswort für die Ableitung des Verschlüsselungsschlüssels.

Wie wurde der Designfehler entdeckt?

Während der Vorbereitung meiner Abschlussarbeit "Security Analysis of the KNXnet/IP Secure Protocol" habe ich untersucht, wie die ETS5 Projektinformationen speichert. Da die ETS kryptografische Schlüssel und Passwörter generiert und speichert, die von den KNX-IP-Secure-Geräten verwendet werden, um sich gegenseitig zu authentifizieren, Vertraulichkeit für Multicast-Kommunikation zu gewährleisten und die Konfiguration der Geräte zu sichern, ist es wichtig, die Informationen geheim zu halten. Wenn ein Angreifer Zugriff auf die von der ETS gespeicherten Projektinformationen erlangen würde, wäre die Sicherheit der KNX-Installation vollständig gefährdet.

Aus diesem Grund wurde das Projektverzeichnis der ETS5 überprüft, um festzustellen, ob die Daten auf eine Weise gespeichert werden, die Vertraulichkeit gewährleistet. Die Projektdateien in C:\ProgramData\KNX\ETS5\ProjectStore sind für jedes Benutzerkonto lesbar, es sind keine Administratorrechte erforderlich. Es wurden die folgenden Hinweise gefunden, die den Verdacht aufkommen ließen, dass die Daten nicht ordnungsgemäß verschlüsselt sind:

1. Die XML-Konfigurationsdateien werden nicht als Ganzes verschlüsselt. Nur die sensiblen Attribute, wie die Geräteauthentifizierungscodes, Geräteverwaltungspasswörter, FDSKs und Werkzeugschlüssel, wurden so modifiziert, dass sie ihren Klartextwert nicht enthalten.
2. In einer der XML-Dateien wird ein Attribut für das Projektpasswort gespeichert. Dies erschien etwas seltsam, da bei einer ordnungsgemäßen Implementierung die Verschlüsselung den Schlüssel aus dem Projektpasswort ableiten würde, sodass die Speicherung nicht unbedingt erforderlich gewesen wäre. Hypothetisch hätte dies jedoch verwendet werden können, um zu überprüfen, ob das eingegebene Passwort korrekt ist, bevor andere Attribute entschlüsselt werden.
3. Zwei Projekte mit unterschiedlichen Projektpasswörtern, aber identischen Geräten wiesen für einige gerätespezifische Attribute, wie den FDSK, dieselben Werte auf.

Der letzte Punkt zeigte deutlich, dass das Projektpasswort nicht im Algorithmus verwendet wurde, der die Attributwerte modifiziert. Ein Beispiel ist unten zu sehen, wo die Geräteauthentifizierungscodes in zwei Projekten P-02FB und P-0117 auf identische Werte gesetzt wurden. Die verschleierten Ausgaben sind ebenfalls gleich, obwohl unterschiedliche Projektpasswörter verwendet wurden. Da beim Öffnen des Projekts in der ETS5 keine andere Eingabe als das Projektpasswort erforderlich ist, bedeutete dies, dass der Schlüssel entweder irgendwo gespeichert sein musste oder es sich um einen einfachen Verschleierungsalgorithmus handelte, der keinen Schlüssel benötigt. Es schien wahrscheinlich, dass die Lösung nicht ideal war, um die Vertraulichkeit zu gewährleisten, und möglicherweise KNX-Installationen gefährdete.

Die Konfigurationsdateien werden nicht in ihrer Gesamtheit verschlüsselt.```xml

``` #### Ein anderes Projektpasswort ändert die Ausgabe nicht, wenn die ursprünglichen Attributwerte identisch sind.```xml ``` Da die Beobachtungen stark auf die Verwendung eines unsicheren Ansatzes hindeuteten, möglicherweise aufgrund eines hartcodierten kryptografischen Schlüssels, war es notwendig zu untersuchen, wie die Attributwerte geändert wurden. Ziel war es, eine potenzielle Sicherheitslücke zu identifizieren, die dann dem Hersteller gemeldet und behoben werden kann, um die Sicherheit für alle Benutzer zu verbessern. Die Bewertung, ob die Implementierung eine angemessene Vertraulichkeit bietet, erforderte ein Reverse Engineering des ETS5.

Da der ETS5 auf dem .NET-Framework basiert, was sofort anhand der verwendeten DLLs ersichtlich war, konnte das Decompilieren leicht mit ILSpy durchgeführt werden. Die Binärdatei war mit Dotfuscator obfuskiert worden, vermutlich um Reverse-Engineering-Bemühungen zu erschweren. Allerdings blieben Klassen- und Funktionsnamen überraschenderweise größtenteils intakt. Daher wurde der Ansatz gewählt, nach Klassen und Funktionen zu suchen, die mit der Verarbeitung der XML-Dateien, Verschlüsselung, Entschlüsselung, Obfuskierung, Deobfuskierung, Schlüsseln oder Passwörtern zu tun hatten. Dies führte zur Entdeckung von Knx.Ets.ObjectModel.Import.PasswordDescrambler.Scramble und Knx.Ets.ObjectModel.Import.Encryption.EncryptString, die auf die obfuskierten Werte von Attributen in den XML-Dateien aufgerufen werden. Es wurden keine Schlüsselmaterialien an die Funktionen übergeben, es wurden nur konstante Werte verwendet, um einen Schlüssel abzuleiten, der dann zur Ver-/Entschlüsselung der Attribute mit AES-256 im CBC-Modus verwendet wurde. Es war offensichtlich, dass hartcodierte Anmeldeinformationen verwendet wurden, um einen Schlüssel abzuleiten. Der Dotfuscator änderte den Kontrollfluss und fügte überflüssige Operationen ein, aber die Aufrufe der Funktionen aus dem .NET-Framework konnten nicht verborgen werden. Daher war es möglich, zu diesem Zeitpunkt eine Spezifikation für die (De-)Obfuskierung für einen semi-clean-room-Ansatz zu schreiben. Der einzige fehlende Teil war der bei der Schlüsselableitung verwendete String, der durch Dotfuscator verschleiert worden war. De4dot wurde gewählt, um die String-Obfuskierung rückgängig zu machen, was das Passwort ETS5Password enthüllte. Der IV war bereits vor der Anwendung von De4dot lesbar, da er als Byte-Sequenz definiert war. Aus persönlicher Neugier wurde festgestellt, dass es sich nicht um zufällige Bytes handelte, sondern um die ASCII-/UTF-8-Byte-Darstellung des Strings Ivan Medvedev.

Da der Designfehler ein Risiko für KNX-Installationen darstellt, musste das Problem der KNX Association gemeldet werden. Eine Proof-of-Concept-Implementierung war erforderlich, um sicherzustellen, dass das Problem auf Anfrage demonstriert werden kann. Um Urheberrechtsverletzungen zu vermeiden, wurde der Proof of Concept basierend auf der notierten Spezifikation implementiert. Dies geschah, um eine Wiederverwendung von Code aus der Originalsoftware zu vermeiden. Die Anwendung von Dotfuscator stellte zudem sicher, dass der originale und selbst der nicht obfuskierte Code für eine saubere Implementierung ohnehin unbrauchbar waren, was sicherstellte, dass selbst ein unbeabsichtigtes Kopieren des Originals unwahrscheinlich war.

Einzelheiten zur koordinierten Offenlegung nach der Entwicklung des Proof of Concept finden Sie im Abschnitt Koordinierte Offenlegung von Sicherheitslücken.

Wie kann das Risiko gemindert werden?

Leider gibt es zum 2021-07-18 keine gepatchte ETS-Version. Daher sind zusätzliche Maßnahmen außerhalb des ETS5 erforderlich, um die Risiken zu adressieren. Die folgenden Unterabschnitte erläutern verschiedene Ansätze, je nachdem, welches Bedrohungsmodell Sie annehmen und gegen das Sie sich schützen möchten.

Vollständige Festplattenverschlüsselung

• Lösung:
  • Verschlüsseln Sie die gesamte Festplatte mit Windows BitLocker oder einer Drittanbieter-Software wie VeraCrypt.
• Vorteile:
  • Alle Daten auf der Festplatte sind verschlüsselt und für Angreifer unzugänglich, solange das Gerät ausgeschaltet ist. Dies setzt voraus, dass ein komplexes Passwort verwendet wurde.
  • Windows bietet mit BitLocker auf bestimmten Windows-Versionen bereits eine einfach zu verwendende Lösung, und Open-Source-Softwarelösungen sind ebenfalls leicht verfügbar.
• Nachteile:
  • Es bietet keine Vertraulichkeit, während der Computer läuft. Wenn ein Angreifer in der Lage ist, Zugriff auf eines der Benutzerkonten zu erhalten / eine RCE auszunutzen, kann er auf die Projektinformationen im Klartext zugreifen.

Datei-/Ordner-Verschlüsselung

• Lösung:
  • Verschlüsseln Sie das Verzeichnis C:\ProgramData\KNX\ETS5\ProjectStore und alle darin enthaltenen Dateien mit dem Windows Encrypted File System (EFS).
• Vorteile:
  • Die Projektinformationen sind verschlüsselt und für Angreifer unzugänglich, solange das Gerät ausgeschaltet ist.
  • Wenn das EFS vom Administratorkonto oder einem dedizierten Konto für die Ausführung des ETS eingerichtet wird, können andere Benutzerkonten nicht auf die Dateien zugreifen. Dies sollte Schutz bieten, wenn ein Angreifer Zugriff auf ein Benutzerkonto auf dem Computer erlangt, aber nicht auf das Konto, das das EFS konfiguriert hat. Ein starkes Passwort für das Administrator- oder ETS-Konto ist erforderlich, da es zum Schutz des Schlüsselmaterials verwendet wird.
• Nachteile:
  • Es bietet nicht immer Vertraulichkeit, während der Computer läuft. Wenn ein Angreifer in der Lage ist, Zugriff auf das Benutzerkonto zu erlangen, das das EFS eingerichtet hat, oder Code im Kontext dieses Benutzers auszuführen, kann er weiterhin auf die Projektinformationen im Klartext zugreifen.

Verschlüsselter Container

• Lösung:
  • Erstellen Sie einen verschlüsselten Container mit einer Drittanbieter-Software wie VeraCrypt und speichern Sie die Projektinformationen nur dort.
• Vorteile:
  • Die Projektinformationen sind verschlüsselt und für Angreifer unzugänglich, solange der Container nicht eingehängt ist. Dies setzt voraus, dass ein komplexes Passwort oder Hardware-Token für die Container-Verschlüsselung verwendet wurde.
  • Bietet begrenzten Schutz, selbst wenn der Angreifer Administratorrechte erlangen kann. Solange der Container nicht eingehängt ist, während der Angreifer Zugriff auf das System hat, sollten die Daten im verschlüsselten Container vertraulich bleiben.
• Nachteile:
  • Die ursprünglichen Projektdateien müssen in den verschlüsselten Container übertragen und dann sicher gelöscht werden, damit die ursprünglichen unverschlüsselten Dateien nicht wiederhergestellt werden können.
  • Es muss ein symbolischer Link erstellt werden, damit der eingehängte Container unter C:\ProgramData\KNX\ETS5\ProjectStore erscheint.
  • Im Allgemeinen ist die Einrichtung komplizierter.

Koordinierte Offenlegung von Sicherheitslücken

• 2021-06-26 - Problem an die KNX Association gemeldet
• 2021-07-09 - KNX Association bestätigte das Problem
• 2021-07-12 - KNX Association erlaubte sofortige Offenlegung
• 2021-07-18 - Öffentliche Offenlegung
• 2021-07-19 - CVE-2021-36799 zugewiesen

Laut Joost Demarest, CTO und CFO der KNX Association, wird ETS5 keine Patches erhalten, da die Entwicklung für diese Version bereits abgeschlossen ist. Er erlaubte die sofortige Veröffentlichung des Problems am 2021-07-12 und verzichtete auf die angebotene 90-tägige Verzögerung für die Offenlegung.

Update 2021-11-08

Aufgrund eines Missverständnisses behauptete die README zuvor, dass die KNX Association plane, das Problem in ETS6 zu beheben. Dies ist nicht der Fall. Die KNX Association hat am 2021-10-25 klargestellt, dass sie nicht beabsichtigt, dieses Problem zu beheben, da sie es nicht als Verantwortung des ETS ansehen, kryptografisches Schlüsselmaterial sicher zu speichern, wenn es nicht exportiert wird.

Update 2021-11-10

Die KNX Association hat mich kontaktiert und erklärt, dass sie ihre Pläne überarbeitet haben. Sie beabsichtigen nun, die Mängel der aktuellen ETS-Version zu dokumentieren und den Projekt-Speicher in einer zukünftigen Version von ETS6 ordnungsgemäß zu verschlüsseln.

Lizenz

Das Projekt wird unter der MIT-Lizenz vertrieben.

Änderungsprotokoll

1.0.0 - 2021-07-18

Commit-Hash:

• c6a3750cefa74d84c5886097cdd0f30dc1bd0dd1

Download:

• Quellcode
• Ausführbare Datei

Änderungen:

• Erste Version