Rischi di deserializzazione in uso di BinaryFormatter e dei tipi correlati

  • Articolo

Questo articolo si applica ai tipi seguenti:

Questo articolo si applica alle implementazioni .NET seguenti:

  • .NET Framework tutte le versioni
  • .NET Core 2.1 - 3.1
  • .NET 5 e versioni successive

Avviso

Il tipo BinaryFormatter è pericoloso e non è consigliato per l'elaborazione dei dati. Le applicazioni devono smettere di usare BinaryFormatter il prima possibile, anche se ritengono che i dati elaborati siano attendibili. BinaryFormatter non è sicuro e non può essere reso sicuro.

Vulnerabilità della deserializzazione

Le vulnerabilità della deserializzazione sono una categoria di minacce in cui i payload delle richieste vengono elaborati in modo non sicuro. Un utente malintenzionato che sfrutta correttamente queste vulnerabilità contro un'app può causare negazione del servizio (DoS), divulgazione di informazioni o esecuzione remota del codice all'interno dell'app di destinazione. Questa categoria di rischio rende costantemente OWASP Top 10. Le destinazioni includono app scritte in diversi linguaggi, tra cui C/C++, Java e C#.

In .NET la destinazione di rischio più grande è quella delle app che usano il tipo BinaryFormatter per deserializzare i dati. BinaryFormatter è ampiamente usato in tutto l'ecosistema .NET a causa della sua potenza e della sua facilità d'uso. Tuttavia, questa stessa potenza offre agli utenti malintenzionati la possibilità di influenzare il flusso di controllo all'interno dell'app di destinazione. Gli attacchi riusciti possono comportare la possibilità di eseguire codice nel contesto del processo di destinazione.

Come analogia più semplice, si supponga che la chiamata BinaryFormatter.Deserialize a un payload sia l'equivalente di interpretare tale payload come eseguibile autonomo e avviarlo.

Vulnerabilità di sicurezza di BinaryFormatter

Avviso

Il metodo BinaryFormatter.Deserialize non è mai sicuro se usato con input non attendibile. È consigliabile che i consumer considerino invece l'uso di una delle alternative descritte più avanti in questo articolo.

BinaryFormatter è stato implementato prima che le vulnerabilità di deserializzazione fossero una categoria di minacce ben compresa. Di conseguenza, il codice non segue le procedure consigliate moderne. Il metodo Deserialize può essere usato come vettore per gli utenti malintenzionati per eseguire attacchi DoS contro l'utilizzo delle app. Questi attacchi potrebbero impedire all'app di risponde o comportare la terminazione imprevista del processo. Questa categoria di attacco non può essere mitigata con un’opzione di configurazione SerializationBinder o qualsiasi altra opzione di configurazione BinaryFormatter. .NET considera questo comportamento da progettazione e non emette un aggiornamento del codice per modificare il comportamento.

BinaryFormatter.Deserialize può essere vulnerabile ad altre categorie di attacchi, ad esempio la divulgazione di informazioni o l'esecuzione di codice remoto. L'uso di funzionalità come un SerializationBinder personalizzato potrebbe non essere sufficiente per attenuare correttamente questi rischi. Esiste la possibilità che venga individuata una nuova vulnerabilità per cui .NET non può pubblicare praticamente un aggiornamento della sicurezza. Gli utenti devono valutare i singoli scenari e considerare la potenziale esposizione a questi rischi.

È consigliabile che i consumatori BinaryFormatter eseguano valutazioni dei singoli rischi sulle proprie app. È responsabilità esclusiva del consumatore determinare se utilizzare BinaryFormatter. Se si sta valutando l'uso, è consigliabile valutare le conseguenze tecniche, relative alla sicurezza, alla reputazione, alla legalità e alle normative.

Alternative preferite

.NET offre diversi serializzatori predefiniti in grado di gestire in modo sicuro i dati non attendibili:

Alternative pericolose

Evitare i serializzatori seguenti:

Tutti i serializzatori precedenti eseguono la deserializzazione polimorfica senza restrizioni e sono pericolosi, proprio come BinaryFormatter.

I rischi di presumere che i dati siano attendibili

Spesso, uno sviluppatore di app potrebbe credere che stia elaborando solo un input attendibile. Il caso di input sicuro è vero in alcune rare circostanze. Ma è molto più comune che un payload attraversi un limite di attendibilità senza che lo sviluppatore se ne renda conto.

Si consideri un server locale in cui i dipendenti usano un client desktop dalle loro workstation per interagire con il servizio. Questo scenario potrebbe essere considerato ingenuo come una configurazione "sicura" in cui l'utilizzo di BinaryFormatter è accettabile. Tuttavia, questo scenario presenta un vettore di malware che ottiene l'accesso a un singolo computer dipendente per poter essere distribuito in tutta l'azienda. Tale malware può sfruttare l'uso dell'organizzazione di BinaryFormatter per spostarsi successivamente dalla workstation del dipendente al server back-end. Può quindi esfiltrare i dati sensibili dell'azienda. Tali dati possono includere segreti commerciali o dati dei clienti.

Prendere in considerazione anche un'app che usa BinaryFormatter per salvare in modo permanente lo stato di salvataggio. Questo potrebbe inizialmente sembrare uno scenario sicuro, poiché la lettura e la scrittura di dati sul proprio disco rigido rappresentano una minaccia secondaria. Tuttavia, la condivisione di documenti tramite posta elettronica o Internet è diffusa, e la maggior parte degli utenti finali non percepisce l'apertura di questi file scaricati come un comportamento rischioso.

Questo scenario può essere sfruttato per effetti nefasti. Se l'app è un gioco, gli utenti che condividono inconsapevolmente i file di salvataggio si trovano a rischio. Anche gli stessi sviluppatori possono essere presi di mira. L'utente malintenzionato potrebbe inviare un messaggio di posta elettronica al supporto tecnico degli sviluppatori, allegando un file di dati dannosi e chiedendo al personale di supporto di aprirlo. Questo tipo di attacco potrebbe dare all'utente malintenzionato un punto di appoggio nell'azienda.

Un altro scenario è quello in cui il file di dati viene archiviato nell'archiviazione cloud e sincronizzato automaticamente tra i computer dell'utente. Un utente malintenzionato che è in grado di ottenere l'accesso all'account di archiviazione cloud può avvelenare il file di dati. Questo file di dati verrà sincronizzato automaticamente con i computer dell'utente. Alla successiva apertura del file di dati da parte dell'utente malintenzionato, viene eseguito il payload dell'utente malintenzionato. Di conseguenza, l'utente malintenzionato può sfruttare una compromissione di un account di archiviazione cloud per ottenere autorizzazioni complete di esecuzione del codice.

Si consideri un'app che passa da un modello di installazione desktop a un modello cloud-first. Questo scenario include app che passano da un'app desktop o da un modello client avanzato a un modello basato sul Web. I modelli di minaccia disegnati per l'app desktop non sono necessariamente applicabili al servizio basato sul cloud. Il modello di minaccia per l'app desktop potrebbe ignorare una determinata minaccia come "non interessante per il client di attaccarsi". Ma la stessa minaccia potrebbe diventare interessante quando considera un utente remoto (il client) che attacca il servizio cloud stesso.

Nota

In termini generali, la finalità della serializzazione è trasmettere un oggetto all'interno o all'esterno di un'app. Un esercizio di modellazione delle minacce contrassegna quasi sempre questo tipo di trasferimento dei dati come superamento di un limite di attendibilità.

Vedi anche