La QuickSand Sandbox Libraesva garantisce maggiore protezione contro gli allegati pericolosi

Autore: Redazione Argonavis
 

 

Anche nello scorso mese di ottobre è circolato via email un file PDF, denominato CORONAVIRUS SAFETY MEASURES, contenente un virus utilizzato per veicolare attacchi informatici.

A dispetto del suo nome, che all’apparenza sembra essere quello di un file contenente le misure di sicurezza da adottare durante la pandemia di Covid-19, CoronaVirusSafetyMeasures.pdf non è un documento, ma un file eseguibile (un programmino).

Il file già circolava nel mese di marzo, anche su Whatsapp.

E’ importante non scaricare o aprire alcun allegato con questo nome.

I file PDF sono tra le tecniche preferite dai cybercriminali per mietere le proprie vittime.

In particolare, nelle email, sempre più spesso vengono allegati:

  • File PDF attivi
  • File PDF con inclusi testi di link malevoli
  • File PDF con link malevoli.

La QuickSand Sandbox di Libraesva garantisce una maggiore protezione contro gli allegati pericolosi inviati tramite mail.

L’innovativa tecnologia Libraesva QuickSand Protection è in grado di rilevare e classificare i contenuti attivi in tutti i documenti Microsoft Office, file RTF e PDF.

In base al risultato dell’analisi è possibile rimuovere il contenuto attivo e consegnare il documento disinfettato o bloccare l’intero documento.

La Sandbox disarma anche tutti i link presenti nei PDF.

Per ulteriori informazioni o per richiedere una prova gratuita di Libraesva: dircom@argonavis.it

7 Dicembre 2020

Spiegati i misteriosi protocolli SPF, DKIM e DMARC

Tratto da: Security Blog Libraesva
Autore: Rodolfo Saccani – 2 novembre 2020
 
 

 

La posta elettronica è una cosa antica, è nata molto più tempo prima di Internet.

Il primo sistema di posta elettronica è nato nel 1965 al MIT. A quel tempo la comunicazione e-mail era limitata entro i confini di un unico mainframe, quei computer multiutente enormi, molto costosi e delicati che occupavano intere stanze climatizzate e richiedevano una supervisione continua.

Nel 1971 avvenne la prima trasmissione di un’e-mail tra computer collegati. È stato un piccolo passo per una singola email, ma un primo enorme passo per l’umanità.

Nel 1982 nacque il protocollo SMTP, questo è il protocollo che utilizziamo ancora oggi per lo scambio di email su Internet.

Il problema principale dell’email (e dell’SMTP) è che, essendo nato in un ambiente collaborativo in cui la sicurezza non era affatto un problema, essendo progettato in un momento in cui l’abuso non era nemmeno un’opzione teorica, il protocollo non aveva alcuna sicurezza a tutto tra i suoi requisiti di design.
Nessuna autenticazione del mittente: chiunque potrebbe fingere di essere chiunque.
Nessuna riservatezza : i messaggi sono stati scambiati e archiviati in chiaro.
Nessun controllo di integrità : non è stato possibile impedire o addirittura rilevare la manipolazione del contenuto dell’email lungo il percorso.
Nessuna protezione sui messaggi non richiesti : chiunque può inviare qualsiasi quantità di e-mail a qualsiasi destinatario.

Poi la posta elettronica è diventata popolare e questi problemi hanno iniziato a comparire rapidamente.

È diventato chiaro che dovevamo fare qualcosa per affrontare questa mancanza di sicurezza nel protocollo. Nessuno ci aveva pensato prima perché nessuno immaginava che l’e-mail sarebbe diventata ciò che è oggi: la principale forma di comunicazione elettronica su cui si basano le nostre società , qualcosa su cui tutte le organizzazioni, le imprese e gli individui fanno affidamento ogni giorno per gestire la propria vita .

Come tutti abbiamo imparato a nostre spese negli anni seguenti, aggiungere la sicurezza in seguito è molto più difficile che inserirla in fase di progettazione. Questo è uno dei principi più importanti del GDPR: se vuoi una sicurezza reale, ne hai bisogno fin dalla progettazione.

Aggiungere la sicurezza come ripensamento è difficile. È ancora più difficile se devi garantire la compatibilità con le versioni precedenti. La posta elettronica è l’esempio più chiaro di quanto sia difficile aggiungere sicurezza a qualcosa che è già distribuito in tutto il mondo, dove è necessario garantire che la posta elettronica possa ancora essere scambiata con server che non sono stati aggiornati ai nuovi standard.

È qui che entrano in gioco gli acronimi che si trovano nel titolo di questo articolo: SPF , DKIM e DMARC sono tre standard che sono stati aggiunti all’email nel tentativo di renderla più sicura.

