{"id":22675,"date":"2020-08-31T16:28:05","date_gmt":"2020-08-31T14:28:05","guid":{"rendered":"https:\/\/www.kaspersky.it\/blog\/?p=22675"},"modified":"2020-08-31T16:28:05","modified_gmt":"2020-08-31T14:28:05","slug":"black-hat-macos-macros-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.it\/blog\/black-hat-macos-macros-attack\/22675\/","title":{"rendered":"Come eseguire macro dannose senza lasciare traccia su macOS"},"content":{"rendered":"

Molti utenti di computer macOS sono ancora convinti che i propri dispositivi non abbiano bisogno di protezione. O ancor peggio, gli amministratori di sistema delle aziende i cui i dipendenti lavorano su hardware Apple spesso la pensano allo stesso modo.<\/p>\n

Alla conferenza Black Hat USA 2020<\/a>, il ricercatore Patrick Wardle ha provato ad aprire gli occhi al pubblico presentando la sua analisi dei malware per macOS e costruendo una catena di exploit per prendere il controllo di un computer Apple.<\/p>\n

Microsoft, macro e Mac<\/h2>\n

Uno dei modi pi\u00f9 comuni per attaccare i computer che eseguono macOS \u00e8 attraverso documenti con macro dannose, cio\u00e8 attraverso le applicazioni di Microsoft Office. Infatti, nonostante la disponibilit\u00e0 delle app di produttivit\u00e0 Apple, molti utenti preferiscono utilizzare Microsoft Office. Alcuni lo fanno per abitudine, altri per motivi di compatibilit\u00e0 con i documenti creati dai loro colleghi.<\/p>\n

Naturalmente, tutti sono a conoscenza da tempo della potenziale minaccia rappresentata dai documenti contenenti macro. Pertanto, sia Microsoft, sia Apple dispongono di meccanismi per proteggere l\u2019utente.<\/p>\n

Microsoft avvisa gli utenti quando aprono un documento che contiene una macro. Inoltre, se l\u2019utente decide di proseguire comunque, il codice viene eseguito in una sandbox, il che, secondo gli sviluppatori di Microsoft, impedisce al codice di accedere ai file dell\u2019utente o di causare altri danni al sistema.<\/p>\n

Da parte di Apple, l\u2019azienda ha introdotto diverse nuove funzioni di sicurezza nell\u2019ultima versione del suo sistema operativo, macOS Catalina. In particolare, queste includono la quarantena dei file e la \u201cnotarizzazione\u201d, che \u00e8 una tecnologia che impedisce il lancio di file eseguibili da fonti esterne.<\/p>\n

Fondamentalmente, queste tecnologie insieme dovrebbero essere sufficienti a prevenire qualsiasi danno da macro dannose. In teoria, tutto sembra abbastanza sicuro.<\/p>\n\n

Una catena di exploit fa uscire la macro dalla sandbox<\/h2>\n

In pratica, per\u00f2, molti meccanismi di sicurezza sono implementati in modo piuttosto problematico. Pertanto, i ricercatori (o i cybercriminali) possono potenzialmente trovare metodi per aggirarli. Wardle ce lo ha dimostrato grazie a una catena di exploit.<\/p>\n

1. Aggirare il meccanismo che disattiva le macro<\/h3>\n

Prendiamo, ad esempio, il sistema che avverte l\u2019utente quando rileva una macro in un documento. Nella maggior parte dei casi, funziona come previsto dagli sviluppatori. Allo stesso tempo, per\u00f2, \u00e8 possibile creare un documento in cui la macro si avvia automaticamente e senza alcuna notifica all\u2019utente, anche se le macro sono state disattivate nelle impostazioni.<\/p>\n

Questo pu\u00f2 essere fatto utilizzando il formato di file Sylk<\/a> (SLK). Il formato, che utilizza il linguaggio macro XLM, \u00e8 stato sviluppato negli anni \u201980 ed \u00e8 stato aggiornato per l\u2019ultima volta nel 1986. Tuttavia, le applicazioni Microsoft (ad es. Excel) supportano ancora Sylk per ragioni di retro-compatibilit\u00e0. Questa vulnerabilit\u00e0 non \u00e8 nuova ed \u00e8 stata descritta in dettaglio<\/a> gi\u00e0 nel 2019.<\/p>\n

2. Fuga dalla sandbox<\/h3>\n

Come abbiamo potuto appurare, un cybercriminale pu\u00f2 eseguire una macro senza lasciare traccia. Ma il codice viene comunque eseguito all\u2019interno della sandbox isolata di MS Office. Come pu\u00f2 un criminale informatico attaccare il computer? Beh, a quanto pare non \u00e8 molto difficile sfuggire alla sandbox di Microsoft su un Mac.<\/p>\n

\u00c8 vero che non \u00e8 possibile modificare i file gi\u00e0 memorizzati sul computer dall\u2019interno della sandbox. Tuttavia, \u00e8 possibile crearli<\/em>. Questo exploit \u00e8 gi\u00e0 stato utilizzato in precedenza per uscire dalla sandbox e sembra che Microsoft abbia rilasciato un aggiornamento per questa vulnerabilit\u00e0. Tuttavia, il problema non \u00e8 stato realmente risolto, come dimostrato da un esame pi\u00f9 dettagliato della patch: la correzione ne ha affrontato i sintomi, bloccando la creazione di file dall\u2019interno di ubicazioni che alcuni sviluppatori ritenevano non sicuri, come ad esempio nella cartella LaunchAgents, dove vengono custoditi gli script che vengono lanciati automaticamente dopo un riavvio.<\/p>\n

Ma davvero Microsoft ha tenuto conto di ogni \u201cubicazione pericolosa\u201d durante la creazione della patch? Come \u00e8 successo, uno script scritto su Python e lanciato da un documento di Office, e quindi eseguito all\u2019interno di una sandbox, poteva essere usato per creare un oggetto chiamato \u201cLogin Item\u201d. Un oggetto con quel nome si lancia automaticamente quando l\u2019utente effettua il login nel sistema. Il sistema lancia l\u2019oggetto, che verr\u00e0 eseguito fuori<\/em>\u00a0dalla sandbox di Office e quindi aggirer\u00e0 le restrizioni di sicurezza di Microsoft.<\/p>\n

3. Aggirare i meccanismi di sicurezza Apple<\/h3>\n

Quindi, ora sappiamo come eseguire segretamente una macro e creare un oggetto Login Item. Naturalmente, i meccanismi di sicurezza di macOS impediscono ancora il ll\u2019esecuzione della backdoor che, essendo stata creata da un processo non sicuro dall\u2019interno della sandbox, non \u00e8 affidabile, vero?<\/p>\n

Da un lato, \u00e8 vero: i meccanismi di sicurezza Apple bloccano infatti l\u2019esecuzione del codice ottenuto in questo modo. Dall\u2019altro lato, per\u00f2,c\u2019\u00e8 una soluzione per aggirare il problema: se si inserisce un archivio ZIP come Login Item, al prossimo login il sistema decomprimer\u00e0 automaticamente il file.<\/p>\n

Al cybercriminale non resta che scegliere la posizione giusta per decomprimere il file. Ad esempio, l\u2019archivio pu\u00f2 essere collocato nella stessa directory delle librerie degli utenti, un gradino sopra quella in cui si suppone che siano memorizzati gli oggetti di tipo Launch Agent (quelli che Microsoft considera giustamente pericolosi). L\u2019archivio stesso pu\u00f2 includere una directory chiamata LaunchAgents, contenente lo script Launch Agent.<\/p>\n

Una volta decompresso, lo script viene posizionato nella cartella LaunchAgents per essere eseguito al riavvio. Essendo stato creato da un programma di fiducia (Archiver) e non avendo gli attributi di quarantena, pu\u00f2 essere usato per eseguire qualcosa di pi\u00f9 pericoloso. I meccanismi di sicurezza non impediranno nemmeno l\u2019avvio di questo file.<\/p>\n

Di conseguenza, un cybercriminale pu\u00f2 eseguire un meccanismo attraverso la shell di comando Bash per ottenere l\u2019accesso remoto (ottenendo cos\u00ec una cosiddetta shell inversa). Questo processo Bash pu\u00f2 essere utilizzato per scaricare file, che mancheranno anche dell\u2019attributo di quarantena, permettendo ai cybercriminali di scaricare un codice veramente dannoso e di eseguirlo senza alcuna restrizione.<\/p>\n

In sintesi:<\/p>\n