Spcnet.it

2026-06-17 20:26:13

DirectAccess è deprecato: come migrare ad Always On VPN su Windows Server

Microsoft ha ufficialmente deprecato DirectAccess e ne prevede la rimozione in una futura versione di Windows Server. Il successore designato è Always On VPN, introdotto con Windows Server 2016 e Windows 10. In questo articolo analizziamo cosa significa concretamente la deprecazione, perché Microsoft sta operando questa transizione, le differenze tecniche tra le due soluzioni e come pianificare la migrazione.

Cos’è DirectAccess e cosa cambia con la deprecazione

DirectAccess è la tecnologia di accesso remoto di Microsoft che consente ai client Windows uniti al dominio di connettersi automaticamente alle risorse aziendali interne senza una VPN tradizionale avviata dall’utente. Crea tunnel IPsec sempre attivi (usando IPv6 e tecnologie di transizione su IPv4) tra il client e il server DirectAccess, rendendo il dispositivo effettivamente “dentro” la rete aziendale ogni volta che ha connettività internet.

Quando Microsoft contrassegna una funzionalità come deprecata, questa rimane funzionale e supportata per il resto del ciclo di vita della versione del prodotto. DirectAccess non smette di funzionare da un giorno all’altro: se si esegue Windows Server 2025 o qualsiasi versione supportata precedente che include DirectAccess, è possibile continuare a utilizzarlo fino al termine del supporto per quella versione. Tuttavia, Microsoft ha confermato che DirectAccess sarà rimosso completamente da una futura release di Windows Server — nessuna data specifica è stata annunciata a giugno 2026.

Perché DirectAccess viene sostituito

DirectAccess è stato progettato per ambienti on-premises tradizionali in cui tutti i dispositivi gestiti sono uniti al dominio. Si basa su Group Policy per la configurazione e sulle tecnologie di transizione IPv6 per trasportare il traffico su reti IPv4. Questi protocolli di transizione — Teredo, 6to4 e IP-HTTPS — creano livelli aggiuntivi di incapsulamento e cifratura che aggiungono complessità, possono ridurre le prestazioni e sono difficili da diagnosticare.

Ogni client DirectAccess deve eseguire l’edizione Windows Enterprise, e sia il server che il client devono essere uniti al dominio. Questo esclude scenari BYOD e dispositivi Entra ID-joined non appartenenti a un dominio Active Directory on-premises. Microsoft ha inoltre smesso di aggiungere nuove funzionalità a DirectAccess dopo Windows Server 2012 R2: nessuna novità da oltre un decennio.

Panoramica di Always On VPN

Always On VPN utilizza il client VPN integrato di Windows e non richiede una funzionalità Windows dedicata lato client. È disponibile su tutte le edizioni di Windows 10 e Windows 11, inclusi i dispositivi non uniti al dominio. Supporta dispositivi domain-joined, Entra ID-joined, hybrid-joined e workgroup, abilitando scenari BYOD.

Sul lato server è possibile utilizzare Windows RRAS (Routing and Remote Access Service) oppure un gateway VPN di terze parti supportato. Always On VPN supporta due protocolli VPN principali:

• IKEv2 (Internet Key Exchange version 2): protocollo primario, usa le porte UDP 500 e 4500, offre sicurezza elevata e buone prestazioni su connessioni instabili.
• SSTP (Secure Socket Tunneling Protocol): usa la porta TCP 443, utile come fallback in ambienti dove i firewall bloccano il traffico UDP.

Nessuno dei due protocolli richiede meccanismi di transizione IPv6, eliminando la dipendenza da NAT64/DNS64 che caratterizzava DirectAccess.

Tunnel utente e tunnel dispositivo

Always On VPN offre due tipi di connessione che possono essere attivi contemporaneamente sullo stesso dispositivo:

• User Tunnel: si connette dopo l’accesso dell’utente. Supporta IKEv2 e SSTP ed è disponibile in tutte le edizioni di Windows 10 e Windows 11.
• Device Tunnel: si connette prima che l’utente acceda, rendendo raggiungibili i domain controller e i servizi di infrastruttura durante l’avvio del sistema. Supporta solo IKEv2 (nessun fallback SSTP). Richiede Windows 10 Enterprise 1709 o successivo e il dispositivo deve essere unito al dominio. La configurazione avviene tramite PowerShell o PsExec sull’account LOCAL SYSTEM.

