0x00 背景

安全漏洞是导致网络数据库存在数据泄露隐患的主要因素，涉及的数据库（服务）类型主要包括MongoDB、ElasticSearch、MySQL和Redis等，涉及的漏洞类型主要为未授权访问和弱口令漏洞。

CNCERT针对境内的MongoDB、ElasticSearch、MySQL及Redis等数据库进行排查，发现大量存在数据泄露隐患，共涉及20720个数据表、1330.3TB数据量、1.78万亿余条数据。

数据库或者缓存应用属于敏感应用，通常部署在内网，但是如果部署的机器有内外网ip，且默认监听地址为0.0.0.0的话，则敏感端口会对外开放。如mysql/mongodb/redis/rsync/ docker daemon api等端口对外开放。

敏感应用无认证、空口令或者弱口令 如果敏感应用使用默认配置，则不会开启认证，mysql/mongodb/redis/rsync/supervisord rpc/memcache等应用无认证。有时为了测试方便，配置了弱口令或空口令，则认证形同虚设。

攻击者发现并且利用此类漏洞的成本低，效果明显，影响巨大，因此此类漏洞必须高度重视。

0x01 常见应用的未授权访问

1.Redis 未授权访问漏洞

漏洞描述

redis端口对外开放并且没有配置认证选项，未授权用户可直接获取数据库中所有信息，造成严重的信息泄露。

解决方法

方法一： 可以修改绑定的IP、端口和指定访问者IP。

默认情况下，Redis 监听 127.0.0.1。如果仅仅是本地通信，请确保监听在本地，这种方式可以在一定程度上缓解 Redis 未授权访问的风险（例外情况下，如果 Redis 以 root 用户运行，攻击者借助已有的 webshell，就可以利用该 Redis 来反弹 shell 以实现提权）。

只有本机才能访问 Redis：

在 redis.conf 文件中找到 # bind 127.0.0.1，将前面的 # 去掉，然后保存。

注意：该操作需要重启 Redis 才能生效。

指定访问源 IP 来访问 Redis：

bind 192.168.1.100 10.0.0.1

注意：该操作需要重启 Redis 才能生效。

方法二： 设置访问密码

在redis.conf 中找到 requirepass 字段，去掉其注释，并在后面填上需要的密码。Redis 客户端也需要使用此密码来访问 Redis 服务。

打开 /etc/redis/redis.conf 配置文件:

requirepass !QE%^E3323BDWEwwwe1839

方法三： 设置防火墙策略

如果正常业务中 Redis 服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问 Redis 服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 6379 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段

漏洞验证

安装Redis，然后连接到服务。

# yum install redis

# redis-cli -h 10.2.20.73 -p 6379

10.2.20.73:6379> info

2. Mongodb未授权访问漏洞

漏洞描述

刚安装完毕时，MongoDB都默认有一个admin数据库,此时admin数据库是空的,没有记录权限相关的信息！当admin.system.users一个用户都没有时，即使mongodb启动时添加了--auth参数,如果没有在admin数据库中添加用户,此时不进行任何认证还是可以做任何操作(不管是否是以--auth 参数启动),直到在admin.system.users中添加了一个用户。

解决方法

方法一：可以修改端口和指定访问ip，也可以使用防火墙来配置访问策略。

1. 配置AUTH，做好访问认证。打开MongoDB配置文件（.conf），设置为auth=true；

1. 修改访问端口和指定访问ip。使其只监听私有IP（或本地IP），不监听任何公网IP或DNS。

使用--bind_ip选项，该选项可以限制监听接口IP为特定的内网IP， 当在启动mongodb的时候，使用 --bind_ip 10.0.0.1表示启动ip地址绑定，数据库实例将只监听10.0.0.1内网的请求。

mongod --bind_ip 10.0.0.1

方法二：

在admin.system.users中添加用户，启动认证。

#在admin 数据库中创建用户userbb， 密码为xy2020

[mongodb@ceshi]$ ./mongo 127.0.0.1:27017

MongoDB shell version: 2.0.1

connecting to: 127.0.0.1:27017/test

