[{"content":"TeamCity CVE-2024-27198 认证绕过漏洞 — 0day 视角的发现与复现方法 免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。\n系列说明：本文是该系列的第一篇，聚焦漏洞的成因分析、实验环境和 0day 视角的发现方法。关于漏洞的利用影响、在野态势、披露争议以及语义漂移模式的横向分析，见第二篇：[[teamcity-cve-2024-27198-impact]]。\n漏洞编号 CVE-2024-27198 CWE分类 CWE-288（备用路径导致认证绕过） 发现时间 2024年2月（由 Rapid7 的 Stephen Fewer 发现） CVSS评分 9.8 (Critical / 严重) 受影响版本 JetBrains TeamCity On-Premises \u0026lt;= 2023.11.3 修复版本 JetBrains TeamCity 2023.11.4 危害描述 未经身份验证的攻击者可通过特定的URL路径绕过认证机制，获取管理员权限并接管TeamCity服务器，进而可能导致供应链投毒攻击。 目录 引言与漏洞背景 漏洞成因分析 漏洞触发环境与复现条件 漏洞发现方法与过程（0day视角） 防御机制与突破点分析 修复与缓解建议 结论：可迁移的发现方法论 参考与来源 1. 引言与漏洞背景 TeamCity 是 JetBrains 开发的一款广泛使用的 CI/CD（持续集成与持续交付）服务器，在企业软件开发生命周期中占据核心地位。由于其掌控着代码构建与部署权限，一旦被攻陷，极易引发大范围的软件供应链攻击。\n2024年2月，Rapid7 漏洞研究团队在 TeamCity 的 Web 组件中发现了两个严重的认证绕过漏洞（CVE-2024-27198 与 CVE-2024-27199）。其中，CVE-2024-27198（CVSS 9.8）允许未经身份验证的攻击者直接获取最高管理权限并实现远程代码执行（RCE）。\n我关注这个漏洞，不只是因为它严重，更因为它的根因很有代表性——不是某个鉴权函数\u0026quot;写错了\u0026quot;，而是请求在多个处理层之间被不同组件\u0026quot;重新理解\u0026quot;，导致鉴权边界和执行边界发生了错位。这种问题单看代码很难发现，常规扫描器也抓不住，但它有一套可以复用的发现方法论。\n本文的核心目标就是还原这套方法论：在不依赖公开利用样例、不先验知道答案的前提下，从零开始走一遍\u0026quot;发现\u0026quot;的过程。\n2. 漏洞成因分析 本节内容依据 Rapid7 官方报告 analysis 部分进行翻译与整理，重点还原\u0026quot;代码层为什么会绕过\u0026quot;，而非仅描述复现步骤。\n该漏洞本质属于 CWE-288（Authentication Bypass Using an Alternate Path）：请求在不同处理层被解释为不同语义，导致鉴权边界与执行边界错位。\n图2-1 鉴权层与执行层对同一请求语义解释不一致，是本漏洞的核心机制。\nRapid7 在报告中指出，关键问题位于 web-openapi.jar 内的 jetbrains.buildServer.controllers.BaseController。在 handleRequestInternal() 中，当请求未触发重定向时，会进入 updateViewIfRequestHasJspParameter() 逻辑；该逻辑会读取请求中的 jsp 参数并尝试覆盖 ModelAndView 的视图目标。\n结合该控制流可得到漏洞成立的三个条件（Rapid7 原文同样给出了示例语义）：\n入口必须是未认证可达且可进入后续处理链的路径 例如一个不存在路径触发 404 处理流。这里的目的不是访问该路径本身，而是让请求进入 BaseController 的后续逻辑。\n请求中携带可影响目标视图/路由的参数 jsp 参数值被设置为受保护的 REST 路径后，会影响 ModelAndView 的最终视图解析目标。\n请求路径语义被伪装为 JSP 相关形式 在路径中引入分号参数与 .jsp 后缀语义后，不同层（容器、鉴权、控制器）对 URI 的解释出现分歧：上层可能把它当成可放行的 JSP 视图请求，而后续路由阶段可能将其规范化/截断后命中真实受保护 API。\n因此，这不是\u0026quot;单点逻辑缺陷\u0026quot;，而是一个多层解析不一致问题： 鉴权层看到的是\u0026quot;看似无害的视图请求\u0026quot;，执行层命中的是\u0026quot;受保护 REST 端点\u0026quot;。一旦错位成立，未认证请求即可跨越访问控制边界，进一步触发管理员级操作链路，最终导致服务器完全失陷风险。\n3. 漏洞触发环境与复现条件 3.1 复现实验环境 操作系统：Windows 11（宿主机） 容器环境：Docker Desktop 目标版本：jetbrains/teamcity-server:2023.11.3（漏洞版） 对照版本：jetbrains/teamcity-server:2023.11.4（修复版） 踩坑备注：[待补充：Docker 部署过程中遇到的配置问题、初始化步骤、需要注意的版本差异等]\n3.2 触发前提条件 漏洞触发并非\u0026quot;单一 URL 命中\u0026quot;，而是需要满足一组语义条件：\n请求首先进入一个未认证可达的处理流（常见是错误路径处理流）。 请求参数中存在可影响视图/路由目标的输入（如 jsp 参数语义）。 请求路径外观被构造成 JSP 相关语义（例如路径后缀和分号参数语义），使不同处理层产生解析分歧。 这三个条件叠加后，可能出现\u0026quot;上层鉴权判断通过，但下层路由命中受保护 API\u0026quot;的错位。\n3.3 复现实验判定标准 本报告采用\u0026quot;对照验证\u0026quot;而非单点命中验证：\n同一类输入在漏洞版（2023.11.3）出现未授权异常可达行为； 同一输入在修复版（2023.11.4）被拒绝或回到正常鉴权行为； 结合代码层分析，能够解释该差异与路径语义解析不一致有关。 4. 漏洞发现方法与过程 本节仅按 0day 视角还原\u0026quot;当时如何发现\u0026quot;： 从未授权基线出发，经通用语义变异发现异常，再通过旧版反编译做灰盒收敛，最后用第二轮定向样本完成复证闭环。\n图4-1 0day视角发现路径：基线建模 -\u0026gt; 语义变异 -\u0026gt; 灰盒收敛 -\u0026gt; 定向验证。\n4.1 方法论与研究约束 为了避免\u0026quot;先知道答案再倒推\u0026quot;，本次实验设定了四个约束：\n第一轮黑盒不直接使用公开利用样例，也不先假设参数名。 先建立未授权访问基线，再做通用语义变异。 只有当异常稳定出现后，才进入反编译灰盒收敛。 后续公开资料仅用于结果对照，不作为前置发现线索。 对应的分析链路是： 基线建模 -\u0026gt; 第一轮通用变异 -\u0026gt; 灰盒收敛 -\u0026gt; 第二轮定向验证。\n4.2 阶段A：未授权基线建模（0day 起点） 先回答一个最基础的问题：目标在未登录状态下\u0026quot;正常应该返回什么\u0026quot;？ 我们对根路径、登录页面、REST 接口和错误路径做了基线测量，得到三类稳定外观：\n受保护入口（如 /overview.html、/app/rest/server）：以 401 text/plain 为主。 登录相关页面（如 /login.html）：200 text/html。 错误路径（如 /does-not-exist）：404 text/html。 这一步的价值是建立\u0026quot;异常参照系\u0026quot;。后续若错误路径不再 404，或未授权请求出现受保护 API 语义，就属于高优先级异常。\n4.3 阶段B：第一轮通用语义变异（不押答案） 第一轮只测试通用 Web 路径语义，不带特定可疑参数。典型样本包括：\n/does-not-exist /does-not-exist/ /does-not-exist// /does-not-exist;x /does-not-exist.jsp /does-not-exist/.jsp 关键观察是：\n/does-not-exist 返回 404 text/html。 /does-not-exist.jsp 与 /does-not-exist/.jsp 返回 401 text/plain。 这说明单纯 .jsp 外观就能改变处理流：请求从\u0026quot;错误页处理链\u0026quot;偏向\u0026quot;认证相关处理链\u0026quot;。 此时还不知道 jsp 参数，但已经能确定灰盒分析应优先关注 .jsp、视图解析、控制器参数读取。\n4.4 阶段C：旧版反编译灰盒收敛 本阶段并非先验锁定 web-openapi.jar，而是先在 WEB-INF/lib 的 web-* 模块（web-core.jar、web-openapi.jar、web-startup.jar、web-diagnostic.jar）中做并行筛查。筛查关键词来自阶段B暴露出的行为特征，即 .jsp、ModelAndView、setViewName、getParameter。\n检索结果显示，相关控制器线索主要集中在 jetbrains/buildServer/controllers/BaseController.java，且命中位于 web-openapi 反编译结果中；同样检索在 web-core 中未出现对应控制器命中。由此，分析重点自然收敛到 web-openapi.jar。\n在 2023.11.3 旧版 web-openapi.jar 中继续反编译和阅读，可定位到 BaseController 的核心逻辑：\nprivate void updateViewIfRequestHasJspParameter(HttpServletRequest request, ModelAndView modelAndView) { boolean isControllerRequestWithViewName = modelAndView.getViewName() != null \u0026amp;\u0026amp; !request.getServletPath().endsWith(\u0026#34;.jsp\u0026#34;); String jspFromRequest = this.getJspFromRequest(request); if (isControllerRequestWithViewName \u0026amp;\u0026amp; jspFromRequest != null \u0026amp;\u0026amp; !jspFromRequest.equals(modelAndView.getViewName())) { modelAndView.setViewName(jspFromRequest); } } protected String getJspFromRequest(HttpServletRequest request) { String jspFromRequest = request.getParameter(\u0026#34;jsp\u0026#34;); if (jspFromRequest != null \u0026amp;\u0026amp; (!jspFromRequest.endsWith(\u0026#34;.jsp\u0026#34;) || jspFromRequest.contains(\u0026#34;admin/\u0026#34;))) { jspFromRequest = null; } return jspFromRequest; } 同时在路径处理辅助逻辑中可见：\npublic static String removeSessionId(String uri) { int semicolon = uri.indexOf(\u0026#34;;\u0026#34;); return semicolon != -1 ? uri.substring(0, semicolon) : uri; } 图4-2 BaseController 参数读取/视图改写与 WebUtil 分号截断的关键代码逻辑标注。\n灰盒阶段的关键信息有三点：\njsp 参数是从代码中发现的，不是先验猜测。 参数在满足约束后会参与 viewName 改写，具有控制流影响能力。 ; 语义处理支持\u0026quot;请求在不同阶段被不同解释\u0026quot;的机制假设。 4.5 阶段D：第二轮定向验证（灰盒驱动） 基于阶段C线索，设计\u0026quot;命中组 + 对照组\u0026quot;并实测：\n样本 漏洞版（2023.11.3） 解释 /does-not-exist?jsp=/app/rest/server;.jsp 200 application/xml 命中 /does-not-exist?jsp=/app/rest/users;.jsp 200 application/xml 命中 /does-not-exist?jsp=/app/rest/server 404 text/html 不满足 .jsp 约束 /does-not-exist?jsp=/app/rest/server;.jspx 404 text/html 不满足 endsWith(\u0026quot;.jsp\u0026quot;) /does-not-exist?jsp=/admin/admin.html;.jsp 404 text/html 命中 admin/ 限制 /does-not-exist/.jsp?jsp=/app/rest/server;.jsp 401 text/plain 与 servletPath.endsWith(\u0026quot;.jsp\u0026quot;) 分支相关 图4-3 命中组与对照组稳定分离，支持\u0026quot;异常可重复、样本可分离\u0026quot;的发现结论。\n命中样本响应体会出现受保护 REST 语义（如 server / users XML），而不是普通 404 页面。 这一步完成了\u0026quot;黑盒异常 -\u0026gt; 代码机制 -\u0026gt; 黑盒复证\u0026quot;的闭环。\n4.6 阶段E：0day视角收尾与转入影响评估 在不依赖修复版对照、也不直接套用公开利用样例的前提下，至阶段D已经可以形成\u0026quot;高置信候选漏洞\u0026quot;的发现结论。依据主要有三点：\n异常可重复：错误路径在特定语义组合下可稳定偏移到受保护 REST 响应语义。 机制可解释：旧版代码中存在与异常现象一致的参数读取与视图改写链路。 样本可分离：命中组与对照组表现稳定分化，不是偶发抖动或单点噪声。 因此，本节到此完成的是\u0026quot;发现阶段闭环\u0026quot;：已经能回答\u0026quot;漏洞是否被发现、发现依据是否充分\u0026quot;。\n后续关于该漏洞的可利用性、在野利用态势以及披露过程中的社区争议，见本系列第二篇：[[teamcity-cve-2024-27198-impact]]。\n5. 防御机制与突破点分析 5.1 目标系统原有防御机制 基于会话/身份的认证过滤链。 基于路径与资源类型的访问控制判定。 对部分视图后缀（如 JSP）的特殊处理逻辑。 5.2 被突破的关键点 该漏洞并不是\u0026quot;认证组件完全失效\u0026quot;，而是认证判定输入与实际执行输入不一致：\n上层鉴权逻辑按\u0026quot;请求外观\u0026quot;判定可放行； 下层控制器/路由按\u0026quot;规范化后语义\u0026quot;执行目标； 二者在分号参数、后缀与参数覆盖语义上存在差异，形成可利用的 Alternate Path。 5.3 防御启示 单点鉴权不足：必须保证\u0026quot;鉴权路径\u0026quot;和\u0026quot;执行路径\u0026quot;使用同一 canonical form。 路径规范化前置：在最上游统一做 URI 规范化并拒绝歧义输入。 语义黑名单不可靠：仅靠后缀/关键字过滤（如 .jsp）容易被组合绕过。 6. 修复与缓解建议 6.1 根本修复 升级至 TeamCity 2023.11.4 及以上版本（官方已修复）。 对无法立即升级的环境，优先采用官方给出的安全补丁方案。 6.2 过渡期缓解措施 将 TeamCity 管理面从公网下线，限制为内网或零信任访问。 通过反向代理/WAF 阻断异常路径语义组合（分号参数、异常后缀、路径-参数联动模式）。 开启并集中审计 TeamCity 访问日志，重点关注未认证请求命中管理 API 的异常行为。 7. 结论：可迁移的发现方法论 本文没有走\u0026quot;已知答案再倒推\u0026quot;的复现路线，而是从零开始还原了完整的发现过程。\n这套方法论的核心只有四步：先做行为基线，再做语义变异；先证实异常，再灰盒收敛；最后用可分离的对照样本验证机制。 每一步单看不复杂，但四步连起来构成的闭环——从\u0026quot;我不知道\u0026quot;到\u0026quot;我确定了\u0026quot;——才是最有价值的部分。\n说实话，我在阶段 B 第一次看到 /does-not-exist.jsp 返回 401 而不是 404 的时候，脑子里想的其实是：\u0026ldquo;这有啥？不就是后缀解析的小差异吗。\u0026ldquo;直到灰盒阶段看到 jsp 参数直接参与 setViewName()，才意识到这不是小差异，而是一条完整的错位链路。这个从\u0026quot;不以为然\u0026quot;到\u0026quot;原来如此\u0026quot;的过程，可能也是这类漏洞最容易被低估的原因。\n这套路径对于同类\u0026quot;认证边界错位\u0026quot;问题，具有普遍适用性。无论是 Java 生态中的 Shiro + Spring 组合，还是反向代理与后端框架之间的规范化差异，都可以用同样的四步框架去逼近。\n关于这类漏洞的横向比较、模式归纳以及审计清单，见本系列第二篇：[[teamcity-cve-2024-27198-impact]]。\n8. 参考与来源 Rapid7 原始漏洞披露声明: CVE-2024-27198 and CVE-2024-27199: JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities (FIXED) JetBrains 官方安全通报: Additional Critical Security Issues Affecting TeamCity On-Premises (CVE-2024-27198 and CVE-2024-27199) – Update to 2023.11.4 Now ","permalink":"https://aries441.tech/posts/vuln-reproduction/teamcity-cve-2024-27198-discovery/","summary":"\u003ch1 id=\"teamcity-cve-2024-27198-认证绕过漏洞--0day-视角的发现与复现方法\"\u003eTeamCity CVE-2024-27198 认证绕过漏洞 — 0day 视角的发现与复现方法\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003e免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e系列说明\u003c/strong\u003e：本文是该系列的第一篇，聚焦漏洞的成因分析、实验环境和 0day 视角的发现方法。关于漏洞的利用影响、在野态势、披露争议以及语义漂移模式的横向分析，见第二篇：[[teamcity-cve-2024-27198-impact]]。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth style=\"text-align: left\"\u003e漏洞编号\u003c/th\u003e\n          \u003cth style=\"text-align: left\"\u003eCVE-2024-27198\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003eCWE分类\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003eCWE-288（备用路径导致认证绕过）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003e发现时间\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003e2024年2月（由 Rapid7 的 Stephen Fewer 发现）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003eCVSS评分\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003e9.8 (Critical / 严重)\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003e受影响版本\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003eJetBrains TeamCity On-Premises \u0026lt;= 2023.11.3\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003e修复版本\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003eJetBrains TeamCity 2023.11.4\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003e危害描述\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003e未经身份验证的攻击者可通过特定的URL路径绕过认证机制，获取管理员权限并接管TeamCity服务器，进而可能导致供应链投毒攻击。\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"目录\"\u003e目录\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e引言与漏洞背景\u003c/li\u003e\n\u003cli\u003e漏洞成因分析\u003c/li\u003e\n\u003cli\u003e漏洞触发环境与复现条件\u003c/li\u003e\n\u003cli\u003e漏洞发现方法与过程（0day视角）\u003c/li\u003e\n\u003cli\u003e防御机制与突破点分析\u003c/li\u003e\n\u003cli\u003e修复与缓解建议\u003c/li\u003e\n\u003cli\u003e结论：可迁移的发现方法论\u003c/li\u003e\n\u003cli\u003e参考与来源\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"1-引言与漏洞背景\"\u003e1. 引言与漏洞背景\u003c/h2\u003e\n\u003cp\u003eTeamCity 是 JetBrains 开发的一款广泛使用的 CI/CD（持续集成与持续交付）服务器，在企业软件开发生命周期中占据核心地位。由于其掌控着代码构建与部署权限，一旦被攻陷，极易引发大范围的软件供应链攻击。\u003c/p\u003e\n\u003cp\u003e2024年2月，Rapid7 漏洞研究团队在 TeamCity 的 Web 组件中发现了两个严重的认证绕过漏洞（CVE-2024-27198 与 CVE-2024-27199）。其中，CVE-2024-27198（CVSS 9.8）允许未经身份验证的攻击者直接获取最高管理权限并实现远程代码执行（RCE）。\u003c/p\u003e\n\u003cp\u003e我关注这个漏洞，不只是因为它严重，更因为它的根因很有代表性——不是某个鉴权函数\u0026quot;写错了\u0026quot;，而是\u003cstrong\u003e请求在多个处理层之间被不同组件\u0026quot;重新理解\u0026quot;\u003c/strong\u003e，导致鉴权边界和执行边界发生了错位。这种问题单看代码很难发现，常规扫描器也抓不住，但它有一套可以复用的发现方法论。\u003c/p\u003e\n\u003cp\u003e本文的核心目标就是还原这套方法论：在不依赖公开利用样例、不先验知道答案的前提下，从零开始走一遍\u0026quot;发现\u0026quot;的过程。\u003c/p\u003e\n\u003ch2 id=\"2-漏洞成因分析\"\u003e2. 漏洞成因分析\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e本节内容依据 Rapid7 官方报告 analysis 部分进行翻译与整理，重点还原\u0026quot;代码层为什么会绕过\u0026quot;，而非仅描述复现步骤。\u003c/p\u003e","title":"TeamCity CVE-2024-27198 认证绕过漏洞 — 0day 视角的发现与复现方法"},{"content":"从 TeamCity 到语义漂移 — CI/CD 平台的认证绕过模式与披露伦理 免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。\n系列说明：本文是该系列的第二篇，讨论漏洞的利用影响、披露争议，以及将 CVE-2024-27198 放入更广阔的\u0026quot;语义漂移\u0026quot;模式中进行横向比较。技术层面的代码分析、实验环境和发现方法论见第一篇：[[teamcity-cve-2024-27198-discovery]]。\n目录 引言：跳出单个漏洞 漏洞可利用性与在野利用 漏洞披露与社区争议 语义漂移：同类漏洞的横向比较 五条件审计清单 结论 参考与来源 1. 引言：跳出单个漏洞 第一篇还原了 CVE-2024-27198 的发现过程——从不带答案的基线建模，到语义变异、灰盒收敛，再到定向验证。\n但如果只把它看成一个孤立事件，就错过了它背后更值得关注的东西。做完这篇分析后我横向翻了翻过去几年类似的认证绕过漏洞，发现它们不是散点，而是同一根因的反复出现：请求在流经多个路径解析器时，语义发生了漂移，而鉴权决定发生在漂移之前。\n这篇文章想做的事就是把这条线拉通。先还原漏洞造成的真实影响和披露过程中的争议，再用几个同行案例说明这个模式有多常见，最后给一个可以在审计时直接用的检查清单。\n2. 漏洞可利用性与在野利用 2.1 影响能力边界 结合 Rapid7 在 2024-03-04 披露中给出的公开利用样例，漏洞的实际危害可以拆成一条更具体的能力链：\n图2-1 从未认证访问到供应链外溢的能力升级路径。\n未认证调用管理 REST 接口（跨越登录边界） 攻击者可构造类似 /does-not-exist?jsp=/app/rest/...;.jsp 的请求，把本应受保护的 REST 端点暴露给未登录请求。 这一步代表的是直接获得对管理 API 的未认证调用能力。\n直接创建管理员账号（权限立刻提升到 SYSTEM_ADMIN） Rapid7 的公开示例显示，攻击者可向 /app/rest/users 发起创建用户请求，并在请求体中赋予 SYSTEM_ADMIN 角色。 返回结果中的用户对象会包含管理员角色字段，这意味着攻击者无需先拿低权限账号，起手就是全局管理员。\n生成管理员访问令牌（持久化控制） 除了创建管理员用户，攻击者还可针对用户 token 接口（如 /app/rest/users/id:1/tokens/...）生成管理员 token。 一旦 token 生成成功，即使后续密码策略变更，攻击者仍可能通过 API 持续访问，形成较强持久化。\n接管 TeamCity 控制面（项目/构建/制品/代理） 在管理员权限下，影响范围不是单一页面，而是整个 TeamCity 控制面：\n项目与构建配置修改 构建任务与构建步骤变更 构建代理与制品链路控制 凭据、连接配置与自动化流程滥用 供应链外溢风险（从 CI/CD 平台扩展到下游） TeamCity 是 CI/CD 中枢，一旦被管理员级接管，风险会外溢到制品发布、部署流程和下游环境，因此该漏洞的危害不止\u0026quot;单机被控\u0026quot;，而是可能演化为供应链级事件。\n2.2 利用复杂度评估 前置门槛：仅需网络可达目标 TeamCity 服务，无需登录认证等权限。 交互要求：无需受害者额外交互。 利用稳定性：在满足语义条件时，利用链可重复触发。 对应 CVSS 9.8（Critical）的根本原因在于：攻击路径短、权限前置低、影响面高。 其典型向量可表述为：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，即网络可达、低复杂度、无前置权限、无用户交互且三性高影响。\n2.3 在野利用与真实影响 从公开情报看，CVE-2024-27198 并非只是\u0026quot;理论可利用\u0026quot;，而是在披露后快速进入规模化利用阶段，体现出其低门槛与高收益特征。\n美国 CISA 将其纳入 KEV（Known Exploited Vulnerabilities）目录，并标注\u0026quot;已用于勒索软件\u0026quot;：CISA 的 KEV 条目显示该漏洞 Known To Be Used in Ransomware Campaigns: Known，并要求在规定日期前完成处置（联邦机构截止 2024-03-28）。这类信号通常意味着漏洞已进入实战攻击链条且应急优先级很高。\n厂商一手\u0026quot;受害者报告\u0026quot;：JetBrains 在后续官方文章中表示，在 Rapid7 发布完整技术细节与公开 exploit 示例之后，他们开始收到客户反馈服务器被入侵，并列举了多起代表性案例（包括勒索加密、异常管理员账号创建等）。\n披露后数小时至数天内出现规模化扫描与入侵迹象（第三方观测汇总）：\nShadowserver：最早在 2024-03-04 22:00 UTC 观测到利用尝试；2024-03-05 观测到约 16 个 IP 扫描互联网寻找易受攻击实例（媒体汇总口径）。 GreyNoise：追踪到针对该漏洞的利用尝试，观测到数十个恶意 IP 参与活动（媒体引用口径）。 LeakIX：在 2024-03-06 前后报告\u0026quot;clear signs of rogue user creation（明显的异常用户创建迹象）\u0026quot;；并在 2024-03-07 的媒体报道中被引用为 1,442 个实例存在此类迹象；同一报道还提到其观测到约 1,711 个仍处于易受攻击状态的实例。 安全厂商遥测观测到后渗透载荷投放：Trend Micro 报告称，其遥测观测到攻击者利用 TeamCity 漏洞链在受害服务器上投放多种后渗透载荷，包括勒索软件（Jasmin）、挖矿（XMRig）、Cobalt Strike beacon、SparkRAT 等，并给出了示例网络流量与进程树证据。该类后渗透活动符合\u0026quot;先接管 CI/CD 中枢，再横向与变现\u0026quot;的现实攻击路径。\n基于上述情报，可以确认，这个漏洞并不是\u0026quot;理论上很危险\u0026quot;，而是\u0026quot;已经被快速武器化并在野利用\u0026quot;的高危漏洞。\n3. 漏洞披露与社区争议 该漏洞除了技术层面的典型性外，披露过程本身也很有代表性：它把\u0026quot;公开透明\u0026quot;与\u0026quot;防守窗口\u0026quot;之间的矛盾放到了台面上。\n图3-1 从漏洞报告、修复发布到在野利用确认的披露时间线与争议焦点。\n3.1 更完整的披露时间线 结合 JetBrains 与 Rapid7 双方公开信息，可以把链条补得更完整一些（JetBrains 时间线为 CET）：\n2024-02-19：Rapid7 首次联系 JetBrains，报告 TeamCity 严重安全问题。 2024-02-20：Rapid7 提交详细技术报告；JetBrains 当天复现确认。 2024-02-21 ~ 2024-02-23：双方围绕披露策略出现明显分歧。JetBrains 倾向\u0026quot;先发布修复与补丁、邮件通知客户、提供高层次风险说明，再延后完整技术细节\u0026quot;；Rapid7 则坚持修复一旦公开可得，就应尽快同步完整技术披露。 2024-03-01：双方继续就 CVE 标识、版本影响范围与披露节奏沟通。 2024-03-04 15:00：JetBrains 发布 2023.11.4（含修复）及安全补丁插件。 2024-03-04 15:05：JetBrains 向 TeamCity On-Premises 客户和安全订阅用户发送告警邮件。 2024-03-04 15:59：JetBrains 发布单独安全公告，公开 CVE-2024-27198 / CVE-2024-27199、受影响范围、严重性与缓解方案，但未公开完整 root cause、利用链与复现/利用细节。 2024-03-04 19:07：JetBrains 将这两个问题加入其公开安全问题页面，并使对应 CVE 记录对外可见。 2024-03-04 20:23：Rapid7 发布完整技术披露文章与利用细节。 2024-03-07：CISA 将 CVE-2024-27198 纳入 KEV，确认已进入在野利用态势。 需要特别区分的是，15:59 的动作是\u0026quot;安全公告发布\u0026quot;，而不是\u0026quot;完整技术披露\u0026quot;；19:07 则更接近\u0026quot;CVE 记录/安全问题页面正式公开\u0026quot;。Rapid7 文中还特别说明，JetBrains 的版本发布日志在不同时区可能显示为 3 月 3 日或 3 月 4 日，这也让\u0026quot;修复版到底何时已公开可得\u0026quot;在传播层面更容易引发争议。\n3.2 从披露到在野利用的加速链条 从 SecurityWeek（引用 Shadowserver、GreyNoise、LeakIX）和 CISA 信号看，利用出现速度很快：\n2024-03-04：漏洞细节公开当天即出现利用尝试。 2024-03-05：Shadowserver 观测到互联网扫描与探测活动上升；GreyNoise 也开始看到多源攻击尝试。 2024-03-06：LeakIX 报告出现大规模异常账户创建迹象。 2024-03-07：CISA 将其加入 KEV，风险等级进一步被官方\u0026quot;在野利用\u0026quot;标签确认。 这条链路的意义在于：争议不是停留在理念层，而是直接映射为防守方在最初 24~72 小时内的实战压力。\n3.3 争议焦点：不是\u0026quot;有没有公告\u0026quot;，而是\u0026quot;公开粒度与时机\u0026quot; 如果只看表面，会出现一个疑问：JetBrains 既然在 2024-03-04 15:59 已经发布了安全公告，Rapid7 为什么仍然会把这一路径描述为接近其所反对的 \u0026ldquo;silent patching\u0026rdquo;？关键原因在于，双方对\u0026quot;公开\u0026quot;一词的含义并不相同。\n对 Rapid7 而言，问题不在于厂商是否\u0026quot;完全沉默\u0026quot;，而在于：\n修复是否先于充分披露对外可见：一旦修复版已发布，具备逆向能力的攻击者就可能通过补丁比对快速理解漏洞；如果厂商此时只给高层次风险说明、而不及时公开足够的技术细节，信息优势会先落到高水平攻击者手里。 防守方是否获得了足够可操作的信息：从 Rapid7 的视角看，仅有\u0026quot;存在认证绕过风险、请立即升级\u0026quot;这类摘要，并不等于防守者已经拿到与攻击者近似对等的理解能力，因此这种\u0026quot;先修复、后细节\u0026quot;的模式会被归入其反对的 silent patching 范畴。 对 JetBrains 而言，安全公告、CVE 编号、影响范围和缓解措施已经足以构成\u0026quot;负责任通知\u0026quot;；真正不应在修复刚上线时同步公开的，是完整 root cause、利用条件与 exploit 细节。因为一旦这些内容在补丁发布同时出现，会显著降低利用门槛，使尚未完成升级的客户暴露在更高风险窗口中。\n因此，双方真正冲突的不是\u0026quot;该不该公开\u0026quot;，而是：\nRapid7 侧重点：反对\u0026quot;补丁先行、细节后置\u0026quot;，认为这会让 skilled attacker 比普通防守者更早获益。 JetBrains 侧重点：反对\u0026quot;修复与完整利用细节同步公开\u0026quot;，认为这会把窗口期内的攻击门槛压得过低。 换句话说，Rapid7 所说的 \u0026ldquo;silent patching\u0026rdquo; 在这里并不是指 \u0026ldquo;JetBrains 完全没有发公告\u0026rdquo;，而是指其反对\u0026quot;先发布修复和高层次公告，再延后完整技术披露\u0026quot;的披露模式；而 JetBrains 则认为，这种延迟 full disclosure 的做法恰恰是为了给客户争取升级与打补丁的缓冲时间。\n3.4 本文观点 我个人观点会更偏\u0026quot;分层披露\u0026quot;。说直白一点：Rapid7 反对静默修补并没有错，但这次节奏确实偏激进。 TeamCity 这种全球广泛部署的 CI/CD 枢纽软件，企业侧真实响应要走\u0026quot;感知风险 -\u0026gt; 评估影响 -\u0026gt; 变更审批 -\u0026gt; 生产上线\u0026quot;这整套流程；很多组织在跨时区场景下，补丁发布后最初几小时甚至还没进入有效响应状态。\n所以问题不在\u0026quot;该不该公开\u0026quot;，而在\u0026quot;什么时候公开到什么粒度\u0026quot;。更现实的路径是：\n先同步高价值防守信息（受影响范围、风险等级、可执行缓解措施、检测线索）； 给一个可落地的升级窗口； 再发布完整技术细节。 这种\u0026quot;分层+分时\u0026quot;策略，通常更有机会同时兼顾透明性与防守可操作性。\n4. 语义漂移：同类漏洞的横向比较 作者注：本节内容不在原始分析草稿中，是在做完 TeamCity 复现后，横向翻阅过去几年类似漏洞时做的归纳。没有现成理论框架可以参考，属于个人观察总结。\n如果把 TeamCity CVE-2024-27198 只看成一个孤立事件，就错过了它背后反复出现的一个模式。做完这篇分析后，我横向翻了翻近几年的认证绕过漏洞，发现它们共享同一套根因结构。\n4.1 Shiro + Spring：同一出戏，年年返场 Apache Shiro 和 Spring MVC 的组合，可能是这个模式里最高产的一对。从 2020 年开始，几乎每年都有新变种被报出来：\nCVE-2020-13933：%3b（URL 编码的分号）→ Shiro 解码后认为 ; 是路径参数分隔符，匹配不到受限规则 → 请求 pass 给 Spring，Spring 把 %3b 当普通字符 → 命中受限 Controller CVE-2020-17523：// 双斜杠 → Shiro 和 Spring 的 normalize 结果不同 CVE-2020-1957：..; 语义差异 CVE-2022-40664：又是 %3b，前一年修完第二年又出新绕过 核心剧情不在于\u0026quot;Shiro 写错了\u0026quot;或\u0026quot;Spring 写错了\u0026quot;——它们各自单看都是按设计干活。问题出在两个组件的路径语言是两种不同的方言：Shiro 对\u0026quot;什么是路径、什么是参数、什么是分隔符\u0026quot;有一套理解，Spring 有另一套。只要两个组件还在各说各话，组合绕过就不会停。修一次往往只堵了一个具体绕过形式而非根因。\n和 TeamCity 的类比一目了然：TeamCity 是鉴权层 vs 视图路由层在同一进程内的漂移，Shiro+Spring 是安全框架 vs 业务框架的跨组件漂移。根因结构一样。\n4.2 代理层的语义漂移 不光 Java 生态，反向代理和应用服务器之间的路径解析差异也是重灾区：\nEnvoy Proxy OAuth2 Filter 绕过（CVE-2023-27496）：Envoy 的 OAuth2 filter 对路径有自己的 normalize 逻辑。当请求为 /public/../admin/secret-api 时，OAuth2 filter 按 /public/... 匹配 → 不触发鉴权放行 → upstream backend 再做一次 normalize → 命中 /admin/secret-api。又是同样的结构：鉴权发生在前一层，执行发生在后一层，中间路径被重新理解了。\nNginx + 后端规范化不一致：Nginx 的 merge_slashes 和 normalize 行为，跟 Tomcat、uWSGI、Gunicorn 等后端的路径解析各有差异。这类组合没有统一 CVE 编号（因为是跨产品组合问题而非单一产品漏洞），但在实战中非常常见。核心矛盾很简单：反向代理的路径策略是运维配置的，后端的路径解析是开发框架定的——运维和开发很可能互相不知道对方的\u0026quot;理解\u0026quot;。\nF5 BIG-IP Auth Bypass（CVE-2023-46747）：机制上是 HTTP 请求走私，但根因结构如出一辙——前端对 HTTP 请求的解析结果和后端对同一份请求的解析结果不同，鉴权在前端语义里做，执行在后端语义里做。不是同一类攻击手法，但属于同一个漏洞产生模式。\n4.3 共同结构 这些案例横向拉通之后，有一个共同的产生条件，五个条件全部满足 → 极大概率存在可利用的认证绕过：\n请求流经两个或以上的独立路径解析器 各解析器对同一输入产生不同的输出 鉴权决定基于较早的解析器的输出 最终路由/执行基于较晚的解析器的输出 解析差异可以通过请求构造被稳定控制 这不是某一个产品的 bug，而是现代 Web 架构的一种\u0026quot;默认风险\u0026quot;——只要请求链路里躺着两个以上的路径解析器，且没有统一的 canonical form 约束，语义漂移就是必然的。区别只在漂移窗口的大小和被利用的难易程度。\n5. 五条件审计清单 把上面五个条件翻译成审计时可以逐条核对的 checklist：\n# 检查项 怎么确认 风险信号 1 请求链路中是否存在 ≥2 个路径解析环节？ 画出请求从入口到最终 handler 的全链路，标出每个\u0026quot;看路径做决定\u0026quot;的节点 链路中存在容器级路由、框架级路由、反向代理、WAF 等任意两个以上独立解析器 2 这些环节对同一输入是否可能给出不同结果？ 对每个解析环节单独测试：给它同样的输入，看它输出的\u0026quot;有效路径\u0026quot;是什么 两个环节对 //、;、%2f、..、\\ 等字符的处理策略不同 3 鉴权决定发生在哪个环节？ 确认鉴权过滤器/中间件在链路中的位置，它用的是哪个环节的路径理解 鉴权在环节 N，但环节 N+1 对路径的理解不同 4 最终 handler 路由发生在哪个环节？ 确认最终 Controller/Handler 的映射逻辑用的是哪层解析结果 最终路由使用与鉴权不同的解析结果 5 差异是否可被攻击者稳定构造？ 尝试构造特定请求，使其在鉴权层看来是 A、在执行层看来是 B 能够稳定复现\u0026quot;鉴权放行 + 执行命中受保护端点\u0026quot;的组合 如果用这套清单去反查 TeamCity 漏洞：1（鉴权链 + 视图路由 + 路径规范化）→ 2（分号语义差异）→ 3（鉴权在前）→ 4（路由在规范化之后）→ 5（可通过 .jsp 后缀 + jsp 参数 + ; 分号稳定构造），全部打勾。\n这套清单当然不是什么严谨的理论——没有经过大规模统计验证，也没有同行评议。它只是一个基于有限案例的观察归纳。作用不是当定理用，而是下次审计任意 Web 系统时，给你一个可以逐条对照的思考框架，尤其在常规漏洞扫描器扫不出东西的时候。\n6. 结论 CVE-2024-27198 的典型性，不仅在于\u0026quot;未认证可达\u0026quot;，更在于它揭示了现代 Web 系统里一个经常被低估的问题：安全边界不是由某个单点鉴权函数决定的，而是由整条请求处理链的一致性决定的。\n从本文复现与分析过程看，这个漏洞并非传统意义上的\u0026quot;显式越权接口\u0026quot;，而是由三层因素叠加形成的语义错位：\n路径外观（.jsp）改变了请求进入的处理链； 控制器允许请求参数参与视图目标改写； 路径规范化（尤其分号语义）在不同阶段存在解释差异。 这三者叠加后，系统出现了\u0026quot;鉴权看到一种请求，执行命中另一种请求\u0026quot;的结构性问题。 也正因为如此，这类漏洞的修复重点不应停留在\u0026quot;补一个黑名单规则\u0026quot;，而应转向更稳定的工程策略：在统一的 canonical form 上完成鉴权、路由、视图解析与审计，并把跨阶段语义一致性作为安全设计约束。\n6.1 一次分析之后的几个感受 写完这两篇文章，心里有几个很具体的感受。\n第一，知道答案和重走发现路径，完全是两回事。 读 Rapid7 报告的时候觉得\u0026quot;哦，就是路径解析不一致嘛\u0026quot;。但从零基线开始撞的时候——每一步都不知道下一步往哪走。阶段 B 看到 /does-not-exist.jsp 返回 401 而不是 404 时，我的第一反应是\u0026quot;这有啥？不就是后缀影响了错误处理吗\u0026quot;。直到灰盒阶段看到 jsp 参数直接参与 setViewName()，才意识到这不是小差异。大部分漏洞复现文章只展示最后那条成功的路，不展示中间绕过的弯——但那些弯才是最有信息量的部分。\n第二，这个模式比我预想的更普遍。 一开始我只是想深入分析 TeamCity 这一个漏洞。写完第一篇之后不甘心，横着翻了翻 Shiro、Envoy、Nginx 相关的审计资料，发现根因结构高度相似。五个条件对齐之后，这个漏洞不再是\u0026quot;TeamCity 的问题\u0026quot;，而是\u0026quot;多解析器架构的问题\u0026quot;。对我自己的启发是：以后审计任何系统，画出路径解析全景图应该是第一步，而不是最后一步。\n第三，CI/CD 平台的风险被低估了。 CI/CD 一旦被绕过认证进入管理面，影响对象就不是单台服务，而是项目配置、构建链路、制品分发与下游部署流程。这也是该漏洞被评为 Critical 并在披露后迅速武器化的根本原因。做防御的人不能把 CI/CD 当成\u0026quot;又一个内部系统\u0026quot;来对待——它的风险放大效应是普通应用服务器的好几倍。\n6.2 给防守方的实操建议 如果只想带走一句话：下次审计一个 Web 系统，在跑扫描器之前，先把请求链路里每一个\u0026quot;看路径做决定\u0026quot;的节点标出来，问自己：它们看到的是同一个路径吗？ 不一致的地方，就是下一步该深挖的地方。\n本系列第一篇（技术复现与发现方法论）：[[teamcity-cve-2024-27198-discovery]]\n7. 参考与来源 TeamCity 漏洞相关 Rapid7 原始漏洞披露声明: CVE-2024-27198 and CVE-2024-27199: JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities (FIXED) JetBrains 官方安全通报: Additional Critical Security Issues Affecting TeamCity On-Premises (CVE-2024-27198 and CVE-2024-27199) – Update to 2023.11.4 Now JetBrains 官方回应争议的专门文章: Preventing Exploits: JetBrains\u0026rsquo; Ethical Approach to Vulnerability Disclosure JetBrains 披露时间线总结: Insights and Timeline: Our Approach to Addressing the Recently Discovered Vulnerabilities in TeamCity On-Premises 在野利用证据（政府与安全厂商）: CISA Adds One Known Exploited JetBrains Vulnerability, CVE-2024-27198, to Catalog CISA Known Exploited Vulnerabilities Catalog（CVE-2024-27198 条目） Trend Micro: TeamCity Vulnerability Exploits Lead to Jasmin Ransomware, Other Malware Types SecurityWeek: Critical TeamCity Vulnerability Exploitation Started Immediately After Disclosure SC Media/SCWorld: JetBrains TeamCity critical flaw exploited; 1.4k servers compromised 语义漂移同类案例 Apache Shiro + Spring 认证绕过系列: CVE-2020-13933 / CVE-2020-17523 / CVE-2020-1957 / CVE-2022-40664 — 多个独立研究者和厂商 advisory 中有详细技术分析，建议以 NVD 条目和对应的 Apache Shiro 安全公告为入口 Envoy Proxy OAuth2 Filter 绕过: CVE-2023-27496 — Envoy Security Advisory F5 BIG-IP Auth Bypass: CVE-2023-46747 — F5 Security Advisory ","permalink":"https://aries441.tech/posts/vuln-reproduction/teamcity-cve-2024-27198-impact/","summary":"\u003ch1 id=\"从-teamcity-到语义漂移--cicd-平台的认证绕过模式与披露伦理\"\u003e从 TeamCity 到语义漂移 — CI/CD 平台的认证绕过模式与披露伦理\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003e免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e系列说明\u003c/strong\u003e：本文是该系列的第二篇，讨论漏洞的利用影响、披露争议，以及将 CVE-2024-27198 放入更广阔的\u0026quot;语义漂移\u0026quot;模式中进行横向比较。技术层面的代码分析、实验环境和发现方法论见第一篇：[[teamcity-cve-2024-27198-discovery]]。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"目录\"\u003e目录\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e引言：跳出单个漏洞\u003c/li\u003e\n\u003cli\u003e漏洞可利用性与在野利用\u003c/li\u003e\n\u003cli\u003e漏洞披露与社区争议\u003c/li\u003e\n\u003cli\u003e语义漂移：同类漏洞的横向比较\u003c/li\u003e\n\u003cli\u003e五条件审计清单\u003c/li\u003e\n\u003cli\u003e结论\u003c/li\u003e\n\u003cli\u003e参考与来源\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"1-引言跳出单个漏洞\"\u003e1. 引言：跳出单个漏洞\u003c/h2\u003e\n\u003cp\u003e第一篇还原了 CVE-2024-27198 的发现过程——从不带答案的基线建模，到语义变异、灰盒收敛，再到定向验证。\u003c/p\u003e\n\u003cp\u003e但如果只把它看成一个孤立事件，就错过了它背后更值得关注的东西。做完这篇分析后我横向翻了翻过去几年类似的认证绕过漏洞，发现它们不是散点，而是同一根因的反复出现：\u003cstrong\u003e请求在流经多个路径解析器时，语义发生了漂移，而鉴权决定发生在漂移之前。\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e这篇文章想做的事就是把这条线拉通。先还原漏洞造成的真实影响和披露过程中的争议，再用几个同行案例说明这个模式有多常见，最后给一个可以在审计时直接用的检查清单。\u003c/p\u003e\n\u003ch2 id=\"2-漏洞可利用性与在野利用\"\u003e2. 漏洞可利用性与在野利用\u003c/h2\u003e\n\u003ch3 id=\"21-影响能力边界\"\u003e2.1 影响能力边界\u003c/h3\u003e\n\u003cp\u003e结合 Rapid7 在 2024-03-04 披露中给出的公开利用样例，漏洞的实际危害可以拆成一条更具体的能力链：\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"漏洞利用能力链\" loading=\"lazy\" src=\"/images/teamcity-cve-2024-27198/%E5%88%A9%E7%94%A8%E8%83%BD%E5%8A%9B%E9%93%BE.png\"\u003e\n\u003cem\u003e图2-1  从未认证访问到供应链外溢的能力升级路径。\u003c/em\u003e\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e未认证调用管理 REST 接口（跨越登录边界）\u003c/strong\u003e\n攻击者可构造类似 \u003ccode\u003e/does-not-exist?jsp=/app/rest/...;.jsp\u003c/code\u003e 的请求，把本应受保护的 REST 端点暴露给未登录请求。\n这一步代表的是\u003cstrong\u003e直接获得对管理 API 的未认证调用能力\u003c/strong\u003e。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e直接创建管理员账号（权限立刻提升到 SYSTEM_ADMIN）\u003c/strong\u003e\nRapid7 的公开示例显示，攻击者可向 \u003ccode\u003e/app/rest/users\u003c/code\u003e 发起创建用户请求，并在请求体中赋予 \u003ccode\u003eSYSTEM_ADMIN\u003c/code\u003e 角色。\n返回结果中的用户对象会包含管理员角色字段，这意味着攻击者无需先拿低权限账号，起手就是全局管理员。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e生成管理员访问令牌（持久化控制）\u003c/strong\u003e\n除了创建管理员用户，攻击者还可针对用户 token 接口（如 \u003ccode\u003e/app/rest/users/id:1/tokens/...\u003c/code\u003e）生成管理员 token。\n一旦 token 生成成功，即使后续密码策略变更，攻击者仍可能通过 API 持续访问，形成较强持久化。\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003e接管 TeamCity 控制面（项目/构建/制品/代理）\u003c/strong\u003e\n在管理员权限下，影响范围不是单一页面，而是整个 TeamCity 控制面：\u003c/p\u003e","title":"从 TeamCity 到语义漂移 — CI/CD 平台的认证绕过模式与披露伦理"},{"content":"TeamCity认证绕过漏洞（CVE-2024-27198）复现报告与分析 免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。\n漏洞编号 CVE-2024-27198 CWE分类 CWE-288（备用路径导致认证绕过） 发现时间 2024年2月（由 Rapid7 的 Stephen Fewer 发现） CVSS评分 9.8 (Critical / 严重) 受影响版本 JetBrains TeamCity On-Premises \u0026lt;= 2023.11.3 修复版本 JetBrains TeamCity 2023.11.4 危害描述 未经身份验证的攻击者可通过特定的URL路径绕过认证机制，获取管理员权限并接管TeamCity服务器，进而可能导致供应链投毒攻击。 目录 引言与漏洞背景 漏洞成因分析 漏洞触发环境与复现条件 漏洞发现方法与过程（0day视角） 漏洞可利用性分析 防御机制与突破点分析 修复与缓解建议 漏洞披露与社区争议 结论 参考与来源 1. 引言与漏洞背景 TeamCity 是 JetBrains 开发的一款广泛使用的 CI/CD（持续集成与持续交付）服务器，在企业软件开发生命周期中占据核心地位。由于其掌控着代码构建与部署权限，一旦被攻陷，极易引发大范围的软件供应链攻击。\n2024年2月，Rapid7 漏洞研究团队在 TeamCity 的 Web 组件中发现了两个严重的认证绕过漏洞（CVE-2024-27198 与 CVE-2024-27199）。其中，CVE-2024-27198（CVSS 9.8）由于允许未经身份验证的攻击者直接获取最高管理权限并实现远程代码执行（RCE），危害尤为严重。\n值得注意的是，该漏洞在3月初的披露过程并非一帆风顺。由于发现方（Rapid7）与厂商（JetBrains）在“协调披露”与“静默修补”理念上产生严重分歧，Rapid7 在补丁发布当日即公开了详细技术报告。这一事件不仅导致随后几天内爆发了针对该漏洞的大规模在野利用（如勒索软件和挖矿木马），更在安全社区引发了一场关于“漏洞披露伦理”的广泛争论（详见文末讨论）。\n2. 漏洞成因分析 本节内容依据 Rapid7 官方报告 analysis 部分进行翻译与整理，重点还原“代码层为什么会绕过”，而非仅描述复现步骤。\n该漏洞本质属于 CWE-288（Authentication Bypass Using an Alternate Path）：请求在不同处理层被解释为不同语义，导致鉴权边界与执行边界错位。\n图2-1 鉴权层与执行层对同一请求语义解释不一致，是本漏洞的核心机制。\nRapid7 在报告中指出，关键问题位于 web-openapi.jar 内的 jetbrains.buildServer.controllers.BaseController。在 handleRequestInternal() 中，当请求未触发重定向时，会进入 updateViewIfRequestHasJspParameter() 逻辑；该逻辑会读取请求中的 jsp 参数并尝试覆盖 ModelAndView 的视图目标。\n结合该控制流可得到漏洞成立的三个条件（Rapid7 原文同样给出了示例语义）：\n入口必须是未认证可达且可进入后续处理链的路径\n例如一个不存在路径触发 404 处理流。这里的目的不是访问该路径本身，而是让请求进入 BaseController 的后续逻辑。\n请求中携带可影响目标视图/路由的参数\njsp 参数值被设置为受保护的 REST 路径后，会影响 ModelAndView 的最终视图解析目标。\n请求路径语义被伪装为 JSP 相关形式\n在路径中引入分号参数与 .jsp 后缀语义后，不同层（容器、鉴权、控制器）对 URI 的解释出现分歧：上层可能把它当成可放行的 JSP 视图请求，而后续路由阶段可能将其规范化/截断后命中真实受保护 API。\n因此，这不是“单点逻辑缺陷”，而是一个多层解析不一致问题：\n鉴权层看到的是“看似无害的视图请求”，执行层命中的是“受保护 REST 端点”。一旦错位成立，未认证请求即可跨越访问控制边界，进一步触发管理员级操作链路，最终导致服务器完全失陷风险。\n3. 漏洞触发环境与复现条件 3.1 复现实验环境 操作系统：Windows 11（宿主机） 容器环境：Docker Desktop 目标版本：jetbrains/teamcity-server:2023.11.3（漏洞版） 对照版本：jetbrains/teamcity-server:2023.11.4（修复版） 3.2 触发前提条件 漏洞触发并非“单一 URL 命中”，而是需要满足一组语义条件：\n请求首先进入一个未认证可达的处理流（常见是错误路径处理流）。 请求参数中存在可影响视图/路由目标的输入（如 jsp 参数语义）。 请求路径外观被构造成 JSP 相关语义（例如路径后缀和分号参数语义），使不同处理层产生解析分歧。 这三个条件叠加后，可能出现“上层鉴权判断通过，但下层路由命中受保护 API”的错位。\n3.3 复现实验判定标准 本报告采用“对照验证”而非单点命中验证：\n同一类输入在漏洞版（2023.11.3）出现未授权异常可达行为； 同一输入在修复版（2023.11.4）被拒绝或回到正常鉴权行为； 结合代码层分析，能够解释该差异与路径语义解析不一致有关。 4. 漏洞发现方法与过程 本节仅按 0day 视角还原“当时如何发现”：\n从未授权基线出发，经通用语义变异发现异常，再通过旧版反编译做灰盒收敛，最后用第二轮定向样本完成复证闭环。\n图4-1 0day视角发现路径：基线建模 -\u0026gt; 语义变异 -\u0026gt; 灰盒收敛 -\u0026gt; 定向验证。\n4.1 方法论与研究约束 为了避免“先知道答案再倒推”，本次实验设定了四个约束：\n第一轮黑盒不直接使用公开利用样例，也不先假设参数名。 先建立未授权访问基线，再做通用语义变异。 只有当异常稳定出现后，才进入反编译灰盒收敛。 后续公开资料仅用于结果对照，不作为前置发现线索。 对应的分析链路是：\n基线建模 -\u0026gt; 第一轮通用变异 -\u0026gt; 灰盒收敛 -\u0026gt; 第二轮定向验证。\n4.2 阶段A：未授权基线建模（0day 起点） 先回答一个最基础的问题：目标在未登录状态下“正常应该返回什么”？\n我们对根路径、登录页面、REST 接口和错误路径做了基线测量，得到三类稳定外观：\n受保护入口（如 /overview.html、/app/rest/server）：以 401 text/plain 为主。 登录相关页面（如 /login.html）：200 text/html。 错误路径（如 /does-not-exist）：404 text/html。 这一步的价值是建立“异常参照系”。后续若错误路径不再 404，或未授权请求出现受保护 API 语义，就属于高优先级异常。\n4.3 阶段B：第一轮通用语义变异（不押答案） 第一轮只测试通用 Web 路径语义，不带特定可疑参数。典型样本包括：\n/does-not-exist /does-not-exist/ /does-not-exist// /does-not-exist;x /does-not-exist.jsp /does-not-exist/.jsp 关键观察是：\n/does-not-exist 返回 404 text/html。 /does-not-exist.jsp 与 /does-not-exist/.jsp 返回 401 text/plain。 这说明单纯 .jsp 外观就能改变处理流：请求从“错误页处理链”偏向“认证相关处理链”。\n此时还不知道 jsp 参数，但已经能确定灰盒分析应优先关注 .jsp、视图解析、控制器参数读取。\n4.4 阶段C：旧版反编译灰盒收敛 本阶段并非先验锁定 web-openapi.jar，而是先在 WEB-INF/lib 的 web-* 模块（web-core.jar、web-openapi.jar、web-startup.jar、web-diagnostic.jar）中做并行筛查。筛查关键词来自阶段B暴露出的行为特征，即 .jsp、ModelAndView、setViewName、getParameter。\n检索结果显示，相关控制器线索主要集中在 jetbrains/buildServer/controllers/BaseController.java，且命中位于 web-openapi 反编译结果中；同样检索在 web-core 中未出现对应控制器命中。由此，分析重点自然收敛到 web-openapi.jar。\n在 2023.11.3 旧版 web-openapi.jar 中继续反编译和阅读，可定位到 BaseController 的核心逻辑：\nprivate void updateViewIfRequestHasJspParameter(HttpServletRequest request, ModelAndView modelAndView) { boolean isControllerRequestWithViewName = modelAndView.getViewName() != null \u0026amp;\u0026amp; !request.getServletPath().endsWith(\u0026#34;.jsp\u0026#34;); String jspFromRequest = this.getJspFromRequest(request); if (isControllerRequestWithViewName \u0026amp;\u0026amp; jspFromRequest != null \u0026amp;\u0026amp; !jspFromRequest.equals(modelAndView.getViewName())) { modelAndView.setViewName(jspFromRequest); } } protected String getJspFromRequest(HttpServletRequest request) { String jspFromRequest = request.getParameter(\u0026#34;jsp\u0026#34;); if (jspFromRequest != null \u0026amp;\u0026amp; (!jspFromRequest.endsWith(\u0026#34;.jsp\u0026#34;) || jspFromRequest.contains(\u0026#34;admin/\u0026#34;))) { jspFromRequest = null; } return jspFromRequest; } 同时在路径处理辅助逻辑中可见：\npublic static String removeSessionId(String uri) { int semicolon = uri.indexOf(\u0026#34;;\u0026#34;); return semicolon != -1 ? uri.substring(0, semicolon) : uri; } 图4-2 BaseController 参数读取/视图改写与 WebUtil 分号截断的关键代码逻辑标注。\n灰盒阶段的关键信息有三点：\njsp 参数是从代码中发现的，不是先验猜测。 参数在满足约束后会参与 viewName 改写，具有控制流影响能力。 ; 语义处理支持“请求在不同阶段被不同解释”的机制假设。 4.5 阶段D：第二轮定向验证（灰盒驱动） 基于阶段C线索，设计“命中组 + 对照组”并实测：\n样本 漏洞版（2023.11.3） 解释 /does-not-exist?jsp=/app/rest/server;.jsp 200 application/xml 命中 /does-not-exist?jsp=/app/rest/users;.jsp 200 application/xml 命中 /does-not-exist?jsp=/app/rest/server 404 text/html 不满足 .jsp 约束 /does-not-exist?jsp=/app/rest/server;.jspx 404 text/html 不满足 endsWith(\u0026quot;.jsp\u0026quot;) /does-not-exist?jsp=/admin/admin.html;.jsp 404 text/html 命中 admin/ 限制 /does-not-exist/.jsp?jsp=/app/rest/server;.jsp 401 text/plain 与 servletPath.endsWith(\u0026quot;.jsp\u0026quot;) 分支相关 图4-3 命中组与对照组稳定分离，支持“异常可重复、样本可分离”的发现结论。\n命中样本响应体会出现受保护 REST 语义（如 server / users XML），而不是普通 404 页面。\n这一步完成了“黑盒异常 -\u0026gt; 代码机制 -\u0026gt; 黑盒复证”的闭环。\n4.6 阶段E：0day视角收尾与转入影响评估 在不依赖修复版对照、也不直接套用公开利用样例的前提下，至阶段D已经可以形成“高置信候选漏洞”的发现结论。依据主要有三点：\n异常可重复：错误路径在特定语义组合下可稳定偏移到受保护 REST 响应语义。 机制可解释：旧版代码中存在与异常现象一致的参数读取与视图改写链路。 样本可分离：命中组与对照组表现稳定分化，不是偶发抖动或单点噪声。 因此，本节到此完成的是“发现阶段闭环”：已经能回答“漏洞是否被发现、发现依据是否充分”。\n后续第5节将不再讨论“如何发现”，而是转入“发现后可造成什么实际影响”，即漏洞可利用性分析。\n5. 漏洞可利用性分析 5.1 影响能力边界 结合 Rapid7 在 2024-03-04 披露中给出的公开利用样例，漏洞的实际危害可以拆成一条更具体的能力链：\n图5-1 从未认证访问到供应链外溢的能力升级路径。\n未认证调用管理 REST 接口（跨越登录边界）\n攻击者可构造类似 /does-not-exist?jsp=/app/rest/...;.jsp 的请求，把本应受保护的 REST 端点暴露给未登录请求。\n这一步代表的是直接获得对管理 API 的未认证调用能力。\n直接创建管理员账号（权限立刻提升到 SYSTEM_ADMIN）\nRapid7 的公开示例显示，攻击者可向 /app/rest/users 发起创建用户请求，并在请求体中赋予 SYSTEM_ADMIN 角色。\n返回结果中的用户对象会包含管理员角色字段，这意味着攻击者无需先拿低权限账号，起手就是全局管理员。\n生成管理员访问令牌（持久化控制）\n除了创建管理员用户，攻击者还可针对用户 token 接口（如 /app/rest/users/id:1/tokens/...）生成管理员 token。\n一旦 token 生成成功，即使后续密码策略变更，攻击者仍可能通过 API 持续访问，形成较强持久化。\n接管 TeamCity 控制面（项目/构建/制品/代理）\n在管理员权限下，影响范围不是单一页面，而是整个 TeamCity 控制面：\n项目与构建配置修改 构建任务与构建步骤变更 构建代理与制品链路控制 凭据、连接配置与自动化流程滥用 供应链外溢风险（从 CI/CD 平台扩展到下游）\nTeamCity 是 CI/CD 中枢，一旦被管理员级接管，风险会外溢到制品发布、部署流程和下游环境，因此该漏洞的危害不止“单机被控”，而是可能演化为供应链级事件。\n5.2 利用复杂度评估 前置门槛：仅需网络可达目标 TeamCity 服务，无需登录认证等权限。 交互要求：无需受害者额外交互。 利用稳定性：在满足语义条件时，利用链可重复触发。 对应 CVSS 9.8（Critical）的根本原因在于：攻击路径短、权限前置低、影响面高。\n其典型向量可表述为：CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H，即网络可达、低复杂度、无前置权限、无用户交互且三性高影响。\n5.3 在野利用与真实影响 从公开情报看，CVE-2024-27198 并非只是“理论可利用”，而是在披露后快速进入规模化利用阶段，体现出其低门槛与高收益特征。\n美国 CISA 将其纳入 KEV（Known Exploited Vulnerabilities）目录，并标注“已用于勒索软件”：CISA 的 KEV 条目显示该漏洞 Known To Be Used in Ransomware Campaigns: Known，并要求在规定日期前完成处置（联邦机构截止 2024-03-28）。这类信号通常意味着漏洞已进入实战攻击链条且应急优先级很高。\n厂商一手“受害者报告”：JetBrains 在后续官方文章中表示，在 Rapid7 发布完整技术细节与公开 exploit 示例之后，他们开始收到客户反馈服务器被入侵，并列举了多起代表性案例（包括勒索加密、异常管理员账号创建等）。\n披露后数小时至数天内出现规模化扫描与入侵迹象（第三方观测汇总）：\nShadowserver：最早在 2024-03-04 22:00 UTC 观测到利用尝试；2024-03-05 观测到约 16 个 IP 扫描互联网寻找易受攻击实例（媒体汇总口径）。 GreyNoise：追踪到针对该漏洞的利用尝试，观测到数十个恶意 IP 参与活动（媒体引用口径）。 LeakIX：在 2024-03-06 前后报告“clear signs of rogue user creation（明显的异常用户创建迹象）”；并在 2024-03-07 的媒体报道中被引用为 1,442 个实例存在此类迹象；同一报道还提到其观测到约 1,711 个仍处于易受攻击状态的实例。 安全厂商遥测观测到后渗透载荷投放：Trend Micro 报告称，其遥测观测到攻击者利用 TeamCity 漏洞链在受害服务器上投放多种后渗透载荷，包括勒索软件（Jasmin）、挖矿（XMRig）、Cobalt Strike beacon、SparkRAT 等，并给出了示例网络流量与进程树证据。该类后渗透活动符合“先接管 CI/CD 中枢，再横向与变现”的现实攻击路径。\n基于上述情报，我们可以确认，这个漏洞并不是“理论上很危险”，而是“已经被快速武器化并在野利用”的高危漏洞。\n6. 防御机制与突破点分析 6.1 目标系统原有防御机制 基于会话/身份的认证过滤链。 基于路径与资源类型的访问控制判定。 对部分视图后缀（如 JSP）的特殊处理逻辑。 6.2 被突破的关键点 该漏洞并不是“认证组件完全失效”，而是认证判定输入与实际执行输入不一致：\n上层鉴权逻辑按“请求外观”判定可放行； 下层控制器/路由按“规范化后语义”执行目标； 二者在分号参数、后缀与参数覆盖语义上存在差异，形成可利用的 Alternate Path。 6.3 防御启示 单点鉴权不足：必须保证“鉴权路径”和“执行路径”使用同一 canonical form。 路径规范化前置：在最上游统一做 URI 规范化并拒绝歧义输入。 语义黑名单不可靠：仅靠后缀/关键字过滤（如 .jsp）容易被组合绕过。 7. 修复与缓解建议 7.1 根本修复 升级至 TeamCity 2023.11.4 及以上版本（官方已修复）。 对无法立即升级的环境，优先采用官方给出的安全补丁方案。 7.2 过渡期缓解措施 将 TeamCity 管理面从公网下线，限制为内网或零信任访问。 通过反向代理/WAF 阻断异常路径语义组合（分号参数、异常后缀、路径-参数联动模式）。 开启并集中审计 TeamCity 访问日志，重点关注未认证请求命中管理 API 的异常行为。 7.3 检测与应急建议 排查异常新增用户、异常 Token、未知插件变更。 核验构建配置与制品完整性，防止供应链侧后门残留。 在完成修复后执行“漏洞版 vs 修复版”回归对照，确保拦截策略与业务兼容。 8. 漏洞披露与社区争议 该漏洞除了技术层面的典型性外，披露过程本身也很有代表性：它把“公开透明”与“防守窗口”之间的矛盾放到了台面上。\n图8-1 从漏洞报告、修复发布到在野利用确认的披露时间线与争议焦点。\n8.1 更完整的披露时间线 结合 JetBrains 与 Rapid7 双方公开信息，可以把链条补得更完整一些（JetBrains 时间线为 CET）：\n2024-02-19：Rapid7 首次联系 JetBrains，报告 TeamCity 严重安全问题。 2024-02-20：Rapid7 提交详细技术报告；JetBrains 当天复现确认。 2024-02-21 ~ 2024-02-23：双方围绕披露策略出现明显分歧。JetBrains 倾向“先发布修复与补丁、邮件通知客户、提供高层次风险说明，再延后完整技术细节”；Rapid7 则坚持修复一旦公开可得，就应尽快同步完整技术披露。 2024-03-01：双方继续就 CVE 标识、版本影响范围与披露节奏沟通。 2024-03-04 15:00：JetBrains 发布 2023.11.4（含修复）及安全补丁插件。 2024-03-04 15:05：JetBrains 向 TeamCity On-Premises 客户和安全订阅用户发送告警邮件。 2024-03-04 15:59：JetBrains 发布单独安全公告，公开 CVE-2024-27198 / CVE-2024-27199、受影响范围、严重性与缓解方案，但未公开完整 root cause、利用链与复现/利用细节。 2024-03-04 19:07：JetBrains 将这两个问题加入其公开安全问题页面，并使对应 CVE 记录对外可见。 2024-03-04 20:23：Rapid7 发布完整技术披露文章与利用细节。 2024-03-07：CISA 将 CVE-2024-27198 纳入 KEV，确认已进入在野利用态势。 需要特别区分的是，15:59 的动作是“安全公告发布”，而不是“完整技术披露”；19:07 则更接近“CVE 记录/安全问题页面正式公开”。Rapid7 文中还特别说明，JetBrains 的版本发布日志在不同时区可能显示为 3 月 3 日或 3 月 4 日，这也让“修复版到底何时已公开可得”在传播层面更容易引发争议。\n8.2 从披露到在野利用的加速链条 从 SecurityWeek（引用 Shadowserver、GreyNoise、LeakIX）和 CISA 信号看，利用出现速度很快：\n2024-03-04：漏洞细节公开当天即出现利用尝试。 2024-03-05：Shadowserver 观测到互联网扫描与探测活动上升；GreyNoise 也开始看到多源攻击尝试。 2024-03-06：LeakIX 报告出现大规模异常账户创建迹象。 2024-03-07：CISA 将其加入 KEV，风险等级进一步被官方“在野利用”标签确认。 这条链路的意义在于：争议不是停留在理念层，而是直接映射为防守方在最初 24~72 小时内的实战压力。\n8.3 争议焦点：不是“有没有公告”，而是“公开粒度与时机” 如果只看表面，会出现一个疑问：JetBrains 既然在 2024-03-04 15:59 已经发布了安全公告，Rapid7 为什么仍然会把这一路径描述为接近其所反对的 “silent patching”？关键原因在于，双方对“公开”一词的含义并不相同。\n对 Rapid7 而言，问题不在于厂商是否“完全沉默”，而在于：\n修复是否先于充分披露对外可见：一旦修复版已发布，具备逆向能力的攻击者就可能通过补丁比对快速理解漏洞；如果厂商此时只给高层次风险说明、而不及时公开足够的技术细节，信息优势会先落到高水平攻击者手里。 防守方是否获得了足够可操作的信息：从 Rapid7 的视角看，仅有“存在认证绕过风险、请立即升级”这类摘要，并不等于防守者已经拿到与攻击者近似对等的理解能力，因此这种“先修复、后细节”的模式会被归入其反对的 silent patching 范畴。 对 JetBrains 而言，安全公告、CVE 编号、影响范围和缓解措施已经足以构成“负责任通知”；真正不应在修复刚上线时同步公开的，是完整 root cause、利用条件与 exploit 细节。因为一旦这些内容在补丁发布同时出现，会显著降低利用门槛，使尚未完成升级的客户暴露在更高风险窗口中。\n因此，双方真正冲突的不是“该不该公开”，而是：\nRapid7 侧重点：反对“补丁先行、细节后置”，认为这会让 skilled attacker 比普通防守者更早获益。 JetBrains 侧重点：反对“修复与完整利用细节同步公开”，认为这会把窗口期内的攻击门槛压得过低。 换句话说，Rapid7 所说的 “silent patching” 在这里并不是指 “JetBrains 完全没有发公告”，而是指其反对“先发布修复和高层次公告，再延后完整技术披露”的披露模式；而 JetBrains 则认为，这种延迟 full disclosure 的做法恰恰是为了给客户争取升级与打补丁的缓冲时间。\n8.4 本文观点 我个人观点会更偏“分层披露”。说直白一点：Rapid7 反对静默修补并没有错，但这次节奏确实偏激进。\nTeamCity 这种全球广泛部署的 CI/CD 枢纽软件，企业侧真实响应要走“感知风险 -\u0026gt; 评估影响 -\u0026gt; 变更审批 -\u0026gt; 生产上线”这整套流程；很多组织在跨时区场景下，补丁发布后最初几小时甚至还没进入有效响应状态。\n所以问题不在“该不该公开”，而在“什么时候公开到什么粒度”。更现实的路径是：\n先同步高价值防守信息（受影响范围、风险等级、可执行缓解措施、检测线索）； 给一个可落地的升级窗口； 再发布完整技术细节。 这种“分层+分时”策略，通常更有机会同时兼顾透明性与防守可操作性。\n9. 结论 CVE-2024-27198 的典型性，不仅在于“未认证可达”，更在于它揭示了现代 Web 系统里一个经常被低估的问题：\n安全边界不是由某个单点鉴权函数决定的，而是由整条请求处理链的一致性决定的。\n从本文复现与分析过程看，这个漏洞并非传统意义上的“显式越权接口”，而是由三层因素叠加形成的语义错位：\n路径外观（.jsp）改变了请求进入的处理链； 控制器允许请求参数参与视图目标改写； 路径规范化（尤其分号语义）在不同阶段存在解释差异。 这三者叠加后，系统出现了“鉴权看到一种请求，执行命中另一种请求”的结构性问题。\n也正因为如此，这类漏洞的修复重点不应停留在“补一个黑名单规则”，而应转向更稳定的工程策略：在统一的 canonical form 上完成鉴权、路由、视图解析与审计，并把跨阶段语义一致性作为安全设计约束。\n从攻防视角看，CI/CD 平台的风险放大效应值得特别强调。TeamCity 一旦被绕过认证并进入管理面，影响对象不再是单台服务，而是项目配置、构建链路、制品分发与下游部署流程。这也是该漏洞被评为 Critical 并在披露后迅速武器化的根本原因。\n因此，这次分析的价值不只在于还原了一个历史漏洞，更在于给出了一条可迁移的方法论：\n先做行为基线，再做语义变异；先证实异常，再灰盒收敛；最后用可分离的对照样本验证机制。\n这套路径对于同类“认证边界错位”问题，具有普遍适用性。\n10. 参考与来源 Rapid7 原始漏洞披露声明（阐述了漏洞技术细节及其反静默修补的立场）: CVE-2024-27198 and CVE-2024-27199: JetBrains TeamCity Multiple Authentication Bypass Vulnerabilities (FIXED) JetBrains 官方安全通报（呼吁客户升级并提及了与 Rapid7 的时间线争议）: Additional Critical Security Issues Affecting TeamCity On-Premises (CVE-2024-27198 and CVE-2024-27199) – Update to 2023.11.4 Now JetBrains 官方回应争议的专门文章（阐述了其“延迟披露”的伦理考量及后续观测到的勒索攻击情况）: Preventing Exploits: JetBrains’ Ethical Approach to Vulnerability Disclosure JetBrains 披露时间线总结: Insights and Timeline: Our Approach to Addressing the Recently Discovered Vulnerabilities in TeamCity On-Premises 在野利用证据（政府与安全厂商）: CISA Adds One Known Exploited JetBrains Vulnerability, CVE-2024-27198, to Catalog CISA Known Exploited Vulnerabilities Catalog（CVE-2024-27198 条目） Trend Micro: TeamCity Vulnerability Exploits Lead to Jasmin Ransomware, Other Malware Types SecurityWeek: Critical TeamCity Vulnerability Exploitation Started Immediately After Disclosure SC Media/SCWorld: JetBrains TeamCity critical flaw exploited; 1.4k servers compromised ","permalink":"https://aries441.tech/posts/vuln-reproduction/teamcity-cve-2024-27198/","summary":"\u003ch1 id=\"teamcity认证绕过漏洞cve-2024-27198复现报告与分析\"\u003eTeamCity认证绕过漏洞（CVE-2024-27198）复现报告与分析\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003e免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth style=\"text-align: left\"\u003e漏洞编号\u003c/th\u003e\n          \u003cth style=\"text-align: left\"\u003eCVE-2024-27198\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003eCWE分类\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003eCWE-288（备用路径导致认证绕过）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003e发现时间\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003e2024年2月（由 Rapid7 的 Stephen Fewer 发现）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003eCVSS评分\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003e9.8 (Critical / 严重)\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003e受影响版本\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003eJetBrains TeamCity On-Premises \u0026lt;= 2023.11.3\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003e修复版本\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003eJetBrains TeamCity 2023.11.4\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd style=\"text-align: left\"\u003e\u003cstrong\u003e危害描述\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd style=\"text-align: left\"\u003e未经身份验证的攻击者可通过特定的URL路径绕过认证机制，获取管理员权限并接管TeamCity服务器，进而可能导致供应链投毒攻击。\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"目录\"\u003e目录\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e引言与漏洞背景\u003c/li\u003e\n\u003cli\u003e漏洞成因分析\u003c/li\u003e\n\u003cli\u003e漏洞触发环境与复现条件\u003c/li\u003e\n\u003cli\u003e漏洞发现方法与过程（0day视角）\u003c/li\u003e\n\u003cli\u003e漏洞可利用性分析\u003c/li\u003e\n\u003cli\u003e防御机制与突破点分析\u003c/li\u003e\n\u003cli\u003e修复与缓解建议\u003c/li\u003e\n\u003cli\u003e漏洞披露与社区争议\u003c/li\u003e\n\u003cli\u003e结论\u003c/li\u003e\n\u003cli\u003e参考与来源\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"1-引言与漏洞背景\"\u003e1. 引言与漏洞背景\u003c/h2\u003e\n\u003cp\u003eTeamCity 是 JetBrains 开发的一款广泛使用的 CI/CD（持续集成与持续交付）服务器，在企业软件开发生命周期中占据核心地位。由于其掌控着代码构建与部署权限，一旦被攻陷，极易引发大范围的软件供应链攻击。\u003c/p\u003e\n\u003cp\u003e2024年2月，Rapid7 漏洞研究团队在 TeamCity 的 Web 组件中发现了两个严重的认证绕过漏洞（CVE-2024-27198 与 CVE-2024-27199）。其中，CVE-2024-27198（CVSS 9.8）由于允许未经身份验证的攻击者直接获取最高管理权限并实现远程代码执行（RCE），危害尤为严重。\u003c/p\u003e\n\u003cp\u003e值得注意的是，该漏洞在3月初的披露过程并非一帆风顺。由于发现方（Rapid7）与厂商（JetBrains）在“协调披露”与“静默修补”理念上产生严重分歧，Rapid7 在补丁发布当日即公开了详细技术报告。这一事件不仅导致随后几天内爆发了针对该漏洞的大规模在野利用（如勒索软件和挖矿木马），更在安全社区引发了一场关于“漏洞披露伦理”的广泛争论（详见文末讨论）。\u003c/p\u003e\n\u003ch2 id=\"2-漏洞成因分析\"\u003e2. 漏洞成因分析\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e本节内容依据 Rapid7 官方报告 analysis 部分进行翻译与整理，重点还原“代码层为什么会绕过”，而非仅描述复现步骤。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e该漏洞本质属于 \u003cstrong\u003eCWE-288（Authentication Bypass Using an Alternate Path）\u003c/strong\u003e：请求在不同处理层被解释为不同语义，导致鉴权边界与执行边界错位。\u003c/p\u003e","title":"TeamCity 认证绕过漏洞复现与分析（CVE-2024-27198）"},{"content":"我最近在搓一个自动化知识库处理工具，用来处理飞书收集群里的增量消息。起因很简单：平时习惯睡前刷技术博客，顺手把链接丢进微信或飞书——但忙起来根本没空整理；偶尔读完会随手记几句想法，一旦拖着就全忘了。所以就想做个工具，自动帮我汇总内容、归纳知识、顺带把那些随手写下来的东西也存住。\n有些时候这些内容会包含 PDF 文件，需要能自动提取里面的内容。调研之后，发现 MinerU 比较合适，可以从 PDF 里自动提取文本。我最开始是在 B 站上刷到这个工具的，然后从评论区注意到有位用户提到它用的是传染性开源协议——也就是用了这个项目，就必须开源自己的代码。不过我发现最新的项目 README 里写着：\n2026/04/18 3.1.0 Released\nThis release focuses on licensing openness, parsing accuracy, and full-format native support. The main updates include:\nLicense upgrade MinerU has officially moved from AGPLv3 to the MinerU Open Source License, a custom license based on Apache 2.0. This change significantly reduces adoption friction for both community users and commercial deployments, making MinerU easier to integrate into real-world workflows.\n正是这个事情，让我打算了解一下各个常见的开源协议，以及它们的区别和联系，避免以后在用开源项目时因为协议问题踩坑。\n常见开源协议的理解 理解开源协议，核心不是\u0026quot;能不能看代码\u0026quot;，而是拿来之后能不能改、能不能商用、改完之后要不要公开、需不需要带上原作者声明、有没有专利授权。很多纠纷其实不是因为代码本身，而是因为把协议条款想得太简单了。\n如果只是粗粗地分类，可以分成下面几类：\n宽松型协议（Permissive License） 弱传染型协议（Weak Copyleft） 强传染型协议（Strong Copyleft） 自定义协议（Custom License） 其中真正最容易踩坑的，往往是后两类，因为它们对\u0026quot;修改后怎么分发\u0026quot;\u0026ldquo;是否需要开源\u0026quot;\u0026ldquo;是否涉及网络服务\u0026quot;这些问题限制更强。\n速记表 协议 商用 修改 闭源集成 修改后是否可能要求开源 专利条款 MIT 可以 可以 可以 通常不要求 弱 Apache 2.0 可以 可以 可以 通常不要求 强，写得较清楚 BSD 可以 可以 可以 通常不要求 一般 GPL 可以 可以 风险高 分发衍生作品时要求较强 一般 LGPL 可以 可以 相对可以 主要针对库本身修改 一般 AGPL 可以 可以 风险更高 对网络服务场景也要求较强 一般 MPL 2.0 可以 可以 可以 文件级开源要求 一般 这个表只能拿来做第一层筛选，不能直接代替正式合规判断，因为真正有争议的地方往往在\u0026quot;是否构成衍生作品\u0026quot;\u0026ldquo;只是调用还是深度集成\u0026quot;\u0026ldquo;是否发生分发\u0026quot;\u0026ldquo;SaaS 是否触发条款\u0026quot;等边界问题上。\n1. MIT License MIT 应该算是 GitHub 上最常见、也最好理解的协议之一。\n它的核心特点可以概括为：\n允许商用 允许修改 允许再分发 允许闭源使用 只要求保留原始版权声明和许可声明 如果一个项目是 MIT，通常可以比较放心地集成进自己的系统里，哪怕是商业项目也一般问题不大。它的优点就是简单、传播阻力小，很多库作者选 MIT，就是希望别人尽量少受限制地使用。\n不过 MIT 也不是\u0026quot;完全没要求\u0026rdquo;，至少原作者的版权和许可文本不能删。另外它一般不强调专利条款，所以如果项目涉及比较强的专利风险，通常会更倾向于看 Apache 2.0。\n2. Apache License 2.0 Apache 2.0 也是非常常见的宽松型协议，但比 MIT 更完整一些。\n它的关键点可以记成：\n允许商用 允许修改 允许闭源分发 要保留版权声明和 License 如果项目里有 NOTICE 文件，分发时通常也要一起带上 明确给出了专利授权和专利终止条款 所以 Apache 2.0 可以理解成\u0026quot;更工程化的 MIT\u0026rdquo;。\n如果一个项目来自大公司、基金会或者成熟社区，看到 Apache 2.0 往往会更安心，因为它把专利问题写得更清楚。\n像这次 MinerU 从 AGPLv3 切到一个基于 Apache 2.0 的自定义协议，这件事本身就说明了一个问题：项目如果想让更多企业和真实业务接得进来，通常会尽量降低协议阻力，而 Apache 2.0 这类协议就比较适合作为基础。\n3. BSD License BSD 也属于宽松型协议，常见的有 BSD 2-Clause 和 BSD 3-Clause。\n对 BSD 的粗略理解是：\n和 MIT 很像 也是允许商用、修改、闭源 主要义务还是保留版权声明和许可文本 3-Clause 比 2-Clause 多一个\u0026quot;不能用原作者或组织名义做背书宣传\u0026quot;的限制 从实际使用角度看，BSD、MIT、Apache 2.0 经常可以归到一组里理解：整体都比较宽松，适合做基础组件、工具库、SDK 之类的东西。\n4. GPL License GPL 是典型的强传染型协议，也是很多人口中\u0026quot;病毒式协议\u0026quot;\u0026ldquo;传染性协议\u0026quot;的来源。不过\u0026quot;传染性\u0026quot;这个说法虽然好记，但也容易让人理解过度，更准确的说法是：它要求衍生作品在特定分发条件下继续以 GPL 开源。\nGPL 的理解重点是：\n允许使用、修改、分发、商用 但如果把基于 GPL 的程序修改后再分发，通常也必须以 GPL 方式开放源码 不能把 GPL 代码拿进去改一改，然后整体闭源卖掉 所以 GPL 的核心思想不是\u0026quot;禁止商业化\u0026rdquo;，而是\u0026quot;商业化可以，但你不能把自由重新收回去\u0026rdquo;。\n这类协议适合那些希望社区贡献持续回流、不希望别人拿去闭源包装的项目。\n5. LGPL License LGPL 可以看成比 GPL 更宽松一些，常见于类库场景。\nLGPL 的理解是：\n如果只是动态链接一个 LGPL 库，自己的主程序通常不一定需要整体开源 但如果直接修改了这个 LGPL 库本身，修改部分通常仍然要按 LGPL 公开 它比 GPL 更适合做\u0026quot;希望被广泛调用，但又不想完全放弃回馈要求\u0026quot;的基础库 所以 LGPL 经常被看作\u0026quot;弱一点的 GPL\u0026rdquo;。\n对使用者来说，它比 GPL 友好，但也不像 MIT/Apache 那么随意。\n6. AGPL License AGPL 是这次最关注的一个，因为它跟 SaaS/在线服务的关系很大。\nAGPL 的核心理解是：\n它基本继承了 GPL 的强 Copyleft 思想 但它额外补上了\u0026quot;网络服务\u0026quot;这个场景 如果我修改了 AGPL 程序，并通过网络向用户提供服务，那么通常也需要向这些用户提供对应的源码 这就是为什么很多人一听到 AGPL 就很紧张。\n对传统 GPL 来说，有些公司可能不\u0026quot;分发软件\u0026rdquo;，而是只把它部署成在线服务，从而绕开开源义务；AGPL 就是专门堵这个洞的。\n所以如果一个项目是 AGPL，通常会特别关注：\n是只在内部研究使用，还是要对外提供服务 有没有修改原项目 整体系统是否会因此被认定为衍生作品 对于打算商业化部署的工具链来说，AGPL 的采用门槛确实会明显更高。\n7. MPL 2.0 MPL 2.0 是一个很值得记住的中间路线。\n它属于弱传染型协议，可以这样理解：\n允许商用 允许和闭源代码一起组合 但如果修改了 MPL 覆盖的那个文件，这些被修改的文件通常要继续开源 它的开源义务通常是\u0026quot;文件级\u0026quot;的，而不是像 GPL 那样容易扩展到整个项目 所以 MPL 2.0 比较适合那种既想保留一定回馈机制、又不想把限制放得像 GPL/AGPL 那么重的项目。\n如果以后自己做工具，希望\u0026quot;别人能商用，但改了核心文件最好回传\u0026quot;，MPL 其实是一个可以重点考虑的方向。\n8. The Unlicense The Unlicense 可以理解成一种非常极端的宽松态度，接近于把代码直接放进公有领域。\n对它的印象是：\n几乎不设限制 允许任意使用、修改、分发 对某些法域下\u0026quot;公有领域让渡是否绝对成立\u0026quot;可能存在理解差异 所以它虽然很自由，但在一些正式商业场景里，可能不如 MIT/Apache 2.0 那么常见和稳妥。\n9. 自定义协议 — 以 MinerU 为例 前面分类里提到了\u0026quot;自定义协议\u0026quot;，MinerU 的新协议就是一个现成的例子，可以拿来具体看看。\n自定义协议的常见做法是：在 MIT 或 Apache 2.0 这类宽松协议上，叠加一些附加条款，针对特定场景补充约束。MinerU 的协议底层是 Apache 2.0，但额外加了两条：\n条款一：商业规模门槛\n免费商用默认可以，但如果你和你的关联公司合并计算，达到以下任一条件，就需要单独向 MinerU 团队获取商业授权才能继续使用：\n月活用户（MAU）超过 1 亿；或 单月总收入超过 2000 万美元 换句话说，对于大多数使用场景——个人研究、内部工具、中小规模商业部署——这个门槛根本不会触发，用起来跟 Apache 2.0 几乎没有区别。只有真正达到平台级体量的公司，才需要单独谈。\n条款二：在线服务署名义务\n如果把 MinerU 做成面向第三方用户的在线服务，需要在产品界面或公开文档里明确标注使用了 MinerU。\n另需注意：部分依赖模型仍是 AGPL\nMinerU 里集成的一些模型组件（如基于 YOLO 的检测模型）本身使用的是 AGPL 协议，并不随主协议变化。如果最终部署的服务用到了这部分模型，AGPL 的在线服务开源义务仍然适用。所以使用前，最好把依赖链也一起查清楚。\n和 AGPLv3 相比，这个协议温和很多：\n不要求公开源代码，闭源商用也没问题 做成 SaaS 也不需要开源，只需要标明\u0026quot;使用了 MinerU\u0026quot; 只有极少数超大规模场景才需要另行授权 这类\u0026quot;宽松协议 + 商业规模限制\u0026quot;的组合，在 AI 工具和数据处理领域越来越常见——作者希望社区可以自由使用，但不想让大公司直接拿去做亿级用户的产品却没有任何回馈或沟通。\n这也说明了开头那个分类里\u0026quot;自定义协议\u0026quot;存在的意义：当标准协议不能完全表达作者的意图时，自定义一个反而更直接。\n几个关键区别 1. \u0026ldquo;开源\u0026quot;不等于\u0026quot;随便用\u0026rdquo; 只要作者没有明确给出许可证，哪怕代码放在 GitHub 上公开可见，也不代表别人就可以随便复制、修改和商用。\n所以看到仓库的第一件事，不应该先看 star 数，而应该先看 License。\n2. GPL 和 AGPL 的差别，关键在网络服务 这两个很容易混。速记方法：\nGPL：更关注\u0026quot;分发\u0026quot;软件时的开源义务 AGPL：在 GPL 基础上，进一步覆盖\u0026quot;通过网络提供服务\u0026quot;的场景 如果一个工具未来可能做成 Web 服务、SaaS 平台、在线 API，那 AGPL 的影响通常比 GPL 更敏感。\n3. 宽松型协议更适合基础设施传播 MIT、BSD、Apache 2.0 之所以流行，一个很大的原因就是它们太适合做生态底座了。\n别人拿来就能用，商业公司也容易接，阻力小，扩散快。\n4. Copyleft 协议更强调社区回流 GPL、AGPL、MPL、LGPL 这类协议背后的思想，不只是\u0026quot;限制\u0026quot;，更像是在设计一种回馈机制：\n你可以拿去用，但你不能只拿走好处、不把改动回馈回来。\n所以不能简单说哪种协议更\u0026quot;好\u0026quot;，更多还是取决于项目作者想要什么。\n如果以后自己选协议，可以怎么想 目前大概可以这样粗分：\n如果希望别人尽量广泛使用，包括公司直接接入商业系统，可以优先考虑 MIT 或 Apache 2.0 如果担心专利问题，或者希望条款更完整，可以更偏向 Apache 2.0 如果希望改动能回流，但又不想强制整个项目一起开源，可以考虑 MPL 2.0 或 LGPL 如果非常强调\u0026quot;改了再分发就必须继续开源\u0026quot;，可以考虑 GPL 如果连 SaaS 场景也想覆盖，不希望别人改完部署成在线服务却完全不回馈，可以考虑 AGPL 一个排查清单 以后在用一个开源项目之前，至少先问下面几个问题：\n这个仓库到底有没有明确 License？ 它是 MIT/Apache 这种宽松协议，还是 GPL/AGPL 这种 Copyleft 协议？ 是只在内部研究，还是要集成到商业项目里？ 是单纯调用，还是会直接修改它的源代码？ 会不会把它做成对外提供服务的在线系统？ 项目里除了代码 License 之外，还有没有 NOTICE、商标、专利、模型权重、数据集等额外限制？ 一个很重要的认识 以后看开源项目，不能只盯着\u0026quot;功能强不强\u0026quot;，还得把\u0026quot;协议带来的接入成本\u0026quot;也一起算进去。\n有些项目技术上非常合适，但协议不一定适合当前业务形态；有些项目虽然功能略弱，但协议更宽松、接入成本更低，在工程上反而更现实。\n所以协议本身，其实也是技术选型的一部分。\n备注 以上内容主要适合拿来做技术选型和日常避坑时的第一轮判断，不适合直接替代正式法律意见。真遇到商业化、融资、闭源分发、对外 SaaS 或者二次授权这类场景，还是应该认真看原协议文本，必要时找专业法务确认。\n","permalink":"https://aries441.tech/posts/tech-notes/open-source-license/","summary":"\u003cp\u003e我最近在搓一个自动化知识库处理工具，用来处理飞书收集群里的增量消息。起因很简单：平时习惯睡前刷技术博客，顺手把链接丢进微信或飞书——但忙起来根本没空整理；偶尔读完会随手记几句想法，一旦拖着就全忘了。所以就想做个工具，自动帮我汇总内容、归纳知识、顺带把那些随手写下来的东西也存住。\u003c/p\u003e\n\u003cp\u003e有些时候这些内容会包含 PDF 文件，需要能自动提取里面的内容。调研之后，发现 \u003ca href=\"https://github.com/opendatalab/MinerU\"\u003eMinerU\u003c/a\u003e 比较合适，可以从 PDF 里自动提取文本。我最开始是在 B 站上刷到这个工具的，然后从评论区注意到有位用户提到它用的是传染性开源协议——也就是用了这个项目，就必须开源自己的代码。不过我发现最新的项目 README 里写着：\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e2026/04/18 3.1.0 Released\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThis release focuses on licensing openness, parsing accuracy, and full-format native support. The main updates include:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eLicense upgrade\u003c/strong\u003e\nMinerU has officially moved from AGPLv3 to the MinerU Open Source License, a custom license based on Apache 2.0.\nThis change significantly reduces adoption friction for both community users and commercial deployments, making MinerU easier to integrate into real-world workflows.\u003c/p\u003e","title":"从 MinerU 换证说起：常见开源协议的区别和坑"},{"content":"漏洞背景 Nacos 是阿里巴巴开源的动态服务发现、配置管理和服务管理平台。 在特定的历史版本中，Nacos 存在身份认证绕过漏洞（CVE-2021-29441）。\n漏洞原理 由于在处理请求时，对特定 User-Agent 或特定参数判断存在逻辑缺陷，导致攻击者可以伪造身份绕过鉴权，直接读取或修改配置中心的配置。\nAccessGuard 审计视角 在重构 AccessGuard 时，我们将 Nacos 作为一个典型的 DevOps 平台基础设施靶场。 传统的 SAST 工具难以理解 User-Agent 与后端拦截器（Interceptor）或过滤器（Filter）之间的权限状态转移。\n通过引入 LLM-driven 的 Agentic 架构，AccessGuard 能够：\n识别 NacosAuthFilter 中的守卫逻辑。 发现其对特殊请求头的硬编码放行逻辑。 判定该放行逻辑与敏感 Sink 之间存在可达路径。 复现步骤 (本文为测试文章，详细复现步骤将在后续更新)\n","permalink":"https://aries441.tech/posts/vuln-reproduction/nacos-cve-2021-29441/","summary":"\u003ch2 id=\"漏洞背景\"\u003e漏洞背景\u003c/h2\u003e\n\u003cp\u003eNacos 是阿里巴巴开源的动态服务发现、配置管理和服务管理平台。\n在特定的历史版本中，Nacos 存在身份认证绕过漏洞（CVE-2021-29441）。\u003c/p\u003e\n\u003ch2 id=\"漏洞原理\"\u003e漏洞原理\u003c/h2\u003e\n\u003cp\u003e由于在处理请求时，对特定 User-Agent 或特定参数判断存在逻辑缺陷，导致攻击者可以伪造身份绕过鉴权，直接读取或修改配置中心的配置。\u003c/p\u003e\n\u003ch2 id=\"accessguard-审计视角\"\u003eAccessGuard 审计视角\u003c/h2\u003e\n\u003cp\u003e在重构 \u003cstrong\u003eAccessGuard\u003c/strong\u003e 时，我们将 Nacos 作为一个典型的 DevOps 平台基础设施靶场。\n传统的 SAST 工具难以理解 \u003ccode\u003eUser-Agent\u003c/code\u003e 与后端拦截器（Interceptor）或过滤器（Filter）之间的权限状态转移。\u003c/p\u003e\n\u003cp\u003e通过引入 LLM-driven 的 Agentic 架构，AccessGuard 能够：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e识别 \u003ccode\u003eNacosAuthFilter\u003c/code\u003e 中的守卫逻辑。\u003c/li\u003e\n\u003cli\u003e发现其对特殊请求头的硬编码放行逻辑。\u003c/li\u003e\n\u003cli\u003e判定该放行逻辑与敏感 Sink 之间存在可达路径。\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"复现步骤\"\u003e复现步骤\u003c/h2\u003e\n\u003cp\u003e\u003cem\u003e(本文为测试文章，详细复现步骤将在后续更新)\u003c/em\u003e\u003c/p\u003e","title":"Nacos 身份认证绕过漏洞复现 (CVE-2021-29441)"},{"content":"👋 简介 你好！我是 Aries441，一名前沿的 AI 安全研究员。\n目前我正在 中国科学院信息工程研究所 (IIE, CAS) 攻读专硕，研究方向聚焦于 漏洞利用与挖掘（特别是 LLM 辅助 DevOps 平台访问控制漏洞）。 在此之前，我本科毕业于 上海交通大学 (SJTU) 信息安全专业。\n🛡️ 核心关注领域 AI Security: 探索大模型在安全领域的应用与边界。 Vulnerability Audit: 突破传统 SAST 工具的局限，专注于复杂的逻辑漏洞（如 IDOR/BAC）。 DevOps Security: 研究面向复杂权限模型的 DevOps 平台（如 Nacos, Jenkins）的安全体系。 🚀 正在进行的项目 AccessGuard 一个基于 LangGraph 的 DevOps 平台逻辑漏洞自动化审计系统。该项目旨在解决传统扫描器无法理解复杂 RBAC/ABAC 权限模型的问题，利用 LLM 驱动的 Agent 进行智能检索与可达性判定。\n📬 联系方式 GitHub: @Aries-441 Email: (欢迎通过 GitHub 邮箱联系我) “In security, context is everything.”\n","permalink":"https://aries441.tech/about/","summary":"\u003ch2 id=\"-简介\"\u003e👋 简介\u003c/h2\u003e\n\u003cp\u003e你好！我是 \u003cstrong\u003eAries441\u003c/strong\u003e，一名前沿的 AI 安全研究员。\u003c/p\u003e\n\u003cp\u003e目前我正在 \u003cstrong\u003e中国科学院信息工程研究所 (IIE, CAS)\u003c/strong\u003e 攻读专硕，研究方向聚焦于 \u003cstrong\u003e漏洞利用与挖掘\u003c/strong\u003e（特别是 LLM 辅助 DevOps 平台访问控制漏洞）。\n在此之前，我本科毕业于 \u003cstrong\u003e上海交通大学 (SJTU)\u003c/strong\u003e 信息安全专业。\u003c/p\u003e\n\u003ch2 id=\"-核心关注领域\"\u003e🛡️ 核心关注领域\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAI Security\u003c/strong\u003e: 探索大模型在安全领域的应用与边界。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVulnerability Audit\u003c/strong\u003e: 突破传统 SAST 工具的局限，专注于复杂的逻辑漏洞（如 IDOR/BAC）。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDevOps Security\u003c/strong\u003e: 研究面向复杂权限模型的 DevOps 平台（如 Nacos, Jenkins）的安全体系。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"-正在进行的项目\"\u003e🚀 正在进行的项目\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e\u003ca href=\"https://github.com/Aries-441\"\u003eAccessGuard\u003c/a\u003e\u003c/strong\u003e\n一个基于 LangGraph 的 DevOps 平台逻辑漏洞自动化审计系统。该项目旨在解决传统扫描器无法理解复杂 RBAC/ABAC 权限模型的问题，利用 LLM 驱动的 Agent 进行智能检索与可达性判定。\u003c/p\u003e\n\u003ch2 id=\"-联系方式\"\u003e📬 联系方式\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eGitHub\u003c/strong\u003e: \u003ca href=\"https://github.com/Aries-441\"\u003e@Aries-441\u003c/a\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEmail\u003c/strong\u003e: \u003cem\u003e(欢迎通过 GitHub 邮箱联系我)\u003c/em\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cem\u003e“In security, context is everything.”\u003c/em\u003e\u003c/p\u003e","title":"关于我 (About Me)"},{"content":"痛点与背景 传统的 SAST（静态应用安全测试）工具通常基于数据流分析，在处理复杂的业务逻辑漏洞（如越权访问 IDOR/BAC）时显得力不从心。特别是在 DevOps 平台（如 GitLab, Jenkins, Nacos 等）中，权限模型往往是矩阵式的（User/Group/Project），传统扫描器无法有效覆盖。\nAccessGuard 的破局思路 AccessGuard 引入了 LLM 驱动的 Agentic 架构：\n语义理解：利用 LLM 强大的代码理解能力，精准识别代码中的守卫逻辑（Guard）和敏感操作（Sink）。 状态机编排：使用 LangGraph 进行复杂的审计流程状态编排，取代了简单的单次 Prompt 问答。 主动探索：赋予 Agent 检索工具，使其能像人类安全专家一样主动追溯权限流转。 当前进展与评测 目前项目已经在包含 WebGoat、Nacos 等多个靶场的数据集上进行了评测验证。 指标：Recall \u0026gt; 0.9，F1 Score \u0026gt; 0.8。\n(本文为测试文章，详细技术架构文档将在后续更新)\n","permalink":"https://aries441.tech/posts/projects/accessguard-intro/","summary":"\u003ch2 id=\"痛点与背景\"\u003e痛点与背景\u003c/h2\u003e\n\u003cp\u003e传统的 SAST（静态应用安全测试）工具通常基于数据流分析，在处理复杂的业务逻辑漏洞（如越权访问 IDOR/BAC）时显得力不从心。特别是在 DevOps 平台（如 GitLab, Jenkins, Nacos 等）中，权限模型往往是矩阵式的（User/Group/Project），传统扫描器无法有效覆盖。\u003c/p\u003e\n\u003ch2 id=\"accessguard-的破局思路\"\u003eAccessGuard 的破局思路\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eAccessGuard\u003c/strong\u003e 引入了 LLM 驱动的 Agentic 架构：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e语义理解\u003c/strong\u003e：利用 LLM 强大的代码理解能力，精准识别代码中的守卫逻辑（Guard）和敏感操作（Sink）。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e状态机编排\u003c/strong\u003e：使用 LangGraph 进行复杂的审计流程状态编排，取代了简单的单次 Prompt 问答。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e主动探索\u003c/strong\u003e：赋予 Agent 检索工具，使其能像人类安全专家一样主动追溯权限流转。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"当前进展与评测\"\u003e当前进展与评测\u003c/h2\u003e\n\u003cp\u003e目前项目已经在包含 WebGoat、Nacos 等多个靶场的数据集上进行了评测验证。\n指标：\u003ccode\u003eRecall \u0026gt; 0.9\u003c/code\u003e，\u003ccode\u003eF1 Score \u0026gt; 0.8\u003c/code\u003e。\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e(本文为测试文章，详细技术架构文档将在后续更新)\u003c/em\u003e\u003c/p\u003e","title":"AccessGuard: 基于 LangGraph 的 DevOps 漏洞自动化审计"}]