Comment intercepter le trafic des applications clientes lourdes (TCP ou http [s])
Récemment, j'apprends le pentesting des applications client lourd et j'ai trouvé qu'il était difficile d'obtenir un outil pour intercepter le trafic des applications client lourd.
Quelqu'un a-t-il rencontré une application cliente lourde pour le pentesting, ou sait-il s'il existe un logiciel qui peut fonctionner comme proxy d'intercepteur comme Burp Suite pour les applications clientes lourdes? Je recherche un outil capable non seulement d'intercepter le trafic http mais aussi le trafic tcp.
J'ai fait quelques recherches sur Google et j'ai trouvé Mallory . Jusqu'à présent, c'est le meilleur outil que je puisse trouver. Je l'ai testé et il fonctionne comme prévu, mais il n'est pas stable et n'a pas été mis à jour depuis un certain temps.
Un autre problème auquel je suis confronté est que si l'application utilise l'authentification de domaine Windows (authentification NTLM), le trafic TCP sera alors chiffré. Existe-t-il un moyen de voir le trafic en texte brut et de modifier le les données avant leur envoi au serveur (tout comme la façon dont Burp l'a fait pour le trafic HTTPS)?
Cet outil https://github.com/jrmdev/mitm_relay semble faire cela. Il utilise une astuce: il intègre chaque requête dans une requête HTTP POST afin que vous puissiez la relayer via burp et utiliser chaque fonction de burp avec des protocoles arbitraires (le binaire peut être difficile). Burp passe ensuite la demande est renvoyée au proxy qui supprime la partie http et transmet le contenu au serveur/client.
Si vous cherchez un outil capable d'intercepter à la fois HTTP et le trafic général TCP trafic, qui est également en cours de développement actif, je vous recommande de regarder bettercap
Des choses comme l'incerception HTTP sont intégrées et il existe un cadre pour ajouter des modules pour gérer d'autres protocoles.
Comme suggéré par Ian, le mode proxy invisible de Burp Suite serait le meilleur pour capturer la demande d'une application client épaisse ignorant le proxy.
Considérez une application client lourd faisant une demande à www.example.com. Afin de capturer la demande via burp, les opérations suivantes peuvent être effectuées:
- Résolution du domaine pour boucler l'adresse IP locale (127.0.0.1). Cela peut être fait en apportant les modifications suivantes dans le fichier hôte situé dans ** c:\windows\system32\drivers\etc ** (pour Windows).
127.0.0.1 www.example.com
2. Le burp suivant doit écouter l'adresse IP locale de bouclage. Configurez le burp pour écouter 127.0.0.1 et le port utilisé par l'application.
- Enfin, la demande doit être redirigée vers l'hôte réel.
Mais la méthode ci-dessus a une limitation que burp ne peut pas gérer si la demande est directement envoyée à une adresse IP au lieu d'un nom de domaine. Cela peut être surmonté par Burp Suite avec la méthode de l'adaptateur de bouclage Microsoft . Le lien ci-dessous pourrait vous en donner une idée claire.
Si vous avez l'intention d'écrire un rapport officiel pour votre test de stylo, alors je suggère Canape de Context IS.
Non seulement c'est le meilleur proxy enfichable basé sur une interface graphique que j'ai rencontré, mais c'est le seul à avoir une interface bien conçue.
La réponse de BenjaminH utilise Burp, qui est Nice. J'ai également rencontré ce module complémentaire Burp - https://github.com/summitt/Burp-Non-HTTP-Extension - qui je pense est plus fonctionnel. Cependant, si vous voulez quelque chose de joli pour un rapport, alors Canape est probablement encore le chemin à parcourir.
Burp pourrait bien vous convenir pour toutes les tâches. Il dispose d'un mode "invisible" qui a été spécialement conçu pour intercepter le trafic pour les applications clientes lourdes non proxy. Si vous pouvez faire fonctionner cela comme prévu, cela peut vous empêcher d'avoir à intercepter le trafic crypté TCP aussi.
Plus d'informations ici: https://portswigger.net/burp/help/proxy_options_invisible.html
Bonne chance et HTH!
Je travaille sur un outil d'interception de protocoles arbitraires, appelé Mallet. Il est basé sur le framework Netty et est organisé comme un pipeline de gestionnaires. Un "graphique" commun des gestionnaires ressemblerait à ceci:
Listener->SOCKS Server->Handler->Handler->Interceptor->Handler->Target
Le gestionnaire de serveur SOCKS accepte une connexion et négocie une négociation SOCKS avec le client, afin de déterminer où il doit relayer la connexion. Faire en sorte que le client négocie la prise de contact SOCKS peut être aussi simple qu'un paramètre de configuration, ou peut impliquer de socksifier le client d'une manière ou d'une autre (tsocks, sockscap, etc.).
Les gestionnaires peuvent être n'importe lequel des Netty ChannelHandlers existants, qui implémentent divers protocoles, tels que SSL, HTTP, MQTT, etc., ou peuvent être un ChannelHandler personnalisé écrit par vous-même qui décode le protocole en question en quelque chose avec lequel vous pouvez travailler plus facilement. Le plus important est probablement un décodeur de trames qui fragmente le flux en messages individuels, puis quelque chose qui traduit les octets en un objet quelconque.
J'ai également implémenté une classe ScriptHander simple qui peut exécuter des scripts en utilisant n'importe quel langage de script JSR223 tel que Groovy, Nashorn (ECMAScript), JLua, Jython, JRuby, etc., etc. Cela permet d'automatiser le traitement des messages, ce qui est souvent nécessaire en raison de délais d'attente dans le client ou le serveur. (Les délais d'attente sont beaucoup moins un problème dans le monde HTTP!)
L'intercepteur peut alors vous permettre d'afficher et de modifier manuellement le message (si vous le souhaitez), avant de le transmettre à d'autres gestionnaires (par exemple pour recalculer les sommes de contrôle, etc.), et enfin sur la cible.
Vous pouvez voir les premiers progrès dans notre dépôt github sur https://github.com/RoganDawes/Mallet
Les problèmes et les demandes de tirage sont les bienvenus.
Je recommande fortement mitmproxy qui est un proxy d'interception avec de nombreuses fonctionnalités vous permettant d'intercepter les paquets et de les modifier avant qu'ils ne soient transférés vers et depuis l'hôte cible.
Il permet proxy transparent qui est utile pour les applications qui n'ont pas la possibilité d'ajouter des paramètres de proxy ou qui ne respectent pas les paramètres de proxy du système d'exploitation.
Il a la capacité de inspecter TLS grâce à l'utilisation d'une autorité de certification auto-signée que vous installez.
Vous pouvez utiliser mitmproxy avec un proxy en amont qui est utile si vous êtes dans un environnement qui vous oblige à utiliser un proxy pour accéder à Internet.
Il est très flexible, vous pouvez l'utiliser comme un simple proxy d'interception en utilisant l'interface graphique interactive ou vous pouvez l'utiliser comme une bibliothèque python vous permettant d'inspecter et de modifier les paquets par programme, il y en a - exemples sur GitHub.
Je préfère utiliser Fiddler à des fins d'interception. C'est simple à utiliser avec des fonctionnalités illimitées.
Vous pouvez vérifier HTTPSDecryption avec Fiddler pour les instructions.