> use admin

switched to db admin

>

> db.addUser("userbb", "xy2020")

{ "n" : 0, "connectionId" : 4, "err" : null, "ok" : 1 }

{

"user" : "userbb",

"readOnly" : false,

"pwd" : "51a481f72b8b8218df9fee50b3737c44",

"_id" : ObjectId("4f2bc0d357a309043c6947a4")

}

> db.auth("userbb","xy2020")

1

> exit

bye

方法三： 设置防火墙策略

如果正常业务中 MongoDB 服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 27017 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段

漏洞验证

安装mongodb，然后连接到服务。

# yum install mongodb

#  mongo --host 10.2.20.34 --port 27017

xxx-test:SECONDARY> show dbs

3. Memcached 未授权访问漏洞

漏洞描述

Memcached 端口对外开放并且没有配置认证选项，未授权用户可直接获取数据库中所有信息，造成严重的信息泄露。

解决方法

方法一： 可以修改绑定的IP、端口和指定访问者IP。
Memcached没有在公网开放的必要，可在Memcached启动时指定绑定的IP地址为 127.0.0.1。例如，在Linux环境中运行以下命令：
memcached -d -m 1024 -u memcached -l 127.0.0.1 -p 11211 -c 1024 -P /tmp/memcached.pid

方法二： 增加Memcached的认证配置。

Memcached从1.4.3版本开始，支持SASL认证。

安装启动SASL服务，新增用户xy2020,密码也为XY2020

# /etc/init.d/saslauthd start

# /usr/sbin/testsaslauthd -u xy2020 -p XY2020

# ./memcached -d -m 1024 -S -l 192.168.128.83 -p 11212 -u tuxedo

方法三： 设置防火墙策略

如果正常业务中 Memcached 服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 11211 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段

漏洞验证

telnet 10.10.4.89 11211 或 nc -vv <target> 11211

无需用户名密码，可以直接连接memcache 服务的11211端口

使用了 stats 命令来输出 Memcached 服务信息

4. ZooKeeper 未授权访问

漏洞描述

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

在通常情况下，zookeeper允许未经授权的访问。

解决方法

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

方式一：

1）增加一个认证用户

addauth digest 用户名:密码明文

举例： addauth digest user1:password1

2）设置权限

setAcl /path auth:用户名:密码明文:权限

举例： setAcl /test auth:user1:password1:cdrwa

3）查看Acl设置

getAcl /path

方式二：

setAcl /path digest:用户名:密码密文:权限

方法三： 设置防火墙策略

如果正常业务中ZooKeeper服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 11211 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段

漏洞验证

安装ZooKeeper，然后连接到服务。

ZooKeeper: https://zookeeper.apache.org/releases.html

# wget https://mirrors.bfsu.edu.cn/apache/zookeeper/zookeeper-3.6.1/apache-zookeeper-3.6.1-bin.tar.gz

# tar -xzvf  apache-zookeeper-3.6.1-bin.tar.gz

# cd apache-zookeeper-3.6.1-bin/bin

# ./zkCli.sh  -timeout 0 -r -server  10.10.4.72:2181

备注：windows 下为：zkCli.cmd  -timeout 0 -r -server  10.10.4.72:2181

[zk: 10.10.4.72:2181(CONNECTED) 0] version

5. Elasticsearch 未授权访问

漏洞描述

ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java开发的，并作为Apache许可条款下的开放源码发布，是当前流行的企业级搜索引擎。设计用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

安装了 River 机制之后可以同步多种数据库数据（包括关系型的MySQL、MongoDB 等）。如果http://localhost:9200/cat/indices中indices包含了_river，则代表 Elasticsearch 已安装 River 机制。而通过泄露的http://localhost:9200/_rvier/_search URL地址，攻击者可以获取到敏感信息。

通常情况下Elasticsearch 未对敏感信息进行过滤，导致任意用户可读取敏感信息。

解决方法

方式一：提供身份认证策略

elasticsearch-http-basic 就提供了针对ES HTTP连接的IP白名单、密码权限和信任代理功能。

