Verificando se un attaccante può inviare email contraffatte agli utenti del mio dominio.

Verificando se un attaccante può inviare email contraffatte agli utenti del mio dominio.

Recentemente ho deciso di provare lo strumento Truffa del CEO su un mio dominio. Sicuro che il mio fornitore avesse adottato tutte le misure di sicurezza, ho eseguito il test senza ulteriori indugi. Il risultato è stato positivo, il che significava inizialmente che un utente malintenzionato avrebbe potuto inviare un’e-mail per conto di chiunque altro all’interno dell’organizzazione. Ad esempio: potrei ricevere un’email dal mio capo (esempio: miocapo@nostrodominio.com) che mi chiede di effettuare un trasferimento di una determinata somma di denaro su un determinato conto bancario, senza essere effettivamente il mio capo, ma utilizzando esattamente il suo indirizzo Email !

Vista la situazione, ho contattato il mio fornitore di servizi di posta elettronica e ho ricontrollato la sicurezza fornita: Blocklist IP, Reputazione, Limiti di velocità, Filtri antispam, software Antimalware di ultima generazione e persino SPF, DKIM e DMARC correttamente configurati. Com’è possibile che abbia continuato a essere vulnerabile a questi attacchi, nonostante abbia apparentemente adottato tutte le misure tecniche per prevenirli?

Quindi ho eseguito il seguente test per verificare se ciò fosse possibile. Condivido le istruzioni affinché chi lo desidera possa applicarlo.

Come posso verificare se la mia identità può essere impersonata via e-mail?

Importante: ci sono molteplici vulnerabilità in un server di posta che possono essere sfruttate per falsificare le identità, questa è solo una di queste, spesso trascurata dai nostri provider, con gravi conseguenze.

Requisiti

  • Sistema OperativoWindows 10.
  • Applicazione per connettersi al server SMTP: Telnet Cliente (deve essere installato e abilitato). Alcune considerazioni:
    • I comandi Telnet non fanno distinzione tra maiuscole e minuscole.
    • Non è possibile utilizzare il tasto “backspace” nella sessione Telnet.
    • Se si commette un errore durante la digitazione dei comandi SMTP, premere Invio, quindi digitare nuovamente il comando. In caso contrario verrà visualizzato un errore simile al seguente: 500 5.3.3 Comando non riconosciuto.
  • Porta TCP del server SMTP: in genere è 25, 465 o 587. Questa è la porta TCP attraverso la quale il server SMTP riceve le richieste.

Istruttivo

Cerchiamo il nome del server responsabile dell’invio delle email dell’organizzazione che utilizza il protocollo SMTP. Per questo abbiamo bisogno del nome di dominio. Ad esempio, se sappiamo che thisorganizacion.com ha un server di invio della posta associato (usiamo account come nome@thisorganizacion.com), possiamo scoprire qual è quel server inserendo il dominio nello strumento mxtoolbox.

Supponiamo che sia mx-1.estaorganizacion.com.

Una volta ottenuto il nome del server SMTP, apriamo la console “Prompt dei comandi” e ci colleghiamo al server responsabile dell’invio della posta tramite l’applicazione Telnet.

1) Fare clic su “Avvia“.

2) Digita cmd nel motore di ricerca, quindi “Invio“.

3)Nella console digitiamo: telnet mx-1.estaorganizacion.com 25

4)Inseriamo i nostri dati dopo il comando telnet. In questo caso, il nome del server di posta che abbiamo ottenuto al punto 1 e la porta.

5)Digitiamo “Invio“.

6) La finestra verrà nuovamente cancellata, mostrando in alto qualcosa del tipo: 220 host.red.local Microsoft ESMTP MAIL Service ready at Thu, 21 Nov 2019 13:05:52 +0100

Una volta collegati, vediamo il cursore lampeggiare per iniziare a digitare i comandi. Successivamente forniamo istruzioni al server per inviare un’e-mail, digitando.

7)EHLO estaorganizacion.com

8) Digitiamo “ Invio”.

9) Salutiamo il server di posta e ottieni un elenco di parole chiave per indicare le estensioni supportate. Dovrebbe mostrare qualcosa del tipo:

250-host.red.local Hello [85.52.230.99]
250-SIZE 37748736
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 XRDST

10)  MAIL DA:<nicola@lamiaorganizzazione.com>

Qui scriviamo il nome della persona e il dominio che vogliamo appaia nel mittente dell’email che arriverà al destinatario. Io, come attaccante, impersonerei l’identità di Nicola, l’amministratore delegato di questa organizzazione.

11)  Digitiamo “Invio“. Dovrebbe essere visualizzato qualcosa di simile a: 250 2.1.0 Mittente OK.

12)  RCPT A: <virginia@lamiaorganizzazione.com>. Qui scriviamo l’indirizzo del destinatario della nostra email. Io, in qualità di attaccante, voglio che Virginia, il direttore finanziario di lamiaorganizzazione.com, lo riceva.

13) Digitiamo “Invio“. Dovrebbe essere visualizzato qualcosa di simile a: 250 2.1.5 Destinatario OK.

14)  DATA. Digitiamo “Invio“. Dovrebbe essere visualizzato qualcosa di simile a: 354 Avvia input posta; termina con <CRLF>.<CRLF>

15)  Oggetto: Bonifico URGENTE.

Scriviamo il testo dell’oggetto (è sempre scritto “Oggetto:“ e poi il messaggio che vogliamo. Digitiamo “Invio” 2 volte.

16)  Ciao Virginia, avrei bisogno che tu trasferissi 2000 euro sul conto 12987391. Mi servono entro oggi, altrimenti non potremo incorporare il nuovo stagista. Grazie.

Scriviamo il corpo del messaggio. Possiamo premere “Invio” per le interruzioni di riga tutte le volte che vogliamo. Una volta terminato, digitiamo “Invio“, quindi un punto (.) e infine “Invio” per chiudere il messaggio. Dovremmo ricevere qualcosa di simile a:

250 2.6.0 <e4030bf5-a0e5-4ef0-be7d-80e0b90a4588@HOST .red.local> [InternalId=29862907609751, Hostname=HOST .red.local] 1701 bytes in 20.701, 0,080 KB/sec Queuedmail for delivery

17)  QUIT.Digitiamo “Invio” per uscire dal sistema. Dovrebbe essere visualizzato qualcosa di simile a: 221 2.0.0 Servizio chiusura canale di trasmissione

Possibili risultati

Quando ho eseguito questo test, inviando un’e-mail alla mia casella di posta per conto di qualcun altro nell’organizzazione, l’ho ricevuta nella casella di posta senza problemi. Ciò significa che qualcuno avrebbe potuto fare la stessa cosa da qualsiasi possibile applicazione (non solo Telnet), poiché il mio server SMTP consentiva connessioni anonime (non autenticate).

Fortunatamente, il server di posta non era configurato come Open Relay, il che mi avrebbe permesso di inviare un’e-mail a qualsiasi indirizzo esterno a thisorganizacion.com. Open Relay consentirebbe ad altri di inviare SPAM utilizzando il mio server di posta, il che potrebbe farmi bannare.

Poi ho scoperto che era possibile impersonare chiunque si volesse, anche qualsiasi utente di Google, Yahoo Mail, ecc. Ciò ha senso, poiché l’e-mail viene inviata dallo stesso server di questa organizzazione e quindi non esegue alcun controllo di sicurezza come SPF, DKIM o DMARC.

L’inconveniente dei controlli tecnici