Autenticazione, sicurezza e integrazione Zero Trust

Always On VPN supporta l’integrazione con Microsoft Entra ID per MFA (autenticazione a più fattori) e Conditional Access — il motore di policy che concede o blocca l’accesso in base a condizioni come lo stato di conformità del dispositivo o il rischio di accesso. Questo si allinea al modello Zero Trust, che richiede la verifica di ogni connessione indipendentemente dalla posizione di rete.

L’autenticazione del client utilizza tipicamente PEAP-TLS (Protected Extensible Authentication Protocol con Transport Layer Security), che racchiude l’autenticazione basata su certificati utente all’interno di un canale cifrato. In alternativa è supportato Windows Hello for Business per l’autenticazione basata su certificati, che fornisce single sign-on al dispositivo e alla VPN senza un prompt password secondario.

Opzioni di gestione

Always On VPN può essere distribuito e gestito tramite Intune, Configuration Manager, PowerShell o qualsiasi strumento MDM che supporti il formato di configurazione standard ProfileXML. Non si è più limitati a Group Policy, l’unico metodo di gestione disponibile per DirectAccess.

Processo di migrazione: approccio a fasi

Microsoft raccomanda una migrazione a fasi. La guida ufficiale suddivide il processo in quattro stadi:

1. Pianificazione: Definire i “migration ring” (gruppi di utenti o dispositivi migrati in batch), confrontare le funzionalità di DirectAccess e Always On VPN, progettare la nuova infrastruttura.
2. Deploy dell’infrastruttura: Avviare il server Always On VPN affiancato all’ambiente DirectAccess esistente. Entrambi possono funzionare simultaneamente, consentendo la migrazione degli utenti senza downtime.
3. Deploy certificati e configurazione client: Emettere i certificati dalla PKI e distribuire il profilo VPN (uno script VPN_Profile.ps1 o un profilo Intune) ai dispositivi client.
4. Decommissioning: Una volta migrati tutti i client, rimuovere la configurazione DirectAccess dai client, rimuovere il ruolo DirectAccess dal server e dismettere il server da Active Directory.

Confronto diretto: DirectAccess vs Always On VPN

Caratteristica          | DirectAccess              | Always On VPN
------------------------|---------------------------|---------------------------
Edizioni Windows client | Solo Enterprise           | Tutte le edizioni
Requisito dominio       | Obbligatorio              | Opzionale (supporta Entra ID)
BYOD                    | Non supportato            | Supportato
Protocollo              | IPsec/IPv6 + transizione  | IKEv2, SSTP
Gestione                | Solo Group Policy         | Intune, GPO, PowerShell, MDM
MFA/Conditional Access  | Limitato                  | Integrazione Entra ID nativa
Supporto Zero Trust     | No                        | Sì


Conclusioni

DirectAccess continuerà a funzionare sulle versioni supportate di Windows Server, ma la sua deprecazione segnala il cambiamento di rotta di Microsoft verso soluzioni di accesso remoto più flessibili e cloud-ready. Always On VPN risolve molte delle limitazioni di DirectAccess supportando la gestione moderna dei dispositivi, metodi di autenticazione diversificati e una gamma più ampia di scenari di distribuzione, inclusi BYOD e dispositivi Entra ID-joined.

Le organizzazioni che attualmente utilizzano DirectAccess dovrebbero iniziare a pianificare la strategia di migrazione per evitare di essere impattate dalla sua eventuale rimozione da Windows Server. Una transizione a fasi consente la coesistenza delle due tecnologie, minimizzando le interruzioni durante la modernizzazione dell’infrastruttura di connettività remota.

Fonte originale: DirectAccess deprecated: migrate to Always On VPN – 4sysops

DirectAccess deprecated: migrate to Always On VPN – 4sysops

Microsoft has deprecated DirectAccess and will remove it from a future release of Windows Server. The replacement is Always On VPN, introduced with Windows Serv