elasticsearch-http-basic和其他ES插件一样，在config/elasticsearch.yml 中统一配置： 配置名 默认值 说明

http.basic.enabled true 开关，开启会接管全部HTTP连接

http.basic.user “admin” 账号

http.basic.password “admin_pw” 密码

http.basic.ipwhitelist [“localhost”, “127.0.0.1”] 白名单内的ip访问不需要通过账号和密码，支持ip和主机名，不支持ip区间或正则。

方式二：绑定访问IP。

Elasticsearch 默认端口是 9200。不要把 Elasticsearch 的 9200 端口服务发布到互联网上。

进入 config 目录，修改 elasticsearch.yml 配置文件中以下参数：

network.bind_host: 192.168.0.1

# 设置绑定的 IP 地址，可以是 IPv4 或 IPv6 地址，默认为 0.0.0.0。

network.publish_host: 192.168.0.1

# 设置其它节点和该节点交互的 IP 地址，如果不设置它会自动判断，值必须是个真实的 IP 地址。

network.host: 192.168.0.1

# 同时设置上述两个参数：bind_host 和 publish_host。

方法三： 设置防火墙策略

如果正常业务中Elasticsearch 服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 11211 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段

漏洞验证

使用nmap寻找相关的端口和服务，直接访问脆弱的服务：

curl http://10.2.20.48:9200/

curl http://10.2.20.48:9200/_cat

curl http://10.2.20.48:9200/_cat/_river/_search

curl http://10.2.20.48:9200/cat/indices

http://10.2.20.48:9100/metrics

6. Kibana 未授权访问

漏洞描述

Kibana如果允许外网访问，没有做安全的登录认证，也会被外部随意访问查看所有的数据，造成少数据泄露。

解决方法

方法一：

第1步：设置kibana监听本地地址，并设置ElasticSearch登录的账号和密码：

elasticsearch.url: "http://127.0.0.1:9200"

#这里输入在第一节给ElasticSearch创建的账号和密码

elasticsearch.username: "user"

elasticsearch.password: "pass"

第2步：同样的，使用htpasswd创建kibana登录的账号密码，这里可以服用ElasticSearch创建的账号密码，也可以重新创建一个。

htpasswd -c /usr/local/service/nginx/conf/htpasswd username

第3步：配置nginx反向代理，配置好后，重启nginx和kibana，通过15601登录验证访问Kibana。这时候就会弹出如下的对话框：

http://10.10.4.89:15601/Kibana

通过nginx反向代理访问kibana

server {

# 通过反向代理对kibana身份认证

listen 15601;

server_name localhost;

location / {

auth_basic "xscan";

auth_basic_user_file /usr/local/service/nginx/conf/htpasswd;

 

proxy_pass http://127.0.0.1:5601;

}

}

方法二： 设置防火墙策略

如果正常业务中 kibana 服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 11211 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段

同时禁止对外开放。

漏洞验证

直接访问kibana的页面，如：https://10.10.4.89:5601/ https://10.10.4.89/app/kibana#  http://10.10.4.89:5601/app/kibana#/

并且无需账号密码可以登录进入界面。

7. Docker Remote API 未授权访问漏洞

漏洞描述

Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的LINUX机器上，也可以实现虚拟化。

Docker swarm 是一个将docker集群变成单一虚拟的docker host工具，使用标准的Docker API，能够方便docker集群的管理和扩展，由docker官方提供。

Docker Remote API如配置不当可导致未授权访问，被攻击者恶意利用。

攻击者无需认证即可访问到Docker数据，可能导致敏感信息泄露，黑客也可以删除Docker上的数据,直接访问宿主机上的敏感信息，或对敏感文件进行修改，最终完全控制服务器。

解决方法

方式一：端口访问控制

对2375端口做网络访问控制，如设置iptables策略仅允许指定的IP来访问Docker接口；

方式二：使用TLS认证

修改docker swarm的认证方式，使用TLS认证：Overview Swarm with TLS 和 Configure Docker Swarm for TLS这两篇文档，说的是配置好TLS后，Docker CLI 在发送命令到docker daemon之前，会首先发送它的证书，如果证书是由daemon信任的CA所签名的，才可以继续执行。

