PhocaPDF è un plugin scaricabile gratuitamente che permette di aggiungere alcune comode funzioni quali appunto la trasformazione di un articolo Joomla in PDF e l’aggiunta di alcune personalizzazioni come il logo, l’header, il footer, etc.

Presso alcuni Hosting può capitare che invece che la creazione del PDF generi errori quali:

• 504 Gateway Timeout
• 500 Internal Server Error

Questi errori difficilmente vengono segnalati nei log e pertanto sono difficili da individuare e risolvere.

Per esperienza personale ho potuto constatare che questi errori si manifestano poiché PhocaPDF prova di default ad utilizzare le Librerie ImageMagick per convertire e ridimensionare le immagini. Se queste ultime non sono presenti allora utilizzerà le Librerie GD.

Presso l’Hosting su cui ho avuto modo di testare questa problematica le Librerie ImageMagick, sebbene correttamente installate e funzionanti, quando vengono interrogate da PhocaPDF mandano in errore lo script generando migliaia di file di cache nel percorso:

administrator/components/com_phocapdf/assets/tcpdf/cache

causando di conseguenza l’errore 500 o 504.

Per risolvere il problema basterà modificare il file:

administrator/components/com_phocapdf/assets/tcpdf/tcpdf.php

alla riga 7603 sostituendo la voce:

