Il modo in cui viene introdotto il codice dannoso continua ad evolversi riprendendo i vecchi metodi e migliorando il modo in cui le vittime vengono ingannate.
Sembra che l'idea del cavallo di Troia è ancora abbastanza utile oggi e in modi così sottili che molti di noi possono passare inosservati e recentemente ricercatori dell'Università di Leiden (Paesi Bassi) ha studiato il problema della pubblicazione di prototipi di exploit fittizi su GitHub.
L'idea di usa questi per essere in grado di attaccare gli utenti curiosi chi vuole testare e imparare come alcune vulnerabilità possono essere sfruttate con gli strumenti offerti, rende questo tipo di situazione ideale per introdurre codice dannoso per attaccare gli utenti.
È stato riferito che nello studio Sono stati analizzati un totale di 47.313 repository di exploit, coprendo le vulnerabilità note identificate dal 2017 al 2021. L'analisi degli exploit ha mostrato che 4893 (10,3%) di esse contengono codice che esegue azioni dannose.
Ecco perché si consiglia agli utenti che decidono di utilizzare exploit pubblicati di esaminarli prima cercare inserti sospetti ed eseguire exploit solo su macchine virtuali isolate dal sistema principale.
Gli exploit Proof of Concept (PoC) per vulnerabilità note sono ampiamente condivisi nella comunità della sicurezza. Aiutano gli analisti della sicurezza a imparare gli uni dagli altri e facilitano le valutazioni della sicurezza e il teaming di rete.
Negli ultimi anni, è diventato molto popolare distribuire i PoC, ad esempio attraverso siti Web e piattaforme, e anche tramite repository di codice pubblico come GitHub. Tuttavia, i repository di codice pubblico non forniscono alcuna garanzia che un determinato PoC provenga da una fonte attendibile o addirittura che faccia esattamente ciò che dovrebbe fare.
In questo documento, esaminiamo i PoC condivisi su GitHub per le vulnerabilità note scoperte nel 2017-2021. Abbiamo scoperto che non tutti i PoC sono affidabili.
Sul problema sono state identificate due categorie principali di exploit dannosi: exploit che contengono codice dannoso, ad esempio per eseguire il backdoor del sistema, scaricare un Trojan o collegare una macchina a una botnet, e exploit che raccolgono e inviano informazioni riservate sull'utente.
Inoltre, è stata inoltre identificata una classe separata di falsi exploit innocui che non eseguono azioni dannose, ma non contengono nemmeno la funzionalità prevista, ad esempio, progettato per ingannare o avvisare gli utenti che eseguono codice non verificato dalla rete.
Alcune prove di concetto sono fasulle (cioè in realtà non offrono funzionalità PoC) o
anche dannosi: ad esempio, tentano di esfiltrare i dati dal sistema su cui sono in esecuzione o tentano di installare malware su quel sistema.Per risolvere questo problema, abbiamo proposto un approccio per rilevare se un PoC è dannoso. Il nostro approccio si basa sul rilevamento dei sintomi che abbiamo osservato nel set di dati raccolto, per
ad esempio, chiamate a indirizzi IP dannosi, codice crittografato o binari trojan inclusi.Utilizzando questo approccio, abbiamo scoperto 4893 repository dannosi su 47313
repository che sono stati scaricati e verificati (ovvero, il 10,3% dei repository studiati presenta codice dannoso). Questa cifra mostra una preoccupante prevalenza di PoC dannosi pericolosi tra il codice exploit distribuito su GitHub.
Sono stati utilizzati vari controlli per rilevare exploit dannosi:
- Il codice exploit è stato analizzato per la presenza di indirizzi IP pubblici cablati, dopodiché gli indirizzi identificati sono stati ulteriormente verificati rispetto ai database degli host inseriti nella lista nera utilizzati per controllare le botnet e distribuire file dannosi.
- Gli exploit forniti in forma compilata sono stati verificati con software antivirus.
- Nel codice è stata rilevata la presenza di dump esadecimali atipici o inserimenti in formato base64, dopodiché tali inserimenti sono stati decodificati e studiati.
Si consiglia inoltre agli utenti a cui piace eseguire i test da soli, prendere in primo piano fonti come Exploit-DB, poiché cercano di convalidare l'efficacia e la legittimità dei PoC. Poiché, al contrario, il codice pubblico su piattaforme come GitHub non ha il processo di verifica degli exploit.
Infine se sei interessato a saperne di più, puoi consultare i dettagli dello studio nel seguente fascicolo, dal quale tu Condivido il tuo link.