Quartz 4

Identificazione

4 min read

tags: Identificazione_Deserializzazione Deserializzazione

Dove guardare per capire se c’è serializzazione

Nel contesto web la serializzazione di solito si nasconde in:

  • Cookie di sessione o “remember me”

  • Parametri dell’URL (query string) o hidden field nei form

  • Body di richieste POST/PUT (specialmente se non è JSON “pulito”)

  • Header custom (es. X-User-Data, X-Preferences, ecc.)

  • Oggetti passati via API interne (meno immediato, ma nei lab a volte è simulato)

Approccio pratico con Burp/ZAP:

  1. Intercetti una richiesta.

  2. Guardi TUTTI i parametri:

    • Se vedi stringhe brevi tipo id=5, page=home → poco interessante.

    • Se vedi roba del tipo:

      • stringhe lunghissime Base64-ish (eyJ..., rO0..., Tzox..., ecc.)

      • blob binari o esadecimali molto lunghi
        allora ti scatta il sospetto: “questo potrebbe essere un oggetto serializzato”.

  3. Provi a:

    • Decodificare Base64
      Se dopo il decode vedi:

      • JSON leggibile → probabilmente NO native serialization (è solo JSON).

      • Testo strano con pattern tipo O:8:"stdClass":1:{...} → PHP.

      • Prefisso rO0AB → Java.

      • Sequenze come i:1;s:4:"test"; → PHP serialize.

      • Caratteri binari sporchi con header costante → possibile Java/.NET/Pickle ecc.

PortSwigger definisce proprio l’insecure deserialization come “quando dati controllabili dall’utente vengono deserializzati dall’applicazione”

Tilde

Un metodo comune utilizzato dai pentester è quello di aggiungere una ~ alla fine del nome di un file PHP è una tecnica comune utilizzata dagli aggressori per tentare di accedere a file di backup o temporanei creati da editor di testo o sistemi di controllo versione. Quando un file viene modificato o salvato, alcuni editor di testo o sistemi di controllo versione potrebbero creare una copia di backup del file originale con una tilde aggiunta al nome del file.

Per esempio:

http://10.80.188.227/who/index.php~

Messaggi di errore

Alcuni messaggi di errore possono indicare indirettamente problemi con la serializzazione. Ad esempio, PHP potrebbe generare errori o avvisi che contengono frasi come unserialize() o errore di deserializzazione dell’oggetto, che sono indizi di processi di serializzazione sottostanti e potenziali punti di vulnerabilità.

Incoerenze nel comportamento dell’applicazione

Comportamenti imprevisti in risposta a input manipolati (ad esempio, cookie modificati o dati POST) possono suggerire problemi con il modo in cui i dati vengono deserializzati e gestiti. Osservare il modo in cui l’applicazione gestisce i dati serializzati alterati può fornire indizi sul codice potenzialmente vulnerabile.

Cookie

I cookie vengono spesso utilizzati per archiviare dati serializzati nelle applicazioni web. Esaminando il contenuto dei cookie si può normalmente dedurre:

Se i cookie contengono dati che sembrano codificati Base64, la decodifica potrebbe rivelare oggetti serializzati o strutture dati. PHP utilizza spesso la serializzazione per la gestione delle sessioni e la memorizzazione delle variabili di sessione in formato serializzato.

Stato di visualizzazione ASP.NET

Le applicazioni .NET potrebbero utilizzare la serializzazione nello stato di visualizzazione inviato al browser del client. A volte è possibile vedere un campo denominato __VIEWSTATE, che è codificato base64. Decodificarlo ed esaminarlo può rivelare se contiene dati serializzati che potrebbero essere sfruttati.

Riconoscere i formati più comuni

### Java serialization
 
Pattern tipici:
 
- In **hex**: il flusso Java serializzato inizia spesso con `AC ED 00 05`. 
    
- In **Base64**, lo stesso header appare tipicamente come stringhe che iniziano con:  
    `rO0AB` (frequentissimo).
    
 
Se in un cookie o in un parametro vedi `rO0AB` + roba lunga e incomprensibile, è quasi sicuramente Java serialized object.
 
---
 
### NET
 
Per .NET, tipico pattern:
 
- Stringhe Base64 che iniziano con `AAEAAAD/////` [Cobalt+1]
    
 
Se trovi un valore lunghissimo, Base64, che inizia così → sospetto fortissimo di deserializzazione .NET.
 
---
 
### PHP `serialize() / unserialize()`
 
Molto più leggibile:
 
- Pattern:**`a:`, `s:`, `i:`, `O:`** seguiti da numeri e `;`/`:{`
    
 
Esempio di valore che potresti trovare in un cookie o in un parametro:
 
`a:2:{s:4:"user";s:5:"admin";s:5:"isAdmin";b:1;}`
 
Oppure oggetti:
 
`O:4:"User":2:{s:4:"name";s:5:"admin";s:7:"isAdmin";b:1;}`
 
Questo è classicissimo **PHP serialize()**, ed è proprio collegato alle classiche PHP Object Injection / insecure deserialization. [qwiet.ai+1](https://qwiet.ai/an-insecure-deserialization-cheat-sheet/?utm_source=chatgpt.com)
 
---
 
### Python `pickle`
 
Sul wire si vede come:
 
- Binary blob che può iniziare con `0x80 0x03` o `0x80 0x04` (a seconda del protocollo) 
    
- In Base64 non ha un pattern “carino” come `rO0` (Java), ma spesso, se decodifichi, vedi cose tipo:
    
    - `c__builtin__\nexec\n` oppure
        
    - `cos\nsystem\n(S'ls'...`
        
 
Nel mondo reale `pickle` non è comunissimo in HTTP per le app classiche, ma:
 
- è usatissimo in backend, microservizi, code (es. Celery), ML model loading, ecc. 
    
 
 
---
 
### Altri (giusto per cultura)
 
- **Ruby** (Marshal): header `0408` e struttura particolare.
    
- **Framework custom**: qualche app serializza oggetti in JSON ma con metadati di tipo (es. `$type` in JSON.NET, ecc.), che possono portare comunque a deserializzazione pericolosa.

Graph View