漏洞验证

直接使用浏览器访问：

http://10.10.4.89:2375/

http://10.10.4.89:2375/version

http://10.10.4.89:2375/info

docker -H tcp://192.168.15.5:2375 version

docker -H tcp://10.10.4.89:2375 images

8. Kubernetes Api Server 未授权访问漏洞

漏洞描述

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

解决方法

方式一：进行授权认证

Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server的RESTAPI来实现的，因此集群安全的关键点就在于如何识别并认证客户端身份（Authentication），以及随后访问权限的授权（Authorization）环节。

Kubernetes集群提供了3种级别的客户端身份认证方式。

HTTPS证书认证：此方式最严格，基于CA根证书签名的双向数字证书认证方式。

HTTP Token认证：通过一个Token来识别合法用户。

HTTP Base认证：通过用户名+密码的方式认证。

方式二：使用Service Account令牌

Service Account是一个自动启用的认证器，它使用被签名的Bearer Token对请求进行认证，该插件接受两个可选参数：

– -service-account-key-file： 一个包含用于对Bearer Token进行签名的PEM编码密钥文件。如果不指定，将使用API服务器的TLS私钥。

– -service-account-lookup ：如果启用，从API中删除的tokens将会被废除。

Service Account通常由API服务器自动创建，并通过ServiceAccount Admission Controller与集群中的Pods进行关联。 Bearer tokens被挂载到pod中众所周知的位置，从使集群中的进程可以与API服务器进行通信。Service Account可以使用PodSpec的serviceAccountName字段来关联到Pod中。

方法三： 设置防火墙策略

如果正常业务中 Kubernetes服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 8080 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段

漏洞验证

使用nmap寻找相关的端口和服务，直接访问脆弱的服务：

端口：8080   http://10.10.4.89:8080/

端口：8080： api dashboard： http://10.10.4.89:8080/ui

 

端口：10250端口是kubelet API的HTTPS端口，通过路径/pods获取环境变量、运行的容器信息、命名空间等信息。

http://10.10.4.89:10250/pods

http://10.10.4.89:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

http://192.168.56.101:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/#!/login

9. Hadoop 未授权访问

漏洞描述

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。在默认情况下，Hadoop允许任意用户访问管理接口。

解决方法

方式一：使用身份认证

升级Hadoop到2.x版本以上，并启用Kerberos认证功能，禁止匿名访问

1. 配置Service Level Authorization

修改core-site.xml

<property>

<name>hadoop.security.authorization</name>

<value>true</value>

</property>

hadoop.security.authorization=true则开启ServiceLevel Authorization，若为false则不经过任何验证，所有用户拥有全部权限。(修改此配置需要重启hadoop)

每个可配置多个用户，用户之间用“，”分割；可配置多个用户组，分组之间用“，”分割，用户和分组之间用空格分割，如果只有分组，前面保留一个空格，如：

<property>

<name>security.job.submission.protocol.acl</name>

<value>alice,bobgroup1,group2</value>

</property>

默认情况下，属性不对任何用户和分组开放。

该配置文件可使用以下命令动态加载：

(1)    更新namenode相关属性：bin/hadoop dfsadmin –refreshServiceAcl

(2)    更新jobtracker相关属性：bin/hadoopmradmin –refreshServiceAcl

方法二： 设置防火墙策略

1. 设置防火墙策略：

如果正常业务中Hadoop服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 8088 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段

2.如无必要，不要将接口开放在公网，改为本地或者内网调用

漏洞验证

使用nmap寻找相关的端口和服务，直接访问脆弱的服务：

访问 http://192.168.18.129:8088/cluster

可完成攻击，命令被执行，在相应目录下可以看到生成了对应文件

curl-s -i -X POST -H 'Accept: application/json' -H 'Content-Type: application/json'http://ip:8088/ws/v1/cluster/apps --data-binary @1.json

http://192.168.18.129:50075/

 

10. jenkins未授权访问漏洞

漏洞描述

