psc
1.0.0
Ce projet - ainsi que son projet frère crash - appartient à mon ensemble d'outils anti-censure qui permet de configurer des shells cryptés entièrement fonctionnels et le transfert TCP/UDP dans des environnements de censure hostiles. Il est également utile pour la médecine légale de vider les données des appareils 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 e2e des sessions shell, à sauts simples ou multiples, en étant indépendant du transport sous-jacent, à condition qu'il soit fiable et qu'il puisse envoyer/recevoir des données codées en Base64 sans modification/filtrage. Avec le pty e2e que vous recevez (par exemple dans un port-shell), vous pouvez transférer les connexions TCP et UDP, similaire au paramètre -L d'OpenSSH. Cela fonctionne de manière transparente et sans avoir besoin d'une adresse IP attribuée localement au point de départ. Cela permet aux légistes et aux pen-testeurs de créer des connexions réseau, par exemple via :
adb shell , si l'OEM adbd ne prend pas en charge le transfert TCPImaginez simplement que vous ayez une session ppp invisible dans votre session shell, sans que l'homologue distant ne prenne réellement en charge ppp.
Il fonctionne sous Linux, Android, OSX, Windows, FreeBSD, NetBSD et (éventuellement) OpenBSD .
PSC inclut également la prise en charge des proxys SOCKS4 et SOCKS5 afin d'avoir de véritables sessions de navigation Web via des shells de ports ou des connexions par modem à distance.
Modifiez le Makefile pour refléter vos clés pré-partagées, telles que définies en haut du Makefile .
Ensuite, tapez simplement make sous Linux et OSX .
Sur BSD, vous devez installer GNU make et appeler gmake à la place.
Sous Windows, vous devez installer cygwin et sélectionner les packages gcc, gcc-g++, make et git appropriés.
Sous Linux , PSC utilisera des pseudo-terminaux Unix98 , sur d'autres systèmes, il utilisera des pty POSIX mais cela devrait être transparent pour vous. J'ai ajouté une fois le support de 4.4BSD pty et SunOS à l'âge de pierre pour une raison particulière, donc il peut ou non être construit même avec Solaris .
fièrement sponsorisé par :
Clair et simple. Sur votre machine locale, exécutez pscl et transmettez tous 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 si c'est dans un port-shell, SSH, une connexion à la 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 avez exécuté pscr , les deux extrémités établissent une poignée de main cryptographique et établissent 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 box 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 dispose d'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 transmettre plusieurs paramètres -T et -U . Si vous avez perdu la trace si votre session est déjà cryptée e2e, vous pouvez envoyer un SIGUSR1 au processus pscl local, et il vous le dira.
PSC est également utile si vous souhaitez utiliser Tor à partir d'un shell SSH distant, où vous pouvez transférer les chaussettes5 et le port DNS vers l'adresse 127.0.0.1 des hôtes distants. Étant donné que SSH ne transmet pas les paquets UDP, vous utiliserez normalement deux connecteurs socat ou similaires pour résoudre via le nœud tor. PSC a l'avantage de conserver les limites du datagramme UDP, tandis que socat sur SSH -L peut briser les limites du datagramme et créer des requêtes DNS mal formées.
La session sera chiffrée avec aes_256_ctr d'un PSK que vous choisissez dans le Makefile . Ce schéma de chiffrement est malléable, mais l'ajout de données AAD ou OAD fait exploser la taille du paquet, où chaque octet compte puisque sur les sessions interactives et en raison de l'encodage Base64, chaque caractère tapé entraîne 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 puisque minicom créera des fenêtres invisibles avec des lignes d'état et agira comme un filtre qui détruit le protocole de PSC. PSC essaie de détecter le filtrage et peut supporter une certaine quantité de données altérées, mais dans certaines situations, il n'est pas possible de les récupérer. C'est la même chose avec tmux . Vous devez éviter d'empiler les gestionnaires pty avec PSC qui gâchent/gèrent trop leurs données entrantes.
La variable d'environnement SHELL doit être définie à la fois pour pscl et pscr afin que PSC sache quel shell exécuter sur le pty. SHELL est défini par défaut dans la plupart des environnements, mais dans le cas contraire, PSC doit être exécuté comme SHELL=/bin/bash pscl etc.
pscl prend également en charge le transfert des connexions TCP via SOCKS4 ( -4 port ) et SOCKS5 ( -5 port ). Cela configure le port en tant que port SOCKS pour les connexions TCP, ainsi, par exemple, vous pouvez parcourir les réseaux distants à partir d'une session port-shell sans avoir besoin d'ouvrir une autre connexion pendant un test d'intrusion. Si vous transmettez -N à pscl , cela active la résolution de nom DNS du côté distant, vous pouvez donc également utiliser Chrome avec. Mais attention : il existe 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 côté distant a une configuration DNS défectueuse, votre shell de saisie peut se bloquer pendant plusieurs secondes si les paquets de réponse DNS sont manquants. Il n'existe pas de bonnes fonctions de résolution asynchrone intégrables et portables, j'ai donc dû m'appuyer sur getaddrinfo() dans le thread unique au prix d'éventuels blocages pendant plusieurs secondes en cas de problèmes DNS. C'est pourquoi la résolution de noms doit être activée explicitement. pscr essaie cependant de minimiser ce problème potentiel avec les caches de recherche DNS, donc dans la plupart des situations, cela devrait fonctionner sans douleur. Si vous transmettez -X IP-address (doit être le premier argument), vous pouvez lier votre proxy local à une adresse différente de 127.0.0.1 , afin de pouvoir partager le proxy sur votre réseau local.
Les fonctionnalités psc permettent aux connexions TCP ou aux blobs de données binaires d'être transférées depuis/vers des périphériques distants sur plusieurs sauts, même s'il n'est pas possible d'installer le binaire pscr sur le site distant. Ceci est très utile à des fins médico-légales si vous ne disposez d'aucun moyen pour télécharger des artefacts à partir de l'appareil (qui peut être un téléphone connecté UART par exemple) ou si vous devez transférer des connexions sans toucher au FS pour ne pas détruire les preuves sur le système ou lorsque le root-FS est monté sur ro et vous ne pouvez pas télécharger votre ensemble d'outils.
Il s'agit d'une fonctionnalité vraiment intéressante, car vous pouvez voir votre connexion TCP passer par votre terminal local vers une boîte distante sans avoir besoin d'installer quoi que ce soit à distance.
Cela fonctionne uniquement en pty punkrock local et en transmettant une commande de rebond à pscl qu'elle déposera sur le shell distant (sans pscr en cours d'exécution) et une certaine magie du moteur d'état qui filtre et gère les données du côté local. Habituellement, cela nécessite de définir d'abord le pty distant en mode brut avant d'émettre la commande réelle et d'autres détails qui sont transmis à -B . L’argumentation est divisée en parties suivantes :
: , par exemple 1234: .stty -echo raw ou python -c "import tty;tty.setraw(0)" (veillez à bien mettre les guillemets, car -B doit également être cité) ou quelque chose de similaire.pscl de commencer à envoyer des données pour éviter une course entre stty et le début de la cmd, par exemple un echo GO est parfait.nc 127.0.0.1 22 pour renvoyer le port local 1234 vers le serveur SSH distantpscl de réinitialiser son état tty. echo FIN le fera. Recommandé, sinon vous pourriez avoir du mal à reconnaître la fin de votre commande.; et mis entre parenthèses.Exemples :
Si vous souhaitez transférer une connexion TCP, cet exemple nécessite que stty et nc soient installés sur l'appareil, mais il pourrait théoriquement s'agir de tout autre élément équivalent.
Démarrez 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 au périphérique distant si vous vous connectez localement au port 1234, puis transférez simplement toutes les données qu'il voit dans les deux sens et limitez le débit du trafic. elle ne dépassera pas la vitesse tty des appareils (115 200 est la valeur par défaut).
Lorsque la session pscl est démarrée, connectez-vous au périphérique distant par UART, ssh -e none ... ou quoi que ce soit et une fois que vous avez le shell distant, tapez également localement :
ssh [email protected] -p 1234 pour renvoyer la connexion SSH de votre boîtier local via 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 transmettre plusieurs commandes -B pour différents transferts) et il y a une chance de suspendre le shell après la session TCP puisque le pty est en raw -echo et selon que le homologue distant final ferme également la connexion, il se peut que le shell se bloque après cela. Si vous trouvez une notification pscl indiquant que la connexion est terminée et que vous voyez une invite, vous devez la reset afin qu'une nouvelle connexion puisse être démarrée. Pendant le transfert des données, vous verrez des notifications ASCII < et > 7 bits dans pscl qui sont simplement locales pour faciliter le débogage et la détection de la progression.
Notez que la connexion au site distant doit être propre sur 8 bits, c'est-à-dire que le canal ssh, telnet, UART ou tout autre canal ne doit pas gérer les séquences d'échappement (contrairement à l'utilisation pscr ). Pour les connexions ssh, cela signifie que vous devez utiliser ssh -e none dans la session pscl .
Ensuite, suivez quelques exemples pour gérer le fichier binaire xfer où rfile désigne le fichier distant et lfile le fichier local.
Pour démarrer une session afin de supprimer 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 attendue par le côté distant. Cela fonctionnerait également sans (par exemple cat>... ), mais la session se bloquerait une fois la transmission terminée, car cat attend sans cesse une entrée. En utilisant dd count=... , vous obtiendrez une sortie propre et en serez averti par le marqueur FIN.
Ensuite, ssh ou tout ce qui est nécessaire pour obtenir un shell sur le périphérique distant à partir de la session pscl qui vient de démarrer. Sur un deuxième terminal en local :
dd if=lfile.bin|nc 127.0.0.1 1234
qui se connectera au port local 1234 de pscl et déclenchera la commande dump du côté distant, transmettant les données binaires du lfile.bin local aux rfile.bin distants. En raison de la limitation du débit, cela peut prendre un certain temps et vous ne faites confiance à votre écran de progression psc que si le transfert est terminé. La commande locale dd ...|nc ... vous montrera uniquement l'état local qui peut consommer des fichiers entiers en ms en raison des tampons TCP locaux pendant que le fichier est toujours en cours de transfert via le pty. Assurez-vous donc de n'appuyer sur Ctrl-C que lorsque l'écran pscl vous indique qu'il est terminé ou que vous voyez le marqueur de fin FIN vous être renvoyé lors de 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 boîte locale à des fins d'investigation. Encore une fois, début de la séance en local :
./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, connectez-vous en SSH au périphérique 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 également. Notez que sur le périphérique distant, vous devez disposer d'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 via une connexion série, les bits perdus peuvent tuer tout votre plaisir. Si vous exécutez sans HW FC, vous finirez par rencontrer des pertes de bits et des connexions bloquées, en particulier car il n'y a pas de limitation lorsque l'appareil envoie des données dans votre direction lors de l'utilisation de commandes de rebond . Le transfert de données vers l'appareil fonctionne mieux car ces données dépassent les limites de débit pscl .
Cependant, voici quelques conseils qui ont fonctionné pour moi dans des circonstances où il n'est pas possible d'utiliser pscr sur l'appareil et HW FC. Cela s'applique uniquement lors de l'utilisation d'UART, car il s'agit d'un canal de transport potentiellement peu fiable.
pscr sur l'appareil afin de pouvoir définir une limite de débit pour les données envoyées dans votre direction. Comme la direction vers le périphérique est toujours à débit limité, vous pouvez utiliser des commandes de rebond pour transférer un binaire pscr compilé de manière croisée sur le périphérique et démarrer une session bidirectionnelle à débit limité avec celui-ci.tio -o 1 ou -o 2 pour ajouter des délais entre les octets de sortie envoyés38400 bien que la ligne série ait défini 115200 )psc avec -DRESPECT_UART_BUFSIZE=4096 , mais cela rendra la session très lente Dans le dossier contrib , vous trouverez également un correctif tio-noprefix pour désactiver le traitement des caractères d'échappement, mais ce correctif n'est nécessaire que pour les anciennes versions, car en amont a déjà accepté et intégré ce correctif. Je recommande vraiment d'utiliser tio lors de l'utilisation d'UART.
Lorsque vous utilisez des commandes de rebond sur tio , vous devez ajouter à votre fichier ~/.tioconfig :
[default]
prefix-ctrl-key = none
qui désactive la gestion ESC et vous donne un canal clair de 8 bits.
Vous pouvez envoyer SIGUSR1 à pscl pour qu'il vous indique si la session est cryptée. Si le pscr distant meurt ou se ferme sans possibilité de le signaler à la partie locale, pscl restera en mode cryptage et se bloquera donc. Dans ce cas, vous pouvez forcer une réinitialisation en mode texte brut en envoyant SIGUSR2 , afin qu'une nouvelle session puisse être démarrée.
Depuis la version 0.64, psc prend en charge les sockets de script, vous n'avez donc plus besoin screen pour obtenir/mettre des fichiers ou vider les tampons de collage sur la console distante. Au lieu de cela, vous démarrez votre session locale comme ceci :
~ > ./pscl -S ~/psc.script_sock
Vous pouvez ensuite continuer et l’utiliser comme avant. Si vous avez besoin de « coller » quelque chose que vous aimez :
~ > ./pscsh -S ~/psc.script_sock -f script_/helloworld
Cela « tapera » le contenu de script_/helloworld sur la console. Pendant l'écriture du script, le stdin de pscl est bloqué afin que l'entrée injectée ne se mélange à aucune saisie. 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 possibilité de décoder des fichiers en base64, même avec des caractères CR intégrés pour plus de commodité. Il est compatible avec uuencode -m .
