stealth/pscСквозное шифрование для многошаговых tty-сессий или портшеллов + проброс TCP/UDP портов
Данный проект, как и его сестринский проект crash, относится к моему набору инструментов для борьбы с цензурой, который позволяет настроить полностью рабочие зашифрованные оболочки и пересылку TCP/UDP во враждебных цензурирующих средах. Он также полезен в криминалистике для извлечения данных с устройств через UART или adb, когда другие средства недоступны.
DNS-запрос и SSH-сессия, пересылаемые через UART-соединение к Pi
PSC позволяет сквозное шифрование сессий оболочки, одно- или многошаговое, независимо от базового транспорта, при условии, что он надёжен и может отправлять/принимать данные в кодировке Base64 без модификации/фильтрации. Наряду с сквозным pty (который вы получаете, например, внутри портовой оболочки), вы можете пересылать TCP и UDP соединения, аналогично параметру -L в OpenSSH. Это работает прозрачно и без необходимости наличия IP-адреса, назначенного локально в начальной точке. Это позволяет криминалистам и пентестерам создавать сетевые соединения, например, через:
adb shell-сессии, если OEM adbd не поддерживает пересылку TCPПредставьте, что у вас есть невидимая ppp-сессия внутри вашей сессии оболочки, без того, чтобы удалённый peer фактически поддерживал ppp.
Работает на Linux, Android, OSX, Windows, FreeBSD, NetBSD и (возможно) OpenBSD.
PSC также включает поддержку прокси SOCKS4 и SOCKS5 для возможности полноценного просмотра веб-страниц через портовые оболочки или модемные дозвоны удалённо.
Отредактируйте Makefile, чтобы указать ваши предварительно распределённые ключи, определённые в верхней части Makefile.
Затем просто выполните make на Linux и OSX.
На BSD необходимо установить GNU make и выполнить gmake.
На Windows необходимо установить cygwin и выбрать соответствующие пакеты gcc, gcc-g++, make и git.
На Linux PSC будет использовать псевдотерминалы Unix98, на других системах — POSIX pty, но это должно быть прозрачно для вас. Когда-то давно я добавил поддержку 4.4BSD pty и SunOS по особой причине, так что он может собираться даже на Solaris.
с гордостью спонсируется:
Просто и понятно. На вашей локальной машине выполните pscl и передайте любые TCP или UDP порты, которые вы хотите пересылать из удалённого сайта на определённый адрес. Например:
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 ... ]
На удалённом сайте (последний прыжок) с сессией оболочки, независимо от того, находится ли она в портовой оболочке, SSH, консольном входе и т.д., вы выполняете pscr:
linux:~ > ./pscr
PortShellCrypter [pscr] v0.60 (C) 2006-2020 stealth -- github.com/stealth/psc
pscl: Seen STARTTLS sequence, enabling crypto.
linux:~ >
Как только вы выполните pscr, оба конца установят криптографическое рукопожатие и наложат дополнительный протокол поверх вашей существующей сессии, который для вас прозрачен. Затем вы можете подключиться к 127.0.0.1:1234 на вашей локальной машине, чтобы добраться до 192.168.0.254:22 по TCP или до резолвера 8.8.8.8 по UDP. Это также работает с адресами [IPv6], если удалённый сайт имеет IPv6-подключение. Фактически, вы можете даже использовать это для перевода IPv4-программного обеспечения на IPv6, так как вы всегда подключаетесь к 127.0.0.1 на локальной стороне.
Вы можете передавать несколько параметров -T и -U. Если вы потеряли отслеживание того, зашифрована ли ваша сессия сквозным шифрованием, вы можете отправить SIGUSR1 локальному процессу pscl, и он сообщит вам об этом.
PSC также полезен, если вы хотите использовать tor из удалённой SSH-оболочки, где вы можете переслать порт socks5 и DNS на адрес 127.0.0.1 удалённого хоста. Поскольку SSH не пересылает UDP-пакеты, обычно вы используете два соединителя socat или подобное для разрешения через узел tor. PSC имеет преимущество сохранения границ UDP-датаграмм, в то время как socat через SSH -L может нарушить границы датаграмм и создать некорректные DNS-запросы.
Сессия будет зашифрована с помощью aes_256_ctr от PSK, который вы выбираете в Makefile. Эта криптосхема пластична, но добавление данных AAD или OAD увеличивает размер пакета, где каждый байт имеет значение, так как при интерактивных сессиях и из-за кодировки Base64 каждый введённый символ уже вызывает отправку гораздо большего объёма данных.
UART-сессии могут использоваться через screen, но, например, не через minicom, так как minicom создаёт невидимые окна со строками состояния и действует как фильтр, разрушающий протокол PSC. PSC пытается обнаружить фильтрацию и может выдерживать определённое количество искажения данных, но в некоторых ситуациях восстановление невозможно. Аналогичная ситуация с tmux. Следует избегать наложения обработчиков pty с PSC, которые слишком сильно изменяют/обрабатывают входящие данные.
Переменная окружения SHELL должна быть задана как для pscl, так и для pscr, чтобы PSC знал, какую оболочку выполнять на pty. В большинстве сред SHELL установлена по умолчанию, но если это не так, PSC нужно запускать как SHELL=/bin/bash pscl и т.д.
pscl также поддерживает пересылку TCP-соединений через SOCKS4 (-4 порт) и SOCKS5 (-5 порт). Это настраивает порт как SOCKS-порт для TCP-соединений, так что, например, вы можете просматривать удалённые сети из портовой сессии оболочки без необходимости открывать другое соединение во время пентеста. Если вы передаёте -N в pscl, то он включает разрешение DNS-имён на удалённой стороне, так что вы также можете использовать chrome с этим. Но будьте предупреждены: существует проблема конфиденциальности с браузерами, которые пытаются разрешить последовательность DNS-имён при запуске, которая не находится под вашим контролем. Кроме того, если на вашей удалённой стороне сломанная настройка DNS, ваша печатающая оболочка может блокироваться на несколько секунд, если отсутствуют DNS-ответные пакеты. Нет хороших асинхронных функций резолвера, которые были бы встраиваемыми и переносимыми, поэтому мне пришлось полагаться на getaddrinfo() в одном потоке ценой возможных блокировок на несколько секунд при проблемах с DNS. Поэтому разрешение имён должно быть явно включено. pscr старается минимизировать эту потенциальную проблему с помощью кэша DNS-запросов, так что в большинстве ситуаций всё должно работать безболезненно.
Если вы передаёте -X IP-адрес (должен быть первым аргументом), вы можете привязать свой локальный прокси к адресу, отличному от 127.0.0.1, так что вы сможете делиться прокси в своей локальной сети.
psc позволяет пересылать TCP-соединения или двоичные блоки данных от/к удалённым устройствам через несколько прыжков, даже если невозможно установить двоичный файл pscr на удалённом сайте. Это очень полезно для криминалистических целей, если у вас нет других средств для загрузки артефактов с устройства (например, подключенного по UART телефона) или если нужно пересылать соединения, не затрагивая файловую систему, чтобы не уничтожать улики на системе, или когда корневая ФС смонтирована только для чтения и вы не можете загрузить свой инструментарий.
Это действительно классная функция, так как вы можете видеть, как ваше TCP-соединение прыгает через ваш локальный tty на удалённую машину без необходимости установки чего-либо удалённо.
Это работает исключительно за счёт локального pty punkrock и передачи команды отскока в pscl, которую он отправит на удалённую оболочку (без запущенного pscr), а также некоторой магии конечного автомата, которая фильтрует и обрабатывает данные на локальной стороне. Обычно это требует сначала установки удалённого pty в сырой режим перед выполнением фактической команды и некоторых других деталей, которые передаются в -B. Аргумент разбивается на следующие части:
:, например 1234:.stty -echo raw или python -c "import tty;tty.setraw(0)" (будьте внимательны с кавычками, так как -B также нужно заключать в кавычки) или что-то подобное.pscl начать отправку данных, чтобы избежать гонки между фактическим выполнением stty и началом команды, например echo GO идеально.nc 127.0.0.1 22 для отскока локального порта 1234 на SSH-сервер удалённого устройства.pscl сбросить состояние tty. Подойдёт echo FIN. Рекомендуется, иначе у вас могут возникнуть проблемы с распознаванием окончания вашей команды.Примеры:
Если вы хотите переслать TCP-соединение, в этом примере на устройстве должны быть установлены stty и nc, но теоретически это может быть что угодно, выполняющее эквивалентную работу.
Запустите локальную сессию:
./pscl -B '1234:[stty -echo raw;echo GO;nc example.com 22;echo FIN]'
Это отправит команду stty -echo raw;echo GO;nc example.com 22;echo FIN на удалённое устройство, если вы подключитесь локально к порту 1234, а затем просто пересылает любые данные в обе стороны, ограничивая трафик, чтобы он не превышал скорость tty устройства (по умолчанию 115200).
Когда сессия pscl запущена, подключитесь к удалённому устройству по UART, ssh -e none ... или как угодно, и как только у вас появится удалённая оболочка, также введите локально:
ssh [email protected] -p 1234 чтобы отскочить SSH-соединение от вашей локальной машины через удалённое устройство к месту назначения example.com. Конечно, предпочтительнее вариант с pscr, так как -B может отскакивать только одно соединение за раз (хотя вы можете передавать несколько команд -B для различных пересылок), и есть вероятность зависания оболочки после TCP-сессии, так как pty находится в режиме raw -echo, и в зависимости от того, закроет ли конечный удалённый peer соединение, оболочка может просто зависнуть после этого. Если вы случайно увидите уведомление pscl о завершении соединения и увидите приглашение, вы должны выполнить reset, чтобы можно было запустить новое соединение. Во время пересылки данных вы будете видеть уведомления 7-битных ASCII < и > в pscl, которые являются локальными для упрощения отладки и отслеживания прогресса.
Обратите внимание, что соединение с удалённым сайтом должно быть 8-битным чистым, т.е. канал ssh, telnet, UART или любой другой не должен обрабатывать управляющие последовательности (в отличие от использования pscr). Для SSH-соединений это означает, что вы должны использовать ssh -e none в сессии pscl.
Далее несколько примеров для обработки передачи двоичных файлов, где rfile обозначает удалённый файл, а lfile — локальный.
Чтобы запустить сессию для сброса удалённых файлов, локально:
./pscl -B '1234:[stty -echo raw;echo GO;dd of=rfile.bin bs=1 count=7350;echo FIN]'
Здесь нужно указать количество данных, которое ожидает удалённая сторона. Можно также обойтись без этого (например, cat>...), но после завершения передачи сессия зависнет, так как cat бесконечно ждёт ввод. Используя dd count=..., вы получите чистый выход и будете уведомлены о нём маркером FIN.
Затем ssh или что-то необходимое для получения оболочки на удалённом устройстве из только что запущенной сессии pscl. На втором терминале локально:
dd if=lfile.bin|nc 127.0.0.1 1234
Это подключится к локальному порту 1234 pscl и запустит команду дампа на удалённой стороне, пересылая двоичные данные локального lfile.bin в удалённый rfile.bin. Из-за ограничения скорости это может занять некоторое время, и доверяйте только экрану прогресса psc, чтобы узнать, завершена ли передача. Локальная команда dd ...|nc ... покажет вам только локальный статус, который может съесть целые файлы за миллисекунды из-за локальных TCP-буферов, пока файл ещё передаётся через pty. Поэтому убедитесь, что вы нажимаете Ctrl-C только тогда, когда экран pscl сообщит о завершении, или вы увидите завершающий маркер FIN, передаваемый обратно в сессию dd ...|nc ....
Аналогично, похожие команды можно использовать для передачи двоичных данных с удалённого устройства на локальную машину в криминалистических целях. Снова запуск сессии локально:
./pscl -B '1234:[stty -echo raw;echo GO;dd if=rfile.bin]' или
./pscl -B '1234:[stty -echo raw;echo GO;cat rfile.bin]'
Затем ssh на удалённое устройство для получения оболочки, затем снова локально:
nc 127.0.0.1 1234|dd of=lfile.bin bs=1 count=7350
Чтобы получить rfile.bin размером 7350, скопированный в локальный файл lfile.bin
Если stty -echo raw недоступно на устройстве, подойдёт что-то вроде
python -c "import tty;tty.setraw(0)". Обратите внимание, что при использовании команд отскока на удалённом устройстве должен быть tty (не просто портовая оболочка), так как команда stty для установки сырого режима требует настоящего tty.
Если psc работает через последовательное соединение, потерянные биты могут испортить всё удовольствие. Если вы работаете без аппаратного управления потоком, со временем вы столкнётесь с потерей битов и зависанием соединений, особенно при отсутствии регулирования, когда устройство отправляет данные в вашу сторону при использовании команд отскока. Сброс данных на устройство работает лучше, так как эти данные проходят через ограничения скорости pscl.
Однако вот несколько советов, которые сработали для меня в условиях, когда невозможно использовать pscr на устройстве и аппаратное управление потоком. Это относится только к использованию UART, так как это потенциально ненадёжный транспортный канал.
pscr на устройстве, чтобы можно было установить ограничение скорости для данных, отправляемых в вашу сторону. Так как направление к устройству всегда ограничено по скорости, вы можете использовать команды отскока для сброса скомпилированного под другую платформу двоичного файла pscr на устройство и запустить двустороннюю сессию с ограничением скорости.tio -o 1 или -o 2 для добавления задержек между отправляемыми выходными байтами38400, хотя последовательная линия настроена на 115200)psc с -DRESPECT_UART_BUFSIZE=4096, однако это сделает сессию очень медленнойВ папке contrib вы также найдёте патч tio-noprefix для отключения обработки escape-символов, но этот патч необходим только для старых версий, так как разработчики уже приняли и включили этот патч. Я настоятельно рекомендую использовать tio при работе с UART.
При использовании команд отскока через tio необходимо добавить в файл ~/.tioconfig:
[default]
prefix-ctrl-key = none
Это отключает обработку ESC и даёт вам 8-битный чистый канал.
Вы можете отправить SIGUSR1 процессу pscl, чтобы он сообщил вам, зашифрована ли сессия. Если удалённый pscr умирает или завершается без возможности сообщить об этом локальной части, pscl останется в режиме шифрования и, следовательно, зависнет. В этом случае вы можете принудительно сбросить его в режим открытого текста, отправив SIGUSR2, чтобы можно было запустить новую сессию.
Начиная с версии 0.64, psc поддерживает сокеты скриптинга, так что вам больше не нужен screen для получения/отправки файлов или сброса буферов вставки на удалённую консоль. Вместо этого вы запускаете локальную сессию так:
~ > ./pscl -S ~/psc.script_sock
Затем вы можете использовать её как обычно. Если вам нужно 'вставить' что-то, сделайте так:
~ > ./pscsh -S ~/psc.script_sock -f script_/helloworld
Это 'напечатает' содержимое script_/helloworld на консоль. Во время скриптинга stdin pscl блокируется, чтобы инжектированный ввод не смешивался с любым набором текста. Если -S опущен в pscsh, автоматически используется ~/psc.script_sock. По соображениям безопасности скрипты должны начинаться с префикса script_.
В качестве бонуса pscr теперь содержит возможность кодировать/декодировать файлы в base64, даже с встроенными символами CR для удобства. Он совместим с uuencode -m.
; и заключаются в скобки.