基于云的源代码管理(SCM)平台支持通过webhook与自托管CI/CD解决方案集成，这非常适合DevOps自动化。然而，好处可能伴随着安全性的权衡。根据Cider研究人员的新发现，恶意行为者可以滥用webhook访问内部资源、运行远程代码执行(RCE)，并可能获得反向shell访问权限。

软件即服务(SaaS)SCM系统为其webhook提供IP范围。组织必须向这些IP范围开放其网络，以实现SCM与其自托管CI/CD系统之间的集成。

“我们知道SaaS源代码控制管理系统和自我管理CI以及允许用于CI的webhook服务IP范围的组合是一种通用架构，我们希望在那里检查我们的可能性，”Omer Gil，研究主管说。

攻击者可以使用webhook绕过组织的防火墙。但是SCM webhook有严格的限制，对webhook请求进行修改的空间非常小。

然而，研究人员发现，通过正确的更改，他们可以超越SCM webhook可用的有限端点。

在CI/CD方面，研究人员在开源DevOps服务器Jenkins上进行了实验。

“我们选择Jenkins是因为它是自托管且常用的，但[我们的发现]可以应用于任何可从SCM访问的系统，例如工件注册表，”Gil说。

在SCM方面，他们测试了GitHub和GitLab。虽然webhook旨在触发特定的CI端点，但它们可以修改请求以将它们定向到返回用户数据的其他端点或管道的控制台输出。然而，限制仍然存在。

“Webhook作为POST请求发送，这限制了针对目标服务的选项，因为用于检索数据的端点通常只接受GET参数，”Gil说。“虽然不可能通过GitHub触发GET请求，但在GitLab中却是另一种情况，因为如果POST请求通过重定向响应，GitLab webhook服务将跟随它发送GET请求。”

使用GitLab，研究人员能够使用webhook组合POST和GET请求来访问内部资源。有趣的是，一些Jenkins资源无需身份验证即可访问。

“默认情况下，某些资源可以匿名访问。话虽如此，组织保持原样并不常见 - 但有些确实允许匿名访问，“吉尔说。

如果需要进行身份验证，研究人员发现他们可以将webhook定向到登录端点并对CI/CD平台进行暴力密码攻击。一旦通过身份验证，他们就会获得一个可用于访问其他资源的会话cookie。

如果Jenkins实例有一个易受攻击的插件，则webhook机制可以利用它。在上面的概念验证视频中，研究人员表明他们可以强制易受攻击的Jenkins服务器下载恶意J​​AR文件，在服务器上运行它，并为攻击者启动反向shell端点。

这一发现提醒人们，当CI/CD服务器部分对Internet开放时会产生风险。

“一个封闭的解决方案是拒绝来自SCM webhook服务的入站流量，但这通常会带来工程成本，”Gil说。“可以采取一些对策，比如在CI中设置安全身份验证机制、修补，并确保服务器中的所有操作都保存在日志中。”