DiGiTaL RiOt

Le insidie di WordPress.com : Link Injection

Dicembre 23, 2009 · Lascia un Commento

[English Version: here]

Chi di voi , come il sottoscritto, fosse un affezionato utente della piattaforma wordpress.com credo sarebbe d’accordo con me sull’utilità e la praticità della voce “statistiche” nella gestione dei nostri blog. Essa infatti ci riporta diversi dati relativi alle visite al nostro blog: Visite giornaliere, notorietà dei nostri articoli, commenti, parole cercate nei motori di ricerca ma soprattutto i referer: ovvero da quale url gli utenti sono giunti nel nostro blog.

Questa funzionalità ci aiuta a capire se i nostri articoli vengono linkati dall’esterno e in tal caso ci permette di scoprire cosa si dice a proposito di quanto abbiamo scritto.

La pagina delle statistiche di questo Blog

Alcuni di voi avranno già capito dove voglio andare a parare: Il referer è un campo dell’header della request HTTP che il browser dell’utente che raggiunge il nostro blog, scambia con il server in cui il nostro blog è hostato. In particolare, questo campo indica qual’è l’url che conduce l’utente all’elemento corrente, in questo caso al nostro blog.
Come si potrebbe utilizzare questo referer per compiere un attacco al gestore di un blog WordPress.com?

L’hacker potrebbe modificare il campo referer dell’header HTTP e così pubblicare un qualsiasi link nella pagina di amministrazione del blog. Inoltre, l’hacker potrebbe creare diverse richieste http con il campo referer modificato così che la vittima, incuriosita da questa discreta “fonte di visite”, segua il link. A questo punto la vittima si ritroverebbe a scaricare la pagina indicata dall’hacker, esponendosi a diversi potenziali rischi (per l’hacker, il più è fatto).

La prima riflessione su quanto esposto riguarda la pericolosità di questo tipo di attacchi, infatti la piattaforma wordpress.com (come altre piattaforme esistenti e gratuite) risulta essere molto user friendly e non sempre chi ne fa uso possiede conoscenze in ambito di web security.

A questo bisogna aggiungere la semplicità dell’attacco : basta essere in grado di modificare un campo dell’header della richiesta http cosa realizzabile in modo estremamente semplice grazie all’estensione per firefox: modify headers, reperebile Qui

La finestra principale di Modify Headers

anche se personalmente preferisco utilizzare un tool avanzato come Webscarab, che mette a disposizione sotto un’unica interfaccia una miriade di funzionalità per l’analisi delle comunicazioni HTTP/S. Webscarab è un progetto parte dell’OWASP (Open Web Application Security Project).

Un aspetto molto importante riguarda la possibilità di inserire codice javascript nel referer, poiché nella pagina delle statistiche, viene stampato un input utente, l’applicazione è potenzialmente esposta al Cross Site Scripting (sono già alla ricerca di un possibile vettore javascript ;) )

Concludo dicendo che l’utilizzo di questa tecnica per portare la vittima nella pagina web infetta è molto efficiente, in quanto non richiede un contatto diretto con la vittima (irc, mail , msn ecc).

→ Lascia un CommentoCategorie: Sicurezza · Vulnerabilità · Wordpress
Messo il tag: , , ,

Advisory: ESL.eu profiles vulnerability

Dicembre 18, 2009 · Lascia un Commento

EDIT: Ho ricevuto immediatamente una risposta dagli admin, pubblicherò la vulnerabilità solamente una volta che sarà stata fixata.

Il sito http://www.esl.eu è vulnerabile, in particolare la gestione delle informazioni degli utenti può essere facilmente utilizzato contro la volontà degli utenti stessi, ho contattato gli admin ed attendo una risposta.

Esl

In caso la risposta non dovesse arrivare entro il 18 gennaio 2010 la vulnerabilità sarà pubblicata

→ Lascia un CommentoCategorie: Advisory · Sicurezza · Vulnerabilità

Session Storage: sicurezza delle applicazioni php ed insicurezze degli hosting condivisi

Novembre 9, 2009 · Lascia un Commento

Php salva i dati relativi alle sessioni tramite la serializzazione, ovvero l’array $_SESSION viene linearizzato e salvato in un supporto come un file o un record di un database.

