Lezione del 21/03/2024

Questa videolezione e’ stata ripresa senza la parte relativo allo schermo, quindi non ci saranno probabilmente screenshot e li andro’ ad integrare eventualmente piu’ avanti.

Solitamente si lavora con questa configurazione: web server - application logic - database

La logica applicativa che viene eseguita e’ la cosa che ci interessa di piu’ sicuramente. Perche’ vogliamo andare ad accedere a dei contenuti che vengono generati da pagine dinamiche. Quindi i problemi li possiamo andare tranquillamente a trovare all’interno della logica applicativa. Consideriamo per altro che per quel che riguarda la persistenza di dati si utilizzi una qualche forma di database.

Tipicamente identifico una DMZ che e’ sicuro per definizione ed espongo le macchine che sono aperte ad internet (server http). Quesa zona deve essere sicuramente circondata da firewall. Questo espone le macchine ad una serie di attacchi. L’application server non deve essere in DMZ. In DMZ ho solo http server, smtp server, app gateway, ftp serer. Posizionamento fisico puo’ avere conseguenze interessanti anche per un attaccante.

[00:08:00]

OS Command Injection

Quando abbiamo una applicazione web che espone delle vulnerabilita’ possiamo in realta’ poter andare ad eseguire dei comandi come se fossimo connessi localmente. Puoi vedere tutto questo con OWASP, che praticamente e’ una associazione che e’ attiva e produce doc e software utile per applicazioni web. Tra i vari progetti, anche se sono obsoleti, ci sono broker web application broker. E’ una singola immagine VM, Non ha interfaccia grafica e fa tutto quanto da linea di comando ed e’ configurata affinche’ sia raggiungibile tramite NAT localhost, questo e’ quello che sta facendo il professore nella lezione. Questa VM contiene un sacco di operazione diverse, molto carino per andare a fare test e quant’altro. Ci sono anche progetti piu’ aggiornati. Molto comodo perche’ ho gia’ tutto quanto dentro. Ci sono app didattiche, nate proprio per scopo didattico per andare a fare per esempio sql injection. poi troviamo delle applicazioni vulnerabili ma realistiche. Ovviamente vanno a mimare delle applicazioni reali. la parte ancora piu’ interessante e’e quella con le applicazioni vecchie, con roba che un tempo era effettivamente in produzione. Tutta roba senza patch di sicurezza. Si entra con admin admin all’interno di DWA ed e’ basata su PHP. Molto didattica come app in cui possiamo scegliere che tipo di vulnerabilita’ vogliamo andare ad esplorare. Possiamo andare anche a ressetare il database. Abbiamo anche modo di andare a selezionare il livello di sicurezza.

Come prima cosa il prof fa vedere che possiamo praticamente fare ping da una search bar che non controlla assolutamente alcun tipo di input.

Questo metodo e’ veramente un nightmare di andare a fare una applicazione. Il sito dovrebbe far fare ping for free, ma il backend e’ terribile perche’ abbiamo praticamente 1 mega parametro che e’ tutto quanto comando e questo permette all’attaccante di creare confusione tra input e comando che deve essere eseguito. La cosa piu’ banale che si puo’ fare e’ andare a scrivere: 8.8.8.8 ; cat /etc/passwd

Qui praticamente non abbiamo separazione tra i parametri e quindi viene eseguito tutto quanto, mentre il sito si aspetta solamente un indirizzo ip molto banale. Alla fine shell_exec che e’ il codice php che letteralmente apre una shell ed esegue quello che gli viene chiesto, mi stampa a schermo il risultato del cat senza fare una piega.

[00:27:35]

Se sono molto cattivo potrei andare a fare tutto quanto come root, soprattutto se apache e’ in esecuzione come root 🤣 Anche se in teoria apache ora e’ utente nobody in teoria… poi in praticamente dipende chi ha configurato il tutto.

Posso anche andare a creare pagine web!

Solitamente un attaccante che cosa fa? Inietta delle web shell! Che cosa sono? Mi scarico WSO, e’ un file php lunghissimo essenzialmente che consente di andare a fare tante cose interessanti.

Un’altra cosa che viene comunemente fatta e’ mandare in esecuzione una reverse shell. Se ne trovano tantissime in giro, uno ne sceglie una e poi la installa sulla macchina target. Che logica abbiamo nella reverse shell? Potenzialmente e’ come se avessi un interprete dei comandi, ma questo interprete passa tutto sempre per il server HTTP, che gli passa poi ad application server. Questo non e’ buona perche’ se qualcuno guarda i log del server mi scopre. Vorrei avere una shell direttamente aperta su application server. Questo application server non e’ fatto per ricevere messaggi dall’esterno, come possiamo andare a fare?

Ma e’ probabible che app server possa aprire una shell su host esterno su internet. Praticamente apro una shell verso l’attaccante, quindi e’ letteralmente in reverse e possiamo andare a fare reverse shell in tanti modi. Posso anche andare ad iniettare codice php per andare a fare una reverse shell, mentre ce ne sono anche in python, dipende sempre chi va ad interpretare i miei comandi.

Come funziona il comando che sta mostrando il prof al minuto 40? Praticamente cancello tmp/f, poi uso mkfifo per creare un file speciale che si chiama fifo. Anche le fifo servono per mettere in comunicazione processi tra loro. Questi sembrano dei file e sono praticamente delle named pipe. Creo qualcosa simile ad una pipe ma gli posso dare un nome, come se fosse un file, ma esiste solamente in memoria. Leggo da questo file che ho creato e quello che ho letto lo passo a /bin/sh, poi con l’output di bash lo do in pasta a netcat (apre connessione) che apre una connessione ad un indirizzo ip verso una macchina controllata dall’attaccante ad una determinata porta. Questo comando, puo’ anche ricevere dalla rete e vengono rediretti sulla named pipe e vengono letti e mandati in input a bash. Dalla connessione di rete legge comandi, li esegue e l’output lo spara sulla connessione! Se ho una versione di netcat recente va anche molto meglio per fare queste cose (nc -e, senza andare ad usare named pipe alcuna).

[00:43:00]