Attacco al filesystem

Dalle pagine di un manifesto hacker impariamo come funziona l’exploit HTTP alla base dell’attacco Traversal Path. Ed è solo l’inizio di un grande viaggio nell’(in)sicurezza dei sistemi

Tra i molti segreti che il Dark Web cela, si annovera anche il presunto “manifesto” dal titolo The Fallen Dreams: origini e scopi sono rimasti nella nebbia per più di 15 anni. Pare sia stato trovato nella Darknet e tradotto da un hacker che si firma Demian Kurt. Ho avuto modo di studiarlo a fondo, in quanto mi è stato chiesto di scriverne note e glossario per il libro che ne è nato. La prefazione del testo, invece, è stata curata dal Prof. Stefano Bistarelli, docente di Matematica e Informatica presso l’Università di Perugia.

Alla ricerca di una chiave

Demian Kurt sembra aver tradotto il testo, di una centinaia di pagine, con la finalità di trovare la seconda parte di una “chiave”. A tale proposito lascia perfino un indirizzo mail a cui contattarlo: dkt01@protonmail.ch. Qualcuno afferma che, durante le varie revisioni la mail originale sia stata cambiata in quest’ultima da anonimi (o da Demian stesso). Nel corso del tempo, inoltre, pare che il manifesto sia stato attribuito a diversi hacker. Le ambiguità cominciano già dal titolo stesso, lasciato volutamente in lingua originale: “The Fallen Dreams”. Ho sentito pareri discordanti, a riguardo: qualcuno lo interpreta come “I Sogni Caduti/Infranti” altri come, “I Sogni di Fallen”. Demian Kurt, riporta, che in alcuni forum, sulla Darknet, si sia molto speculato in particolare sul secondo capitolo, in cui il “protagonista” sembra aver violato i server di alcuni laboratori di ricerca: <<[…] Ho aperto porte che non dovevano essere aperte>>, riporta il manifesto. Qui, pare abbia trovato qualcosa riguardo a un “simbionte”, una “hidden variable”. Difatti, molti credono che la fantomatica “chiave” che l’autore ha lasciato non si riferisca a un conto in bitcoin, ma bensì a una “chiave di conoscenza”.

 Inizia l’avventura

Lo scopo di questa mia rubrica che ci accompagnerà nei prossimi mesi, tuttavia, non è quello di addentrarmi nei labirintici enigmi di questo manifesto hacker. L’obiettivo che mi prefiggo è, piuttosto, quello di esaminare approfonditamente le tecniche hacking utilizzate, capitolo per capitolo, cominciando dalle prime pagine, sino ad arrivare al cuore del libro e alla creazione di un malware (tutto questo, sempre facendo attenzione a non fare spoiler).

 Il piano dell’opera

Se siete curiosi di sapere cosa vi attende in questa serie di articoli, indichiamo qui i titoli dei capitoli del manifesto e i relativi argomenti trattati (che però, attenzione, in alcuni casi potrebbero cambiare…).

Parte 1: The Fall – Traversal Path Attack
Parte 2: Dura Veritas sed Veritas – Scrivere un Keylogger e renderlo “undetected”
Parte 3: The Wolf – Buffer-Overflow Attack
Parte 4: Let there be Darkness – Deploy a Honeypot
Parte 5: Happy Birthday: DoS Attack using IoT Device
Parte 6: Better to Reign in Hell, Than Serve in Heav’n – Privilege Escalation
Parte 7: Polimorfismo – Creazione di un Malware
Parte 8: The Abyss – Creare una BotNet
Epilogo: Blank.Room

Se volete acquistare e leggere il libro, lo trovate su Amazon all’URL https://amzn.to/2ZDYp9N.

—————————————————————————————————

 Capitolo I -The Fall (La Caduta)

 Traversal Path Attack

Il “Path Traversal” (anche conosciuto come “Directory Traversal”) è una tipologia di attacco che sfrutta una vulnerabilità all’interno di una data applicazione (non sufficientemente protetta), per ottenere l’accesso a determinati percorsi (path) nel filesystem, cioè a cartelle presenti nel disco che non dovrebbero, in realtà, essere accessibili a un utente non autorizzato.

