Cisco lancia l'allarme per il malware Rombertik, MBR a rischio

Cisco lancia l'allarme per il malware Rombertik, MBR a rischio

Arriva da Cisco l'allerta per un nuovo malware individuato nel web capace di crittografare i dati dell'utente e danneggiare il Master Boot Record. Abbiamo consultato un esperto, Marco Giuliani di Saferbytes, per avere maggiori informazioni in merito

di pubblicata il , alle 13:01 nel canale Sicurezza
 

Si chiama Rombertik la minaccia scoperta dal Talos Group di Cisco, l'élite di ricercatori della multinazionale americana specializzati in ricerca e analisi di minacce informatiche avanzate. I ricercatori Ben Baker e Alex Chiu hanno isolato e successivamente descritto il nuovo malware in un articolo (lo trovate qui: http://blogs.cisco.com/security/talos/rombertik); la minaccia si propaga tramite spam ed e-mail di phishing, con l'intenzione di rubare informazioni dal PC colpito.

Mettendo già in chiaro che l'infezione si diffonde principalmente tramite social engineering, Rombertik, una volta nel PC, tende a camuffarsi in modo tale da rendersi di difficile analisi agli occhi dei ricercatori informatici. Il file, di dimensioni rilevanti (circa 1.2 MB), è composto dal 97% di codice inutile, messo lì solo per deviare l'attenzione di possibili malware researcher. Il flusso di codice del malware è scritto appositamente per rendere lenta e laboriosa l'estrazione del vero payload, le cui dimensioni sono in realtà molto più piccole - circa 30KB di codice eseguibile.

Il malware, una volta colpito il PC, attacca i browser principali - Internet Explorer, Chrome, Firefox - rubando informazioni, credenziali di accesso, dati personali dalle connessioni Internet, anche protette da SSL, e invia il tutto al server di controllo localizzato all'indirizzo web centozos.org.in. Tuttavia la parte più pericolosa di questo malware è la sua capacità di autodifesa: se "scopre" infatti di essere analizzato, esegue un meccanismo distruttivo per il PC infetto, tentando di cancellare completamente la tabella delle partizioni del Master Boot Record e crittografando tutti i file presenti nella home directory dell'utente infetto.

Marco Giuliani, CEO della società italiana di sicurezza informatica Saferbytes che si occupa di threat intelligence e analisi malware, sentito per l'occasione da Hardware Upgrade, ha avuto modo di analizzare l'infezione e di fornirci un commento a riguardo:

"L'infezione in questione, sebbene abbia catturato l'attenzione di molti ricercatori, in realtà è una tipologia di infezione vecchio stile, tecnicamente non all'avanguardia come molte altre infezioni ad oggi in circolazione. Per le modalità di infezione ed attacco è molto efficace contro chi sta ancora utilizzando Windows XP, mentre comincia ad essere molto meno efficace nei confronti degli utilizzatori di Windows Vista,7,8, 8.1. La routine di attacco contro il Master Boot Record è totalmente inefficace contro i nuovi sistemi che utilizzano UEFI. Inoltre l'infezione non tende in alcun modo a nascondersi una volta in esecuzione nel PC, è perfettamente visibile tra i processi di sistema attivi.

Purtroppo, pur essendo un'infezione tecnicamente arretrata e di semplice progettazione, può comunque far molti danni. Soprattutto la parte di crittografia dei dati - che vengono cifrati con algoritmo RC4 e chiave generata in maniera casuale utilizzando il PRNG di Windows - mette in evidenza come stiamo vivendo il periodo informatico dove sempre più vi è bisogno di capire che il backup e la sicurezza dei dati personali sono più che mai critici. Questa infezione, così come i vari ransomware che colpiscono e poi chiedono il riscatto per recuperare i dati cifrati, dovrebbero far capire come un approccio alla sicurezza basato su backup regolari dei dati sia oggi più che mai fondamentale."

Una nota curiosa messa in evidenza da Giuliani è la presenza all'interno del malware di stringhe che fanno riferimento ad una società di sicurezza italiana, la NoVirusThanks s.r.l. Gli autori del malware, ci spiega Giuliani, hanno probabilmente inserito queste stringhe per depistare le analisi e rendere più veritiero il file principale dell'infezione.

Ad oggi, tuttavia, tutte le soluzioni antivirus hanno già aggiornato le proprie firme virali per individuare e rimuovere la minaccia.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione

35 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
Unrealizer08 Maggio 2015, 13:56 #1
no un attimo... usano davvero RC4?
Dane08 Maggio 2015, 14:34 #2
Originariamente inviato da: Unrealizer
no un attimo... usano davvero RC4?


chissà da quanto è n giro
hrossi08 Maggio 2015, 14:50 #3
Pensate, il tutto in 30k di codice. Propagazione, attacco a diversi browser, sniffing, invio dati, riconoscimento analisi antimalware, cancellazione mbr e crittografia file.

