该漏洞滥用 Active Storage
Ruby on Rails（以下简称“Rails”）Web 应用框架中曝出一个新的严重漏洞 CVE-2026-66066，它可能将一张看似无害的图片变成通往你秘密的大门。
该 CVE 于 7 月 30 日披露，严重性评分为 9.5 分（满分 10 分），对运行着处理用户上传图片的 Rails 应用的企业构成重大风险。
该漏洞被命名为“KindaRails2Shell”，针对开源框架中过度信任的 Active Storage 组件，可让未认证攻击者读取敏感文件，或升级为远程代码执行（RCE）。
该问题已在 Active Storage 7.2.3.2、8.0.5.1 和 8.1.3.1 版本中修复；运行 Rails 的企业应立即更新。
Beauceron Security 的 David Shipley 表示：“最‘完美’之处在于，攻击者可以上传一个实际上不是图片的‘图片’，而是一段能够窃取秘密的代码。”
攻击者拿到了城堡的钥匙
Ruby on Rails 是一个开源的服务端应用框架，用于构建全栈 Web 应用和应用程序编程接口（API）。
它受到开发者的欢迎，因为它具有可扩展性，易于学习和使用，支持快速应用开发，拥有一个由 1000 多名工程师组成的活跃社区来开发和维护它，并拥有一个近 200 万行预构建代码的庞大库。
CVE-2026-66066 专门针对 Rails 内置的 Active Storage 组件，该组件允许用户将文件上传到云服务或本地磁盘，并将其链接到应用程序。尤其值得注意的是，该漏洞利用了 Active Storage 与 libvips 图像处理库交互以生成图像的方式。
libvips 包含一些被称为“未模糊测试”（unfuzzed）的操作，这些操作没有通过模糊测试（fuzzing）技术进行加固，以抵御恶意输入。模糊测试会测试这些操作在哪里崩溃、泄漏数据，或以其他方式表现出异常行为。这使得它们在与不受信任的内容一起使用时并不安全，但 Active Storage 没有充分禁用这些操作。
SOCRadar 的 CISO Ensar Seker 解释说：“CVE-2026-66066 尤其危险，因为攻击者可能不需要账户或特权访问。”
攻击者可以利用这个不安全的管道，上传特制的文件，诱使 Active Storage 让他们访问 Rails 进程有权访问的文件，即使是应用处理环境中高度敏感的文件。
Seker 解释说，实际上，这可能暴露环境变量、Rails 应用密钥、数据库凭据、云访问密钥、API 令牌以及相关服务的凭据。
攻击者还可以获得 secret_key_base，它用于对 cookie、凭据和会话数据进行签名和加密。一旦 secret_key_base 被泄露，攻击者基本上就掌握了应用的钥匙。
Seker 说：“直接的漏洞是任意文件读取，但诸如 Rails 的 secret_key_base 等密钥被盗，可以将信息泄露变成更大范围的危害。”
根据应用的具体情况，攻击者可能伪造受信任的应用数据或会话，访问数据库和云服务，横向移动到相连系统中，或实现 RCE。
Seker 说，这种升级路径正是该漏洞被列为严重级别的原因。“一个看似普通的图片上传功能，例如个人资料照片、头像或缩略图生成器，都可能成为进入应用底层基础设施的入口。”
如何判断自己是否受影响
当应用配置为使用 libvips 进行 Active Storage 图像处理（自 Rails 7.0 以来的默认行为），并接受来自不受信任或未认证用户的图片上传时，就会受到影响。Seker 建议，企业应审计每一个内部和第三方应用，确认是否采用了这种配置，并立即修补 Rails 和 Active Storage。他们还应该检查所有接受图片的功能，包括头像、支持附件、产品图片和管理员的上传功能。
仅升级 Rails 并不足够，如果底层仍然使用较旧版本的 libvips，那么 libvips 必须升级到 8.13 或更高版本，他说。
Seker 指出，Rails 项目提供的取证指导和工具可以帮助企业确定应用是否存在漏洞，或文件是否可以被利用。同时，检查应用、代理、对象存储和图像处理日志中是否有可疑的上传或异常请求，也很重要。
此外，管理员应轮换 secret_key_base 以及 Rails 中可用的所有其他凭据，使活动会话失效，并调查下游系统中可能暴露的凭据。
Seker 说：“安全团队应将此视为潜在的秘密暴露事件，而不仅仅是补丁管理工作。”
不要信任图像处理管道
Seker 指出，复杂的图像库支持多种格式，并依赖众多解析器和第三方组件，造成广泛的攻击面。因此，这些库“应被视为不受信任的代码执行领域”。
他建议，图像处理应隔离在专用的沙箱、容器中，或限制在具有最低文件系统访问权限的工作进程中。不应有不必要的网络连接，也不应授予对应用文件或秘密的访问权限。应应用严格的允许列表，人工验证文件内容，上传文件在存储到应用目录之外之前应先进行扫描，然后再进行处理。
Seker 说，额外的控制措施应包括使用短生命期、范围受限的凭据，限制出站网络连接，监控依赖项和软件组成，以及进行自动化测试，以确认危险的编解码器或操作在升级后已被禁用。
他指出：“更广泛的教训是，各组织不能仅仅通过询问自己是否‘使用了 Rails’来评估风险。”他提醒说，两个运行相同 Rails 版本的应用可能因图像处理器、上传路径和操作系统包的不同，而具有非常不同的风险敞口。这使得对运行时配置、库和应用功能的可见性变得至关重要。
他还补充说，这一事件也证明了秘密轮换在漏洞响应中的重要性。“当一个漏洞允许任意文件访问时，安装补丁可以关闭入口，但并不会撤销可能已被复制的凭据。”
不要想当然地认为自己很安全
Beauceron 的 Shipley 指出，这个漏洞完美地展示了软件物料清单（SBOM）的用例，它可以加快发现易受攻击的软件并进行分类。除了隔离系统和打补丁，企业还可以采用智能 Web 应用防火墙监控和干预。
他说：“在任何严重漏洞中，你最不想听到的词就是‘任意代码执行’和‘远程代码执行’。这两个词都可能意味着坏消息。”
他还指出，这个案例中还有一个有趣的地方，即披露过程被劫持了。Rails 项目在计划披露之前近一个月，就发布了有关该漏洞的技术细节和取证工具，以帮助应用评估受影响情况并查找数据泄露证据，因为有多位研究人员对攻击进行了逆向工程，并发布了概念验证（PoC）代码。
Seker 指出，现在有了 PoC，“实质上增加了机会主义扫描和利用尝试的可能性”。
因此，他说：“即使组织没有看到明显的入侵迹象，也不应认为仅靠打补丁就能消除之前暴露的秘密所带来的风险。”
参考来源：
Ruby on Rails critical bug puts every image upload under scrutiny
https://www.csoonline.com/article/4205383/ruby-on-rails-critical-bug-puts-every-image-upload-under-scrutiny.html
关注 云栈社区，获取更多安全技术动态与漏洞解读。
发表于 3 小时前
|
查看: 3|
回复: 0
