Come si dissolve sul server FTP FreeFloat utilizzando SPIKE Fuzzing?

5

Vorrei chiedere aiuto sull'utilizzo di SPIKE fuzzer per confondere un server FTP che sto testando sul server FTP Freefloat ma non ho idea su come lavorare. Durante la ricerca e il collaudo di molti diversi tipi di script fuzzing SPIKE per eseguire il fuzzing sul server FTP ma il server non è stato in grado di arrestarsi.

Mentre provo alcuni degli script come:

s_readline(); s_string("USER "); s_string_variable("COMMAND"); s_string("\r\n"); s_string("PASS "); s_string_variable("COMMAND"); s_read_packet();

Quando ho eseguito lo script usando "generic_send_tcp" e aperto anche il wireshark per catturare il traffico, lo script fa crashare il server. Ma il problema è che quando guardo nel primo pacchetto del traffico lo mostra:

500 'USER COMMAND' command not understood\r\n

Ma questa non era la parte che causa il crash del server. Come se il primo pacchetto fosse andato a buon fine, suppose di renderlo fedele alla password e dichiarerà '230 Utente loggato'. Ma non è riuscito a passare fino alla fase della password.

Quindi vorrei chiedere aiuto a chiunque possa aiutarmi in questo problema. Come ho davvero provato molti metodi diversi, ma potrei riuscire a lavorare.

    
posta ebiz 07.01.2013 - 10:28
fonte

2 risposte

1

Mi dispiace non posso aiutare direttamente con il componente SPIKE, ma come fai a sapere che il server FTP FreeFloat è addirittura insicuro e si blocca? Potrebbe essere ben scritto e in grado di gestire tutto ciò che SPIKE getta su di esso.

Nel frattempo, metasploit ha grandi moduli di fuzzing FTP che ho usato in passato con molto successo.

link

    
risposta data 07.01.2013 - 17:11
fonte
-1

So che questa domanda è molto vecchia ma voglio solo far notare che la parte che causa il crash del server contiene la stessa espressione regolare "Comando non compreso!" ... Ma uno ha appena essere paziente! Nel mio caso (mentre tornavo), dovevo controllare uno ad uno il pacchetto catturato su wireshark e controllare dove (usando uno specifico filtro di visualizzazione) il server non rispondeva più (restituisce sempre la sua intestazione, quindi se "no" intestazione ricevuta significa arresto anomalo) e solo il pacchetto prima ha funzionato. Come sempre, penso che sarebbe saggio provare sempre a replicare il crash semplicemente con ^ + c & & ^ + v lo streaming da wireshark e inviarlo al server per mezzo di un piccolo script, solo per controllare, prima di andare avanti! Nel mio caso 512 byte hanno fatto il lavoro!

    
risposta data 16.01.2017 - 20:30
fonte

Leggi altre domande sui tag