Come intercettare il traffico di applicazioni client spesse (tcp o http [s])

Questo strumento link sembra farlo. Usa un trucco: Incorpora ogni richiesta in una richiesta POST HTTP in modo da poterla inoltrare tramite burp e utilizzare ogni funzione di burp con protocolli arbitrari (ben binario potrebbe essere difficile). Burp restituisce quindi la richiesta al proxy che rimuove la parte http e inoltra il contenuto al server / client.

Come suggerito da Ian, la modalità Burp Suite Invisible Proxy sarebbe la soluzione migliore per catturare la richiesta da un'applicazione client thick inconsapevole del Proxy.

Considera un'applicazione client spessa che richiede a www.example.com. Inorder per catturare la richiesta tramite burp si può fare quanto segue:

1. Risoluzione del dominio per il loopback dell'indirizzo IP locale (127.0.0.1). Questo può essere fatto apportando le seguenti modifiche nel file HOST che si trova in ** c: \ windows \ system32 \ drivers \ etc ** (per windows).

127.0.0.1 www.example.com

2.Il prossimo rutto deve ascoltare l'indirizzo IP locale di loopback. Configura il rutto per ascoltare 127.0.0.1 e la porta che viene utilizzata dall'applicazione.

3. Finalmente la richiesta deve essere reindirizzata all'host attuale.

Ma il metodo di cui sopra ha una limitazione che Burp non può gestire se la richiesta viene attivata direttamente su un IP anziché su un nome di dominio. Questo può essere risolto con Burp Suite con Microsoft Loopback Adapter Method . Il link sottostante potrebbe darti un'idea chiara di ciò.

link

Se intendi scrivere un rapporto ufficiale per il tuo pen-test, allora suggerisco Canape da Context IS.

Non solo è il miglior proxy collegabile basato su GUI che abbia mai visto, ma è l'unico ad avere un'interfaccia ben progettata.

La risposta di BenjaminH usa Burp, che è bello. Ho anche trovato questo componente aggiuntivo Burp - link - che ritengo sia più funzionale. Tuttavia, se vuoi qualcosa di carino per un report, Canape è probabilmente ancora la strada da percorrere.

Burp potrebbe adattarsi a te per tutte le attività. Ha una modalità 'invisibile' che è stata specificamente progettata per intercettare il traffico per applicazioni thick client non proxy. Se riesci a farlo funzionare come previsto, potrebbe precludere la necessità di intercettare anche il traffico TCP crittografato.

Maggiori informazioni qui: link

Buona fortuna e HTH!

Preferisco usare Fiddler per scopi di intercettazione. È semplice da utilizzare con funzioni illimitate.

Puoi controllare HTTPSDecryption con Fiddler per le istruzioni.

Se stai cercando uno strumento in grado di intercettare sia il traffico HTTP che il traffico TCP generale, anch'esso in fase di sviluppo attivo, ti consiglio di consultare bettercap

Cose come l'incertezza HTTP sono integrate e c'è un framework per aggiungere moduli per gestire altri protocolli.

Consiglio vivamente mitmproxy che è un proxy di intercettazione con molte funzionalità che ti consentono di intercettare i pacchetti e modificarli prima che vengano inoltrati a e da l'host di destinazione.

Consente proxy trasparente che è utile per le applicazioni che non hanno la possibilità di aggiungere impostazioni proxy o non rispettare le impostazioni del proxy del sistema operativo.

Ha la capacità di ispezionare TLS tramite l'uso di una CA autofirmata che installi.

Puoi usare mitmproxy con un proxy upstream che è utile se ti trovi in una ambiente che richiede l'utilizzo di un proxy per accedere a Internet.

È molto flessibile, puoi usarlo come un semplice proxy di intercettazione usando la GUI interattiva o puoi sfruttarlo come una libreria python che ti permette di ispezionare e cambiare i pacchetti a livello di programmazione, ci sono alcuni examples su GitHub.

Sto lavorando a uno strumento per intercettare protocolli arbitrari, chiamato Mallet. È basato sul framework Netty ed è organizzato come una pipeline di gestori. Un comune "grafico" di gestori sarebbe simile a questo:

Listener->SOCKS Server->Handler->Handler->Interceptor->Handler->Target

Il gestore del server SOCKS accetta una connessione e negozia un handshake SOCKS con il client, per determinare dove deve essere inoltrata la connessione. Ottenere il client per negoziare l'handshake di SOCKS potrebbe essere semplice come un'impostazione di configurazione, o potrebbe comportare la socksificazione del client in qualche modo (tsocks, sockscap, ecc.).

I gestori possono essere qualsiasi Netty ChannelHandlers esistente, che implementa vari protocolli, come SSL, HTTP, MQTT, ecc. o può essere un ChannelHandler personalizzato scritto da te che decodifica il protocollo in questione in qualcosa con cui puoi lavorare più facilmente. Probabilmente il più importante è un decodificatore di frame che suddivide il flusso in singoli messaggi, quindi qualcosa che traduce i byte in un oggetto di qualche tipo.

Ho anche implementato una semplice classe ScriptHander in grado di eseguire script utilizzando qualsiasi linguaggio di script JSR223 come Groovy, Nashorn (ECMAScript), JLua, Jython, JRuby, ecc. ecc. Ciò rende possibile automatizzare l'elaborazione dei messaggi, che è spesso necessario a causa di timeout nel client o nel server. (I timeout sono molto meno un problema nel mondo HTTP!)

L'intercettore può quindi consentire di visualizzare e modificare manualmente il messaggio (se lo si desidera), prima di passarlo a ulteriori gestori (ad esempio per ricalcolare il checksum, ecc.) e infine sul Target.

Puoi vedere i primi progressi nel nostro repository Github al link

I problemi e le richieste di pull sono i benvenuti.