Toyota, uno dei più grandi produttori di auto al mondo, pochi giorni fa ha subito un fermo produzione non banale in 12 su 14 delle sue fabbriche in Giappone, fermo macchina che ha causato la mancata fabbricazione di circa 13.000 veicoli. Un attacco hacker andato a segno? Forse un ransomware? Nulla di tutto questo: è bastata una manutenzione programmata di alcuni database server, su cui tuttavia in quel momento non era disponibile sufficiente spazio disco. Questo tipo di incidenti informatici (contrariamente a quanto pensa il mainstream, la Cybersecurity non ha solo a che fare con gli hacker o i malware) dimostra la complessità delle connessioni tra i vari sistemi operativi e dispositivi, le diverse e numerose procedure operative da non trascurare, l’importanza fondamentale del monitoraggio dei sistemi e dei servizi ICT, la serietà con cui andrebbe effettuato il testing dei processi di backup e delle connessioni ridondate, le potenziali conseguenze sul piano tecnico ed economico di un incidente generato evidentemente dalla negligenza.
Investire in Sicurezza Informatica vuol dire anche investire in sistemi di monitoraggio, vuol dire prevenire potenziali incidenti informatici di questo e di altro tipo. L’incidente della Toyota evidenzia almeno due aspetti su cui riflettere: il primo è che pur essendo una solida Industria 4.0 (come Toyota e altri colossi del settore), storici e banali incidenti informatici (banali nelle cause tecniche, ma non nelle conseguenze) di questo tipo posso comunque capitare se i sistemisti di turno non vigilano a sufficienza su allarmi e sensori; il secondo, è che pur investendo in costosi software commerciali (come verosimilmente avrà fatto Toyota) questi problemi possono comunque sorgere se il progettista, il sysadmin o il dirigente di turno non ha pensato bene (o addirittura non ha mai più di tanto immaginato!) agli scenari di fault (un sottoinsieme della Cyber threat modeling) e alle cause che possono generarli…ergo, è sempre l’ingegno dell’Uomo unito alla nostra attenzione che fa la differenza, è sempre la nostra capacità di immaginare le opportunità tecnologiche piuttosto che le potenziali minacce informatiche nei contesti più disparati che può fare la differenza tra un incidente informatico e una serena continuità di servizio, non lo strumento adottato in sé.
Nagios e CACTI sono due eccellenti software di monitoraggio sistemistico, molto utili a tal fine, peraltro Open Source. Certo non sono gli unici, ma ne garantisco la loro efficacia.
E tu, cosa utilizzi come sistema di monitoraggio, e cosa come sistema di backup? Li testi entrambi periodicamente? Ne effettui il monitoraggio H24 con procedure a prova di fault, magari anche con l’ausilio di un SIEM?
Fantastico syslog server che nella sua versione gratuita consente di raccogliere e gestire messaggi syslog al massimo da 5 indirizzi IP sorgente: non è decisamente intuitivo il fatto che se non si provvede a editare la maschera in alto subito dopo l’installazione, i pacchetti syslog di tali client – pur se configurati a puntino come è successo a me – Windows o Linux che siano, non verranno visualizzati nella finestra principale del server mai e poi mai (tale problema non si manifesta nella versione a pagamento: in tal caso, infatti, basterà inserire solo l’IP 255.255.255.255 per autorizzare la raccolta di tutto il traffico syslog diretto al server).
Un video esplicativo delle sue tante funzionalità.
Le applicazioni e i moderni siti Web gestiscono ormai enormi quantità di traffico HTTPS. Due dei principali strumenti per garantire l’efficienza dei sistemi su larga scala sono i bilanciatori di carico (o Load Balancer) e i proxy inversi (o Reverse Proxy)
Tuttavia, affrontano la gestione del traffico in modi leggermente diversi.
I Load Balancer si occupano di instradare le richieste dei client su più server, al fine di distribuire agilmente il traffico di rete prevenendo colli di bottiglia: ciò aiuta a massimizzare il throughput, riducendo i tempi di risposta e ottimizzando l’utilizzo delle risorse. Quando in un’architettura di rete è presente un Load Balancer, ecco cosa accade: 1) le richieste dei client vengono inviate al Load Balancer invece che direttamente ai server che ospitano l’applicazione 2) attraverso un algoritmo di bilanciamento, viene selezionato uno dei server disponibili dall’elenco degli host a disposizione del Load Balancer 3) la richiesta del client in coda viene inoltrata al server selezionato. 4) il server elabora le richieste e invia la risposta al Load Balancer 5) a sua volta il Load Balancer inoltrerà la risposta al client
Un Reverse Proxy, viceversa, è un server che si trova tra i client esterni e le applicazioni interne. Sebbene i Reverse Proxy possano distribuire il carico di rete come farebbe un Load Balancer, forniscono funzionalità avanzate come la terminazione del traffico TLS/SSL, la memorizzazione in cache, nonché aspetti di sicurezza informatica. I Reverse Proxy sono più interessati a limitare e salvaguardare l’accesso al/ai server.
Sebbene Load Balancer e Reverse Proxy possiedano teoricamente funzionalità distinte, nella pratica i confini possono confondersi, poiché molti software possono espletare sia le funzioni di un Load Balancer che quelle di un Reverse Proxy, come ad esempio è in grado di fare Nginx, un eccellente software FOSS (giunto ormai alla versione 1.25 nel momento in cui sto scrivendo) che può svolgere entrambi i ruoli a seconda della configurazione.
Microsoft Office e Google Docs al momento sono i software più utilizzati nel mercato delle Suite per ufficio, ossia quelle applicazioni per scrivere ed editare testi, creare fogli di calcolo e produrre presentazioni. Ma entrambe le suite hanno anche alcune limitazioni, che in certi casi possono costituire una barriera per alcune categorie di utenti.
Per esempio, Microsoft Office richiede una licenza che va acquistata, ma soprattutto gestita quando si passa da un computer a un altro, e inoltre non è disponibile per Linux se non in versione on-line tramite browser. Google Docs, d’altro canto, salvo casi particolari è utilizzabile solo quando si è connessi a Internet, e comunque implica la possibilità che Google legga (!!!) quello che scriviamo (“Accediamo ai tuoi contenuti privati soltanto se abbiamo la tua autorizzazione o se siamo obbligati per legge”, sostiene Google nel suo portale ufficiale), con ovvie implicazioni legate a possibili violazioni della Privacy personale e professionale.
Una soluzione a questi scenari è costituita da LibreOffice, una suite gratuita realizzata dalla Document Foundation, che di recente ha pubblicato la relativa versione 7.6 Community. LibreOffice permette di creare gratuitamente testi avanzati, fogli di calcolo e presentazioni nel formato standard OpenDocument, ma è altrettanto in grado di leggere modificare e creare file nei più classici formati proprietari di Microsoft Office.
LibreOffice, anche se accetta donazioni, è da sempre gratuito nonché Open Source, con l’indubbio vantaggio di offrire la massima trasparenza e flessibilità: l’utente può così evitare i costi e soprattutto le complicazioni dovute all’uso di licenze commerciali, è disponibile in oltre 120 lingue (compreso naturalmente l’italiano) su tutti i principali sistemi operativi, e dal 2011 viene sviluppato e mantenuto da una vasta comunità internazionale di programmatori volontari.
Lo utilizzo quotidianamente dal 2012 per tutti i documenti Office, compresi quelli di lavoro, e trovo impagabile la sua semplicità d’uso: fa tutto quello che mi serve su tutti i computer che uso, non mi assilla con scadenze e minacciose richieste di rinnovi di licenza come invece mi accadeva quando ero ancora un utente Microsoft Office. Vero, la compatibilità con alcuni formati Microsoft Office non è perfetta (specialmente negli scenari con documenti aventi formattazioni complesse) ma nella maggior parte dei casi è assolutamente accettabile, e se si utilizza il suo formato di default, ossia OpenDocument, si ha la garanzia di poter rileggere e rieditare i propri documenti anche a grandissima distanza di tempo.
Se desideri provarlo o direttamente installarlo, puoi scaricare LibreOffice dal seguente URL: sono disponibili le versioni per Windows, macOS e Linux. Ha un altro vantaggio importante rispetto alla concorrenza: funziona anche su vecchisistemi operativi (da Microsoft Windows 7 SP1 in su, e da macOS 10.12 in su) e offre anche alcuni prodotti per i s.o. Android e iOS. La versione per macOS è disponibile sia per i computer dotati dei recenti processori Apple Silicon, che per quelli che montano i più tradizionali processori Intel.
Questo video riassume le principali novità della versione 7.6, la più recente nel momento in cui sto scrivendo:
A onor del vero, per esperienza posso confermare che dei punti di criticità esistono, in particolare nell’ipotesi d’implementazione di macro VBA o nella gestione di file Excel di grandi dimensioni (per intenderci con griglie che ospitano decine di migliaia di righe contigue), ma trattasi di scenari poco diffusi, ergo, LibreOffice costituisce un FOSS funzionale ed aggiornato, valida alternativa per tantissimi utenti Microsoft Word, Excel e PowerPoint, nonché per tutti quelli come me stanchi di dover aggiornare tempestivamente i vari Microsoft Office installati presso i clienti poiché privi delle necessarie hotfix di sicurezza informatica pubblicate da Microsoft in ritardo rispetto ai relativi exploit scovabili in rete o nell’underground (una fra le tante storiche vulnerabilità, ma emblematica di quanto sia opportuno patchare o direttamente abbandonare sistemi Microsoft Office: l’RCE Follina)
Il buon vecchio FOSS draw.io (divenuto da poco app.diagrams.net) conserva ancora il suo prestigio e la sua semplicità d’utilizzo nel 2023, continuando ad essere un valido strumento per molti progettisti ICT/OT (me compreso), valida alternativa al commerciale Microsoft Visio.
È possibile usarlo sia on-line accedendo al portale app.diagrams.net, piuttosto che appunto off-line scaricando gratuitamente l’applicazione standalone da questa URL GitHub.
Semplice ed essenziale nel suo utilizzo ma anche estremamente versatile, il software è dotato di numerosissime icone ed oggetti con cui realizzare nonché arricchire schemi di Networking e/o schemi architetturali di Cybersecurity. Per quanto riguarda lo stile grafico c’è solo l’imbarazzo della scelta tra i suoi numerosi template.
Alcuni esempi:
Preferisco francamente la versione standalone, installabile in locale: lavorare con calma al progetto, salvando poi la bozza architetturale sulla mia postazione in uno dei formati supportati (.html, .png, .svg o .drawio (il default)) non ha prezzo, rappresenta per me un connubio tra Creatività e Ingegneria informatica applicata.
A progetto finito, si potrà inviare il file al cliente con uno dei formati selezionati in precedenza, scegliendo se condividere l’intero progetto editabile (e quindi dando al nostro interlocutore a sua volta la possibilità di rieditarlo), o solo la veste grafica.
Modelli di attacco informatico per aggirare l’autenticazione a due fattori (o 2FA, Two-Factor Authentication, come d’ora in avanti indicherò nell’articolo) ne esistono da anni, ma alcuni metodi stanno diventando sempre più pervasivi a causa dell’aumento delle organizzazioni che adottano e implementano la 2FA con leggerezza. Sebbene siano svariati i modi attraverso cui un attacker possa tentare di violare un account su cui è stata abilitata la 2FA, il presente post tratta di una tecnica facile da sfruttare, ma difficile da prevenire: i siti di phishing proxy.
I siti di phishing proxy sono versioni più avanzate della tipica pagina di phishing per la raccolta di credenziali, in quanto consentono l’intercettazione dei token di autenticazione. Tali siti sono anche noti come siti Man-in-the-Middle/Machine-in-the-Middle (“MitM“) o Adversary-in-the-Middle (“AitM“) poiché si pongono tra l’utente (vittima) e un servizio apparentemente legittimo ma impersonato dall’attacker.
Esistono diversi kit di phishing disponibili su GitHub, e creati per essere utilizzati da Red Team e penetration tester consentendo di creare i propri siti web da utilizzare in attacchi di phishing proxy: Evilginx2, Modlishka e EvilnoVNC sono tutti kit per effettuare phishing che dispongono di modelli per servizi popolari come Okta®, Microsoft 365® (“M365“), Google Workspace® e altri.
Evilginx2: una panoramica operativa Si tratta di un framework FOSS per realizzare attacchiphishing. Evilginx2 è scritto nel linguaggio di programmazione Go e viene fornito con vari phishlet integrati per imitare egregiamente le pagine di logon per Citrix, M365, Okta, PayPal, GitHub nonché altri sistemi e ambienti operativi: per ospitare il sito di phishing deve essere configurato utilizzando un’infrastruttura server nonché un dominio personalizzato.
L’attacker acquista un dominio, configura il DNS ed esegue i comandi necessari per strutturare il sito di phishing su di un server, ad esempio con il phishlet O365 integrato: nel periodo di tempo in cui il sito rimarrà attivo e raggiungibile, tutti gli utenti target che visiteranno il collegamento di phishing generato da Evilginx2 saranno accolti da una pagina web graficamente identica alla legittima pagina di accesso Microsoft. I comuni consigli di sicurezza informatica (“best practices”) sostengono che le pagine senza l’icona del lucchetto (la cui presenza indica l’effettiva adozione del protocollo di crittografia TLS tra client e server HTTPS) nella barra delle URL del browser dovrebbero mostrare una bandierina rossa in caso di attività dannose o di problemi con il certificato digitale: ma Evilginx2 a sua volta richiede l’adozione di un certificato TLS da Let’s Encrypt, una Certification Authority gratuita e (per usare un sottile eufemismo) poco attenta ai controlli di Identità, il che significa che le sue comunicazioni sono cifrate con HTTPS, con conseguente possibilità di effettuare phishing anche dei portali che sfruttano tale protocollo: per un utente l’unico modo per distinguere la seguente pagina web da quella di accesso legittima (ossia l’autentica) sarà l’analisi dell’URL o del certificato digitale (questo secondo caso è spesso prerogativa dei soli addetti ai lavori, programmatori, sistemisti o professionisti InfoSec).
Pagina di accesso fraudolenta visualizzata dalla vittima del phishlet Evilginx2O365 integrato
Se un utente ignaro inserirà le sue credenziali nella pagina di accesso fraudolenta, il sito di phishing le controllerà con Microsoft per assicurarsi che siano autentiche. Successivamente, all’utente verrà richiesta una normale verifica 2FA attraverso uno qualunque dei metodi abilitati sul proprio account M365. Ad esempio, se l’account della vittima è stato configurato per ricevere SMS e/o telefonate come secondo fattore di autenticazione, la schermata che gli si presenterà potrà essere così:
Se la 2FA viene approvata con successo, alla vittima sembrerà di aver effettuato un accesso con le proprie credenziali. Gli sforzi per accedere a risorse aggiuntive richiederanno un altro accesso poiché l’attacker dovrà ora sganciarsi dal sito ingannevole per accedere al vero workspace on-line della vittima. Gli utenti potrebbero essere avvertiti da una richiesta aggiuntiva di autenticazione o dal fatto che tutto ciò che è stato promesso loro nell’e-mail di phishing non è al momento disponibile, ma molti utenti potrebbero ancora non rendersi conto di essere stati oggetto di phishing.
Dall’altra parte (lato attacker) l’operatore del sito di phishing avvierà il comando sessions dalla propria istanza Evilginx2, potendo così visualizzare tutte le credenziali acquisite, nonché i dettagli su qualsiasi sessione specifica e token associati, similmente al seguente screenshot:
L’attacker ora provvederà a copiare il testo del cookie (visibile nella parte inferiore delle informazioni sulla sessione) importandolo in un browser utilizzando qualsiasi plug-in di modifica dei cookie (come ad esempio EditThisCookie). Quando aggiornerà la pagina di accesso di Microsoft, verrà eseguito l’accesso come utente sottoposto a phishing. Il seguente diagramma mostra ad alto livello il workflow dell’attacco:
Evidenze utili a scopo di Digital Forensics Sebbene possa essere intricato identificare con certezza l’uso di un sito di phishing che sfrutti proxy malevoli come Evilginx2, esistono modelli su cui periti forensi e analisti InfoSec possono far affidamento per accertare se un attacker ha effettivamente rubato il cookie di un utente attraverso un sito di phishing, tra cui:
accessi che continuano a essere effettuati da indirizzi IP anomali
tutte le attività degli attacker avranno lo stesso SessionId, anche se il cookie viene spostato dal server di phishing per essere importato in un browser di un altro sistema
gli accessi iniziali dal server di phishing appariranno come la stringa dello User Agent legittimo della vittima
Indirizzi IP anomali In questo scenario è possibile applicare i tipici metodi per identificare compromissioni della posta elettronica. Anche se all’utente sembra che stia accedendo tramite Microsoft, le sue credenziali verranno inviate a Microsoft tramite il sito di phishing, quindi sarà l’indirizzo IP pubblico del phishing server, e non l’IP del device utilizzato dall’utente, che apparirà nei log del primo accesso.
Coerenza dell’ID di sessione L’indirizzo IP del server di phishing viene tracciato a seguito del primo accesso, ma potrebbe cambiare con la successiva attività loggata. Nei tipici attacchi AitM, l’accesso avviene sul server di phishing ma l’autore dell’attacco poi sposta il cookie su di un’altra macchina, per importarlo in un browser. Poiché il cookie è il medesimo, il SessionId nell’Unified Audit Log (“UAL”) sarà coerente tra gli accessi, anche se proverranno da indirizzi IP e/o User Agent differenti. Per gli eventi riconducibili a UserLoggedIn, nell’UAL è possibile reperire il SessionId sotto la voce “Device Properties”.
Esempi di Audit Log unificati che mostrano gli accessi effettuati dagli attacker
Nella griglia l’indirizzo IP del server di phishing è evidenziato in rosso, e termina con .91, mentre l’indirizzo IP del sistema fake gestito dall’attacker è evidenziato in arancione (ha .94 come ultimo ottetto). Gli accessi successivi con l’indirizzo IP .94 si sono verificati quando l’attacker ha importato il cookie catturato dal server di phishing in un browser Chrome, continuando a interagire con l’account della vittima: il SessionId visualizzato in blu è lo stesso durante tutta l’attività di phishing, poiché l’attacker ha riutilizzato il medesimo cookie di autenticazione.
User Agent pattern In molte indagini riguardanti accessi abusivi alle e-mail, chi si occupa di Digital Forensics può rilevare l’attività criminosa seguendo le tracce dello User Agent, che è una stringa che identifica il tipo di dispositivo e il client utilizzati per accedere all’account. Generalmente l’utente legittimo avrà uno User Agent diverso da quello dell’attacker poiché quest’ultimo accede dalla propria infrastruttura. Tuttavia, Evilginx2 è in grado di acquisire la stringa dello User Agent della vittima, dando così la possibilità all’attacker di clonare l’User Agent dell’utente legittimo: questo significa che sebbene il sito di phishing possa essere eseguito su un sistema Linux, se la vittima fa click sul collegamento utilizzando Firefox su un computer Windows 10, lo User Agent che sarà tracciato nei file di log risulterà identico a quello originale della vittima. Nei log UAL mostrati nella griglia, ad esempio, la finta vittima durante i test ha effettuato l’accesso al sito di phishing utilizzando Windows 10 e il browser Opera, lo stesso User Agent che viene rilevato negli accessi iniziali originati dall’indirizzo IP del server di phishing.
Questo tentativo di fondersi con accessi legittimi nei log di autenticazione ha implicazioni sostanziali per gli investigatori: senza uno User Agent anomalo, l’unico chiaro indicatore di compromissione nell’evento di accesso è l’indirizzo IP difforme. In uno scenario in cui l’attacker dovesse impiegare una botnet o un’altra infrastruttura appartenente a ISP aziendali, il rilevamento di questa attività diventerebbe molto complicata.
Nella seconda fase dell’attacco, una volta catturati i cookie, il phisher provvederà a importarli nel suo browser: il truffatore potrà visualizzare lo User Agent dalla sessione catturata all’interno di Evilginx2, e clonarlo all’interno del proprio browser in modo da non destare sospetti.
Tecniche di Prevenzione
Autenticazione FIDO2 I meccanismi di autenticazione basati su hardware che sfruttano i protocolli FIDO2 attualmente sembrano essere il miglior modo per mitigare il rischio che un attacker eluda la 2FA in una qualunque delle sue forme. L’autenticazione FIDO2 utilizza chiavi crittografiche preregistrate (con un servizio come Microsoft 365) per consentire all’utente di autenticarsi su quel sito: la sfida presentata al dispositivo FIDO2 dal servizio include dettagli sull’origine della richiesta (come l’URI del sito) ed é per questo che i tentativi di autenticazione a un sito di phishing fraudolento utilizzando questi protocolli falliscono miseramente. Esempi di autenticazione FIDO2 includono token hardware come Yubikeys o una soluzione integrata nel laptop utente come Windows Hello.
Tuttavia, laddóve sono disponibili anche metodi di autenticazione alternativi, esiste il rischio di attacchi di downgrade all’autenticazione FIDO2: ad esempio, un’organizzazione può aver impostato l’autenticazione FIDO2 come metodo principale, ma in alternativa potrebbe anche consentire l’invio di password monouso (OTP) tramite SMS o e-mail. Oltre a questo rischio, ci sono ragioni logistiche per cui l’autenticazione FIDO2 può essere difficile da implementare, infatti, il suo utilizzo costituisce un cambiamento strutturale per la maggior parte degli utenti e in molti casi comporta costi aggiuntivi per le organizzazioni che allo stato attuale utilizzano standard di autenticazione vetusti.
Circoscrivere gli accessi Le organizzazioni che continuano a utilizzare notifiche push, telefonate o SMS come secondo fattore di autenticazione dovrebbero prendere in considerazione l’utilizzo di un approccio di sicurezza informatica a più livelli che includa anche la limitazione degli accessi esterni agli account utente: questo scenario generalmente viene implementato consentendo l’accesso remoto solo da indirizzi IP approvati, come il range degli indirizzi IP delle VPN aziendali, ma soprattutto richiedendo che i dispositivi di autenticazione siano gestiti dall’organizzazione attraverso l’utilizzo di PKI, certificati digitali e architetture di rete basate sullo standard Zero Trust: tali controlli e modelli architetturali costituiscono misure di Cybersecurity efficaci e drastiche in grado di rendere estremamente difficile la vita alle cybergang.
Protocolli di sicurezza su più livelli Ulteriori tecniche che aiutano a ridurre al minimo il rischio che questo attacco vada a segno già nelle sue fasi iniziali includono l’utilizzo di filtri antispam (utilizzando i filtri incorporati nella piattaforma di posta elettronica aziendale piuttosto che (ancora meglio) quelli disponibili in un’appliance di terze parti) e di proxy web per filtrare il traffico HTTP/HTTPS degli utenti. Attraverso l’uso dei proxy, agli utenti può essere facilmente impedito di visitare siti di phishing noti o altri portali appartenenti a categorie rischiose per la postazione stessa dell’utente ma soprattutto per la rete informatica dell’organizzazione. Un altro fattore chiave è la formazione in ambito Cybersecurity, in particolare sul tema Phishing: istruire dipendenti, manager e consulenti esterni dell’organizzazione a identificare email palesemente contraffatte o pericolose attraverso “campagne di Phishing” a sorpresa, volte a scoprire chi in azienda non è ancora in grado di distinguere un’email autentica da un tentativo di Phishing, è fondamentale, aggiungerei doveroso per un reale progresso della Cybersecurity Posture.
Sebbene la riduzione della durata dei token non impedisca completamente la possibilità di un accesso abusivo agli account target, limita concretamente l’impatto complessivo sull’organizzazione, riducendo al minimo il tempo che un attacker avrà a disposizione per raggiungere i suoi obiettivi fraudolenti. Nello specifico di M365, i Sysadmin possono modificare la durata della sessione: l’accesso condizionato può infatti essere configurato anche per particolari gruppi di utenti, come gli amministratori. Il reset delle password in M365 invaliderà i vecchi token persistenti, costituendo quindi un’efficace deterrente per gli account che hanno subìto questo attacco.
Considerazioni conclusive La Cybersecurity è in continua evoluzione e le capacità degli attacker di eludere la 2FA non sono una novità. I furti di sessione e gli attacchi AitM esistono da anni, ma con il crescente numero di organizzazioni che stanno adottando la 2FA come linea difensiva, gli attacker stanno a loro volta raffinando le tecniche per effettuare accessi abusivi negli account delle vittime. Tali attacchi costituiscono una minaccia non solo per i classici sistemi e servizi di posta elettronica aziendale (BEC), poiché anche altri servizi come Okta, Citrix ecc.. sono potenzialmente a rischio della medesima minaccia. La compromissione di questi account può avere come conseguenza la violazione della rete dell’organizzazione su vasta scala, culminando nella distribuzione a tappeto di ransomware, nel furto e/o nell’esfiltrazione di dati, nonché, dulcis in fundo, nell’installazione di kit APT per un futuro riutilizzo o rivendita delle backdoor impiantate nella rete del target, ovviamente a totale insaputa dell’organizzazione.
Gli attacker possono potenzialmente aggirare la 2FA anche senza possedere le competenze tecniche necessarie per creare un sito di phishing proxy. Servizi di Phishing-as-a-Service si noleggiano per circa duecento euro al mese, una cifra irrisoria rispetto a quanto può guadagnare illecitamente un truffatore da un singolo bonifico bancario reindirizzato. Scenario ancora più facile per l’attacker è quello in cui l’utente target (o potremmo dire utOnto in questo caso!) disgraziatamente accetti notifiche push sul proprio smartphone anche quando non ha avviato di sua iniziativa il logon su di un portale web: sebbene la 2FA sia uno strumento indispensabile e non negoziabile nel mondo della Cybersecurity, non costituisce una soluzione definitiva. Perduto e perso chi crede fermamente il contrario.
Nelle mani di un analista InfoSec, Ghidra semplifica il processo di Reverse Engineering e consente agli utenti di personalizzare ed estendere le analisi per soddisfare le esigenze individuali o del cliente, migliorando contemporaneamente i flussi di lavoro. Ghidra è accessibile e fondamentale anche per chi si avvicina al mondo del Reverse Engineering, in particolare grazie al decompilatore incluso che può aiutare a comprendere più chiaramente le relazioni tra i linguaggi ad alto livello e i codici disassemblati mentre si esplora l’intricato mondo dell’analisi binaria. Ghidra è una complessa suite di strumenti di Reverse Engineering Open Source in continua evoluzione, tant’è che la community di utenti Ghidra continua a migliorare ed estendere le sue capacità.
DLest è un’applicazione freeware utilizzabile per individuare le funzioni esportate nei file PE (Portable Executable), in particolare in file DLL. Con DLest è facile enumerare le funzioni utilizzando una varietà di metodi, tra cui il trascinamento della selezione, l’apertura di una cartella o la scansione ricorsiva di un folder sfruttando i filtri delle espressioni regolari, ad esempio per includere solo i PE con specifici nomi di funzioni di esportazione.
Oltre alla possibilità di analizzare file PE archiviati su disco, DLest consente anche l’analisi dei moduli caricati in memoria nonché la manipolazione in tempo reale delle funzioni esportate, rendendolo uno strumento prezioso per attività di Reverse engineering o durante le fasi di Incident Response. Puoi persino eseguire il dump di una versione ricostruita di qualsiasi modulo per future analisi o riutilizzi di vario tipo.
Essendo un tool multithreading, garantisce un’elaborazione tempestiva anche in presenza di un gran numero di file PE. Che tu sia un programmatore che sta cercando di individuare e/o manipolare le funzioni esportate, piuttosto che un malware analyst che necessita di uno strumento affidabile per le attività di ogni giorno, DLest può costituire una preziosa risorsa FOSS da inserire nella tua cassetta degli attrezzi.
Tra le caratteristiche che trovo degne di nota:
supporta file eseguibili sia per ambienti x86-32 (PE) che x86-64 (PE+)
caricamento dei file tramite Drag and Drop (supporta l’UAC)
caricamento dalla finestra di dialogo aperta
caricamento di file dall’intera cartella
possibilità di cercare file PE attraverso controlli avanzati (scansione in profondità, ricorsiva e filtraggio delle funzioni di esportazione tramite regex)
scansiona e analizza i moduli mappati in memoria dal processo in esecuzione
possibilità di effettuare una ricerca contestuale integrata tramite Google
DLest consente di utilizzare la finestra di dialogo predefinita di Microsoft Windows per selezionare uno o più file PE (Portable Executable) da analizzare: apparirà una finestra di dialogo standard che ti permetterà di navigare nel computer target, e selezionare i file PE che desideri caricare.
Dopo che avrai selezionato i file di tuo interesse, verranno sottoposti a un processo di filtraggio per garantire che siano file PE validi, ossia di un’architettura compatibile con la versione DLest che hai installato. Questo processo garantisce che in DLest vengano caricati solo file compatibili. Utilizzando la modalità file aperto, puoi facilmente caricare e analizzare i singoli file PE secondo le tue necessità, sia per scopi di sviluppo che di analisi di malware: che tu abbia bisogno di esaminare un singolo file piuttosto che un corposo elenco, la modalità file aperto in DLest ti consente di farlo comodamente.
La modalità “open folder” scansiona rapidamente una singola directory consentendo di identificare tutti i file Portable Executable (PE) validi al suo interno, in particolare file DLL, utilizzando lo stesso filtraggio della modalità “open file”.
La modalità “scan folder” consente di eseguire la scansione completa di un albero di directory, individuando eventuali librerie DLL che offrono funzioni esportate. Questa modalità consente di eseguire la scansione ricorsiva di una cartella e delle sue sottocartelle, alla ricerca di file PE compatibili e validi che offrano funzioni esportate. Una delle caratteristiche principali di questa modalità di scansione è la sua capacità di utilizzare query avanzate di espressioni regolari (regex) per filtrare determinati file in base ai nomi delle loro funzioni esportate. Ciò può essere particolarmente utile se stai cercando funzioni specifiche o se hai bisogno di escludere determinati file dalla scansione. Oltre ai file DLL, la modalità “scan folder” include anche la possibilità di cercare qualsiasi file PE compatibile: ciò lo rende uno strumento versatile per individuare e analizzare le funzioni esportate in una varietà di diversi tipi di file PE. Che tu debba individuare rapidamente le funzioni esportate in una singola cartella piuttosto che eseguire una scansione più avanzata di una struttura di directory più ampia, puoi farlo sfruttando questa modalità di scansione.
Il caricamento dalla modalità Processo in esecuzione di DLest consente di analizzare l’intestazione PE (Portable Executable) per le funzioni esportate direttamente da moduli in memoria, piuttosto che dai file archiviati su disco. Questa funzionalità può giovare a tutti coloro a cui occorre analizzare funzioni esportate in tempo reale o che hanno necessità di lavorare con moduli caricati in memoria che non sono archiviati su disco.
Per utilizzare il caricamento dalla modalità Processo in esecuzione basta selezionare il processo desiderato dall’elenco dei PID in esecuzione sul sistema: DLest analizzerà l’intestazione PE del processo selezionato, identificando eventuali funzioni esportate al suo interno. Particolarmente utile per analizzare e manipolare le funzioni esportate in tempo reale, questa funzionalità consente di accedere direttamente ai moduli in memoria di un processo in esecuzione.
Dump Reconstructed PE Image Tale funzionalità consente di salvare una copia di qualsiasi modulo mappato in memoria – da un processo di destinazione – in un file per ulteriori analisi o utilizzi. Per utilizzare questa funzione è necessario selezionare il processo e il modulo desiderati da un elenco di processi attualmente in esecuzione, e i relativi moduli mappati in memoria. DLest creerà quindi una copia del modulo selezionato e lo ricostruirà in un formato che può essere letto da analizzatori PE o altri strumenti. L’immagine PE ricostruita può essere salvata in un file sul sistema per un uso successivo: ti consentirà di esaminare il modulo in modo più dettagliato, ricostruendone il comportamento e/o riutilizzandolo per test o altri scopi.
La funzionalità di filtraggio delle esportazioni ti consente di utilizzare espressioni regolari per selezionare le sole funzioni esportate in tempo reale che ti interessano. Per utilizzare questa funzione, inserisci semplicemente un’espressione regolare nel campo designato e fai click sul pulsante applica. DLest filtrerà l’elenco delle funzioni esportate utilizzando la regex, visualizzando solo quelle che corrispondono al modello. Sebbene questa funzione possa essere molto comoda, vale la pena notare che potrebbe essere più lenta se applicata a un numero molto elevato di funzioni esportate. In tali casi, potrebbe esser necessario più tempo affinché DLest applichi il filtro e aggiorni la visualizzazione, tuttavia, nella maggior parte dei casi la funzione di filtraggio delle esportazioni in tempo reale è rapida ed efficiente, il che la rende uno strumento prezioso per individuare rapidamente funzioni esportate specifiche o escludere quelle indesiderate.
DLest è in grado di loggare eventuali errori o problemi che si verificano durante l’analisi dei file PE (Portable Executable), oppure quando un file di destinazione non contiene funzioni esportate. Ogni qual volta dovesse verificarsi un errore o un problema durante l’analisi di un file PE (ma anche quando un file di destinazione non dovesse contenere funzioni esportate), nella finestra di dialogo Logs verranno tracciati degli avvisi informativi: saranno presenti dettagli sul file in questione, sulla natura dell’errore, come tracce dello stack pertinente nonché altre informazioni diagnostiche.
funzionalità “Extended Libraries Informations”
È una funzionalità che mostra un elenco di file PE (Portable Executable) analizzati dal contesto della scheda corrente, insieme a una varietà di dettagli su ciascun file:
nome della libreria (così come appare nell’intestazione del file)
conteggio esportazioni: mostra il numero totale di funzioni esportate per libreria
la dimensione del file espressa in byte
hash del file: MD5, SHA1 e SHA256
attributi del file: ad esempio se è di sola lettura o nascosto.
Dallo stesso autore di DarkComet e SubSeven Legacy, un ottimo FOSS utilizzabile sia per effettuare analisi e approfondimenti in ambito Incident Response nonché in ambito sviluppo software / troubleshooting Windows. Nel momento in cui sto pubblicando questo articolo, puoi scaricare il codice sorgente di DLest da questo link.
A lavoro, a casa, o all’università hanno inserito dei blocchi che ti impediscono di accedere a WhatsApp con la connessione che utilizzi? E allora tu bypassa i blocchi sfruttando un proxy server!
Da qualche giorno WhatsApp ha introdotto la possibilità di accedere ai suoi servizi attraverso server proxy. Questa nuova funzionalità permette alle persone di accedere e mantenere l’accesso a WhatsApp anche se c’è in atto un tentativo di bloccare le connessioni, o interromperle. Scegliendo di transitare attraverso un proxy, potrai sostanzialmente collegarti a WhatsApp tramite un server “ponte” esterno creato da volontari e/o organizzazioni umanitarie in tutto il mondo per consentire alle persone di comunicare liberamente (i tuoi messaggi personali continueranno a essere protetti da crittografia end-to-end… a parte i metadati (il problema sulla mancata cifratura dei metadati si manifesta comunque anche senza l’utilizzo di server proxy)).
Questa opzione è disponibile attraverso il menù delle Impostazioni per tutti gli utenti che stanno utilizzando la versione più recente di WhatsApp.
Un proxy server espone più porte a seconda dello scenario in cui lo si utilizza, tuttavia le porte di default tipicamente includono:
porta 80: per il traffico HTTP (meglio non utilizzare questa porta)
porta 443: per il traffico web cifrato attraverso il protocollo HTTPS
porta 5222: per il traffico di rete del protocollo XMPP/Jabber (il default per WhatsApp)
Dunque, come collegarti con un proxy? (istruzioni per i sistemi basati su Android)
individua l’indirizzo IP di un proxy server (in rete trovi tanti blog, articoli e video che spiegano come fare, nonché liste di proxy server aggiornate anche a poche ore fa: basta cercare)
Nella scheda Chat, seleziona la voce di menù Altre opzioni > Impostazioni
successivamente Spazio e dati > Proxy
pigia ora su Usa proxy
pigia quindisu Imposta proxy e inserisci l’indirizzo IP pubblico del proxy che hai individuato precedentemente
conferma facendo click su Salva
apparirà una piccola icona con un segno di spunta verde, ma solo se la connessione al proxy è riuscita!
diversamente, se non riesci a inviare o ricevere messaggi WhatsApp utilizzando il proxy che hai inserito, sono possibili due scenari:
è possibile che quel proxy nel frattempo sia stato bloccato, oppure
quel proxy non è più on-line per qualche motivo (manutenzione, piuttosto che abbia raggiunto il numero massimo di connessioni contemporanee configurate dal sysadmin per l’intervallo temporale in cui stai provando a collegarti)
in entrambi gli scenari puoi selezionare e tener premuto l’indirizzo IP del proxy per eliminarlo, e successivamente inserire l’indirizzo IP di un altro proxy per riprovare la connessione
Puoi consultare i seguenti link per ulteriori informazioni:
link3 (interessante paginetta per chi non volesse affidarsi ad un proxy di qualcun altro, ma desiderasse mettere in piedi il proprio…magari piazzandolo in qualche datacenter estero poco propenso a mantenere i log delle connessioni dei propri clienti)
…o contattarmi se hai problemi con i proxy pur avendone provati diversi
Perché chiedere al cliente di installare un software R.A.T. (più comunemente noti come software di teleassistenza) di terze parti quando è possibile accedere da remoto a una postazione Windows 10/11 attraverso un software verosimilmente già presente nel sistema operativo? E’ il caso di Microsoft Quick Assist (o “Assistenza rapida” nella versione italiana di Microsoft Windows), interessante alternativa al più classico servizio RDP o ai vari TeamViewer, AMMI Admin, Anydesk ecc..ecc..
Uno dei vantaggi dell’utilizzo di questo software è che non abbiamo necessità di conoscere (ma soprattutto di chiederglielo!) l’indirizzo IP del pc/server utilizzato dal cliente a cui stiamo per fornire assistenza tecnica (scenario estremamente comodo quando abbiamo a che fare con utenti a digiuno di networking, o ancor peggio con veri e propri utOnti che alla parola TCP/IP vanno in tilt e si rifiutano categoricamente di collaborare sostenendo a prescindere “non lo so fare”). D’altronde, tuttavia, leggendo anche la documentazione ufficiale del servizio, si scopre che di fatto il traffico di rete per l’assistenza sistemistica transita attraverso i sistemi in Cloud di Microsoft… con tutte le implicazioni di (dubbia) Privacy del caso.
“Assistenza rapida” è un tool per la teleassistenza molto semplice da usare, ma a differenza di altri R.A.T. richiede appunto che la postazione del cliente a cui vogliamo accedere da remoto sia presidiata (quanto meno per farci comunicare il codice d’accesso iniziale). Ovviamente, in contesti bancari e/o militari (ma aggiungerei anche in tutti quei contesti in cui in ballo c’è la tutela di brevetti e/o segreti industriali) ne scoraggio l’utilizzo per ovvi motivi legati a potenziali minacce alla Privacy dei sistemi coinvolti e dei dati in transito.
dmzware.com 