if (extension_loaded('imagick')) { // ImageMagick

con

if (!extension_loaded('imagick')) { // ImageMagick

In questo modo si forzerà l’utilizzo delle Librerie GD che non daranno problemi e PhocaPDF convertirà correttamente l’articolo in PDF.

Se riscontrate problemi o anomalie scriveteci!

Per fortuna arrivarono i Content Management System, più conosciuti come CMS.

Qualche povero tizio, martoriato come il sottoscritto, ma con più pazienza e capacità di me e della maggior parte dell’umanità, ha avuto la brillante idea di semplificare la vita a se stesso e a tutto il mondo: perchè perdere ore a scrivere righe di codice quando posso creare una piattaforma che mi permetta di aggiornare una gran mole di dati con pochi semplici click?

Ed ecco che i CMS spuntarono come funghi, ognuno con uno scopo differente, ognuno con la Sua utilità e caratteristiche, molti Open Source e GRATUITI, fino a creare delle sottocategorie in base al loro utilizzo.

Allo stato attuale esistono centinaia di progetti per CMS di vario genere e quando qualcuno mi chiede “Cosa devo fare per farmi il mio sito?” la mia risposta è “cosa VUOI fare per il tuo sito? Di sicuro c’è il CMS giusto per te!!“.

Di seguito elencherò in ordine alfabetico una serie di CMS ed applicativi tra i più conosciuti ed utilizzati con una breve descrizione ed il sito di riferimento per guide e downloads:

Coppermine (galleria fotografica)

piattaforma multiuso pieno di funzionalità con gestione integrata delle immagini tramite le librerie GD o ImageMagick, scritto in PHP, necessita di un Database MySQL

Sito ufficiale

Sito ufficiale supporto italiano

Drupal (cms)

gestore di contenuti (CMS) Open Source realizzato in PHP, che consente di realizzare una grande varietà di siti Web basati sulla logica contenuto/commenti. Le sue doti di robustezza, sicurezza e flessibilità ne stanno decretando la diffusione a livello mondiale

Sito ufficiale

Sito ufficiale supporto italiano

e107 (cms)

sistema di gestione dei contenuti scritto in PHP e utilizza il popolare sistema di database open source MySQL per la memorizzazione dei contenuti.

Sito ufficiale

Sito ufficiale supporto italiano

Joomla! (cms)

gestore di contenuti per la realizzazione di siti Internet dinamici, è gratuito, per il suo utilizzo non sono necessarie conoscenze di linguaggi di programmazione e può essere utilizzato anche per scopi commerciali

Sito ufficiale

Sito ufficiale supporto italiano

Magento (ecommerce)

piattaforma ricca di funzionalità costruita su tecnologia OpenSource flessibile e personalizzabile

Sito ufficiale

Sito ufficiale supporto italiano

MediaWiki (enciclopedia)

pacchetto di software libero ed open source wiki originariamente scritto per Wikipedia. Attualmente viene usato anche per gli altri progetti no profit della Wikimedia Foundation e per altri wiki

Sito ufficiale

Sito ufficiale supporto italiano

Moodle (e-learning)

noto anche come Learning Management System (LMS) o Virtual Learning Environment (VLE), è una applicazione web libera che i formatori possono utilizzare per creare siti di formazione efficaci

Sito ufficiale

Sito ufficiale supporto italiano

PhpBB (forum)

forum free  con funzionalità di bacheca virtuale che può essere utilizzato per rimanere in contatto con un gruppo di persone o per costruire integralmente il vostro sito web

Sito ufficiale

Sito ufficiale supporto italiano

PhpList (mailing list)

gestore di mailing list e news letter, semplice e integrabile con qualsiasi cms

Sito ufficiale

Sito ufficiale supporto italiano

PivotX (blog)

applicativo free da utilizzare per il mantenimento di siti dinamici come blog, giornali online e siti con frequenti aggiornamenti

Sito ufficiale

non è presente supporto in lingua italiana

PrestaShop (ecommerce)

ecommerce OpenSource gratuito, completamente personalizzabile, vanta un premio come miglior piattaforma OpenSource per il 2010

Sito ufficiale

Sito ufficiale supporto italiano

vBullettin (forum)

sistema a pagamento di gestione di forum, prodotto dalla Jelsoft Enterprises, scritto in PHP e basato su database MySQL permette la gestione di contenuti come un cms

Sito ufficiale

Sito ufficiale supporto italiano

WordPress (blog)

applicativo web Open Source gratuito, basato su PHP e MySQL, permette la creazione di siti web o blog, completamente personalizzabile può essere arricchito di funzionalità tramite appositi componenti aggiuntivi. Questo sito è realizzato con piattaforma WordPress

Sito ufficiale

Sito ufficiale supporto italiano

 ZenCart (ecommerce)

sistema di carrello elettronico open source completo, gratuito e di notevole facilità d’uso

Sito ufficiale

Sito ufficiale supporto italiano

ZenPhoto (galleria fotografica)

applicativo web per la gestione semplificata di galleria di immagini, personalizzabile

Sito ufficiale

non è presente supporto in lingua italiana

Una volta selezionata la piattaforma ideale alle nostre esigenze dovremo verificare quali requisiti hardware vengono richiesti (tipologia di spazio web e tipologia di Database). Questi requisiti vengono in genere illustrati in apposite sezioni del sito di supporto o nelle guide all’installazione.

I CMS elencati richiedono principalmente spazi web basati su sistema operativo Linux, con webserver Apache, Database MySQL e supporto per il linguaggio PHP. Questa configurazione viene definita LAMP e ve ne parlerò nella seconda parte di questa guida.

Per ora vi lascio all’ardua scelta di quale sia il CMS fatto apposta per voi.

Allo stato attuale la maggior parte di questi spazi sono ospitati in servizi di Hosting Condiviso e non in un mio Server, per cui sono soggetti a forti limitazioni nelle operazioni svolte, soprattutto se la tempistica di esecuzione degli script viene bloccata da un max_execution_time basso (minore di 300 sec).

Nel mio caso Le operazioni di upgrade/migrazione tramite il componente JUpgrade, come da indicazioni ufficiali richiedono tempistiche molto più elevate, vuoi per la mole impressionante dei dati, vuoi per la velocità di elaborazione di una macchina condivisa,  così mi sono visto impossibilitato ad eseguire l’upgrade direttamente in remoto.

Ma a tutto c’è un rimedio!

Per aggirare le limitazioni imposte dal mio servizio di Hosting Condiviso ho eseguito queste semplici operazioni che elenco e che spero possano risolvere la problematica se vi si presenta.

Passo 1: eseguire una copia di Backup

Il backup deve essere eseguito sia per i file, tramite un client FTP (io uso FileZilla), sia del Database utilizzato dal vosto Joomla (in genere il vostro gestore fornisce un pannello di PhpMyAdmin).

Passo 2: eseguire in locale il proprio sito

Realizziamo una copia del backup che abbiamo creato. Questa seconda copia dovrà essere utilizzata per una installazione in locale del nostro sito. Per eseguirlo su un pc Windows dovrete ricreare un WebServer nella vostra macchina. Tale operazioni risulta facilitata da una suite apposita che prende il nome di WAMP (Apache, MySQL, PHP on Windows).

Passo 3: eseguire l’aggiornamento di Joomla

Una volta che il nostro sito sarà correttamente reinstallato all’interno del nostro pc trasformato in WebServer per l’occasione, potremo eseguire l’aggiornamento di Joomla tramite JUpgrade, in quanto non avremo limiti di tempo per l’esecuzione degli script PHP.

Passo 4: ripubblicare Joomla

Una volta completato l’aggiornamento, verifichiamo il corretto funzionamento di ogni plugin, template e articolo presente nel nostro portale. Quando siamo sicuri che tutto vada bene possiamo ripubblicare via FTP i file attualmente modificati e il nuovo Database del nostro sito.

La cosa preferibile è eseguire la pubblicazione in una sottocartella dello spazio web e in un diverso Database se possibile, in modo da testare le funzionalità delle nostre pagine direttamente sul web, ma non rendendole accessibili ad altri, per evitare magre figure. Una volta che saremo sicuri che tutto vada bene, potremo sovrascrivere il contenuto della root del nostro spazio web, con i nuovi file e rendere disponibile a tutti il nostro nuovo sito con l’ultima versione di Joomla.

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

L’ingresso è gratuito e coloro interessati possono inviare le proprie richieste e proposte così da stilare un programma che soddisfi tutti gli amanti di questo Cms giunto ormai alla versione 1.6.1.

Non appena ci saranno maggiori informazioni provvederò ad aggiornare l’articolo.

Buona domenica!

Spesso capita d non ricordarsi la password o, a volte (purtroppo), ci troviamo la password cambiata in seguito a qualche attacco hacker.

Per poterla ripristinare basterà copiare il file “joomla15_reset_pwd.php” nella root del vostro Joomla e successivamente richiamarlo via Web all’indirizzo:

http://www.dominio.com/<root_joomla>/joomla15_reset_pwd.php

Vi apparirà un form minimal come quello della seguente figura:

Basterà inserire l’username dell’utente e la password che si vuole impostare e il gioco è fatto!!

Download joomla15_reset_pwd.php

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

inizio la mia collaborazione con capn3m0 pubblicando la risoluzione per un piccolo problema che può affliggere gli utilizzatori del noto CMS Joomla!

Può capitare che nell’aggiornamento/modifica di un template dal back-end il sistema segnali l’impossibilità nell’esecuzione di tali operazioni a causa del file params.ini che presenta permessi di scrittura errati.

Tale errore può essere risolto aggiungendo al seguente file:

administrator/components/com_templates/admin.templates.html.php

nella riga 397 questa stringa:

chmod($client->path.$templatefile, 0755);

Nell’esempio viene impostato 755 poiché nell’attuale Hosting questi sono i permessi CHMOD minimi per rendere un file scrivibile. A seconda dei casi i permessi potranno essere diversi.

Il risultato finale dovrà essere:

<?php $templatefile = DS.’templates’.DS.$template.DS.’params.ini’;
chmod($client->path.$templatefile, 0755);
echo is_writable($client->path.$templatefile) ? JText::sprintf(‘PARAMSWRITABLE’, $templatefile):JText::sprintf(‘PARAMSUNWRITABLE’,$templatefile); ?>

Modificando i vostri templates non avrete più problemi

Ciauz!

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

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!

Questo CMS di default (personalmente non ne capisco il motivo) ha abilitata la “ricerca ricorsiva” per tutto ciò che riguarda l’elencazione (listing) di file e cartelle di una path. In questo caso in particolare mi riferisco al componente “com_media” che si occupa della gestione dei contenuti multimediali quali foto e video. Nella pagina principale dell’Amministrazione del Joomla andando su “Gestione Media” si accede ad un interfaccia stile “client ftp” che permette di navigare all’interno delle cartelle “images” e “media” ed eseguire le normali operazioni di cancellazione/modifica/etc su file e cartelle in esse contenute.

Il problema sorge quando il numero di file contenuti in queste due cartelle raggiunge dimensioni tali da non rendere possibile il listing di tutto il contenuto nei 120 secondi di Timeout impostati sul Server (tranne servizi dedicati appostivamente al Joomla i normali Hosting Provider impostano il max_execution_time a 120 secondi). Al termine di tale tempo se l’operazione non è completata, a seconda della configurazione e della versione del WebServer, viene mostrato l’errore “500 Internal Server Error” o “504 Gateway Timeout“. Tradotto in parole povere significa che lo script ha provato ad eseguire l’operazione ma il processo era ancora in corso trascorsi 2 minuti e pertanto è stato bloccato.

Per disabilitare la “ricerca ricorsiva”, quindi, è necessario aprire il file “manager.php” presente nella path:

<root_di_Joomla>/administrator/components/com_media/models/manager.php

e successivamente posizionarsi alle Righe 63 e 102 che appariranno così:

$folders = JFolder::folders($base, '.', true, true);

e modificarle variando il 1° true su false come di seguito:

$folders = JFolder::folders($base, '.', false, true);

Di seguito le prime righe della funzione che viene richiamata che dimostrano che il parametro variato va a disabilitare la ricorsione.

	/**
	 * Utility function to read the folders in a folder.
	 *
	 * @param	string	The path of the folder to read.
	 * @param	string	A filter for folder names.
	 * @param	mixed	True to recursively search into sub-folders, or an
	 * integer to specify the maximum depth.
	 * @param	boolean	True to return the full path to the folders.
	 * @param	array	Array with names of folders which should not be shown in
	 * the result.
	 * @return	array	Folders in the given folder.
	 * @since 1.5
	 */
	function folders($path, $filter = '.', $recurse = false, $fullpath = false, $exclude = array('.svn', 'CVS'))
	{
		// Initialize variables
		$arr = array();
 
		// Check to make sure the path valid and clean
		$path = JPath::clean($path);
 
		// Is the path a folder?
		if (!is_dir($path)) {
			JError::raiseWarning(21, 'JFolder::folder: ' . JText::_('Path is not a folder'), 'Path: ' . $path);
			return false;
		}
 
		// read the source directory
		$handle = opendir($path);
		while (($file = readdir($handle)) !== false)
		{
			if (($file != '.') && ($file != '..') && (!in_array($file, $exclude))) {
				$dir = $path . DS . $file;
				$isDir = is_dir($dir);
				if ($isDir) {
					// Removes filtered directories
					if (preg_match("/$filter/", $file)) {
						if ($fullpath) {
							$arr[] = $dir;
						} else {
							$arr[] = $file;
						}
					}
					if ($recurse) {
						if (is_integer($recurse)) {
							$arr2 = JFolder::folders($dir, $filter, $recurse - 1, $fullpath);
						} else {
							$arr2 = JFolder::folders($dir, $filter, $recurse, $fullpath);
						}
 
						$arr = array_merge($arr, $arr2);
					}
				}
			}
		}
		closedir($handle);
 
		asort($arr);
		return $arr;
	}

Come spiegato nei commenti della funzione stessa l’impostare su “false” il 3° parametro disabilita la ricorsione evitando il manifestarsi dell’errore di Timeout.
In alternativa è possibile modificare il parametro inserendo un valore numerico intero. Così facendo si indicano quanti livelli deve scendere nella ricerca dei file/cartelle.

Esempio della modifica da apportare se si vuole che la ricerca scenda al massimo di 3 livelli, ossia:

<root_di_Joomla>/images/cartella1/cartella2/cartella3

La riga andrebbe modificata nel seguente modo:

$folders = JFolder::folders($base, '.', 3, true);

Fatto ciò il problema sarò risolto e all’apertura del “com_media” verrà effettuata la ricerca per le sole cartelle “images” e “media” e per il numero di livelli da voi impostato. Tale modifica crea un piccolo problema visivo che, a mio avviso, non è molto rilevante poiché disabilitando la ricorsività dal menu ad albero del “Gestione Media” non si potrà vedere il solito “+” davanti alle cartelle che ne contengono delle altre. Analizzando solo il primo livello delle cartelle non può creare l’albero di navigazione fin da subito e pertanto si aggiornerà man mano che si scende nelle sottocartelle.

Per un problema risolto ritengo sia una piccola perdita.

In questo caso parliamo del componente “Virtuemart” di Joomla che consente di trasformare il Cms in un negozio on line. In alcuni Hosting a causa della configurazione del “Timeout CGI” impostato in Apache possono verificarsi errori “500 Internal Server Error” in occasione dell’aggiunta di nuove immagini per un prodotto.

Questo perché quando si carica l’interfaccia di upload il Virtuemart esegue un check su tutti i file e cartelle della cartella predefinita delle immagini. Se, quindi, sono presenti numerosi file lo script non riesce a terminare in tempo la verifica di ogni singolo file andando in errore di “Timeout CGI”.

Nel mio attuale Hosting tale Timeout è impostato a 60 secondi e, quindi, ho provveduto ad editare direttamente il codice sorgente del Virtuemart per fare in modo che non esegua tale verifica indipendentemente da quanti file son presenti nella cartella predefinita.

Per fare ciò è necessario aprire il file “product.file_form.php” presente nella path:

<root_di_Joomla>/administrator/components/com_virtuemart/html/

e successivamente posizionarsi alla Riga 105 che apparirà come segue:

$downloadRootFiles = vmReadDirectory(DOWNLOADROOT, '.', true);

e modificarla variando il parametro da “true” a “false” come di seguito:

$downloadRootFiles = vmReadDirectory(DOWNLOADROOT, '.', false);

In questo modo il problema dell’error “500 Internal Server Error” in fase di upload dei file sarà risolto.

Tengo a precisare che la versione del Virtuemart su cui ho eseguito tali modifiche è la 1.1.3.

Resto a disposizione per qualsiasi chiarimento o qualora dopo tali modifiche si riscontrino altri generi di problematiche.

[11/03/2009 - 00.40] AGGIORNAMENTO #1: Ho fatto delle verifiche per validare il perché di tale modifica e vi riporto direttamente il codice dell’intera funzione “vmReadDirectory” presa dal file originale “ps_main.php“:

/**
* Utility function to read the files in a directory
* @param string The file system path
* @param string A filter for the names
* @param boolean Recurse search into sub-directories
* @param boolean True if to prepend the full path to the file name
*/
function vmReadDirectory( $path, $filter='.', $recurse=false, $fullpath=false  ) {
	$arr = array();
	if (!@is_dir( $path )) {
		return $arr;
	}
	$handle = opendir( $path );
 
	while ($file = readdir($handle)) {
		$dir = vmPathName( $path.'/'.$file, false );
		$isDir = is_dir( $dir );
		if (($file != ".") && ($file != "..")) {
			if (preg_match( "/$filter/", $file )) {
				if ($fullpath) {
					$arr[] = trim( vmPathName( $path.'/'.$file, false ) );
				} else {
					$arr[] = trim( $file );
				}
			}
			if ($recurse && $isDir) {
				$arr2 = vmReadDirectory( $dir, $filter, $recurse, $fullpath );
				$arr = array_merge( $arr, $arr2 );
			}
		}
	}
	closedir($handle);
	asort($arr);
	return $arr;
}

Come spiegato nei commenti della funzione stessa l’impostare su “false” il 3° parametro disabilita la ricorsione evitando che il check dei file venga effettuato anche nelle sottocartelle generando l’errore di Timeout (Timeout CGI = 60 sec; max_execution_time = 120).

Problema

I problemi che si riscontrano utilizzando detto componente in Hosting che hanno abilitato il “Mod_Security” sono principalmentdue due:

1) Mancato accesso all’interfaccia di gestione dal Pannello di Controllo del Joomla;

2) Errore nell’upload dei file tramite l’interfaccia Flash.

