一次 .NET 后台渗透实录：从黑盒到白盒，JWT 伪造拿下后台

一、登录框常规测试

目标是一个常见的后台登录页面。先用插件扫了一遍接口，不出所料，全部返回 403。

抓登录包看数据格式，发现是 JSON 提交。本来想试试 Fastjson 反序列化，但响应头暴露了服务器信息：IIS 7.5 + ASP.NET 8，Java 那一套漏洞直接排除。

转向爆破弱口令，却发现验证码无法绕过——删除验证码字段返回"不能为空"。

有人可能会说用 OCR 识别，但这里的验证码是 Base64 内嵌的，现有爆破工具都不支持，需要写中转脚本配合，较麻烦，先放一放。

于是我又想到了，修改返回包，看看能否中个奖，绕过登录。

返回了，JWT 认证格式。我寻思，JWT 不都是 Java 里面的，.NET 竟然也会有？

于是 F12，全局搜索关键字，翻找半天，并未发现相关的参数，点燃的希望又破灭了。

常规思路走完一遍，还是没有突破，剩下最后一招：扫目录。

二、Swagger 未授权访问

目录扫描命中了 Swagger 接口文档。

文档里列出了大量后台接口，但绝大多数都需要鉴权，只有两三个字典类接口能匿名访问，且不含敏感信息。

不过有一个有价值的收获：响应中暴露了后端框架信息——Vol.Core（一个开源的 .NET 后台框架）。

三、源码审计：定位加密逻辑

既然知道了框架，直接把源码拉下来做源码审计。

翻到 SQL 初始化文件，里面存了默认管理员密码，但是 Base64 解不开，说明是加密存储，需要找密钥。

接着翻配置文件，找到了 Key。

但直接拿这个 Key 还是解不出来，说明加密逻辑不是简单的 AES/DES。全局搜索 decrypt 定位解密函数。

发现一个有意思的地方：函数命名是 Des，但内部实际调用的是 AES。密钥取配置值的前 16 位。

解密成功，拿到默认 admin 密码，登录——失败。说明默认密码已被修改。

四、JWT 伪造：第一次尝试

思考片刻：配置文件里同时存在 JWT 密钥，如果默认密钥没改，直接伪造 Token 就能进后台。

伪造 Token 需要知道参数结构，前端没有，但这是后端，继续全局搜索 JWT，定位到核心生成逻辑。

需要六个字段：

字段	含义
jti	用户ID
iat	当前时间戳
nbf	当前时间戳
exp	过期时间戳
iss	配置中的 Issuer
aud	配置中的 Audience

构造 Payload：

{
  "jti": "1",
  "iat": "1788013440",
  "nbf": "1788013440",
  "exp": "1788020640",
  "iss": "vol.core.owner",
  "aud": "vol.core"
}

用配置文件里的密钥签名后请求——401。

说明 JWT 密钥也被改了。继续硬刚的话，只能审未授权漏洞或前台 RCE。

但审了半个多小时，确认 Swagger 里的接口和代码里的接口一一对应，不存在未授权接口。

五、意外收获：string/{key} 接口读取真实配置

正当准备放弃时，重新仔细看了一遍接口文档，发现一个被忽略的接口：string/{key}。

而这个接口，findsomething 插件并未提取出来，所以在一开始接口 fuzz 的时候，并未注意到。

起初不知道这个接口是干什么的，丢给 AI 生成了一批常见 key 值挨个试，还真发现了问题。

string/Path → 返回系统环境变量
string/username → 返回系统用户名
string/os → 返回 Windows

第一反应是命令注入或文件读取，但试了 id、cmd:whoami 都没反应。

卡了一个小时无法深入利用。

回头看接口定义：

"/string/{key}": {
  "get": {
    "tags": ["ApiConfig"],
    "parameters": [
      {
        "name": "key",
        "in": "path",
        "required": true,
        "schema": { "type": "string" }
      }
    ],
    "responses": {
      "200": { "description": "Success" }
    }
  }
}

推测逻辑是：根据 key 从 API 配置文件中返回对应的字符串值。

关键来了——我手上有源码啊。匹配了三层参数后确认，这个接口就是从配置中按 key 取值。

一一对应。

既然前面 JWT 默认密钥伪造失败，那就用这个接口把真实密钥读出来。

成功拿到真实密钥。

六、二次伪造：拿下后台权限

用读到的真实密钥重新签发 JWT，调用用户列表接口测试。

接口直接返回了 1000+ 条用户数据，且包含密码字段。

用前面审计到的 AES 密钥解密，发现存在弱口令（如 123456），只是用户名是中文姓名。

再多说一嘴，在前期审计的时候，发现了上传接口，需 token，但由于是配置原因，aspx 不解析。

最后在登录页面，抓包修改返回包并添加有效 token，即可登录后台。

七、总结

主要坑点在于 .NET 系统的权限校验做得比较好，但好在接口文档泄露了后台框架，且为开源项目，可自行审计，发现配置关键字后一举拿下后台。

这条链路从 Swagger 泄露到配置读取，再到 JWT 伪造，在 .NET 后台渗透中并不罕见。对 .NET 安全、JWT 伪造与源码审计感兴趣的朋友，也欢迎到云栈社区交流实战经验。