----- Forwarded message from Alberto Trivero <trivero(at)jumpy.it> ----- From: Alberto Trivero <trivero(at)jumpy.it> To: ml(at)sikurezza.org Subject: Re: [ml] bug research
Il giorno 16/apr/08, alle ore 18:15, break 0x90 ha scritto: > >Sono sempre rimasto affascinato dal reversing in generale, ed ho >iniziato a >muovere i miei primi passi. Sono in grado di comprendere il flusso >di un >listato asm, ho imparato le api fondamentali di windows per l'input >dai >controlli predefiniti ed altre api comunemente usate. Con i crackme >ormai me >la cavo discretamente, almeno con quelli non fantascientifici, >diciamo entry >level. Gi? che ci sono faccio che darti qualche dritta anche in questo campo, magari ti interressa. ;) Ah, tutto il materiale che ti fornir? ? in inglese, spero non sia un problema. Se ti interessa parecchio il tema, questo ? un buon team che si occupa di RCE: http://reteam.org/ Poi qualche altro bel link a papers o libri (sempre materiale abb generico sul tema): http://www.uninformed.org/?v=1&a=7&t=sumry http://www.informit.com/articles/article.aspx?p=353553 http://www.aspfree.com/c/a/Windows-Security/Windows-Reverse-Engineering/ http://www.nologin.org/Downloads/Papers/reveng-memory-analysis.pdf http://www.irmplc.com/content/pdfs/High-Level%20Reverse%20Engineering.pdf http://www.amazon.com/Reversing-Secrets-Engineering-Eldad-Eilam/dp/0764574817 http://www.amazon.com/Reverse-Engineering-Code-IDA-Pro/dp/159749237X/ref=pd_sim_b_title_16 >Mi sono sempre chiesto come si ricercano vulnerabilita' in software >closed >inquanto non e' possibile fare l'auditing dei sorgenti, se non >facendo il >debug. Ora l'idea che mi balza in mente, da perfetto ignorante in >materia, >e' che per trovare una vulnerabilita' in un software closed l'unica >cosa sia >quella di determinare gli input e "provare a riempirli", mi spiego >meglio. >Per ogni textedit provo a incollare una stringa lunghissima e vedo che >succede, oppure un file che "legge" formati compressi, mp3, jpeg, >altro >provo a fare la stessa cosa con gli header o i marcatori, oppure se >e' un >processo server mi attacco con netcat o simili sulla porta su cui e' >in >ascolto e mando pacchetti di grosse dimensioni. In questo caso se >crasha ho >trovato un bug e ripeto l'operazione debuggando il processo sperando >di >capirci qualcosa dentro... >Questo e' quello che ho in mente io... >E' molto lontano dalla verita' ? Per niente, sei proprio sulla strada giusta. ;) >Esistono delle tecniche >piu' specifiche ? Esistono dei pattern da cercare ? Esistono dei >papers che, >magari anche partendo da programmini scritti appositamente in 2 righe, >spieghino come cercare il problema e come sfruttarlo ? Il tema ? vastissimo, cerchiamo di fare una breve panoramica generale. Quando si vogliono fare operazioni di vulnerability discovery su applicazioni di cui non sia ha a disposizione i sorgenti, si ? soliti parlare di testing di tipo black box. L'approccio da te descritto (enumerare tutti i possibili input dell'applicazione e modificarli in modo tale da generare delle exceptions) ? effettivamente uno dei modi pi? noti, comuni e applicati. In particolare si parla di tecniche di fuzzing e fault injection. Un fuzzer ? un'applicazione che permette di automatizzare e velocizzare le operazioni di vulnerability discovery (un fuzzer non ? ovviamente in grado di coprire tutte le possibili vulnerabilit? di un software, ma molte s? (soprattutto quelle legate a overflow dei buffer, format string e diverse vulnerabilit? delle applicazioni web)) inviando a tutti i possibili input dell'applicazione in esame (e sono molti di pi? di quelli che ci si immagina agli inizi) migliaia di dati formattati in modi che notoriamente scatenano una vulnerabilit? (pattern quali: 'A'x65535, %n %n%n, 0xFFFFFFFF, ../../../, etc). E' un metodo a forza bruta un po' stupido ma molto efficace (soprattutto se si ottimizzano i test cases per lo specifico software che si testa, per esempio facendo una GET / HTTP/1........0 o mettendo un Content-Length negativo in un header HTTP). Ricordiamoci per? che stack, heap, off-by-one e integer overflow non sono le uniche vulnerabilit? interessanti. Con tecniche di fuzzing ? anche possibile trovare vulnerabilit? di remote command execution (non esistono solo nelle web applications) oppure pagine critiche senza autenticazione in una web app. Le vulnerabilit? che un fuzzer pu? trovare in una web app (sempre ipotizzando un approccio black box) sono infinite: SQL injections, XSS, path traversal, RFI, SOAP injection, XPath injection, LDAP injection, CSRF, etc.. Come gi? detto in precedenza, un fuzzer non ? in grado di trovare tutti quei tipi di vulnerabilit? del software che necessitano di un'intelligenza artificiale pi? o meno complessa. Per esempio non segnalerebbe se un'applicazione web salva in chiaro su un file senza gli adeguati permessi di accesso le credenziali degli utenti registrati, oppure non segnalerebbe overflow che si presentano solo in seguito ad un input utente ben preciso che il fuzzer non fornisce, eccetera.. Una questione delicata quando si ha a che fare con un fuzzer ? anche risalire con precisione all'input che ha causato un problema nell'applicazione di test. Questo ? quanto, ovviamente, dopo aver trovato la vulnerabilit?, sfruttarla (sempre che sia exploitabile) ? un altro paio di maniche e probabilmente questo tema ? ancora pi? ampio del precedente. :D Ora veniamo a qualche interessante paper e libro (se hai voglia di spendere): https://buildsecurityin.us-cert.gov/daisy/bsi/articles/tools/black-box/261.html https://www.blackhat.com/presentations/bh-europe-07/Luiz_Ramos/Whitepaper/bh-eu-07-luiz_ramos-WP.pdf http://www.securityfocus.com/images/infocus/Wysopal_CH11.pdf http://research.microsoft.com/research/pubs/view.aspx?type=Technical%20Report&id=1300 http://www.fuzzing.org/wp-content/sample_chapter.pdf http://events.ccc.de/congress/2005/fahrplan/attachments/582-paper_fuzzing.pdf http://www.infigo.hr/files/INFIGO-TD-2006-04-01-Fuzzing-eng.pdf http://toorcon.org/2007/talks/60/real_world_fuzzing.pdf http://events.ccc.de/congress/2005/fahrplan/attachments/683-slides_fuzzing.pdf http://www.amazon.com/Fuzzing-Brute-Force-Vulnerability-Discovery/dp/0321446119/ http://www.amazon.com/Open-Source-Fuzzing-Tools-Rathaus/dp/1597491950/ http://www.amazon.com/Art-Software-Security-Assessment-Vulnerabilities/dp/0321444426/ Bene, ne avrai da leggere per un po'.. ;D Come per qualsiasi nuovo tema ci vuole un po' per entrare nell'ordine di idee, non ti fare intimorire. >Fin'ora sono rimasto in silenzio perche' contavo >molto sul corso di sicurezza in universita', ma si sta rivelando >soltanto un >corso accellerato di linux che per quanto possa essere interessante >(e lo e' >!) non soddisfa pero' le mie aspettative in materia. Purtroppo la maggior parte dei corsi universitari di sicurezza informatica si limita a qualche base di crittografia e di sicurezza delle reti. La sicurezza delle applicazioni ? molto trascurata nell'ambito accademico italiano, forse perch? poco conosciuta dai docenti.. (Mica parlo con te Stefano... :P ) Saluti, Alberto Trivero ----- End forwarded message -----
________________________________________________________ http://www.sikurezza.org - Italian Security Mailing List