SPF ha un compito molto semplice: prevenire lo spoofing del dominio. La tua organizzazione può dichiarare al mondo un sottoinsieme di indirizzi IP autorizzati a inviare email per conto del dominio della tua organizzazione. Definendo questo criterio, è possibile impedire ad attori malintenzionati di inviare e-mail fingendo di essere la tua organizzazione.
La configurazione di una policy SPF è molto semplice e relativamente priva di rischi: è sufficiente mappare tutti gli indirizzi IP che la tua organizzazione utilizza per inviare email. Un piccolo sforzo per ciò che ricevi in ​​cambio e se hai enumerato correttamente tutti i tuoi indirizzi IP legittimi da cui invii email, nessuna email andrà persa.
SPF non è perfetto, però, e non è sufficiente per prevenire tutti i tipi di spoofing, ma è comunque molto meglio di niente.

DKIM ha uno scopo principale: garantire l’integrità del contenuto dell’email. Integrità significa che il destinatario può rilevare se l’email è stata modificata o manomessa lungo il percorso. Questo avviene tramite una firma elettronica: se la firma è valida, sai che puoi fare affidamento sul contenuto dell’email. Se la firma non è valida, è probabile che il messaggio sia stato manomesso. Questa firma viene aggiunta e controllata automaticamente dai server di posta e l’utente non deve fare nulla.
L’impostazione di DKIM richiede un po ‘più di sforzo rispetto a SPF ma è sicuro: se lo si configura male, l’email non andrà persa.

SPF e DKIM non risolvono ancora completamente il problema del phishing. L’e-mail è un po ‘come una semplice lettera di carta: il mittente e il destinatario scritti sulla busta vengono utilizzati per la consegna, ma il destinatario non vede la busta. Il destinatario vede semplicemente la lettera all’interno della busta e in quella lettera il nome e l’indirizzo del mittente possono essere falsificati. Fondamentalmente, il client di posta mostra il mittente che è scritto nella lettera, non quello sulla busta (che può essere protetta con SPF).

DMARC è stato progettato esattamente per questo scopo: assicurarti che il mittente mostrato dal tuo client di posta elettronica sia affidabile. Ciò viene eseguito pubblicando un criterio DMARC che istruisce i destinatari a verificare se il mittente visualizzato dal destinatario corrisponde a SPF o DKIM. L’email deve essere inviata da un indirizzo IP autorizzato per quel dominio (SPF è ok), oppure deve essere firmata con una chiave legittima di quel dominio (la firma DKIM è ok), altrimenti non verrà consegnata.

DMARC deve essere configurato dominio per dominio dall’amministratore di posta elettronica del dominio di invio. Fornisce un’ottima protezione contro lo spoofing e la rappresentazione, ma la configurazione non è semplice e gli errori nella configurazione possono portare alla perdita della posta elettronica . Pertanto, la configurazione di DMARC deve essere eseguita con competenza, senza improvvisare.

Ci sono altri standard che sono stati introdotti nell’email, come TLS (per crittografare l’email in transito) e S / MIME o PGP per la crittografia end-to-end. Queste sono cose di cui non devi preoccuparti. TLS è gestito automaticamente dai server di posta. S / MIME e PGP hanno un’adozione minuscola a causa delle complessità legate alla gestione delle chiavi da parte degli utenti finali.

Ti interessa SPF, DKIM e DMARC per la tua organizzazione? Dovresti.
Inizia con SPF, quindi procedi con DKIM e infine valuta DMARC.

Queste configurazioni non risolveranno tutti i problemi di sicurezza della posta elettronica, ma renderanno la tua comunicazione e-mail molto più sicura e affidabile.

3 Novembre 2020

Email Security Tester

Per valutare la capacità di intercettazione ed eliminazione delle minacce e dei malware del proprio sistema di posta è disponibile il tool di Libraesva Email Security Tester.

Si tratta di un test gratuito, facile e veloce, non invasivo, del proprio sistema di protezione della posta.

Il tool invia 8 email , NON PERICOLOSE/NON INVASIVE , che simulano diversi tipi di minacce: il vostro sistema di protezione , se ben configurato, deve bloccarle.

Come si effettua il test?

  • Ci si collega al link che potete richiederci all’indirizzo dircom@argonavis.it
  • Si inserisce l’indirizzo email sul quale si vogliono ricevere le finte email malevoli
  • Si conferma l’indirizzo email rispondendo alla email in arrivo
  • Libraesva quindi invierà immediatamente 8 email, ognuna contenente un tipo di minaccia diverso. Le email ricevute sulla mailbox scelta per il test saranno quelle che sono riuscite a bypassare i filtri del sistema di posta.

Le eventuali email che dovessero passare i controlli di protezione del sistema di posta simulano un codice malevole ma non sono pericolose.

