Exploiting – Fuzzing parte 4

Usare Spike Parte 2

Nella seconda puntata su Spike vediamo come customizzare uno script così da poterlo utilizzare con Vulnserver.

Installiamo quindi come prima cosa le applicazioni sulla macchina target: OllyDBG e Vulnserver (i riferimenti si trovano nell’articolo precedente (https://greyhathacking.wordpress.com/2013/04/06/exploit-fuzzing-3-usare-spike-parte-1/).

Eseguiamo quindi OllyDBG con privilegi di Amministratore e dal debugger lanciamo Vulnserver; per fare questo premiamo F3 (o “File – open”) selezioniamo Vulnserver e in Arguments digitiamo la porta su cui Vulnserver ascolterà le connessioni, ovvero 4444.

Premiamo infine F9 (o “Debug – run”) così da eseguire il programma.

Image

Vale la pena a questo punto di ricordare brevemente come funziona Vulnserver: si tratta di un applicativo scritto ad hoc per effettuare test di verifica di fuzzing o buffer overflow, una volta lanciato il programma questo si mette ad ascoltare su una determinata porta ed accetta una serie di comandi seguiti da stringhe di caratteri.

Per verificarne il funzionamento è sufficiente utilizzare telnet o netcat indicando l’indirizzo ip della macchina target e la porta, nel nostro caso la 4444: nel mio caso <nc 192.168.159.138 4444> oppure <telnet 192.168.159.138 4444>. Basterà a questo punto digitare il comando HELP (tutti i comandi devono essere digitati in maiuscolo) per vedere la lista di comandi che vengono accettati da Vulnserver.

Un comando tipo inviato a Vulnserver sarà: “STATS 1234567890” a cui Vulnserver risponderà con un “STATS VALUE NORMAL”.

Image

Spike, Wireshark e VulnServer

Ora che e’ chiaro il funzionamento di Vulnserver e come interagire con il programma stesso, vediamo come customizzare Spike in modo da tentarne l’exploit.

In primo luogo proviamo un semplice script che non invierà alcun comando particolare ma una stringa di lunghezza sempre maggiore; per fare questo utilizziamo un editor testo e scriviamo i seguenti parametri:

s_readline(); // viene letto l’output inviato da Vulnserver

s_string_variable(“COMMAND”); // invia la stringa a Vulnserver

Salviamo lo script con il nome “vulnserver.spk

Per controllare quali stringhe vengono passate a Vulnserver utilizzeremo Wireshark specificando l’interfaccia di rete su cui effettuare lo sniffing “eth0” e indicando come “Capture Filter” la seguente stringa “host 192.168.159.138 and tcp port 4444” (ovviamente l’ip dovra’ essere sostituito).

Image

Localizziamo con locate “generic_send_tcp” (in kali è disperso in /usr/bin, in Backtrack è sotto /pentest/fuzzers/spike) ed eseguiamo il seguente comando:

/usr/bin/generic_send_tcp 192.168.159.138 4444 vulnserver.spk 0 0

Image

Immediatamente wireshark inizierà a registrare pacchetti sull’interfaccia eth0 e nella shell da cui abbiamo eseguito il comando generic_send_tcp inizieremo a vedere il dettaglio dell’attacco: Spike resterà in attesa dell’output da Vulnserver e quindi invierà la stringa per il buffer overflow (notate nell’output la stringa “Variablesize=” seguita dalla lunghezza della stringa inviata a Vulnserver, questa informazione sarà utile quando riusciremo a crashare l’applicazione). Purtroppo questo attacco non sortirà alcun effetto.

Image

Per poter vedere quale stringa e’ stata inviata a Vulnserver stoppiamo lo sniffing di Wireshark, selezioniamo una riga nel log che abbia un valore di “Lenght” elevato (di almeno un migliaio) clicchiamo sulla riga con il tasto destro e selezioniamo l’opzione “Follow Tcp Stream” si aprirà una finestra contenente i dati relativi ai pacchetti catturati.

Automatizzare l’utilizzo di Spike per Vulnserver

Quello che ora vogliamo fare è scrivere un file script .spk per ogni comando da inviare a Vulnserver, utilizzarli in sequenza e dare comandi aggiuntivi a Spike per ottenere maggiori informazioni sull’attacco in essere; scriveremo quindi una procedura che eseguirà ognuno dei file .spk con il comando generic_send_tcp.

L’applicazione sarà scritta in modo da bloccarsi quando Vulnserver cascherà’.

A questo punto utilizzeremo OllyDBGwireshark e lo script di automazione di Spike per capire cosa ha provocato il crash di Vulnserver; queste informazioni saranno preziosissime se vorremo scrivere un exploit. Importante ricordare che fino ad ora le attività svolte sono di Vulnerability Assessment e non di exploit vero e proprio.

Creiamo gli script

Iniziamo a creare gli script con un editor di testo: creiamo come prima cosa lo script che inviera’ a Vulnserver il comando “HELP” seguito da una stringa. Cloneremo quindi lo script sostituendo a HELP  via via tutti gli altri comandi gestiti da Vulnserver.

Il primo script si chiamerà 00help.spk e risultera’ il seguente:

printf(“Comando inviato HELP nome script eseguito: 00help.spk”); // stampa a video il comando inviato e il nome dello script

s_readline(); // stampa a video la linea inviata da Vulnserver

s_string(“HELP “); // invia il comando HELP a Vulnserver

s_string_variable(“COMMAND”); // invia la stringa per il tentativo di buffer overflow

Creiamo ora una directory ed al suo interno salviamo lo script; sostituiamo a HELP gli altri comandi di Vulnserver e salviamo gli script con una numerazione progressiva e con il nome del comando: 00help.spk, 01stats.spk, 02rtime.spk, 03ltime.spk

Per comodità potete scaricare tutti gli script dal link – https://mega.co.nz/#!AswS2CAT!VhBiiDCAA4eGevxjMiPkAX_dUK5A0zPX-9eybBMJr5g.

Lo script stamperà quindi come prima cosa a video il nome del comando che invierà ed il nome del file stesso, quindi stamperà a video la stringa ricevuta da Vulnserver; invierà quindi il comando HELP seguito dalla stringa di buffer overflow generata automaticamente da Spike.

Creiamo l’applicazione che eseguirà gli script

Per fare questo utilizzeremo il linguaggio Perl; non essendo la programmazione oggetto di questi tutorial non mi soffermerò sulla sintassi della applicazione.

Di seguito l’applicazione

#!/usr/bin/perl

# Una semplice applicazione per eseguire in sequenza i vari script di Spike

$comando_spike = ‘/usr/bin/generic_send_tcp’;

# Controlla che siano passati tutti I parametri

if ($ARGV[4] eq “”) {

die (“utilizzare $0 Indirizzo macchina target, porta, progressivo file spk , skipvar, skipstr\n\n”);

}

# Indica al programma da quale script file partire

$progressivofile = $ARGV[2];

@files = <*.spk>;

# Per ogni file con estensione *.spk esegue il seguente comando

Foreach $file (@files) {

If (! $progressivofile) {

If (system(“$comando_spike $ARGV[0] $ARGV[1] $file $ARGV[3] $ARGV[4]”) ) {

# segnala dove si e’ interrotto il programma

Print “Il programma si e’ interrotto processando il file $file\n”;

}

} else {

$progressivofile–;

}

}

L’applicazione dovrà essere eseguita nella stessa directory in cui sono stati salvati gli script *.spk e marcata come eseguibile con il comando “chmod +x”.

Eseguendo l’applicazione dovremo specificare l’indirizzo ip della macchina con Vulnserver, la porta, da quale script partire “0 = 00help.spk, 1 = 01stats.spk” e poi le variabili skipvar e skipstr descritte nell’articolo precedente.

Per comodità troverete lo script al link: https://mega.co.nz/#!0sxXhQxB!azMCrFlzyx-sMJjSu9VfP2jFA2RT5ntLrZLfTrjI-Bw

Per lanciare l’applicazione quindi scriveremo: “./vulnserver.pl 192.168.159.138 4444 0 0 0

Debuggare Vulnserver

Se non volete aspettare troppo tempo, lanciate l’applicazione con i seguenti parametri:

./vulnserver.pl 192.168.159.138 4444 8 0 0”; verrà eseguito lo script 08kstet.spk che cascherà’ in pochissimo tempo.

Fermate l’applicazione con CTRL-C e come prima cosa esaminate il debugger che mostrerà un errore eseguendo [41414141] e vedrete anche che il registro EIP punterà a [41414141].

Image

Per vedere esattamente quale stringa è stata inviata a Vulnserver basterà utilizzare Wireshark avendo l’accortezza come prima cosa di ordinare i pacchetti catturati con gli ultimi in cima; dopo questo basterà cercare la stringa “Welcome” così da trovare l’ultima volta che Vulnserver ha risposto correttamente. Il pacchetto subito precedente è quello che avrà causato il crash.

HackingLab – Raven

WordPress and DB exploit {contains spoilers}

“Questa è la storia, la Raven Security, vi sfida ad effettuare un Penetration Testing sul proprio server Web al cui interno ha riposto4 file, o flags, che voi dovete trovare ed aprire.
Potete cominciare quando volete.
Buona fortuna.”

La macchina si scarica all’indirizzo https://download.vulnhub.com/raven/Raven.ova ed è configurata per acquisire il proprio indirizzo IP in modalità dinamica DHCP.

EnumerationARP-SCAN
NMAP
NIKTO
Information GatheringWEBSITE BROWSING
WebSite EnumerationDIRBUSTER
DIRB
GOBUSTER
CMS EnumerationWPSCAN
Privilege EscalationSSH LOGIN
SQL LOGIN
SCRIPTING
Password AttacksJOHN

HackingLab – DeIce #1.140

“Questa è la storia, il Presidente di una piccola Società, la Lazy Admin Corp., vi ha chiesto di effettuare un Penetration Testing a partire da un server web che presente alcune informazioni sulla Società.
Potete cominciare quando volete.
Buona fortuna.”

EnumerationARP-SCAN
NMAP
NIKTO
LEGION
WebSite EnumerationDIRBUSTER
DIRB
GOBUSTER
OSINTLOG ANALYSIS
WEB SITE BROWSING
Privilege EscalationSSH LOGIN
Information GatheringOPENSSL
Password AttacksJOHN

HackingLab – DeIce #2.100

Password Attacks – Hidden Directories {contains spoilers}

“Questa è la storia, il Presidente di una piccola Società, la De-ICE Net, vi ha chiesto di effettuare un Penetration Testing a partire da un server web che presente alcune informazioni sulla Società.
Potete cominciare quando volete.
Buona fortuna.”

EnumerationARP-SCAN
NMAP
NIKTO
LEGION
WebSite EnumerationDIRBUSTER
DIRB
GOBUSTER
Privilege EscalationSSH LOGIN
Information GatheringEmail
Password AttacksJOHN

Le fasi del Penetration Testing – Information Gathering

Information Gathering

Il primo passo in un Penetration Test è quello relativo alla raccolta di informazioni o Information Gathering; con la conclusione di questa fase si avranno bene chiare la mappa del network del nostro Cliente e l’effort necessario svolgere le attività di Pen Testing. Saremo anche in grado di identificare i sistemi all’interno della rete, le applicazioni che vi girano e la loro versione.

Le informazioni possono essere raccolte secondo due tipologie di azioni:
Passive, che contemplano tutte le informazioni che vengono raccolte senza collegarsi alla rete Target;
Attive, che comprendono invece le informazioni che vengono raccolte collegandosi alla rete Target.
Il vantaggio nell’utilizzo di tecniche di acquisizione di informazioni passive è quello che si resta non identificati.

Le fasi del Penetration Testing – Introduzione

Introduzione

Quando iniziamo una attività di Pen Testing, quali sono i primi task di cui dobbiamo occuparci, quali sono le attività che dobbiamo svolgere ed in quale ordine devono essere espletate ?
Di seguito le fasi come descritte dal consorzio ISSAF che, anche se non aggiornate dal 2006, costituiscono una ottima soluzione per organizzare il lavoro di un Pentester:

  • Pianificazione e preparazione;
  • Assessment;
  • Reporting.

La fase di Pianificazione e Preparazione coinvolge tutti i processi relativi alla stesura e firma di un documento di mutuo accordo tra le parti ovvero tra chi richiede le attività di Penetration Testing e chi si occuperà di effettuare il Pen Testing vero e proprio; il documento dovrebbe identificare il gruppo di lavoro, le date per l’esecuzione della attività, gli orari e via discorrendo.

  • Scopo, quali sono gli indirizzi IP da scansionare, quali azioni sono permesse e quali no: avete il permesso di eseguire degli exploit o siete limitati solo a verificare le vulnerabilità ? E’ chiaro e noto che alcune azioni potrebbero portare al down di un server o di un router ? E’ chiaro al cliente che alcune azioni potrebbero essere potenzialmente distruttive per i Sistemi Operativi o per i dati ?
  • Timeframe, i Penetration Test possono essere svolti 24/7 o devono essere eseguiti in giorni ed orari predefiniti,ad esempio in periodo di downtime (es. dalle 18:30 alle 8:30 del mattino) ?
  • Contatti, chi siete autorizzati a contattare, ed in quale circostanza ? Siete autorizzati a contattare in caso di urgenze 24/7 al telefono o il tramite di contatto richiesto sono le E-mail ?
  • “Esci Gratis di Prigione”, avete un contratto scritto che vi autorizza alle attività di Pen Testing ? Nel caso in cui i sistemi siano hostate presso terze parti, avete l’autorizzazione dell’Hosting Provider a procedere ? Il rischio è una denuncia se non addirittura una condanna.
  • Pagamento, quando come e quanto vi pagheranno ?
  • N.D.A., avete stipulato un NDA con il Cliente che lo tutela da una vostra possibile divulgazione delle informazioni riservate che avete trovato nel corso della attività di Pen Testing ?

HackingLab – DeIce #1.20 version 1.0

Password attack and programming {contains spoilers}

“Questa è la storia, il Presidente di una piccola Banca, la Bank of No Security’s, vi ha chiesto di effettuare un Penetration Testing a partire da un server web che presente alcune informazioni sulla Banca.
Potete cominciare quando volete.
Buona fortuna.”

EnumerationARP-SCAN
NMAP
NIKTO
LEGION
Information GatheringLOG ANALYSIS
WEB SITE BROWSING
EXPLOITINGJAVA CODING

HackingLab – DeIce #1.120

Web Attack – SQL Injections {contains spoilers}

“Questa è la storia, Charlie il CEO di una piccola società, la No Security Corp.’s, dopo che siete riusciti ad ottenere il file dei salari ed il file con i nominativi dei clienti della ditta arricchito dai codici PAN delle loro carte di credito dal server FTP compromesso vi invita ad effettuare un nuovo tentativo di pentesting a partire da un server WEB aduso solo interno alla configurazione che viene utilizzato per caricare e visualizzare una lista di prodotti tramite Data Base.
Come prova dell’accesso fornite le informazioni relative agli utenti del sito.
Potete cominciare quando volete.
Buona fortuna.”

EnumerationARP-SCAN
NMAP
NIKTO
LEGION
WebSite EnumerationDIRBUSTER
DIRB
GOBUSTER
SQL InjectionSQLMAP
Password AttacksSQLMAP
Privilege EscalationSCRIPTING
La macchina virtuale può essere scaricata al link: https://drive.google.com/open?id=1Ym7nw029i_fvMUrEg08GA-cAyzD2nLAk