La scorsa settimana è stato scoperto che un’autorità di certificazione poco conosciuta, chiamata Fina, ha emesso 12 certificati TLS non autorizzati per 1.1.1.1 (un popolare servizio DNS di Cloudflare) tra febbraio 2024 e agosto 2025, senza l’autorizzazione dell’azienda. I certificati potrebbero essere stati utilizzati per decrittografare query crittografate tramite DNS su HTTPS e DNS su TLS.

La diffusione di certificati sospetti è diventata nota quasi per caso: un ricercatore è stato il primo a segnalarlo nella mailing list dev-security-policy di Mozilla. I certificati sono stati emessi da Fina RDC 2020, una CA che fa capo a Fina Root CA. È diventato subito chiaro che Microsoft si fidava dei certificati Fina Root CA, il che significava che anche Windows e Microsoft Edge si fidavano di loro.

I rappresentanti di Cloudflare hanno subito attirato l’attenzione sulla situazione e confermato che i certificati erano stati emessi illegalmente.

“Cloudflare non ha autorizzato Fina a emettere questi certificati. Dopo aver visto il rapporto nella mailing list sulla trasparenza dei certificati, abbiamo immediatamente avviato un’indagine e contattato Fina, Microsoft e l’organismo di vigilanza TSP di Fina, che potrebbero essere in grado di risolvere il problema revocando la fiducia in Fina o i certificati emessi erroneamente”, ha affermato Cloudflare.

Nella dichiarazione dell’azienda si sottolinea inoltre che il problema non riguarda i dati crittografati tramite WARP VPN. A loro volta, i rappresentanti di Microsoft hanno riferito di aver contattato il centro di certificazione e di aver chiesto un intervento immediato. L’azienda ha assicurato di aver già adottato misure per bloccare questi certificati.

I rappresentanti di Google, Mozilla e Apple hanno affermato che i loro browser non si sono mai fidati dei certificati Fina e che gli utenti non devono intraprendere alcuna azione. Il problema è che i certificati sono una parte fondamentale del protocollo TLS (Transport Layer Security). Contengono una chiave pubblica e informazioni sul dominio per il quale vengono emessi, mentre l’autorità di certificazione (l’organizzazione autorizzata a emettere certificati attendibili) detiene la chiave privata che verifica la validità del certificato.

La CA utilizza la propria chiave privata per firmare i certificati e i browser li verificano utilizzando chiavi pubbliche attendibili. In pratica, questo significa che chiunque possieda un certificato e la relativa chiave privata può impersonare crittograficamente il dominio per il quale è stato emesso.

Pertanto, il proprietario dei certificati di 1.1.1.1 potrebbe potenzialmente utilizzarli in attacchi man-in-the-middle, intercettando le comunicazioni tra gli utenti e il servizio DNS di Cloudflare. Di conseguenza, le terze parti in possesso di certificati 1.1.1.1 potrebbero decrittografare, visualizzare e modificare il traffico DNS di Cloudflare.

“L’ecosistema delle CA è un castello con molte porte: il fallimento di una CA può compromettere l’intero castello. Il comportamento scorretto delle CA, intenzionale o meno, rappresenta una minaccia significativa e continua per Cloudflare. Cloudflare ha contribuito a sviluppare e lanciare Certificate Transparency fin dall’inizio , il che ha portato alla scoperta di questo caso di emissione impropria di certificati”, ha affermato Cloudflare.

Verso la fine della scorsa settimana, Cloudflare ha pubblicato un rapporto dettagliato sull’incidente. Un audit condotto dall’azienda ha mostrato che il numero di certificati emessi impropriamente era 12, non i tre inizialmente segnalati. Peggio ancora, i primi erano stati emessi già a febbraio 2024.

I rappresentanti di Fina hanno commentato l’incidente in una breve e-mail, affermando che i certificati erano stati “emessi per test interni del processo di emissione dei certificati in un ambiente di produzione”.

L’autorità di certificazione ha dichiarato che si è verificato un errore durante l’emissione dei certificati di prova “a causa dell’inserimento errato degli indirizzi IP”. È stato sottolineato che, come parte della procedura standard, i certificati sono stati pubblicati nei registri di Certificate Transparency.

Fina ha assicurato che le chiavi private non hanno lasciato l’ambiente controllato dalla CA e sono state “distrutte immediatamente, prima che i certificati venissero revocati”. L‘azienda afferma che i certificati emessi in modo improprio “non hanno in alcun modo compromesso la sicurezza degli utenti o di altri sistemi”.

Tuttavia, Cloudflare ha affermato di prendere l’incidente molto seriamente, sottolineando che deve “presupporre che la chiave privata in questione esista e non sia sotto il controllo di Cloudflare”, poiché non c’è modo di verificare le affermazioni di Fina.