^{IT Experts (4sysops)}

Spcnet.it

2026-06-17 20:26:28

Linux tmpfs: filesystem in memoria per build più veloci e storage temporaneo ad alte prestazioni

Alcune funzionalità di Linux sono nascoste in bella vista. tmpfs è una di queste. La si usa ogni giorno senza pensarci: ogni volta che si usa /dev/shm, si ispeziona /run, o si lavora su un sistema che monta /tmp come storage in memoria, si sta interagendo con tmpfs. In questa guida vediamo cos’è, dove Linux lo usa già, come montare istanze personalizzate, renderle persistenti e quando ha davvero senso sfruttarlo.

Cos’è tmpfs?

tmpfs è un tipo di filesystem che archivia tutto nella memoria virtuale — RAM e, se necessario, spazio di swap. Si comporta come un filesystem normale: è possibile creare file, impostare permessi e nidificare directory. La differenza è che tutto scompare nel momento in cui viene smontato o il sistema viene riavviato.

Non è la stessa cosa di un RAM disk. Un RAM disk tradizionale (come ramfs) alloca un blocco fisso di memoria in anticipo, lo mantiene indipendentemente da quanto si usa effettivamente e non ha un limite di dimensione, quindi un processo impazzito può silenziosamente consumare tutta la RAM disponibile.

tmpfs è dinamico: consuma solo la memoria necessaria per i file attualmente archiviati. Impostare un limite di 512 MB e usarne solo 50 MB significa che vengono consumati solo 50 MB di RAM. Il kernel gestisce tmpfs direttamente: nessun dispositivo a blocchi, nessun passaggio di formattazione, nessun fsck.

Dove Linux usa già tmpfs

Prima di configurare qualcosa, vale la pena vedere quanto il sistema si affidi già a tmpfs. Eseguire:

mount | grep tmpfs

Su un moderno sistema Linux si otterrà un output simile a questo:

tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=1633768k,mode=700)

Ogni punto di mount ha uno scopo specifico:

• /run: dati runtime per il boot corrente — PID file, socket, lock file.
• /dev/shm: memoria condivisa POSIX, usata dalle applicazioni per la comunicazione inter-processo ad alta velocità.
• /run/lock: lock file specifici, montati con noexec per sicurezza.
• /tmp: file temporanei (non tutte le distro lo montano come tmpfs di default).
• /run/user/1000: directory runtime per-utente gestita da systemd-logind.

Per vedere dimensioni e utilizzo attuale:

df -h -t tmpfs

La dimensione predefinita per /run e /dev/shm è tipicamente metà della RAM totale — il default del kernel, modificabile.

Montare un filesystem tmpfs manualmente

Creare un mount tmpfs è immediato:

sudo mkdir -p /mnt/ramdisk
sudo mount -t tmpfs -o size=256m tmpfs /mnt/ramdisk

Verifica:

df -h /mnt/ramdisk
# Filesystem  Size  Used Avail Use% Mounted on
# tmpfs       256M     0  256M   0% /mnt/ramdisk

Per smontare (e cancellare tutto il contenuto):

sudo umount /mnt/ramdisk

Opzioni di mount

Il flag -o accetta diverse opzioni utili (combinabili con virgole):

size=      # Dimensione massima: k, m, g o percentuale RAM (es. size=25%)
nr_inodes= # Limite numero di inode (file/directory)
mode=      # Permessi sulla root del filesystem (default 1777)
uid= / gid=# Owner della directory root
noexec     # Impedisce l'esecuzione di binari
nosuid     # Ignora i bit setuid sui binari
nodev      # Non consente device file

Un mount scratch sicuro e generico:

sudo mount -t tmpfs -o size=512m,nosuid,nodev,noexec,mode=1777 tmpfs /mnt/scratch

Rendere i mount tmpfs persistenti con /etc/fstab

I mount manuali scompaiono dopo un riavvio. Per renderli persistenti, aggiungere una riga a /etc/fstab:

tmpfs /mnt/ramdisk tmpfs defaults,size=256m,nosuid,nodev,noexec,mode=1777 0 0