默认情况下 Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令，攻击者可通过未授权访问漏洞或者暴力破解用户密码等进入后台管理服务，通过脚本执行界面从而获取服务器权限。

解决方法

方式一：添加认证

在Jenkins管理页面添加访问密码

方式二：禁止暴露在公网

禁止把Jenkins直接暴露在公网。

检测方法

先用 nmap 扫描查看端口开放情况看是否开放，

然后直接访问：http://192.168.18.129:8080/manage

11. ActiveMQ未授权访问漏洞

漏洞描述

ActiveMQ是一款流行的开源消息服务器。默认情况下，ActiveMQ服务是没有配置安全参数。恶意人员可以利用默认配置弱点发动远程命令执行攻击，获取服务器权限，从而导致数据泄露。

解决方法

方式一：ActiveMQ的安全配置

ActiveMQ的安全配置分为控制台安全配置和后台安全配置。

控制台安全配置是指用户通过浏览器登录ActiveMQ管理界面，对ActiveMQ进行管理的一个安全配置；主要是添加用户和密码。后台安全配置是指程序通过ActiveMQ发送消息的一个安全配置。

1. ActiveMQ控制台安全配置。

修改端口号（将密码改为weigq，端口改为8191）。

ActiveMQ的管理后台 http://localhost:8161/admin 的默认用户名和密码是admin，admin。默认端口为8061。采用的是JETTY服务器。所以修改端口和密码也是改JETTY的配置jetty.xml、jetty-realm.xml。

<bean id="securityConstraint" class="org.eclipse.jetty.util.security.Constraint">

<property name="name" value="BASIC" />

<property name="roles" value="admin" />

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

</bean>

注意：第三个属性authenticate要为true.

端口部分：

<bean id="Server" class="org.eclipse.jetty.server.Server" init-method="start"

destroy-method="stop">

<property name="connectors">

<list>

<bean id="Connector" class="org.eclipse.jetty.server.nio.SelectChannelConnector">

<property name="port" value="8191" />

</bean>

再次修改用户名和密码（用户名改为parry，密码改成parry123）。建议使用十位以上数字+字母+特殊符号的强密码。控制台的登录用户名密码保存在conf/jetty-realm.properties文件中，内容如下:

parry: parrYd@#1w%6, admin

user: user, user

## 用户名和密码的格式：username: password, [rolename ...]

2. ActiveMQ后台安全配置。

配置置连接ActiveMQ的用户名和密码，如果不设置ActiveMQ安全机制，任何知道ActiveMQ服务的IP、端口和消息地址的人，都可以接受和发送消息。推荐您使用以下简单配置，在conf/activemq.xml文件broker标签里的<systemUsage>标签前加入如下内容：

<plugins>

<simpleAuthenticationPlugin>

<users>

<authenticationUser username="parry" password="parry123" groups="users,admins"/>

</users>

</simpleAuthenticationPlugin>

注意：必须要在标签前，否则ActiveMQ服务重启会报错，所有配置完毕后重启ActiveMQ服务。

漏洞验证

先用 nmap 扫描查看端口开放情况看是否开放，ActiveMQ默认使用8161端口，默认用户名和密码是admin/admin

13. RabbitMQ未授权访问漏洞

漏洞描述

RabbitMQ是目前非常热门的一款消息中间件，基于AMQP协议的，可以在发布者和使用者之间交换异步消息。 消息可以是人类可读的JSON，简单字符串或可以转换为JSON字符串的值列表。

解决方法

方法一：修改为强密码，删除默认的账号guest

方法二：禁止对外网开放，仅限于内部访问。

漏洞验证

http://10.10.4.89:15672

http://10.10.4.89:25672/

http://10.10.4.89:15692/

默认账号密码都是guest

14. Springboot actuator 未授权访问漏洞   

漏洞描述

