secforce/tunnaTunna — это набор инструментов, которые оборачивают и туннелируют любую TCP-связь через HTTP. Он может использоваться для обхода сетевых ограничений в полностью защищённых брандмауэрами средах.
Tunna — это набор инструментов, которые оборачивают и туннелируют любую TCP-коммуникацию через HTTP. Он может использоваться для обхода сетевых ограничений в полностью брандмауэризованных средах.
v1.1 Альфа-версия
_____
|_ _| _ _ __ _ __ __ _
| || | | | '_ \| '_ \ / _` |
| || |_| | | | | | | | (_| |
|_| \__,_|_| |_|_| |_|\__,_|
Tunna 0.1, для туннелирования TCP-соединений через HTTP от Nikos Vassakis
http://www.secforce.co.uk / nikos.vassakis <at> secforce.com
################################################################################################################
TLDR: Туннелирует TCP-соединения через HTTP
В полностью брандмауэризованной среде (входящие и исходящие соединения ограничены — кроме порта веб-сервера)
Веб-шелл может использоваться для подключения к любому сервису на удалённом хосте. Это будет локальное соединение на локальном порту удалённого хоста и должно разрешаться брандмауэром.
Веб-шелл будет читать данные из порта сервиса, оборачивать их в HTTP и отправлять как HTTP-ответ локальному прокси.
Локальный прокси будет разворачивать и записывать данные в свой локальный порт, к которому будет подключена клиентская программа.
Когда локальный прокси получает данные на локальном порту, он отправляет их веб-шеллу как HTTP POST.
Веб-шелл прочитает данные из HTTP POST и передаст их в порт сервиса.
и повтор —^
Должен быть открыт только порт веб-сервера (обычно 80/443) Вся коммуникация (внешне) осуществляется по протоколу HTTP
python proxy.py -u <remoteurl> -l <localport> [options]
--help, -h показать это справочное сообщение и выйти
--url=URL, -u URL url удалённого веб-шелла
--lport=LOCAL_PORT, -l LOCAL_PORT
локальный порт для прослушивания
--verbose, -v Подробный вывод (выводит размер пакета)
--buffer=BUFFERSIZE, -b BUFFERSIZE*
Размер HTTP-запроса (некоторые веб-шеллы имеют ограничения
на размер)
Параметры игнорируются, если используется SOCKS-прокси
--no-socks, -n Не использовать SOCKS-прокси
--rport=REMOTE_PORT, -r REMOTE_PORT
удалённый порт сервиса для подключения веб-шелла
--addr=REMOTE_IP, -a REMOTE_IP
адрес для удалённого подключения веб-шелла (по умолчанию =
127.0.0.1)
Туннелирование соединения через локальный прокси
--up-proxy=UPPROXY, -x UPPROXY
Вышестоящий прокси (http://proxyserver.com:3128)
--auth, -A Вышестоящий прокси требует аутентификации
--ping-interval=PING_DELAY, -q PING_DELAY
Интервал опроса потока webshprx (по умолчанию = 0.5)
--start-ping, -s Запустить поток опроса первым — некоторые сервисы отправляют
данные первыми (например, SSH)
--cookie, -C Cookie запроса
--authentication, -t Базовая аутентификация
Пример использования:
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v
# Запустит локальный SOCKS-прокси-сервер на порту 8000
# Это соединение будет обёрнуто через HTTP и развёрнуто на удалённом сервере
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v
# Запустит локальный SOCKS-прокси-сервер на порту 8000
# Он подключится через локальный прокси (https://192.168.1.100:3128), требующий аутентификации,
# к удалённому веб-шеллу Tunna
python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v --no-socks
# Это инициирует соединение между веб-шеллом и удалённым сервисом RDP (порт 3389)
# RDP-клиент может подключиться к localhost:4444
# Это соединение будет обёрнуто через HTTP
Возможность загрузить веб-шелл на удалённый сервер
Это POC-код и может вызвать DoS сервера.
Были предприняты все усилия для очистки после выполнения или при ошибке (без гарантий)
По результатам локальных тестов:
* JSP buffer нужно ограничивать (параметр buffer):
4096 работало в Linux Apache Tomcat
1024 работало в XAMPP Apache Tomcat (медленно)
* Больше этого вызывало проблемы с пропаданием байтов на удалённом сокете
например: ruby proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v
* Сокеты не включены по умолчанию:
php windows (IIS + PHP)
XAMPP Windows
php linux (встроенный веб-сервер PHP / apache + PHP)
Если вы получаете ошибку Uncaught Error: Call to undefined function socket_create()
см. https://stackoverflow.com/questions/6137823/fatal-error-call-to-undefined-function-socket-create
* Возврат каретки в веб-шеллах (вне кода):
отправляются в ответах / записываются в локальный сокет -> повреждают пакеты
* PHP-веб-шелл для windows: цикл вызывает DoS удалённого сокета:
добавлена функция sleep -> работает, но немного медленно
* В PHP-веб-шелле нужно удалять символы новой строки в конце файла (после "?>")
так как они будут отправляться в каждом ответе и сбивать Tunna
Веб-шеллы:
conn.jsp Проверен на Apache Tomcat (windows + linux)
conn.aspx Проверен на IIS 6+8 (windows server 2003/2012)
conn.php Проверен на LAMP + XAMPP + IIS (windows + linux)
Веб-сервер:
webserver.py Проверен с Python 2.6.5
Прокси:
proxy.py Проверен с Python 2.6.5
Данные передаются в сыром виде в теле HTTP POST (без POST-переменной)
Инструкции / конфигурация передаются веб-шеллу как параметры URL (HTTP GET)
Данные передаются в теле HTTP (HTTP POST)
Веб-сокеты не используются: не поддерживаются по умолчанию большинством веб-серверов
Асинхронные HTTP-ответы не совсем возможны
Прокси постоянно опрашивает сервер (по умолчанию каждые 0.5 секунд)
1-й пакет инициирует сессию с веб-шеллом — получает cookie обратно например: http://webserver/conn.ext?proxy
2-й пакет отправляет параметры подключения веб-шеллу например: http://webserver/conn.ext?proxy&port=4444&ip=127.0.0.1
IP и порт для подключения веб-шелла
Это запрос в отдельном потоке:
В php этот запрос войдёт в бесконечный цикл,
чтобы поддерживать сокетное соединение веб-шелла живым
В других веб-шеллах приходит [OK]
Создаётся локальный сокет, к которому будет подключаться клиентская программа Как только клиент подключается, запускается поток опроса и начинается выполнение. Любые данные в сокете (от клиента) считываются и отправляются как HTTP POST-запрос Любые данные в сокете веб-шелла отправляются как ответ на POST-запрос
Поскольку HTTP-ответы не могут быть асинхронными. Этот поток будет выполнять HTTP GET-запросы к веб-шеллу с определённым интервалом (по умолчанию 0.5 сек) Если у веб-шелла есть данные для отправки, он (также) отправит их как ответ на этот запрос В противном случае он отправляет пустой ответ
В общем: Данные от локального прокси отправляются через HTTP POST Каждые 0.5 сек выполняются GET-запросы для опроса веб-шелла на наличие данных Если есть данные на стороне веб-шелла, они отправляются как ответ на один из этих запросов
Веб-шелл подключается к сокету на локальном или удалённом хосте. Любые данные, записанные в сокет, отправляются обратно прокси как ответ на запрос (POST/GET) Любые данные, полученные через POST, записываются в сокет.
Все запросы должны содержать URL-параметр "proxy", чтобы обрабатываться веб-шеллом (http://webserver/conn.ext?proxy)
Убивает все потоки и закрывает локальный сокет Отправляет proxy&close веб-шеллу: Убивает удалённые потоки и закрывает сокет
Поддержка SOCKS — это дополнительный модуль для Tunna. Локально это отдельный поток, который обрабатывает запросы на подключение и трафик, добавляет заголовок, указывающий порт и размер пакета, и пересылает его в Tunna. Tunna отправляет его на удалённый веб-сервер, удаляет HTTP-заголовки и пересылает пакет на удалённый SOCKS-прокси. Удалённый SOCKS-прокси инициирует соединение и сопоставляет полученный порт с локальным портом. Если удалённый SOCKS-прокси получает данные от сервиса, он смотрит в таблицу соответствия и находит порт, на который нужно ответить, добавляет порт в качестве заголовка, чтобы локальный SOCKS-прокси знал, куда пересылать данные. Любой трафик с полученного порта будет пересылаться на локальный порт и обратно.
Tunna, Туннелирование TCP через HTTP Nikos Vassakis Copyright (C) 2014 SECFORCE.
Этот инструмент предназначен только для законных целей.
Эта программа является свободным программным обеспечением: вы можете распространять её и/или модифицировать в соответствии с условиями Стандартной общественной лицензии GNU, опубликованной Фондом свободного программного обеспечения, версии 3 лицензии или (по вашему усмотрению) любой более поздней версии.
Эта программа распространяется в надежде, что она будет полезна, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ; даже без подразумеваемой гарантии КОММЕРЧЕСКОЙ ЦЕННОСТИ или ПРИГОДНОСТИ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ. См. Стандартную общественную лицензию GNU для более подробной информации.
Вы должны были получить копию Стандартной общественной лицензии GNU вместе с этой программой. Если нет, см. http://www.gnu.org/licenses/.