Una vulnerabilità di N-central mette in luce i rischi per gli MSP: cosa significa l’incidente N-able per la sicurezza del tuo RMM?

Il tuo RMM dispone dell’accesso a livello amministrativo a tutti i dispositivi che gestisci, senza intervento dell’utente, a qualsiasi ora e in ogni ambienti client in cui lavori. Questo tipo di accesso non è una funzionalità. È il prodotto. Ed è proprio per questo che la scelta del fornitore di RMM è una delle decisioni più importanti per la sicurezza del tuo stack: non per come funziona quando va tutto bene, ma per ciò che può accadere in caso di problemi.

Il 1° agosto, N-able ha divulgato la vulnerabilità CVE-2026-18577, una lacuna critica in N-central, la piattaforma di RMM utilizzata da migliaia di MSP per applicare patch centralmente e accedere da remoto a tutti i dispositivi dei propri clienti, che permetteva agli utenti malintenzionati di controllare la console a livello amministrativo senza credenziali valide. Una volta all’interno, gli utenti malintenzionati hanno utilizzato la funzionalità di controllo remoto di N-central per raggiungere gli endpoint gestiti, inclusi i controller di dominio, in più organizzazioni, prima che N-able rilasciasse un hotfix il 2 agosto (il rapporto di Huntress sull’incidente contiene la cronologia completa). La stessa settimana CISA ha aggiunto la vulnerabilità al proprio catalogo delle Known Exploited Vulnerabilities e ha ordinato alle agenzie federali statunitensi di applicare la patch entro pochi giorni.

Quando siamo venuti a conoscenza di questa vulnerabilità, abbiamo ripensato alle discussioni avute durante lo sviluppo di LogMeIn Resolve nel 2021, sulla scia di un grave attacco alla supply chain ampiamente documentato. Uno dei nostri ingegneri capo aveva previsto che questi attacchi sarebbero diventati sempre più frequenti e che avremmo dovuto adottare un approccio diverso per proteggere i nostri utenti. Ed è quello che abbiamo fatto con l’architettura Zero Trust di Resolve, aggiungendo controlli pensati per impedire che una singola compromissione a livello di gestione possa si propaghi a cascata e colpisca tutti gli ambienti a valle, ovvero quelli gestiti di cui è responsabile un MPS.

L’architettura di Resolve si basa sul presupposto che prima o poi il server verrà compromesso. La domanda che ci siamo posti è la stessa che oggi rivolgeremmo a qualsiasi fornitore di RMM: “Se l’infrastruttura viene compromessa, cosa può realmente fare un utente malintenzionato?” Nel caso di LogMeIn Resolve, non potrà raggiungere i tuoi endpoint. La chiave di firma Zero Trust può impedire agli utenti malintenzionati di eseguire azioni privilegiate sugli endpoint gestiti, perché nessuno, neanche il fornitore, possiede quella chiave.

L’architettura è uno degli aspetti più importanti, ma non è l’unico da considerare. Prima di discutere nuovamente del rinnovo o di valutare l’adozione di una nuova piattaforma, ecco sei domande da porre al tuo fornitore di RMM.

La maggior parte degli MSP con cui ci interfacciamo considera il modello di distribuzione del proprio RMM come una scelta IT. In realtà si tratta di una decisione di sicurezza, anche se spesso non viene trattata come tale.

L’appliance in locale presenta un problema che spesso viene sottovalutato. È un server che richiede funzionalità come l’applicazione di patch, la protezione avanzata e la sicurezza degli endpoint, ma nella pratica raramente viene trattato in questo modo. Non è una workstation, quindi spesso il rilevamento e la reazione dagli endpoint (EDR) non vengono considerati. Non è un servizio cloud, quindi nessuno monitora la postura di sicurezza: sei tu a doverlo fare. Inoltre, risiede sulla tua rete con accesso elevato a tutti i dispositivi che gestisci.

L’incidente di N-able ha confermato quasi esattamente questo scenario: l’appliance N-central viene eseguita su una build Linux bloccata e, secondo le persone esterne che rispondono all’incidente, in genere non dispone di EDR perché viene gestita come un’appliance anziché come un server.

Con la distribuzione nativa del cloud, questa responsabilità è del fornitore. L’importanza di questo aspetto dipende soltanto da quanto efficacemente il fornitore protegge e sottopone ad audit la propria infrastruttura, ed è proprio ciò che mirano a verificare le domande 3 e 6.

