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.