Dalla guerra dei chip al Mar Nero: perché la geopolitica sta riscrivendo le regole del cyber

Negli ultimi due anni il cyber ha smesso di essere una dimensione “tecnica” del conflitto ed è diventato infrastruttura strategica. La conseguenza è un effetto domino: parte dalla competizione USA-Cina sui semiconduttori e sull’AI, attraversa la guerra Russia-Ucraina (e i corridoi energetici del Mar Nero), e arriva alla governance europea, che prova a mettere ordine con regolazione e compliance mentre la minaccia accelera.


Questo articolo propone una lettura OSINT orientata ai meccanismi (non alle narrazioni), con indicatori pratici utili per chi lavora in cybersecurity, risk e intelligence economica.

USA–Cina: la supply chain dei chip AI come terreno di scontro

La competizione USA-Cina è sempre meno una gara commerciale e sempre più una partita sui colli di bottiglia: chip avanzati, tool di fabbricazione, cloud/AI e controlli export. Il fattore destabilizzante non è solo il “divieto”, ma la volatilità della policy: licenze, eccezioni, enforcement e ritorsioni diventano variabili operative per intere filiere.

Implicazione cyber: quando l’hardware diventa geopolitica, la sicurezza di filiera (provenance, audit, SBOM, trusted suppliers) non è più una best practice. È una condizione di accesso al mercato e una leva di resilienza nazionale.

Europa: governance e compliance mentre la minaccia corre

In Europa la risposta strutturale è regolatoria: NIS2 (governance e obblighi per settori/entità) e Cyber Resilience Act (sicurezza dei prodotti digitali “by design”). Il tema, però, è il tempo: recepimenti e implementazioni disomogenei producono una postura a macchia di leopardo, con differenze di obblighi, reporting ed enforcement tra Paesi.

Implicazione cyber: l’UE sta costruendo un perimetro serio, ma nel breve periodo molte organizzazioni devono alzare maturità e resilienza senza poter contare su un quadro uniforme in tutti i mercati in cui operano.

Mar Nero: energia, logistica e guerra ibrida

Il Mar Nero è un punto di contatto tra interessi militari, energetici e logistici. È anche l’area in cui cyber e ibrido si intrecciano: porti, raffinerie, shipping, assicurazioni, tracciamento, droni e sabotaggi.

In un contesto sanzionatorio, la pressione su rotte e snodi diventa leva economica e leva politica.
Implicazione cyber: la parola chiave è infrastruttura. Anche senza “hacking spettacolare”, basta rendere più costosi e rischiosi trasporto, assicurazione, manutenzione e compliance per ottenere effetti strategici.

Israele: stress operativo, ma il cyber resta un asset strategico

Il sistema israeliano è sotto stress per la situazione regionale, ma il comparto cyber continua a rappresentare un asset di capacità e di mercato: talenti, prodotti e M&A restano un magnete globale.

Questo produce, da un lato, accelerazione tecnologica; dall’altro, maggiore attenzione a export compliance, supply chain e rischio di escalation informativa.

Indicatori pratici (OSINT) per chi lavora in sicurezza

Se la dinamica geopolitica deve diventare una checklist operativa, alcuni indicatori ricorrenti sono:
Volatilità normativa su export controls e controlli tecnologici (licenze, eccezioni, enforcement).
Concentrazione dei colli di bottiglia (pochi fornitori per chip, tool, cloud, componenti critici).
Disruption fisica su nodi logistici ed energetici (porti, raffinerie, shipping) come segnali di guerra ibrida.

Frammentazione regolatoria nell’UE (divergenze di posture minime e responsabilità tra Stati).
Consolidamento del mercato su identity e cloud security come segnale di spostamento della superficie d’attacco.

Conclusione

La tesi è semplice: cyber e geopolitica condividono ormai la stessa supply chain. Gli Stati gestiscono tecnologia e infrastrutture come leve strategiche; le imprese devono trattare la cybersecurity come risk management geopolitico, non come sola IT security.

Per le organizzazioni, il vantaggio competitivo nei prossimi anni passerà dalla capacità di leggere policy, filiere e logistica con lo stesso rigore con cui si legge un threat report.

