Red Hot Cyber
La cybersecurity è condivisione.
Riconosci il rischio, combattilo, condividi le tue esperienze ed
incentiva gli altri a fare meglio di te.
Menu
La cybersecurity è condivisione.
Riconosci il rischio, combattilo, condividi le tue esperienze ed
incentiva gli altri a fare meglio di te.
Redazione RHC : 27 Aprile 2021 08:00
Lo sappiamo, l’asimmetria tra “bene e male” sta crescendo a ritmi frenetici di anno in anno, questo è stato confermato dagli attacchi Solarwinds e gli zeroday di Exchange, ma anche dai ransomware che risultano sempre più sofisticati, capaci di violare organizzazioni di ogni ordine e grado.
Nel mentre troviamo i Blue Team e i Red Team, che cercano affannosamente di fare tutto il possibile con le loro spesso esigue forze, per poter ostacolare l’accesso alle reti ai criminali informatici, effettuando (nel caso delle più virtuose) ricerche sui bug non documentati, tentando di stare un passo avanti ai loro aggressori e avere un piccolo vantaggio per proteggere al meglio le loro organizzazioni.
Supporta Red Hot Cyber attraverso
Ma trovare e sfruttare un bug (definendo una PoC di sfruttamento) può richiedere da un paio d’ore (nel caso di semplici XSS o SQL injection), a diversi mesi o più, nel caso di bug particolari come i Side Channel Attack oppure vulnerabilità su protocolli particolarmente sicuri.
Alcuni aggressori utilizzano metodi collaudati, ma i più creativi trovano modi alternativi per sfruttare i sistemi attraverso vettori di attacco inaspettati.
I team di ricerca, per prima cosa devono comprendere quale parte analizzare rispetto alla complessiva superficie di attacco di un sistema, per poi avviare una serie di test mirati in modo empirico o strutturato, capaci di rilevare potenziali vulnerabilità non documentate su uno specifico prodotto testato in laboratorio.
Come sempre, occorre ispirarci al “male”, per essere i migliori, pertanto i malintenzionati che cercano vulnerabilità zeroday, generalmente sfruttano dei metodi consolidati che possiamo sintetizzare in questo articolo, che possiamo utilizzare a nostro vantaggio.
Ogni software, in particolare quelli di larga diffusione, che hanno versioni stabili e non aggiornate da tempo, sono state analizzate da una flotta di ricercatori assetati di zeroday prima di te. Generalmente tutti i bug scoperti saranno di livello basso e medio (in termini di difficoltà di analisi), pertanto potresti optare per avviare una ricerca su bug complessi che potrebbero portarti ad un nulla di fatto su quello specifico prodotto, oltre che farti perdere molto tempo.
Invece tutte quelle parti software recentemente aggiornate (eseguibili, librerie, firmware ecc…), sono un ottimo spunto per avviare una ricerca che potrebbe ricompensarti ampiamente sia in termini di bug bounty (qualora il vendor ne adotti uno) oppure di reputation.
E’ tutta una questione di tempo. Pertanto se sei intenzionato ad analizzare i bug di sicurezza di una applicazione particolarmente diffusa, segui con minuzia gli aggiornamenti e le librerie ricompilate (comprendine le parti aggiornate) e non appena vengono distribuite, avvia la tua ricerca.
Fai attenzione che siccome molti ricercatori adottano la tua stessa strategia, potresti in alcuni casi lavorare a vuoto in quanto il vendor del prodotto potrebbe dirti, dopo aver inviato il tuo bel “report di disclosure”, che quel bug era stato scoperto da un altro ricercatore 4 giorni prima e che la fix è quasi pronta al rilascio.
Una tra le prime cose da fare è un controllo incrociato tra software e vulnerabilità come punto di partenza. Pertanto cerca tutte quelle vulnerabilità “documentate”, ad esempio i CVE ad alta gravità (le famose Remote Code Execution) in modo da analizzarli e comprendere quale bug software e quali PoC sono state rilasciate, tutto questo per capire con previsione lo strato software dove sono state isolate.
I CVE noti, sono ottimi spunti per scoprire nuovi bug simili introdotti da errori di programmazione fatti dal singolo sviluppatore, che si nascondono all’interno del codice.
Pensa al ciclo di vita dello sviluppo del software. Le basi dell’OOP chiedono espressamente il riutilizzo del codice tra progetti, pertanto questo potrebbe essere un buon punto di partenza.
Quindi se è stato rilevato uno zeroday su una specifica funzionalità, su una libreria o su una classe di codice che è stata fixata, la stessa (o una sua variante) potrebbe essere contenuta in analoghi strati software di altri prodotti rilasciati dalla stessa azienda e questo può essere un interessante spunto di ricerca.
Leggere il codice sorgente (ad esempio il codice open-source di un prodotto o il reverse engineering di un binario) può essere un po’ come scoprire una mappa del tesoro.
Spesso proprio nei commenti si trovano informazioni straordinariamente importanti, soprattutto quando il codice è stato ben documentato.
Durante la creazione del software, gli sviluppatori commentano il codice e quelli più bravi lo commentano davvero bene, in quanto sono convinti che le descrizioni in linguaggio naturale possano aiutarli una volta che ritornano su una specifica classe o blocco di codice dopo diverso tempo. E proprio nei commenti che si possono trovare delle informazioni molto utili, come i commenti su blocchi di codice fixati che prima contenevano bug software e bug di sicurezza risolti.
Commenti come “FIXME” o “RBF” (remove before flight) oppure “BUG” e “vulnerability” (e tutto quello che vi viene in mente per isolare un buon commento a contorno di un bug), sono ottimi spunti da dove cominciare per rilevare le vecchie vulnerabilità e comprendere come effettuarne un ulteriore bypass, il che risulta più semplice avendo dotto mano l’intero codice.
Tag come questi all’interno del codice, devono far aumentare l’attenzione, perché proprio in quella zona del codice, potrebbe essere presenti un bug risolto, non risolto o risolto male e quindi sfruttabile per i nostri scopi.
Le revisioni del codice sono difficili da fare bene. Soprattutto quando non sai bene cosa cercare. Nel caso in cui sai cosa cercare, ecco che entrano in azione diverse metodologie (che non descriveremo in questo articolo) che permettono di aiutare il ricercatore nella revisione del codice fino ad arrivare a scoprire i bug non risolti.
Una buona revisione del codice utilizza una combinazione tra tecniche automatizzate quali SAST e DAST e attività manuali di analisi, concentrandosi su sette aree di sicurezza.
Una debolezza su queste sette aree, può introdurre vulnerabilità che un utente malintenzionato può sfruttare e abusarne in una fase di attacco.
Spesso è possibile effettuare una analisi preliminare del prodotto, accedendo ai forum di supporto per comprendere se ci sono dei team di sviluppo che parlano di specifici bug (non solo di sicurezza) o di problematiche non risolte su quello specifico prodotto.
Magari anche su richieste di supporto su una determinata fix di sicurezza già risolta, oppure su problematiche intercorse nella risoluzione di un bug ancora non risolti, non necessariamente di sicurezza.
Spesso i forum di supporto dei prodotti, danno informazioni molto utili per poter successivamente condurre delle analisi mirate all’interno del software ed isolare ulteriori bug.
IL Fuzzing, come abbiamo riportato su Red Hot Cyber, è lo strumento chiave per il bug hunter.
Si tratta di una tecnica che consente di rilevare bug che porta ottimi frutti in ambiente di laboratorio, cosa che però in ambiente di produzione e nelle attività di ethical-hacking, può portarti ad arrecare danni al sistema da anlizzare, oltre a farti riconoscere dal blue-team, costantemente in ascolto sulla superfice di attacco da te aggredita.
Il fuzzing è una tecnica sofisticata utilizzata dai ricercatori professionisti, che consente attraverso l’utilizzo di prodotti che inviano richieste malformate ad un software, di analizzare il suo comportamento con l’obiettivo di indurlo in errore.
Questo avviene iniettando dati non validi, imprevisti o semi-casuali in un’interfaccia o programma e quindi monitorando gli eventi come gli arresti anomali, salti non documentati per eseguire il debug di una routine, asserzioni di codice non riuscite e potenziali perdite di memoria.
Questo processo aiuta sviluppatori e ricercatori a trovare bug e vulnerabilità zero-day che altrimenti sarebbero quasi impossibili da scoprire e il team di Google project-zero al Black Hat USA del 2014 riportò più della metà (54,2%) dei bug scoperti da Project Zero sono manuali, ad esempio, trovate durante la revisione del codice sorgente, mentre il 37,2% delle vulnerabilità sono rilevate attraverso l’utilizzo del Fuzzing.
Pertanto se volete veramente fare il cambio di passo, studiate il fuzzing.
Conclusioni
Sicuramente la ricerca dei bug non documentati, sta diventando sempre più una attività importante, soprattutto per quelle aziende che vogliono stare un passo avanti al crimine informatico. Ad oggi non esistono diffuse best-practices in materia, ma piano piano delle “golden rules” si iniziano ad intravedere.
RedazioneRedazione: [email protected]
© Copyright RED HOT CYBER. PIVA 16821691009
