La cronaca recente ha messo in evidenza un incidente significativo riguardante lo scudo anti-pirateria italiano, noto come Piracy Shield, quando il sito di tecnologia DDay è stato erroneamente bloccato. Questo evento non solo solleva domande sulla funzionalità del sistema ma riapre anche un dibattito (in realtà mai chiuso) sui suoi limiti, i suoi scopi e sulla sua efficacia.

Innovativo o inadeguato?

Il Piracy Shield è stato promosso come una risposta innovativa alla pirateria online, in particolare per proteggere le trasmissioni di eventi sportivi, come le partite di calcio della Serie A. Sviluppato e gestito dall’Autorità per le Garanzie nelle Comunicazioni (AGCOM), il sistema permette ai detentori dei diritti di segnalare contenuti pirata, che poi vengono bloccati entro 30 minuti dall’avvio della segnalazione.

Neanche Google è al sicuro

Tuttavia, il blocco di DDay ha messo in luce un problema critico: l’overblocking. Il sito, del tutto legittimo, è stato reso
inaccessibile perché ha usato lo stesso indirizzo IP di siti pirata, per una banale questione di load balancing del CDN
(leggi paragrafo in basso “Load balancing: un meccaniscmo omnipresente“). Questo errore evidenzia una grave lacuna nel sistema, che non riesce a distinguere accuratamente tra contenuti legali e illegali. Non si tratta, purtroppo, del primo errore. Il 19 ottobre 2024, per esempio, il dominio drive.usercontent.google.com, utilizzato per scaricare file da Google Drive, è stato erroneamente bloccato a livello DNS. Questo dominio è essenziale per il funzionamento del servizio di archiviazione e condivisione file di Google. L’errore specifico in questo caso è stato causato da una segnalazione errata che ha incluso un dominio di Google Drive nella lista dei siti da bloccare. Il disguido potrebbe essere avvenuto perché qualcuno ha condiviso link pirata su Google Drive, e il sistema ha automaticamente bloccato l’intero dominio associato senza verificare accuratamente la natura del contenuto. Il blocco ha causato problemi di accesso per diverse ore, influenzando migliaia di utenti, inclusi privati, aziende, scuole e università. Anche altri servizi del colosso, come YouTube, hanno riscontrato problemi temporanei correlati a questo incidente.

Tanti problemi sin dall’inizio

Il Piracy Shield, nato, come dicevamo, con l’intento di contrastare lo streaming illegale di eventi sportivi e contenuti protetti da copyright, è stato introdotto con la legge 93 del 14 luglio 2023. Già dal primo mese di operatività, si sono
verificati casi di overblocking a spese di siti legali. Nel febbraio 2024, poco dopo l’attivazione completa del sistema, un indirizzo IP di Cloudflare, che ospita milioni di siti, è stato bloccato, causando l’inaccessibilità di molti siti legittimi. Diversi esperti e associazioni di tecnologia hanno criticato il sistema per la sua progettazione amatoriale e la mancanza di considerazione per come funziona Internet oggi (load balancing incluso), oltre che per una mancanza
di trasparenza riguardo a chi esegue le segnalazioni, per la loro gestione e per i costi elevati. Il suo codice
sorgente e la documentazione interna sono stati persino pubblicati su GitHub in un leak di protesta che accusava il sistema di essere una forma di censura. Nonostante sia stato emesso un avviso DMCA per rimuovere il materiale, il codice è già in circolazione su piattaforme come Telegram e reti peer-to-peer, creando ovvi problemi per AGCOM.

L’incidente con DDAY sembra evidenziare la scarsa considerazione del sistema per come funziona Internet oggi, con indirizzi IP dinamici e CDN (Content Delivery Network) che distribuiscono contenuti attraverso numerosi indirizzi IP. Chi protegge i siti onesti?

Ancora più limiti: ne vale la pena?

