Realizzare PKI con sw open-source

Acronimo di Enterprise JavaBeans Certificate Authority, EJBCA è un interessante software open-source per mettere in piedi un’infrastruttura a chiave pubblica (PKI) in grado di avvalersi di crittografia PQC (Post Quantum Cryptography) per emettere e proteggere i certificati digitali dei propri utenti e dispositivi.
Gestito e sponsorizzato dalla società svedese PrimeKey Solutions AB, il pacchetto software EJBCA può essere utilizzato per installare un’autorità di certificazione (una CA), un’autorità di convalida e un’autorità di registrazione gestibili privatamente.
Ormai giunto alla versione 9.4.2 nel momento in cui sto scrivendo, il software EJBCA è utilizzato per gestire autorità di certificazione (CA) in diversi contesti, tra cui e-Government, endpoint management, sistemi IoT, energia, telecomunicazioni, eIDAS, networking e perfino nell’ambito delle PMI.

Una Certification authority **EJBCA** sotto forma di appliance

Ma perché adottare una CA privata quando sono già disponibili quelle pubbliche? Il caso della compromissione della CA DigiNotar, nel 2011, rappresenta probabilmente uno degli esempi più emblematici dei rischi associati all’adozione di autorità di certificazione (CA) pubbliche. In un’infrastruttura PKI (Public Key Infrastructure), una Certification Authority (CA) è responsabile dell’emissione e della firma digitale dei certificati che attestano l’associazione tra una chiave pubblica e l’identità di un dominio o di un’entità. Nel modello delle CA pubbliche, tali certificati sono implicitamente considerati affidabili dai browser e dai sistemi operativi poiché inclusi nei trust store globali. Nel caso di DigiNotar, un attacker riuscì a compromettere l’infrastruttura della CA e a generare certificati fraudolenti per domini di alto profilo, tra cui servizi di Google. Poiché i certificati risultavano firmati da una CA pubblica riconosciuta, i browser li accettavano automaticamente come validi. Questo rese possibile l’esecuzione di attacchi MiTM (man-in-the-middle) su larga scala, intercettando comunicazioni HTTPS apparentemente sicure. L’incidente dimostrò come la compromissione di una singola CA pubblica possa avere conseguenze sistemiche sull’intero ecosistema di fiducia del web.

Una CA privata, al contrario, opera in un contesto di fiducia limitato (private trust domain). I certificati emessi non sono riconosciuti universalmente, ma solo dai sistemi configurati esplicitamente per fidarsi di quella specifica root CA. Questo riduce significativamente la superficie di attacco e l’impatto di un’eventuale compromissione: un certificato fraudolento sarebbe accettato solo all’interno dell’infrastruttura organizzativa e non dall’intera Internet.

Dal punto di vista della sicurezza operativa, inoltre, una CA privata consente un controllo più rigoroso delle policy di emissione, dei processi di autenticazione delle entità richiedenti nonché della protezione delle chiavi critiche (ad esempio tramite HSM e segmentazione della rete). In sintesi, mentre le CA pubbliche offrono scalabilità e interoperabilità globale, le CA private riducono il rischio sistemico limitando l’ambito di fiducia e migliorando il controllo amministrativo dell’infrastruttura crittografica 🔐

Link di approfondimento:
– Link1
– Link2
– Link3

nmap, una galassia di possibilità

Ancora oggi, molti addetti ai lavori utilizzano questo magnifico tool di Fyodor con superficialità… ad esempio in molti credono che da nmap non sia possibile farsi restituire solo gli indirizzi IP (quindi senza gli ulteriori dettagli che il tool normalmente ci restituirebbe) che hanno effettivamente la porta che ci interessa in stato open, ma come si evince da questa schermata, è possibile farlo concatenando in pipe qualche comando bash.

Di seguito il comando testuale se desideri (ri)utilizzarlo:
nmap -n -Pn target/subnet -p3389 -oG – | grep ‘/open/’ | awk ‘/Host:/{print $2}’
(attenzione agli apici e al simbolo – quando incollerai questo codice nella tua shell: riconfrontali con la videata, poiché WordPress cambia volutamente gli apici)