Perché?

Entrambe le problematiche nascono dalla presenza in diverse cartelle del file “.htaccess” contenente due istruzioni che, se abilitate nel Server in Hosting, consentono di disabilitare il “Mod_Security” per evitare che blocchi il passaggio di dati/file tra l’interfaccia Flash e il Server.

Il codice di questo file è il seguente:

SecFilterEngine Off
SecFilterScanPOST Off

Sul mio ed altri Hosting tale possibilità è disabilitata in quanto le misure di Sicurezza devono (giustamente) essere sempre attive e, quindi, il file “.htaccess” genera il manifestarsi di errori “500 Internal Server Error” e il mancato funzionamento degli applicativi/componenti dove esso è posizionato.

Al fine di risolvere le due problematiche precedentemente indicate, quindi, è necessario eliminare il file .htaccess dai seguenti percorsi:

/components/com_expose/expose/manager/amfphp
/components/com_expose/expose/manager/upload

Ho riscontrato che su alcuni Hosting (Aruba per esempio) quando si clicca su uno degli Eventi presenti alla voce “Prossimamente” va in errore mostrando una pagina simile alla seguente.

Errore nella visualizzazione Eventi di Gcalendar per Joomla

Andando a verificare la pagina segnalata nell’errore ossia

/components/com_gcalendar/hiddenviews/event/tmpl/default.php