Un buon sistema di email security dovrebbe trattenere tutte le email malevoli.

Per informazioni tecnico/commerciali sulle soluzioni Libraesva: dircom@argonavis.it

 

22 Settembre 2020

Attacchi informatici, il 90% parte da una email

Lo specialista di email security Libraesva presenta le evidenze di un’analisi condotta in seno al settore bancario, nazionale ed europeo, con riferimento alla cyber sicurezza con focus sulle email, da anni canale prioritario di veicolazione di attacchi e infezioni malevoli.

Attacchi informatici, il 90% parte da una email

Strettamente intrecciato alla quotidianità delle persone in tutto il mondo, il settore finanziario è al centro delle economie globali e per questo è bersaglio dei cyber criminali che mostrano in misura crescente particolare interesse nel perpetrare i propri attacchi informatici contro le aziende di questo settore, tra le più colpite nell’area EMEA. L’incremento degli attacchi perpetrati contro le banche è cresciuto del +238% dal mese di febbraio 20201 (contro un incremento medio degli attacchi informatici che si attesta solitamente intorno all’80%) e sono oltre 3000 i dipendenti bancari ad avere subito un attacco da inizio anno.

In piena pandemia, Internet ha conosciuto un aumento d’uso per effettuare pagamenti e operazioni finanziarie, incentivando un notevole incremento dei cyber-attacchi. Se aziende e privati rimangono l’obiettivo preferito dei criminali informatici, le banche non sono quindi da meno e sono chiamate a reagire con piani di intervento su più fronti. Un recente studio di Moody’s1 identifica in tre modi come le banche mitigano il rischio informatico. Il primo è una forte governance aziendale, che comprende framework di sicurezza informatica, applicazione di policy e reporting. Il secondo è la prevenzione e la risposta al rischio, e la prontezza di recupero. Il terzo è la condivisione di informazioni con altre banche e l’adozione di standard e protocolli internazionali come strumento per fare fronte comune contro gli attacchi.

“Dal phishing al malware, passando per il Business Email Compromise, non si arresta il flusso delle minacce contro gli istituti di credito di tutto il mondo. In Italia la situazione è in linea con gli altri Paesi Europei e l’auspicio che in qualità di esperti di security possiamo fare è che si concretizzi la definizione di standard comuni utili ad affrontare in modo coeso la minaccia informatica in tutte le sue forme” afferma Paolo Frizzi, Ceo di Libraesva.

Le buone pratiche cominciano dai singoli

Se le banche stanno attuando misure e infrastrutture di protezione dedicate, d’altro canto gli stessi clienti possono contribuire a ridurre l’impatto potenziale degli attacchi via email. Gli esperti degli ESVAlabs, i laboratori di ricerca e sviluppo di Libraesva, grazie alla loro quotidiana attività di verifica e analisi di dati e informazioni trasmesse via email hanno stilato un vademecum di buone pratiche d’uso del canale email che consentono di elevare il livello di protezione dalla crescente e mutevole minaccia informatizzata che si articola in 5 principali punti:

  1. ATTENDIBILITA’ – Quando si eseguono operazioni bancarie, è opportuno operare direttamente dall’applicazione mobile dell’Istituto Bancario o cercando il sito ufficiale tramite i motori di ricerca web, senza selezionare alcun link fosse invece presente in comunicazioni email o SMS. Le mail legittime delle banche infatti solitamente non contengono link, cosa che invece si evidenzia nelle email di phishing
  2. ATTENZIONE – Quando si accede al sito della banca dal browser, assicurarsi che nella barra di ricerca compaia https://www… e che, quindi, la connessione al sito sia sicura. La forma http:// è oggi obsoleta e da considerarsi non attendibile
  3. TUTELA DEI DATI – Nel ricevere email che sembrano provenire dalla propria banca, controllare anzitutto se l’indirizzo email del mittente sia scritto correttamente, senza errori o elementi che destano sospetti, quindi non rispondere ad alcuna email fornendo dati personali relativi al proprio conto bancario o carte di pagamento
  4. SUPERVISIONE – Utilizzare password lunghe e complesse, evitando di ricorrere a quelle utilizzate già per altri siti
  5. CAUTELA – Non eseguire transazioni mentre si è connessi a reti Wi-Fi pubbliche, sia da pc che da mobile

“Questo elenco di piccoli seppur fondamentali accorgimenti consente di attivare un primo filtro umano che abbiamo constatato cooperare perfettamente con i filtri tecnici che i fornitori di servizi email mettono a disposizione degli istituti e degli utenti spiega Rodolfo Saccani, R&D Security Manager di Libraesva. Le tattiche di ingegneria sociale messe in atto dagli attaccanti puntano proprio a cogliere in fallo i più disattenti o noncuranti per varie ragioni. Eppure il fattore umano è in grado anche oggi con le minacce di nuova generazione di fare la differenza e di boicottare le iniziative malevoli degli aggressori”.

