La differenza tra un’azienda sicura e una vulnerabile non risiede nell’assenza di bug, ma nel modo in cui questi vengono gestiti e nell’approccio delle aziende verso i ricercatori di sicurezza.
Recentemente, BreldoItalia, ha compiuto un passo coraggioso e non scontato: ha aperto le porte del proprio ecosistema BreldoBox al team di Hackerhood per un’attività gratuita di testing intensivo.
Il risultato? Un report onesto e allo stesso tempo crudo, che conta circa 70 vulnerabilità, ma che segna allo stesso tempo l’inizio di un percorso di miglioramento senza precedenti per un produttore, che ha capito che la community di hacker etici, può essere puo’ essere una risorsa piuttosto che un fastidio.
L’analisi presentata in questo articolo è stata condotta dai ricercatori di sicurezza Manuel Roccon e Alessandro Sgreccia del team Hackerhood.
Cos’è il Gateway Hotspot BreldoBox
Il BreldoBox è un dispositivo hardware e software dedicato alla gestione e al controllo degli accessi per reti Wi-Fi, utilizzato prevalentemente in contesti aziendali, strutture ricettive e ambienti pubblici ad alta affluenza.
L’apparato adotta un’architettura di tipo Edge: l’elaborazione dei dati, le policy di sicurezza e le funzioni di captive portal, firewall e instradamento del traffico (SD-WAN) avvengono localmente sul dispositivo stesso, riducendo la dipendenza da server cloud esterni.
Le sue funzioni principali includono la segmentazione logica delle reti, l’autenticazione degli utenti ospiti e il monitoraggio del traffico in tempo reale per garantire la stabilità e l’isolamento delle connessioni.
L’anatomia delle vulnerabilità: una radice comune
Le vulnerabilità individuate dal team di Hackerhood si dividono principalmente in tre categorie critiche:
- RCE (Remote Code Execution): Il rischio più elevato, che permette a un attaccante di eseguire comandi arbitrari sul sistema.
- SQLi (SQL Injection): Interrogazioni malevole al database per estrarre o manipolare dati sensibili.
- XSS (Cross-Site Scripting): Iniezione di script lato client per compromettere le sessioni degli utenti.
Perché così tante?
L’analisi ha evidenziato che molte delle vulnerabilità individuate erano riconducibili a componenti software e logiche applicative condivise tra diverse funzionalità del BreldoBox. Questo aspetto ha consentito di identificare rapidamente le cause comuni e di intervenire in modo sistematico, applicando correzioni estese a più aree del prodotto.
CVE: il processo di Disclosure e l’attesa del MITRE
Come da consueta procedura di Responsible Disclosure, dopo aver notificato al produttore e aver permesso l’avvio delle attività di patching, il team ha proceduto alla richiesta degli identificativi CVE (Common Vulnerabilities and Exposures) presso il MITRE.
Attualmente le richieste sono in fase di elaborazione. Data l’entità dei bug scovati e l’attuale carico di lavoro degli enti certificatori, il MITRE ha confermato la presa in carico specificando che l’assegnazione segue un modello di gestione basato sul rischio:
“We have a large volume of CVE requests and we process CVE ID requests on a risk-based management model. We’ll let you know when your request has been processed.”
Nonostante le vulnerabilità totali rilevate nel sistema sfiorino quota 70, la nostra analisi ha isolato i vettori più critici che sono state sottoposte al processo di assegnazione CVE. Nello specifico, l’attenzione si è concentrata su 8 macro-vulnerabilità strutturali:
- 2x Command Injection (RCE): uno sfruttabile previa autenticazione e uno, estremamente critico, accessibile senza credenziali.
- 2x SQL Injection (SQLi): anche in questo caso, un vettore richiede privilegi di accesso, mentre l’altro è esposto pubblicamente (Unauthenticated).
- 3x Cross-Site Scripting (XSS): una combinazione di vulnerabilità di tipo Reflected (sia autenticate che non) e una vulnerabilità Stored, capace di rendere l’attacco persistente sul sistema.
- 1x Broken Access Control: un difetto nella logica di autorizzazione che permette di bypassare i limiti imposti ai profili utente.
Un esempio di trasparenza rara
Va fatto un plauso a BreldoItalia. In un settore dove molti produttori tendono a nascondere le falle sotto il tappeto (il cosiddetto Security through obscurity), Breldo ha scelto la via della trasparenza.
“Collaborare con Hackerhood e rendere pubblici i risultati non è un segno di debolezza, ma un atto di responsabilità verso i propri clienti.”
Questa mentalità consente di trasformare i risultati del testing in un piano di intervento mirato, permettendo al produttore di rafforzare in modo sistematico la sicurezza dei propri dispositivi.
Bravi.
Dai test di sicurezza all’azione
BreldoItalia ha trasformato i risultati dei test di sicurezza in interventi concreti, implementando gli aggiornamenti necessari per correggere le vulnerabilità individuate e rafforzare la protezione dei propri dispositivi.
Il percorso di remediation ha portato al rilascio della patch che aggiorna il firmware Breldo O.S. alla versione 6.1, migliorando ulteriormente la sicurezza dei sistemi e dei servizi offerti.
Come prevenire: l’importanza di SAST e DAST
Per evitare che pattern di errore si ripetano su larga scala, è fondamentale che realtà come Breldo integrino i test di sicurezza direttamente nel ciclo di vita del software (SDLC).
Per garantire la massima sicurezza, i test dovrebbero dividersi in due grandi famiglie:
SAST (Static Application Security Testing): Analizza il codice sorgente “a riposo”, senza eseguire l’applicazione. È fondamentale per scovare i pattern di sviluppo errati (come quelli trovati in BreldoBox) prima ancora che il software venga compilato. È particolarmente efficace nell’individuare pattern di codice che possono dare origine a SQL Injection, Command Injection e altre vulnerabilità prima della distribuzione del software.
DAST (Dynamic Application Security Testing): Analizza l’applicazione mentre è in esecuzione, simulando attacchi dall’esterno (come farebbe un hacker). È perfetto per individuare vulnerabilità di configurazione e problemi di runtime come gli XSS.
L’orizzonte normativo: il Cyber Resilience Act (CRA)
L’iniziativa di BreldoItalia non rappresenta soltanto una scelta orientata alla trasparenza, ma si inserisce pienamente nella direzione indicata dal Cyber Resilience Act (CRA), il regolamento europeo che introduce requisiti obbligatori di cybersicurezza per tutti i prodotti con elementi digitali.
Il CRA impone ai produttori di adottare un approccio security by design e security by default, integrando la sicurezza fin dalle prime fasi di progettazione e garantendo configurazioni sicure per impostazione predefinita.
A questi requisiti si affianca l’obbligo di gestire le vulnerabilità lungo l’intero ciclo di vita del prodotto (5 anni minimo), distribuire aggiornamenti di sicurezza tempestivi e adottare una Coordinated Vulnerability Disclosure (CVD) Policy, mettendo a disposizione un canale dedicato attraverso il quale ricercatori e terze parti possano segnalare in modo responsabile eventuali vulnerabilità.
In questo scenario, attività di penetration testing indipendente e la collaborazione con la comunità della sicurezza non rappresentano soltanto una buona pratica tecnica, ma costituiscono strumenti fondamentali per migliorare la resilienza dei prodotti e facilitare la conformità ai requisiti introdotti dalla normativa europea.
Conclusione
Il caso Breldo-Hackerhood dimostra che la sicurezza informatica non è una destinazione, ma un viaggio continuo. Identificare 70 vulnerabilità non è un fallimento, ma una vittoria della consapevolezza.
Grazie a questa attività, BreldoItalia può ha potuto intervenire sui difetti strutturali del proprio codice, garantendo un prodotto finale decisamente più sicuro.
Se sei una azienda che vuole testare la sicurezza dei propri device o infrastrutture, invia una email a [email protected]. Possiamo analizzare gratuitamente la tua infrastruttura o i tuoi device con i nostri ricercatori di sicurezza.
Ho iniziato la mia carriera occuparmi nella ricerca e nell’implementazioni di soluzioni in campo ICT e nello sviluppo di applicazioni. Al fine di aggiungere aspetti di sicurezza in questi campi, da alcuni anni ho aggiunto competenze inerenti al ramo offensive security (OSCP), occupandomi anche di analisi di sicurezza e pentest in molte organizzazioni.
Aree di competenza: Ethical Hacking, Bug Hunting, Penetration Testing, Red Teaming, Security Research, Cybersecurity Communication