Spring Boot Framework包含许多称为执行器的功能，可在您将Web应用程序投入生产时帮助您监视和管理Web应用程序。 它们旨在用于审计，运行状况和指标收集，当配置错误时，它们还可以为您的服务器打开一扇隐藏的门。当Spring Boot应用程序运行时，它会自动注册多个端点（例如'/ health'，'/ trace '，'/ beans'，'/ env'等）进入路由过程。 对于Spring Boot 1-1.4，无需身份验证即可访问它们，从而导致严重的安全性问题。 从Spring 1.5版开始，默认情况下，除'/ health'和'/ info'之外的所有端点都被视为敏感和安全的，但是此安全性通常被应用程序开发人员禁用。

解决方法

方法一：

禁用/env接口，则可设置如下：

endpoints.env.enabled= false

如果只想打开一两个接口，那就先禁用全部接口，然后启用需要的接口：

endpoints.enabled = false

endpoints.metrics.enabled = true

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

<dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-security</artifactId>

</dependency>

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

management.port=8099

management.security.enabled=true

security.user.name=tech

security.user.password=WEsllsl

方法二：

1. 升级到Springboot actuator  2.0
2. 禁止对外开放。

漏洞验证

直接访问相关路径：

http://10.2.20.48:/autoconfig

 

14. FTP未授权访问漏洞（匿名登录）

漏洞描述

FTP 弱口令或匿名登录漏洞，一般指使用 FTP 的用户启用了匿名登录功能，或系统口令的长度太短、复杂度不够、仅包含数字、或仅包含字母等，容易被黑客攻击，发生恶意文件上传或更严重的入侵行为。

解决方法

方式一、禁止匿名登

添加一个新用户（test），并配置强密码。例如，执行useradd -d /home -s /sbin/nologin test命令。

其中，/sbin/nologin参数表示该用户不能登录 Linux shell 环境。

test为用户名。

通过passwd test命令，为该用户配置强密码。密码长度建议八位以上，且密码应包括大小写字母、特殊字符、数字混合体，且不要使用生日、姓名拼音等常见字符串作为密码。

修改配置文件 vsftpd.conf，执行#vim /etc/vsftpd/vsftpd.conf命令。

漏洞验证

直接访问ftp路径：ftp://ip:port/

15.  JBOSS 未授权访问漏洞

漏洞描述

JBOSS 企业应用平台EAP是 J2EE 应用的中间件平台。默认情况下访问 http://ip:8080/jmx-console 就可以浏览 jboss 的部署管理的信息不需要输入用户名和密码可以直接部署上传木马有安全隐患。

解决方法

① 找到 %JBOSS_HOME%/server/default/deploy/jmx-console.war/WEB-INF/jboss-web.xml 文件去掉下面这段 xml 文本的注释。

② 与 jboss-web.xml 同级的目录下还有一个文件 web.xml找到下面这段 xml 文本把 GET 和 POST 两行注释掉同时 security-constraint 整个部分取消注释, 不然存在head头绕过。

③ %JBOSS_HOME%\server\default\conf\props\jbossws-users.properties 中删除原始的 admin/admin添加新的用户名密码。

④ %JBOSS_HOME%\server\default\conf\props\jbossws-roles.properties 中定义新用户名所属角色。该文件定义的格式为用户名 = 角色多个角色以 “,” 隔开该文件默认为 admin 用户定义了 JBossAdmin 和 HttpInvoker 这两个角色。

# A sample roles.properties file foruse with the UsersRolesLoginModule

kermit = JBossAdmin,HttpInvoker

漏洞验证

先用 nmap 扫描查看端口开放情况看是否开放 JBOSS 端口。再使用漏洞测试工具测试 jmx 组件存在情况通过访问 http://ip:jboss端口/ 看是否能进入 jmx-console 和 web-console 。

 

0x02 不常见应用的未授权访问

16. ldap未授权访问

漏洞描述

LDAP中文全称为：轻型目录访问协议（Lightweight Directory Access Protocol），默认使用389， LDAP 底层一般使用 TCP 或 UDP 作为传输协议。目录服务是一个特殊的数据库，是一种以树状结构的目录数据库为基础。未对LDAP的访问进行密码验证，导致未授权访问。

解决方法

1）修改ldap的acl，不允许匿名访问。

