快盘下载：好资源、好软件、快快下载吧！

快盘排行|快盘最新

当前位置：首页 → 软件教程 → 电脑软件教程 → 常见未授权访问漏洞风险及修复建议

常见未授权访问漏洞风险及修复建议

时间：2022-08-25 13:10:12人气：次作者：快盘下载我要评论

在企业上云过程中，我们发现越来越多的企业业务在部署数据库服务或大数据应用过程中，常常存在配置不当的问题，从而导致未授权访问漏洞的出现，引发业务数据泄露风险。

未授权漏洞定义

未授权访问漏洞是一个在企业内部非常常见的问题，这种问题通常都是由于安全配置不当、认证页面存在缺陷，或者在启动过程中未配置认证导致。当企业对外的服务和端口对公网开放，并且对用户的访问没有做任何限制时，可能会泄露业务数据或内部敏感信息，部分数据可能被攻击者进一步利用以执行系统命令，操作系统文件，进而对系统造成破坏或重大数据泄露威胁。

本文主要介绍常见的未授权数据泄露风险以及相关加固修复建议，为您提供安全最佳实践。

ElasticSearch 未授权访问MongoDB 未授权访问Hadoop 未授权访问Kibana 未授权访问CouchDB 未授权访问mysql 弱口令SQL Server 弱口令PostgreSQL 弱口令Confluence 未授权访问漏洞

常见未授权漏洞

ElasticSearch 未授权访问

风险概述：

Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。

Elasticsearch默认会在9200或9300端口对外开放，用于提供远程管理数据的功能。任何连接到服务器端口上的人，都可以调用相关API对服务器上的数据进行任意的增删改查。

检测方式：

curl http://公网IP:9200/_cat/indices/

若返回集群名称等敏感信息，则说明存在相关风险。

修复建议：

1）9200端口不要对外开放，如需开放，建议在云控制台-安全组限制只允许指定IP才能访问9200端口，或者在主机防火墙上设置禁止外网访问9200端口： 

// accept 
## iptables -A INPUT -p tcp -s 127.0.0.1 --dport 9200 -j ACCEPT 
## iptables -A INPUT -p udp -s 127.0.0.1 --dport 9200 -j ACCEPT 

// drop
## iptables -I INPUT -p tcp --dport 9200 -j DROP 
## iptables -I INPUT -p udp --dport 9200 -j DROP 

// 保存规则并重启 
## service iptables save
## service iptables restart

2）在config/elasticsearch.yml中为9200端口设置认证，相关配置参数可参考：

http.basic.enabled true #启动认证，开启会接管全部HTTP连接
http.basic.user "admin" #配置认证账号
http.basic.password "admin_pwxxxxx" #配置复杂认证密码，建议包含数字、大写字母、小写字母、特殊字符中的三种
http.basic.ipwhitelist ["localhost", "127.0.0.1"]

3）使用nginx搭建反向代理，通过配置Nginx实现对Elasticsearch的认证；

MongoDB 未授权访问

风险概述：

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

造成未授权访问的根本原因就在于启动 Mongodb 的时候未设置 --auth 参数，忽略了给数据库添加上账号密码（默认空口令），使用默认空口令将直接导致恶意攻击者无需进行账号认证就可以登陆到数据服务器。

检测方式：

(1) 检测是否仅监听 127.0.0.1

方法1：
ps -ef|grep mongodb   //查看命令行是否绑定了本地地址，为--bind_ip 127.0.0.1

方法2：
vim /etc/mongodb.conf //查看bind_ip字段是否为bind_ip = 127.0.0.1

(2) 检测是否开启 auth 认证 

mongod --auth  //查看是否需要认证密码
vim /etc/mongodb.conf //查看auth字段是否为 true
auth = true

修复建议：

1）为MongoDB添加认证：MongoDB 启动时添加–auth参数、为MongoDB添加用户认证；

2）MongoDB 自身带有一个HTTP服务和并支持REST接口，在2.6以后这些接口默认是关闭的。MongoDB默认会使用默认端口监听web服务，一般不需要通过web方式进行远程管理，建议禁用。可以修改配置文件设置 nohttpinterface=false

或在启动的时候选择参数 --nohttpinterface。

3）使用云控制台安全组防火墙或本地系统防火墙对访问源IP进行控制，如果仅对内网服务器提供服务，建议勿将 MongoDB服务发布到互联网上。

4）启动时加入参数 --bind_ip 127.0.0.1 或在 /etc/mongodb.conf 文件中添加以下内容：bind_ip = 127.0.0.1，只允许本地访问。

Hadoop 未授权访问

风险概述：