Questo articolo adotta un approccio OSINT e si basa su fonti pubbliche (atti e comunicazioni istituzionali UE, copertura stampa economico-finanziaria internazionale e report di settore su cyber/tech).

L'articolo Dalla guerra dei chip al Mar Nero: perché la geopolitica sta riscrivendo le regole del cyber proviene da Red Hot Cyber.

Vulnerabilità in .NET: eseguire codice remoto tramite messaggi SOAP

I ricercatori di sicurezza hanno scoperto una vulnerabilità in .NET che potrebbe colpire diversi prodotti aziendali e causare l’esecuzione di codice remoto. Il problema deriva dal modo in cui le applicazioni Microsoft basate su .NET gestiscono i messaggi SOAP e Microsoft, secondo i ricercatori, si rifiuta di risolvere il problema, scaricando la colpa su sviluppatori e utenti.

Piotr Bazydło di watchTowr ha segnalato la scoperta alla conferenza Black Hat Europe . Ha affermato che diverse soluzioni commerciali e interne sono vulnerabili agli attacchi di esecuzione di codice remoto ( RCE ) a causa di errori nella gestione dei messaggi SOAP nelle applicazioni .NET.

Il problema chiave era la classe SoapHttpClientProtocol. Il ricercatore ha spiegato che può essere utilizzata dagli aggressori in vari modi, a seconda dei loro obiettivi. Questa classe eredita da HttpWebClientProtocol, come altri client proxy, ma SoapHttpClientProtocol è la più comune nel codice sorgente, quindi watchTowr si è concentrato su di essa.

Sulla carta, tutto sembra innocuo: sia il nome della classe che la documentazione ufficiale indicano che dovrebbe gestire messaggi SOAP tramite HTTP. Uno scenario “semplice, prevedibile e sicuro” , come osserva ironicamente Bazydło. In pratica, le cose sono più complicate.

La classe è responsabile dell’impostazione dell’URL di destinazione del servizio SOAP e dell’invocazione del metodo SOAP. La vulnerabilità si verifica quando un aggressore riesce a influenzare questo URL e il modo in cui SoapHttpClientProtocol crea il client. Sebbene sia progettata per funzionare con richieste HTTP, utilizza internamente un meccanismo generalizzato che supporta più protocolli: HTTP/HTTPS, FTP e persino FILE.

Se un aggressore sostituisce l’indirizzo web con un URL del file system, la classe non genererà un errore, ma scriverà semplicemente la richiesta SOAP (inviata tramite il metodo POST) direttamente nel file. “Perché un proxy SOAP dovrebbe ‘inviare’ richieste a un file locale? Nessuna persona sana di mente si aspetterebbe di ricevere una risposta SOAP valida dal file system“, osserva il ricercatore.

Questo comportamento può essere sfruttato per scrivere file arbitrari, inclusi dati XML da una richiesta SOAP. Uno scenario meno distruttivo, ma comunque spiacevole, potrebbe riguardare attacchi di relay NTLM.

Bazydło ha inizialmente segnalato il problema a Microsoft tramite la Zero Day Initiative (ZDI). Secondo lui, l’azienda ha risposto che non avrebbe risolto il bug perché gli sviluppatori non dovrebbero consentire l’utilizzo di dati di input non attendibili.

“Come prevedibile, Microsoft ha considerato questa una ‘funzionalità’ piuttosto che una vulnerabilità “, scrive. “La risposta ha attribuito la colpa agli sviluppatori e agli utenti. Secondo Microsoft, l’URL passato a SoapHttpClientProtocol non dovrebbe mai essere controllato dall’utente e la convalida dell’input è interamente responsabilità dello sviluppatore.”

Bazydło aggiunge sarcasticamente che, ovviamente, “tutti gli sviluppatori decompilano regolarmente gli assembly .NET Framework e studiano l’implementazione interna, ben sapendo che un ‘proxy client HTTP’ può essere convinto a scrivere dati su disco. Come potrebbe essere altrimenti? “

