In breve: il codice PHP offuscato è codice reso volutamente illeggibile, di solito tramite codifica e compressione che vengono risolte solo in fase di esecuzione. Modelli tipici di riconoscimento sono eval insieme a base64_decode, gzinflate o str_rot13, righe molto lunghe, stringhe esadecimali e nomi di funzione composti da singoli pezzi. Cerchi con innocui comandi grep, non esegua mai il codice e confronti i ritrovamenti con il pacchetto originale.
Perché gli aggressori nascondono il loro codice
Chi deposita una webshell o una backdoor su un server vuole che resti a lungo inosservata. Il codice leggibile salterebbe all'occhio a qualunque amministratore apra il file, e qualunque scanner lo troverebbe. Perciò gli aggressori impacchettano il loro codice: viene codificato, compresso e solo alla richiesta ricomposto ed eseguito.
Per PHP2Shell non esistono Indicators of Compromise confermati. Il codice offuscato non è una caratteristica di questa vulnerabilità, ma un segno generale che qualcuno ha inserito codice, in qualunque modo. Come trovare e rimuovere le webshell nel complesso lo descrive Riconoscere e rimuovere una webshell. Questo articolo si concentra sulla domanda da cosa si riconosca il codice offuscato.
eval, base64 e simili: i mattoni tipici
L'offuscamento segue quasi sempre lo stesso principio: un blocco di dati illeggibile viene riconvertito da una o più funzioni in codice, che poi viene eseguito. I mattoni seguenti ricorrono sempre.
| Mattone | Esempi | Perché spicca |
|---|---|---|
| Esecuzione | eval, assert con stringa (fino a PHP 7.x), create_function (fino a PHP 7.x) |
esegue testo come codice |
| Decodifica | base64_decode, str_rot13, hex2bin, strrev, convert_uudecode |
rende di nuovo leggibili i dati |
| Decompressione | gzinflate, gzuncompress, gzdecode |
estrae codice incorporato |
| Composizione | catene di chr(), concatenazione di brevi frammenti, escape \x |
nasconde i nomi delle funzioni |
| Chiamata dinamica | variabili come nome di funzione, call_user_func, array_map con stringa |
la chiamata non compare mai in chiaro |
| Accesso al sistema | system, exec, shell_exec, passthru, proc_open, popen |
comandi sul server |
Secondo il manuale PHP, assert() dal PHP 8.0 non valuta più stringhe come codice e create_function() è stata rimossa in PHP 8.0. Sui server con versioni di PHP più vecchie entrambe restano termini di ricerca rilevanti.
Un singolo mattone è raramente sospetto, base64_decode ad esempio molte applicazioni lo usano legittimamente. Diventa sospetta la combinazione: una decodifica il cui risultato confluisce direttamente in un'esecuzione.
Cercare senza rischi: innocui comandi grep
I comandi seguenti scorrono i file solo come testo. Non eseguono codice PHP. Adatti il percorso.
# Esecuzione combinata con decodifica o decompressione
grep -rlE "(eval|assert)\s*\(\s*(base64_decode|gzinflate|gzuncompress|str_rot13|hex2bin)" /var/www --include="*.php*"
# Righe molto lunghe (spesso codice compresso)
grep -rlE ".{2000,}" /var/www --include="*.php*"
# Molti escape esadecimali o catene chr() in una riga
grep -rlE "(\\\\x[0-9a-fA-F]{2}){20,}" /var/www --include="*.php*"
grep -rlE "(chr\s*\(\s*[0-9]+\s*\)\s*\.\s*){8,}" /var/www --include="*.php*"
# Chiamata di funzione tramite una variabile subito dopo un'assegnazione da stringhe
grep -rnE "\\\$[a-zA-Z_]+\s*=\s*['\"][a-z_]{4,}['\"]\s*;\s*\\\$[a-zA-Z_]+\s*\(" /var/www --include="*.php*" | head -50
Verifichi i risultati dapprima con ls -l e la marcatura temporale e li apra poi solo come testo, ad esempio con less. Non richiami mai i file sospetti tramite il browser, perché così il server li eseguirebbe.
Dove si trova tipicamente il codice offuscato
Il codice offuscato raramente sta in un file proprio e vistoso. Più spesso viene inserito in file esistenti, proprio all'inizio o proprio alla fine, spesso dopo molte righe vuote, perché all'apertura non salti subito all'occhio. Sono apprezzati i file caricati a ogni richiesta: l'index.php centrale, i file di configurazione e i file di funzioni di un tema.
Una via particolarmente discreta passa dalla configurazione. Con l'impostazione auto_prepend_file PHP carica un file aggiuntivo prima di ogni script. Se è in un .user.ini o .htaccess creato da un aggressore, il suo codice gira a ogni richiesta di pagina senza che sia stato modificato un solo file dell'applicazione. Il file incluso porta volentieri un'estensione innocua come .ico o .png.
# Prima o dopo ogni script viene caricato del codice aggiuntivo?
grep -rnE "auto_(prepend|append)_file" /var/www --include=".user.ini" --include=".htaccess" --include="*.conf" 2>/dev/null
# Codice PHP in file con estensione di immagine o icona
grep -rlE "<\?php" /var/www --include="*.ico" --include="*.png" --include="*.jpg" --include="*.gif" 2>/dev/null
Distinguere l'offuscamento legittimo dal codice dannoso
Non ogni codice illeggibile è dannoso. Tre casi sono frequenti:
- Encoder commerciali: alcuni produttori di plugin e software proteggono il proprio codice con strumenti come ionCube o SourceGuardian. I file sono illeggibili, ma rimandano tipicamente al loader necessario. Li confronti con il pacchetto originale.
- Codice minificato o generato: cache e motori di template producono righe lunghe senza interruzioni, tuttavia senza eseguire testo decodificato.
- Dati incorporati: immagini o caratteri come stringa Base64 in un file PHP sono insoliti, ma innocui finché il risultato non viene eseguito.
Il test più affidabile è il confronto con la fonte: se il file proviene invariato dal pacchetto del produttore, è legittimo. Se non è in nessun pacchetto originale o ne diverge, va esaminato.
Non tenti di decifrare codice offuscato sul server di produzione, ad esempio sostituendo eval con un'uscita a schermo e richiamando il file. Già un errore in questa operazione esegue il codice dannoso. L'analisi va fatta in un ambiente isolato.
Limiti della ricerca per modelli
Gli aggressori conoscono i comandi di ricerca più comuni. Dividono i nomi delle funzioni, li compongono in fase di esecuzione o spostano il codice vero e proprio nel database, in file immagine o in voci di configurazione. Una ricerca per modelli trova quindi molto, ma non tutto. Perché anche gli scanner incontrino qui dei limiti lo spiega Scanner antimalware per siti web: cosa trovano e cosa no.
Un ritrovamento, inoltre, raramente è l'unico. Gli aggressori usano spesso in più file lo stesso mattone, ad esempio un nome di variabile vistoso o una sequenza di caratteri caratteristica all'inizio del blocco codificato. Dopo un ritrovamento confermato cerchi quindi in modo mirato proprio quella sequenza in tutta la directory web, anche in altri siti sullo stesso server. Così trova i fratelli che nessuna delle ricerche generali per modelli ha colto.
Integri la ricerca con il confronto con i file originali e con uno sguardo al database, vedi Verificare il database alla ricerca di codice inserito. In via preventiva si possono bloccare le funzioni di sistema non necessarie, come descritto nella guida Usare correttamente disable_functions.
Come aiuta concretamente PHP SOS?
- Cercare: esaminiamo file e database con modelli estesi e confrontiamo con i pacchetti originali.
- Analizzare: esaminiamo il codice sospetto in un ambiente isolato, senza mettere a rischio il Suo sistema.
- Bonificare: con la rimozione del malware rimuoviamo tutti i componenti e chiudiamo la via d'ingresso.
- Mettere in sicurezza: limitiamo funzioni PHP e permessi di scrittura e monitoriamo i file nuovi o modificati.
Domande frequenti
eval con base64_decode è sempre codice dannoso?
Non sempre, ma molto spesso. Il codice legittimo non ha quasi mai bisogno di questa combinazione. Nei file che non appartengono alla Sua applicazione o a un plugin noto è un forte segnale d'allarme.
Posso decodificare il codice offuscato per leggerlo?
Solo senza eseguirlo e non sul server di produzione. Già un'esecuzione involontaria può causare danni. Nel dubbio lasci l'analisi a specialisti che lavorano con ambienti isolati.
Perché il mio scanner antimalware non trova il codice?
Gli scanner cercano modelli noti. Gli aggressori modificano continuamente il loro codice, dividono i nomi delle funzioni o li compongono in fase di esecuzione. Una scansione vuota non è quindi una prova di un server pulito.
E i plugin cifrati commercialmente?
Alcuni produttori proteggono il proprio codice con encoder come ionCube o SourceGuardian. Tali file sono illeggibili, ma legittimi se provengono dal produttore. Li confronti con il pacchetto originale.
disable_functions aiuta contro il codice offuscato?
In parte. Funzioni come exec o system si possono bloccare, eval invece no, perché è un costrutto del linguaggio e non una funzione. Il blocco rende più difficile il passo successivo agli aggressori, ma non impedisce ogni codice dannoso.