si riscontra che la riga che genera l’errore è la seguente dove viene composto l’Url da richiamare per visualizzare in un iframe l’evento direttamente dal Google Calendar.

$url = $p['scheme'] . ‘://’ . $p['host'] . ‘/calendar/event?eid=’ . $this->eventID . $this->timezone;

Analizzando meglio il codice si riscontra che i due campi “scheme” e “host“, da come vengono utilizzati, dovrebbero essere presenti nell’”Array $p” ma, in realtà non esistono e di conseguenza l’Url che viene generato non è corretto.

Non ho potuto effettuare molti controlli ma effettuando una stampa dell’intero “Array $p” ho riscontrato che vi è un solo campo che, tra l’altro, non viene utilizzato all’interno della pagina. Per fare una verifica approfondita andrebbe verificato il popolamento dell’Array che avviene alla riga 12 dello stesso file tramite la seguente riga:

$p= parse_url($this->gcalendar);

Dato che, come detto, non ho avuto la possibilità di effettuare controlli approfonditi ho risolto il problema a monte commentando la riga 14 dove si generava l’errore e aggiungendone una in cui l’Url viene generato “manualmente”. Ecco il codice:

#$url = $p['scheme'] . ‘://’ . $p['host'] . ‘/calendar/event?eid=’ . $this->eventID . $this->timezone;

$url = ‘http://www.google.com’.'/calendar/event?eid=’ . $this->eventID . $this->timezone;

Così facendo il problema, ovviamente, si è risolto.

Sicuramente non è il metodo migliore per “fixare” il problema in quanto si tratta di un accorgimento piuttosto grezzo ma, temporaneamente, funzionante.

Eccovi il file già fixato:

Joomla Gcalendar Components – RAW FIX EVENT VIEW

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!