psc
1.0.0
このプロジェクトは、姉妹プロジェクトのクラッシュと同様に、私のアンチ検閲ツールセットに属しており、敵対的な検閲環境で完全に機能する暗号化シェルと TCP/UDP 転送をセットアップできるようになります。他に利用可能な手段がない場合に、UART または adb 経由でデバイスからデータをダンプすることは、フォレンジックにも役立ちます。
DNS ルックアップと SSH セッションが UART 接続を介して Pi に転送される
PSC では、信頼性が高く、変更やフィルタリングを行わずに Base64 でエンコードされたデータを送受信できる限り、基礎となるトランスポートに依存せず、シングルホップまたはマルチホップでシェル セッションを e2e 暗号化できます。 (たとえば、ポートシェル内で) 受信した e2e pty とともに、OpenSSH の-Lパラメータと同様に、TCP および UDP 接続を転送できます。これは透過的に機能し、開始点でローカルに IP アドレスを割り当てる必要はありません。これにより、法医学者や侵入検査者は、たとえば次のようなネットワーク接続を作成できるようになります。
adb shellセッション (OEM adbd TCP 転送をサポートしていない場合)リモートピアが実際に ppp をサポートしていない状態で、シェルセッション内に非表示の ppp セッションが存在することを想像してください。
Linux、Android、OSX、Windows、FreeBSD、NetBSD、そして (おそらく) OpenBSD上で動作します。
PSC には、ポート シェルまたはモデム ダイヤルアップを介してリモートで実際の Web ブラウジング セッションを行うためのSOCKS4およびSOCKS5プロキシ サポートも含まれています。
Makefileの先頭で定義されている事前共有キーを反映するようにMakefile編集します。
次に、 LinuxおよびOSXではmakeと入力するだけです。
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に接続し、TCP 経由で192.168.0.254:22に、または UDP 経由で8.8.8.8リゾルバに到達できます。リモート サイトに IPv6 接続がある場合、これは [IPv6] アドレスでも機能します。実際、常にローカル側の127.0.0.1に接続するため、これを使用して IPv4 ソフトウェアを IPv6 に変換することもできます。
複数の-Tおよび-Uパラメーターを渡すことができます。セッションがすでに e2e 暗号化されているかどうかが分からなくなった場合は、ローカルのpsclプロセスにSIGUSR1を送信すると、そのことがわかります。
PSC は、リモート SSH シェルから tor を使用する場合にも役立ちます。これにより、socks5 と DNS ポートをリモート ホストのアドレス127.0.0.1に転送できます。 SSH は UDP パケットを転送しないため、通常は 2 つのsocatコネクタなどを使用して tor ノード経由で解決します。 PSC には UDP データグラム境界を維持できるという利点がありますが、 SSH -Lを介したsocatデータグラム境界を壊し、不正な形式の DNS リクエストを作成する可能性があります。
セッションは、 Makefileで選択した PSK のaes_256_ctrで暗号化されます。この暗号化スキームは順応性がありますが、AAD または OAD データを追加するとパケット サイズが大幅に増加します。対話型セッションではすべてのバイトがカウントされ、Base64 エンコーディングにより、入力された文字ごとにすでにより多くのデータが送信されることになります。
UART セッションはscreen経由で使用できますが、たとえばminicom経由では使用できません。minicom はステータス行のある非表示のウィンドウを作成し、PSC のプロトコルを破壊するフィルターのように機能するためです。 PSC はフィルタリングの検出を試み、ある程度のデータマングリングに耐えることができますが、状況によっては回復できない場合があります。 tmuxでも同様のことが起こります。受信データを過度に混乱させたり処理したりする PSC と pty ハンドラーをスタックすることは避けるべきです。
PSC が pty でどのシェルを実行するかを認識できるようにするには、 SHELL環境変数をpsclとpscr両方に設定する必要があります。 SHELLほとんどの環境でデフォルトで設定されていますが、設定されていない場合は、 SHELL=/bin/bash psclなどのように PSC を実行する必要があります。
pscl SOCKS4 ( -4 port ) およびSOCKS5 ( -5 port ) を介した TCP 接続の転送もサポートします。これにより、ポートがTCP 接続用の SOCKS ポートとして設定されるため、たとえば、ペネトレーション テスト中に他の接続を開くことなく、ポート シェル セッションからリモート ネットワークを参照できます。 -N psclに渡すと、リモート側で DNS 名解決が有効になるため、Chrome も使用できます。ただし、注意してください。起動時に制御できない一連の DNS 名を解決しようとするブラウザには、プライバシーの問題があります。また、リモート側の DNS 設定が壊れている場合、DNS 応答パケットが見つからないと入力シェルが数秒間ブロックされる可能性があります。埋め込み可能で移植可能な優れた非同期リゾルバー関数がないため、DNS 問題が存在する場合は数秒間ブロックされる可能性を犠牲にして、シングル スレッドのgetaddrinfo()に依存する必要がありました。そのため、名前解決を明示的に有効にする必要があります。 pscr 、DNS ルックアップ キャッシュに関するこの潜在的な問題を最小限に抑えようとするため、ほとんどの状況では問題なく動作するはずです。 -X IP-address (最初の引数である必要があります) を渡すと、ローカル プロキシを127.0.0.1とは異なるアドレスにバインドできるため、ローカル ネットワークでプロキシを共有できます。
psc機能を使用すると、リモート サイトにpscrバイナリをインストールできない場合でも、TCP 接続またはバイナリ データ BLOB をリモート デバイスとの間で複数のホップを介して転送できます。これは、デバイス (UART に接続された電話など) からアーティファクトをダウンロードする手段がない場合、またはシステム上の証拠を破壊しないように FS に触れることなく接続を転送する必要がある場合や、ルート FS は ro マウントされているため、ツールセットをアップロードできません。
これは非常に優れた機能で、リモートで何かをインストールすることなく、TCP 接続がローカル tty を介してリモート ボックスにホップするのを確認できます。
これは、ローカルの pty punkrock と、( pscr実行せずに) リモート シェルにドロップする bounce コマンドをpsclに渡すこと、およびローカル側でデータをフィルタリングして処理するいくつかの状態エンジン マジックによってのみ機能します。通常、これには、実際のコマンドと-Bに渡されるその他の詳細を発行する前に、最初にリモート pty を raw モードに設定する必要があります。議論は次の部分に分かれています。
:が続きます (例: 1234: )。stty -echo rawまたはpython -c "import tty;tty.setraw(0)" ( -Bも引用符で囲む必要があるため、正しく引用符を付けるように注意してください)、または似たようなもの。sttyと cmd の開始との間の競合を回避するために、 psclデータの送信を開始するよう指示するリモートによって発行される「GO」マーカー。たとえば、 echo GO完璧です。nc 127.0.0.1 22pscl tty 状態をリセットできるようになります。 echo FINそれを行います。そうしないと、コマンドの終わりを認識するのが困難になる可能性があるため、これをお勧めします。;で区切られています。そして括弧で囲まれています。例:
TCP 接続を転送する場合、この例ではデバイスにsttyとncがインストールされている必要がありますが、理論的には同等の機能を備えた他のものであれば何でも可能です。
ローカルセッションを開始します。
./pscl -B '1234:[stty -echo raw;echo GO;nc example.com 22;echo FIN]'
これにより、ローカルでポート 1234 に接続している場合、コマンドstty -echo raw;echo GO;nc example.com 22;echo FINリモート デバイスに発行され、その後、受信したデータがすべて前後に転送され、トラフィックがレート制限されます。デバイスの tty 速度を超えることはありません (デフォルトは 115200)。
pscl セッションが開始されたら、UART、 ssh -e none ...などを使用してリモート デバイスに接続し、リモート シェルを取得したら、ローカルで次のように入力します。
ssh [email protected] -p 1234ローカル ボックスからリモート デバイスを介してexample.com宛先に SSH 接続をバウンスします。もちろん、 -B pscrに 1 つの接続しかバウンスできず (ただし、さまざまな転送に複数の-Bコマンドを渡すことはできます)、pty がraw -echoであるため、TCP セッション後にシェルがハングする可能性があるため、pscr バリアントが推奨されます。 raw -echoモードであり、最後のリモート ピアも接続を閉じるかどうかによっては、その後シェルがハングするだけである可能性があります。接続が完了したという pscl 通知を見つけてプロンプトが表示された場合は、新しい接続を開始できるようにreset必要があります。データが転送されている間、 psclに 7 ビット ASCII の<および>通知が表示されますが、これはデバッグと進行状況の検出を容易にするためのローカルなものです。
リモート サイトへの接続は 8 ビット クリーンである必要があることに注意してください。つまり、ssh、telnet、UART などのチャネルはエスケープ シーケンスを処理してはなりません( pscr使用する場合とは異なります)。 ssh 接続の場合、これはpsclセッションでssh -e none使用する必要があることを意味します。
次に、いくつかの例に従ってバイナリ ファイル xfer を処理します。ここで、 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セッション内からリモート デバイス上のシェルを取得するために必要なものすべてを使用します。ローカルの 2 番目の端末で次のようにします。
dd if=lfile.bin|nc 127.0.0.1 1234
これはpsclのローカル ポート 1234 に接続し、リモート側で dump コマンドをトリガーし、ローカルのlfile.binのバイナリ データをリモートのrfile.binに転送します。レート制限があるため、これには時間がかかる場合があり、転送が完了したかどうかはpsc の進行状況画面のみを信頼してください。 local dd ...|nc ...コマンドは、ファイルが pty を介して転送されている間に、ローカル TCP バッファが原因でミリ秒単位でファイル全体を消費する可能性があるローカル ステータスのみを表示します。したがって、 pscl画面に終了が表示された場合、またはdd ...|nc ...セッションでFIN終了マーカーがエコーバックされているのが表示された場合にのみCtrl-Cを押すようにしてください。
同様に、フォレンジック目的で、同様のコマンドを使用して、リモート デバイスからローカル ボックスにバイナリ データを転送することもできます。もう一度、ローカルでセッションを開始します。
./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
サイズ 7350 のrfile.bin取得するには、ローカル ファイルlfile.binにコピーします
stty -echo rawデバイスで利用できない場合は、 python -c "import tty;tty.setraw(0)"のようなものでも機能します。 raw モードを設定するsttyコマンドには実際の tty が必要であるため、bounce コマンドを使用する場合は、リモート デバイス上に tty (単なるポートシェルではなく) が必要であることに注意してください。
psc がシリアル接続で実行されている場合、ビットが失われると楽しみがすべて台無しになる可能性があります。 HW FC なしで実行すると、特にバウンス コマンドを使用するときにデバイスがユーザーの方向にデータを送信するときにスロットリングがないため、最終的にビット損失や接続のハングが発生します。このデータがpsclレート制限を通過するため、デバイスへのデータのダンプはより適切に機能します。
ただし、デバイスと HW FC でpscr使用できない状況で役に立ったヒントをいくつか紹介します。これは、信頼性が低い可能性があるトランスポート チャネルであるため、UART を使用する場合にのみ適用されます。
pscr使用すると、自分の方向に送信されるデータのレート制限を設定できます。デバイスへの方向は常にレート制限されているため、bounce コマンドを使用してクロスコンパイルされたpscrバイナリをデバイスにダンプし、それとの双方向のレート制限セッションを開始できます。tio -o 1または-o 2を使用して、送信された出力バイト間に遅延を追加します115200に設定されていますが、 38400優先します)。psc -DRESPECT_UART_BUFSIZE=4096でコンパイルしますが、これによりセッションが非常に遅くなります。 contribフォルダー内には、エスケープ文字の処理を無効にするtio-noprefixパッチもありますが、アップストリームがすでにこのパッチを受け入れ、統合しているため、このパッチは古いバージョンにのみ必要です。 UART を使用する場合はtio使用することを強くお勧めします。
tio間で bounce コマンドを使用する場合は、 ~/.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の内容がコンソールに「入力」されます。スクリプト作成中、挿入された入力が入力と混同されないように、 psclの stdin はブロックされます。 pscshで-Sを省略した場合、 ~/psc.script_sockが自動的に使用されます。安全上の理由から、スクリプトはscript_プレフィックスで始める必要があります。
ボーナスとして、 pscrには、便宜上 CR 埋め込み文字を含むファイルを Base64 でエンコード/デコードする機能が含まれるようになりました。 uuencode -mと互換性があります。