Hermes
zappy08 Maggio 2015, 15:38 #4
Originariamente inviato da: hrossi
Pensate, il tutto in 30k di codice. Propagazione, attacco a diversi browser, sniffing, invio dati, riconoscimento analisi antimalware, cancellazione mbr e crittografia file.

Hermes

e 97% di fuffa.
esattamente come il SO ospite
rockroll08 Maggio 2015, 17:15 #5
Originariamente inviato da: zappy
e 97% di fuffa.
esattamente come il SO ospite


Esattamente!

Ma non meravigliatevi troppo dei soli 30 KB di codice utile: ai miei tempi in dimensioni di quest'ordine dovevamo farci stare interi S.O. ... proprio come oggi, tale e quale ...

Provate voi a riempire 30 KB di codice oggetto programmando in Assebler, poi mi dite quanto vi impegna e quante e quali cose si riescono a fare.

Certo che è deprimente pensare che in 30 KB ora non riusciamo manco a farci stare un centomillesimo di film HD, di quelli che volendo possiamo scaricare a decine al giorno!

Oh tempora, oh mores... (sono un vecchiardo nostalgico, lo so).
zappy08 Maggio 2015, 17:33 #6
Originariamente inviato da: rockroll
Esattamente!

Ma non meravigliatevi troppo dei soli 30 KB di codice utile: ai miei tempi in dimensioni di quest'ordine dovevamo farci stare interi S.O. ... proprio come oggi, tale e quale ...

Provate voi a riempire 30 KB di codice oggetto programmando in Assebler, poi mi dite quanto vi impegna e quante e quali cose si riescono a fare.

Certo che è deprimente pensare che in 30 KB ora non riusciamo manco a farci stare un centomillesimo di film HD, di quelli che volendo possiamo scaricare a decine al giorno!

Oh tempora, oh mores... (sono un vecchiardo nostalgico, lo so).

vabbè, senza esagerare a programmare in assembler, una interfaccia grafica a colori è il minimo, dai
da qui al rendere pachidermico qualunque sw che poi produce anche solo uno sputo ce ne passa... in effetti non riesco bene a capacitarmi come si fa a rendere così giganteschi i sw... è tutta grafica bitmap?!?
bobafetthotmail08 Maggio 2015, 18:20 #7
Pensate, il tutto in 30k di codice. Propagazione, attacco a diversi browser, sniffing, invio dati, riconoscimento analisi antimalware, cancellazione mbr e crittografia file.
Come se fosse difficile. Questo è un programma molto semplice che non deve gestire nessun tipo di input dall'utonto nè interfacce nè errori nè niente. Se scazza muore, fine.
Non ha 8 pagine di controlli e check per evitare di incasinare la macchina o far passare errori dell'utonto.

Provate voi a riempire 30 KB di codice oggetto programmando in Assebler, poi mi dite quanto vi impegna e quante e quali cose si riescono a fare.

hai una vaga idea di cosa significhi programmare in assembler?
Praticamente stai scrivendo in binario o in esadecimale https://upload.wikimedia.org/wikipe...ly_Language.png

In genere ci scrivono driver e cose di bassissimo livello (nel senso di più vicine possibile alla macchina fisica).
C'è gente che scappa urlando quando menzioni l'assembler.
da qui al rendere pachidermico qualunque sw che poi produce anche solo uno sputo ce ne passa... in effetti non riesco bene a capacitarmi come si fa a rendere così giganteschi i sw... è tutta grafica bitmap?!?
Più il linguaggio di programmazione è astratto (=facile da capire per un essere umano) più grossa viene la roba.

Il punto è che quelli che programmano in assembler sono delle persone con capacità particolari, mentre lavorare in c++ o altri linguaggi più umani ci riesce più gente.

L'apoteosi della scarsa ottimizzazione si ha con i programmi che ti fanno assemblare blocchi di codice pre-fatto come se fossero dei lego colorati e poi sputano il binario o lo script o quel che è.
zappy08 Maggio 2015, 19:20 #8
Originariamente inviato da: bobafetthotmail
Come se fosse difficile. Questo è un programma molto semplice che non deve gestire nessun tipo di input dall'utonto nè interfacce nè errori nè niente. Se scazza muore, fine.
Non ha 8 pagine di controlli e check per evitare di incasinare la macchina o far passare errori dell'utonto.

beh, si, in effetti anche questo è vero. in effetti gestire input ed errori occupa parecchio codice.

hai una vaga idea di cosa significhi programmare in assembler?

a me è parso di capire che rockroll sappia bene che vuol dire...

Più il linguaggio di programmazione è astratto (=facile da capire per un essere umano) più grossa viene la roba.

beh, una volta che compili in teoria tutta la complessità del linguaggio dovrebbe diventare solo 1 e 0 e sparire tutto ciò che serviva all'umano... no?