L’azienda riconosce che i rischi a cui sono stati esposti milioni di utenti Windows che si affidavano alla versione 1.1.1.1 sono in parte dovuti a Cloudflare. Cloudflare non ha implementato un controllo regolare dei log di Certificate Transparency che indicizzano l’emissione di ciascun certificato TLS e ha scoperto il problema troppo tardi.

“Abbiamo fallito tre volte. La prima volta, perché 1.1.1.1 è un certificato IP, ma il nostro sistema non ci ha avvisato di questi casi. La seconda volta, perché, anche se siamo stati avvisati delle emissioni di certificati come tutti i nostri clienti, non abbiamo implementato un filtraggio adeguato. Dato l’enorme numero di nomi e di emissioni che gestiamo, i controlli manuali non sono sufficienti. Infine, a causa di un monitoraggio troppo “rumoroso”, non abbiamo abilitato gli avvisi per tutti i nostri domini. Stiamo lavorando per correggere tutte e tre queste carenze”, scrive Cloudflare.

L'articolo Scoperti certificati TLS non autorizzati per 1.1.1.1, il servizio DNS di Cloudflare proviene da il blog della sicurezza informatica.

Cyberstorage: la risposta degli IT manager italiani a ransomware sempre più sofisticati. Negli ultimi anni lo scenario è cambiato: ransomware più aggressivi, esfiltrazione dei dati prima della cifratura, interruzioni dei servizi dovute a eventi fisici e non solo. In questo contesto, “salvare” i dati non basta più: lo storage diventa parte della sicurezza. Proprio per questo motivo, tra gli IT manager italiani cresce l’attenzione verso il cyberstorage: uno storage progettato per resistere agli attacchi direttamente dove risiedono i dati.

Alla base c’è un principio architetturale chiave: la frammentazione e distribuzione nativa del dato su più sedi geografiche. A questo si affiancano funzionalità di sicurezza integrate – come immutabilità, cifratura, controllo accessi – che aumentano la resilienza e supportano una reale continuità operativa anche in scenari critici.

Cos’è (davvero) il cyberstorage

Per semplificare: è storage con sicurezza incorporata. Non un layer applicato sopra, ma controlli nativi a livello dati per resistere a manomissioni, cancellazioni, cifrature e accessi non autorizzati.

Storicamente ci si è affidati a controlli perimetrali (firewall, segmentazione di rete), gestione delle identità, versioning. Strumenti utili, ma non sufficienti quando l’attaccante arriva fino allo storage. Il cyberstorage nasce per colmare questa lacuna: porta lo zero trust fino al livello dei dati, riducendo la probabilità di compromissione totale e facilitando il recovery.

Non è un caso che gli analisti di Gartner indicano il cyberstorage tra i 6 trend strategici IT del 2025: frammentare, distribuire e proteggere i dati su più sedi minimizza il rischio di compromissione e breach dei dati.

Perché oggi il cyberstorage è una priorità per gli IT manager

Le ransomware gang di oggi non si limitano più a cifrare i dati. In molti casi, l’attacco inizia con l’esfiltrazione: i dati vengono copiati e portati fuori dall’organizzazione, poi cifrati per renderli inaccessibili e infine usati come leva per minacciare la pubblicazione.
È la cosiddetta doppia o tripla estorsione, un approccio che rende inutile anche un backup perfettamente funzionante, perché il danno vero non è solo l’interruzione del servizio, ma la perdita di riservatezza.

Questo espone l’azienda a:

• Perdite economiche (fermi operativi, penali, costi di risposta)
• Danni reputazionali, se i dati esfiltrati riguardano clienti, dipendenti o partner

In parallelo aumentano gli attacchi mirati a infrastrutture di virtualizzazione e repository di backup. Sul piano fisico restano i rischi di disastro fisico (incendi, alluvioni) e di interruzioni prolungate (blackout).

Il cyberstorage non è la soluzione magica, ma rappresenta un tassello chiave in un piano di disaster recovery moderno, che punta su integrità e riservatezza del dato anche in condizioni estreme.

Cosa cambia rispetto allo storage tradizione

Lo storage “classico” è nato per capacità, performance e disponibilità. Il cyberstorage aggiunge:

• Un principio architetturale: frammentazione e distribuzione nativa del dato su più sedi/domìni per ridurre il rischio di perdita e compromissione in caso di incidente.
• Controlli di sicurezza (non necessariamente nativi, ma integrati nello stack di storage) che aumentano la resilienza: immutabilità, cifratura, controllo degli accessi e non solo.

Questi elementi operano sul dato stesso, non solo al perimetro della rete.

Normative: cosa cambia con NIS2 e GDPR