Le modifiche del 2024, approvate tramite il decreto legge Omnibus lo scorso ottobre, hanno portato ad altre critiche. L’obbligo di blocco non si limita più agli ISP italiani ma si estende anche ai fornitori di servizi VPN e di DNS pubblici globali. Questa estensione ha sollevato preoccupazioni per la privacy e la libertà di Internet, poiché impone a operatori internazionali di conformarsi alle leggi italiane. Ora, inoltre, non è più necessario che un sito sia “univocamente destinato ad attività illecite” per essere bloccato, ma basta che le attività illecite siano “prevalenti”, una distinzione che potrebbe portare a un aumento dei casi di overblocking. Le modifiche hanno ampliato i
poteri di AGCOM e imposto nuovi obblighi ai fornitori di servizi, come la segnalazione tempestiva di attività sospette alle autorità competenti. Questo ha aumentato la complessità operativa per gli ISP e altri operatori di rete. Le nuove misure hanno quindi intensificato il dibattito sul bilanciamento tra la protezione del diritto d’autore e la libertà online. Ci sono preoccupazioni che tali regolamenti possano portare a una forma di censura, influenzando
negativamente l’accesso a contenuti e servizi legittimi. Le modifiche hanno, infine, incrementato i costi operativi per gli ISP e altri operatori e molti mettono in discussione l’efficacia reale di queste misure nel ridurre la pirateria, considerando che i siti pirata possono facilmente cambiare indirizzi IP o utilizzare tecnologie per aggirare le restrizioni.

LOAD BALANCING: UN MECCANISMO ONNIPRESENTE

I provider di Content Delivery Network (CDN) utilizzano il load balancing per migliorare l’efficienza, l’affidabilità e le prestazioni nella distribuzione dei contenuti agli utenti finali. Una CDN opera distribuendo copie di contenuti statici (come immagini, video, file CSS/JavaScript e pagine HTML) su una rete globale di server posizionati strategicamente
in diverse località. Il load balancing è una parte fondamentale di questo sistema, poiché consente di gestire il
flusso di richieste degli utenti in modo intelligente. Quando accedete a un sito che utilizza una CDN, infatti, determina quale server nella rete è più adatto a rispondere alla vostra richiesta. Questo viene fatto considerando
vari fattori, come la vostra posizione geografica, la latenza di rete, il carico attuale sui server e persino eventuali
guasti. Per esempio, se un utente europeo visita un sito ospitato su una CDN, il sistema di bilanciamento del carico lo reindirizzerà al server più vicino in Europa, riducendo la latenza e migliorando la velocità di caricamento. I provider CDN utilizzano il load balancing anche per garantire una distribuzione uniforme del traffico. Durante eventi ad alto accesso, come il lancio di un prodotto o un grande evento mediatico, il sistema distribuisce le richieste tra i vari server per evitare che uno solo di essi venga sovraccaricato, garantendo così che il servizio rimanga stabile. Inoltre, se un server in una specifica area geografica non è disponibile, il load balancing ridirige automaticamente le richieste verso un altro nodo funzionante, mantenendo l’alta disponibilità del servizio. In sintesi, il load balancing permette ai provider CDN di offrire un’esperienza utente ottimale indipendentemente dalla posizione o dalle condizioni di traffico, assicurando velocità, affidabilità e scalabilità nella distribuzione dei contenuti. L’esperienza di DDAY sembra
suggerire che, se un segnalatore di Piracy Shield inserisce in blacklist uno degli IP del provider CDN utilizzato
da un sito innocente che vi viene indirizzato per il load balancing, questo rischia l’interruzione del proprio servizio
con i danni che ne conseguono. La lotta alla pirateria è sicuramente importante, ma tutelare chi lavora onestamente su Internet dovrebbe esserlo altrettanto…

Leggi anche: “Maxi operazione contro lo streaming online“

Come è ben noto, nessun sistema operativo ha di base tutte le applicazioni che potrebbero servire a uno specifico utente, quindi la possibilità di installarne di nuove è fondamentale. Per questo, Elementary OS 8.0 introduce per la prima volta Flathub come store predefinito, con il vantaggio di avere applicazioni completamente autonome per le loro necessità di funzionamento. Sul fronte della privacy, il nuovo sistema operativo permette un controllo più capillare delle applicazioni che possono accedere ai dati dell’utente, grazie ad autorizzazioni esplicite. Anche la Dock ha subito alcuni miglioramenti. Ora è infatti sempre possibile visualizzare contemporaneamente, con un solo clic, tutte le finestre aperte e passare con più facilità da un’attività all’altra. Per chi usa questo sistema operativo nei dispositivi mobili, viene introdotto il supporto per il multi-touch, rendendo così molto più comoda e fluida la
navigazione nell’interfaccia. Per quanto riguarda un aspetto più estetico, sebbene con un’influenza diretta sulla praticità d’uso, Elementary OS introduce un nuovo set di icone per il puntatore del mouse e nuovi sfondi
sfocati nelle schermate di multitasking.

