Re: [ml] Affidabilita' tool di VA/PT
IMHO tool di VA devono essere lanciati contro tutta l’infrastruttura: produzione, test, ecc. Scegliere solo un ambiente perché si ha il timore di rompere qualcosa non ha molto senso perché chi ti vuole bucare non ti chiede dove preferisci essere attaccato. Magari all’inizio, in fase di valutazione, potrebbe avere senso cominciare dall’ambiente di test per capire cosa succede, ma poi si dovrebbe coprire tutto l’esposto, idealmente sia verso l’interno che verso l’esterno. Per quanto riguarda la scelta del tool, sicuramente è meglio affidarsi a tool consolidati: i tool di VA si limitano a raschiare la superficie, se si scelgono tool “beta” o poco supportati l'elevato falso senso di sicurezza è assolutamente controproducente. E se un tool qualsiasi sfascia un prodotto in produzione forse è meglio sostituirlo quel prodotto… My $.02 Gerardo > On Mar 17, 2018, at 1:59 AM, h...@libero.it wrote: > > Se lavori in ambito enterprise e sono scansioni interne, quindi non eseguite > da terze parti per cui ci sarebbe tutta una trafila diversa ad esempio > banalmente di firme per nda e altro, fatte per validare ambienti sviluppati > in casa o acquistati da fornitori esterni la best practice minima sarebbe di > lanciare i tools verso ambienti di collaudo / sviluppo. > > Per inciso ricordo ancora il lancio da parte di uno sviluppatore di uno scan > acunetix verso la nuova release del prodotto software fatta in produzione, > santo rman di oracle. > >> Il 15 settembre 2017 alle 8.44 ED ha scritto: >> >> >> Un articolo di ieri relativo all'ennesima shell PHP con annessa backdoor >> [1], ha rafforzato i miei timori sull'uso di tool poco conosciuti >> durante i test di sicurezza verso ambienti di produzione. >> >> Lavoro in un ambiente "enterprise", in cui mi limito ad usare tool >> commerciali di grosse case o open source rinomati (Nmap, Nikto ecc). >> Salvo rare eccezioni, i tool poco conosciuti che vanno oltre la mia >> capacita' di analisi (es. script ExploitDB con blob binari, framework >> PowerShell che nascono e muoiono come meteore) sono esclusi, >> specialmente se necessitano di privilegi local elevati o di credenziali >> sull'obiettivo. Non avendo io tempo e competenze per scrivere exploit, >> cio' naturalmente limita di molto i risultati. >> >> Come fate voi? Qual'e' il confine fra un tool sicuro ed uno pericoloso? >> Dipende dall'obiettivo? Che precauzioni prendete quando eseguite tool >> nuovi? Sono mai state formalizzate best practice a riguardo? >> >> Saluti >> ED >> >> >> [1] >> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fisc.sans.edu%2Fforums%2Fdiary%2FAnother%2Bwebshell%2Banother%2Bbackdoor%2F22826%2F&data=02%7C01%7C%7C322428deb128417aa66c08d58ce48877%7C84df9e7fe9f640afb435%7C1%7C0%7C636569835516193246&sdata=h9FBMlbmFd16ahhPqkmVvplKv2vZBJCrdv5zH1pK2PU%3D&reserved=0 >> >> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sikurezza.org&data=02%7C01%7C%7C322428deb128417aa66c08d58ce48877%7C84df9e7fe9f640afb435%7C1%7C0%7C636569835516193246&sdata=sweDk5MkHoQxTMyqs%2BNRsfFn1LR0TkD3Gve%2BF7ZO7Ks%3D&reserved=0 >> - Italian Security Mailing List >> > > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sikurezza.org&data=02%7C01%7C%7C322428deb128417aa66c08d58ce48877%7C84df9e7fe9f640afb435%7C1%7C0%7C636569835516193246&sdata=sweDk5MkHoQxTMyqs%2BNRsfFn1LR0TkD3Gve%2BF7ZO7Ks%3D&reserved=0 > - Italian Security Mailing List > ��i��0�Ȥ���ͪ+��Z�&�I�.�+r1���x ��
Re: [ml] Affidabilita' tool di VA/PT
Se lavori in ambito enterprise e sono scansioni interne, quindi non eseguite da terze parti per cui ci sarebbe tutta una trafila diversa ad esempio banalmente di firme per nda e altro, fatte per validare ambienti sviluppati in casa o acquistati da fornitori esterni la best practice minima sarebbe di lanciare i tools verso ambienti di collaudo / sviluppo. Per inciso ricordo ancora il lancio da parte di uno sviluppatore di uno scan acunetix verso la nuova release del prodotto software fatta in produzione, santo rman di oracle. > Il 15 settembre 2017 alle 8.44 ED ha scritto: > > > Un articolo di ieri relativo all'ennesima shell PHP con annessa backdoor > [1], ha rafforzato i miei timori sull'uso di tool poco conosciuti > durante i test di sicurezza verso ambienti di produzione. > > Lavoro in un ambiente "enterprise", in cui mi limito ad usare tool > commerciali di grosse case o open source rinomati (Nmap, Nikto ecc). > Salvo rare eccezioni, i tool poco conosciuti che vanno oltre la mia > capacita' di analisi (es. script ExploitDB con blob binari, framework > PowerShell che nascono e muoiono come meteore) sono esclusi, > specialmente se necessitano di privilegi local elevati o di credenziali > sull'obiettivo. Non avendo io tempo e competenze per scrivere exploit, > cio' naturalmente limita di molto i risultati. > > Come fate voi? Qual'e' il confine fra un tool sicuro ed uno pericoloso? > Dipende dall'obiettivo? Che precauzioni prendete quando eseguite tool > nuovi? Sono mai state formalizzate best practice a riguardo? > > Saluti > ED > > > [1] > https://isc.sans.edu/forums/diary/Another+webshell+another+backdoor/22826/ > > http://www.sikurezza.org - Italian Security Mailing List > http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Affidabilita' tool di VA/PT
Non in tool opensource di VA, ma in tool opensource in generale ( https://codiceinsicuro.it/blog/linux-mint-la-iso-intorno-al-buco/) Una backdoor no, ma il comportamento più o meno può essere rilevato... cmq, finché stai su tool mainstream (nmap, dirbuster, dirb, nikto) devi solo preoccuparti che non buchino i loro repo, e di solito se succede si ha un riscontro appena il buco viene rilevato. Poi, caso per caso, ti devi armare di pazienza e spulciarti il codice. Mah, sinceramente i sw di sicurezza mi sembrano abbastanza longevi. Paolo Il giorno 18 settembre 2017 18:50, ED ha scritto: > Paolo Perego ha scritto: > > [...] Se faccio un >> pentest mi affido a msfvenom x crearmi la webshell [...] >> > > Mi pare un buon consiglio, grazie. > > > Visto che le backdoor le hanno messe anche in tool open source >> commerciali [...] >> > > Quali? Non ne ero al corrente della scoperta di backdoor in software > commerciali di VA/PT (non escludo che ce ne siano, solo non avevo sentito > che ne fossero state scoperte). > > > Fidati dei tool che conosci e magari se devi provarne uno nuovo vedi >> come si comporta contro un ambiente di test isolato. >> Vedi se fa cose strane, connessioni particolari o altri. >> > > Una backdoor bene nascosta potrebbe non essere evidente (vedi il mio > messaggio ad antonio) e implicherebbe che dovremmo tutti ri-testare tutto > in continuazione con grande spreco di energie. > > Considerata la frequenza con cui i software di sicurezza open nascono e > muoiono potrebbe avere senso concentrare le forze della comunita', > classificando le analisi tramite una "web of trust". Io personalmente sarei > disposto a pagare qualcosa e immagino anche altri... o no? > > ciao > ED > > > http://www.sikurezza.org - Italian Security Mailing List > > -- $ cd /pub $ more beer I pirati della sicurezza applicativa: https://codiceinsicuro.it
Re: [ml] Affidabilita' tool di VA/PT
Paolo Perego ha scritto: [...] Se faccio un pentest mi affido a msfvenom x crearmi la webshell [...] Mi pare un buon consiglio, grazie. Visto che le backdoor le hanno messe anche in tool open source commerciali [...] Quali? Non ne ero al corrente della scoperta di backdoor in software commerciali di VA/PT (non escludo che ce ne siano, solo non avevo sentito che ne fossero state scoperte). Fidati dei tool che conosci e magari se devi provarne uno nuovo vedi come si comporta contro un ambiente di test isolato. Vedi se fa cose strane, connessioni particolari o altri. Una backdoor bene nascosta potrebbe non essere evidente (vedi il mio messaggio ad antonio) e implicherebbe che dovremmo tutti ri-testare tutto in continuazione con grande spreco di energie. Considerata la frequenza con cui i software di sicurezza open nascono e muoiono potrebbe avere senso concentrare le forze della comunita', classificando le analisi tramite una "web of trust". Io personalmente sarei disposto a pagare qualcosa e immagino anche altri... o no? ciao ED http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Affidabilita' tool di VA/PT
Bhe, in questo caso la backdoor era in una webshell. Se faccio un pentest mi affido a msfvenom x crearmi la webshell oppure, se devo scaricarlo dal web, è da farsi una code review. Visto che le backdoor le hanno messe anche in tool open source commerciali direi che la popolarità può non bastare. Per definizione credo che la fiducia non sia un kpi. Io neanche di nexpose mi fido. Mi fido di quello che scrivo io. Purtroppo non esiste un confine. Per il resto, lavoro anche io in ambiente Enterprise, uso una combinazione di tool open e commerciali e mi baso su funzionalità che offrono. Fidati dei tool che conosci e magari se devi provarne uno nuovo vedi come si comporta contro un ambiente di test isolato. Vedi se fa cose strane, connessioni particolari o altri. Paolo Il 15 set 2017 13:45, "ED" ha scritto: Un articolo di ieri relativo all'ennesima shell PHP con annessa backdoor [1], ha rafforzato i miei timori sull'uso di tool poco conosciuti durante i test di sicurezza verso ambienti di produzione. Lavoro in un ambiente "enterprise", in cui mi limito ad usare tool commerciali di grosse case o open source rinomati (Nmap, Nikto ecc). Salvo rare eccezioni, i tool poco conosciuti che vanno oltre la mia capacita' di analisi (es. script ExploitDB con blob binari, framework PowerShell che nascono e muoiono come meteore) sono esclusi, specialmente se necessitano di privilegi local elevati o di credenziali sull'obiettivo. Non avendo io tempo e competenze per scrivere exploit, cio' naturalmente limita di molto i risultati. Come fate voi? Qual'e' il confine fra un tool sicuro ed uno pericoloso? Dipende dall'obiettivo? Che precauzioni prendete quando eseguite tool nuovi? Sono mai state formalizzate best practice a riguardo? Saluti ED [1] https://isc.sans.edu/forums/diary/Another+webshell+another+ backdoor/22826/ http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Affidabilita' tool di VA/PT
Antonio parata ha scritto: [...] per esperienza (come lavoro analizzando malware) che in caso di comportamenti malevoli le richieste verso il C&C vengono fatte nei primi 15/20 minuti a partire dall'esecuzione (ovviamente ci possono essere delle eccezioni). [...] Eventuali backdoor potrebbero anche attivarsi in base a fattori specifici (IP del server privato/pubblico, disponibilità di collegamento Internet, ora del giorno, o anche casualmente es. una esecuzione ogni 10). Sono paranoico? identificare alcune funzioni/variabili chiave, ad esempio in caso di tool PHP (come quello riportato nell'articolo), il primo step e' fare grep per stringhe come eval/assert/system/$_GET/$_POST/base64_decode/... [...] Quanto ci impieghi a fare simili analisi? Le chiamate pericolose restano molte (sistema, filesystem, posta, db...). Occorre risalire a tutte le variabili/funzioni usate compreso il codice JavaScript che potrebbe inviare la backdoor dal client. In un programma python occorrerebbe revisionare tutto. Non si finisce piu'. Ti ringrazio per la condivisione. Nel tuo caso mi sembra abbia senso, ma spero che mi venga suggerita una soluzione piu' adatta alle mie esigenze (alto rischio) ed alle mie capacita/risorse limitate. ciao ED http://www.sikurezza.org - Italian Security Mailing List
Re: [ml] Affidabilita' tool di VA/PT
Ciao ED, ti riporto la mia personale esperienza per quanto riguarda l'analisi di nuovi tool. Premetto che sono uno sviluppatore di un tool VA per web app (pingami off-list se ti interessa :P) e mi capita spesso di analizare altri tool. In caso di tool open-source direi che il primo step e' sicuramente l'analisi del codice. In seguito testo il tool in una VM verso un target per capire che richieste vengono effettuate. Immagino che quest ultimo test possa interessarti maggiormente, in quanto e' facile vedere se fa collegamenti esterni. Posso dirti per esperienza (come lavoro analizzando malware) che in caso di comportamenti malevoli le richieste verso il C&C vengono fatte nei primi 15/20 minuti a partire dall'esecuzione (ovviamente ci possono essere delle eccezioni). Purtroppo in caso di tool con backdoor la questione si complica in quanto (in teoria) dovrebbero "solo" rimanere in attesa di connessioni. Non mi viene nulla in mente se non analisi del codice/binario. Durante l'analisi non c'e' bisogno che ti spippoli tutto il codice, spesso basta identificare alcune funzioni/variabili chiave, ad esempio in caso di tool PHP (come quello riportato nell'articolo), il primo step e' fare grep per stringhe come eval/assert/system/$_GET/$_POST/base64_decode/... e da li vedere cosa fanno. Attenzione che alcune backdoor potrebbero essere un po' piu' subdole (vedi [1]). Spero di esserti stato un minimo di aiuto (o per lo meno di non averti confuso maggiormente le idee :P). Ciao, Antonio [1] http://antonioparata.blogspot.it/2017/05/hiding-php-webshell-in-effective-way.html 2017-09-15 8:44 GMT+02:00 ED : > Un articolo di ieri relativo all'ennesima shell PHP con annessa backdoor > [1], ha rafforzato i miei timori sull'uso di tool poco conosciuti durante i > test di sicurezza verso ambienti di produzione. > > Lavoro in un ambiente "enterprise", in cui mi limito ad usare tool > commerciali di grosse case o open source rinomati (Nmap, Nikto ecc). Salvo > rare eccezioni, i tool poco conosciuti che vanno oltre la mia capacita' di > analisi (es. script ExploitDB con blob binari, framework PowerShell che > nascono e muoiono come meteore) sono esclusi, specialmente se necessitano > di privilegi local elevati o di credenziali sull'obiettivo. Non avendo io > tempo e competenze per scrivere exploit, cio' naturalmente limita di molto > i risultati. > > Come fate voi? Qual'e' il confine fra un tool sicuro ed uno pericoloso? > Dipende dall'obiettivo? Che precauzioni prendete quando eseguite tool > nuovi? Sono mai state formalizzate best practice a riguardo? > > Saluti > ED > > > [1] https://isc.sans.edu/forums/diary/Another+webshell+another+ > backdoor/22826/ > > http://www.sikurezza.org - Italian Security Mailing List > >
