Google spinge i domini .zip e .mov su Internet e Internet respinge Ars Technica

Una recente mossa di Google per popolare Internet con otto nuovi domini di primo livello sta suscitando preoccupazioni sul fatto che due delle aggiunte potrebbero essere un vantaggio per i truffatori online che inducono le persone a fare clic su collegamenti dannosi.

Spesso abbreviato in TLD, un dominio di primo livello è il segmento più a destra di un nome di dominio. Agli albori di Internet, aiutavano a classificare lo scopo, la regione geografica o l’operatore di un determinato dominio. Il TLD .com, ad esempio, corrispondeva a siti gestiti da entità commerciali, .org era utilizzato per organizzazioni non profit, .net per entità Internet o di rete, .edu per scuole e università e così via. Esistono anche prefissi nazionali, come .uk per il Regno Unito, .ng per la Nigeria e .fj per le Figi. Una delle prime comunità Internet, The WELL, era raggiungibile all’indirizzo www.well.sf.ca.us.

Da allora, le organizzazioni che governano i domini Internet hanno implementato migliaia di nuovi TLD. Due settimane fa, Google ha aggiunto otto nuovi TLD a Internet, portando il numero totale di TLD a 1.480, secondo l’Internet Assigned Numbers Authority, l’organo di governo che sovrintende alla radice DNS, all’indirizzamento IP e ad altre risorse del protocollo Internet.

Due dei nuovi TLD di Google.zip e .movhanno suscitato disprezzo in alcuni circoli di sicurezza. Mentre i marketer di Google dicono che l’obiettivo è quello di designare il legare le cose insieme o lo spostamento molto veloce e le immagini in movimento e qualunque cosa ti muova, rispettivamente, questi suffissi sono già ampiamente utilizzati per designare qualcosa di completamente diverso. Nello specifico, .zip è un’estensione utilizzata nei file di archivio che utilizzano un formato di compressione noto come zip. Il formato .mov, nel frattempo, appare alla fine dei file video, di solito quando sono stati creati nel formato QuickTime di Apple.

Molti professionisti della sicurezza avvertono che questi due TLD creeranno confusione quando verranno visualizzati nelle e-mail, sui social media e altrove. Il motivo è che molti siti e software convertono automaticamente stringhe come “arstechnica.com” o “mastodon.social” in un URL che, una volta cliccato, conduce un utente al dominio corrispondente. La preoccupazione è che le e-mail e i post sui social media che fanno riferimento a un file come setup.zip o vacation.mov li trasformino automaticamente in link cliccabili e che i truffatori colgano l’ambiguità.

Gli attori delle minacce possono facilmente registrare nomi di dominio che potrebbero essere utilizzati da altre persone per fare casualmente riferimento a nomi di file, ha scritto in una e-mail Randy Pargman, direttore del rilevamento delle minacce presso la società di sicurezza Proofpoint. Possono quindi utilizzare quelle conversazioni che l’autore della minaccia non ha nemmeno dovuto avviare (o partecipare) per indurre le persone a fare clic e scaricare contenuti dannosi.

Annullando anni di consapevolezza anti-phishing e anti-inganno

Un truffatore che detiene il controllo del dominio photos.zip, ad esempio, potrebbe sfruttare l’abitudine decennale delle persone di archiviare una serie di immagini all’interno di un file zip per poi condividerle in un’e-mail o sui social media. Invece di rendere photos.zip come testo in chiaro, cosa che sarebbe accaduta prima del trasferimento di Google, molti siti e app li stanno ora convertendo in un dominio cliccabile. Un utente che pensa di accedere a un archivio fotografico di qualcuno che conosce potrebbe invece essere indirizzato a un sito Web creato da truffatori.

I truffatori potrebbero facilmente configurarlo per fornire un download di file zip ogni volta che qualcuno visita la pagina e includere qualsiasi contenuto desiderino nel file zip, come malware”, ha affermato Pargman.

Diversi siti di nuova creazione dimostrano come potrebbe essere questo gioco di prestigio. Tra questi ci sono setup.zip e steaminstaller.zip, che utilizzano nomi di dominio che comunemente fanno riferimento alle convenzioni di denominazione per i file di installazione. Particolarmente toccante è clientdocs.zip, un sito che scarica automaticamente uno script bash che recita:

#! /bin/bash
echo IAMHAVINGFUNONLINEIAMHAVINGFUNONLINEIAMHAVINGFUNONLINEIAMHAVINGFUNONLINEIAMHAVINGFUNONLINEIAMHAVINGFUNONLINE

Non è difficile immaginare che gli attori delle minacce utilizzino questa tecnica in modi che non sono altrettanto comici.

Il vantaggio per l’autore della minaccia è che non dovevano nemmeno inviare i messaggi per invogliare le potenziali vittime a fare clic sul collegamento: dovevano solo registrare il dominio, configurare il sito Web per servire contenuti dannosi e attendere passivamente che le persone creassero collegamenti accidentalmente. al loro contenuto, ha scritto Pargman. I link sembrano molto più affidabili perché arrivano nel contesto di messaggi o post di un mittente fidato.