Guida pratica all’uso

Elementary OS può essere annoverato tra i sistemi operativi che cercano di rendere facile la vita agli utenti, anche a quelli meno esperti, grazie a un’interfaccia pratica da usare. In alto a sinistra c’è il menu Applicazioni, all’interno del
quale troverete tutti i programmi disponibili in ordine alfabetico. Tuttavia, facendo clic sul pulsante Visualizza per categoria, potrete averli raggruppati per area tematica. Per avere il lanciatore di un’applicazione nella Dock è
sufficiente afferrarne l’icona con il mouse e trascinarla in basso. Invece, se volete togliere un launcher dalla Dock, basterà fare un clic destro su di esso e togliere la spunta a Keep in Dock. Le notifiche sui vari aggiornamenti
disponibili vengono visualizzate facendo clic sulla campanella in alto a destra quando su di essa appare un puntino rosso. Poi sarà sufficiente premere sul pulsante dell’aggiornamento da installare per dare il via alla procedura. In Impostazioni di sistema troverete la sezione Sicurezza e privacy. Qui potrete modificare diversi parametri.
Per esempio, in Cronologia è possibile disattivare con un clic i dati di utilizzo per tutte le applicazioni contemporaneamente. Oppure potete selezionare le applicazioni che non dovranno conservarli. In Manutenzione potrete invece decidere quanto a lungo debbano venire conservati i vecchi file, per esempio quelli nel Cestino. Dopodiché, il sistema operativo li eliminerà automaticamente.

COME INSTALLARE ELEMENTARY OS

Localizzazione e tastiera
Avviato il file ISO, la prima finestra che viene proposta è quella in cui scegliere la nostra lingua. Scorrete l’elenco e selezionate Italiano, dopodiché fate clic su Select. Nella schermata seguente, scegliete la tastiera Italiana scorrendo l’elenco e poi lasciate selezionato Predefinito. Premete su Seleziona per proseguire.

Scelta del tipo di installazione
Nella schermata Prova o installa, selezionate con un clic Erase Disk and Install. Poi premete sul pulsante Erase Disk and Install, in basso. Se state usando una macchina virtuale, apparirà un messaggio che vi avverte che il sistema operativo potrebbe subire rallentamenti o altro. Fate clic su Install Anyway.

Disco rigido e cifratura
In Seleziona un supporto vengono elencati i dischi rigidi disponibili per l’installazione. Selezionate quello che volete
dedicare a Elementary OS e fate clic su Successivo. In Enable Drive Encryption, premete su Don’t Encrypt, a meno che non abbiate motivi di sicurezza per fare diversamente.

Driver aggiuntivi e installazione
Nella schermata Additional Drivers, selezionate con un clic Include third-party proprietary drivers… e premete sul pulsante Cancella e installa. A questo punto ha inizio l’installazione vera e propria di Elementary OS, al termine della quale dovrete fare clic su Riavvia il dispositivo. Rimuovete il file ISO e premete INVIO.

Il benvenuto
Nella finestra Welcome, fate clic su Successivo. Poi selezionate l’aspetto dell’interfaccia, per esempio Scuro. Premete su Successivo e decidete se attivare la Luce Notturna. Poi selezionate il tipo di Manutenzione, per esempio con la
cancellazione automatica dei file temporanei.

Ultimi dettagli
Nella schermata successiva potrete attivare fin da subito gli Online Accounts. Quindi, in Ottieni delle applicazioni, potrete già installare quelle che vi servono. In Automatic Updates, selezionate Operating System dopodiché, fatto clic su Per iniziare, potrete finalmente usare Elementary OS.

Leggi anche: “Vojager 24.10: una distro live“

Nel mondo hacker, la linea tra “eroi” e “antieroi” è sottile, ed è comune che figure considerate generalmente come “i buoni” si rivelino meno perfette di quanto appaiano. Ciò che è certo, è che si tratta di figure non convenzionali. Anzi, uniche. È il caso di Tsutomu Shimomura, un esperto di sicurezza informatica giapponese diventato noto perché contribuì a incastrare Kevin Mitnick, uno dei più celebri hacker della storia, conosciuto come “il Condor”. Forse il primo in assoluto, di cui abbiamo più volte parlato sulle colonne di questa rivista. Ma chi è questo enigmatico uomo e come riuscì a compiere una tale impresa?

IL PRINCIPIO

Tsutomu Shimomura non è un hacker nel senso classico del termine. Non proveiene da una cultura di sovversione digitale né condivide l’etica del “libero accesso” che spesso guida il mondo dell’hacking. È uno scienziato, un esperto in crittografia e sicurezza informatica che lavora per difendere i sistemi dagli attacchi. In passato, il suo percorso si è incrociato con quello di Mitnick, quando quest’ultimo decise di infiltrarsi nei suoi sistemi.

Shimomura ha raccontato la sua “impresa” nel libro Takedown (del 1996) che fu adattato per il cinema nel film omonimo nel 2000.

UNA SFIDA

Tutto avvenne nel 1994, quando Mitnick, già ricercato dall’FBI, violò i sistemi di Shimomura e, per quest’ultimo, la caccia al Condor non fu solo una questione lavorativa, ma una vera e propria sfida.

Armato delle sue competenze e della sua passione per la sicurezza, Shimomura collaborò con l’FBI per rintracciare Mitnick. Fu una battaglia tecnologica all’avanguardia, in cui Shimomura utilizzò tecniche di tracciamento innovative per l’epoca, tra cui la triangolazione dei segnali cellulari, per localizzare l’hacker che si nascondeva dietro il suo alias.

Mitnick, che aveva passato anni eludendo le autorità, si trovò improvvisamente davanti un avversario inaspettato. Non un altro hacker, ma un uomo che combinava una profonda conoscenza tecnica con una determinazione feroce. Alla fine, nel febbraio del 1995, Kevin Mitnick fu arrestato in un appartamento a Raleigh, nel North Carolina, grazie anche all’inseguimento digitale orchestrato da Shimomura.

John Markoff è il giornalista informatico che collaborò con Shimomura alla cattura di Mitnick.

UNA BATTAGLIA TRA DUE MONDI

“L’inseguimento” tra Shimomura e Mitnick non fu solo una battaglia tecnologica, ma anche una sorta di scontro ideologico. Da una parte, c’era il Condor, simbolo della libertà hacker e della sfida alle autorità; dall’altra, Shimomura, emblema della difesa della sicurezza e del rispetto per la legge. Questo conflitto rappresenta perfettamente una delle dinamiche più affascinanti del mondo dell’hacking: la costante tensione tra chi vede nella Rete uno spazio di anarchia e libertà, e chi lo considera un terreno da proteggere e regolamentare. Entrambi i protagonisti di questa vicenda sono diventati figure di culto nei rispettivi ambiti, e la loro storia continua a essere studiata e discussa dagli appassionati di tecnologia e sicurezza informatica.

Il padre di Shimomura, Osamu Shimomura, vinse il premio Nobel per la chimica nel 2008.

Leggi anche: “Addio a Kevin Mitnick“

SEESII NANOVNA-H
ANALISI DI RETE
Il NavoVNA-H è uno strumento avanzato pensato per ingegneri elettronici, radioamatori e professionisti delle telecomunicazioni. Con un intervallo di misura da 10KHz a 1,5GHz, permette di analizzare con precisione le prestazioni delle antenne, il rapporto d’onda stazionaria (SWR) e i parametri S11/S21. Sfrutta l’estensione delle armoniche dispari del si5351, garantendo misurazioni più accurate e riducendo le interferenze con la schermatura metallica. Dotato di un display touchscreen LCD da 2,8 pollici, è intuitivo e facile da usare. Il metodo TX/RX consente di misurare i parametri completi S11 e S21 con cambio manuale delle porte del ricetrasmettitore, mentre la compatibilità con il software NanoVNA Saver permette di collegarlo al PC per visualizzare, analizzare ed esportare i dati in formato Touchstone (.snp) per simulazioni radio.

Quanto costa: € 66

Dove acquistarlo: su Amazon

LOCKPIC
PER L’APERTURA DI SERRATURE
Il LockPic è un gadget indispensabile per professionisti della sicurezza, esperti di lockpicking e per chi desidera apprendere le tecniche di apertura non distruttiva. È uno strumento avanzato è progettato per sbloccare serrature in modo rapido ed efficiente, senza danneggiarle, rendendolo perfetto per situazioni di emergenza o test di sicurezza. Dotato di una tecnologia di precisione, permette di manipolare i meccanismi interni della serratura con estrema facilità. Il design ergonomico garantisce una presa salda e un utilizzo intuitivo, anche per chi è alle prime armi. Inoltre, grazie alla sua struttura compatta e leggera, può essere trasportato ovunque senza ingombri.

Quanto costa: € 36

Dove acquistarlo: su Amazon 

ROMPICAPO QANMUA
SFIDE PER LA MENTE
Una serie di rompicapo perfetta per chi ama mettere alla prova le proprie abilità, offrendo un’esperienza stimolante e coinvolgente. Ogni enigma è progettato per sfidare la mente, stimolare la creatività e affinare il pensiero, rendendo ogni tentativo un’opportunità per migliorare la propria agilità mentale. Ideali per allenare la mente, questi gadget sono un modo divertente e intelligente per trascorrere il tempo, sia da soli che in compagnia. Realizzati con materiali di alta qualità, uniscono estetica e funzionalità, garantendo un’esperienza di gioco piacevole e duratura. La loro costruzione solida li rende adatti sia per adulti che per bambini, offrendo un livello di difficoltà progressivo che consente a chiunque di mettersi alla prova, indipendentemente dall’esperienza. La soluzione ideale per chi è alla ricerca di un passatempo intelligente!

Quanto costa: € 13

Dove acquistarlo: su Amazon

Leggi anche: “Gadget dell’hacker – gennaio“

La televisione sta per fare un salto nel futuro grazie a una nuova tecnologia che promette di cambiare il modo in cui guardiamo i programmi sui nostri dispositivi mobili. Si chiama 5G Broadcast ed è una modalità innovativa per trasmettere contenuti televisivi direttamente su smartphone e tablet senza consumare i preziosi Gigabyte del piano dati. La Rai ha recentemente avviato la prima sperimentazione su larga scala di questo sistema nelle aree metropolitane di Roma e Torino, utilizzando frequenze dedicate in banda UHF assegnate dal Ministero di riferimento. L’obiettivo è portare programmi televisivi di alta qualità e bassa latenza direttamente sui dispositivi mobili di nuova generazione.

I vantaggi del 5G Broadcast

Come funziona esattamente questa nuova tecnologia? Il 5G Broadcast si differenzia sia dalle trasmissioni televisive tradizionali che dallo streaming via Internet. Invece di utilizzare la normale rete dati mobile, impiega una frequenza dedicata attraverso la quale trasmette il segnale in modalità “one-to-all”, proprio come fa il digitale terrestre. In pratica, un solo segnale raggiunge contemporaneamente tutti i dispositivi nell’area di copertura, indipendentemente dal numero di utenti che lo ricevono. I vantaggi sono molteplici: niente consumo del traffico dati, nessuna congestione della rete nelle aree affollate e una qualità costante, indipendentemente dal numero di spettatori. Inoltre, questa tecnologia potrebbe portare a una riduzione significativa delle emissioni elettromagnetiche e dei consumi energetici, dato che un singolo impianto può servire un numero elevatissimo di utenti.

La vera chiave per l’adozione del 5G Broadcast è nascosta nel cuore degli smartphone: i chip modem di Qualcomm includono già l’hardware necessario grazie all’esperienza maturata con LTE Broadcast, il predecessore di questa tecnologia. Non servirà quindi sostituire i dispositivi, ma solo un aggiornamento software per attivare la funzionalità.

La sperimentazione e gli ostacoli

La sperimentazione italiana guarda già ai grandi eventi del prossimo futuro: il Giubileo del 2025 e le Olimpiadi invernali di Milano-Cortina 2026 saranno occasioni ideali per mettere alla prova il sistema in situazioni di alta concentrazione di pubblico.
C’è però un ostacolo da superare: al momento non esistono dispositivi commerciali in grado di ricevere questi segnali. Sebbene molti smartphone moderni utilizzino modem Qualcomm che integrano già l’hardware necessario, mancano ancora i software e i driver per attivare questa funzionalità. Gli esperti sono ottimisti: una volta che il segnale sarà disponibile, i produttori inizieranno ad aggiornare i loro dispositivi per supportare il nuovo standard. WindTre ha già annunciato che nel presto lancerà il suo servizio 5G standalone, un passaggio fondamentale per sfruttare appieno le potenzialità del 5G Broadcast. La Rai, dal canto suo, prevede di estendere la sperimentazione ad altre aree metropolitane nel corso del prossimo anno. Il 5G Broadcast rappresenta una piccola rivoluzione nel panorama delle telecomunicazioni: unisce la capillarità della televisione tradizionale alla comodità dei dispositivi mobili, promettendo di trasformare radicalmente la nostra esperienza di fruizione dei contenuti televisivi in mobilità. È il sogno, più di vent’anni dopo, del “videofonino”, che in Italia fece la sua comparsa nel 2003 con il 3G.

Dalla radio alla TV: un secolo di Broadcasting

Il termine broadcast ha radici profonde nella storia delle telecomunicazioni. Nato nel 1922 per descrivere le trasmissioni radio aperte a tutti (in contrapposizione alle comunicazioni punto-punto), il concetto ha rivoluzionato la comunicazione di massa. La televisione ha adottato lo stesso principio negli anni trenta, e oggi il 5G Broadcast rappresenta la terza generazione di questa modalità di diffusione. E c’è un grande vantaggio rispetto allo streaming tradizionale: consuma molto meno. Infatti, il video streaming rappresenta oggi oltre il 70% del traffico Internet mobile globale, con picchi durante eventi live come le partite di calcio o concerti. In queste situazioni, migliaia di connessioni simultanee allo stesso contenuto creano quello che gli esperti chiamano “effetto valanga”: ogni utente richiede una propria copia del flusso video, moltiplicando esponenzialmente il carico sulla rete. Un esempio pratico: durante una partita in uno stadio da 50mila posti, lo streaming tradizionale deve gestire 50mila flussi video identici, mentre il broadcast ne utilizza uno solo per tutti.

Leggi anche: “Attacco alle rete mobile 5G”

*illustrazione articolo progettata da Freepik

La crescente diffusione e sofisticazione dei malware per dispositivi mobili, negli ultimi anni, ha reso gli smartphone un obiettivo primario per i cybercriminali. Lo scorso anno, l’espansione di codici malevoli per dispositivi Android ha registrato numeri preoccupanti: secondo Kaspersky, sono stati bloccati oltre 33,8 milioni di attacchi tra malware, adware e riskware, con un aumento delle minacce legate ai trojan bancari e altre forme di malware pensati per il mobile. Quelli per Android si stanno evolvendo rapidamente, passando da semplici adware e a soluzioni più insidiose e difficili da rilevare, capaci di eludere le difese degli utenti più esperti. Uno dei più recenti e preoccupanti è TrickMo nelle sue ultime varianti, un trojan che ha attirato l’attenzione delle comunità di esperti di sicurezza per l’aggiornamento delle sue capacità che lo rendono ancora più pericoloso.

VECCHIA CONOSCENZA

È stato documentato per la prima volta dagli specialisti della divisione sicurezza di IBM X-Force nel 2020. Di recente, invece, la società di sicurezza informatica Cleafy ha rivelato che TrickMo è stato aggiornato con nuove funzionalità, tra queste, l’intercettazione di, OTP, la registrazione dello schermo, l’esfiltrazione dei dati e la possibilità di lanciare attacchi, in gergo overlay, col fine di proporre all’utente delle false schermate in cui inserire le credenziali, tra queste il PIN utilizzato per sbloccare lo smartphone.
Un’evoluzione che ha reso TrickMo molto pericoloso, poiché non solo sottrae informazioni sensibili ma, potenzialmente, apre anche la porta a ulteriori attacchi, come l’accesso non autorizzato ai conti bancari, il furto di dati di accesso a servizi online e la compromissione della privacy. Gli esperti di Zimperium hanno stimato che le vittime del malware siano oltre 13mila, con la diffusione che avviene principalmente tramite phishing.
Per ridurre al minimo il rischio di infezione, si raccomanda di evitare il download di file APK da URL sospette. Fortunatamente, Google Play Protect (la funzionalità di sicurezza integrata nei dispositivi Android che serve a proteggere smartphone o tablet da applicazioni dannose) dovrebbe essere in grado di rilevare e bloccare tutte le varianti conosciute, ma è possibile che ne esistano altre non ancora documentate.

Google Play Protect permette di analizzare tutte le applicazioni presenti sui telefoni Android e impedisce l’installazione di malware o app dannose.

COME FA A RUBARE IL TELEFONO

La variante di TrickMo che consente a un cybercriminale di rubare il PIN dello smartphone della vittima, induce l’utente a inserire il codice su una schermata che sembra proprio quella del sistema operativo del telefono. Nello specifico, durante la navigazione Web, il sistema visualizza a schermo intero una pagina HTML, ospitata su un sito esterno, che imita alla perfezione l’interfaccia del sistema operativo per la richiesta del codice di sblocco; se l’utente, ignaro del pericolo, digita il PIN o la sequenza di sblocco, queste informazioni, insieme a un identificativo unico del dispositivo, vengono inviate così al server dell’attaccante tramite una richiesta HTTP di tipo POST. Grazie al PIN trafugato gli aggressori possono in seguito sbloccare il dispositivo, magari durante la notte quando non è monitorato, e così perpetrare i loro scopi malevoli.