L'apoteosi della scarsa ottimizzazione si ha con i programmi che ti fanno assemblare blocchi di codice pre-fatto come se fossero dei lego colorati e poi sputano il binario o lo script o quel che è.

bello! dove li trovo 'sti cubi colorati?!?
bobafetthotmail08 Maggio 2015, 19:59 #9
a me è parso di capire che rockroll sappia bene che vuol dire...
Uno che non considera che l'assembly è per pochi eletti non lo considero uno che sa quello che vuole dire.
Poi magari mi sbaglio eh.
beh, una volta che compili in teoria tutta la complessità del linguaggio dovrebbe diventare solo 1 e 0 e sparire tutto ciò che serviva all'umano... no?
Te lo spiego con un esempio più visuale.

è la differenza tra costruire un modellino di nave segando e intagliando ogni singolo pezzo a mano con banco da lavoro e strumenti seri vs fare una nave coi lego vs farla coi duplo (lego con mattoncini di grosse dimensioni per bambini piccoli).

Alla fine hai sempre una nave. Ma la nave fatta con gli strumenti più fini sarà ovviamente tutta un'altra cosa che quella fatta coi lego, e anche la nave fatta coi lego sarà millemila volte meglio di quello schifo che c'è venuto coi duplo.

I linguaggi più astratti sono dei prefabbricati, come i lego. Puoi ottimizzare, ma stai comunque lavorando con dei prefabbricati, se stessi lavorando construmenti più fini potresti fare magheggi da paura, ma devi essere in grado di lavorarci, e devi essere in grado di fare i magheggi da paura (sennò non li puoi implementare). Sennò è meglio restare coi prefabbricati. Perchè è sempre meglio qualcosa che va di qualcosa che non va.

E per prefabbricato intendo che lasci al compilatore (il programma che legge il codice e sputa il binario) la decisione di cosa fare per interpretare quello che scrivi nel sorgente. Coi linguaggi di livello più basso il compilatore deve decidere sempre meno cose (perchè le decide chi programma).

bello! dove li trovo 'sti cubi colorati?!?
Ci sono programmi per avvicinare i giovani alla programmazione tipo questo
https://www.tynker.com/
E una valanga di simili. Poco più di uno script glorificato. Carino ma niente di che.

Poi c'è qualcosa di più serio come il sistema dei Mindstorm (robot lego, non sono propriamente giocattoli, costano un occhio) http://www.lego.com/en-us/mindstorms/learn-to-program
Questo è tutta un'altra cosa rispetto al precedente.

E qui una lista ti altra roba più seria usata dagli adulti o comunque per lavoro. https://en.wikipedia.org/wiki/Visua...amming_language
cdimauro08 Maggio 2015, 20:01 #10
Originariamente inviato da: bobafetthotmail
hai una vaga idea di cosa significhi programmare in assembler?
Praticamente stai scrivendo in binario o in esadecimale https://upload.wikimedia.org/wikipe...ly_Language.png

In realtà si usa(va) binario o esadecimale quando si lavorava col linguaggio macchina. L'assembly è un linguaggio di più alto livello.
In genere ci scrivono driver e cose di bassissimo livello (nel senso di più vicine possibile alla macchina fisica).

Ormai ha poco senso usare l'assembly. I compilatori fanno generalmente un buon lavoro, e soltanto in pochi casi, se strettamente necessario, si può pensare di ottimizzare qualche hot spot in assembly.
Più il linguaggio di programmazione è astratto (=facile da capire per un essere umano) più grossa viene la roba.

No, è l'esatto contrario: più il linguaggio è astratto, e meno codice serve per modellare la soluzione di un problema.
Originariamente inviato da: zappy
a me è parso di capire che rockroll sappia bene che vuol dire...

Ma anche no, perché ha mischiato contesti completamente diversi e confrontato mele con pere.

Anche oggi è possibile scrivere s.o. in assembly che occupino pochino KB. Il punto è: cosa ci fai? Poco. Perché mettono a disposizione poche, rozzissime, funzionalità.

Siccome l'appetito vien mangiando, allora dopo il classico "Hello, my o.s.", ti accorgi che ti serve una shell, un filesystem decente, ... un'interfaccia grafica, ecc. ecc. ecc. Cominci a scrivere tonnellate di codice, che non richiederanno più 30KB, ma 300KB, ... 3MB, ecc. ecc.

Esistono ancora oggi s.o. scritti interamente in assembly, e che occupano poco spazio. Uno dei più noti è MenuetOS . In poco meno di 900KB di archivio mette a disposizione parecchie funzionalità. Ma è tutto in assembly, e dunque i tempi di sviluppo sono biblici.
beh, una volta che compili in teoria tutta la complessità del linguaggio dovrebbe diventare solo 1 e 0 e sparire tutto ciò che serviva all'umano... no?

Se compili tutto, sì.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^