Un anno dopo, il team di watchTowr ha iniziato ad analizzare Barracuda Service Center , una “piattaforma RMM ampiamente utilizzata”, anch’essa risultata vulnerabile alla tecnica descritta in precedenza. I ricercatori hanno scoperto che la sua API SOAP poteva essere chiamata senza autenticazione e hanno quindi trovato una via di exploit alternativa: importando file WSDL (Web Services Description Language).

Il punto chiave è che un aggressore può fornire a un’applicazione un URL che punta a un file WSDL sotto il suo controllo. L’applicazione vulnerabile utilizza questa descrizione per generare un proxy client HTTP, dopodiché Bazydło è riuscito a ottenere l’esecuzione di codice remoto in due modi: caricando una web shell ASPX sul server e inserendo il payload (una web shell CSHTML o uno script PowerShell) nello spazio dei nomi del corpo della richiesta SOAP.

Questa tecnica basata sullo spazio dei nomi, afferma, ha consentito lo sfruttamento efficace di Ivanti Endpoint Manager e Umbraco 8 CMS. Sebbene il rapporto di WatchTowr menzioni specificamente questi prodotti, i ricercatori sottolineano che l’elenco effettivo delle soluzioni interessate è molto più ampio.

L'articolo Vulnerabilità in .NET: eseguire codice remoto tramite messaggi SOAP proviene da Red Hot Cyber.

Sinceramente, credo che…
la magia arrivi proprio quando smetti di inseguirla, ho smesso anche di cercarla.

A volte la vita si fa creativa e ti manda regali inaspettati, senza fiocchi, senza bigliettini, senza istruzioni, forse anche senza merito!
La verità è che la magia, soprattutto di questo periodo, e parlo per me, non si è persa,
stava solo aspettando che io smettessi di cercarla nei posti sbagliati e nelle persone sbagliate, come sempre!
Sapeva che l’avrei trovata proprio quando avrei smesso di crederci, insieme alla sua fedele compagna e cioè la speranza, colei che compare in giornate stanche, in angoli dell’anima dove credevi non ci fosse più spazio, arriva all'improvviso e aspetta e resta!
E così proprio come dopo una tempesta, il cielo torna a colorarsi di azzurro, rosa...succede che torna la luce e anche il colore, nella nostra giornata grigia, in punta di piedi, senza clamore e preavviso,
a volte si manifesta con un gesto, uno sguardo, una parola o semplicemente un pensiero, tipico delle persone rare!
Questo perché la vita, anche quando sembra una scatola vuota, incrinata,
ha sempre un dettaglio nascosto nella speranza, con cui basta posto per riaccendersi, per illuminare e colorare, che sia un attimo, una giornata o un tortuoso cammino!
Il mio modo per esprimere
Non gratitudine, ma di più a chi ieri ha illuminato la mia giornata, con un gesto, un pensiero ...regalandomi un po' di magia!

Why Games Work, and How to Build Them

Most humans like games. But what are games, exactly? Not in a philosophical sense, but in the sense of “what exactly are their worky bits, so we know how to make them?” [Raph Koster] aims to answer that in a thoughtful blog post that talks all about game design from the perspective of what, exactly, makes them tick. And we are right into that, because we like to see things pulled apart to learn how they work.

On the one hand, it’s really not that complicated. What’s a game? It’s fun to play, and we generally feel we know a good one when we see it. But as with many apparently simple things, it starts to get tricky to nail down specifics. That’s what [Raph]’s article focuses on; it’s a twelve-step framework for how games work, and why they do (or don’t) succeed at what they set out to do.

[Raph] says the essentials of an engaging game boil down to giving players interesting problems to solve, providing meaningful and timely feedback, and understanding player motivation. The tricky part is that these aren’t really separate elements. Everything ties together in a complex interplay, and [Raph] provides insights into how to design and manage it.

It’s interesting food for thought on a subject that is, at the very least, hacker-adjacent. After all, many engaging convention activities boil down to being games of some kind, and folks wouldn’t be implementing DOOM on something like KiCAD’s PCB editor or creating first-person 3D games for the Commodore PET without being in possession of a healthy sense of playfulness.

hackaday.com/2025/12/13/why-ga…