
Lokale Authentifizierungs-Bypass-Schwachstelle in der Reolink-Desktop-Anwendung
Die Reolink-Desktop-Anwendung (Version 8.18.12) enthält eine lokale Authentifizierungs-Umgehungsschwachstelle in ihrer Sperrbildschirm-Funktion. Der Quellcode der Anwendung ist nicht in einem ASAR-Archiv verpackt, wodurch kritische Authentifizierungslogik, wie die Passwortprüfung, im Klartext in clientseitigen JavaScript-Dateien offengelegt wird. Eine einfache Änderung der Logik in diesem offengelegten Code reicht aus, um die Passwortprüfung zu neutralisieren und den Sperrbildschirm zu umgehen.
Das Sperrbildschirm-Passwort wird über JavaScript-Code im lokalen Ressourcen-Bundle gespeichert und abgerufen, insbesondere:
%LOCALAPPDATA%\Programs\Reolink\resources\app\~node_modules_sharp_vendor_Sync_recursive_versions_json_~private_main_index_ts.js
Der relevante Code registriert einen Handler für den Befehl get_settings_lock_screen_password, der das gespeicherte Passwort aus der Eigenschaft a.settingsManager.lockScreenPassword zurückgibt:
this.registerCommonCmd(
"get_settings_lock_screen_password",
"",
R(function () {
return N(this, function (e) {
return [2, a.settingsManager.lockScreenPassword];
});
}),
);
Da diese Logik vollständig clientseitig liegt, kann ein Angreifer den Rückgabewert auf "" (einen leeren String) patchen und so den Sperrbildschirm effektiv umgehen:
return [2, ""];
Nach dem Ändern und Speichern dieser Datei behandelt die Anwendung den Sperrbildschirm so, als hätte sie kein Passwort, wodurch Zugriff ohne jegliche Authentifizierung gewährt wird.
Diese Schwachstelle ermöglicht es jedem lokalen Angreifer mit Dateisystemzugriff, die Authentifizierung auf Anwendungsebene zu umgehen und vollen Zugriff auf die Anwendungsoberfläche und die Einstellungen zu erhalten.
Da das Passwort nicht gegen eine externe Quelle validiert wird und über modifizierbares JavaScript offengelegt ist, bietet dieser Sperrbildschirm keinen echten Schutz.
Der Inhalt des Codes kann durch Ausführen von poc.py manipuliert werden.
Der folgende Screenshot zeigt den Sperrbildschirm der Reolink-Anwendung vor dem Patchen, mit aktivierter Passwortabfrage:
Der folgende Screenshot zeigt die Anwendung nach dem Anwenden des Patches und dem Neustart, ohne angezeigte Passwortabfrage:

Der Anwendungscode muss in ein ASAR-Archiv verpackt werden, und beim Start muss ein Integritätsprüfungsprozess implementiert werden, wie die Überprüfung des Hash-Werts oder der Signatur der ASAR-Datei. Jede Anwendung, die manipuliert wurde, muss an der Ausführung gehindert werden.
Kritische Authentifizierungslogik, wie die Sperrbildschirm-Passwortprüfung, sollte nach Möglichkeit in nativem Binärcode behandelt werden, der schwerer zu manipulieren ist, anstatt in JavaScript, oder über serverseitige Kommunikation verarbeitet werden.