0x 01 前言
在日常的渗透测试工作中，常会遇到 ASP.NET WebForms 这类历史较久的框架构建的网站。它们的特点是类似桌面应用的开发模式，页面上往往缺少 JavaScript 文件，导致在不登录的情况下，可测试的接口和功能点非常有限，这无疑增加了测试的难度。今天就记录一次针对此类站点的完整渗透过程，希望能为遇到类似场景的安全爱好者提供一些思路。
0x 02 渗透过程
目标是一个学校的教务系统后台，登录页面路径为 /Login。通常，这种以大写字母开头的路径多见于ASP站点。
使用 Wappalyzer 插件识别，确认后端技术栈为 ASP.NET。
尝试了常见弱口令进行登录，但由于存在验证码，手工测试了几个均告失败。在缺乏JS文件的情况下，目录扫描成了突破口。幸运的是，目标没有部署WAF，扫描得以顺利进行。
扫描结果中，/dev 这个目录引起了注意，这通常是开发人员遗留的调试接口。
访问该目录，页面直接展示了数据库的连接信息，包括服务器名、用户名、密码和数据库名。
随即使用 Goby 对目标进行端口扫描，发现其开放了 MSSQL 数据库端口。思路变得清晰：尝试用泄露的凭据直接连接数据库。
使用 Navicat 成功连接，数据库中包含了大量的师生个人信息，如学号、姓名等。
同时也发现了后台管理员账号及其密码哈希，但由于是加盐哈希，直接破解难度较大。
峰回路转，在 /dev 页面中还发现了一个“重置密码”功能。该功能可以将任意管理员账号密码重置为默认的 admin。
利用此功能重置 admin 账号后，使用 admin/admin 成功登录系统后台。
在后台功能中浏览，发现“学生管理”模块存在上传头像的功能点。
尝试直接上传 .asp 或 .aspx 后缀的 Webshell 文件，前端提示文件类型不合规。这是一种常见的客户端校验。于是先上传一个正常的图片文件，然后通过 Burp Suite 抓包，修改文件名后缀。
修改后缀上传后，虽然返回了“未找到路径”的错误，但通过访问猜测的路径 /Files/Student/1/[上传文件名].aspx，发现文件实际上传成功了。
使用 AntSword（中国蚁剑）成功连接该 Webshell，获得了服务器权限。
通过资产测绘平台搜索，发现这是一套通用的CMS系统，且很多站点都未删除 /dev 这个开发接口。考虑到这类老旧 ASP.NET WebForms 站点后台存在 SQL注入 的可能性较高，便着手进行测试。
开启代理抓包，在后台遍历所有可能带入参数的功能点，然后对抓到的请求包逐个进行测试。
很快，在 /Grade/Report 接口下，参数 ctl00%24cphMain%24txtWhere 对单引号产生了报错。从参数名推断，其值很可能被拼接到了 SQL 语句的 WHERE 条件之后。
初步使用 SQLMAP 测试未能成功，即使将检测等级调到 --level 5 也无济于事。这让人一度怀疑判断有误。后来将报错信息交给 AI 分析，才意识到 SQL 语句需要闭合括号。查看报错信息其实已有所提示，当时可能过于激动而忽略了细节。
正确的 SQLMAP 命令需要指定前缀来闭合原有语句：
sqlmap -r sql.txt --dbms="mssql" --prefix="')" --level 5 --batch
指定 --prefix="')" 参数后，SQLMAP 立刻成功识别并利用了注入点。
根据经验，如果一个参数存在注入，那么其他调用相同数据操作组件的接口，同一参数很可能也存在相同问题。在抓取的一堆请求包中搜索 ctl00%24cphMain%24txtWhere 参数，果然在 /Grade/Report1 接口中再次发现了注入，利用方式完全相同。
0x 03 反思
与当下主流的 Java 框架相比，ASP.NET WebForms 这类老站点在无权限时确实难以切入。但一旦通过某种方式（如本次的密码重置漏洞）进入后台，往往能发现更宽松的安全策略。例如，文件上传功能对后缀的限制较弱，不像一些现代框架会在配置文件中全局限制 jsp 等危险后缀；SQL 注入这类基础漏洞的出现概率也相对更高。
此外，面对 ASP.NET 站点，ViewState 反序列化也是一个经典的攻击思路。但本次目标站点启用了 ViewState MAC 验证，增加了利用难度（这方面还需深入研究）。
0x 04 后续
通过资产测绘，发现使用该框架的站点有一定数量。于是编写脚本，批量检测这些站点的 /dev 接口及其他已发现的漏洞点，又收获了一批注入点。
例如，在另一个站点的后台，发现一个“高级搜索”功能。
抓取其 POST 请求包，发现多个参数与之前遇到的形式类似，如 ctl00%24cphMain%24txtSearchTitle、ctl00%24cphMain%24txtSearchCreated 等。FUZZ 测试证实，这些参数均存在 SQL 注入，只是拼接方式略有不同。
利用报错注入的 Payload 为：' AND 1/DB_NAME() ='。其原理是利用 1/字符串 引发类型转换错误，并通过 = 使整个表达式构成布尔条件以满足语法。
基于此“高级搜索”功能，推测其他管理模块也可能调用相同的筛选逻辑。经过测试，又找到了三四个存在同类注入的接口。最终，这次渗透测试累计提交了数十个高危漏洞。
这次实战经历再次印证了针对传统系统进行渗透测试的思路：信息收集要全面，不放过任何看似不起眼的路径（如 /dev）；对常见的漏洞类型（如弱口令、未授权访问、SQL注入、文件上传）要保持敏感；在遇到阻碍时（如 SQLMAP 跑不出来），仔细分析报错信息往往能发现关键细节。希望这篇在 云栈社区 分享的笔记，能对你有所帮助。
发表于 1 小时前
|
查看: 3|
回复: 0