I campi sono: filesystem, mount point, tipo, opzioni, dump, pass. Sia dump che pass devono essere 0 per tmpfs — non c’è nulla da eseguire come backup né da fsck.

Per applicare la nuova voce senza riavviare:

sudo mount /mnt/ramdisk
# oppure per ricaricare tutte le voci fstab:
sudo mount -a

Ridimensionare un mount tmpfs a caldo

È possibile ridimensionare un tmpfs live senza smontarlo — utile quando si sottostima lo spazio necessario per una build:

sudo mount -o remount,size=1g /mnt/ramdisk

Il contenuto viene preservato e il ridimensionamento ha effetto immediato.

Casi d’uso pratici

Accelerare le build software

L’output del compilatore, i file oggetto e gli artefatti intermedi vengono scritti e cancellati costantemente durante una build. Su disco questo genera molto seek time (su HDD) o write amplification inutile (su SSD). Su tmpfs sono solo operazioni RAM.

Per un progetto C/C++ o Rust, è possibile reindirizzare la directory di build su tmpfs:

sudo mount -t tmpfs -o size=4g tmpfs /mnt/build
export CARGO_TARGET_DIR=/mnt/build   # per Rust
# oppure per CMake:
cmake -B /mnt/build -S /path/al/progetto

Ridurre le scritture su SSD e schede SD

Le schede SD e i drive eMMC hanno cicli di scrittura limitati. Montare /tmp come tmpfs riduce significativamente l’usura. Su Raspberry Pi e sistemi embedded questo può prolungare sensibilmente la vita del supporto.

Su systemd, abilitare il mount di /tmp come tmpfs:

systemctl enable --now tmp.mount

Scratch space rapido per script e processing dati

Quando uno script elabora file di grandi dimensioni (log, dump CSV, file di testo), usare tmpfs come directory di lavoro elimina la latenza I/O. I file scompaiono automaticamente al riavvio senza necessità di pulizia manuale.

Monitorare l’utilizzo di tmpfs

# Panoramica con df
df -h -t tmpfs

# Per dettagli su un mount specifico
stat -f /mnt/ramdisk

# Monitoraggio in tempo reale con watch
watch -n 2 "df -h -t tmpfs"

Limitazioni e avvertenze

• I dati non sono persistenti: tutto ciò che non viene copiato altrove va perso al riavvio o all’unmount.
• Consuma RAM: un tmpfs pieno mette pressione sulla memoria di sistema e può innescare l’uso dello swap.
• Il limite di dimensione non riserva memoria: è un tetto massimo, non un’allocazione anticipata. Impostare size=8g su un sistema con 4 GB di RAM non fallisce immediatamente — fallisce quando si tenta di usare più memoria di quella disponibile.
• Non sostituisce uno storage affidabile: per qualsiasi dato che deve sopravvivere a un riavvio, tmpfs non è lo strumento giusto.

Conclusioni

tmpfs è uno degli strumenti più sottovalutati nell’arsenale del sistemista Linux. Richiede due minuti di configurazione e i benefici sono immediati: build più veloci, meno scritture su disco, scratch space che si pulisce da solo al riavvio. Il punto chiave da ricordare è la natura volatile: tutto ciò che viene salvato in tmpfs deve essere copiato su storage permanente prima dello spegnimento, se ha valore.

Per ambienti di build, sistemi embedded, pipeline di processing dati o semplicemente per ridurre l’usura su SSD, tmpfs è la risposta giusta.

Fonte originale: Linux tmpfs for Speed and Temporary Storage – LinuxBlog.io

Linux tmpfs for Speed and Temporary Storage | LinuxBlog.io

tmpfs lets you mount a filesystem entirely in RAM. Here is how Linux already uses it, how to create your own mounts, and where it actually makes sense to use one.

^{Hayden James (LinuxBlog.io)}

(in)sicurezza digitale

2026-06-17 20:24:17

Supply chain attack su Uncanny Automator Pro: build backdoorata v7.3.0.5 distribuita a migliaia di siti WordPress