Hadoop是一款由Apache基金会推出的分布式系统框架，它通过著名的MapReduce算法进行分布式处理，Yarn是Hadoop集群的资源管理系统。

由于部分用户服务器在业务部署过程中，直接开放了 Hadoop 机器 HDFS 的 50070 Web 端口及部分默认服务端口，黑客可以通过命令行操作多个目录下的数据，如进行删除，下载，目录浏览甚至命令执行等操作，产生极大的危害。

模块

节点

默认端口

HDFS

Namenode

50070

HDFS

SecondNameNode

50090

HDFS

DataNode

50075

HDFS

Backup/Checkpoint node

50105

WebUI

Hadoop YARN ResourceManager WebUI

8088

MapReduce

JobTracker

50030

MapReduce

TaskTracker

50060

通过访问 NameNode WebUI 管理界面的 50070 端口，可以下载任意文件，如果 DataNode 的默认端口 50075 开放，攻击者可以通过 HDSF 提供的 restful API 对 HDFS 存储的数据进行操作，环境启动后，没有配置身份认证，攻击者可以未授权访问到Hadoop YARN ResourceManager WebUI页面，从而执行恶意命令控制服务器。

检测方式：

访问 http://192.168.xx.xx:8088/cluster，检查YARN ResourceManager WebUI 是否对公网开放

本地检查Hadoop 50070、50075等端口是否对公网开放。

修复建议：

网络访问控制

登录云控制台，设置“安全组”访问控制策略，将 Hadoop 默认开放的多个端口对公网全部禁止或限制可信任的 IP 地址才能访问包括 50070 以及 WebUI 等相关端口

关闭公网敏感服务

如无必要，关闭 Hadoop Web 管理页面

启用认证功能

启用 Kerberos 认证功能，或部署Knox、Nginx之类的反向代理系统，防止未经授权用户访问

Kibana 未授权访问

风险概述：

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

检测方式：

直接访问 kibana 的页面，如：

http://192.168.126.130:5601/ https://192.168.126.130/app/kibana# http://192.168.126.130:5601/app/kibana#/

若无需账号密码可以登录进入界面，则说明在受影响范围。

修复建议：

设置防火墙策略，限定制定 IP 访问服务；设置 kibana 监听本地地址，并设置ElasticSearch登录的账号和密码；

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

elasticsearch.url: "http://127.0.0.1:9200"
#这里输入ElasticSearch的账号和密码
elasticsearch.username: "user"
elasticsearch.password: "pass"

Step2：使用htpasswd创建kibana登录的账号密码，这里可以复用ElasticSearch创建的账号密码，也可以重新创建一个。

htpasswd -c /usr/local/service/nginx/conf/htpasswd username
配置 nginx 反向代理，配置好后，重启 nginx 和 kibana，通过15601登录验证访问Kibana
server {
    # 通过反向代理对kibana身份认证
    listen 15601;
    server_name localhost;
    location / { 
        auth_basic "xxxxx";
        auth_basic_user_file /usr/local/service/nginx/conf/htpasswd;
        
        proxy_pass http://127.0.0.1:5601;
         }
     }

CouchDB 未授权访问

风险概述：

Apache CouchDB 是一个开源数据库，默认会在5984端口开放Restful的API接口，如果使用SSL就会监听在6984端口，用于数据库的管理功能。其HTTP Server默认开启时没有进行验证，而且绑定在0.0.0.0，所有用户均可通过API访问导致未授权访问。

在官方配置文档中对HTTP Server的配置有WWW-Authenticate：Set this option to trigger basic-auth popup on unauthorized requests，但是很多用户都没有这么配置，导致漏洞产生。

检测方式：

curl http://192.168.126.130:5984

curl http://192.168.126.130:5984/_config

若返回CouchDB版本或配置等敏感信息，则说明存在相关风险。

修复建议：

1）指定CouchDB绑定的IP （需要重启CouchDB才能生效） ：在 /etc/couchdb/local.ini 文件中找到 bind_address = 0.0.0.0，把 0.0.0.0 修改为 127.0.0.1 ，然后保存。注：修改后只有本机才能访问CouchDB。

2）设置访问密码 （需要重启CouchDB才能生效） 在配置文件 /etc/couchdb/local.ini中找到 [admins] 字段配置密码

MySQL弱口令

风险概述：

MySQL服务器未设置 root 账号口令或者某个账号使用了简单的口令，导致黑客可以远程不使用口令连接或者很容易猜测到账号口令，进而直接登录数据服务器获取敏感数据。

检测方式：

使用 MySQL 客户端以空口令登录或者账号/口令形式进行猜解，如果能够登录，则表示存在MySQL空口令/弱口令漏洞。

修复建议：

