pipe-intercept

Interceptez la communication des Named Pipes Windows à l'aide de Burp ou d'outils de proxy HTTP similaires

Les Named Pipes sont très populaires pour la communication interprocessus sous Windows. Ils sont utilisés dans de nombreuses applications, y compris l'appel de procédure distante (RPC) de Windows. Le but de cet outil est de permettre aux chercheurs en sécurité et aux testeurs d'intrusion d'effectuer une évaluation de sécurité pour les applications qui utilisent des named pipes. Ce projet est inspiré de l'excellent projet MITM_Intercept de CyberArk Labs.

Comment ça fonctionne ?

L'outil crée un proxy client/serveur de pipe avec un pont client/serveur WebSocket. Le client WebSocket se connecte au serveur WebSocket via un proxy HTTP tel que Burp.

Remarque importante : Cet outil utilise l'API win32 pour créer les named pipes, il ne fonctionne donc que sous Windows. Actuellement, il doit être exécuté sur la même machine que le serveur de pipe cible et le proxy HTTP. Je pourrais ajouter une option pour utiliser un proxy distant et une option pour relayer vers un serveur de pipe distant, mais l'outil devra toujours être exécuté sous Windows.

Diagramme de flux :

Il est important de comprendre que cet outil fonctionne en créant des instances de serveur de pipe distinctes, en dehors des instances créées par l'application serveur cible, ce qui force l'application cliente cible à se connecter à ces instances proxy. Cela implique plusieurs choses :

1. Si l'outil est exécuté après que l'application serveur cible a démarré et créé ses instances de serveur de pipe, l'utilisateur qui exécute l'outil doit disposer de permissions suffisantes pour créer des instances de serveur de pipe
2. En général, une application serveur aura toujours une instance de serveur de pipe en attente d'une connexion client. Les clients se connectent dans l'ordre FIFO, il est donc possible qu'après avoir exécuté l'outil, le premier client se connecte à l'instance créée par l'application cible, et que les clients suivants commencent à passer par le proxy. Certaines applications peuvent se comporter différemment : elles peuvent ne pas avoir d'instance en écoute en permanence, ou même en avoir plus d'une - pour le moment, il faudra essayer de comprendre comment fonctionne votre application cible
3. Certaines applications vérifient le client/serveur de pipe à l'autre extrémité (par identifiant de processus, nom d'utilisateur, etc.) et l'utilisent comme méthode d'authentification. Dans ces cas, l'outil pourrait ne pas fonctionner
4. Si l'outil crée la première instance de serveur de pipe, l'application serveur cible pourrait ne pas démarrer (si elle utilise FILE_FLAG_FIRST_PIPE_INSTANCE)

Comme vous pouvez le voir dans les points ci-dessus, l'utilisation de cet outil peut modifier le comportement de l'application cible. N'oubliez pas que cet outil est principalement destiné aux tests de sécurité, ne l'utilisez pas dans des systèmes de production.

Dépendances

L'outil a été testé avec la version 3.13.7 de Python. Installation :

python -m venv .venv
.venv\Scripts\activate.bat
pip install -r requirements.txt

Utilisation

usage: pipe_intercept.py [-h] --pipe-name PIPE_NAME [--ws-port WS_PORT] [--http-proxy-port HTTP_PROXY_PORT] [--log-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}]

options:
  -h, --help            show this help message and exit
  --pipe-name PIPE_NAME
                        The name of the pipe to be intercepted
  --ws-port WS_PORT     An available port number for the internal WebSocket server (if not specified, a random port will be used)
  --http-proxy-port HTTP_PROXY_PORT
                        The port number of the HTTP proxy (if not specified, the default is 8080)
  --log-level {CRITICAL,ERROR,WARNING,INFO,DEBUG}
                        Log level (if not specified, the default is INFO)

Exécuter les tests

Depuis le dossier racine (pipe-intercept) :

pytest

Exemple

Docker sur Windows utilise un named pipe pour la communication entre le client et le service docker. Le nom du pipe est "\\.\pipe\docker_engine". Voyons comment intercepter cette communication. Nous commençons par exécuter l'outil :

C:\pipe-intercept>python pipe_intercept.py --pipe-name docker_engine

INFO:websockets.server:server listening on 127.0.0.1:12037

Nous pouvons maintenant démarrer Burp et, depuis un autre shell, créer un conteneur Windows :

C:\pipe-intercept>docker run -it --name win mcr.microsoft.com/windows:1809-amd64 cmd

Microsoft Windows [Version 10.0.17763.2803]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>dir
 Volume in drive C has no label.
 Volume Serial Number is 5C09-8FFA

 Directory of C:\

05/07/2020  06:16 AM             5,510 License.txt
04/04/2022  02:57 PM    <DIR>          PerfLogs
04/04/2022  04:13 PM    <DIR>          Program Files
04/04/2022  02:57 PM    <DIR>          Program Files (x86)
04/04/2022  04:17 PM    <DIR>          Users
04/04/2022  04:13 PM    <DIR>          Windows
               1 File(s)          5,510 bytes
               5 Dir(s)  21,188,812,800 bytes free

C:\>

Maintenant, si on ouvre l'onglet WebSocket dans Burp, on peut voir la communication :

Nous pouvons également activer l'interception et modifier le message :

Microsoft Windows [Version 10.0.17763.2803]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>dir
 Volume in drive C has no label.
 Volume Serial Number is 5C09-8FFA

 Directory of C:\

05/07/2020  06:16 AM             5,510 License.txt
04/04/2022  02:57 PM    <DIR>          PerfLogs
04/04/2022  04:13 PM    <DIR>          Modified Name
04/04/2022  02:57 PM    <DIR>          Program Files (x86)
04/04/2022  04:17 PM    <DIR>          Users
04/04/2022  04:13 PM    <DIR>          Windows
               1 File(s)          5,510 bytes
               5 Dir(s)  21,188,288,512 bytes free

C:\>