中間件漏洞總結(jié)報告
一、 IIS解析漏洞
首先一般文件解析漏洞用于各種上傳漏洞中脚粟，在文件上傳的地方一般會限制用戶上傳文件的后綴名靡砌。在實際環(huán)境中IIS一般是和asp搭配的。但是事實上IIS除了可以解析.asp的后綴還可以解析.cer和.asa的文件
1.1文件解析
1.1.1漏洞原理
IIS 6.0在處理含有特殊符號的文件路徑時會出現(xiàn)邏輯錯誤珊楼，從而造成文件解析漏洞
這一漏洞有兩種不同的利用方式（也就是說有兩個特殊符號可以做到來利用漏洞）
IIS 7.5+php開啟了cgi.fix_pathinfo 兩者結(jié)合起來就會產(chǎn)生解析漏洞，因為cgi.fix_pathinfo開啟后會對路徑進(jìn)行修剪
1.1.2 漏洞利用
?????? 一．①特殊符號為?/
?????? 新建一個名為“test.asp”的目錄 那么該目錄下任何文件都被IIS當(dāng)做asp程序執(zhí)行（test.asa? test.cer同理可以實現(xiàn)）
?????? ?? ②特殊符號為?;
?????? 當(dāng)存在分號時例如1.asp;jpg? 仍會被IIS當(dāng)做asp程序執(zhí)行
?????? 二．例如1.jpg/.php?? 一看后綴是php 無論該文件是否存在都直接交給php處理
而php又默認(rèn)開啟了cgi.fix_pathinfo會對問價路徑進(jìn)行修理 （如上 .php不存在? 刪減掉 看1.jpg是否存在若存在 直接把該文件當(dāng)做php程序執(zhí)行）
1.1.3 漏洞修復(fù)
?????? 針對第一個IIS6.0 修復(fù)辦法就是更新版本
?????? 第二個漏洞的解決辦法就是把cgi.fix_pathinfo這個參數(shù)的值設(shè)為0
1.2命令執(zhí)行漏洞
1.2.1 漏洞原理
?????? 在IIS6.0處理PROPFIND指令的時候度液，由于對url的長度沒有進(jìn)行有效的長度控制和檢查厕宗，導(dǎo)致執(zhí)行memcpy對虛擬路徑進(jìn)行構(gòu)造的時候引發(fā)棧溢出，該漏洞可以導(dǎo)致遠(yuǎn)程代碼執(zhí)行
1.2.2 漏洞利用
下載exp
https://github.com/edwardz246003/IIS_exploit堕担，使用python執(zhí)行exploit.py已慢。
1.2.3 漏洞修復(fù)
?????? 更新版本
1.3短文件名漏洞
1.3.1 漏洞原理
?????? 為了兼容16位MS-DOS程序，Windows為文件名較長的文件（和文件夾）霹购，生成了對應(yīng)的windows8.3短文件名????注 使用dir/x 可以在windows下查看對應(yīng)的短文件名
1.3.2 漏洞利用
?????? 可以根據(jù)訪問時頁面的回顯判斷這個短文件是否存在
?????? 構(gòu)造某個存在的短文件名會返回404
?????? 若不存在則會返回400
http://github.com/lijiejie/IIS_shortname_Scanner? 短文件名掃描工具
此漏洞可以用來猜解后臺地址及敏感文件 甚至可以通過短文件名web直接下載對應(yīng)文件但是這個漏洞也有一定的局限性 只能猜解前六位而且名稱較短的根本猜不出來
1.3.3 漏洞修復(fù)
?????? 1.升級.net framework
?????? 2.修改注冊表鍵值
?????? 3.將web文件夾的內(nèi)容拷貝到另一個位置 刪除這個文件 然后再把拷貝的文件夾放回原處
二佑惠、 Apache解析漏洞
1.? ? 漏洞原理
Apache文件解析有一個特性
Apache默認(rèn)一個文件可以有多個以點分隔的后綴，當(dāng)后面的后綴無法識別（不在mine.type內(nèi)---列表里有各種文件類型用來告訴瀏覽器用什么格式去解析文件）就會繼續(xù)向左識別
例如 shell.php.xxx.yyy 首先yyy無法識別向左xxx 依舊不認(rèn)識 再向左php 這個認(rèn)識 就把他交給php來處理
雖然交給了php 但是你去訪問就會發(fā)現(xiàn) 代碼并沒有執(zhí)行 而是直接原樣輸出了
那是因為雖然交給了php來處理這個文件 但是php也不知道這個.yyy后綴的文件應(yīng)該咋辦 所以只能原樣輸出了
那么Apache解析漏洞到底從何而來呢
其實漏洞的產(chǎn)生是由于運維人員在配置服務(wù)器 為了使Apache服務(wù)器能解析php齐疙，而自己添加了一個handler AssHandler application/x-httpd-php.php
這行代碼的作用就是為了讓Apache把php文件交給php_module解析
但是膜楷。。贞奋。赌厅。它的后綴并沒有采用正則去匹配 所以，在文件名的任何位置匹配到php后綴它都會讓php_module去解析 也就因為這樣 漏洞產(chǎn)生了
之前的shell.php.xxx.yyy 一路向左發(fā)現(xiàn)了php 就會激活php處理器 執(zhí)行php代碼
2.? ?漏洞利用
上傳php腳本 就可以拿到shell了
3.? ?漏洞修復(fù)
不要使用AddHandler轿塔，改用SetHandler寫好正則就不會有解析問題了
三特愿、Nginx相關(guān)漏洞
1.目錄遍歷
1.1漏洞原理
?????? Nginx的配置文件被修改因為它默認(rèn)是不會開啟目錄遍歷的
?????? 在Nginx/sites-available/default文件中的location這里加上autoindex on
1.2漏洞利用
?????? 該漏洞可以用來下載源碼或者一些敏感文件對網(wǎng)站極不安全
1.3漏洞修復(fù)
?????? 刪掉那一條配置命令就可以了
2.文件解析漏洞
2.1 漏洞原理
?????? Nginx和Apache一樣也是通過mime.types識別文件
?????? 例如創(chuàng)建一個1.jpg文件 訪問1.jpg/1.php?? 當(dāng)Nginx拿到這個路徑后，一看后綴是.php 便認(rèn)為這個是php文件 就會交給php去處理
?????? 但是php發(fā)現(xiàn)1.jpg/1.php并不存在 便刪去后面的/1.php? 可是1.jpg存在 便把1.jpg當(dāng)成要執(zhí)行的文件 然而因為后綴是.jpg勾缭，php認(rèn)為這不是php文件所以會返回Access denied 所以到目前為止 還不會產(chǎn)生解析漏洞
?????? 要出現(xiàn)解析漏洞還需要兩個條件
①cgi.fix_pathinfo保持默認(rèn)值為1 表示開啟 并對文件路徑進(jìn)行修剪
②配置文件的/etc/php5/fpm/pool.d/www.conf中的security.limit_extensions后面的參數(shù)去掉也就是說讓他把所有的文件統(tǒng)一當(dāng)成php去處理
2.2 漏洞利用
?????? 完整的利用流程就是：訪問1.jpg/1.php 發(fā)現(xiàn)是php 交給php處理 發(fā)現(xiàn)沒有1.php這個文件揍障，進(jìn)行路徑修剪 就成了1.jpg 但仍然把這個1.jpg當(dāng)成php執(zhí)行這樣漏洞就產(chǎn)生了
2.3 漏洞修復(fù)
?????? ①把cgi.fix_pathinfo的值設(shè)為0 這樣就不會進(jìn)行路徑修剪 沒有這個文件網(wǎng)頁就直接返回404
?????? ②配置文件的/etc/php5/fpm/pool.d/www.conf中的security.limit_extensions后面的參數(shù)設(shè)置成.php 這樣他就只能解析php 而不會所有文件直接默認(rèn)用php解析
3.目錄穿越
3.1 漏洞原理
?????? Nginx反向代理時，靜態(tài)文件存儲在/home/下俩由，而訪問時需要在url中輸入要訪問的目標(biāo)文件files毒嫡，需要如下配置：
location /files{
??? alias/home/;
}
其中/files沒有閉合，導(dǎo)致可以穿越之上層目錄
3.2 漏洞利用
既然可以進(jìn)行目錄穿越 那就以訪問根目錄下的/etc/passwd為例
在訪問目標(biāo)文件http://ip/files時采驻，我們可以這樣來構(gòu)造url：
http://ip/files../../../../../../../../../../../../../etc/passwd
弄大概六七個就可以到達(dá)根目錄了
3.3 漏洞修復(fù)
加個閉合
location /files/{
??? alias/home/;
}
4.CRLF注入
4.1 漏洞原理
Nginx的配置文件/etc/nginx/conf.d/error1.conf：
location / {
???return 302 https://$host$uri;
}
問題就出在這個$uri上 它是解碼后請求路徑审胚，不含參數(shù) 和$document_uri一樣
這兩個參數(shù)會將路徑進(jìn)行解碼
首先我們要知道CRLF是“回車+換行”（\r\n）的簡稱匈勋。
HTTP Header與HTTP
Body是用兩個CRLF分割的，瀏覽器根據(jù)兩個CRLF來取出HTTP內(nèi)容并顯示出來膳叨。
通過控制HTTP消息頭中的字符洽洁，注入一些惡意的換行，就能注入一些會話cookie或者惡意的HTML代碼菲嘴。
4.2漏洞利用
首先正常的跳轉(zhuǎn)頁面如下
①進(jìn)行會話固定
②產(chǎn)生反射型XSS
當(dāng)然 雖然輸入了惡意代碼但是仍然沒有彈窗 那是因為瀏覽器Filter對XSS特征進(jìn)行了過濾
在此只是證明一下可以往網(wǎng)頁注入惡意代碼
4.3 漏洞修復(fù)
不再使用$uri 把參數(shù)改為$requestt_uri這個不會解碼 訪問完整的url
另外 任何可以設(shè)置HTTP頭的場景都會出現(xiàn)CRLF注入問題
四饿自、Tomcat任意文件上傳漏洞
1.1漏洞原理
其實 Tomcat本身并無漏洞 漏洞是人為配置的 即開啟put方法可實現(xiàn)上傳文件
在tomcat文件夾下的/conf/web.xml文件插入
?<init-param>
? ? ? ? ? ? <param-name>readonly</param-name>
? ? ? ? ? ? <param-value>false</param-value>
? ? ? </init-param>
重啟tomcat服務(wù) 記住用shutdown.bat 開啟時用startup.bat
1.2 漏洞利用
打開burpsuit 設(shè)置一個新端口 避免沖突
刷新網(wǎng)頁截取數(shù)據(jù)包 進(jìn)行改造
將請求方式改為put創(chuàng)建一個123.jsp 并用%20轉(zhuǎn)義空格字符。123.jsp內(nèi)容為<%out.print("Hello World!");%>龄坪，輸出Hello World!
在web目錄上 能查看創(chuàng)建了123.jsp文件
1.3 漏洞修復(fù)
這個漏洞利用的就是readonly參數(shù)為false時 就可通過PUT方式創(chuàng)建一個jsp文件昭雌，并可以執(zhí)行任意代碼
修復(fù)方法就是不要去修改readonly的默認(rèn)參數(shù) 保持true