建议在 MySQL 中为账号加一个安全的口令，一个安全的口令应该包含以下四项中的三项：

（1）大写字母

（2）小写字母

（3）特殊字符

（4）数字

SQL Server 弱口令

风险概述：

SQL Server（微软公司开发的数据库系统）的1433端口主要供对外提供数据管理服务，由于很多企业用户习惯经常开启1433端口进行管理服务器和更新服务器资源，不法黑客趁机利用 sa 弱口令进行端口爆破，入侵企业服务器，给企业造成难以弥补的损害。

检测方式：

使用 SQL Server 客户端以空口令登录或者账号/口令形式进行猜解，如果能够登录，则表示存在 SQL Server 空口令/弱口令漏洞。

修复建议：

建议在 SQL Server 中为账号加一个安全的口令，一个安全的口令应该包含以下四项中的三项：

（1）大写字母

（2）小写字母

（3）特殊字符

（4）数字

PostgreSQL 弱口令

风险概述：

PostgreSQL是一个功能强大的开源对象关系数据库系统，其默认数据库端口为 5432，很多企业在使用过程中由于疏忽，将其开放在了公网且配置了简单口令，导致黑客可以远程很容易猜测到账号口令，进而直接登录数据服务器获取敏感数据。

检测方式：

使用PostgreSQL客户端以空口令登录或者账号/口令形式进行猜解，如果能够登录，则表示存在 PostgreSQL 空口令/弱口令漏洞。

修复建议：

建议在 PostgreSQL 中为账号加一个安全的口令，一个安全的口令应该包含以下四项中的三项：

（1）大写字母

（2）小写字母

（3）特殊字符

（4）数字

Confluence 未授权访问漏洞

风险概述：

Atlassian Confluence是Atlassian公司出品的专业wiki程序。它可以作为一个知识管理的工具，通过它能够实现团队成员之间的协作和知识共享，该组件历史上爆出多个高危远程代码执行漏洞。包括：

CVE-2019-3396

2019年3月20日，Confluence官方发布安全公告，在Confluence Server和Data Center 6.14.2版本前产品中存在存在一处未授权的目录穿越漏洞，通过该漏洞，攻击者可以读取任意文件，或利用Velocity模板注入执行任意命令

CVE-2021-26084

2021年8月25日， Atlassian官方披露了一个关于Confluence 的一个高危OGNI注入漏洞， 此漏洞允许经过身份验证或在某些情况下未授权的攻击者在Confluence Server或Data Center实例上执行任意代码，几乎影响所有Confluence的所有版本

CVE-2022-26134

2022年6月3日，Atlassian官方发布官方公告，披露Confluence Server和Data Center 存在OGNL 注入漏洞，远程攻击者在未经身份验证的情况下，可构造OGNL表达式进行注入，实现在Confluence Server或Data Center上执行任意代码，CVSS评分为10。

相关漏洞细节与PoC已被公开披露，且已有外部企业被外部攻击者利用。

检测方式：

用户可通过查看当前Confluence版本是否在受影响范围内，对当前服务是否受此漏洞影响进行排查。

如下图所示，选择“关于Confluence”，即可对当前版本进行查看。

常见未授权访问漏洞风险及修复建议

查看当前版本

修复建议（推荐）：

官方建议用户升级至最新版本，以保证服务的安全性及稳定性。

参照上表，升级至修复版本

下载链接：https://www.atlassian.com/software/confluence/download-archives

临时修复方案参考：

下面以7.4.1版本为例，使用临时防护措施进行修复（可能存在不稳定性）

先下载如下三个文件并上传到confluence服务器

https://packages.atlassian.com/maven-internal/opensymphony/xwork/1.0.3-atlassian-10/xwork-1.0.3-atlassian-10.jar 
https://packages.atlassian.com/maven-internal/opensymphony/webwork/2.1.5-atlassian-4/webwork-2.1.5-atlassian-4.jar 
https://confluence.atlassian.com/doc/files/1130377146/1137639562/3/1654274890463/CachedConfigurationProvider.class

修复步骤：

[root@centos ~]# cd /opt/CVE-2022-26134_repair/
[root@centos CVE-2022-26134_repair]# ll
total 524
-rw-r--r--. 1 root root   7186 Jun  5 10:55 CachedConfigurationProvider.class
-rw-r--r--. 1 root root 352630 Oct 14  2021 webwork-2.1.5-atlassian-4.jar
-rw-r--r--. 1 root root 170369 Jun  2 16:39 xwork-1.0.3-atlassian-10.jar
[root@centos CVE-2022-26134_repair]# cd /opt/atlassian/confluence/
[root@centos confluence]# ll
total 1340
-rw-r--r--.  1 root       root 975517 Jun  5 10:33 atlassian-agent.jar
drwxr-xr-x.  3 root       root   4096 Jun  5 10:35 bin
-rw-r--r--.  1 root       root  19540 Jun 11  2020 BUILDING.txt
drwxr-xr-x.  3 root       root   4096 Jun  5 10:31 conf
drwxr-xr-x. 27 root       root   4096 Jun  5 10:31 confluence
-rw-r--r--.  1 root       root   5545 Jun 11  2020 CONTRIBUTING.md
-rw-r--r--.  1 root       root 128417 Jun  5 10:31 install.reg
drwxr-xr-x.  7 root       root   4096 Jun  5 10:31 jre
drwxr-xr-x.  2 root       root   4096 Jun  5 10:31 lib
-rw-r--r--.  1 root       root  58153 Jun 11  2020 LICENSE
drwxr-xr-x.  2 root       root  69632 Jun  5 10:31 licenses
drwx------.  2 confluence root   4096 Jun  5 10:35 logs
-rw-r--r--.  1 root       root   2401 Jun 11  2020 NOTICE
-rw-r--r--.  1 root       root   2291 Jun 11  2020 README.html
-rw-r--r--.  1 root       root   3334 Jun 11  2020 README.md
-rw-r--r--.  1 root       root   1202 Jun 11  2020 README.txt
-rw-r--r--.  1 root       root   7072 Jun 11  2020 RELEASE-NOTES
-rw-r--r--.  1 root       root  16738 Jun 11  2020 RUNNING.txt
drwxr-xr-x.  4 root       root   4096 Jun  5 10:31 synchrony-proxy
drwx------.  3 confluence root   4096 Jun  5 10:39 temp
-rwx------.  1 root       root  13586 Jun 11  2020 uninstall
drwxr-xr-x.  2 root       root   4096 Jun 11  2020 webapps
drwx------.  3 confluence root   4096 Jun  5 10:35 work
[root@centos confluence]# cd confluence/WEB-INF/lib/
[root@centos lib]# mkdir /opt/old_backup
[root@centos lib]# mv xwork-1.0.3.6.jar /opt/old_backup/
[root@centos lib]# mv webwork-2.1.5-atlassian-3.jar /opt/old_backup/
[root@centos lib]# cp /opt/CVE-2022-26134_repair/xwork-1.0.3-atlassian-10.jar /opt/atlassian/confluence/confluence/WEB-INF/lib/
[root@centos lib]# cp /opt/CVE-2022-26134_repair/webwork-2.1.5-atlassian-4.jar /opt/atlassian/confluence/confluence/WEB-INF/lib/
[root@centos lib]# cd /opt/atlassian/confluence/confluence/WEB-INF/classes/com/atlassian/confluence/setup/
[root@centos setup]# ll
total 732
-rw-r--r--. 1 root root    280 Jun 11  2020 atlassian-bundled-plugins.zip
-rw-r--r--. 1 root root 737335 Jun 11  2020 demo-site.zip
-rw-r--r--. 1 root root     15 Jun 11  2020 hsqldb-server.acl
[root@centos setup]# mkdir webwork
[root@centos setup]# cd webwork/
[root@centos webwork]# cp /opt/CVE-2022-26134_repair/CachedConfigurationProvider.class ./

重启confluence服务

/opt/atlassian/confluence/bin/stop-confluence.sh 
/opt/atlassian/confluence/bin/start-confluence.sh

原创声明，本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 本站 删除。

上一篇：2022注册谷歌Gmail账号时提示“此手机号无法用于验证”谷歌账号注册跳过手机号验证的最新详细解决方案
下一篇：干货|不出网上线CS的各种姿势

相关文章

  • OceaseBase与分库分表方案对比

    OceaseBase与分库分表方案对比，首先明确的是，这里的对比都是拿商业的分库分表方案与OB做对比，开源的MyCAT由于功能缺失太多，无可比性...

  • Linux运维工程师面试题 -- 精校版

    1）运维是指大型组织已经建立好的网络软硬件的维护，就是要保证业务的上线与运作的正常，在他运转的过程中，对他进行维护，他集合了网络、系统、数据库、开发、安全、监控......

网友评论

快盘下载暂未开通留言功能。

推荐文章

最新文章

文章排行

相关软件

关于我们| 广告联络| 联系我们| 网站帮助| 免责声明| 软件发布

Copyright 2019-2029 【快快下载吧】 版权所有 快快下载吧 | 豫ICP备10006759号公安备案:41010502004165

声明： 快快下载吧上的所有软件和资料来源于互联网，仅供学习和研究使用，请测试后自行销毁,如有侵犯你版权的，请来信指出，本站将立即改正。