Lo script malevolo che associa il PIN digitato dall’utente a un dispositivo Android specifico. Per farlo, utilizza il metodo getAndroidID, che fornisce un valore univoco identificativo dello smartphone.

VI CHIEDE DI AGGIORNARE GOOGLE PLAY SERVICES

TrickMo a è un’app definita in gerso “dropper” (spesso spacciata per il browser Google Chrome), distribuita tramite allegati e-mail infetti, download di software da fonti non sicure o applicazioni apparentemente legittime scaricate da siti web o store di app non ufficiali. Questa tenta di ingannare gli utenti e, se ci riesce, una volta installata, li invita ad aggiornare Google Play Services, il sistema responsabile del corretto funzionamento e dell’aggiornamento delle app sui dispositivi Android. Questo falso aggiornamento richiede il download di un file APK che contiene il payload TrickMo, mascherato da servizio di Google, chiedendo all’utente, ignaro del pericolo, di attivare i servizi di accessibilità per la nuova app. Questa operazione conferisce un controllo esteso sullo smartphone, inclusa la possibilità di disabilitare funzioni di sicurezza, impedire aggiornamenti di sistema e rimuovere app specifiche. Ciò permette al cybercriminale di intercettare messaggi SMS, manipolare le notifiche per nascondere o leggere codici di autenticazione e condurre attacchi con HTML overlay per sottrarre informazioni sensibili.

Leggi anche: “Scylla malware ha infettato milioni di utenti ios e android“

Fin dalla nascita del Web uno degli attacchi più comuni, consiste nel colpire il sito istituzionale. Ma non è che chi costruisce siti non lo sappia: esistono vari meccanismi per proteggere un portale da tentativi di defacciamento e soprattutto di Denial of Service. Alcune soluzioni sono generali, valgono più o meno per tutti i siti “importanti”, altre dipendono dall’infrastruttura e dal framework su cui si basa l’applicazione del sito Web. A questo proposito, i due framework più diffusi per i frontend, cioè proprio per i siti Web istituzionali non dinamici, sono Next.js e Vue.js. E il primo dei due sembra, per ora, avere più successo proprio con i siti più grandi, quelli che si aspettano di dover ricevere un maggiore numero di visitatori e magari avere una struttura più complessa. Naturalmente, anche un sito “statico”, è solitamente realizzato con un qualche CMS, che memorizza i contenuti del sito in un database. Soprattutto perché alcuni componenti possono essere modificati anche in tempo reale, per esempio da qualche automazione. Se, però, ogni volta che un utente visita una pagina del sito viene fatta una sfilza di query sul database per recuperare i contenuti e generare l’HTML da generare, il risultato è un carico notevole sul database stesso. Che può anche essere potente e replicato, ma per siti molto visitati diventa estremamente costoso e inefficiente. Per questo motivo, Next.js ha un meccanismo di caching lato server: i componenti React di ogni pagina vengono renderizzati direttamente dal server, che poi memorizza in locale l’HTML completo e fornisce ai vari client che lo interrogheranno direttamente la pagina già renderizzata. Almeno finché la cache non viene invalidata, in quel caso si costruisce di nuovo l’HTML aggiornato. Il vantaggio è che in questo modo gli unici client che insistono sull’infrastruttura più delicata (il backend e il database) sono le varie istanze del frontend, che al massimo saranno qualche decina o qualche centinaio. Ognuna di queste istanze frontend Next.js, con l’HTML renderizzato, può rispondere alle richieste contemporanee di migliaia di utenti. Quindi, se alla fine il traffico complessivo del sito è di milioni di utenti unici contemporanei, le richieste che arrivano al backend sono al massimo poche centinaia e comunque solo quando c’è bisogno di rifare la cache perché un contenuto è cambiato.
Tutto perfetto, quindi? Come si fa a colpire un sistema che è pensato proprio per reggere a un traffico enorme? In realtà, c’è un piccolo difetto di progettazione che può ritorcere il caching contro se stesso.

Next.js ha introdotto un fix per evitare l’auto-poisoning della cache, ma può essere bypassato da un malintenzionato. FONTE: https://github.com/

