stealth/pscChiffrement de bout en bout pour sessions tty multi-saut ou portshells + transfert de port TCP/UDP
Ce projet - ainsi que son projet frère crash - fait partie de mon ensemble d'outils anti-censure qui permet de mettre en place des shells cryptés entièrement fonctionnels et du forwarding TCP/UDP dans des environnements de censure hostiles. Il est également utile en criminalistique pour extraire des données de dispositifs via UART ou adb lorsqu'aucun autre moyen n'est disponible.
Recherche DNS et session SSH transférées via une connexion UART vers un Pi
PSC permet de chiffrer de bout en bout les sessions shell, en un seul ou plusieurs sauts, en étant indépendant du transport sous-jacent, tant qu'il est fiable et peut envoyer/recevoir des données encodées en Base64 sans modification/filtrage. Avec le pty de bout en bout que vous recevez (par exemple dans un port-shell), vous pouvez transférer des connexions TCP et UDP, similaire au paramètre -L d'OpenSSH. Cela fonctionne de manière transparente et sans nécessiter d'adresse IP assignée localement au point de départ. Cela permet aux enquêteurs judiciaires et aux testeurs d'intrusion de créer des connexions réseau par exemple via :
adb shell, si l'adbd OEM ne supporte pas le forwarding TCPImaginez que vous ayez une session ppp invisible à l'intérieur de votre session shell, sans que le pair distant ne supporte réellement ppp.
Il fonctionne sur Linux, Android, OSX, Windows, FreeBSD, NetBSD et (éventuellement) OpenBSD.
PSC inclut également le support des proxies SOCKS4 et SOCKS5 afin d'avoir de véritables sessions de navigation web via des port-shells ou des connexions modem à distance.
Modifiez le Makefile pour y mettre vos clés pré-partagées, telles que définies en haut du Makefile.
Ensuite tapez simplement make sur Linux et OSX.
Sur BSD, vous devez installer GNU make et invoquer gmake à la place.
Sur Windows, vous devez installer cygwin et sélectionner les paquets appropriés gcc, gcc-g++, make et git.
Sur Linux, PSC utilisera des pseudo-terminaux Unix98, sur d'autres systèmes, il utilisera des pty POSIX mais cela devrait vous être transparent. J'ai ajouté un jour le support des pty 4.4BSD et SunOS à l'âge de pierre pour une raison particulière, donc il peut ou non se compiler même avec Solaris.
fièrement sponsorisé par :
Simple et direct. Sur votre machine locale, exécutez pscl, et passez les ports TCP ou UDP que vous souhaitez transférer du site distant vers une adresse particulière. Par exemple :
linux:~ > ./pscl -T 1234:[192.168.0.254]:22 -U 1234:[8.8.8.8]:53
PortShellCrypter [pscl] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: set up local TCP port 1234 to proxy to 192.168.0.254:22 @ remote.
pscl: set up local UDP port 1234 to proxy to 8.8.8.8:53 @ remote.
pscl: Waiting for [pscr] session to appear ...
linux:~ >
[ UART / SSH / ... login to remote side ... ]
Sur le site distant (le dernier saut) avec la session shell, peu importe qu'il s'agisse d'un port-shell, SSH, login console etc, vous exécutez pscr :
linux:~ > ./pscr
PortShellCrypter [pscr] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: Seen STARTTLS sequence, enabling crypto.
linux:~ >
Une fois que vous exécutez pscr, les deux extrémités établissent une poignée de main cryptographique et ajoutent un protocole supplémentaire sur votre session existante qui est transparent pour vous. Vous pouvez ensuite vous connecter à 127.0.0.1:1234 sur votre machine locale pour atteindre 192.168.0.254:22 via TCP ou le résolveur 8.8.8.8 via UDP. Cela fonctionne également avec les adresses [IPv6], si le site distant a une connectivité IPv6. En fait, vous pouvez même l'utiliser pour traduire un logiciel IPv4 en IPv6, puisque vous vous connectez toujours à 127.0.0.1 côté local.
Vous pouvez passer plusieurs paramètres -T et -U. Si vous ne savez plus si votre session est déjà chiffrée de bout en bout, vous pouvez envoyer un SIGUSR1 au processus local pscl, et il vous le dira.
PSC est également utile si vous souhaitez utiliser tor depuis un shell SSH distant, où vous pouvez transférer le port socks5 et le port DNS vers l'adresse 127.0.0.1 de l'hôte distant. Comme SSH ne transfère pas les paquets UDP, vous utiliseriez normalement deux connecteurs socat ou similaire pour résoudre via le nœud tor. PSC a l'avantage de conserver les limites des datagrammes UDP, alors que socat via SSH -L peut briser les limites des datagrammes et créer des requêtes DNS mal formées.
La session sera chiffrée avec aes_256_ctr d'une PSK que vous choisissez dans le Makefile. Ce schéma cryptographique est malléable, mais l'ajout de données AAD ou OAD augmente la taille des paquets, où chaque compte de bytes, car sur les sessions interactives et en raison du codage Base64, chaque caractère tapé provoque déjà l'envoi de beaucoup plus de données.
Les sessions UART peuvent être utilisées via screen mais par exemple pas via minicom car minicom crée des fenêtres invisibles avec des lignes de statut et agit comme un filtre qui détruit le protocole de PSC. PSC essaie de détecter le filtrage et peut tolérer une certaine altération des données, mais dans certaines situations, il est impossible de récupérer. Chose similaire avec tmux. Vous devriez éviter d'empiler des gestionnaires de pty avec PSC qui modifient/traitent trop leurs données entrantes.
La variable d'environnement SHELL doit être définie pour pscl et pscr afin que PSC sache quel shell exécuter sur le pty. SHELL est défini dans la plupart des environnements par défaut, mais dans le cas contraire, PSC doit être exécuté comme SHELL=/bin/bash pscl etc.
pscl supporte également le forwarding de connexions TCP via SOCKS4 (-4 port) et SOCKS5 (-5 port). Cela paramètre port comme port SOCKS pour les connexions TCP, de sorte que vous pouvez par exemple parcourir des réseaux distants depuis une session port-shell sans avoir besoin d'ouvrir aucune autre connexion pendant un test d'intrusion. Si vous passez -N à pscl, cela active la résolution de noms DNS côté distant, vous pouvez donc aussi utiliser chrome avec. Mais attention : il y a un problème de confidentialité avec les navigateurs qui tentent de résoudre une séquence de noms DNS au démarrage qui n'est pas sous votre contrôle. De plus, si votre site distant a une configuration DNS défaillante, votre shell de saisie peut se bloquer pendant plusieurs secondes si les paquets de réponse DNS sont manquants. Il n'y a pas de bonnes fonctions de résolveur asynchrones qui soient intégrables et portables, j'ai donc dû me fier à getaddrinfo() dans un seul thread au prix de possibles blocages de plusieurs secondes si des problèmes DNS existent. C'est pourquoi la résolution de noms doit être activée explicitement. pscr essaie de minimiser ce problème potentiel avec des caches de recherche DNS, donc dans la plupart des situations, cela devrait fonctionner sans problème. Si vous passez -X adresse-IP (doit être le premier argument), vous pouvez lier votre proxy local à une adresse différente de 127.0.0.1, afin de partager le proxy dans votre réseau local.
Les fonctionnalités de psc permettent de transférer des connexions TCP ou des blobs de données binaires depuis/vers des appareils distants à travers plusieurs sauts même s'il n'est pas possible d'installer le binaire pscr sur le site distant. Cela est très utile à des fins de criminalistique si vous n'avez aucun moyen de télécharger autrement des artefacts depuis l'appareil (qui peut être un téléphone connecté via UART par exemple) ou si vous devez transférer des connexions sans toucher au système de fichiers pour ne pas détruire les preuves sur le système ou lorsque le système de fichiers racine est monté en lecture seule et que vous ne pouvez pas télécharger votre ensemble d'outils.
C'est une fonctionnalité vraiment intéressante, car vous pouvez voir votre connexion TCP sauter à travers votre tty local vers une machine distante sans avoir besoin d'installer quoi que ce soit à distance.
Cela fonctionne uniquement par du punkrock pty local et le passage d'une commande de rebond à pscl qu'il déposera sur le shell distant (sans que pscr ne tourne) et une certaine magie de machine d'état qui filtre et traite les données côté local. Cela nécessite généralement de mettre le pty distant en mode brut d'abord avant d'émettre la commande réelle et quelques autres détails qui sont passés à -B. L'argument est divisé en les parties suivantes :
:, par exemple 1234:.stty -echo raw ou python -c "import tty;tty.setraw(0)" (faites attention aux guillemets, car -B doit aussi être entre guillemets) ou tout autre similaire.pscl de commencer à envoyer des données pour éviter une condition de concurrence entre l'exécution réelle de stty et le début de la commande, par exemple un echo GO est parfait.nc 127.0.0.1 22 pour rebondir le port local 1234 vers le serveur SSH distantpscl de réinitialiser son état tty. echo FIN fera l'affaire. Recommandé, car sinon vous pourriez avoir du mal à reconnaître la fin de votre commande.Exemples :
Si vous souhaitez transférer une connexion TCP, cet exemple nécessite stty et nc installés sur l'appareil, mais théoriquement, cela pourrait être n'importe quoi d'autre qui fait l'équivalent.
Démarrer une session locale :
./pscl -B '1234:[stty -echo raw;echo GO;nc example.com 22;echo FIN]'
Cela émettra la commande stty -echo raw;echo GO;nc example.com 22;echo FIN vers l'appareil distant si vous vous connectez localement au port 1234, puis transfère simplement toutes les données qu'il voit dans les deux sens et limite le débit pour ne pas dépasser la vitesse tty de l'appareil (115200 par défaut).
Lorsque la session pscl est démarrée, connectez-vous à l'appareil distant par UART, ssh -e none ... ou autre, et une fois que vous avez le shell distant, tapez également localement : ssh [email protected] -p 1234 pour rebondir la connexion SSH de votre machine locale à travers l'appareil distant vers la destination example.com. Bien sûr, la variante pscr est préférée car -B ne peut rebondir qu'une seule connexion à la fois (bien que vous puissiez passer plusieurs commandes -B pour différents transferts) et il y a un risque que le shell se bloque après la session TCP car le pty est en mode raw -echo et selon que le pair distant final ferme également la connexion, il se peut que le shell se bloque juste après. Si vous voyez une notification pscl indiquant que la connexion est terminée et que vous voyez une invite, vous devez reset celle-ci, afin qu'une nouvelle connexion puisse être démarrée. Pendant le transfert des données, vous verrez des notifications ASCII 7 bits < et > dans pscl qui sont juste locales pour faciliter le débogage et la détection de progression.
Notez que la connexion vers le site distant doit être propre en 8 bits, c'est-à-dire que le canal ssh, telnet, UART ou autre ne doit pas gérer les séquences d'échappement (contrairement à l'utilisation de pscr). Pour les connexions ssh, cela signifie que vous devez utiliser ssh -e none dans la session pscl.
Ensuite, voici quelques exemples pour gérer le transfert de fichiers binaires où rfile désigne le fichier distant et lfile le fichier local.
Pour démarrer une session pour déposer des fichiers distants, localement :
./pscl -B '1234:[stty -echo raw;echo GO;dd of=rfile.bin bs=1 count=7350;echo FIN]'
Où vous devez spécifier la quantité de données que le côté distant attend. Cela fonctionnerait aussi sans (par exemple cat>...) mais alors la session se bloquera après la fin de la transmission car cat attend indéfiniment une entrée. En utilisant dd count=..., vous obtiendrez une sortie propre et serez notifié par le marqueur FIN.
Ensuite, ssh ou tout ce qui est nécessaire pour obtenir un shell sur l'appareil distant depuis la session pscl qui vient d'être démarrée. Sur un deuxième terminal localement :
dd if=lfile.bin|nc 127.0.0.1 1234
ce qui se connectera au port local 1234 de pscl et déclenchera la commande de vidage sur le côté distant, transférant les données binaires du lfile.bin local vers le rfile.bin distant. En raison de la limitation de débit, cela peut prendre un certain temps et vous ne faites confiance qu'à votre écran de progression psc pour savoir si le transfert est terminé. La commande locale dd ...|nc ... ne vous montrera que l'état local qui peut engloutir des fichiers entiers en millisecondes en raison des tampons TCP locaux pendant que le fichier est encore en cours de transfert via le pty. Assurez-vous donc de n'appuyer sur Ctrl-C que lorsque l'écran pscl vous indique que c'est fini ou que vous voyez le marqueur de fin FIN vous être renvoyé sur la session dd ...|nc ....
De même, des commandes similaires pourraient être utilisées pour transférer des données binaires d'un appareil distant vers la machine locale à des fins de criminalistique. Encore une fois, démarrage de la session localement :
./pscl -B '1234:[stty -echo raw;echo GO;dd if=rfile.bin]' ou
./pscl -B '1234:[stty -echo raw;echo GO;cat rfile.bin]'
Ensuite, ssh vers l'appareil distant pour obtenir le shell, puis à nouveau localement :
nc 127.0.0.1 1234|dd of=lfile.bin bs=1 count=7350
Pour obtenir rfile.bin de taille 7350 copié dans le fichier local lfile.bin
Si stty -echo raw n'est pas disponible sur l'appareil, quelque chose comme python -c "import tty;tty.setraw(0)" fonctionne aussi. Notez que sur l'appareil distant, vous devez avoir un tty (pas seulement un port-shell) lorsque vous utilisez des commandes de rebond, car la commande stty pour définir le mode brut nécessite un vrai tty.
Si psc fonctionne sur une connexion série, des bits perdus peuvent gâcher tout le plaisir. Si vous fonctionnez sans contrôle de flux matériel, vous finirez par subir des pertes de bits et des connexions bloquées, en particulier car il n'y a pas d'étranglement lorsque l'appareil envoie des données dans votre direction lors de l'utilisation de commandes de rebond. Déverser des données vers l'appareil fonctionne mieux car ces données passent par les limites de débit de pscl.
Cependant, voici quelques astuces qui ont fonctionné pour moi dans des circonstances où il n'est pas possible d'utiliser pscr sur l'appareil et le contrôle de flux matériel. Cela s'applique uniquement lors de l'utilisation d'UART, car c'est un canal de transport potentiellement peu fiable.
pscr sur l'appareil afin de pouvoir définir une limitation de débit pour les données envoyées dans votre direction. Comme la direction vers l'appareil est toujours limitée en débit, vous pouvez utiliser des commandes de rebond pour déverser un binaire pscr cross-compilé sur l'appareil et démarrer une session bidirectionnelle limitée en débit avec lui.tio -o 1 ou -o 2 pour ajouter des délais entre les octets de sortie envoyés38400 même si la ligne série est réglée sur 115200)psc avec -DRESPECT_UART_BUFSIZE=4096, cependant cela rendra la session très lenteDans le dossier contrib, vous trouverez également un patch tio-noprefix pour désactiver le traitement des caractères d'échappement mais ce patch n'est nécessaire que pour les versions plus anciennes, car l'amont a déjà accepté et intégré ce patch. Je recommande vraiment d'utiliser tio lors de l'utilisation d'UART.
Lors de l'utilisation de commandes de rebond via tio, vous devez ajouter à votre fichier ~/.tioconfig :
[default]
prefix-ctrl-key = none
ce qui désactive la gestion des ESC et vous donne un canal 8 bits propre.
Vous pouvez envoyer SIGUSR1 à pscl pour qu'il vous dise si la session est chiffrée. Si le pscr distant meurt ou se termine sans possibilité de le signaler à la partie locale, pscl restera en mode chiffrement et donc se bloquera. Dans ce cas, vous pouvez forcer une réinitialisation en mode texte clair en envoyant SIGUSR2, afin qu'une nouvelle session puisse être démarrée.
À partir de la version 0.64, psc supporte les sockets de script, de sorte que vous n'avez plus besoin de screen pour obtenir/envoyer des fichiers ou déverser des tampons de collage vers la console distante. Au lieu de cela, vous démarrez votre session locale comme ceci :
~ > ./pscl -S ~/psc.script_sock
Vous pouvez ensuite l'utiliser comme avant. Si vous avez besoin de 'coller' quelque chose, faites comme ceci :
~ > ./pscsh -S ~/psc.script_sock -f script_/helloworld
Cela va 'taper' le contenu de script_/helloworld sur la console. Pendant le script, l'entrée standard de pscl est bloquée afin que l'entrée injectée ne se mélange pas avec la frappe. Si -S est omis dans pscsh, ~/psc.script_sock est utilisé automatiquement. Pour des raisons de sécurité, les scripts doivent commencer par le préfixe script_.
En prime, pscr contient désormais la capacité de encoder/décoder en base64 des fichiers, même avec des caractères CR intégrés pour plus de commodité. Il est compatible avec uuencode -m.
; et mises entre crochets.