Redazione BitMAT – 17/09/2020

18 Settembre 2020

Libraesva : nuova ondata di campagne malware EXCEL 4.0 che abusano della funzione macro FORMULA

Estratto , tradotto, da un articolo di :
Rodolfo Saccani / Responsabile ricerca e sviluppo sicurezza @ Libraesva
L’articolo originale lo puoi trovare qui

MVBA è stato introdotto in Excel 5.0. Prima di allora Excel aveva solo macro XLM, che sono ancora supportate oggi.

Le macro XLM consentono di scrivere codice immettendo istruzioni direttamente nelle celle, proprio come le normali formule. In realtà sono chiamati macro-formule.

[omissis]

Ci sono alcune dichiarazioni tra queste macro-formule che consentono l’esecuzione di codice dannoso, queste sono denominate EXEC, RUN e CALL. Il mese scorso, nell’aprile 2020, è circolata un’ondata di malware che abusa di queste chiamate.

A maggio abbiamo visto una nuova ondata che apparentemente abusava ancora delle macro XLM ma senza chiamare EXEC, RUN o CALL. Al momento in cui li abbiamo ottenuti, la maggior parte di questi campioni aveva un tasso di rilevamento pari a 0 su virustotal, quindi sembra che valga la pena investigarli.

[omissis]

Alcuni di questi file stavano usando trucchi aggiuntivi per confondere l’analisi, come mettere le macro in fogli “nascosti”. Alcuni hanno usato fogli “molto nascosti”, altri sono stati protetti con la password “VelvetSweatshop” (che è un trucco usato da Microsoft per definire documenti di sola lettura). C’è anche una grande variabilità nei nomi dei file e nelle campagne e-mail. Non perderò tempo con questi dettagli e andrò subito al punto.

[omissis]

[Dall’analisi dei campioni , si e’ visto che tutti hanno in comune] l’abuso della macro-formula FORMULA. La denominazione ricorsiva può creare confusione, quindi lasciatemi fornire un po ‘di chiarimenti: proprio come qualsiasi altra istruzione formula (come IF o SUM per esempio), l’istruzione FORMULA può essere inserita in una cella sotto forma di formula. Questa affermazione particolare sembra essere denominata FORMULA stessa.

Cosa fa questa dichiarazione FORMULA? Immette una formula nella cella attiva (o in un riferimento). Fondamentalmente ciò che viene dato come parametro a questa chiamata diventa una fomula.

Generazione indiretta di formule se lo desideri e, sì, è pericoloso come sembra.

[omissis]

Questo è fondamentalmente il comportamento di questi campioni dannosi: creano una formula raccogliendo dati da molte celle diverse e apportando alcune trasformazioni. Quindi applicano la formula usando l’istruzione FORMULA.FILL (o una delle sue varianti, vedi il riferimento alle funzioni collegato sopra se sei interessato).

Il testo esatto del FORMULA è costruito in fase di esecuzione e ciò garantisce l’offuscamento che sembra essere efficace dato il punteggio zero o molto basso ottenuto da questi campioni su Virustotal.

[omissis]

Non siamo interessati a retroingegnerizzare ogni campione per scoprire i dettagli del comportamento. Come società di sicurezza della posta elettronica ci concentriamo sui metodi e sugli strumenti utilizzati dagli aggressori piuttosto che sulla specifica variante di malware.

Il nostro compito è bloccare queste minacce sul gateway, sappiamo che l’approccio del riconoscimento di elementi dannosi noti non è efficace e pertanto ci concentriamo sulla rimozione degli strumenti utilizzati dagli aggressori.

La filosofia del nostro sandbox QuickSand è più simile a un firewall: quando i nostri sistemi vedono un modello come questo, non si preoccupano davvero del reverse engineering del comportamento reale, non si preoccupano nemmeno di riconoscere se si tratta di una variante di malware nota o uno nuovo.

Che sia diretto o indiretto, non è consentito alcun modo di eseguire materiale per i documenti consegnati via e-mail. Questo approccio è meno soggetto all’evasione ed è proattivo: blocca le varianti attuali e future, note e sconosciute.

Il basso tasso di rilevamento di questi campioni su virustotal e su molti servizi di sandboxing basati sulla virtualizzazione conferma che, per essere efficace con le minacce in continua evoluzione, questo è un approccio migliore.

Estratto , tradotto, da un articolo di :
Rodolfo Saccani / Responsabile ricerca e sviluppo sicurezza @ Libraesva
L’articolo originale lo puoi trovare qui

16 Maggio 2020