sensepost/malletMallet est un proxy d'interception pour des protocoles arbitraires.
Mallet est un outil pour créer des proxies pour des protocoles arbitraires, dans la même veine que les proxies web d'interception familiers, mais plus générique.
Il est construit sur le framework Netty et repose fortement sur le concept de pipeline Netty, qui permet l'assemblage graphique de graphes de gestionnaires. (Voir Captures d'écran ci-dessous pour un exemple.) Dans le monde Netty, les instances de gestionnaires fournissent la délimitation des trames (c'est-à-dire où un message commence et se termine), le décodage et l'encodage des protocoles (convertir un flux d'octets en objets Java, et vice versa, ou convertir un flux d'octets en un autre flux d'octets - pensez à la compression et décompression), et la logique de plus haut niveau (faire réellement quelque chose avec ces objets).
En suivant la séparation minutieuse des Codecs des Handlers qui manipulent réellement les messages, Mallet peut bénéficier de la vaste bibliothèque de Codecs existants et éviter la réimplémentation de nombreux protocoles. La dernière pièce du puzzle est fournie par un Handler qui copie les messages reçus sur un pipeline vers un autre pipeline, en proxyant ces messages vers leur destination finale.
Bien sûr, tant que les messages sont dans Mallet, ils peuvent facilement être modifiés, soit avec des Handlers personnalisés écrits en Java ou un langage de script conforme à JSR-223, soit manuellement, en utilisant l'un des éditeurs fournis.
Vous pouvez avoir une idée des codecs disponibles en regardant le code source de Netty sur GitHub, sous les répertoires codec*. Ou simplement en cherchant netty et le protocole qui vous intéresse. De nombreuses implémentations de protocoles intéressants ont été développées en dehors du projet Netty principal, mais devraient toujours bien fonctionner avec Mallet.
Mallet s'adresse aux personnes travaillant avec des applications réseau qui ne sont pas basées sur les communications HTTP. Des exemples pourraient être l'Internet des objets, qui pourrait utiliser MQTT, COAP, etc, les guichets automatiques et les terminaux de point de vente qui pourraient utiliser ISO8583, ou, pour être honnête, tout autre protocole.
En fait, Mallet peut même être utile pour les applications basées sur HTTP, qui utilisent des protocoles supplémentaires dans HTTP. Par exemple, Google Protobuf sur WebSockets, qui ne sont pas bien pris en charge par les proxies HTTP existants comme Burp, Zap, etc, ou gRPC sur HTTP2.
Mallet n'est pas nécessairement réservé aux audits de sécurité. Parce que Mallet est construit sur le Framework Netty, une fois que votre pipeline a été prototypé avec Mallet, vous pouvez migrer votre code vers une application Netty simple avec très peu d'effort.
Ceci est un exemple d'un proxy SOCKS simple, qui peut être utilisé comme première étape pour comprendre le trafic réseau que vous voyez.
Une fois que vous avez une idée de ce à quoi ressemble réellement le trafic, vous pouvez commencer à ajouter des classes ChannelHandler appropriées le long du pipeline.
Mallet utilise Maven, donc compiler le code est une question de
mvn package
Pour l'exécuter :
cd target/
java -jar mallet-1.0-SNAPSHOT-spring-boot.jar
Quelques graphes d'exemple sont fournis dans le répertoire examples/. Les graphes JSON s'attendent à ce qu'un client JSON se connecte à Mallet sur localhost:9998/tcp, avec le serveur réel sur localhost:9999/tcp. Seul le dernier graphe JSON (json5.mxe) fait des hypothèses sur la structure des messages JSON transmis, ils devraient donc être applicables à toute application qui envoie des messages JSON.
Le fichier demo.mxe montre un graphe complexe, avec deux pipelines, à la fois TCP et UDP. Le pipeline TCP est conçu pour prendre en charge HTTP et HTTPS sur les ports 80 et 443 respectivement, ainsi que les WebSockets, tout en relayant tout autre trafic directement vers sa destination. Le pipeline UDP est conçu pour traiter les requêtes DNS sur localhost:1053/udp, remplacer les requêtes pour google.com par des requêtes pour www.sensepost.com, et transférer les requêtes vers les serveurs DNS Google.
Les retours et contributions sont les bienvenus. Veuillez créer des issues le cas échéant, ou contacter l'auteur sur Twitter @RoganDawes.