Build

Vous pouvez soit compiler l'outil une fois et utiliser le binaire résultant, soit l'exécuter "comme un script" (la chaîne d'outils Go le compilera à la volée). Pour le développement, cette dernière option est pratique. Pour une utilisation en production, il est recommandé de le compiler une fois (depuis le répertoire cli) et d'utiliser l'exécutable résultant. Grâce au compilateur Go, vous pouvez compiler depuis et pour Linux ou Windows. Au moins la version 1.18 de Go est nécessaire pour la compilation (testé avec Go 1.23).

Compilation depuis Linux

Pour compiler depuis Linux pour Windows ou Linux, définissez simplement GOOS de manière appropriée (exécutez depuis le répertoire cli) :``` GOOS=windows GOARCH=amd64 go build -o wcfproxy.exe

GOOS=linux GOARCH=amd64 go build -o wcfproxy

## Compilation depuis Windows
Pour compiler depuis Windows, exécutez les commandes équivalentes, par exemple depuis PowerShell :```
$env:GOOS='windows'; $env:GOARCH='amd64'; go build -o wcfproxy.exe

RÈGLES CRITIQUES :

Traduire UNIQUEMENT le texte en langage naturel. NE JAMAIS traduire : code, commandes de terminal, chemins de fichiers, URLs, noms de paquets, identifiants CVE, noms de variables d'environnement, identifiants.
Préserver INTACTE la structure Markdown : titres, listes, listes imbriquées, tableaux (y compris l'alignement), liens, images, code en ligne, blocs de code, citations, blocs HTML et règles horizontales.

> [!WARNING] > Toute personne ayant accès à l'API peut s'authentifier en utilisant les identifiants fournis (NTLM ou certificats clients TLS). > Sur les systèmes partagés, cela peut être pertinent même si l'API n'est disponible que localement. ### Options de configuration du serveur de contrôle + `listen` - le point de terminaison TCP sur lequel le serveur de contrôle doit écouter + `enable-contorl` - active les fonctionnalités de contrôle comme l'injection de messages ou l'établissement de connexions (voir [Injection de messages](#message-injection)) + `enable-echo` - active un simple serveur HTTP echo à l'adresse `http://{listen}/echo` # Détails Les sections suivantes fournissent des informations de base qui peuvent aider à mieux comprendre WCF ainsi que certaines options de configuration. ## Réécriture de cible Le point de terminaison WCF prévu est encodé dans le préambule net.tcp ainsi que dans l'en-tête `To` des enveloppes SOAP transportées. Les serveurs peuvent vérifier que cette spécification de point de terminaison correspond à celle attendue. Lorsque le client est manipulé pour se connecter au proxy au lieu du serveur d'origine, cette spécification de point de terminaison changera probablement et le serveur peut rejeter la communication. Il est donc généralement judicieux de corriger la spécification de point de terminaison dans le trafic sortant vers le serveur. Pour ce faire, fournissez la spécification de point de terminaison d'origine (par exemple obtenue à partir de la configuration du client) dans l'option `retarget` du fichier de configuration. La spécification de point de terminaison ressemble généralement à ceci : `net.tcp://some/endpoint`. Lorsque vous travaillez avec plusieurs points de terminaison WCF simultanément, il peut être nécessaire d'effectuer une réécriture de cible pour tous. Pour cela, l'option `retarget-map` existe, qui définit un mappage entre les URI cibles. Lorsqu'aucune correspondance n'est trouvée dans `retarget-map`, l'URI cible sera modifiée pour la valeur donnée dans `retarget`. ## Indicateurs de type Le XML binaire, tel que spécifié par `MC-NBFX`, encode les informations de type de base dans le format binaire (types d'enregistrement). Toutes ces informations ne sont pas facilement récupérables à partir de la représentation XML (textuelle) d'un document XML binaire. Pour cette raison, *wcfproxy* insère des indicateurs de type dans les données de caractères XML (et certains attributs) des jetons. Ces indicateurs de type prennent la forme `<h>:`, où `<h>` est une courte chaîne qui encode un certain type (par exemple `i` pour entier, `ch` pour caractères). Une liste complète des indicateurs de type se trouve dans [typehint.go](https://github.com/syss-research/wcfproxy/blob/main/binxml/typehint.go). Il est déconseillé de modifier les indicateurs de type. ## Intercepteurs Les intercepteurs spécifient comment le trafic reçu est traité et sont spécifiés via la [configuration des intercepteurs](#interceptor-configuration). Ils traitent le trafic envoyé dans les deux directions (client -> serveur et serveur -> client). Actuellement, il existe deux intercepteurs : **log** et **http**. ### Intercepteur Log L'intercepteur **log** convertit les enveloppes SOAP encodées en binaire en leurs équivalents lisibles par l'homme, encodés en XML textuel standard. Aucune manipulation active (sauf la réécriture de la spécification de cible) n'est effectuée. La sortie est envoyée à l'emplacement de journalisation spécifié (`stdout` par défaut). Assurez-vous de définir le niveau de journalisation sur `info` (ou `debug`), sinon la sortie pertinente est supprimée. ### Intercepteur HTTP L'intercepteur **http** convertit les enveloppes SOAP binaires en leurs équivalents textuels et les envoie à un point de terminaison HTTP spécifié par `-http-url`. Les messages SOAP décodés sont envoyés dans le corps de la requête. Le serveur HTTP doit renvoyer une enveloppe SOAP valide dans le même format que les messages entrants. Ces messages sont ensuite retransformés au format binaire d'origine et envoyés au serveur en amont. Le simple reflet du message d'origine est toujours une option valide pour le serveur HTTP. Cependant, une manipulation programmatique des messages peut également être réalisée en fournissant un serveur HTTP personnalisé qui effectue les remplacements souhaités. Il faut veiller à ne pas casser la structure des messages SOAP. Il est conseillé de ne pas altérer le format des messages à moins de savoir ce que l'on fait. De plus, les indicateurs de type insérés par *wcfproxy* ne doivent pas être altérés, car cela pourrait casser la transformation des messages SOAP textuels en leurs équivalents binaires ou l'analyse des messages sur le point de terminaison légitime (client ou serveur). *wcfproxy* est livré avec un serveur HTTP trivial qui reflète simplement le corps des requêtes HTTP reçues. Ce serveur sera démarré lorsqu'une [configuration du serveur de contrôle](#control-server-configuration) est fournie et que l'option `enable-echo` est définie sur `true`. L'URL du serveur HTTP souhaité est fournie via l'option `server-url` dans la [configuration de l'intercepteur HTTP](#http-interceptor). Pour permettre une manipulation interactive, un proxy HTTP (par exemple BurpSuite) peut être spécifié via l'option `proxy-url`. Les messages seront alors envoyés au serveur HTTP via le proxy HTTP spécifié. Notez que pour chaque message WCF (par exemple client -> serveur), une paire requête/réponse HTTP est produite. Pour corréler les messages avec la connexion net.tcp dont ils proviennent, l'en-tête `X-Wcpf-Conn-Id` est inséré dans les requêtes générées par l'intercepteur **http**. L'image suivante illustre le flux de données avec l'intercepteur **http**. ![Illustration de l'intercepteur HTTP](https://raw.githubusercontent.com/syss-research/wcfproxy/HEAD/doc/http-interceptor.svg) ## Options TLS WCF (sur net.tcp) peut utiliser TLS pour la sécurité du transport. *wcfproxy* prend en charge l'interception des connexions TLS (uniquement TLS 1.0 - 1.3, pas de SSL). Les paramètres TLS côté serveur et côté client peuvent être contrôlés avec la configuration TLS correspondante (voir [Configuration TLS serveur](#tls-server-configuration) ou [Configuration TLS client](#tls-client-configuration)). ## Options NTLM *wcfproxy* prend en charge l'authentification NTLM. Actuellement, l'authentification NTLM directe ou la négociation via SPNEGO est prise en charge. Vous devez fournir les identifiants du ou des utilisateurs qui s'authentifieront. Ces identifiants sont fournis au format JSON, voir [Configuration NTLM](#ntlm-configuration). La transmission de hachages est prise en charge en fournissant des hachages via la propriété `nt-hash`. ## Injection de messages et établissement de connexions Lorsque le [serveur de contrôle](#control-server-configuration) est activé, une petite API HTTP est fournie qui peut être utilisée pour établir ou terminer des connexions et injecter des messages dans des connexions existantes. Les points de terminaison suivants sont disponibles. ### GET `/connection` Liste les connexions actuellement actives. Pour les connexions côté serveur uniquement (créées via [POST /connection/new](#post-connectionnew)), le client sera affiché comme `wcfproxy`. ### POST `/connection/new` Crée une nouvelle connexion. Le corps doit être un objet JSON spécifiant la mise à niveau prévue (TLS ou Negotiate (NTLM)) le cas échéant. L'URI du point de terminaison est fournie via la propriété `target-uri`. #### Exemple : Aucune mise à niveau Si aucune mise à niveau n'est requise, la propriété `upgrade` peut être omise.```json { "target-uri":"net.tcp://127.0.0.1:9510/example/notes-nettcp" }

Avec la configuration ci-dessus (placée dans `config.json`), nous pouvons l'utiliser comme indiqué ci-dessous. Le trafic via le proxy devrait ensuite être affiché sur la console (`stdout`).``` > .\wcfproxy.exe -config .\config.json -enable wcflab-plain 2025/07/10 15:03:59 dbg: local time zone (for DateTime handling): CEST INFO: Listening on 127.0.0.1:7201 and connecting to 127.0.0.1:8201 INFO: No server certificates given. TLS upgrade not supported. INFO: No client certificates given. TLS client authentication not supported. INFO: Retargeting to net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp INFO: [proxy] Handling new connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201 INFO: [proxy] Connection 0 established (127.0.0.1:50216 <-> 127.0.0.1:8201) INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://127.0.0.1:8201/WCFLab/WCFDemoService/nettcp</a:To> </s:Header> <s:Body> <AddInts xmlns="http://tempuri.org/"> <a>i:1234</a> i:37 </AddInts> </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:b2d5fc85-4bcd-6442-b701-164655365198</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> <AddIntsResponse xmlns="http://tempuri.org/"> <AddIntsResult>i:1271</AddIntsResult> </AddIntsResponse> </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed (127.0.0.1:50216 <-> 127.0.0.1:8201) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50217->127.0.0.1:8201: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: 127.0.0.1:50216 <-> 127.0.0.1:8201

Note that the clients need to trust the server certificate (`server.pem`). Furthermore, the server must trust the certificate presented by the client part of *wcfproxy* (`client.pem`).``` > .\wcfproxy.exe -config .\config.json -enable wcflab-mtls 2025/07/10 15:01:32 dbg: local time zone (for DateTime handling): CEST INFO: Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564) INFO: Listening on 127.0.0.1:7203 and connecting to 127.0.0.1:8203 INFO: Using server certificate wcflab.local (SHA256-fingerprint: 7286ff75d3bb6dc4d96c0c8ac08dbac2204af67e0b1814b3d8c59c24d5bd781a) INFO: Server supports TLS versions 1.0 - 1.3 INFO: Using client certificate client-01.local (SHA256-fingerprint: 9b258653a4d5f338f2be1dafe0caf892b01d271183e52f0821d80439de4b7564) INFO: Client supports TLS versions 1.0 - 1.3 INFO: Retargeting to net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls INFO: [proxy] Handling new connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203 INFO: [proxy] Connection 0 established (127.0.0.1:50214 <-> 127.0.0.1:8203) INFO: [proxy] Initiating TLS upgrade INFO: [proxy] 127.0.0.1:50214 <-> 127.0.0.1:7203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) INFO: [proxy] 127.0.0.1:50215 <-> 127.0.0.1:8203: negotiated TLS 1.2 (TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) INFO: [proxy] Upgrade done INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8203/WCFLab/WCFDemoService/nettcps-mtls</a:To> </s:Header> <s:Body> <AddInts xmlns="http://tempuri.org/"> <a>i:1234</a> i:37 </AddInts> </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:d36e17be-2cc2-a94f-83a7-cd2442dba24e</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> <AddIntsResponse xmlns="http://tempuri.org/"> <AddIntsResult>i:1271</AddIntsResult> </AddIntsResponse> </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed (127.0.0.1:50214 <-> 127.0.0.1:8203) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp 127.0.0.1:50215->127.0.0.1:8203: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: 127.0.0.1:50214 <-> 127.0.0.1:8203

Notez qu'actuellement, il est plus robuste de fournir le nom d'hôte via le champ `server` ou `domain` que de se fier à la configuration automatique. De plus, l'authentification dans un contexte de domaine AD n'est pas testée et est donc probablement cassée pour le moment. Lorsque SPNEGO est utilisé, le mécanisme NTLM doit actuellement être le préféré, sinon la négociation échouera.``` > .\wcfproxy.exe -config .\config.json -enable wcflab-ntlm 2025/07/10 15:15:15 dbg: local time zone (for DateTime handling): CEST INFO: Listening on [::1]:7204 and connecting to [::1]:8204 INFO: No server certificates given. TLS upgrade not supported. INFO: No client certificates given. TLS client authentication not supported. INFO: Retargeting to net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth INFO: [proxy] Handling new connection 0: [::1]:50247 <-> [::1]:8204 INFO: [proxy] Connection 0 established ([::1]:50247 <-> [::1]:8204) INFO: [proxy] Initiating Negotiate upgrade INFO: [NTLM server] User wcflab authenticated successfully INFO: [proxy] [::1]:50247 <-> [::1]:7204: negotiated NTLM INFO: [proxy] [::1]:50248 <-> [::1]:8204: negotiated NTLM INFO: [proxy] Upgrade done INFO: [proxy] Envelope (Connection 0, Client -> Server): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddInts</a:Action> <a:MessageID>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:MessageID> <a:ReplyTo> <a:Address>ch:http://www.w3.org/2005/08/addressing/anonymous</a:Address> </a:ReplyTo> <a:To s:mustUnderstand="c:1">ch:net.tcp://localhost:8204/WCFLab/WCFDemoService/nettcp-winauth</a:To> </s:Header> <s:Body> <AddInts xmlns="http://tempuri.org/"> <a>i:1234</a> i:37 </AddInts> </s:Body> </s:Envelope> INFO: [proxy] Envelope (Connection 0, Server -> Client): <s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://www.w3.org/2005/08/addressing"> <s:Header> <a:Action s:mustUnderstand="c:1">ch:http://tempuri.org/IWCFDemoService/AddIntsResponse</a:Action> <a:RelatesTo>uid:urn:uuid:f9cc5af3-3930-9242-be3c-d36d2a0cb09e</a:RelatesTo> <a:To s:mustUnderstand="c:1">ch:http://www.w3.org/2005/08/addressing/anonymous</a:To> </s:Header> <s:Body> <AddIntsResponse xmlns="http://tempuri.org/"> <AddIntsResult>i:1271</AddIntsResult> </AddIntsResponse> </s:Body> </s:Envelope> INFO: [proxy] Connection 0 closed ([::1]:50247 <-> [::1]:8204) ERROR: [net.tcp] Error readEnvelopeOrFaultI2R: read tcp [::1]:50248->[::1]:8204: i/o timeout. Entering fault state. INFO: [proxy] Done handling connection 0: [::1]:50247 <-> [::1]:8204

wcfproxy

Populaires

Options de configuration

Configuration du serveur TLS

Options de configuration du client TLS

Configuration NTLM

Configuration de l'intercepteur

Intercepteur de journal

Configuration du serveur de contrôle

Exemple : Mise à niveau TLS

POST `/connection/{id}/kill`

POST `/connection/{id}/inject`

Limite de connexion

Exemples

Utilisation de l'intercepteur log

Utilisation de l'intercepteur http

Configuration de l'interception (m)TLS

Configuration de l'authentification NTLM