2）根据业务设置ldap访问白名单或黑名单。

漏洞验证

使用nmap寻找到相关的LDAP服务器，可以使用ldapbrowser直接连接，获取目录内容。

17. Rsync 未授权访问漏洞

漏洞描述

Rsync（remote synchronize）是一个远程数据同步工具，可通过 LAN/WAN 快速同步多台主机间的文件，也可以同步本地硬盘中的不同目录。Rsync 默认允许匿名访问，如果在配置文件中没有相关的用户认证以及文件授权，就会触发隐患。Rsync 的默认端口为 837。

解决方法

方式一：修改rsync的配置

更改rysnc默认配置文件/etc/rsyncd.conf，添加或修改参数：

访问控制；设置host allow，限制允许访问主机的IP；：hosts allow = 123.123.123.123。

权限控制；设置read only，将模块设置成只读；Read only = true

访问认证；设置auth、secrets，认证成功才能调用服务。

模块隐藏；设置list，将模块隐藏；list =false

数据加密传输：Rsync 默认没有直接支持加密传输，如果需要 Rsync 同步重要性很高的数据，可以使用 ssh。

详情可参考官方doc：https://rsync.samba.org/ftp/rsync/rsyncd.conf.html

漏洞验证

#rsync rsync://{target_ip}/

#rsync rsync://172.16.2.250:873/

#rsync rsync://172.16.2.250:873/src

利用rsync下载任意文件

rsync rsync://172.16.2.250:873/src/etc/passwd ./

18. VNC 未授权访问漏洞

漏洞描述

VNC 是虚拟网络控制台Virtual Network Console的英文缩写。它是一款优秀的远程控制工具软件由美国电话电报公司AT&T的欧洲研究实验室开发。VNC是基于 UNXI 和 Linux 的免费开源软件由 VNC Server 和 VNC Viewer 两部分组成。VNC 默认端口号为 5900、5901。VNC 未授权访问漏洞如被利用可能造成恶意用户直接控制受控主机危害相当严重。

解决方法

方式一：配置账号密码

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

漏洞验证

vncviewer 192.168.15.8

19. dubbo 未授权访问漏洞

漏洞描述

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

解决方法

方法一：

配置dubbo认证。

方法二： 设置防火墙策略

如果正常业务中dubbo 服务需要被其他服务器来访问，可以通过 iptables 策略，仅允许指定的 IP 来访问服务。

iptables -A INPUT -s x.x.x.x -p tcp --dport 11211 -j ACCEPT

注意：x.x.x.x  修改为实际IP或者网段,同时禁止对外开放。

漏洞验证

telent IP port

链接进入dubbo 服务，进行操作。

20. NFS 共享目录未授权访问

漏洞描述

Network File System(NFS)，是由SUN公司研制的UNIX表示层协议(pressentation layer protocol)，能使使用者访问网络上别处的文件就像在使用自己的计算机一样。服务器在启用nfs服务以后，由于nfs服务未限制对外访问，导致共享目录泄漏。

解决方法

利用iptables限制端口2049和20048端口的访问，禁止外部访问。

漏洞验证

apt install nfs-common 安装nfs客户端

showmount -e 192.168.70.162 查看nfs服务器上的共享目录

mount -t nfs 192.168.70.162:/grdata /mnt 挂载到本地

21. druid 未授权访问   

漏洞描述

当开发者配置不当时就可能造成未授权访问下面给出常见Druid未授权访问路径

/druid/websession.html

/system/druid/websession.html

/webpage/system/druid/websession.html(jeecg)

解决方法

1. 配置访问账号密码
2. 禁止对外网开放访问。

漏洞验证

访问相关的路径：http://10.20.37.152:7001/BSCC/druid/index.html

22. CouchDB 未授权访问漏洞

漏洞描述

CouchDB 是一个开源的面向文档的数据库管理系统，可以通过 RESTful JavaScript Object Notation (JSON) API 访问。CouchDB会默认会在5984端口开放Restful的API接口，用于数据库的管理功能。 CouchDB数据库存在未授权访问漏洞，利用该未授权访问漏洞可执行任意系统命令，可能造成数据的丢失和泄露。