Il 12 giugno 2026, un attaccante sconosciuto ha compromesso l’infrastruttura di distribuzione di Uncanny Automator Pro, uno dei plugin WordPress più diffusi con oltre 50.000 installazioni attive. Il risultato: una build malevola — la versione 7.3.0.5 — consegnata automaticamente a una percentuale dei siti che usano il plugin, trasformando il canale di aggiornamento in un vettore di attacco. Un caso da manuale di supply chain attack nel mondo WordPress.

Cos’è Uncanny Automator e perché è un target appetibile

Uncanny Automator, sviluppato dalla società canadese Uncanny Owl, è un plugin WordPress per l’automazione di workflow. Permette di connettere plugin, app e servizi creando “ricette” automatizzate — integrazioni tra WooCommerce, BuddyBoss, LearnDash, Slack e molti altri. La versione Pro conta migliaia di siti attivi e viene distribuita tramite il sito automatorplugin.com, server di aggiornamento e licensing separato dal repository ufficiale di WordPress.org.

Questo modello di distribuzione autonomo — comune tra i plugin premium — è esattamente ciò che ha reso possibile l’attacco: compromettere automatorplugin.com significa controllare cosa viene consegnato agli aggiornamenti automatici di migliaia di siti WordPress.

Come si è svolto l’attacco

Secondo la comunicazione ufficiale firmata dal co-fondatore Ken, l’attaccante ha sfruttato una vulnerabilità in un software di terze parti in esecuzione su automatorplugin.com per ottenere accesso ai sistemi dell’azienda. Una volta dentro, ha eseguito due operazioni ad alto impatto in rapida successione:

• Tampering del pacchetto di aggiornamento: la build legittima di Uncanny Automator Pro sul server di distribuzione è stata sostituita con una versione backdoorata, etichettata come versione 7.3.0.5.
• Accesso al database di licensing: l’attaccante ha violato il database dello store e del sistema di licenze, esfiltrando dati cliente.

Il repository del codice sorgente non è stato toccato — un dettaglio importante che limita l’impatto futuro ma non quello immediato, poiché i siti non scaricano il codice dal repository ma dal server di distribuzione.

La finestra di esposizione: 21 ore di distribuzione malevola

La build compromessa è rimasta disponibile per circa 21 ore, dal 12 al 13 giugno 2026, quando Uncanny Owl ha rilevato l’intrusione e rimosso l’accesso dell’attaccante. In questa finestra, la versione 7.3.0.5 è stata distribuita a meno del 6% dei siti attivi che usano il plugin Pro — un numero contenuto, ma potenzialmente ancora nell’ordine delle migliaia di installazioni WordPress compromesse.

La versione gratuita Uncanny Automator Lite, distribuita tramite il repository ufficiale di WordPress.org, non è stata interessata dall’attacco.

Dati esposti e rischi per i clienti

La violazione del database di licensing ha esposto i seguenti dati per i clienti registrati:

• Nomi e indirizzi email
• Chiavi di licenza del plugin
• URL dei siti WordPress associati alle licenze

Dati di pagamento e numeri di carta non sono stati compromessi poiché l’azienda non li memorizza. Le password erano archiviate come hash crittografici — non in chiaro — ma come misura precauzionale Uncanny Owl ha resettato tutte le password degli account.

La combinazione di email + URL del sito + chiave di licenza crea però un vettore di phishing estremamente credibile: un attaccante può inviare email personalizzate fingendo di essere Uncanny Owl, chiedendo di installare “l’ultima versione” del plugin — che potrebbe essere di nuovo una build malevola. È un rischio che persiste anche dopo la remediation dell’infrastruttura.

Risposta dell’azienda e remediation

Uncanny Owl ha risposto rapidamente una volta rilevata l’intrusione:

• 13 giugno: rimosso l’accesso dell’attaccante, rilasciata la versione pulita 7.3.0.6
• 14 giugno: completata l’indagine, nessun segno di reinfezione
• Eliminati account amministratore non autorizzati, entry malevole nel database e task pianificati inseriti dall’attaccante
• Rotazione di tutte le credenziali e chiavi esposte

L’azienda ha pubblicato un Security Incident Notice completo sul proprio sito con tutti i dettagli e gli step di remediation raccomandati.

Il rischio residuo: la 7.3.0.5 è ancora in circolazione