Quando un’organizzazione decide di intraprendere azioni di sicurezza delle informazioni, generalmente si concentra sull’implementazione di misure tecniche di sicurezza su o per proteggere le apparecchiature informatiche. Queste misure, da sole, comportano i seguenti inconvenienti:

  • Non coprono l’intero ambito e possono essere molto costosi. Infatti, per quanto ne implementiamo una dozzina, non coprono mai l’intero ambito (IoT, Cloud, dispositivi, ecc.), oltre a comportare costi molto elevati.
  • Possono essere facilmente omessi. Potremmo avere tutta la tecnologia di sicurezza informatica all’avanguardia gestita da esperti per proteggere i nostri sistemi, ma i criminali informatici utilizzeranno altri metodi, come l’ingegneria sociale, per attaccarci senza dover affrontare queste barriere.

Allo stesso tempo, potremmo contare sui migliori specialisti nelle tecnologie e nei servizi che l’area ICT fornisce all’organizzazione per cercare di garantire configurazioni corrette e sicure dal punto di vista tecnico, ma ci saranno sempre errori o omissioni.

Un esempio è il caso analizzato, dove la vulnerabilità è che il protocollo SMTP non richiede l’autenticazione per la sua implementazione, consentendo ad un attacker di eseguire le azioni dimostrate. Inoltre, se questa vulnerabilità venisse sfruttata per lanciare un attacco di ingegneria sociale (come quello esposto), che non coinvolge file o collegamenti con codice dannoso, le misure di sicurezza non avrebbero alcuna possibilità di fermarlo.

Soluzioni e conclusioni

Pertanto, per difendersi da questo e da ogni altro tipo di attacco simile, è necessario adottare uno schema di difesa approfondita che incorpori misure tecniche e fisiche di sicurezza delle informazioni ma senza dimenticare i controlli amministrativi, generalmente trascurati, come l’implementazione di politiche interne e consapevolezza degli utenti che garantiscono un cambiamento positivo nel loro comportamento.

Attualmente quasi nessuno garantisce che l’utente a contatto con la tecnologia abbia il profilo minimo necessario per rispondere correttamente alle minacce alla sicurezza rivolte all’organizzazione.

Di seguito dettaglio alcune delle linee guida che la formazione degli utenti dovrebbe includere per evitare di cadere in una trappola simile a quella analizzata:

  • Utilizzare l’opzione “Inoltra” e non “Rispondi” se devi rispondere a un’e-mail. Quando si inoltra l’e-mail, è necessario digitare l’indirizzo corretto o selezionarlo manualmente dalla rubrica. Molte volte quando utilizziamo l’opzione “risposta” crediamo di farlo al mittente originale quando in realtà è programmato per inviarlo all’attaccante.
  • Non condividere pubblicamente informazioni eccessive. Occorre prestare attenzione a ciò che viene pubblicato sui social network e sui siti web dell’organizzazione, in particolare tutto ciò che riguarda le mansioni e le descrizioni delle mansioni, le informazioni gerarchiche e i dettagli degli orari (esempio: fuori sede). Inoltre, maggiore è il numero degli account di posta elettronica aziendali esposti a Internet, maggiore è la vulnerabilità della tua organizzazione a un attacco di Spear Phishing. Attraverso questo strumento puoi verificare quali indirizzi email sono pubblicati su Internet.
  • Conferma le richieste critiche in più modi. Stabilire una procedura che consenta ai dipendenti di confermare le richieste effettuate tramite e-mail per un bonifico bancario o informazioni riservate in altri modi. Ad esempio, faccia a faccia o tramite telefonata utilizzando numeri precedentemente noti, non numeri di telefono forniti tramite e-mail.
  • Conoscere le abitudini di dipendenti, clienti e fornitori. Ad esempio, prestare attenzione se si verifica un improvviso cambiamento nelle pratiche o nei processi aziendali o personali. Se un contatto aziendale ti chiede improvvisamente di utilizzare il suo indirizzo e-mail personale quando tutta la corrispondenza precedente è avvenuta tramite e-mail aziendale, la richiesta potrebbe essere fraudolenta. Verifica sempre la richiesta tramite una fonte diversa.

Lascia un commento