Ad esempio, poniamo di avere l’alberatura di un server Web Apache visibile in [figura #1] e di trovarci nella directory radice del server Web stesso, nel nostro esempio /var/www/html. Da qui, ipotizziamo di volerci spostare nella cartella root del sistema (/).

Esempio schema attacco

Scendendo di tre sub-folders arriveremmo nella root folder:

Oppure, potremmo utilizzare un solo comando di concatenazione di cd (change directory)

Adesso proviamo a fare ciò che in gergo viene chiamato PoC(Proof of Concept).

Ipotizziamo, ad esempio, che un’applicazione autorizzi l’utente a selezionare quali pagine visualizzare attraverso il parametro GET.

Prepariamo la nostra vulnerabilità ipotizzata ed esponiamola attraverso una macchina virtuale Kali Linux:

1. Avviamo il servizio apache2 tramite il comando: service apache2 start
2. Rechiamoci nella cartella /var/www/html
3. Rinominiamo index.html con un: mv index.html old_hmtl
4. Creiamo il file index.php: vi index.php
5. Ed incolliamo il nostro “codice vulnerabile”:

6. Salviamo il file, premendo “Esc” (per uscire dalla modalità “insert”) e digitiamo :wq

Ora abbiamo la nostra “applicazione”, che contiene del codice potenzialmente vulnerabile al “Trasversal Path Attack”

Prima di uscire, verifichiamo l’IP della nostra macchina Kali, digitando un ifconfig e prendiamone nota.

A questo punto, da un’altra qualsiasi macchina che raggiunga la nostra Kali, apriamo un browser e digitiamo l’indirizzo IP annotato (nel mio caso: http://192.168.178.42/ ) e diamo invio. Attraverso il browser saremo reindirizzati automaticamente sulla pagina index.php , che abbiamo creato.

La domanda è: cosa accadrebbe se l’attaccante sfruttasse la chiamata GET all’interno del file index.php (che abbiamo creato) reindirizzandolo verso un percorso differente?

Ad esempio, inserendo:  ../../../../etc/passwd e sfruttando la chiamata alla pagina /?page=

Il risultato sarebbe la visualizzazione del file passwd:

Analogamente, se nella root folder avessimo, ad esempio, un file di testo, potremmo visualizzarlo sfruttando il “Path Traversal”:

Facciamo ora un ulteriore passo ed addentriamoci nella vulnerabilità. Ipotizziamo di avere:

1. La nostra macchina attaccante, Kali, con IP : 168.178.42
2. La nostra vittima, una macchina virtuale con Windows 10 (64bit), avente IP: 168.178.44

Il nostro scopo in questa PoC non sarà solo quello di utilizzare la tecnica del path traversal, ma di eseguire comandi attraverso il “cmd” della macchina windows, contaminando il file di log, ed eseguirli attraverso l’URL.

Per l’hosting della nostra web page vulnerabile, ho utilizzato XAMPP un “application server” free che contiene già tutte le componenti necessarie (database management, FTP, PHP, etc..) per l’hosting di una webpage o di un applicazione. Può essere scaricato nella sezione download del sito ufficiale: https://www.apachefriends.org/it/download.html

Ho proseguito quindi con l’installazione di XAMPP ed avviato i servizi attraverso l’interfaccia.

Sotto c:\ ho creato la mia “applicazione vulnerabile”, inserendola nella cartella di “document root” C:\xampp\htdocs (“Folder-Location” di default del programma, dove posizionare applicazioni e web page).

La nostra banale, ma efficace “web-page” risulta così composta:

da un file index.html e tre .php

• index.html
• hjournal.php
• aggiungiutente.php
• listautenti.php

Esaminiamoli nel dettaglio:

• index.html:

È la nostra home page, con le informazioni che vengono inviate tramite il get a hjournal.php. Quali siano le informazioni inviate, dipende dalla scelta: listautenti.php oppure aggiungiutente.php.  Per procedere nella selezione si clicca sul pulsante “Invia Richiesta”.

• Il file hjournal.php riceve l’informazione della selezione effettuata:

Controlla che il menù sia settato (la variabile esista), allora “include” il file .php selezionato:

• aggiungiutente.php

Viene visualizzata a schermo la stringa di testo: Aggiungi un nuovo utente!

• Oppure listautenti.php

Viene visualizzata a schermo la stringa di testo: Controlla la lista degli utenti

Sostanzialmente, ciò che fa è abbastanza ovvio. Viene visualizzata una ListBox di selezione fra due voci: ListaUtenti o AggiungiUtente. Se si seleziona “ListaUtenti” verremo reindirizzati a “listautenti.php” e comparirà la frase “Controlla la lista degli utenti”. Viceversa, se si seleziona AggiungiUtente, la scelta sarà “aggiungiutente.php” ed apparirà la dicitura: “Aggiungi un nuovo utente!”.

Vediamo, a questo punto, come si presenta il nostro URL se selezioniamo l’opzione di: “ListaUtenti”

http://192.168.178.44/hjournal.php?command=listautenti.php

Non essendo previsto dall’applicazione nessun controllo sul file che viene passato (listautenti.php),  potremo inserire (proprio come abbiamo precedentemente visto) qualsiasi file name si desideri visualizzare.

Quindi, proviamo a scendere di una directory ../ e listare il contenuto del file passwords.txt locato nel percorso: c:\xampp (la directory di partenza è c:\xampp\htdocs).

Ci basterà sostituire listautenti.php con ../passwords.txt

Il risultato sarà:

http://192.168.178.44/hjournal.php?command=../passwords.txt

Nota: una possibile mitigazione di questa vulnerabilità è la modifica del parametro open_basedir , all’interno del file C:\xampp\php\php.ini : abilitando il comando (rimuovendo il “;” )  e selezionando solo il percorso consentito. Nel nostro caso, potremmo settarlo in questo modo:

open_basedir = c:\\xampp\\htdocs

Spingiamoci oltre.

I file log di Apache sono contenuti nel file access.log al percorso: C:\xampp\apache\logs, dove vengono immagazzinate tutti le informazioni relative agli eventi del server.

Portiamoci sulla nostra macchina attaccante Kali ed utilizziamo un terminale per effettuare una richiesta di connessione alla macchina bersaglio. Quindi, utilizzando netcut (conosciuto come il “coltellino svizzero” nelle reti di calcolatori, che permette di stabilire una comunicazione remota sia attraverso il protocollo TCP, che UDP) digitiamo:

nc -nv 192.168.178.44 80

• nc : è il comando netcut
• -n : esclusivamente da indirizzi IP e non da DNS
• v : fornisce dettagli aggiuntivi nell’output del comando;
• 168.178.44 : IP della vittima
• 80 : la porta di connessione

Una volta connessi alla porta 80 (convenzionalmente utilizzata per il protocollo HyperText Transfer Protocol – http. WWW) inoculiamo il seguente comando, dando invio:

La richiesta restituirà un errore: 400 Bad Request

Ma non è questo che a noi importa. La chiave di volta è che la nostra richiesta sarà registrata all’interno del file access.log, riportata assieme agli altri eventi.

Ora che il nostro codice PHP malevolo è stato introdotto all’interno del file locale, possiamo eseguirlo attraverso l’URL. Quindi, riapriamo il nostro browser e puntando al file di log dov’ è memorizzato il nostro codice PHP, eseguiamolo attraverso la “chiamata alla variabile” cmd:

http://192.168.178.44/hjournal.php?command=../apache/logs/access.log&cmd=systeminfo

Analizziamolo da vicino:

• http://192.168.178.44/hjournal.php?command= : URL del mio sito vulnerabile originale
• ../apache/logs/access.log : percorso per arrivare al log file che contiene l’injection del mio codice PHP malevolo
• &cmd= : “invocazione” del cmd
• systeminfo : comando da eseguire

Il risultato sarà l’esecuzione del comando systeminfo, sulla macchina target:

Ci sono casi in cui determinate applicazioni analizzano le query string al fine di ricercare caratteri malevoli, per prevenire proprio questo tipo di attacco.

In questo caso è possibile bypassare questo tipo di protezione sfruttando il passaggio di decodifica all’interno dell’URI (Uniform Resource Identifier).Cosa ne deriva? Facciamo un esempio, con i seguenti encoding e double-encoding (URL encoding):

• %2e%2e%2f rappresenta ../
• %2e%2e/ rappresenta ../
• ..%2f rappresenta ../
• ..%5c rappresenta ..\
• %2e%2e%5c rappresenta ..\

Tornando al nostro esempio, avremo quindi:

http://192.168.178.44/hjournal.php?command=../../Windows/System32/filetarget

diverrebbe:

http://192.168.178.44/hjournal.php?command=/%2e%2e/%2e%2e/Windows/System32/filetarget

Nota: Un esempio concreto? Recentemente il sito dell’INPS, ha rilevato molte informazioni per effetto fuzzing (direttamente o indirettamente provocato).

Ora che abbiamo visto la teoria, potremmo voler fare un po’ di pratica avvalendoci di alcuni tool. Tra questi prendiamo, ed esempio:

dotdotpwn, un tool per il Directory Traversal Fuzzing (sudo apt-get install dotdotpwn): https://github.com/wireghoul/dotdotpwn

• dotdotpwn : il comando
• -m  : identifica il nostro modulo nel nostro caso si tratta di http
• -h :  l’indirizzo IP del nostro host

È inoltre possibile effettuare un brute-force ad un URL per verificare quali percorsi vi siano e trovarne altri sfruttabili. Ad esempio, durante lo svolgimento della CTF Necromancer, uno dei passaggi che effettuai fu un attacco “di forza bruta” al seguente URL:

http://192.168.178.37/amagicbridgeappearsatthechasm/

Questo, proprio al fine di verificare se vi fossero altri percorsi nascosti:

gobuster è un tool utilizzato per gli attacchi di “forza-bruta” a URL (directory e file) di siti web e sottodomini DNS.

• gobuster : il comando
• dir : seleziona la modalità di brute-force a directory e file
• -u :  specifica l’URL sul quale verrà eseguito l’attacco.
• http://192.168.178.37/amagicbridgeappearsatthechasm/ : l’URL target
• – w: il percorso della lista di parole da utilizzare per l’attacco
• usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt : il percorso del mio file .txt contenente il mio dizionario. In quel caso ne utilizzai uno “standard” chiamato: directory-list-lowercase-2.3-medium.txt

Quando avrà trovato un percorso esistente, il server genererà una risposta (Status: 200).

Nota: Durante questo tipo di attacchi, il sito Web potrebbe restituire errori contenenti molteplici dati, rivelando così informazioni preziose per pianificare le fasi di un attacco successivo.

 

Come è possibile proteggersi da questo attacco?

Il modo più efficace per prevenire il Path Traversal Attack è evitare di trasmettere del tutto l’input fornito dall’utente alle API del filesystem.

L’applicazione deve convalidare l’input dell’utente prima di elaborarlo. Idealmente, la convalida dovrebbe essere confrontata con una whitelist di valori consentiti. Se ciò non è possibile per la funzionalità richiesta, la convalida dovrebbe verificare che l’input contenga solo contenuti consentiti, ad esempio caratteri puramente alfanumerici.

Inoltre è opportuno:

• Hostare i file su di un file-server/partition separati oppure utilizzare un cloud storage.
• Concedere ad ogni singolo processo un determinato permesso solo se strettamente necessario e vincolato esclusivamente alla sua funzione.
• Non utilizzare parti del “filename” direttamente all’interno del codice.
• Normalizzare l’input inserito prima dell’utilizzo.