target/subnet va ovviamente sostituito con la sottorete che desideri scansionare (ma puoi inserire banalmente anche un unico target /32), come nella scansione che vedi in videata (da cui è possibile desumere che un sysadmin imprudente abbia lasciato raggiungibili da Internet ben 11 servizi RDP!), mentre immediatamente a destra del flag -p va inserito il numero di porta che ti interessa verificare (da remoto o in locale).

P.S.: è possibile personalizzare ulteriormente il comando per farsi restituire anche l’hostname del target di cui nmap rileva la porta aperta.

Letture di approfondimento:
– “Nmap Network Exploration” (Calderon, 2021)
– “Nmap Network Scanning: A Complete Guide to Exploring And Scanning Networks With NMAP” (S. Gellis, 2024)

Sessioni Windows anomale, un tool FOSS per rilevarle da remoto

Ti sei mai chiesto come rilevare eventuali sessioni utente sospette o insolite sui computer del tuo dominio Windows? FindUnusualSessions è un tool di enumerazione delle sessioni remote che sfrutta il protocollo Windows RPC per agevolare il rilevamento di anomalie relative agli utenti connessi alle tue reti.

🛠️ Funzionalità principali:
✅ segnala utenti di dominio esterni insoliti o inusuali che potrebbero costituire un sintomo di movimenti laterali o compromissioni non ancora individuate dai tuoi XDR/EDR
✅ utilizza RPC per interrogare da remoto i dispositivi Windows

OpenSSL e crittografia post-quantum

Manca poco (8 aprile 2025) al rilascio di un innovativo software gratuito per applicare crittografia moderna: OpenSSL 3.5.

Per la prima volta un’intera gamma di applicazioni, inclusi i web server, saranno in grado di utilizzare PQC (Post Quantum Cryptography) e quindi di migliorare la Cybersecurity del settore nonché dei servizi erogati. OpenSSL è la libreria globalmente più utilizzata per cifrare file e stream, e appunto dalla versione 3.5 supporterà la sostituzione del protocollo crittografico ECDH con ML-KEM nonché degli algoritmi RSA ed ECDSA con ML-DSA.

L’integrazione più interessante per lo scambio di chiavi sarà quella di poter utilizzare un metodo ibrido, come ML-KEM-X25519, il quale utilizza sia X25519 (con curve ellittiche) che ML-KEM per creare la chiave. Dalla versione 3.5 in avanti ci sarà anche la possibilità di applicare metodi di firma digitale ibridi, come ML-DSA-Ed25519.

Ulteriori informazioni disponibili su:
– Link1
– Link2
– Link3

Ricostruire i logon/logoff con LogonTracer

LogonTracer è uno di quegli strumenti Open Source che non dovrebbe mai mancare nell’arsenale di chi s’occupa di Incident Response e/o di Digital Forensics (DFIR)

Questo software analizza gli eventi correlati agli accessi (logon andati a buon fine), associa gli hostname (e/o gli indirizzi IP) e gli account correlati visualizzandoli in un grafico schematico: in questo modo è possibile vedere in quale account si verifica il tentativo di accesso, e quale host viene utilizzato. È davvero utile per controllare rapidamente gli account compromessi in contesti Microsoft AD (Active Directory) aziendali.

Nei grafici generati da LogonTracer ogni indirizzo IP, così come ogni hostname, viene rappresentato da un nodo avente delle connessioni (che rappresentano l’ID dell’evento) all’altro nodo (utente). LogonTracer consente quindi di filtrare, cercare ed esportare risultati, visualizzare la cronologia, e molte altre funzionalità.

Utilizza anche PageRank, il modello Hidden Markov e ChangeFinder per rilevare host ed account dannosi analizzando l’Event Viewer.

È anche possibile visualizzare i registri eventi in ordine cronologico:

Valido strumento da affiancare all’utilizzo di un SIEM (attenzione: da affiancare, non con cui sostituire!), puoi scaricarlo gratuitamente dalla pagina ufficiale del tool.

🔴 Attenzione: rammenta di abilitare l’audit su ogni workstation su cui desideri analizzare le attività di accesso (Audit Credential Validation, Audit Kerberos Authentication Service, Audit Kerberos Service Ticket Operations, Audit Logon, Audit Special Logon, Logoff)

