shinycolumn/cve-2025-56799# Schwachstelle für OS-Befehlsinjektion über den Cache-Bereinigungsplaner in der Reolink-Desktopanwendung
Die Reolink-Desktop-Anwendung (Version 8.18.12) enthält eine OS-Command-Injection-Schwachstelle in ihrer Funktion des Cache-Bereinigungsplaners (coverCacheClearScheduler). Die Anwendung erstellt einen OS-Shell-Befehl unter Verwendung eines temporären Ordnerpfads, der aus einer Konfigurationsdatei innerhalb von gelesen wird. Da dieser Pfadwert keine ordnungsgemäße Eingabebereinigung aufweist, kann ein Angreifer ihn manipulieren, um beliebige OS-Befehle einzuschleusen.
%LOCALAPPDATA%Diese Schwachstelle wird durch den Planer ausgelöst, der automatisch jeden Tag um 3:00 Uhr ausgeführt wird, was dem Angreifer Persistenz auf dem System verschafft. Darüber hinaus wird der eingeschleuste Befehl als Teil des legitimen, digital signierten Reolink.exe-Prozesses ausgeführt, was durch die Umgehung der Erkennung durch Sicherheitslösungen Tarnung gewährt.
Die Anwendung initialisiert einen Planer, der jeden Tag um 3:00 Uhr ausgeführt wird:
{
key: "clearCoverCacheRegularly",
value: function () {
if (this.coverCacheClearScheduler) {
var e = new Date(),
t = new Date(
e.getFullYear(),
e.getMonth(),
e.getDate(),
3,
0,
0,
).getTime();
(e.getTime() > t &&
(t = new Date(
e.getFullYear(),
e.getMonth(),
e.getDate() + 1,
3,
0,
0,
).getTime()),
this.coverCacheClearScheduler.add({
id: this.clearCoverCacheTaskId,
name: "clearCoverCache",
unit: r.ETaskUnit.DAY,
interval: 1,
args: !1,
execute: this.removeCoverCacheDir,
nextTime: t,
isInExact: !0,
}),
this.coverCacheClearScheduler.start());
}
},
}
Die vom Planer ausgeführte Funktion erstellt eine Shell-Befehlszeichenfolge mit der folgenden Logik:
p(
"darwin" === process.platform
? "rm -rf ".concat(t)
: "rd /s /q ".concat(t),
function (t) {
//...
Unter Windows lautet der resultierende Befehl:
rd /s /q %LOCALAPPDATA%\Temp\reolink\<TEMP_FOLDER>\playback-covers
Unter macOS lautet der resultierende Befehl:
rm -rf ~/Library/Caches/reolink/<TEMP_FOLDER>/playback-covers
Da <TEMP_FOLDER> nicht ordnungsgemäß bereinigt wird, kann ein Angreifer über die Manipulation des Ordnernamens zusätzliche Befehle einschleusen, was zur Befehlsausführung führt:
rd /s /q %LOCALAPPDATA%\Temp\reolink\& <COMMAND> &\playback-covers
rm -rf ~/Library/Caches/reolink/& <COMMAND>; echo /playback-covers
Das Auslösen des Angriffs erfordert eine lokale Dateimodifikation, was eine weitere Schwachstelle, die Ausführung von Malware oder physischen Zugriff auf das System voraussetzt.
Obwohl der anfängliche Auslöser relativ schwierig ist, ist der Angriff nach erfolgreicher Ausführung äußerst effektiv, da er Persistenz bietet, indem er das Payload automatisch jeden Tag um 3:00 Uhr erneut ausführt. Diese Persistenz wird durch die Natur der Anwendung als physisches Sicherheitstool, das oft rund um die Uhr läuft, weiter verstärkt. Sie unterstützt außerdem eine Funktion 'Start beim Booten', die sicherstellt, dass das Payload Neustarts übersteht.
Darüber hinaus erlangt der Angreifer erhebliche Tarnung. Der Befehl wird als Teil des vertrauenswürdigen, digital signierten Reolink.exe-Prozesses ausgeführt, was ihn äußerst effektiv bei der Umgehung von EDR- und Anwendungs-Whitelisting-Lösungen macht. Dies ist eine klassische Living-Off-the-Land-Technik (LOTL).
Der Angriff kann durch Ausführen von poc.py ausgeführt werden, das die lokale Konfigurationsdatei modifiziert. Dies wird durch die Verkettung anderer Schwachstellen im Zusammenhang mit unzureichender Verschlüsselung (CVE-2025-56801 und CVE-2025-56802) ermöglicht, die zum Entschlüsseln und erneuten Verschlüsseln der Konfigurationsdatei verwendet werden.
Normalerweise würde das Payload erst um 3:00 Uhr ausgelöst. Da die Anwendung jedoch keine ASAR-Paketierung verwendet, kann der Code für Demonstrationszwecke gepatcht werden, um die Schwachstelle sofort auszulösen.
Das Ausführungsergebnis ist wie folgt:
Weitere Einzelheiten finden Sie unter CVE-2025-56801 für die AES-CFB-IV-Generierungsschwachstelle und CVE-2025-56802 für die AES-CFB-Schlüsselerzeugungs- und -verwaltungsschwachstelle.
Um diese OS-Command-Injection-Schwachstelle grundlegend zu beheben, müssen Sie vermeiden, Werte, die aus nicht vertrauenswürdigen externen Quellen wie Benutzerkonfigurationsdateien gelesen werden, direkt in OS-Shell-Befehlszeichenfolgen aufzunehmen. Die empfohlene Lösung besteht darin, die Verwendung von Shell-Befehlen wie rd oder rm durch native APIs zu ersetzen, die den Pfad als reine Daten und nicht als Befehl behandeln, wie z. B. fs.rm() von Node.js. Diese Methode eliminiert diese Klasse von Schwachstellen vollständig.
Wenn die Erstellung eines Shell-Befehls absolut unvermeidbar ist, muss eine defensive Logik implementiert werden, die alle Sonderzeichen, die eine Befehlsinjektion verursachen könnten, wie &, | und ;, streng validiert und entweder bereinigt oder escaped.