解决方法

方式一：配置密码

设置访问密码，在 /etc/couchdb/local.ini 中找到“[admins]”字段配置密码。

漏洞验证

使用nmap寻找相关的端口和服务，直接访问脆弱的服务：

curl http://192.168.18.129:5984

curl http://192.168.18.129:5984/_config

23. Atlassian Crowd 未授权访问漏洞

漏洞描述

Atlassian Crowd和Atlassian Crowd Data Center都是澳大利亚Atlassian公司的产品。Atlassian Crowd是一套基于Web的单点登录系统。该系统为多用户、网络应用程序和目录服务器提供验证、授权等功能。Atlassian Crowd Data Center是Crowd的集群部署版。Atlassian Crowd和Crowd Data Center在其某些发行版本中错误地启用了pdkinstall开发插件，使其存在安全漏洞。攻击者利用该漏洞可在未授权访问的情况下对Atlassian Crowd和Crowd Data Center安装任意的恶意插件，执行任意代码/命令，从而获得服务器权限。

解决方法

1.升级到最新版本(截止目前，最新版本为3.5.0)

2.设置访问/crowd/admin/uploadplugin.action的源ip

漏洞验证

进行上传一个标准的插件，来自atlassian-bundled-plugins中的applinks-plugin-5.4.12.jar

curl --form "[email protected]" http://192.168.18.138:8095/crowd/admin/uploadplugin.action -v

访问地址并执行命令：http://10.10.20.166:8095/crowd/plugins/servlet/exp?cmd=cat%20/etc/shadow

24. Jupyter Notebook 未授权访问漏洞

漏洞描述

Jupyter Notebook（此前被称为 IPython notebook）是一个交互式笔记本，支持运行 40 多种编程语言。如果管理员未为Jupyter Notebook配置密码，将导致未授权访问漏洞，游客可在其中创建一个console并执行任意Python代码和命令。

解决方法

• 开启身份验证，防止未经授权用户访问。
• 访问控制策略，限制IP访问，绑定固定IP。

漏洞验证

利用nmap 扫描端口，获取到服务，访问地址：http://192.168.18.129:8888

利用terminal命令执行：New > Terminal 创建控制台

可以执行任意命令

25. RTSP未授权访问漏洞

漏洞描述

RTSP（Real Time Streaming Protocol），实时流传输协议，是TCP/IP协议体系中的一个应用层协议，该协议定义了一对多应用程序如何有效地通过IP网络传送多媒体数据，被广泛用于视频直播领域,为方便用户远程监控摄像头内容，许多摄像头厂商会在摄像头或NVR中开启RTSP服务器。

攻击者可通过VLC等视频播放软件打开rtsp地址进行摄像头画面的实时查看。

解决方法

1. 修改默认口令。
2. 禁止开放到外网。

漏洞验证

使用nmap扫描开放的端口和服务，初步判断后使用相关的工具的链接测试。

这里以VLC media player为例进行漏洞验证。单击“媒体”选项，选择“打开网络串流”。
在弹出的窗口中输入网络URL：
rtsp://admin:[email protected]:554/cam/realmonitor?channel=2&subtype=1

说明:
RTSP地址：rtsp://username:password@ip:port/cam/realmonitor?channel=1&subtype=0
username: 用户名。例如admin。
password: 密码。例如admin。
ip: 为设备IP。例如 192.168.1.1。
port: 端口号默认为554，若为默认可不填写。
channel: 通道号，起始为1。例如通道2，则为channel=2。
subtype: 码流类型，主码流为0（即subtype=0），辅码流为1（即subtype=1）。
例如，请求某设备的通道2的辅码流，URL如下
rtsp://admin:[email protected]:554/cam/realmonitor?channel=2&subtype=1

单机“播放”按钮，等待一会：

0x03 总结

攻击者发现并且利用此类漏洞的成本低，效果明显，影响巨大，因此此类漏洞必须高度重视。

 

原文链接：https://blog.csdn.net/qq_29277155/article/details/108390891