Firme digitali falsificabili in Putty

Le versioni del noto software PuTTY dalla 0.68 alla 0.80 (inclusa) presentano una vulnerabilità critica nella parte di codice che genera firme dalle chiavi private ECDSA che utilizzano la curva NIST P521 (PuTTY, o Pageant, genera una firma digitale da una chiave quando la usi per autenticarti su di un server SSH).

A questa vulnerabilità è stato assegnato il CVE-2024-31497. La vulnerabilità è stata scoperta da Fabian Bäumer e Marcus Brinkmann, dell’Università della Ruhr di Bochum (è disponibile un loro articolo sulla mailing list oss-security), in Germania.

L’effetto della vulnerabilità è quello di consentire la compromissione della chiave privata. Un attacker o un utente malintenzionato in possesso di alcune dozzine di messaggi firmati (e della chiave pubblica) ha informazioni sufficienti per recuperare la chiave privata e quindi falsificare le firme come se provenissero da te, consentendogli (ad esempio) di accedere a qualsiasi server in cui utilizzi quella chiave per autenticarti. Per ottenere queste firme, l’attacker deve solo compromettere brevemente un qualsiasi server su cui si utilizza la chiave per autenticarsi, oppure ottenere momentaneamente l’accesso a una copia di Pageant che detiene la chiave (tuttavia, queste firme non sono esposte agli sniffer passivi delle connessioni SSH…).

Pertanto, se disponi di una chiave di questo tipo, i crittoanalisti consigliano di revocarla immediatamente: rimuovi la vecchia chiave pubblica da tutti i file Authorized_keys di OpenSSH e l’equivalente negli altri server SSH, in modo che una firma della chiave compromessa non abbia più valore. Genera quindi una nuova coppia di chiavi per sostituirla.
(il problema non riguarda il modo in cui la chiave è stata generata; non importa se proviene da PuTTYgen o da qualche altra parte: ciò che conta è se è stata mai utilizzata con PuTTY o Pageant).

La buona notizia: l’unico tipo di chiave crittografica inficiata da CVE-2024-31497 è l’ECDSA a 521 bit. Cioè una chiave che in Windows PuTTYgen si presenta come ecdsa-sha2-nistp521 all’inizio della casella “Impronta digitale chiave”, oppure come NIST p521 quando viene caricata in Windows Pageant, oppure ha un ID che inizia con ecdsa-sha2- nistp521 nel protocollo SSH o nel file della chiave. Altre dimensioni dell’ECDSA e altri algoritmi chiave non sono coinvolti dalla vulnerabilità, in particolare, non è coinvolto lo schema di firma Ed25519.

Link di approfondimento:
– Link1
– Link2
– Link3

Anydesk breach 2024

Sì, AnyDesk ha revocato il certificato digitale usato per firmare i suoi binari utilizzati da migliaia – milioni? – di utenti. Sì, hanno anche revocato le credenziali per accedere al loro portale. Tutto ciò che si sa al momento è questo, così come solo questa è la portata dei fatti pubblici nel momento in cui sto scrivendo. Il resto di quello che leggo nei forum e nelle testate del settore, in questi giorni, non sono altro che FUD spuri: client AnyDesk con backdoor, dump delle credenziali provenienti dalle violazioni ecc.. ossia quel tipo di pettegolezzi spesso privi di fondamento quando non risultano avvalorati da perizie informatiche giurate che ne appurino le veridicità senz’ombra di dubbio. Si trovano appunto molti FUD in rete, ma non ancora nessuno che mostri o abbia reso disponibili evidenze digitali in grado di avvalorare nero su bianco (o se preferite, byte su byte) i peggiori scenari di breach.

Ciò nonostante, qui trovi delle regole YARA per rilevare i binari firmati con un certificato digitale AnyDesk potenzialmente compromesso: fare comunque una ricerca sui filesystem dei nostri clienti non è una cattiva idea.

Server di posta “Secured by Design”

Aziende plurimiliardarie che investono milioni di euro in costose “soluzioni” (?) di Cybersecurity e consulenze erogate da fantomatici “esperti”, e poi immancabilmente si ritrovano a distanza di mesi o anni infettate da un ransomware o coinvolte in gravissimi incidenti informatici iniziati con una banale BEC.

