Vi siete mai chiesti come fa Windows a sapere che un certo file lo avete scaricato da Internet? 

L’informazione deve risiedere da qualche parte, altrimenti un file sarebbe esattamente come tutti gli altri, un file locale. 

Ebbene, questa caratterizzazione avviene per mezzo di una funzionalità di sicurezza introdotta con Internet Explorer (ma che è propria di tutti gli altri browser e molti altri software in uso su Windows) e viene rispettata da molti programmi (tutta la suite Office, per esempio, e soprattutto Windows Defender) durante l’apertura del documento scaricato: la funzionalità è comunemente indicata (ma non è un nome ufficiale) Mark-of-the-Web (MOTW) e consente di associare al file scaricato l’origine (quindi anche l’URI) dello stesso. 

Secondo quali siano i tipi di file, il MOTW viene realizzato con strumenti differenti; ad esempio, nei file HTML il MOTW è semplicemente ottenuto aggiungendo (lo fa il browser che esegue il download) un commento HTML nella forma <!—save from url: …. 

Quando il file è di altra natura (es. un eseguibile), il sistema operativo deve venire in aiuto per consentire la “marcatura” del file. In Windows, a partire da Windows 3.1, il filesysem NTFS consente di associare a ciascun file un “flusso alternativo”, ossia la capacità di associare dati aggiuntivi (dunque separati) ai tradizionali dati associati al nome del file, quindi associati senza alterazione dei dati propriamente intesi come file. 

Gli ADS (questo il nome della funzionalità dei flussi alternativi: Alternate Data Stream) non sono dunque una novità per il sistema operativo Windows, e per lungo tempo sono stati posti sotto silenzio dallo stesso che non ne aveva trovato modi di utilizzo. Il MOTW è dunque un utilizzo concreto degli ADS per Windows: viene utilizzato a nostra insaputa e per la nostra sicurezza. Dunque il sistema aggiunge uno stream alternativo, denominato Zone.Identifier in cui aggiunge una ZoneId per identificare l’origine del file (0 = Computer locale, 1 = Intranet locale, 2 = Siti affidabili, 3 = Internet, 4 =Siti con restrizioni). Niente di troppo complicato. 

Naturalmente non tutto è oro quel che luccica. Gli ADS vengono ora sfruttati da sistema per ampliare la sicurezza, ma sono già stati utilizzati in natura per minacciare la stessa sicurezza, proprio per la loro natura di occultare payload malevoli sulle macchine vittime. Ora però anche la natura difensiva vacilla: infatti in natura sono state già viste tecniche per superare questa misura difensiva di Windows, e non (questa volta) per colpa sua. 

La prima tecnica è basata sull’uso di software che non rispettano la propagazione dell’ADS Zone.Identifier: le più comuni sono il client git e 7zip. In entrambi i casi, un eventuale payload malevolo trasportato mediante questi strumenti sul filesystem del sistema non verrebbe segnalato come proveniente da Internet, e non “allerterebbe” gli strumenti di utilizzo relativo (da Office a Defender). 

Un’altra strategia è basata sull’utilizzo di contenitori che non siano in grado di gestire ADS, ossia contenitori basati su altri filesystems come ISO e VHD(X). In questo caso, un payload trasportato mediante ISO (una tecnica già vista in natura), avrebbe facile gioco in quanto Esplora Risorse terrebbe conto sì dell’ADS associato al file ISO scaricato, ma nulla potrebbe rispetto al file/payload al suo intetno, in quanto, posto su un filesystem differente e privo di ADS, non sarebbe in grado di propagare sullo stesso le “considerazioni” di oggetto esterno appartenenti al contenitore, consentendo un utilizzo del file/payload (apertura, esecuzione, ecc) come se fosse un comune file locale. 

Un’altra tecnica vista in natura è l’adozione di strategie di social engineering per indurre la vittima a rimuovere le restrizioni che derivino dall’ADS Zone.Identifier: un utente può rimuovere (“Annulla blocco”) lo Zone.Identifier semplicemente leggendo le proprietà del file e apponendo la spunta alla voce Sicurezza nella prima pagina in basso. L’ADS letteralmente viene rimosso e non esiste più traccia della provenienza del file. Una strategia che in qualche misura “cancella le tracce”, niente male. Magari sarebbe opportuno impedire agli utenti finali questa operazione impostando il criterio di gruppo HideZoneInfoOnPropertie. 

Quindi occorre fare molta più attenzione alla strategia di sicurezza, affidandosi a più elementi contemporaneamente, e non solo la protezione dello Zone.Identifier.

Tweet