Con l’entrata in vigore della direttiva NIS2, le organizzazioni italiane – sia pubbliche che private – devono dimostrare di essere in grado di garantire continuità operativa, sicurezza dei dati e disponibilità dei servizi essenziali anche in caso di attacco. Non è più sufficiente avere un backup: le normative chiedono prove concrete di misure tecniche e organizzative efficaci, come stabilito anche dal GDPR. Una strategia carente espone l’azienda a rischi elevati: interruzioni prolungate, danni economici e sanzioni fino a 10 milioni di euro o al 2% del fatturato globale annuo, a seconda di quale sia il valore più alto.

Da dove iniziare senza rifare tutto

L’obiettivo non è stravolgere lo stack, ma aumentare la resilienza con scelte concrete e misurabili. Ecco i fondamentali:

• Applica la regola del 3-2-1-1-0 backup: tre copie, due supporti diversi, una offsite, una immutabile, zero errori nei test.
• Separazione dei domini: chi amministra la produzione non amministra i backup; privilegi minimi, autenticazione a più fattori (MFA) e controllo a doppio fattore per operazioni critiche.
• Testa il ripristino in modo reale e completo (non solo tabletop): misura RPO/RTO, documenta, correggi.
• Standard diffusi (es. compatibilità S3/Object Lock) per integrare i tool esistenti e mantenere portabilità. Evitando il lock-in tecnologico.

Domande guida per orientare le priorità:

• Quanto tempo il mio business può rimanere offline senza danni gravi?
• Quali dati devo ripristinare per primi?
• Chi prende decisioni, e con quali strumenti?
• Dove sono conservate le copie dei dati, e sono al sicuro?
• I dati salvati sono anche protetti da accessi non autorizzati?

La capacità di ripristinare è fondamentale, ma lo è anche la prevenzione della perdita/esfiltrazione prima della cifratura. Un piano moderno di disaster recovery deve includere storage resistenti agli attacchi, controlli di accesso rigorosi, segregazione dei ruoli e sistemi progettati per la sicurezza by design.

Fattori da considerare nella scelta di una soluzione storage resiliente

Quando valuti una soluzione di cyberstorage, non basta guardare al costo e alla performance: la resilienza nasce da scelte architetturali e funzionalità di sicurezza. Di seguito, i criteri tecnici più rilevanti da tenere presenti.

• Dato frammentato e distribuito by design su più ambienti o sedi fisiche: questo minimizza il rischio di compromissione in caso di incidente.
• Cifratura forte dei dati (es. AES-256), con gestione sicura delle chiavi (tramite sistemi dedicati come KMS), eventualmente controllate direttamente dal cliente.
• Immutabilità dei dati (ad es. tramite modalità WORM o Object Lock) e creazione di copie automatiche (snapshot) per garantire la disponibilità anche in caso di ransomware.
• Zero trust al livello dati: Accesso secondo il principio del privilegio minimo, con sistemi di gestione delle identità (IAM), autenticazione a più fattori (MFA) e controllo a doppio fattore per operazioni critiche.
• Tracciabilità e integrità dei dati: registrazione dettagliata e non alterabile degli accessi e delle modifiche ai file, utile per audit e indagini forensi; verifica automatica dell’integrità per garantire che i dati non siano stati compromessi o alterati nel tempo.

Cubbit: la risposta italiana al bisogno di cyberstorage resiliente

In un contesto in cui i cyberattacchi sono sempre più sofisticati, Cubbit offre una risposta concreta. A differenza del cloud tradizionale, Cubbit cifra, frammenta e replica i dati su più sedi geografiche – al sicuro da ransomware e disastri. Parliamo di un cloud storage 100% italiano, scelto da Leonardo, Rai Way e più di 400 aziende italiane ed europee.

Oltre all’immutabilità e alla geo-ridondanza nativa, Cubbit si distingue per un approccio trasparente: niente costi nascosti, risparmi fino all’80% rispetto agli hyperscaler, localizzazione dei dati in Italia e conformità con normative come GDPR, ACN e NIS2.

Compatibile con lo standard S3, si integra facilmente con Veeam e altri client già in uso. L’architettura scalabile consente di passare rapidamente da TB a PB. La tecnologia è disponibile in due modalità, in base alle esigenze operative:

Puoi partire con DS3 Cloud (cloud object storage pronto all’uso) oppure creare il tuo cloud personalizzato con DS3 Composer (soluzione software-defined completamente europea).

Attiva una prova gratuita di Cubbit o contatta direttamente il team sul sito ufficiale.

L'articolo Cyberstorage: La Risposta degli IT Manager Italiani ai Ransomware proviene da il blog della sicurezza informatica.