Cosa sta facendo questo @ nel mio nome di dominio?

Un altro esempio del potenziale di abuso è arrivato in un recente post del ricercatore sulla sicurezza Bobby Rauch. In esso, ha mostrato come un utente malintenzionato potrebbe utilizzare il TLD .zip per creare un URL dannoso che potrebbe ingannare praticamente chiunque e che sembra quasi identico a quello legittimo che imita. I due URL sono:

https://github.comkuberneteskubernetesarchiverefstags@v1271.zip

E

https://github.com/kubernetes/kubernetes/archive/refs/tags/v1.27.1.zip

Il primo porta a https://v1271.zip, che, se utilizzato da un vero utente malintenzionato che ha impiegato del tempo per registrare il dominio, potrebbe consegnare un file .exe dannoso. Sebbene il secondo URL sembri quasi identico, scarica un file zip Kubernetes legittimo dal repository GitHub ufficiale per quel software open source.

Il trucco di Rauch sfrutta un dominio .zip combinandolo con l’operatore @ e il carattere Unicode (U+2215) per creare un URL che porta al sito teorico dannoso.

Ecco come: all’insaputa di molti, tutto ciò che si trova tra https:// e l’operatore @ in un nome di dominio viene trattato come informazione dell’utente, mentre tutto ciò che segue l’operatore @ viene trattato come un nome host. Uno dei motivi per cui questa distinzione sfugge alla maggior parte delle persone è che molti browser, tra cui Chrome, Safari e Edge, non agiscono sui caratteri nella sezione delle informazioni utente del nome di dominio e indirizzano invece l’utente alla parte del nome host.

Questa convenzione porta a risultati controintuitivi. L’URL https://google.com@bing.com, ad esempio, porta effettivamente a bing.com. Come se le cose non fossero abbastanza confuse, inserendo una barra prima dell’operatore @ nello stesso URL, ad esempio, https://google.com/search@bing.com porterà a google.com (l’errore 404 si verifica perché il percorso / search@bing.com non esiste su google.com). Questi URL portano a domini diversi perché i browser analizzano tutto ciò che segue la barra come percorso.

Diventa ancora più complicato. Un bug di Chromium noto dal 2016 consente a due caratteri Unicode che sembrano quasi identici alla barra U+2044 () e U+2215 () di essere presenti in un URL senza alterare il modo in cui il browser lo interpreta. Di conseguenza, mentre https://google.com/search@bing.com (con una normale barra) porta alla pagina 404 su google.comcome abbiamo visto sopra, sostituire la normale barra con uno dei caratteri Unicode simili porta al Bing pagina iniziale.

La pagina Kubernetes dannosa che porta all’URL .zip teoricamente dannoso è identica alla vera pagina Kubernetes su GitHub con una distinzione quasi impercettibile: le barre che seguono https:// sono state sostituite con caratteri Unicode. Il post di Rauch continua mostrando come la manipolazione dell’operatore @ nell’URL, cambiando specificatamente la sua dimensione in un carattere di dimensione 1, possa rendere gli URL dannosi ancora più convincenti.

Non credo .zip o .mov [top-level] i domini aprono necessariamente qualsiasi nuovo o nuovo vettore di attacco, ma certamente possono rendere più facile il lavoro di un attore di minacce, ha scritto Rauch in un’intervista online. Il TLD .mov può essere sfruttato allo stesso modo del TLD .zip.

Lui continuò:

In un contesto aziendale, supponiamo che venga diffuso un file video .mov che descrive in dettaglio come i dipendenti possono utilizzare un nuovo software di contabilità. Ricevi un’e-mail da qualcuno della tua azienda contenente il seguente link per guardare il video tutorial su Dropbox. Lo clicchi?

Ha quindi fornito due URL:

https://www.dropbox[.]coms6lv9fph03m2boen@tutorial.mov

E

https://www.dropbox[.]com/s/6lv9fph03m2boen/@tutorial.mov

Sebbene sembrino quasi identici, il primo può potenzialmente fornire malware, mentre il secondo porta a un account Dropbox legittimo che ospita un video.

Ci sono cose che possono succedere

I rappresentanti di Google hanno difeso l’uso da parte dell’azienda dei TLD .zip e .mov in una dichiarazione in cui si afferma che la società monitorerà l’utilizzo dei nuovi TLD per eventuali nuove minacce che potrebbero rappresentare. La società ha fornito un paio di motivi per cui i suoi nuovi TLD sono sicuri. Uno è che qualsiasi abuso sarà tenuto sotto controllo da mitigazioni del browser come Google Safe Browsing, che avvisa gli utenti quando tentano di navigare su un sito Web dannoso o di scaricare file dannosi.

