Ogni qualvolta una nuova vulnerabilità viene fuori e inizia a inondare i news feed di sistemisti e DevOps, la prima domanda a cui si tenta di dar risposta è: siamo vulnerabili anche noi?
Per verificare proprio questo e verificare se l’exploit funzionerebbe anche sulla nostra macchina nel caso venissimo attaccati, è facile reperire del codice open-source che abbia come unico scopo l’eseguire un breve test, simulando l’attacco per verificare se siamo vulnerabili anche noi, senza però portarlo a termine. Insomma, una ‘prova concettuale’, da cui il nome proof of concept (PoC) exploits con cui sono conosciuti.
Come si può già intuire, sebbene si tratti di codice open-source (chi, altrimenti, si sognerebbe di eseguirli?), essi sono raramente sottoposti a scrutinio approfondito per verificare cosa faccia realmente il codice, prima di eseguirlo. Ancor più raro è possedere l’arguzia tecnica di notare delle istruzioni malevole abilmente nascoste e offuscate e discernerle dal codice che serve per simulare l’attacco.
Insomma, avete capito: quale posto migliore per nascondere del malware? Tale codice è spesso eseguito per motivi di studio ma anche di hardening in loco da parte di sistemisti.
Come s’intuisce, un malware eseguito in queste circostanze avrebbe esiti abbastanza preoccupanti, sia perché potrebbe infettare le stesse macchine che si cercava di perfezionare, magari anche in produzione, sia perché l’operatore addetto a tali verifiche potrebbe avere accesso a parecchie macchine di parecchi clienti.
Sebbene non sia un concetto nuovo e, come ci si augura, la maggior parte di chi lavora nel settore IT abbia già coltivato una naturale, salutare paranoia, un’occasione del genere non poteva passare inosservata ai cyber criminali che non hanno mancato di voler comunque tentare la sorte, visto il grosso potenziale danno.
Secondo uno studio del Leiden Institute of Advanced Computer Science, infatti, una fetta non trascurabile di repository GitHub contenenti le proof-of-concept di exploit appena discusse contengano anche del malware. Il paper, attualmente consultabile in preprint su arXiv, descrive uno studio svolto dal 2017 al 2021 su 47,300 repository e, sembra, intorno al 10% di questi conteneva del malware e\o tentava di contattare indirizzi IP presenti sulle maggiori blocklist in quanto già segnalati per utilizzi impropri.
Stiamo parlando di un range di minacce che spazia dall’innocuo (ma pur sempre del codice diverso da quello che ci aspettavamo di eseguire) a dei veri propri trojan per il controllo remoto delle macchine infette.
Ricordiamo che, purtroppo, è possibile ritrovarsi del codice offuscato anche dentro una singola stringa in base64 e la situazione si complica se, per qualche ragione, nel repository abbiamo degli eseguibili binari parte del test, i quali sono ancor più impervi a uno scrutinio pre-esecuzione.
Eseguire il binario in una macchina virtuale e darlo in pasto a VirusTotal sono delle opzioni sicuramente migliori dell’esecuzione alla cieca, tuttavia non si tratta di metodi sicuri al 100% e, pertanto, non rimane che prestare la massima attenzione e limitare l’esecuzione di codice esterno ai minimi termini, se non eliminarla del tutto in tutti quei casi in cui non si riesca a verificare il codice che stiamo eseguendo nella sua interezza.
English (US)