session storage

Il comportamento di questa caratteristica di php può essere controllato da due variabili di configurazione di php:

Session.save_handler: indica a php come viene salvata la sessione e in quale supporto, il valore di default è file (quindi php out of the box scrive i dati di sessione su un file) mentre gli altri valori possibili son user, mm e sqlite.

Session.save_path: indica la directory in cui le sessioni saranno salvate e mantenute. Il valore di default è /tmp (la mia installazione di xampp ad esempio salva in C:\xampp\tmp).

Al giorno d’oggi la maggior parte dei servizi di hosting forniscono un servizio di hosting condiviso, molto gettonato perchè abbassa di molto i costi sia per la gestione che per l’utente finale. Un setup del genere però, in cui diverse web application girano sullo stesso server in cui tutte le sessioni vengono salvate nella stessa directory porta degli enormi problemi di sicurezza, vediamo un esempio:

Un cliente del servizio di hosting ha due applicazioni web che girano sullo stesso server. Entrambe fanno uso di sessioni ma sono destinate ad utilizzi diversi; entrambe fanno uso di form per inserire dati nel sito ma la prima delle due applicazioni salva nella sessione anche l’input utente non filtrato, mentre la seconda mantiene in sessione soltanto dati filtrati.

Poiché le due applicazioni condividono lo spazio in cui vengono salvate le sessioni un possibile attacco consiste nel:

  1. Popolare la sessione della prima applicazione (che non filtra l’input) con dati creati ad hoc
  2. Modificare il cookie della sessione relativa all’applicazione 2 inserendo il session id dell’applicazione 1 (questa sessione contiene dati non filtrati)
  3. L’attaccante utilizza i dati non filtrati dell’applicazione 1 per danneggiare l’applicazione 2.

Altro scenario ancora più pericoloso riguarda la condivisione di spazio di salvataggio delle sessioni e dell’implementazione dell’applicazione: capita spesso che i servizi di hosting php mettano a disposizione alcuni CMS per facilitare l’avvio di un sito web, ecco quali sono i rischi:

  1. L’attaccante è un utente dell’applicazione 1 con certi privilegi, magari è un editor o un moderatore. In particolare l’applicazione 1 si apoggia su un CMS.
  2. L’applicazione 2 condivide la directory di salvataggio delle sessioni (sempre lo stesso servizio di web hosting un pò farlocco) ma in più si appoggia allo stesso CMS dell’applicazione 1.
  3. L’attaccante logga nella applicazione 2 come utente senza privilegi, copia il session id dell’applicazione 1 nel cookie dell’applicazione 2 e si ritrova loggato con gli stessi privilegi che aveva nell’applicazione 1 (perchè le due applicazioni fanno uso dello stesso sistema di gestione dei ruoli).

Vediamo quindi che potenzialmente, se un servzio di hosting, ospitante un sito non protetto, non si occupasse di dividere le directory dedicate alle sessioni, i problemi di sicurezza del sito non protetto potrebbero ripercuotersi anche sugli altri.

Ne consegue che la precauzione necessaria al fine di evitare queste falle di sicurezza è la divisione delle directory di salvataggio delle sessioni in applicazioni, così che ogni applicazione avrà la propria directory, ad esempio:

/tmp/applicazione1

/tmp/applicazione2 ecc..

Se il servizio di hosting in cui ci appoggiamo non ha già pensato a modificare la variabile del php.ini possiamo provare ad aggiungere la seguente riga di codice nella nostra applicazione:

ini_set(‘session.save_path‘, ‘/tmp/nostra_app‘);

Incrociando le dita e sperando che la funzione ini_set non sia inibita dal servizio di hosting.

Un’altra soluzione è quella di aggiungere una variabile all’interno della nostra sessione che identifichi univocamente la nostra applicazione, ad esempio:

session_start();

if (!isset($_SESSION['application']) || ((string)$_SESSION['application'] !== ‘application_1′)) {

session_regenerate_id();

$_SESSION = array(‘application’ => ‘application_1′);

}

In questo modo il cookie modificato dall’attaccante sarà diverso dai cookie della nostra applicazione e l’id di sessione viene rigenerato.

