Anche se “l’anno di Linux sul desktop sarà l’anno prossimo” (cit.), ormai le distro moderne funzionano senza troppi problemi anche per gli utenti meno tecnici. A complicare le cose, spesso, ci si mettono gli altri. Nello specifico la TS-CNS italiana (Tessera Sanitaria/Carta Nazionale dei Servizi) e il middleware sviluppato da Bit4id.
Normalmente ci sarebbe OpenSC per interagire con i certificati presenti all’interno della Smart Card, tramite le API PKCS#11 fornite dalla libreria opensc-pkcs11.so. Ma la CNS italiana è “speciale” e quindi ha bisogno di un middleware proprietario. Ci pensa Bit4id ed è scaricabile da qui oppure da qui come riportato anche nel Wiki di Ubuntu, ma voi non fatelo!.
Fantastico che ci sia la versione per Linux, ma il pacchetto .deb per le distro Debian/Ubuntu utilizza un PATH non standard e installa all’interno delle directory di sistema destinate alle librerie alcuni file (con estensioni .rc e .conf) non conformi agli standard, dove normalmente dovrebbero essere presenti esclusivamente file con estensione .so (ELF shared object).
A seguito dell’installazione, il sistema genera dei warning ogni qual volta venga eseguito ldconfig.
Warning all’esecuzione di ldconfig
Ho segnalato la questione a Bit4id. Nel frattempo possiamo sfruttare InfoCert GoSign che si porta dietro la stessa libreria middleware (libbit4xpki.so) evitando così di installare il pacchetto buggato.
GoSign è un software per la firma digitale e, visto che supporta la TS-CNS, ha bisogno di quel middleware. InfoCert l’ha inclusa nel suo pacchetto di installazione di GoSign per Debian/Ubuntu.
Autenticazione CNS e Firma Digitale con TS-CNS su Linux Debian/Ubuntu, un’installazione pulita senza warning
Scaricare e installare InfoCert GoSign se non l’avete già fatto
Aprire Firefox, andare su impostazioni, Privacy & Sicurezza, scorrere fino alla sezione Certificati e cliccare “Dispositivi di Sicurezza“
Cliccare su Carica
Inserire come Nome Modulo quello che volete, ad esempio Bit4id e come file /usr/lib/gosigndesktop/resources/app/node_modules/@ice/dike-core-js/node_modules/@ice/dike-core-linux/native/lib/libbit4xpki.so e date OK a tutto
Fine
Autenticazione CNS con Chrome o Chromium
Installare i tool necessari per gestire l’NSS Shared DB
L’utilizzo dei servizi Dynamic DNS (DDNS) integrati nelle appliance, ovvero quelli messi a disposizione direttamente dai produttori come Fortinet o QNAP, comporta un impatto sulla sicurezza in quanto il loro utilizzo si ripercuote su una maggiore superficie di attacco identificabile da un attaccante.
Attraverso questa breve analisi, si intende dimostrare come l’implementazione di tale servizio su una rete influisca sulla sua sicurezza creando un’opportunità per un attaccante di sfruttare eventuali vulnerabilità.
Introduzione a TLS e Certificate Transparency Log
La sicurezza delle comunicazioni su Internet è essenziale per garantire la confidenzialità e l’integrità delle informazioni scambiate tra utenti e siti web. Uno strumento fondamentale per implementare questa sicurezza è rappresentato dai certificati X.509 e dal protocollo TLS, tecnologie che consentono di stabilire connessioni crittografate e autenticate.
Il Certificate Transparency (CT) è un meccanismo progettato per migliorare la sicurezza e la trasparenza nell’emissione dei certificati SSL, consentendo a terze parti di monitorare e verificare il processo di certificazione.
Il Certificate Transparency Log è un registro pubblico e immutabile di tutti i certificati emessi da una Certification Authority (CA). Questo registro fornisce un meccanismo trasparente per monitorare e verificare l’emissione dei certificati, consentendo di individuare e mitigare potenziali minacce alla sicurezza, come l’emissione di certificati fraudolenti.
Il funzionamento del Certificate Transparency Log può essere riassunto nei seguenti passaggi:
Richiesta di Certificato SSL: Un sito web richiede un certificato SSL a una Certification Authority (CA).
Emissione del Certificato SSL: La CA emette un certificato SSL.
Registrazione nel Certificate Transparency Log: Il certificato emesso viene registrato nel Certificate Transparency Log insieme ad altre informazioni pertinenti, come il nome del dominio, la data e l’ora di emissione e altri dettagli.
Nonostante il Certificate Transparency Log sia stato progettato per migliorare la sicurezza e la trasparenza, la sua stessa natura pubblica può comportare rischi di Information Disclosure.
Dynamic Domain Name System (Dynamic DNS o DDNS) è una tecnologia che consente agli utenti di associare un Fully Qualified Domain Name (FQDN) a un indirizzo IP che può cambiare nel tempo. Il processo coinvolge due elementi principali: un client DDNS installato sul dispositivo che si desidera rendere accessibile e un server DDNS gestito da un provider di servizi.
Sebbene questo tipo di tecnologia non sia consigliata per l’uso in ambienti SMB (Small and Medium Business) o Enterprise, è molto popolare in ambienti SOHO (Small Office/Home Office). Infatti, un numero crescente di fornitori sta integrando questo servizio nelle proprie appliance.
Mass-Exploitation
L’ultilizzo combinato delle due tecnologie, ovvero richiedere un certificato SSL per un FQDN associato a un dominio DDNS di un determinato vendor, può creare un problema relativo allo sfruttamento massivo di vulnerabilità.
Si pensi ad esempio a un produttore di firewall “ACME Inc.” che offra il suo servizio DDNS sul dominio “acme-firewall.com”. In caso di vulnerabilità su questo firewall, un attaccante può sfruttare il log della Certificate Transparency per individuare target vulnerabili semplicemente cercando tutti i sotto-domini di “acme-firewall.com” e compromettere massivamente migliaia di dispositivi esposti.
Fortinet
FortiNet nei prodotti firewall FortiGate, ha introdotto il servizio “FortiGuard DDNS” che, oltre ad agevolare il setup di sistemi VPN in assenza di IP statico, di fatto incoraggia l’esposizione ad internet dell’interfaccia amministrativa dell’appliance.
Il servizio FortiGuard DDNS utilizza tre domini di proprietà di FortiNet: fortiddns.com, fortidyndns.com, float-zone.com, e integra un client ACME per la generazione automatica dei certificati SSL tramite Let’s Encrypt.
Interrogando un servizio di Certificate Transparency Log per il dominio fortiddns.com un attaccante può venire a conoscenza di oltre 2300 potenziali target a cui è stato rilasciato di recente un certificato per fortiddns.com (risultati filtrati per certificati non ancora scaduti). Il servizio usato per questo esempio ha troncato i risultati per la presenza di troppe entry corrispondenti alla query di ricerca, questo significa che in realtà i potenziali target sono molti di più.
Su Shodan invece sono indicizzati ben 7968 target per lo stesso dominio. La quasi totalità degli host è stata indicizzata tramite il campo “Common Name” del certificato SSL.
QNAP
QNAP dispone del servizio “myQNAPcloud” per semplificare l’accesso remoto ai propri prodotti NAS. Anche in questo caso, il produttore incoraggia di fatto l’esposizione ad internet dell’appliance tramite tale servizio che utilizza il DDNS proprietario myqnapcloud.com.
Il servizio di Certificate Transparency Log interrogato restituisce oltre 4400 potenziali target, anche in questo caso i risultati di ricerca sono troncati.
Shodan restituisce 39027 target, anche in questo caso indicizzati tramite il campo “Common Name” del certificato SSL.
Mikrotik
Anche Mikrotik, produttore di router e switch, dispone di un servizio DDNS sul dominio sn.mynetname.net e integra un client ACME sulle loro appliance. Il sotto-dominio generato dal servizio è composto dal numero seriale dell’appliance (che corrisponde al MAC address della prima interfaccia di rete), esempio: serialnumber.sn.mynetname.net.
L’FQDN generato dal servizio è composto dal numero seriale dell’appliance (che corrisponde al MAC address della prima interfaccia di rete), esempio: serialnumber.sn.mynetname.net.
Il servizio di Certificate Transparency Log interrogato restituisce oltre 1300 potenziali target, anche in questo caso i risultati di ricerca sono troncati.
Shodan invece restituisce 3885 target indicizzati per Common Name.
Conclusioni
Anche se l’utilizzo di DDNS non implica automaticamente l’esposizione ad internet di interfacce amministrative e servizi, di fatto ne incoraggia la pratica. Ad ogni modo, quando utilizzato in concomitanza con un client ACME che genera automaticamente un certificato X.509 sul dominio DDNS, si viene a creare automaticamente un problema di Information Disclosure.
Pertanto, è fondamentale che i produttori comunichino chiaramente agli utenti questi potenziali rischi per la sicurezza, sottolineando l’importanza di una configurazione prudente.
Metasploit’s post gather modules are useful to gathering additional information from a host after a Metasploit session has opened.
This module is a Post-Exploitation Windows Gather to perform credentials extraction against the Mikrotik Winbox when the “Keep Password” option is selected in Winbox.
CJMCU-232H is a very popular module based on the FT232H that can be used as JTAG, SWD, ICSP/ISP interface to flash most of microcontrollers (for example ESP32, STM32 and AVR).
AVRDUDE stands for “AVR Downloader Uploader” and is a software tool for downloading and uploading the on-chip memories of Microchip’s AVR microcontrollers (like ATMega).
The CJMCU-232H presents itself to the OS as “idVendor=0403, idProduct=6014”, so we can use the default “UM232H” programmer type of AVRDUDE like:
avrdude -c UM232H -p m328pb -v
UM232H programmer should already be defined in the “/etc/avrdude.conf” so we don’t need to modify/patch any files.
For completeness I report the configuration:
programmer
id = "UM232H";
desc = "FT232H based module from FTDI and Glyn.com.au";
type = "avrftdi";
usbvid = 0x0403;
usbpid = 0x6014;
usbdev = "A";
usbvendor = "";
usbproduct = "";
usbsn = "";
sck = 0;
mosi = 1;
miso = 2;
reset = 3;
;
