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" <[email protected]> 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
