Deserialization
Last updated
Last updated
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
La serializzazione è intesa come il metodo di conversione di un oggetto in un formato che può essere preservato, con l'intento di memorizzare l'oggetto o trasmetterlo come parte di un processo di comunicazione. Questa tecnica è comunemente impiegata per garantire che l'oggetto possa essere ricreato in un secondo momento, mantenendo la sua struttura e stato.
La deserializzazione, al contrario, è il processo che contrasta la serializzazione. Comporta il prendere dati che sono stati strutturati in un formato specifico e ricostruirli nuovamente in un oggetto.
La deserializzazione può essere pericolosa perché consente potenzialmente agli attaccanti di manipolare i dati serializzati per eseguire codice dannoso o causare comportamenti imprevisti nell'applicazione durante il processo di ricostruzione dell'oggetto.
In PHP, specifici metodi magici sono utilizzati durante i processi di serializzazione e deserializzazione:
__sleep
: Invocato quando un oggetto viene serializzato. Questo metodo dovrebbe restituire un array dei nomi di tutte le proprietà dell'oggetto che devono essere serializzate. È comunemente usato per impegnare dati in sospeso o eseguire compiti di pulizia simili.
__wakeup
: Chiamato quando un oggetto viene deserializzato. Viene utilizzato per ristabilire eventuali connessioni al database che potrebbero essere state perse durante la serializzazione e per eseguire altri compiti di reinizializzazione.
__unserialize
: Questo metodo viene chiamato invece di __wakeup
(se esiste) quando un oggetto viene deserializzato. Fornisce un maggiore controllo sul processo di deserializzazione rispetto a __wakeup
.
__destruct
: Questo metodo viene chiamato quando un oggetto sta per essere distrutto o quando lo script termina. È tipicamente usato per compiti di pulizia, come la chiusura di gestori di file o connessioni al database.
__toString
: Questo metodo consente a un oggetto di essere trattato come una stringa. Può essere utilizzato per leggere un file o altri compiti basati sulle chiamate di funzione al suo interno, fornendo effettivamente una rappresentazione testuale dell'oggetto.
Se guardi i risultati, puoi vedere che le funzioni __wakeup
e __destruct
vengono chiamate quando l'oggetto viene deserializzato. Nota che in diversi tutorial troverai che la funzione __toString
viene chiamata quando si cerca di stampare un attributo, ma apparentemente non sta più accadendo.
Il metodo __unserialize(array $data)
viene chiamato invece di __wakeup()
se è implementato nella classe. Ti consente di deserializzare l'oggetto fornendo i dati serializzati come un array. Puoi utilizzare questo metodo per deserializzare le proprietà e svolgere eventuali compiti necessari al momento della deserializzazione.
Puoi leggere un esempio PHP spiegato qui: https://www.notsosecure.com/remote-code-execution-via-php-unserialize/, qui https://www.exploit-db.com/docs/english/44756-deserialization-vulnerability.pdf o qui https://securitycafe.ro/2015/01/05/understanding-php-object-injection/
Potresti abusare della funzionalità di autoload di PHP per caricare file php arbitrari e altro:
PHP - Deserialization + Autoload ClassesSe per qualche motivo vuoi serializzare un valore come una riferimento a un altro valore serializzato puoi:
PHPGGC può aiutarti a generare payload per abusare delle deserializzazioni PHP.
Nota che in diversi casi non sarai in grado di trovare un modo per abusare di una deserializzazione nel codice sorgente dell'applicazione, ma potresti essere in grado di abusare del codice di estensioni PHP esterne.
Quindi, se puoi, controlla il phpinfo()
del server e cerca su internet (e anche sui gadgets di PHPGGC) alcuni possibili gadget che potresti abusare.
Se hai trovato un LFI che sta solo leggendo il file e non eseguendo il codice php al suo interno, ad esempio utilizzando funzioni come file_get_contents(), fopen(), file() o file_exists(), md5_file(), filemtime() o filesize(). Puoi provare ad abusare di una deserializzazione che si verifica quando leggi un file utilizzando il protocollo phar. Per ulteriori informazioni leggi il seguente post:
phar:// deserializationQuando l'oggetto viene deserializzato, la funzione __reduce__ verrà eseguita. Quando sfruttato, il server potrebbe restituire un errore.
Prima di controllare la tecnica di bypass, prova a usare print(base64.b64encode(pickle.dumps(P(),2)))
per generare un oggetto compatibile con python2 se stai eseguendo python3.
Per ulteriori informazioni su come evadere da pickle jails controlla:
Bypass Python sandboxesLa seguente pagina presenta la tecnica per abuse an unsafe deserialization in yamls delle librerie python e termina con uno strumento che può essere utilizzato per generare payload di deserializzazione RCE per Pickle, PyYAML, jsonpickle e ruamel.yaml:
Python Yaml DeserializationJS non ha funzioni "magiche" come PHP o Python che vengono eseguite solo per creare un oggetto. Ma ha alcune funzioni che sono frequentemente usate anche senza chiamarle direttamente come toString
, valueOf
, toJSON
.
Se abusi di una deserializzazione puoi compromettere queste funzioni per eseguire altro codice (potenzialmente abusando delle inquinamenti del prototipo) potresti eseguire codice arbitrario quando vengono chiamate.
Un altro modo "magico" per chiamare una funzione senza chiamarla direttamente è compromettendo un oggetto restituito da una funzione async (promise). Perché, se trasformi quell'oggetto di ritorno in un'altra promise con una proprietà chiamata "then" di tipo funzione, verrà eseguito solo perché è restituito da un'altra promise. Segui questo link per ulteriori informazioni.
__proto__
e inquinamento di prototype
Se vuoi imparare su questa tecnica dai un'occhiata al seguente tutorial:
NodeJS - __proto__ & prototype PollutionQuesta libreria consente di serializzare funzioni. Esempio:
L'oggetto serializzato apparirà come:
Puoi vedere nell'esempio che quando una funzione è serializzata, il flag _$$ND_FUNC$$_
viene aggiunto all'oggetto serializzato.
All'interno del file node-serialize/lib/serialize.js
puoi trovare lo stesso flag e come il codice lo utilizza.
Come puoi vedere nell'ultimo blocco di codice, se il flag viene trovato eval
viene utilizzato per deserializzare la funzione, quindi fondamentalmente l'input dell'utente viene utilizzato all'interno della funzione eval
.
Tuttavia, serializzare semplicemente una funzione non la eseguirà poiché sarebbe necessario che qualche parte del codice chiamasse y.rce
nel nostro esempio e questo è altamente improbabile.
Comunque, potresti semplicemente modificare l'oggetto serializzato aggiungendo alcune parentesi in modo da eseguire automaticamente la funzione serializzata quando l'oggetto viene deserializzato.
Nel prossimo blocco di codice nota l'ultima parentesi e come la funzione unserialize
eseguirà automaticamente il codice:
Come indicato in precedenza, questa libreria otterrà il codice dopo _$$ND_FUNC$$_
e lo eseguirà utilizzando eval
. Pertanto, per eseguire automaticamente il codice puoi eliminare la parte di creazione della funzione e l'ultima parentesi e eseguire semplicemente un oneliner JS come nel seguente esempio:
Puoi trovare qui ulteriori informazioni su come sfruttare questa vulnerabilità.
Un aspetto notevole di funcster è l'inaccessibilità degli oggetti standard incorporati; essi rientrano al di fuori dell'ambito accessibile. Questa restrizione impedisce l'esecuzione di codice che tenta di invocare metodi su oggetti incorporati, portando a eccezioni come "ReferenceError: console is not defined"
quando vengono utilizzati comandi come console.log()
o require(something)
.
Nonostante questa limitazione, è possibile ripristinare l'accesso completo al contesto globale, inclusi tutti gli oggetti standard incorporati, attraverso un approccio specifico. Sfruttando direttamente il contesto globale, si può eludere questa restrizione. Ad esempio, l'accesso può essere ripristinato utilizzando il seguente frammento:
Per maggiori informazioni leggi questa fonte.
Il pacchetto serialize-javascript è progettato esclusivamente per scopi di serializzazione, mancando di qualsiasi capacità di deserializzazione integrata. Gli utenti sono responsabili dell'implementazione del proprio metodo per la deserializzazione. Un uso diretto di eval
è suggerito dall'esempio ufficiale per deserializzare i dati serializzati:
Se questa funzione viene utilizzata per deserializzare oggetti, puoi sfruttarla facilmente:
Per maggiori informazioni leggi questa fonte.
Nelle pagine seguenti puoi trovare informazioni su come abusare di questa libreria per eseguire comandi arbitrari:
In Java, i callback di deserializzazione vengono eseguiti durante il processo di deserializzazione. Questa esecuzione può essere sfruttata da attaccanti che creano payload dannosi che attivano questi callback, portando a potenziali esecuzioni di azioni dannose.
Per identificare potenziali vulnerabilità di serializzazione nel codice, cerca:
Classi che implementano l'interfaccia Serializable
.
Utilizzo delle funzioni java.io.ObjectInputStream
, readObject
, readUnshare
.
Fai particolare attenzione a:
XMLDecoder
utilizzato con parametri definiti da utenti esterni.
Il metodo fromXML
di XStream
, specialmente se la versione di XStream è minore o uguale a 1.46, poiché è suscettibile a problemi di serializzazione.
ObjectInputStream
accoppiato con il metodo readObject
.
Implementazione di metodi come readObject
, readObjectNodData
, readResolve
o readExternal
.
ObjectInputStream.readUnshared
.
Uso generale di Serializable
.
Per il testing in black box, cerca specifiche firme o "Magic Bytes" che denotano oggetti serializzati java (provenienti da ObjectInputStream
):
Modello esadecimale: AC ED 00 05
.
Modello Base64: rO0
.
Intestazioni di risposta HTTP con Content-type
impostato su application/x-java-serialized-object
.
Modello esadecimale che indica una compressione precedente: 1F 8B 08 00
.
Modello Base64 che indica una compressione precedente: H4sIA
.
File web con estensione .faces
e il parametro faces.ViewState
. Scoprire questi modelli in un'applicazione web dovrebbe indurre a un esame come dettagliato nel post sulla Deserializzazione del ViewState di Java JSF.
Se vuoi imparare come funziona un exploit di deserializzazione Java dovresti dare un'occhiata a Deserializzazione Java di Base, Deserializzazione DNS Java e Payload CommonsCollection1.
Puoi controllare se è installata qualche applicazione con vulnerabilità note.
Puoi provare a controllare tutte le librerie note per essere vulnerabili e per le quali Ysoserial può fornire un exploit. Oppure puoi controllare le librerie indicate su Java-Deserialization-Cheat-Sheet. Puoi anche usare gadgetinspector per cercare possibili catene di gadget che possono essere sfruttate. Quando esegui gadgetinspector (dopo averlo costruito) non preoccuparti dei tonnellate di avvisi/errori che sta attraversando e lascialo finire. Scriverà tutte le scoperte sotto gadgetinspector/gadget-results/gadget-chains-year-month-day-hore-min.txt. Si prega di notare che gadgetinspector non creerà un exploit e potrebbe indicare falsi positivi.
Utilizzando l'estensione Burp gadgetprobe puoi identificare quali librerie sono disponibili (e anche le versioni). Con queste informazioni potrebbe essere più facile scegliere un payload per sfruttare la vulnerabilità.
Leggi questo per saperne di più su GadgetProbe.
GadgetProbe è focalizzato sulle deserializzazioni ObjectInputStream
.
Utilizzando l'estensione Burp Java Deserialization Scanner puoi identificare librerie vulnerabili sfruttabili con ysoserial e sfruttarle.
Leggi questo per saperne di più su Java Deserialization Scanner.
Java Deserialization Scanner è focalizzato sulle deserializzazioni ObjectInputStream
.
Puoi anche usare Freddy per rilevare vulnerabilità di deserializzazione in Burp. Questo plugin rileverà non solo vulnerabilità relative a ObjectInputStream
ma anche vulnerabilità da librerie di deserializzazione Json e Yml. In modalità attiva, cercherà di confermarle utilizzando payload di sleep o DNS.
Puoi trovare ulteriori informazioni su Freddy qui.
Test di Serializzazione
Non si tratta solo di controllare se qualche libreria vulnerabile è utilizzata dal server. A volte potresti essere in grado di modificare i dati all'interno dell'oggetto serializzato e bypassare alcuni controlli (forse concederti privilegi di amministratore all'interno di un'app web). Se trovi un oggetto Java serializzato inviato a un'applicazione web, puoi usare SerializationDumper per stampare in un formato più leggibile dall'uomo l'oggetto di serializzazione che viene inviato. Sapere quali dati stai inviando renderebbe più facile modificarli e bypassare alcuni controlli.
Lo strumento principale per sfruttare le deserializzazioni Java è ysoserial (scarica qui). Puoi anche considerare di usare ysoseral-modified che ti permetterà di usare comandi complessi (con pipe ad esempio).
Nota che questo strumento è focalizzato sullo sfruttamento di ObjectInputStream
.
Inizierei usando il payload "URLDNS" prima di un payload RCE per testare se l'iniezione è possibile. Comunque, nota che forse il payload "URLDNS" non funziona ma un altro payload RCE sì.
Quando crei un payload per java.lang.Runtime.exec() non puoi usare caratteri speciali come ">" o "|" per reindirizzare l'output di un'esecuzione, "$()" per eseguire comandi o anche passare argomenti a un comando separati da spazi (puoi fare echo -n "hello world"
ma non puoi fare python2 -c 'print "Hello world"'
). Per codificare correttamente il payload potresti usare questa pagina web.
Sentiti libero di usare il prossimo script per creare tutti i possibili payload di esecuzione del codice per Windows e Linux e poi testarli sulla pagina web vulnerabile:
Puoi usare https://github.com/pwntester/SerialKillerBypassGadgetCollection insieme a ysoserial per creare più exploit. Maggiori informazioni su questo strumento nelle diapositive del talk in cui lo strumento è stato presentato: https://es.slideshare.net/codewhitesec/java-deserialization-vulnerabilities-the-forgotten-bug-class?next_slideshow=1
marshalsec può essere utilizzato per generare payload per sfruttare diverse librerie di serializzazione Json e Yml in Java.
Per compilare il progetto ho dovuto aggiungere queste dipendenze a pom.xml
:
Installa maven, e compila il progetto:
Leggi di più su questa libreria Java JSON: https://www.alphabot.com/security/blog/2020/java/Fastjson-exceptional-deserialization-vulnerabilities.html
Se vuoi testare alcuni payload ysoserial puoi eseguire questa webapp: https://github.com/hvqzao/java-deserialize-webapp
Java utilizza molto la serializzazione per vari scopi come:
Richieste HTTP: La serializzazione è ampiamente impiegata nella gestione dei parametri, ViewState, cookie, ecc.
RMI (Remote Method Invocation): Il protocollo RMI di Java, che si basa interamente sulla serializzazione, è un pilastro per la comunicazione remota nelle applicazioni Java.
RMI su HTTP: Questo metodo è comunemente usato dalle applicazioni web client pesanti basate su Java, utilizzando la serializzazione per tutte le comunicazioni tra oggetti.
JMX (Java Management Extensions): JMX utilizza la serializzazione per trasmettere oggetti attraverso la rete.
Protocolli personalizzati: In Java, la prassi standard prevede la trasmissione di oggetti Java grezzi, che verrà dimostrata negli esempi di exploit futuri.
Una classe che implementa Serializable
può implementare come transient
qualsiasi oggetto all'interno della classe che non dovrebbe essere serializzabile. Ad esempio:
In scenari in cui determinati oggetti devono implementare l'interfaccia Serializable
a causa della gerarchia delle classi, c'è il rischio di deserializzazione involontaria. Per prevenire ciò, assicurati che questi oggetti non siano deserializzabili definendo un metodo readObject()
final
che lanci costantemente un'eccezione, come mostrato di seguito:
Personalizzare java.io.ObjectInputStream
è un approccio pratico per garantire la sicurezza dei processi di deserializzazione. Questo metodo è adatto quando:
Il codice di deserializzazione è sotto il tuo controllo.
Le classi previste per la deserializzazione sono conosciute.
Sovrascrivi il resolveClass()
metodo per limitare la deserializzazione solo alle classi consentite. Questo impedisce la deserializzazione di qualsiasi classe tranne quelle esplicitamente autorizzate, come nell'esempio seguente che limita la deserializzazione solo alla classe Bicycle
:
Utilizzare un agente Java per il miglioramento della sicurezza offre una soluzione di riserva quando la modifica del codice non è possibile. Questo metodo si applica principalmente per il blacklisting di classi dannose, utilizzando un parametro JVM:
Fornisce un modo per proteggere la deserializzazione in modo dinamico, ideale per ambienti in cui le modifiche immediate al codice sono impraticabili.
Controlla un esempio in rO0 by Contrast Security
Implementazione dei filtri di serializzazione: Java 9 ha introdotto i filtri di serializzazione tramite l'interfaccia ObjectInputFilter
, fornendo un meccanismo potente per specificare i criteri che gli oggetti serializzati devono soddisfare prima di essere deserializzati. Questi filtri possono essere applicati globalmente o per stream, offrendo un controllo granulare sul processo di deserializzazione.
Per utilizzare i filtri di serializzazione, puoi impostare un filtro globale che si applica a tutte le operazioni di deserializzazione o configurarlo dinamicamente per stream specifici. Ad esempio:
Sfruttare le librerie esterne per una sicurezza migliorata: Librerie come NotSoSerial, jdeserialize e Kryo offrono funzionalità avanzate per controllare e monitorare la deserializzazione in Java. Queste librerie possono fornire ulteriori livelli di sicurezza, come la whitelist o blacklist di classi, l'analisi di oggetti serializzati prima della deserializzazione e l'implementazione di strategie di serializzazione personalizzate.
NotSoSerial intercetta i processi di deserializzazione per prevenire l'esecuzione di codice non attendibile.
jdeserialize consente l'analisi di oggetti Java serializzati senza deserializzarli, aiutando a identificare contenuti potenzialmente dannosi.
Kryo è un framework di serializzazione alternativo che enfatizza velocità ed efficienza, offrendo strategie di serializzazione configurabili che possono migliorare la sicurezza.
Deserializzazione e talk di ysoserial: http://frohoff.github.io/appseccali-marshalling-pickles/
Documento Marshalsec: https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true
Documento sulla deserializzazione di Java e .Net JSON paper: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf, talk: https://www.youtube.com/watch?v=oUAeWhW5b8c e slide: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf
CVE di deserializzazione: https://paper.seebug.org/123/
Scopri cos'è l'iniezione JNDI, come abusarne tramite RMI, CORBA & LDAP e come sfruttare log4shell (e un esempio di questa vulnerabilità) nella seguente pagina:
JNDI - Java Naming and Directory Interface & Log4ShellL'API Java Message Service (JMS) è un'API middleware orientata ai messaggi in Java per inviare messaggi tra due o più client. È un'implementazione per gestire il problema del produttore-consumatore. JMS è parte della Java Platform, Enterprise Edition (Java EE), ed è stata definita da una specifica sviluppata presso Sun Microsystems, ma che da allora è stata guidata dal Java Community Process. È uno standard di messaggistica che consente ai componenti dell'applicazione basati su Java EE di creare, inviare, ricevere e leggere messaggi. Consente la comunicazione tra diversi componenti di un'applicazione distribuita di essere debolmente accoppiata, affidabile e asincrona. (Da Wikipedia).
Ci sono diversi prodotti che utilizzano questo middleware per inviare messaggi:
Quindi, fondamentalmente ci sono un sacco di servizi che utilizzano JMS in modo pericoloso. Pertanto, se hai sufficienti privilegi per inviare messaggi a questi servizi (di solito avrai bisogno di credenziali valide) potresti essere in grado di inviare oggetti maligni serializzati che verranno deserializzati dal consumatore/sottoscrittore. Questo significa che in questo sfruttamento tutti i client che utilizzeranno quel messaggio verranno infettati.
Dovresti ricordare che anche se un servizio è vulnerabile (perché deserializza in modo insicuro l'input dell'utente) devi comunque trovare gadget validi per sfruttare la vulnerabilità.
Lo strumento JMET è stato creato per connettersi e attaccare questi servizi inviando diversi oggetti maligni serializzati utilizzando gadget noti. Questi exploit funzioneranno se il servizio è ancora vulnerabile e se uno dei gadget utilizzati è all'interno dell'applicazione vulnerabile.
Talk su JMET: https://www.youtube.com/watch?v=0h8DWiOWGGA
Nel contesto di .Net, gli exploit di deserializzazione operano in modo simile a quelli trovati in Java, dove i gadget vengono sfruttati per eseguire codice specifico durante la deserializzazione di un oggetto.
Il codice sorgente dovrebbe essere ispezionato per la presenza di:
TypeNameHandling
JavaScriptTypeResolver
L'attenzione dovrebbe essere rivolta ai serializer che consentono di determinare il tipo tramite una variabile sotto il controllo dell'utente.
La ricerca dovrebbe mirare alla stringa codificata in Base64 AAEAAAD///// o a qualsiasi modello simile che potrebbe subire deserializzazione sul lato server, concedendo il controllo sul tipo da deserializzare. Questo potrebbe includere, ma non è limitato a, strutture JSON o XML con TypeObject
o $type
.
In questo caso puoi utilizzare lo strumento ysoserial.net per creare gli exploit di deserializzazione. Una volta scaricato il repository git, dovresti compilare lo strumento utilizzando Visual Studio, ad esempio.
Se vuoi sapere come ysoserial.net crea il suo exploit puoi controllare questa pagina dove viene spiegato il gadget ObjectDataProvider + ExpandedWrapper + Json.Net formatter.
Le principali opzioni di ysoserial.net sono: --gadget
, --formatter
, --output
e --plugin
.
--gadget
utilizzato per indicare il gadget da abusare (indica la classe/funzione che verrà abusata durante la deserializzazione per eseguire comandi).
--formatter
, utilizzato per indicare il metodo per serializzare l'exploit (devi sapere quale libreria sta utilizzando il back-end per deserializzare il payload e usare la stessa per serializzarlo)
--output
utilizzato per indicare se vuoi l'exploit in raw o base64 codificato. Nota che ysoserial.net coderà il payload utilizzando UTF-16LE (codifica utilizzata per impostazione predefinita su Windows) quindi se ottieni il raw e lo codifichi semplicemente da una console linux potresti avere alcuni problemi di compatibilità di codifica che impediranno all'exploit di funzionare correttamente (nella box JSON di HTB il payload ha funzionato sia in UTF-16LE che in ASCII, ma questo non significa che funzionerà sempre).
--plugin
ysoserial.net supporta plugin per creare exploit per framework specifici come ViewState
--minify
fornirà un payload più piccolo (se possibile)
--raf -f Json.Net -c "anything"
Questo indicherà tutti i gadget che possono essere utilizzati con un formatter fornito (Json.Net
in questo caso)
--sf xml
puoi indicare un gadget (-g
) e ysoserial.net cercherà formatter che contengono "xml" (case insensitive)
Esempi di ysoserial per creare exploit:
ysoserial.net ha anche un parametro molto interessante che aiuta a comprendere meglio come funziona ogni exploit: --test
Se indichi questo parametro, ysoserial.net proverà l'exploit localmente, così puoi testare se il tuo payload funzionerà correttamente.
Questo parametro è utile perché se rivedi il codice troverai pezzi di codice come il seguente (da ObjectDataProviderGenerator.cs):
Questo significa che per testare l'exploit il codice chiamerà serializersHelper.JsonNet_deserialize
In the codice precedente è vulnerabile all'exploit creato. Quindi, se trovi qualcosa di simile in un'applicazione .Net, significa che probabilmente anche quell'applicazione è vulnerabile.
Pertanto, il --test
parametro ci consente di capire quali parti di codice sono vulnerabili all'exploit di deserializzazione che ysoserial.net può creare.
Dai un'occhiata a questo POST su come provare a sfruttare il parametro __ViewState di .Net per eseguire codice arbitrario. Se conosci già i segreti utilizzati dalla macchina vittima, leggi questo post per sapere come eseguire codice.
Per mitigare i rischi associati alla deserializzazione in .Net:
Evitare di consentire ai flussi di dati di definire i propri tipi di oggetto. Utilizzare DataContractSerializer
o XmlSerializer
quando possibile.
Per JSON.Net
, impostare TypeNameHandling
su None
: %%%TypeNameHandling = TypeNameHandling.None%%%
Evitare di utilizzare JavaScriptSerializer
con un JavaScriptTypeResolver
.
Limitare i tipi che possono essere deserializzati, comprendendo i rischi intrinseci con i tipi .Net, come System.IO.FileInfo
, che può modificare le proprietà dei file del server, potenzialmente portando ad attacchi di denial of service.
Essere cauti con i tipi che hanno proprietà rischiose, come System.ComponentModel.DataAnnotations.ValidationException
con la sua proprietà Value
, che può essere sfruttata.
Controllare in modo sicuro l'istanza dei tipi per prevenire che gli attaccanti influenzino il processo di deserializzazione, rendendo vulnerabili anche DataContractSerializer
o XmlSerializer
.
Implementare controlli di white list utilizzando un SerializationBinder
personalizzato per BinaryFormatter
e JSON.Net
.
Rimanere informati sui gadget di deserializzazione insicuri noti all'interno di .Net e assicurarsi che i deserializzatori non istanzino tali tipi.
Isolare il codice potenzialmente rischioso dal codice con accesso a Internet per evitare di esporre gadget noti, come System.Windows.Data.ObjectDataProvider
nelle applicazioni WPF, a fonti di dati non attendibili.
Documento sulla deserializzazione JSON in Java e .Net: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf, talk: https://www.youtube.com/watch?v=oUAeWhW5b8c e slide: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-Json-Attacks.pdf
In Ruby, la serializzazione è facilitata da due metodi all'interno della libreria marshal. Il primo metodo, noto come dump, viene utilizzato per trasformare un oggetto in un flusso di byte. Questo processo è noto come serializzazione. Al contrario, il secondo metodo, load, viene impiegato per riportare un flusso di byte in un oggetto, un processo noto come deserializzazione.
Per proteggere gli oggetti serializzati, Ruby utilizza HMAC (Hash-Based Message Authentication Code), garantendo l'integrità e l'autenticità dei dati. La chiave utilizzata per questo scopo è memorizzata in uno dei diversi possibili luoghi:
config/environment.rb
config/initializers/secret_token.rb
config/secrets.yml
/proc/self/environ
Catena di gadget di deserializzazione generica Ruby 2.X a RCE (maggiori informazioni in https://www.elttam.com/blog/ruby-deserialization/):
Altra catena RCE per sfruttare Ruby On Rails: https://codeclimate.com/blog/rails-remote-code-execution-vulnerability-explained/
Come spiegato in questo rapporto di vulnerabilità, se un input non sanitizzato di un utente raggiunge il metodo .send()
di un oggetto ruby, questo metodo consente di invocare qualsiasi altro metodo dell'oggetto con qualsiasi parametro.
Ad esempio, chiamare eval e poi codice ruby come secondo parametro permetterà di eseguire codice arbitrario:
Inoltre, se solo un parametro di .send()
è controllato da un attaccante, come menzionato nel precedente articolo, è possibile chiamare qualsiasi metodo dell'oggetto che non necessita di argomenti o i cui argomenti hanno valori predefiniti.
Per questo, è possibile enumerare tutti i metodi dell'oggetto per trovare alcuni metodi interessanti che soddisfano tali requisiti.
Questa tecnica è stata presa da questo post del blog.
Ci sono altre librerie Ruby che possono essere utilizzate per serializzare oggetti e quindi che potrebbero essere abusate per ottenere RCE durante una deserializzazione insicura. La seguente tabella mostra alcune di queste librerie e il metodo che chiamano della libreria caricata ogni volta che viene deserializzata (funzione da abusare per ottenere RCE fondamentalmente):
Libreria
Dati di input
Metodo di avvio all'interno della classe
Marshal (Ruby)
Binario
_load
Oj
JSON
hash
(la classe deve essere inserita in hash(mappa) come chiave)
Ox
XML
hash
(la classe deve essere inserita in hash(mappa) come chiave)
Psych (Ruby)
YAML
hash
(la classe deve essere inserita in hash(mappa) come chiave)
init_with
JSON (Ruby)
JSON
json_create
([vedi note riguardo json_create alla fine](#table-vulnerable-sinks))
Esempio base:
Nel caso di tentare di abusare di Oj, è stato possibile trovare una classe gadget che all'interno della sua funzione hash
chiamerà to_s
, che chiamerà spec, che chiamerà fetch_path, il che è stato possibile farlo recuperare un URL casuale, fornendo un ottimo rilevatore di questo tipo di vulnerabilità di deserializzazione non sanificate.
Inoltre, è stato scoperto che con la tecnica precedente viene anche creata una cartella nel sistema, che è un requisito per abusare di un altro gadget al fine di trasformare questo in un RCE completo con qualcosa come:
Controlla ulteriori dettagli nel post originale.
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)