Gente che blatera di Sicurezza Informatica senza conoscerne a fondo le reali basi ingegneristiche, sistemisti e tecnici ICT che venerano Active Directory come una panacea per tutti i mali, nonché Microsoft Exchange come “il” mail server per antonomasia…ma anche lì, incidenti su incidenti informatici dietro l’angolo.

La lungimiranza e la perspicacia, quel think outside of the box che ha permeato le vite di tanti acuti pensatori, nonché dei padri fondatori di Internet e di svariati progettisti, dovrebbe pervadere le riflessioni, le scelte progettuali e gli investimenti portati avanti anche dai manager e dai CISO italiani…o almeno, della maggior parte tra loro. Ma non è esattamente così.

Se davvero lo fosse, la maggior parte dei mail server ancor oggi utilizzati in Italia in ambienti Enterprise non continuerebbero ad essere basati su Microsoft Exchange piuttosto che su O365 (Microsoft Office 365)… sistemi su di cui più o meno periodicamente vengono scoperte devastanti vulnerabilità RCE (Remote Code Execution).

DoveCot, invece, è fatto di un’altra pasta: è un mail server Open Source ideato con la Sicurezza Informatica in testa; si definisce “Secured by Design”, ma puoi leggerlo come “Sicurizzato fin dalla progettazione”.

Un esempio emblematico: qualche anno fa l’ente Mozilla Open Source (non esattamente dei “bottegai” dell’informatica) ha commissionato un audit di sicurezza informatica su DoveCot, il primo audit pubblico del suo codice sorgente. Il team che ha eseguito l’audit è rimasto estremamente colpito dalla qualità del suo codice sorgente, dichiarando nero su bianco che “nonostante i molti sforzi e l’approccio onnicomprensivo, i penetration tester di Cure53 sono riusciti solo a confermare l’eccellente livello di sicurezza informatica di DoveCot. Più specificamente, sono stati riscontrati solo tre problemi di sicurezza nel codice, ma di scarsa gravità, traducendosi così in un risultato prestigioso per DoveCot, nonché una prova-provata del fatto che mantenere le aspettative di Cybersecurity è una priorità dello sviluppo e del funzionamento di questo software”. È possibile reperire il report dettagliato delle vulnerabilità riscontrate dal team dei penetration tester di Cure53 consultando questo URL.
Analogamente, a questo indirizzo è possibile leggere le più recenti vulnerabilità scoperte su DoveCot: provate a confrontare il numero di queste vulnerabilità (sia in quantità ma soprattutto in qualità/gravità!) con quelle scoperte su Microsoft Exchange, poi rifletteteci sopra chiedendovi se adottare software on-premises piuttosto che sistemi fruibili in SaaS per la posta elettronica sviluppati e distribuiti entrambi dalla Microsoft (società closed-source per antonomasia, anche omertosa quando si tratta dei propri databreach…leggetevi o rileggetevi, a tal proposito, dello scandalo riguardante il databreach di Microsoft Azure fatto emergere lo scorso anno dal senatore Ron Wyden e di questa recente inchiesta pubblicata sul Washington Post) sia ancora una scelta sensata e prudente.

LOLBins CTI-Driven

Acronimo di Living-Off-the-Land Binaries Cyber Threat Intelligence, LOLBins CTI-Driven è un progetto ideato per supportare gli analisti InfoSec nella ricostruzione di come i binari LOLBin vengano utilizzati dagli attacker durante un’intrusione. Il software è in grado di ricostruire il workflow percorso dai processi generando e mostrando un formato grafico compatibile con le piattaforme TIP e con lo standard STIX.

Di recente, alla piattaforma è stato aggiunto il supporto per il processo regsvr32.exe:

Perché proprio regsvr32.exe? Poiché viene comunemente utilizzato (abusato!) dagli attacker per avviare l’esecuzione di codice malevolo tramite proxy. Il suo utilizzo malevolo coinvolge attività come:
– il bypass degli agent di sistemi XDR ed EDR
– l’esecuzione di scriptlet COM per scaricare dinamicamente backdoor da iniettare in memoria
– l’avvio di script dannosi
– l’utilizzo di librerie .dll malevole
– la distribuzione di payload
– l’avvio di script remoti in grado di rilasciare ed eseguire file
– la persistenza dei malware all’avvio dei sistema operativi
– l’esecuzione di file con estensione .sct