Un aspetto critico sottolineato da Uncanny Owl riguarda la persistenza del rischio: installare una build 7.3.0.5 da qualsiasi fonte infetterà ancora il sito. Non è sufficiente che il server di distribuzione sia ora pulito. Copie della build malevola potrebbero circolare su repository non ufficiali, forum di pirateria software o essere utilizzate in attacchi successivi.

Inoltre, un aggiornamento in-place verso la 7.3.0.6 non è sufficiente per i siti già infetti: il backdoor installato dalla 7.3.0.5 può persistere indipendentemente dall’aggiornamento del plugin. È necessaria una remediation completa.

Cosa devono fare gli amministratori WordPress

• Verificare immediatamente la versione installata del plugin: deve essere 7.3.0.6 o superiore, mai 7.3.0.5
• Se il sito ha eseguito la 7.3.0.5, trattarlo come compromesso e seguire la procedura di remediation completa indicata da Uncanny Owl
• Resettare la password dell’account su automatorplugin.com tramite i canali ufficiali
• Monitorare eventuali email sospette da mittenti che si spacciano per Uncanny Owl o Uncanny Automator
• Non installare la versione 7.3.0.5 da nessuna fonte, anche se presentata come “originale”
• Verificare l’assenza di account amministratore WordPress non autorizzati, task pianificati anomali e modifiche al database

# Indicatori di compromissione da verificare su siti WordPress con plugin v7.3.0.5

# 1. Account amministratore WordPress non autorizzati
SELECT user_login, user_email FROM wp_users 
JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id
WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%'
ORDER BY user_registered DESC;

# 2. Task schedulati WordPress anomali (wp-cron)
SELECT * FROM wp_options WHERE option_name = 'cron' -- cercare entry con hook sconosciuti

# 3. Modifiche recenti a file core o plugin (ultimi 21 giorni)
find /path/to/wordpress -newer /path/to/wordpress/wp-config.php -name "*.php" 
  -not -path "*/cache/*" -not -path "*/uploads/*"

# Versione sicura: >= 7.3.0.6
# Versione compromessa: 7.3.0.5 (da qualsiasi fonte)
# Versione Lite (WordPress.org): non interessata dall'attacco

L’incidente di Uncanny Automator si inserisce in un pattern preoccupante di supply chain attack contro plugin WordPress premium, dove la distribuzione autonoma fuori dal repository ufficiale diventa il tallone d’Achille. La dipendenza da infrastrutture di distribuzione di terze parti, spesso meno protette del repository centrale, continuerà a essere un vettore di attacco privilegiato per chi vuole colpire a scala migliaia di siti simultaneamente.

Security Incident Notice: Uncanny Automator - Uncanny Automator

Summary We are writing to inform you of a security incident affecting Uncanny Automator and automatorplugin.com. On June 12, 2026, an attacker exploited a vulnerability in third-party software running on automatorplugin.

^{Ken Young (Uncanny Automator)}

(in)sicurezza digitale

2026-06-17 18:49:58

Come un semplice account FIFA avrebbe potuto compromettere i Mondiali 2026

Quando si parla di grandi eventi sportivi globali, l’immaginario collettivo corre subito agli stadi, alle telecamere, alle regie televisive e alle centinaia di milioni di spettatori collegati da ogni parte del mondo. Molto meno visibile è invece l’enorme infrastruttura digitale che permette a tutto questo di funzionare.

Eppure, secondo quanto raccontato dalla ricercatrice nota come BobDaHacker, sarebbe bastata una semplice registrazione come agente FIFA per ottenere accesso a sistemi interni capaci di influenzare direttamente la distribuzione delle immagini dei Mondiali di calcio 2026.

La storia inizia in modo apparentemente banale. La ricercatrice decide di iscriversi alla piattaforma pubblica utilizzata dalla FIFA per la registrazione degli agenti calcistici. Dopo aver completato il processo di verifica dell’identità, il suo account viene automaticamente inserito nel tenant Microsoft Entra utilizzato dall’organizzazione. Nulla di strano, almeno in apparenza.

Il problema emerge quando, esplorando altri portali appartenenti all’ecosistema FIFA, la ricercatrice scopre che l’autenticazione funziona correttamente ma l’autorizzazione no.

