Sulle tracce di un Botmaster…

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! 😉

  • massimiliano

    sarebbe interessante e completo spiegare come hai trovato e come hai sfruttato le vulnerabilità, così salti un po di passaggi del procedimento 🙂

    • Ciao Massimiliano,
      alcuni passaggi li ho saltati volutamente! 🙂 meglio non dare troppi vantaggi al Botmaster!
      Andrea

    • Mi pare abbastanza evidente, ha lanciato un attacco con heartbleed e dalla memoria leakata dal server si possono chiaramente vedere gli url ( vedere primo screenshot del post ) … non mi pare ci sia niente di misterioso sotto.

    • Per la precisione, ha usato questo https://github.com/sensepost/heartbleed-poc

      • Peppone

        no ha semplicemente usato il modulo auxiliary/scanner/ssl/openssl_heartbleed del framework metasploit. Poi in quel repository github c’è anche lo script ruby di metasploit ma è una vecchissima versione.

        use auxiliary/scanner/ssl/openssl_heartbleed
        set VERBOSE true
        set RHOSTS
        run

        ed il gioco è fatto.

        Anche l’ip oscurato non ne capisco il significato, a parte che dall’immagine si capisce ma poi basta risolvere il nome che hai indicato nella seconda immagine o la risoluzione fatta appena sotto.

  • Peppone

    “No, è un trucchetto voluto dal botmaster per confonderci le idee!”
    Mah… ti rendi conto di quello che scrivi? Non è un trucchetto ma una semplice configurazione del webserver. In pratica avviene questo: nel momento in cui si richiede il path con / senza indicare il nome del file si richiede il contenuto di default della directory, che in molti webserver è configurata come index.html o default.html per apache httpd vedi il parametro DirectoryIndex o index per NGINX, nel momento in cui in quella directory non esiste il file configurato, il web server ti dice “not found” o meglio status code 404.
    Se poi viene abilitata l’opzione Indexes (Apache HTTPD) per la directory è lo stesso web server a produrre una pagina html dove il contenuto è la lista dei file con i dettagli di ultima modifica.
    Come vedi quella che a te sembra una magia o un trucco svelato, non è nulla di eccezionale… ma una semplice configurazione!!