渗透区块

去年秋天，渗透区块我在一个做网络安全的渗透区块朋友办公室里，看他演示了一次渗透测试。渗透区块目标是渗透区块一家小型电商平台，前后不到四十分钟，渗透区块他从一个看似无关紧要的渗透区块客服工单系统摸进了核心数据库。整个过程没有用任何零日漏洞，渗透区块全是渗透区块“正常功能”的滥用。这事让我意识到，渗透区块渗透区块这个概念，渗透区块远比大多数人理解的渗透区块更日常。

所谓渗透区块，渗透区块不是渗透区块某个具体的漏洞类型，也不是渗透区块一套固定的攻击工具。它更像一种思维模型：把目标系统切成若干个功能区块，渗透区块然后逐个问自己——这个区块的信任边界在哪里？它跟其他区块之间靠什么传递信任？那些传递信任的接口，有没有可能被诱导着做出超出设计意图的事？

那个客服工单系统就是典型。它本身权限很低，只能查看和回复用户提交的问题。但它有一个“附件预览”功能，会从对象存储里拉取用户上传的图片。朋友发现，预览接口没有校验文件路径，只校验了文件扩展名。于是他构造了一个路径穿越请求，让预览接口去读对象存储之外的一个配置文件。配置文件里躺着数据库连接串。就这么简单。

这里的关键不是路径穿越本身。路径穿越是老掉牙的东西。关键在于，客服工单系统这个区块，被设计为“低权限、只读、面向外部用户”。但它跟对象存储之间有一条信任通道，而对象存储又跟内部配置管理共享同一套凭证体系。信任在区块之间流动的时候，没有被重新评估。

很多团队做安全加固，习惯按资产重要性来分配精力。核心数据库、支付网关、用户认证服务，这些是重点。客服工单？边缘系统，随便搞搞就行。但渗透区块的思路恰恰相反：攻击者不关心哪个区块“重要”，他们关心哪个区块“好进”，以及进去之后能摸到哪条信任链。一条从边缘到核心的信任链，比核心系统本身的一个中危漏洞危险得多。

我后来跟另一个做红队的朋友聊起这事。他说他们内部有个说法叫“区块跳板”。每次拿到一个低权限入口，第一件事不是急着提权，而是画一张图：当前区块能访问哪些其他区块？哪些访问是设计内的，哪些是设计外的？哪些设计外的访问虽然不能直接利用，但能作为下一步的跳板？这张图画完，攻击路径往往就浮出来了。

防御方要做的，是反过来审视这张图。不是问“这个区块有没有漏洞”，而是问“这个区块被攻破之后，攻击者能到达哪里”。如果答案是一个核心区块，那这两个区块之间的信任关系就需要重新设计。可能是加一道网关，可能是换一套独立凭证，可能是把同步调用改成异步消息——具体手段看场景，但原则是一致的：信任不应该在区块之间自动传递。

回到那个电商平台。朋友最后给的修复建议里，第一条不是修路径穿越，而是把客服工单系统的对象存储访问权限单独隔离出来，不再共享内部配置管理的凭证。路径穿越当然也修了，但那条信任链断了之后，就算再出一个类似的漏洞，攻击者也摸不到数据库了。

渗透区块这件事，说到底是在跟系统的“连接方式”较劲。单个区块再硬，连接方式错了，整个系统就是软的。而连接方式往往藏在那些不起眼的、被认为“不重要”的边缘区块里。