Chiedi al tuo fornitore: “Se utilizzo il tuo prodotto in locale, di cosa sono responsabile per quanto riguarda la sicurezza del server? L’EDR è supportato e consigliato?”

Questa è probabilmente la domanda sull’architettura più importante dell’elenco e dovrebbe essere sempre una delle prime questioni da affrontare con un fornitore. La risposta ti dice praticamente tutto ciò che ti serve sapere sulla sua architettura.

In un’architettura tradizionale basata sull’affidabilità del server, il server rappresenta un nodo affidabile. Un utente malintenzionato che ottiene l’accesso amministrativo al server eredita automaticamente lo stesso livello di affidabilità, compresa la possibilità di inviare comandi e script e avviare sessioni remote a tutti i dispositivi gestiti collegati. Il back-end è la chiave ed è esattamente ciò che è accaduto nell’incidente di N-able: dopo aver compromesso la console, gli utenti malintenzionati hanno utilizzato la funzionalità di controllo remoto integrata per raggiungere gli endpoint gestiti, inclusi i controller di dominio, in più organizzazioni. L’approccio Zero Trust di LogMeIn Resolve è stato progettato per superare proprio questo modello.

Un’architettura Zero Trust funziona in modo diverso. Ogni comando inviato a un endpoint gestito viene firmato con la chiave privata del tecnico, una chiave che rimane sempre sul dispositivo del tecnico. L’endpoint verifica la firma prima di eseguire qualsiasi operazione. Un server back-end compromesso non può inviare comandi dannosi, perché non ha mai avuto accesso alla chiave privata: il back-end conserva esclusivamente la chiave pubblica e non può utilizzarla per ricavare quella privata. Qualsiasi comando che non supera la verifica della firma viene scartato direttamente dal dispositivo senza essere eseguito.

David Bisztrai, VP of Engineering della linea di prodotti LogMeIn di GoTo, l’ha spiegato così: “Immagina una grande cassaforte in una banca. In un sistema tradizionale, gli utenti malintenzionati scavano un tunnel per entrare e, una volta dentro, trovano il vero tesoro, ovvero gli endpoint. Il back-end comunica con il dispositivo, il dispositivo si fida ed esegue ogni tipo di comando. La nostra architettura Zero Trust adotta lo stesso presupposto: qualcuno prima o poi riuscirà a trovare un tunnel per accedere alla cassaforte. Quando l’aprirà, però, non troverà il tesoro, ma migliaia di piccoli armadietti, ognuno dei quali può essere aperto soltanto con una chiave di firma che è esclusivamente in possesso dell’utente e a cui noi non abbiamo accesso. Anche se arrivi alla cassaforte, non puoi aprire nulla”.

Questa è una questione di progettazione, non di applicazione di patch. Nessun hotfix può modificare il modello su cui è costruita la piattaforma del tuo fornitore.

Chiedi al tuo fornitore: “Se la tua infrastruttura venisse completamente compromessa, cosa impedirebbe a un utente malintenzionato di utilizzare la piattaforma per raggiungere i miei endpoint gestiti?”

La velocità è importante. Ma la completezza lo è di più. Si tratta di due questioni diverse ed è proprio in questa differenza che si annida il rischio reale.

Una patch che chiude il vettore di attacco segnalato lasciandone aperto uno adiacente può creare una falsa sensazione di sicurezza, facendo credere che il problema sia risolto. Il rilascio di patch successive per le vulnerabilità degli RMM è una realtà comune in tutto settore e l’incidente di N-able è solo un esempio. Gli utenti malintenzionati hanno utilizzato un nuovo vettore correlato alla correzione precedente.

Non devono necessariamente trovare una nuova vulnerabilità. È sufficiente che la patch del fornitore sia incompleta.

La domanda non è solo: “Quanto velocemente applichi le patch?” Piuttosto è :“Come verifichi che la correzione sia effettivamente completa?” 

Chiedi al tuo fornitore: “Quando è stata l’ultima volta che hai rilasciato una patch aggiuntiva per una vulnerabilità che credevi già risolta e cosa non era stato rilevato durante il processo di testing la prima volta?”

È una questione di logistica, oltre che di sicurezza. È la domanda che la maggior parte degli MSP si pone solo quando è già trascorsa una settimana dal rilascio della patch e metà dei propri server self-hosted è ancora esposta.

