Hanno bucato SharePoint, ma la vera minaccia è Machine Key: backdoor che nessuno considera

A partire dalla fine di luglio 2025, sono stati segnalati casi di abuso attivo di due vulnerabilità insiste in Microsoft SharePoint (CVE-2025-53770 e CVE-2025-53771), entrambe legate a problematiche di deserializzazione (vedere il paragrafo successivo) non sicura. Gli exploit sono rapidamente diventati strumenti pratici nelle mani degli attaccanti, e si fondano su una debolezza spesso sottovalutata: la gestione delle Machine Key in IIS e ASP.NET.

Cos’è la deserializzazione?

La deserializzazione è il processo con cui un’applicazione ricostruisce un oggetto a partire da dati strutturati, tipicamente in formato binario o testuale (ad esempio, JSON, XML, Base64). In pratica, è l’operazione inversa della serializzazione, che serve a trasformare un oggetto in una rappresentazione salvabile o trasmissibile.

Nel contesto di ASP.NET, ad esempio, il meccanismo VIEWSTATE usa la deserializzazione per ricostruire lo stato dei controlli della pagina al ritorno da una richiesta (postback).

Se i dati da deserializzare non sono adeguatamente protetti o validati, un attaccante può iniettare un oggetto malevolo che, al momento della deserializzazione, esegue codice arbitrario sul sistema, generalmente un server.

Cosa sono le Machine Key in IIS e ASP.NET?

Le Machine Key rappresentano un elemento chiave nella sicurezza delle applicazioni ASP.NET: sono utilizzate per firmare (e facoltativamente cifrare) dati riservati come i cookie di autenticazione, lo stato della sessione e, soprattutto, VIEWSTATE, un meccanismo che conserva lo stato dei controlli tra una richiesta e l’altra all’interno delle cosiddette Web Forms.

Il sistema di validazione predefinito di VIEWSTATE si basa su un Message Authentication Code (MAC). Se il MAC è valido, il server considera affidabile l’integrità del VIEWSTATE e procede alla deserializzazione, operazione che – come abbiamo spiegato in precedenza – diventa potenzialmente pericolosa se l’input è controllato da un attaccante.

Il collegamento tra le vulnerabilità di SharePoint e un meccanismo trascurato (Machine Key)

L’analisi recentemente pubblicata su ISC-SANS da Bojan Zdrnja, CTO del team di penetration testing presso INFIGO IS, è particolarmente importante per diverse ragioni tecniche, operative e culturali nel campo della sicurezza informatica.

Zdrnja parte dai due CVE attivamente sfruttati in SharePoint (CVE-2025-53770 e CVE-2025-53771), ma sposta l’attenzione su una conseguenza a lungo termine che la maggior parte degli approfondimenti ancora ignora: la compromissione della Machine Key e la creazione di una backdoor persistente attraverso il meccanismo di VIEWSTATE.

La trattazione si sposta quindi dalla singola vulnerabilità allo scenario di persistenza post-exploit, che è molto più subdolo, duraturo e pericoloso.

VIEWSTATE come vettore di attacco

Il VIEWSTATE contiene un oggetto serializzato restituito al client e poi rispedito al server in occasione di una postback. Se un attaccante è in grado di generare un VIEWSTATE firmato correttamente (con un MAC valido), il server deserializzerà automaticamente il contenuto, anche se malevolo, senza svolgere ulteriori controlli.

Tale funzionalità, combinata con la disponibilità di strumenti come ysoserial.net, permette di creare payload dannosi che eseguono comandi arbitrari sul server. La condizione necessaria è il possesso della Machine Key usata dal server, che consente di firmare correttamente il VIEWSTATE.

Machine Key: modalità di gestione e attacco

In IIS/ASP.NET, le Machine Key possono essere gestite in due modi principali:

• Generazione automatica da parte di IIS (default): le chiavi sono memorizzate nel Registro di sistema. Sono inoltre utilizzate in modo isolato per ogni applicazione (IsolateApps).
• Definizione manuale nel file web.config: necessaria in scenari con bilanciamento di carico per garantire coerenza tra nodi. Quasi sempre in chiaro, a meno di esplicita cifratura (rara nella pratica).

Un attaccante può ottenere le Machine Key in diversi modi, a seconda della modalità di gestione. Quando la chiave è contenuta nel file web.config si possono usare vulnerabilità LFI (Local File Inclusion) o XXE (XML External Entity). Uno script ASPX malevolo può accedere al contenuto del file e stampare le chiavi in output, recuperandole facilmente se non sono crittografate.

La memorizzazione della Machine Key nel Registro di sistema richiede invece l’esecuzione di codice lato server. Come spiega Zdrnja, può essere letta da script ASPX avanzati.

In entrambi i casi, una volta ottenuta la Machine Key, l’attaccante può firmare un qualsiasi VIEWSTATE, anche se cifrato, e inviarlo a qualsiasi endpoint ASP.NET dell’applicazione. Anche se l’endpoint ricevente non è vulnerabile, la presenza di un VIEWSTATE valido ma malevolo comporta l’esecuzione del payload sul server.

Persistenza della minaccia e backdoor applicativa

Una volta compromesso il server, il payload VIEWSTATE può essere utilizzato in qualsiasi momento, finché la Machine Key rimane invariata.

Di fatto ci troviamo dinanzi a una backdoor persistente e silenziosa in quanto la Machine Key:

• Non è rigenerata automaticamente da Windows o IIS.
• Persiste tra i riavvii del sistema.
• Può essere riutilizzata per nuovi attacchi in futuro, anche se la vulnerabilità iniziale è stata corretta con l’installazione delle patch Microsoft.

Zdrnja rivela che IIS registra un evento con codice 4009 nel registro quando la validazione del VIEWSTATE fallisce per deserializzazione anomala. È fondamentale monitorare regolarmente questi eventi per intercettare possibili attacchi in corso.

Conclusioni

Il caso delle vulnerabilità SharePoint CVE-2025-53770 e CVE-2025-53771 ci ricorda una lezione fondamentale: la sicurezza di un’applicazione Web non termina con l’applicazione delle patch di sicurezza. Se un attaccante ottiene codice in esecuzione, può sfruttare caratteristiche legittime del framework per mantenere l’accesso.

La gestione delle Machine Key è una componente critica, spesso trascurata, ma essenziale per evitare che una compromissione temporanea si trasformi in una persistente backdoor server-side.