Report del 25/01/2023
nomedominio.it
Indice dei contenuti
- Haiku report Che cos’è Haiku? Che cosa fa Haiku?
- Haiku score e dati di analisi La valutazione dell’esposizione “perimetrale” dell’azienda - I riferimenti e i dati relativi al dominio analizzato.
-
Gli ambiti verificati
I campi oggetto di analisi
- Credential Leak Password e credenziali a rischio.
- Certificates Health Stato dei salute dei certificati SSL.
- DNS Health La salute del DNS e del server di posta elettronica.
- Vulnerability Analysis Tutte le vulnerabilità registrate negli anni.
- Open ports and services Analisi dello stato delle porte di comunicazione dell’infrastruttura.
- Assets distribution La collocazione geografica degli IP Pubblici.
- Questionario&Dichiarazioni necessari per ricevere quotazione della polizza Cyber
Haiku Report
Haiku è un motore capace di raccogliere e analizzare tutte le informazioni correlate al cyber-risk perimetrale di un dominio. Si tratta di una web-application che continua a evolversi autonomamente, grazie a un algoritmo per la stima del livello complessivo di rischio che auto-apprende dalla propria esperienza, sulla base delle tecniche di intelligenza artificiale (machine learning). Haiku – che è stato creato da un team di ethical hacker* - analizza le debolezze di un’infrastruttura, valuta le potenziali vulnerabilità in diversi ambiti e restituisce uno score complessivo insieme a commenti, dati specifici e indicazioni sulle prime azioni da compiere per limitare i rischi.
Il report generato è costruito con lo scopo di aiutare l’azienda analizzata a comprendere il livello della propria esposizione, di attivare interventi correttivi e anche – grazie alla collaborazione con un team di professionisti assicurativi – d’identificare molti dei parametri necessari per definire la polizza Cyber più adatta, in termini di garanzie.
Haiku ha scelto di esprimere e commentare i dati dell’assessment con una forma espressiva che permette anche ai “non addetti ai lavori” di comprendere facilmente gli output.
*esperti di sicurezza informatica che compiono attacchi informatici a reti, infrastrutture IT, siti web o applicazioni, unicamente per identificare e risolvere eventuali vulnerabilità e migliorare la sicurezza.
L'origine del nome
L’haiku è un componimento poetico breve, nato in Giappone nel XVII secolo, che vuole sintetizzare in pochi versi - diciassette unità di suono complessive – concetti, stati dell’essere o della natura, in maniera efficace e pregnante, ma soprattutto comprensibile a tutti.
Questo documento cerca di utilizzare gli stessi valori che stanno alla base degli haiku: verità, sintesi, efficacia e chiarezza.
Haiku Score
L’Haiku Score rappresenta la sintesi finale - definita in centesimi - dell’esposizione in nove diversi ambiti che vengono preventivamente analizzati, uno per uno. L’immagine sotto riportata rappresenta graficamente le aree meno esposte (evidenziate in verde) e quelle più scoperte.
Lo score finale non è una mera media delle singole valutazioni ma è riparametrato sulla scorta degli ambiti più delicati e del segmento di attività.
Score ottenuto: 33 / 100
Riferimenti e dati di analisi
| Dominio | nomedominio.it |
| Questionario&Dichiarazioni | Questionario compilato |
| Data di generazione del report | 25/01/2023 |
| Data di creazione del dominio | 10 August 2000 |
| Data di scadenza del dominio | 03 February 2023 |
| Data di ultimo aggiornamento | 18 July 2022 |
| Provider | Non disponibile |
Lista dei sottodomini individuati:
- Hostname: nomedominio.it, IP: 172.**.**.95
- Hostname: shop.nomedominio.it, IP: 185.**.**.167
- Hostname: www.nomedominio.it, IP: 185.**.**.167
- Hostname: autodiscover.nomedominio.it, IP: 52.**.**.152
- Hostname: ftp.nomedominio.it, IP: 193.**.**.33
- Hostname: lyncdiscover.nomedominio.it, IP: 52.**.**.12
- Hostname: sip.nomedominio.it, IP: 52.**.**.11
- Hostname: vpn.nomedominio.it, IP: 94.**.**.73
- Hostname: webmail.nomedominio.it, IP: 104.**.**.44
Credential Leak
Per capire meglio
Molte “credenziali” di utenti di ogni genere sono state rubate (hackerate) e spesso rivendute nel corso degli ultimi 20 anni ed è possibile ritrovarle - complete di password in chiaro - nel DEEPWEB (la parte più nascosta e senza controlli di internet). Questa esposizione rappresenta una delle maggiori vulnerabilità delle infrastrutture IT. È infatti probabile che, nonostante l’utente abbia modificato la password, lo abbia fatto solo parzialmente: la maggior parte delle persone mantiene nel corso della sua vita una sorta di perniciosa coerenza nelle scelte cambiando solo alcuni caratteri o numeri. Un malintenzionato potrebbe, seguendo un pattern - una sorta di algoritmo che prova e riprova temi e combinazioni simili o collegate a quella trovata – accedere ad esempio alla VPN aziendale e/o alle mail. Questo pericolo evidenzia peraltro come l’utilizzo di email aziendali per registrarsi a servizi privati (come ad esempio siti di streaming), sarebbe da disincentivare.
I test effettuati
Haiku ricerca nel DEEPWEB e in altre fonti tutte le mail appartenenti al dominio che talvolta presentano anche la password in chiaro o crittografata.
I risultati
| Nome utente | Credenziali rubate | Fonti di leak |
|---|---|---|
| info@nomedominio.it | Password in chiaro: ******x | la****************************y) |
| info@nomedominio.it | Password in chiaro: *****7 | ca************************y) |
| info@nomedominio.it | Hash della password: **********************= | ***** |
| amministrazione@nomedominio.it | Hash della password: **********************= | ***** |
| web@nomedominio.it | Hash della password: ******************************3 | se**********************y) |
| mrossi@nomedominio.it | Password in chiaro: ****************i | Co*******************************************21 |
| mrossi@nomedominio.it | Password in chiaro: ******3 | Co*********************************************************************on |
INDICAZIONI PER AFFRONTARE IL RISCHIO
Non esiste una “tecnica” specifica per prevenire questa tipologia di attacco (*1) e questo semplicemente perché non dipende dalla qualità delle difese IT messe in atto sulla propria struttura. Nella maggior parte dei casi, infatti, l’esfiltrazione di credenziali e password è compiuta su siti, portali e app che non hanno nulla a che vedere con l’organizzazione stessa.
La criticità resta però nel fatto che tra i dati rubati “all’esterno” spesso ci sono USER ID e PASSWORD direttamente o indirettamente associati alle e-mail aziendali. Sono queste stesse che vengono poi utilizzate dagli attaccanti per effettuare tentativi di accesso all’organizzazione, per il tramite di specifici attacchi di Credential Stuffing/Reuse (*2): la sopradescritta tipologia di attacco che consiste appunto nel riutilizzare credenziali rubate per tentare di ottenere l’accesso sui sistemi cui fanno riferimento, quali e-mail o VPN aziendali.
Va poi considerato che nel caso in cui l’attaccante non riuscisse a identificare password valide, potrebbe comunque intentare una campagna di phishing sugli indirizzi e-mail collezionati nelle fonti di Leak (*3 e *4).
Come mitigare il rischio
- Limitare al massimo l’inserimento di dati sensibili su piattaforme di terze parti
- Evitare di utilizzare la mail aziendale per scopi privati
- Creare e applicare “policy” efficaci di cambio password a tutti i propri account aziendali e privati
- Dove possibile utilizzare meccanismi di 2 factor-authentication
- Promuovere attività di formazione e condivisione sulla Cyber-Security Awarness per tutti gli utenti dell’organizzazione per assicurarsi che siano consapevoli dei rischi derivanti dall’uso inconsapevole della rete e responsabilizzati sulle attività che svolgono.
Referenze
- *1 Credential Leak: https://attack.mitre.org/versions/v10/techniques/T1589/001/
- *2 Brute Force: Credential Stuffing: https://attack.mitre.org/versions/v10/techniques/T1110/004/
- *3 Gather Victim Email Addresses: https://attack.mitre.org/versions/v10/techniques/T1589/002/
- *4 Search Engines: https://attack.mitre.org/versions/v10/techniques/T1593/002/
Certificates Health
Per capire meglio
Il protocollo di comunicazione HTTPS serve a garantire o, quantomeno, ad aumentare la sicurezza della comunicazione tra server WEB e l’utente che lo naviga, attraverso un’operazione di cifratura asimmetrica che riduce il rischio di subire attacchi di tipo man in the middle, di qualcuno cioè che, all’insaputa delle parti, resta in mezzo al flusso di dati osservandoli, immagazzinandoli oppure danneggiandoli.
I test effettuati
Haiku controlla i certificati (SSL / TLS) che permettono il funzionamento del protocollo HTTPS per verificare che gli stessi siano aggiornati e/o installati in maniera corretta. Una criticità registrata non solo sul certificato principale, ma anche su quelli intermedi, potrebbe portare a una fragilità su cui un malintenzionato potrebbe intervenire modificando, impossessandosi o interrompendo la comunicazione (spesso in maniera non percepita dagli utenti dell’organizzazione).
I risultati
| Certificato | Host | Ambito indagato | Risultato |
|---|---|---|---|
| *.online.lync.com | 52.**.**.12:443 | Heartbleed | Fallito |
| *.online.lync.com | 52.**.**.12:443 | Expired | Passato |
| *.online.lync.com | 52.**.**.12:443 | Versioni TLS sicure: TLSv1.2 | Passato |
| *.online.lync.com | 52.**.**.12:443 | Cipher sicuro utilizzato: ECDHE-RSA-AES256-GCM-SHA384 | Passato |
| *.online.lync.com | 52.**.**.12:443 | Public Key Bits: 2048 | Passato |
| sipfed.online.lync.com | 52.**.**.11:443 | Heartbleed | Fallito |
| sipfed.online.lync.com | 52.**.**.11:443 | Expired | Passato |
| sipfed.online.lync.com | 52.**.**.11:443 | Versioni TLS sicure: TLSv1.2 | Passato |
| sipfed.online.lync.com | 52.**.**.11:443 | Cipher sicuro utilizzato: ECDHE-RSA-AES256-GCM-SHA384 | Passato |
| sipfed.online.lync.com | 52.**.**.11:443 | Public Key Bits: 2048 | Passato |
| *.nomedominio.it | 94.**.**.73:443 | Heartbleed | Passato |
| *.nomedominio.it | 94.**.**.73:443 | Expired | Passato |
| *.nomedominio.it | 94.**.**.73:443 | Versioni TLS sicure: TLSv1.2, TLSv1.3 | Passato |
| *.nomedominio.it | 94.**.**.73:443 | Cipher sicuro utilizzato: TLS_AES_256_GCM_SHA384 | Passato |
| *.nomedominio.it | 94.**.**.73:443 | Public Key Bits: 4096 | Passato |
INDICAZIONI PER AFFRONTARE IL RISCHIO
Una sessione SSL/TLS che utilizza un certificato scaduto non dovrebbe mai essere autorizzata dal Client: si tratta di un errore d’impostazione che potrebbe portare a incorrere nei descritti attacchi del tipo man-in-the-middle (*1).
Per limitare fortemente questo rischio è consigliabile l’acquisto/rinnovo di tutti i certificati SSL per il tramite di enti verificati e autorevoli. È importante, inoltre, che i vecchi certificati - non più validi – siano rimossi dai server.
Una sessione SSL/TLS che utilizzi un certificato “auto-firmato” mostra un messaggio di allarme in quanto il certificato non è stato verificato da un ente certificatore accreditato. Nonostante il traffico e le credenziali scambiate fra il Client e il Server vengano comunque crittografate, è altamente consigliato quindi provvedere ad applicare un certificato attendibile lato Server.
Pubblicare servizi associati sulla base di un certificato “auto-firmato” espone infatti l’organizzazione alla potenziale sfiducia dei fruitori del servizio, che potrebbero non ritenerlo autorevole e sicuro.
L’uso di un certificato scaduto – anche qualora non si verifichi un rischio di sicurezza - espone l’organizzazione a perdite di reputazione e/o comunque alla diminuzione della fiducia del Cliente.
Come mitigare il rischio
- Assicurarsi che le chiavi pubbliche dei certificati SSL siano firmate da enti certificatori attendibili.
- Evitare che i certificati installati vadano in scadenza provvedendo a una gestione metodica e puntuale dei rinnovi.
- Assicurarsi che l'url chiamato dal client corrisponda al nome host associato al certificato SSL.
Referenze
- *1 Man-in-the-Middle: https://capec.mitre.org/data/definitions/94.html