La dichiarazione ha anche rilevato che la potenziale confusione si è verificata quando il conglomerato statunitense 3M ha acquisito il nome di dominio command.com, il nome di un importante programma su MS-DOS e le prime versioni di Windows. La dichiarazione di Google ha sorvolato sul fatto, tuttavia, che command.com è un singolo nome di dominio, mentre i TLD .zip e .mov hanno il potenziale per essere apposti su centinaia di migliaia o addirittura milioni di nomi di dominio.

Google ha tecnicamente ragione sul fatto che preoccupazioni simili sui TLD non sono nuove. Più di un decennio fa, la Internet Corporation for Assigned Names and Numbers, l’organismo che sovrintende ai nomi di dominio, ha approvato una misura che consente a chiunque di presentare domande per praticamente qualsiasi TLD. La mossa ha alimentato la preoccupazione che gli attori delle minacce possano compromettere gravemente la sicurezza e la stabilità di Internet, ad esempio ottenendo TLD come .domain, .mailserver, .lan e .local, che entrerebbero in collisione con nomi di server ampiamente utilizzati all’interno reti locali.

Quei timori non si sono mai concretizzati non perché non fossero validi, ma perché nessuno di quei nomi è mai stato utilizzato nei TLD disponibili. Nel 2016, ICANN ha rifiutato affermativamente le domande di TLD che richiedevano .corp, .home e .mail. Inoltre, l’Internet Assigned Numbers Authority ha vietato anche i TLD .example, .invalid, .local, .localhost, .onion e .test.

Sebbene la dichiarazione di Google mirasse a dimostrare che le preoccupazioni sulla confusione dei TLD non sono nuove, non ha riconosciuto che la restrizione dei TLD per tali motivi è un precedente consolidato che il suo uso di .zip e .mov sembra andare contro.

[Update, May 19: An ICANN technologist, meanwhile, said that .zip and .mov didn’t meet the same threshold that was used when restricting the use of .corp, .localhost, and the other TLDs that have been reserved. All of those were were what he called “collisions.”

“A Collision is when you enter a domain name into your own computer that has a TLD that somehow is local to you that is also now in the global DNS,” ICANN Distinguished Technologist Paul Hoffman said in an interview, referring to the domain name system, a hierarchical database of domain names. He said .corp is the “canonical example” because Microsoft encourages network administrators to use it when setting up Active Directory. He said the .zip and .mov TLDs are entirely different.

“Youre talking about file extensions. No one types file names into their location bar. Therefore, it’s not a collision. Its confusing. There are some things that can happen,” Hoffman said. “Im not saying that theres no problem, but the fact that this jumps over the boundary between I think this is a domain name and I think this is a filename is quite large.”]

Dove andare da qui?

A partire da giovedì, c’erano 2.753 domini che terminavano in .zip, secondo Johannes Ullrich, decano della ricerca presso il SANS Institute. Di questi, Ullrich ne ha identificati solo due sospetti, il che significa che erano potenzialmente dannosi. Un dominio, fermwartung[.]zip (“Fernwartung” è la parola tedesca per manutenzione remota), diretto a quello che sembrava un sito Web aziendale legittimo ma che scaricava un file che, secondo VirusTotal, era stato contrassegnato come malware dalla società di sicurezza Dr.Web.

Gli altri sono stati parcheggiati, ovvero sono stati prenotati ma i siti non sono stati ancora configurati o hanno generato errori o hanno avuto comportamenti sconosciuti. Quarantotto dei domini sono diretti alla canzone di Rick Astley “Never Gonna Give You Up”, uno scherzo noto come “rickrolling” che i ricercatori usano spesso per dimostrare la capacità di compromettere un utente finale.

Ora che i nuovi TLD di Google sono disponibili, gli ingegneri che sovrintendono alle convenzioni sui nomi di dominio stanno discutendo su cosa fare dopo. Uno di questi ingegneri ha recentemente richiesto che .zip e .mov vengano rimossi dall’elenco dei suffissi pubblici (PSL), un elenco leggibile da computer gestito dalla comunità di tutti i suffissi pubblici DNS noti e delle relative regole. Lo scopo del PSL è aiutare a garantire che i browser e altre applicazioni elaborino i nomi di dominio in un modo che promuova la sicurezza e la stabilità di Internet.

Questi TLD non sono sicuri per essere sul PSL a causa della loro natura ingannevole, ha scritto l’ingegnere. PoC [proofs of concept] stanno emergendo e le organizzazioni stanno bloccando questi TLD.

Diversi ingegneri che hanno risposto si sono opposti alla proposta, principalmente sulla base del fatto che la rimozione dei TLD approvati dall’ICANN creerebbe instabilità e andrebbe contro lo scopo del PSL. Alla fine, il poster originale cedette.

Le mie critiche vanno a Google, che non ha fornito vantaggi tecnici sostanziali di questi nuovi TLD, quindi possiamo solo concludere che l’incentivo è il denaro; e la community ha dimostrato diversi nuovi rischi e minacce PoC che ora dobbiamo affrontare, ha scritto l’ingegnere, aggiungendo: rischioso da usare.