Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2025-56800 — Vulnerabilità di Bypass dell'Autenticazione Locale nell'Applicazione Desktop Reolink | Kitploit
Strumenti/GitHubGitHub/shinycolumn/cve-2025-56800
Analisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebPenetration TestingAutenticazione
GitHubshinycolumn/cve-2025-56800

CVE-2025-56800

Vulnerabilità di Bypass dell'Autenticazione Locale nell'Applicazione Desktop Reolink

Vedi Repository
10 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

CVE-2025-56800

Vulnerabilità di Bypass dell'Autenticazione Locale nell'Applicazione Desktop Reolink

1. Panoramica

Reolink Icon
  • Nome: Applicazione Desktop Reolink
  • Versione: 8.18.12
  • Vendor: Reolink
  • CWE: CWE-290: Authentication Bypass by Spoofing
  • CVSS: 5.1 MEDIUM
  • Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

2. Riepilogo

L'Applicazione Desktop Reolink (versione 8.18.12) contiene una vulnerabilità di bypass dell'autenticazione locale nella sua funzionalità di schermata di blocco. Il codice sorgente dell'applicazione non è impacchettato in un archivio ASAR, lasciando la logica critica di autenticazione, come la verifica della password, esposta in chiaro nei file JavaScript lato client. È sufficiente modificare la logica in questo codice esposto per neutralizzare il controllo della password e bypassare la schermata di blocco.

3. Dettagli

La password della schermata di blocco viene memorizzata e recuperata tramite codice JavaScript nel bundle di risorse locale, in particolare:

root@kitploit:~
%LOCALAPPDATA%\Programs\Reolink\resources\app\~node_modules_sharp_vendor_Sync_recursive_versions_json_~private_main_index_ts.js

Il codice pertinente registra un handler per il comando get_settings_lock_screen_password, che restituisce la password memorizzata dalla proprietà a.settingsManager.lockScreenPassword:

root@kitploit:~
this.registerCommonCmd(
  "get_settings_lock_screen_password",
  "",
  R(function () {
    return N(this, function (e) {
      return [2, a.settingsManager.lockScreenPassword];
    });
  }),
);

Poiché questa logica risiede interamente lato client, un attaccante può modificare il valore di ritorno in "" (una stringa vuota), bypassando efficacemente la schermata di blocco:

root@kitploit:~
return [2, ""];

Dopo aver modificato e salvato questo file, l'applicazione tratterà la schermata di blocco come se non avesse alcuna password, consentendo così l'accesso senza alcuna autenticazione.

Questa vulnerabilità consente a qualsiasi attaccante locale con accesso al file system di bypassare l'autenticazione a livello di applicazione e ottenere pieno accesso all'interfaccia e alle impostazioni dell'applicazione.

Poiché la password non viene validata contro alcuna fonte esterna ed è esposta tramite JavaScript modificabile, questa schermata di blocco non offre alcuna protezione reale.

4. Proof of Concept (PoC)

Il contenuto del codice può essere manomesso eseguendo poc.py.

Lo screenshot seguente mostra la schermata di blocco dell'applicazione Reolink prima della patch, con il prompt della password abilitato: PoC Lo screenshot seguente mostra l'applicazione dopo l'applicazione della patch e il riavvio, senza alcun prompt della password visualizzato: PoC

5. Raccomandazioni

Il codice dell'applicazione deve essere impacchettato in un archivio ASAR e deve essere implementato un processo di verifica dell'integrità, come il controllo del valore hash o della firma del file ASAR, all'avvio. Qualsiasi applicazione che sia stata manomessa deve essere bloccata dall'esecuzione.

La logica critica di autenticazione, come la verifica della password della schermata di blocco, dovrebbe essere gestita all'interno del codice binario nativo, che è più difficile da manomettere, piuttosto che in JavaScript, ove possibile, oppure essere elaborata tramite comunicazione lato server.

6. Riferimenti

  • https://www.cve.org/CVERecord?id=CVE-2025-56800
  • https://nvd.nist.gov/vuln/detail/CVE-2025-56800
Scarica lo strumento