LOLBins CTI in azione

Link di approfondimento:
– Link1
– Link2
– Link3

SolarWinds…e l’ingenuità dei suoi clienti (anche italiani)

La Securities and Exchange Commission statunitense di recente ha rivolto accuse contro la nota Corporation di sviluppo software SolarWinds, con sede in Texas, e contro il suo responsabile della Cybersecurity, Timothy G. Brown, per frodi relative a rischi e vulnerabilità di sicurezza informatica taciute agli investitori e consumatori. La denuncia sostiene che, dall’offerta pubblica iniziale dell’ottobre 2018 e almeno fino al momento dell’annuncio nel dicembre 2020, SolarWinds sarebbe stata l’obiettivo di un massiccio attacco informatico durato quasi due anni, soprannominato “SUNBURST”: la Corporation e Brown hanno frodato gli investitori sopravvalutando SolarWinds in malafede, nascondendo anche ai consumatori finali dei loro software i reali rischi informatici a cui andavano incontro. Dai documenti depositati presso la SEC si evince che durante quel periodo SolarWinds avrebbe ingannato gli investitori rivelando solo rischi generici e ipotetici, in un momento storico in cui, invece, la società e Brown erano perfettamente consapevoli delle carenze informatiche strutturali nelle architetture ICT e nelle policy di sicurezza informatica dell’azienda (volutamente omesse nei rapporti con l’esterno), nonché dei rischi sempre più elevati che la Corporation stava affrontando all’epoca.

Come sostiene la denuncia, le dichiarazioni pubbliche di SolarWinds sulle pratiche di Cybersecurity interne – e soprattutto sui rischi dei possibili incidenti informatici – erano apertamente in contrasto con le loro analisi tecniche, inclusa una presentazione del 2018 preparata da un ingegnere e condivisa internamente anche con Brown, secondo cui le configurazioni per l’accesso remoto ai sistemi e ai servizi SolarWinds “non erano molto sicure” (per usare un sottile eufemismo!), e che “qualcuno che dovesse sfruttare la vulnerabilità può praticamente fare qualsiasi cosa prima che noi lo scopriamo, finché non sarà troppo tardi”, il che potrebbe portare a “gravi perdite sia di reputazione che finanziarie”. Allo stesso modo, come affermato nella denuncia della SEC, le presentazioni interne del 2018 e del 2019 di Brown evidenziavano, rispettivamente, che “l’attuale livello della Cybersecurity espone le nostre risorse critiche ad un potenziale stato molto vulnerabile“, e che “l’accesso privilegiato ai sistemi critici nonché ai dati è inappropriato“.
(puoi continuare l’approfondimento sul testo originale della denuncia seguendo questo link)

Perché continuare ad usare i prodotti di una software house che evidentemente, in un modo o nell’altro, continua ad ingannare i suoi clienti? Non bastano forse i pesanti databrech subiti da questa Corporation negli anni passati a mettere sul chi vive il consumatore?

…evidentemente no, se ancora molte aziende italiane (ma anche estere) continuano ad utilizzare (probabilmente nella più beata ingenuità…o forse a causa di una più preoccupante negligenza massificata?) software commerciali sviluppati da questa ormai ingannevole software house. Timore di cambiare fornitore o pigrizia per un ipotetico passaggio al mondo Open Source? Solo il tempo e gli incidenti informatici attuali e futuri dimostreranno ai clienti SolarWinds quanto costa (in termini di migliaia di dollari o di euro) la mancata valutazione di alternative, magari di alternative basate su software di monitoraggio Open Source: versatili, efficienti, spesso lowcost quando non del tutto FOSS, ma soprattutto più sicuri poiché liberamente ispezionabili dalle Community (Open Source —> codice aperto…oltre che libero!) nonché riprogrammabili dagli utenti, e spesso progettati con i principi ingegneristici della Security by Design in testa…e non con l’obiettivo di massimizzare a prescindere i profitti con la vendita di licenze di software consapevolmente buggato e insicuro.