Si tratta di una delle vulnerabilità più comuni e allo stesso tempo più pericolose nel mondo delle applicazioni enterprise: il sistema verifica chi sei, ma non controlla adeguatamente cosa sei autorizzato a fare.

Nel caso specifico, alcune verifiche di autorizzazione sembravano essere implementate principalmente lato client. Una volta aggirati questi controlli, l’account appena creato riusciva ad accedere a piattaforme che avrebbero dovuto essere riservate esclusivamente al personale autorizzato.

La scoperta più preoccupante riguarda il pannello di gestione dello streaming dei Mondiali.

Secondo la documentazione pubblicata dalla ricercatrice, il sistema mostrava l’elenco completo delle partite del torneo, gli stream video associati, i relativi endpoint RTMP e diversi controlli operativi utilizzati per la gestione delle trasmissioni. Ancora più grave, sarebbero stati presenti comandi per l’avvio, l’arresto e la pianificazione dei flussi video.

BobDaHacker afferma di non aver mai eseguito operazioni distruttive e di essersi limitata a verificare l’accessibilità delle risorse. Tuttavia il semplice fatto che tali funzioni fossero raggiungibili da un account privo di privilegi rappresenta un classico scenario di “Broken Access Control”, categoria che da anni occupa le prime posizioni della classifica OWASP Top 10.

L’aspetto più interessante, dal punto di vista di chi si occupa di sicurezza applicativa, è che non siamo davanti a un sofisticato attacco zero-day, né a tecniche avanzate di exploitation.

Non ci sono buffer overflow, catene di exploit o vulnerabilità particolarmente esotiche.

L’intera vicenda sembra essere riconducibile a un errore architetturale estremamente semplice: un account legittimo appartenente al tenant aziendale veniva considerato implicitamente attendibile da sistemi che avrebbero invece dovuto effettuare controlli granulari sui ruoli e sulle autorizzazioni.

È un problema che molte organizzazioni incontrano quando adottano ecosistemi cloud complessi basati su Single Sign-On. L’autenticazione centralizzata riduce la complessità operativa, ma può trasformarsi in un rischio significativo quando le applicazioni downstream assumono che chiunque possieda un’identità valida debba poter accedere alle funzionalità disponibili. In altre parole, l’esistenza di un account non dovrebbe mai equivalere automaticamente all’esistenza di privilegi.

Secondo la ricostruzione pubblicata, la FIFA avrebbe corretto rapidamente il problema dopo la segnalazione, anche se senza instaurare un dialogo diretto con la ricercatrice.

Al di là dell’aneddoto del possibile “Rickroll” trasmesso durante una partita dei Mondiali, questa storia rappresenta un promemoria importante per tutte le organizzazioni che gestiscono infrastrutture critiche, piattaforme cloud e sistemi federati di identità.

Molto spesso la sicurezza non viene compromessa da vulnerabilità particolarmente sofisticate. Basta una singola autorizzazione mancante, un controllo implementato nel posto sbagliato o una fiducia eccessiva nell’identità dell’utente.

E quando il sistema in questione controlla la distribuzione televisiva dell’evento sportivo più seguito del pianeta, anche il più banale errore di autorizzazione può trasformarsi in un incidente di portata globale.

I Could've Rickrolled the Entire FIFA World Cup. All I Needed Was My ID.

How I found that anyone could register on FIFA's public Agent Platform, gain access to the Football Data Platform's Streaming Management panel, and get RTMP ingest URLs and stream keys for every live FIFA World Cup 2026 camera feed.

^{bobdahacker.com}

cretinodicrescenzago

2026-06-15 10:28:26

@alessandroid e ovviamente il discorso non vale solo per la salure psichica ma pure per malattie statisticamente rare, questioni riproduttive e addirittura allergie – qui nella comunità finocchia, senza passaparola informale faremmo una fatica bestia ad accedere a quel po' di risorse che ancora ci sono, e non è un caso se nella comunità trans* si ironizza sempre (o forse no) sul fare il Breaking Bad frocio con la produzione di ormoni in casa.
Per dire che il problema è sistemico