Un parametro ignorato

Next.js scambia tra client e server un blob binario, chiamato RSC (React Server Component), che serve al browser per sapere come aggiornare il DOM della pagina. Visto che questo blob proviene sempre dallo stesso URL, l’intestazione delle sue richieste HTTP contengono il valore
Rsc: 1 nel parametro Vary, così da da far sapere al browser che questo contenuto può cambiare e non va tenuto nella cache. Per ulteriore sicurezza, però, all’URL viene aggiunto un parametro GET del tipo:

_rsc=valorecasuale

In questo modo la richiesta HTTP risulta fatta, ogni volta, a un URL diverso, perché basta cambiare il valore casuale alla fine dell’URL per essere certi di bypassare la cache del browser o di una eventuale CDN posta davanti a Next.js (che poi si comporta come un browser). Il parametro _rsc è utilizzato come “cache buster”. La domanda da porsi è: perché serve questo parametro? Non bastava l’header Vary? Evidentemente no: Next.js finisce per “avvelenarsi” da solo, in un esempio di cache-poisoning da manuale. Se, infatti, le CDN non sanno di dover aggiornare la propria cache rischiano di continuare a mantenere dei contenuti non più validi, e se vengono indotte a mettere in cache qualcosa che non esiste da quel momento forniranno per sempre agli utenti un errore 404.
Il problema dell’header Vary è che molte CDN commerciali (Cloudflare, Cloudfront, o Akamai, per esempio) tendono a ignorarlo o comunque a rimuoverlo quando passano i contenuti ai browser. Questo significa che la pagina che arriva all’utente non ha questo header e rischia di non essere aggiornata correttamente. Non solo: per come funziona Next.js, è anche possibile spingere la CDN a memorizzare la cosa sbagliata e “rompere” il sito. Infatti, la logica di Next.js prevede che la prima volta che un client (il browser di un utente) raggiunge una pagina riceva l’HTML iniziale, e le volte successive ottenga il blob RSC per aggiornare solo il necessario, chiamando sempre lo stesso URL. Questo però significa che è possibile eseguire una richiesta al server Next.js togliendo il parametro _rsc e aggiungendo l’intestazione Rsc: il risultato è che la CDN memorizza, per l’URL base non l’HTML iniziale (che avrebbe senso tenere in cache) ma il blob binario. Sostanzialmente, il problema è che sono previste due modalità di accesso alla risorsa HTTP, che forniscono due output distinti, un HTML da tenere in cache e un blob da non conservare nella cache. Le due modalità si distinguono per i vari parametri che vengono passati nell’URL o nell’intestazione. Il problema è che se qualcuno costruisce una richiesta malevola, mescolando questi parametri, può convincere la CDN a tenere in cache il contenuto “sbagliato” (il blob) al posto del contenuto “giusto”. E il risultato è che i browser, alla fine, non sanno come interpretarlo e l’utente non vede il sito.

Con una serie di tentativi, è possibile indurre una CDN a memorizzare il blob RSC invece dell’HTML, rendendo il sito di fatto non accessibile. FONTE: https://zhero-web-sec.github.io/

Entità della vulnerabilità

Questo tipo di vulnerabilità è particolarmente subdola: il pericolo è che alcuni aspetti non dipendano nemmeno da chi sviluppa il sito, ma dal funzionamento della CDN. Se ci si rivolge a una CDN commerciale, non c’è sempre la garanzia che non cambi il modo di funzionare in futuro. Inoltre, se ci si dovesse accorgere che il proprio sito è vulnerabile a questo tipo di attacco non è facile modificarne il funzionamento per correggere il problema.

La soluzione

Il problema è legato a un “rimpallo” di responsabilità tra gli autori di Next.js e i progettisti delle CDN. Per Next.js, la responsabilità di interpretare l’intestazione Vary è dei client, quindi di browser e CDN. Per le CDN, la regola di fondo è che i contenuti diversi dovrebbero avere URL diversi a prescindere. L’unica soluzione reale è assicurarsi che la CDN di propria scelta non stia rimuovendo o rifiutando l’header Vary: alcune tra le CDN più famose rispettano questo header, ma solo nei piani a pagamento. In alternativa, si può porre davanti a Next.js un reverse proxy (es: nginx) configurato per mappare correttamente URL in modo da soddisfare le regole della CDN.

Leggi anche: “Una falla Mastodontica”

*illustrazione articolo progettata da Freepik