Nel Q3 2025 è stato osservato un nuovo gruppo ransomware, identificato come The Gentlemen, che ha lanciato un proprio Data Leak Site (DLS) nella rete Tor.

L’infrastruttura e le modalità operative del gruppo indicano un livello di organizzazione medio-alto, con particolare attenzione alla gestione dell’immagine e alla sicurezza operativa. Il DLS di The Gentlemen è accessibile tramite un indirizzo .onion e si presenta come segue:

• Homepage minimalista con logo, motto e branding coerente.
• TOX ID pubblico per comunicazioni cifrate P2P, probabilmente utilizzato per le negoziazioni.
• QR code ridondante per facilitare l’accesso ai contatti.
• Sezione dedicata alle vittime, organizzata in schede con descrizioni e riferimenti a dati esfiltrati.

L’assenza di funzionalità superflue e la scelta di protocolli decentralizzati riducono la superficie d’attacco contro la loro infrastruttura.

Victimology

Le vittime osservate appartengono a settori ad alto valore strategico:

• Manifatturiero/Automotive (EU)
• Servizi tecnologici/IT consulting (Asia)
• Energia e Telecomunicazioni (global)

L’approccio suggerisce una strategia mirata verso entità con bassa tolleranza alla disruption e forte esposizione reputazionale.

Distinguishing Factors

• Branding marcato: stile grafico coerente e naming che punta a differenziarsi da gruppi caotici.
• OpSec rafforzata: uso di TOX invece di portali centralizzati.
• DLS modulare: struttura scalabile, pronta a ospitare un numero crescente di vittime.

Considerazioni finali

Il debutto di The Gentlemen conferma che il panorama ransomware è in continua evoluzione. L’attenzione ai dettagli, la costruzione di un DLS pulito e funzionale, e la scelta di obiettivi nei settori industriali più redditizi lasciano intuire che questo gruppo non sia un’iniziativa improvvisata, ma il risultato di un’organizzazione con risorse e competenze consolidate.

Per le aziende, la lezione è chiara: rafforzare le difese di rete e i processi di incident response è ormai imprescindibile, soprattutto in quei comparti che rappresentano un target primario per attori malevoli di nuova generazione.

L'articolo The Gentlemen ransomware: analisi di una minaccia emergente nel dark web proviene da il blog della sicurezza informatica.

Recently, [Solder Hub] put together a brief video that demonstrates the basics of a Hall Effect sensor — in this case, one salvaged from an old CPU fan. Two LEDs, a 100 ohm resistor, and a 3.7 volt battery are soldered onto a four pin Hall effect sensor which can toggle one of two lights in response to the polarity of a nearby magnet.

If you’re interested in the physics, the once sentence version goes something like this: the Hall Effect is the production of a potential difference, across an electrical conductor, that is transverse to an electric current in the conductor and to an applied magnetic field perpendicular to the current. Get your head around that!

Of course we’ve covered the Hall effect here on Hackaday before, indeed, our search returned more than 1,000 results! You can stick your toe in with posts such as A Simple 6DOF Hall Effect ‘Space’ Mouse and Tracing In 2D And 3D With Hall Effect Sensors.

youtube.com/embed/YTwcnHwplQw?…

hackaday.com/2025/09/09/the-ma…

Most people’s memories of programming in the 8-bit era revolve around BASIC, and not without reason. Most of the time, it was all we had. On the other hand, there were other options if you sought them out, and [Paul Lefebvre] makes the case that Goto10Retro that Action! was the best of them.

The limits of BASIC as an interpreted language are well-enough known that we needn’t go over them here. C and Pascal were available for some home computers in the 1980s, and programs written in those languages ran well, but compiling them? That was by no means guaranteed.
The text editor. Unusual for Atari at the time, it allowed scrolling along a line of greater than 40 char.
For those who lived on the Atari side of the fence, the Action! language provided a powerful alternative. Released by Optimized Systems Software in 1983, Action! was heavily optimized for the 6502, to the point that compiling and running simple programs with “C” and “R” felt “hardly slower” than typing RUN in BASIC. That’s what [Paul] writes, anyway, but it’s a claim that almost has to be seen to be believed.

You didn’t just get a compiler for your money when you bought Action!, though. The cartridge came with a capable text editor, simple shell, and even a primitive debugger. (Plus, of course, a hefty manual.) It’s the closest thing you’d find to an IDE on a computer of that class in that era, and it all fit on a 16 kB cartridge. There was apparently also a disk release, since the disk image is available online.

Unfortunately for those of us in Camp Commodore, the planned C-64 port never materialized, so we missed out on this language. Luckily our 64-bit supercomputers can easily emulate Atari 8-bit hardware and we can see what all the fuss was about. Heck, even our microcontrollers can do it.

hackaday.com/2025/09/09/was-ac…