Cómo interceptar el tráfico de aplicaciones de cliente grueso (tcp o http [s])

Esta herramienta enlace parece hacer esto. Utiliza un truco: Incorpora cada solicitud en una solicitud HTTP POST para que pueda transmitirla a través de eructar y usar cada función de eructo con protocolos arbitrarios (bien binario podría ser difícil). Burp luego pasa la solicitud al proxy, que elimina la parte http y reenvía el contenido al servidor / cliente.

Según lo sugerido por Ian, el modo Burp Suite Invisible Proxy sería el mejor para capturar la solicitud del Proxy que no conoce la aplicación cliente Thick.

Considere una solicitud de cliente Thick que realiza una solicitud a www.example.com. Para capturar la solicitud a través de eructo, se puede hacer lo siguiente:

1. Resolviendo el dominio para volver a la dirección IP local (127.0.0.1). Esto se puede hacer realizando los siguientes cambios en el archivo HOST ubicado en ** c: \ windows \ system32 \ drivers \ etc ** (para Windows).

127.0.0.1 www.example.com

2.El siguiente burp tiene que escuchar la dirección IP local del bucle de retorno. Configurar el eructo para escuchar 127.0.0.1 y el puerto que utiliza la aplicación.

3. Por último, la solicitud debe redirigirse al host real.

Pero el método anterior tiene una limitación que burp no puede manejar si la solicitud se dispara directamente a una dirección IP en lugar de a un nombre de dominio. Esto se puede superar con Burp Suite with Microsoft Loopback Adapter Method . El siguiente enlace podría darle una idea clara de ello.

enlace

Si tiene la intención de escribir un informe de aspecto oficial para su prueba de lápiz, le sugiero Canape de El contexto es.

No solo es el mejor proxy conectable basado en GUI que he encontrado, sino que es el único que tiene una interfaz bien diseñada.

La respuesta de BenjaminH usa Burp, lo cual es bueno. También encontré este complemento Burp, enlace , que creo que es más funcional. Sin embargo, si desea algo bonito para un informe, entonces Canape es probablemente el camino a seguir.

Burp puede ser adecuado para todas las tareas. Tiene un modo 'invisible' que fue diseñado específicamente para interceptar el tráfico para aplicaciones de clientes gruesos que no tienen en cuenta el proxy. Si puede hacer que esto funcione de la forma prevista, es posible que no tenga que interceptar también el tráfico TCP cifrado.

Más información aquí: enlace

¡Buena suerte y HTH!

Prefiero usar Fiddler para fines de intercepción. Es fácil de usar con funciones ilimitadas.

Puede consultar HTTPSDecryption con Fiddler para obtener instrucciones.

Si está buscando una herramienta que pueda interceptar tanto el tráfico HTTP como el tráfico TCP general, que también está en desarrollo activo, le recomiendo que consulte bettercap

Cosas como la incercepción de HTTP están integradas y hay un marco para agregar módulos para manejar otros protocolos.

Recomiendo encarecidamente mitmproxy , que es un proxy de intercepción con muchas características que le permiten interceptar paquetes y cambiarlos antes de que sean enviados y recibidos el host de destino

Permite proxy transparente que es útil para aplicaciones que no tienen la opción de agregar La configuración del proxy o no respeta la configuración del proxy del sistema operativo.

Tiene la capacidad de inspeccionar TLS mediante el uso de una CA autofirmada que instale.

Puede usar mitmproxy con un proxy ascendente que es útil si está en un entorno que requiere que uses un proxy para acceder a Internet.

Es muy flexible, puede usarlo como un simple proxy de intercepción utilizando la GUI interactiva o puede aprovecharla como una biblioteca de Python que le permite inspeccionar y cambiar paquetes programáticamente, hay algunos ejemplos en GitHub.

Estoy trabajando en una herramienta para interceptar protocolos arbitrarios, llamada Mallet. Se basa en el marco de Netty y se organiza como un conjunto de manejadores. Un "gráfico" común de manejadores se vería así:

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

El controlador del servidor SOCKS acepta una conexión y negocia un acuerdo SOCKS con el cliente para determinar dónde debe retransmitir la conexión. Lograr que el cliente negocie el protocolo de intercambio SOCKS puede ser tan simple como un ajuste de configuración, o puede implicar socksificar al cliente de alguna manera (tsocks, sockscap, etc.).

Los manejadores pueden ser cualquiera de los Netty ChannelHandlers existentes, que implementan varios protocolos, como SSL, HTTP, MQTT, etc., o pueden ser un ChannelHandler personalizado escrito por usted mismo que decodifica el protocolo en cuestión en algo con lo que pueda trabajar. más fácilmente. Probablemente lo más importante es un decodificador de trama que divide el flujo en mensajes individuales, algo que convierte los bytes en un objeto de algún tipo.

También he implementado una clase simple de ScriptHander que puede ejecutar scripts utilizando cualquier lenguaje de scripts JSR223 como Groovy, Nashorn (ECMAScript), JLua, Jython, JRuby, etc. Esto permite automatizar el procesamiento de mensajes, lo que A menudo es necesario debido a los tiempos de espera en el cliente o servidor. (¡Los tiempos de espera son un problema mucho menor en el mundo HTTP!)

El interceptor puede permitirle ver y editar manualmente el mensaje (si lo desea), antes de pasarlo a otros manejadores (por ejemplo, para recalcular las sumas de comprobación, etc.) y finalmente al Destino.

Puede ver los primeros avances en nuestro repositorio de github en enlace

Los problemas y las solicitudes de extracción son bienvenidos.