secforce/tunnaTunnaは、あらゆるTCP通信をHTTP上でラップしてトンネリングするツールセットです。完全にファイアウォールで保護された環境でのネットワーク制限を回避するために使用できます。
Tunnaは、あらゆるTCP通信をHTTP上でラップしてトンネリングするツール群です。完全にファイアウォールで制限された環境でも、ネットワーク制限を回避するために使用できます。
v1.1 Alpha版
_____
|_ _| _ _ __ _ __ __ _
| || | | | '_ \| '_ \ / _` |
| || |_| | | | | | | | (_| |
|_| \__,_|_| |_|_| |_|\__,_|
Tunna 0.1, HTTPトンネリングTCP接続用 / 作成者 Nikos Vassakis
http://www.secforce.co.uk / nikos.vassakis <at> secforce.com
################################################################################################################
一言で言うと：TCP接続をHTTP上でトンネリングします
完全にファイアウォールで保護された環境（インバウンド/アウトバウンド接続が制限されており、Webサーバーポートのみ許可）において
Webシェルを使用して、リモートホスト上の任意のサービスに接続できます。 これはリモートホストのローカルポートへのローカル接続となり、ファイアウォールで許可されるはずです。
Webシェルはサービスポートからデータを読み取り、HTTPでラップし、HTTPレスポンスとしてローカルプロキシに送信します。
ローカルプロキシはラップを解除し、クライアントプログラムが接続するローカルポートにデータを書き込みます。
ローカルプロキシがローカルポートでデータを受信すると、HTTP POSTとしてWebシェルに送信します。
WebシェルはHTTP POSTからデータを読み取り、サービスポートに書き込みます。
これを繰り返します。
Webサーバーポートのみが開いていればよく（通常は80/443）、通信全体（外部）はHTTPプロトコルで行われます。
python proxy.py -u <リモートURL> -l <ローカルポート> [オプション]
--help, -h このヘルプメッセージを表示して終了
--url=URL, -u URL リモートWebシェルのURL
--lport=LOCAL_PORT, -l LOCAL_PORT
ローカルリスニングポート
--verbose, -v 詳細出力（パケットサイズを出力）
--buffer=BUFFERSIZE, -b BUFFERSIZE*
HTTPリクエストサイズ（一部のWebシェルにはサイズ制限があります）
SOCKSプロキシ使用時はこれらのオプションは無視されます
--no-socks, -n SOCKSプロキシを使用しない
--rport=REMOTE_PORT, -r REMOTE_PORT
Webシェルが接続するリモートサービスのポート
--addr=REMOTE_IP, -a REMOTE_IP
リモートWebシェルが接続するアドレス（デフォルト = 127.0.0.1）
ローカルプロキシを経由したトンネル接続
--up-proxy=UPPROXY, -x UPPROXY
アップストリームプロキシ（例：http://proxyserver.com:3128）
--auth, -A アップストリームプロキシが認証を必要とする
--ping-interval=PING_DELAY, -q PING_DELAY
webshprxのpingスレッド間隔（デフォルト = 0.5）
--start-ping, -s 最初にpingスレッドを開始する - 一部のサービスは最初にデータを送信します（例：SSH）
--cookie, -C リクエストクッキー
--authentication, -t ベーシック認証
使用例：
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v
# これにより、ローカルポート8000でローカルSOCKSプロキシサーバーが起動します
# この接続はHTTP上でラップされ、リモートサーバーでアンラップされます
python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v
# これにより、ローカルポート8000でローカルSOCKSプロキシサーバーが起動します
# 認証が必要なローカルプロキシ（https://192.168.1.100:3128）を経由してリモートTunna Webシェルに接続します
python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v --no-socks
# これにより、WebシェルとリモートホストのRDP（3389）サービス間の接続が開始されます
# RDPクライアントはlocalhostポート4444に接続できます
# この接続はHTTP上でラップされます
リモートサーバーにWebシェルをアップロードできること
これはPOCコードであり、サーバーのDoSを引き起こす可能性があります。
実行後またはエラー時のクリーンアップには可能な限り対応していますが、保証はありません。
ローカルテストに基づく：
* JSPバッファは制限が必要（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組み込みWebサーバー/Apache + PHP）
エラー「Uncaught Error: Call to undefined function socket_create()」が発生する場合は、
以下を参照：https://stackoverflow.com/questions/6137823/fatal-error-call-to-undefined-function-socket-create
* Webシェル上の改行（コード外）：
レスポンスで送信される / ローカルソケットに書き込まれる → パケットが破損
* Windows用PHP Webシェル：ループ関数がリモートソケットをDoSさせる：
sleep関数を追加 → 動作するが少し遅い
* PHP Webシェルはファイル末尾（"?>"以降）の改行を削除する必要がある
これらの改行がすべてのレスポンスで送信され、Tunnaを混乱させるため
Webシェル：
conn.jsp Apache Tomcat（Windows + Linux）でテスト済み
conn.aspx IIS 6+8（Windows Server 2003/2012）でテスト済み
conn.php LAMP + XAMPP + IIS（Windows + Linux）でテスト済み
Webサーバー：
webserver.py Python 2.6.5でテスト済み
プロキシ：
proxy.py Python 2.6.5でテスト済み
データはHTTP POST本文にそのまま送信される（POST変数なし）
指示/設定はURLパラメータ（HTTP GET）としてWebシェルに送信される
データはHTTP本文（HTTP POST）で送信される
WebSocketは未使用：ほとんどのWebサーバーでデフォルトサポートなし
非同期HTTPレスポンスは実質的に不可
プロキシが定期的（デフォルト0.5秒）にサーバーに問い合わせる
1番目のパケットがWebシェルとのセッションを開始し、クッキーを取得する 例：http://webserver/conn.ext?proxy
2番目のパケットが接続設定オプションをWebシェルに送信する 例：http://webserver/conn.ext?proxy&port=4444&ip=127.0.0.1
Webシェルが接続するIPとポート
これはスレッド化されたリクエスト：
PHPでは、このリクエストは無限ループに入り、
Webシェルのソケット接続を維持する
他のWebシェルでは[OK]が返される
クライアントプログラムが接続するローカルソケットが作成される クライアントが接続すると、pingスレッドが開始され、実行が始まる ソケット上のデータ（クライアントからのもの）は読み取られ、HTTP POSTリクエストとして送信される Webシェルソケット上のデータは、POSTリクエストへのレスポンスとして送信される
HTTPレスポンスは非同期にできないため、 このスレッドは間隔（デフォルト0.5秒）に基づいてWebシェルにHTTP GETリクエストを行う Webシェルに送信するデータがある場合、このリクエストへの返信としても送信する そうでなければ空のレスポンスを送信する
一般的に： ローカルプロキシからのデータはHTTP POSTで送信される 0.5秒ごとにGETリクエストが行われ、Webシェルにデータを問い合わせる Webシェル側にデータがあれば、これらのリクエストのいずれかへのレスポンスとして送信される
Webシェルはローカルまたはリモートホストのソケットに接続する ソケットに書き込まれたデータは、リクエスト（POST/GET）への返信としてプロキシに送り返される POSTで受信したデータはソケットに書き込まれる
すべてのリクエストにはURLパラメータ「proxy」が設定されている必要がある（Webシェルが処理するため） (http://webserver/conn.ext?proxy)
すべてのスレッドを終了し、ローカルソケットを閉じる proxy&closeをWebシェルに送信： リモートスレッドを終了し、ソケットを閉じる
SOCKSサポートはTunnaのアドオンモジュールです。ローカルでは、接続リクエストとトラフィックを処理する独立したスレッドが存在し、パケットのポートとサイズを指定するヘッダーを追加してTunnaに転送します。TunnaはそれをリモートWebサーバーに送信し、HTTPヘッダーを削除してパケットをリモートSOCKSプロキシに転送します。リモートSOCKSプロキシは接続を開始し、受信したポートをローカルポートにマッピングします。リモートSOCKSプロキシがサービスからデータを受信すると、マッピングテーブルを参照して応答先のポートを見つけ、ポートをヘッダーとして追加してローカルSOCKSプロキシがデータを転送する場所を認識できるようにします。受信ポートからのトラフィックはローカルポートに転送され、その逆も同様です。
Tunna, TCP Tunneling Over HTTP Nikos Vassakis Copyright (C) 2014 SECFORCE.
このツールは法的な目的でのみ使用してください。
このプログラムはフリーソフトウェアです。あなたはこれを、フリーソフトウェア財団によって発行されたGNU一般公衆利用許諾書（バージョン3、または（あなたの選択により）それ以降のバージョン）の条件の下で再配布または改変することができます。
このプログラムは有用であることを期待して配布されていますが、いかなる保証も提供されません。ただし、商品性または特定目的への適合性に関する暗黙の保証も含め、一切の保証はありません。詳細はGNU一般公衆利用許諾書をご覧ください。
このプログラムとともにGNU一般公衆利用許諾書のコピーを受け取っているはずです。そうでない場合は、http://www.gnu.org/licenses/ をご覧ください。