Un metodo forse ancora più efficiente per gestire il mantenimento delle sessioni nel web server consiste nell’implementazione manuale delle funzioni di session storaging tramite la funzione set_session_save_handler(): essa permette di definire quali funzioni si occupano delle diverse operazioni di gestione delle sessioni.

→ Lascia un CommentoCategorie: Sessioni · Sicurezza · php
Messo il tag: , , ,

Netlog vulnerabile a CSRF

Ottobre 18, 2009 · 2 Commenti

Premetto che non mi assumo nessuna responsabilità per eventuali danni causati sul sito in questione.

In un mio precedente articolo, risalente a qualche mese fa, riportavo la suddetta vulnerabilità di questa (abbastanza) famosa piattaforma di social networking.
Ho inviato delle mail al support italiano, sono stato rimandato a quello europeo dai quali non ho mai più ricevuto alcuna risposta…. evidentemente non lo ritengono una minaccia.

Data Contatto: 11/07/2009 (senza ottenere risposta)
Pubblicazione:18/10/09
Tipologia:Cross Site Request Forgeries
Indirizzo: it.netlog.com

netlogEseguendo  nel browser la pagina creata ad hoc (ecco un esempio) mentre è attiva una sessione in netlog,  la vittima si ritroverà tra i post del suo blog un nuovo articolo, il quale contenuto sarà a completa discrezione di chi esegue l’attacco. Non ho avuto tempo di provare ad inserire vettori XSS ma probabilmente ci sarà modo ,visto che non fixano il form nemmeno sotto segnalazione.

Questa vulnerabilità permette la auto-distribuzione dell’ attacco, poichè se il post forgiato  contenesse un link alla pagina di partenza da cui il post stesso è stato creato e se un altro utente vi cliccasse, esso si replicherebbe istantaneamente nel profilo di chi ha visitato la pagina infetta . La capacità di autodiffondersi unita ad una falla XSS rappresenterebbe una minaccia per gli utenti di Netlog.

Il file di prova che ho inserito in questo articolo è puramente a scopo informativo, scoraggio chiunque nell’effettuare un attacco verso il sito internet indicato.

→ 2 CommentiCategorie: Advisory · CSRF · Sicurezza
Messo il tag:

Vulnerabilità modulo News v1.63 per Xoops

Luglio 27, 2009 · Lascia un Commento

Vulnerabilità Modulo News per Xoops

Vulnerabilità Xoops modulo news

Il modulo news (La versione più aggiornata è la 1.63) per la gestione dei contenuti in Xoops è vulnerabile a XSS e CSRF.

Il modulo news, mette a disposizione un form per l’invio di nuovi post e di nuovi topic di sezione; sono entrambi vulnerabili a CSRF in quanto non protetti da alcun token di sessione.

Inoltre, il modulo news non effettua nessun escaping con l’editor DHTML ed è possibile inserire tag html, compreso <script>, <link> ecc.., quindi è possibile fare in modo che venga postato del codice javascript ad insaputa dell’autore e questo ha miliardi di applicazioni. Impostare un editor diverso da DHTML non servirebbe a molto in quanto è possibile modificare il tipo di editor con una semplce richiesta cross site.

PoC

Scaricate ed installate l’ultima versione di Xoops e del suddetto modulo News

http://localhost/xoops-2.3.3/htdocs/modules/news/admin/index.php?op=newarticle è l’url che vi fa raggiungere direttamente il form in questione, vi basta copiare l’html del form e correggere il tag <textarea> che viene espresso come <textarea />, questo comporta che il restante codice html che includerete sarà interpretato come testo della <textarea>, mentre utilizzando <textarea></textarea> ciò non accade. Salvate il form che avete copiato , oppure prendete il mio e apritelo con il browser.

Sarete persino in grado di fare l’upload di un file che volete voi (sempre che sia tra i tipi MIME accettati dal server e da xoops).

Per metterci una pezza, installate il modulo protector, che trovate anche nel sito di xoops e magari provate qualche altro modulo per la gestione dei contenuti (se proprio non potete fare a meno di utilizzare xoops, che dopotutto è un buon cms)

→ Lascia un CommentoCategorie: Advisory · Vulnerabilità
Messo il tag: , , ,