Per le implementazioni ospitate nel cloud, i fornitori distribuiscono centralmente gli aggiornamenti di sicurezza: molti utenti nemmeno si accorgono quando una patch viene rilasciata. Per le implementazioni in locale, questa responsabilità ricade su di te.

L’incidente di N-able ha messo in evidenza questo divario. Secondo la telemetria di Huntress sulla propria base di partner e clienti, più della metà dei server N-central ospitati nel cloud raggiungibili non era ancora stata aggiornata il primo giorno successivo al rilascio dell’hotfix di N-able. Con l’aggiornamento successivo, l’applicazione delle patch nel cloud aveva quasi colmato il divario, ma quasi tre server self-hosted raggiungibili su dieci non erano ancora stati aggiornati.

“Il ritardo nell’applicazione delle patch sul campo non è un dettaglio trascurabile: riguarda quel 10% o 20% di dispositivi più lenti che non riesce mai a mettersi completamente al passo. Ed è proprio su questa percentuale che fanno affidamento gli utenti malintenzionati”, ha dichiarato Steve Shattuck, Vice President of Global Partner Ecosystems presso GoTo.

Chiedi al tuo fornitore: “Per un hotfix di sicurezza chiave, quanti dei tuoi clienti normalmente utilizzano ancora una versione vulnerabile dopo 48 ore dopo il rilascio? Come fai a sapere che è effettivamente così?”

La crittografia è ormai un requisito fondamentale. La questione più importante è capire se la piattaforma applica controlli sulle autorizzazioni, mantiene un log di audit e offre all’utente il pieno controllo sul proprio dispositivo. Ciò che distingue realmente i fornitori non riguarda la crittografia delle sessioni come semplice requisito di base.

In questo contesto, l’accesso senza utente è un aspetto che merita particolare attenzione. Come viene configurato? Chi lo approva? Chi può revocarlo? Queste domande definiscono il tuo livello di esposizione e la tua capacità di spiegare a un cliente, guardandolo negli occhi, come vengono realmente gestiti gli accessi ai suoi sistemi.

Chiedi al tuo fornitore: “Una persona può revocare autonomamente l’accesso remoto senza utente, senza dover contattare l’MSP? Dove viene documentata questa funzionalità e in che modo viene resa accessibile all’utente?”

C’è differenza tra un fornitore che dichiara di “prendere sul serio la sicurezza” e uno che possiede certificazioni che hanno richiesto la verifica da parte di un revisore indipendente. La prima è solo un’affermazione. La seconda è una prova.

Certificazioni da prendere in considerazione: ISO/IEC 27001:2022, SOC 2 Type II, BSI C5. Ognuna rappresenta una convalida esterna e verificata tramite audit dei controlli di sicurezza, non un’autovalutazione redatta dal fornitore stesso. Il test di penetrazione esterno condotto da società di terze rappresenta un ulteriore e prezioso livello di garanzia. Sfortunatamente, molti fornitori scelgono di non adottarlo.

Chiedi al tuo fornitore: “Quali certificazioni possiedi e quando hai sostenuto l’ultimo audit? Esegui test di penetrazione esterni e puoi condividerne l’ambito?”

Nessun fornitore può garantire un futuro senza incidenti. Neanche noi. La domanda giusta non è mai stata: “Questo fornitore ha mai avuto un problema?” Piuttosto ci siamo chiesti: “Quando si verifica un problema, cosa fa la sua architettura per limitare i danni?”

Un modello Zero Trust che isola dal punto di vista della crittografia l’accesso agli endpoint da un back-end compromesso è strutturalmente più resiliente, non perché previene ogni attacco, ma perché impedisce che un determinato tipo di attacco si trasformi in una catastrofica reazione a catena. Questa è una caratteristica di progettazione. O esiste o non esiste.

LogMeIn Resolve è stato progettato proprio secondo questo modello, perché il nostro team di ingegneri aveva previsto che le piattaforme di RMM sarebbero diventate obiettivi importanti per gli attacchi alla supply chain. Il recente incidente su N-central dimostra ancora di più quanto sia importante questo approccio architetturale.

Se attualmente utilizzi un RMM che si basa su un modello di affidabilità del server tradizionale, vale la pena porre queste sei domande questa settimana, anziché aspettare il prossimo rinnovo.