从枯燥的渗透测试到发现高危CVE

引言

在一次发现甚少的枯燥渗透测试中，我在全国多个组织使用的专有工业维护管理系统中发现了一个高危漏洞。这清楚地提醒我们，所谓的"过时"漏洞（如SQL注入）至今仍构成实际风险——而"再努力一点"的心态终会得到回报。

我正在对某个组织的资产进行黑盒渗透测试。经过数天的枚举和验证，没有发现特别有趣的内容。侦察阶段识别出的大多数可访问资产都是具有明确定权方案的应用程序，机构企业网站缺乏任何有意义的功能或有价值的信息。

该组织还依赖第三方服务和软件，如Microsoft 365租户和WordPress等CMS平台——不幸的是，这些都没有显示可见的错误配置或过时组件迹象。一切似乎都设置得很好且运行平稳。我以为这次不会有什么有价值的发现可以呈现给客户。

在侦察阶段早期，一个特定应用程序引起了我的注意。这是一个用于管理工业设备和维护例程的系统。根据供应商网站的描述，该平台可能包含与被测试组织高度相关的信息。

不幸的是，它似乎也只是另一扇关闭的门。访问时只显示登录和密码恢复页面。我尝试了不同的技术，但没有工作流程可以被利用。也没有默认或泄露的凭据。这似乎是一个健壮的系统——或者至少，我当时是这么认为的。

在几乎一无所获并接近结束这次任务时，我重新回到了那个应用程序。我重新测试了加载、登录和密码恢复请求中的可用输入点。都没有效果。

仔细观察这些请求后，我注意到设置了一个非标准cookie，与使用的框架无关。它叫做LanguageCombobox，在页面首次加载时定义，保存着为系统选择的语言值。

我觉得这很奇怪，因为我以前从未见过这种行为。虽然我不是这类功能通常如何实现的专家，但在我能回忆起的其他所有情况下，选择的语言值都以不同的方式存储和检索以进行条件渲染。考虑到可能有一些易受攻击的功能与之相关，我尝试了已经在其他输入点上尝试过的常见注入。

在应用程序的根目录或登录页面上没有结果。于是我转到密码恢复页面，在cookie值中尝试了一个简单的SQL注入——果然…

应用程序直接响应了底层数据库返回的错误：“在字符串’‘后未闭合引号。\r\n在’‘附近语法不正确。“当我添加另一个引号使底层查询再次有效时，页面正常加载。

由于这是一个盲注，我使用了一些有效负载来推断底层数据库的类型（幸运的是，这个特定资产没有位于WAF后面——或者我直接命中了它）。使用有效负载' WAITFOR DELAY '0:0:10'，应用程序花了二十秒才响应（是的，延迟时间翻倍），确认后端数据库是SQL Server。

从那里，我使用SQLMap开始提取数据库中存储的信息。

当我尝试从可用表（如通用配置表）中提取记录时，我注意到SQLMap使用的有效负载与应用程序的处理冲突。具体来说，当使用格式<database>.dbo.<table>引用表对象时，应用程序响应HTTP 500错误。

因此，我不得不编写一个简单的tamper脚本（你可以在这里找到）来将有效负载调整为正确格式，这起到了作用。

我能够通过这种方式枚举所有表中的信息。一些有价值的信息包括通用系统配置、与其他系统的集成数据、应用程序用户详细信息（密码不幸被加密）以及业务相关信息，包括业务合作伙伴联系人的PII。

由于使用的数据库是SQL Server（我认为是这个系统的首选数据库），我本可以使用堆叠查询任意修改记录值，对存储数据的完整性和可用性以及应用程序的正常运行构成风险。

该漏洞最初通过客户报告，客户转发了发现结果以便采取修复措施。任务结束后，在尝试直接联系供应商后，我通过VulDB提交了该漏洞并等待。一周多后，我收到确认，它已发布为CVE-2025-8220。

这次任务强烈提醒我们，即使是最平淡无奇的测试，只要稍加坚持就可能发生急剧转变。我发现的漏洞并没有隐藏在复杂的逻辑或认证绕过后面——它静静地存在于一个cookie中，那种我们经常忽略的地方。

最后，这次经历证明，即使情况看起来冷淡，应用"再努力一点"的心态也能带来显著影响客户安全和工作质量的成果。