创建目录myconfluence, 并将环境配置的压缩包解压至其目录下.
在目录下创建一个data的文件夹.
docker-compose -f docker-compose-confluence.yml up -d
即可(如果想复现其他版本,更改yml文件中的image即可)
进入docker, 进行初始化配置,输入以下命令即可:
apt-get update; apt-get install -y net-tools vim mysql-server netcat tcpdump
访问8090端口, 复制ServerID:
进入docker中断, 执行以下命令:
cd /var/atlassian/ ; java -jar atlassian-agent.jar -d -m [email protected] -n BAT -p 'conf' -o http://localhost:8090 -s <ServerID>
docker cp ./my.cnf confluence:/etc/mysql/my.cnf
CREATE DATABASE confdb CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; CREATE USER 'testuser'@'%' IDENTIFIED BY 'test123'; GRANT ALL PRIVILEGES ON confluence.* TO 'testuser'@'%'; GRANT ALL PRIVILEGES ON *.* TO 'testuser'@'%'; FLUSH PRIVILEGES;
/entrypoint.py
文件, 加入以下内容:import os;os.system("service mysql start")
在1.2中, 配置过序列号后,来到了数据库配置的界面
在之前已经创建好了数据库和连接的用户名密码, 这里直接按照下图输入, 测试连接即可:
如果出现连接失败, 请检查 “1.3.1步骤”是否正确配置.
通过比较8.6.1(已经修复的版本)的com.atlassian.confluence_confluence-8.6.1.jar, 发现大部分的action都加入了AdminOnly:
由此可以猜测可能是某些action可以未授权访问,导致的该漏洞的产生
Confluence是基于Struct2框架开发的一个项目. 在查看Confluence的struct.xml
配置文件时, 我们可以看到它主要使用了一种称为二级哈希表的数据结构来进行路由查找. 由于这种使用二级哈希表的一些特性, 导致了问题的产生
比如有一个哈希表, 它用来存储不同的namespace和与之相关联的action. 哈希表中的每个键都是一个namespace, 而对应的值是该namespace下的所有action, 这里有个细节, hash表中除了存储当前package的action之外, 还从父级包中通过extend的方法继承了他们的action!
换句话说, 当我们在当前 <package>
中定义一个action时, 它会被添加到哈希表中. 然而, 如果我们在当前 <package>
中使用了 extends
属性, 并指定了一个父级包, 那么我们也会继承父级包中的所有action, 并将它们一起添加到哈希表中.
/json/xxxaction
实际上会路由到/admin/xxxaction
, 或者路由到/setup/xxxaction
......果然是有的..
通过下载该bin文件, 调用它进行检测:
同时在docker里安装一个tcpdump进行抓包:
tcpdump port 8090 -w /tmp/p1.pcap
拿到了流量包, 对这个流量包进行分析:
发现访问了/json/setup-restore.action
这个请求, 并且有一个X-Atlassian-Token: no-check
的请求头
重放一下,成功访问:
他本来应该是/setup/setup-restore.action
这个路由的, 这个页面直接访问, 则是已经安装好的界面
由于2.1中所提到的存在的问题, 导致了这个接口的未授权访问
通过后台备份功能, 将修改好密码的站点备份后, 从/setup/setup-restore.action
接口处恢复备份
这里注意: 如果是一个空备份, 会导致清空数据的操作, 这里的上传备份文件类型仅适用于站点备份:
成功恢复备份:
达到未授权登陆后台效果:
通过后台的“管理应用”->“上传应用”功能, 传一个马上去即可:
最后达到未授权任意命令执行的效果: