EDUSRC校园安全系统JWT弱密钥通杀漏洞剖析

EDUSRC校园安全系统JWT弱密钥通杀漏洞剖析

在针对高校系统的渗透测试中，使用 JSON Web Token (JWT) 作为身份验证和授权机制的系统相当常见。JWT 本质上是一个包含身份验证信息的令牌，用于在客户端和服务器之间安全地传递用户身份与权限。对于安全测试人员而言，JWT 的常见测试点之一就是利用弱密钥进行伪造，从而实现越权访问或任意用户登录。本文将复盘一次在实际测试中，由 JWT 弱密钥引发的、影响多个高校系统的通用漏洞。

漏洞发现与初次测试

在一次对某校系统的测试中，首先进入了一个功能相对简单的后台。后台页面类似一个在线考试系统的个人中心，顶部导航栏包含“首页”、“通知公告”、“政策法规”等选项。主体区域显示了用户的考试记录，例如一条名为“2022年……实验室安全知识竞赛线上选…”的记录，状态为“已结束”，并提供“评阅”按钮。整体功能点较少。

为了寻找测试入口，在尝试点击“修改信息”等功能时进行了抓包。捕获到的 HTTP 请求如下所示（敏感信息已做脱敏处理）：

GET /info/base_info?nocache=1764169866000 HTTP/1.1
Host: [redacted]
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:145.0) Gecko/20100101 Firefox/145.0
Accept: application/json, text/plain, */*
Accept-Language: zh-CN,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Timestamp: 1704169866000
Sign: 6aaa30a5558cc054760c1621bbe20c81
Cauthorization: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIyIiwibmFtZSI6IjEyNTAzMzMwbiwibW9yZ2VuX3VzZXJAZXhhbXBsZS5jb20iLCJleHAiOjE2NzU5MzI5NTA5fQ.SGVFY29kZSJ6IiIsInN1YnNjcmlwdGVkIjoiMCIsInN0YXR1cyI6WyJzdXBwb3J0IjoiYmFja2Ryb3BvZCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmVycyIsImlhdCI6MTYzODk1MzkwMX0.VzZXJpZCI6IjwvcHJlc2VydmVkIn0.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmVycyIsImlhdCI6MTYzODk1MzkwMX0.dTepTnqP2tlm3gUKxKRBhuAv33JI4s0Bu_qpw
Referrer: empty
Sec-Fetch-Dest: cors
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Priority: u=0
Te: trailers
Connection: close

请求的响应返回了用户的详细信息：

HTTP/1.1 200
Server: nginx/1.28.0
Date: Wed, 26 Nov 2025 15:11:38 GMT
Content-Type: application/json;charset=UTF-8
Connection: close
Access-Control-Expose-Headers: config-hash
config-hash: 1736038858
Content-Length: 528

{
  "code": 200,
  "message": "OK",
  "data": {
    "username": "[redacted]",
    "phone": "[redacted]",
    "email": "[redacted]",
    "mentor": "[redacted]",
    "researchDirection": "[redacted]",
    "involveChemicals": 0,
    "involveBiologicalSafety": 0,
    "involveRadiation": 0,
    "involveElectrical": 0,
    "contentAndCondition": "金工实习",
    "emergencyName": "15888888888",
    "emergencyPhone": "[redacted]",
    "id": 3159,
    "user": null,
    "name": "[redacted]",
    "userType": 1,
    "labBeanList": null,
    "mentorList": null,
    "gmtCreate": null,
    "labIds": null,
    "validEmergencyPhone": true
  }
}

分析数据包发现，权限校验并非通过常见的 id 等参数传递，而是依赖于请求头中的 Cauthorization 字段，其值正是一个 JWT 令牌。这提示我们，系统的权限验证逻辑可能就构建在这个 JWT 之上。

JWT 密钥爆破与越权验证

既然怀疑权限由 JWT 控制，接下来的思路就是尝试破解其签名密钥。如果密钥强度不足，便可以伪造任意用户的令牌。这里使用了渗透测试工具无影中的 JwtCrack 模块。

该工具界面清晰地展示了 JWT 的结构：

• Header (头部)： 通常包含签名算法（如 HS256）和令牌类型。
• Payload (载荷)： 存放实际传递的数据，如用户ID(sub)、角色(role)等。
• Verify (签名校验)： 用于验证令牌完整性的部分。

工具还列出了常见的 JWT 漏洞验证项，例如 CVE-2015-2951（将算法修改为none）、CVE-2016-10555（算法混淆攻击）等。

将捕获到的 JWT 令牌放入工具进行密钥爆破。幸运的是，系统使用的密钥强度很低，很快就被常见的弱密钥字典成功破解。

获取密钥后，下一步是验证漏洞的真实危害。通过解码原始 JWT 的 Payload，可以发现其中包含了标识用户的字段（如 userid、sub 或 userNo）。使用破解出的密钥，伪造一个修改了目标用户ID的新 JWT 令牌，替换原请求中的 Cauthorization 头再次发送。

请求报文变为（关键部分已替换）：

GET /info/base_info?nocache=1764169866000 HTTP/1.1
Host: [redacted]
...
Cauthorization: <伪造的JWT，其中userid已修改>
...

服务器返回了另一个用户的敏感信息，响应体如下：

HTTP/1.1 200
...
{
  "code":200,
  "message":"OK",
  "data":{
    "username":"",
    "phone":"",
    "email":"",
    "mentor":"10010700",
    "researchDirection":"未知",
    "labList":["0a6bb93187ac4015ba3c4707b3741298"],
    "involveChemicals":0,
    "involveBiologicalSafety":0,
    "involveRadiation":null,
    "involveElectrical":null,
    "contentAndCondition":"未知",
    "emergencyName":null,
    "emergencyPhone":null,
    "id":2765,
    "user":null,
    "name":null,
    "userType":1,
    "labBeanList":[]
  }
}

这证实了通过伪造 JWT 可以实现越权访问（水平越权），能够查看到其他用户的个人信息。由于当时测试的系统后台功能有限，未能进一步深入，仅将此漏洞作为“越权访问”提交，评定为中危，错过了一个更严重的漏洞形态——任意用户登录（垂直越权）。

漏洞深入：从越权到任意管理员登录

时隔不久，在对另一个高校站点进行测试时，再次遇到了同一套系统。令人惊讶的是，使用相同的方法，JWT 的密钥依然可以被爆破。这表明该漏洞是一个未修复的通用问题。

这一次，测试人员掌握了更全面的利用思路。目标不再是简单的信息查看越权，而是实现任意用户登录，最好是管理员登录。在流量分析中，发现了一个关键的登录接口：

POST /xxxx/auth/api/admin/login HTTP/1.1
Host: [redacted]
Cookie: JSESSIONID=D0F0B722CB901E99DB3A6F1A8EFAF9B0
Content-Length: 0
...
Cgauthorization: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIyMj3LCJycCI6Il9mTlN4MHQiLCJqdGkiOiJhZWM0ZWYwNy1mY2RhLTQ2NWItOGFkNS1lYTEzOWQ1YzI2Y2EiLCJ0aW1lc3RhbXAiOjE3NjQ1MTExNTc0MjR9.nNGCZd9Vjr_OzTi1sYj9lBRmgnKMo

并且后续所有访问后台的请求都携带同一个 JWT 令牌。这清晰地表明，该系统使用 JWT 作为后台全局会话状态。

要伪造管理员令牌，除了需要密钥，还必须知道管理员的用户标识（如 userid）。这类信息有时会在系统的公告、通知等位置泄露。通过信息收集，成功找到了一个管理员的 userid。

利用之前爆破得到的弱密钥，将 JWT Payload 中的用户标识替换为管理员的 userid，重新生成签名，伪造出管理员令牌。使用该令牌访问系统，成功触发角色选择界面。界面列表显示可选择的角色包括：root管理员、院级管理员、系所管理员、检查人员、课题组管理员等。

选择“root管理员”或“校级管理员”等高级别角色后，便畅通无阻地进入了系统管理后台。后台功能强大，主要包括：

1. 组织机构管理： 可以按组织机构、校区楼宇查看和管理所有单位，系统显示实验室总数超过3900个。
2. 人员与角色管理： 在“人员信息”页面，可以查看所有绑定系统角色的用户（如教师、处领导、校级管理员等），并执行“解绑”操作。
3. 全局用户管理： “用户管理”页面展示了全系统的用户列表，包含博士研究生、教职工等不同类型用户，数据量庞大（超过11万条），并提供修改、删除等操作权限。

至此，一个由 JWT 弱密钥导致的“任意用户登录（此处为管理员）”高危漏洞被完整验证。攻击者可以在未授权的情况下，直接获得目标系统的最高管理权限，对数据进行任意增删改查，危害极大。

漏洞的通用性与影响范围

由于该高校系统由同一厂商开发并部署于众多高校，此次发现的 JWT 弱密钥问题并非个例，而是一个“通杀”漏洞。通过提取系统的特征（如特定的接口路径、参数名Cauthorization、返回数据结构等），可以快速定位其他使用同款系统的学校。

在后续的测试中，以此方法连续在多个高校的同一系统中复现了该漏洞，并提交了安全报告。部分漏洞状态显示为“中危-已修复”或“高危-等待修复”。

厂商在接到多个报告后，修复速度较快。修复方案相对简单直接：将默认的弱密钥更换为足够强壮的随机密钥即可从根本上解决此问题。这也从侧面说明，开发者在初始部署时忽视了密钥安全这一基本配置。

总结与反思

本次漏洞利用链清晰而经典：

1. 发现JWT鉴权： 在流量中发现使用 JWT 作为身份凭证。
2. 爆破弱密钥： 利用工具对 JWT 签名密钥进行爆破并成功。
3. 越权测试： 通过修改 Payload 中的用户标识，验证越权访问漏洞。
4. 信息收集： 寻找管理员用户标识。
5. 构造恶意令牌： 使用弱密钥伪造管理员身份的 JWT。
6. 实现特权登录： 利用伪造令牌登录系统后台，获取完全控制权。

这个案例给开发者和安全人员都带来了警示：

• 对开发者而言： 在使用 JWT 时，必须使用密码学安全的随机生成的强密钥，并定期轮换。绝不能使用默认密钥、简单单词或短字符。密钥的安全管理应被视为系统安全的基础。
• 对安全测试人员而言： 在测试中遇到 JWT 时，应将其列为常规检查项。不仅要测试 alg: none、算法混淆等逻辑漏洞，也要将弱密钥爆破纳入测试流程。许多“简单”的漏洞往往因为思维定式或测试项遗漏而被忽视，却可能成为通往核心系统的捷径。

在网络/系统安全中，身份验证环节的坚固与否直接决定了整个系统的安全水位。一个看似微小的密钥配置失误，足以导致全线溃败。安全建设需要开发者与测试者共同努力，于细微处见真章。

参考资料

[1] 记一次EDUSRC简单却容易忽视的通杀, 微信公众号：mp.weixin.qq.com/s/NkXNSa6RlF89kDzahGujaQ

版权声明：本文由 云栈社区 整理发布，版权归原作者所有。