德国研究员 Juraj Somorovsky、Mario Heiderich、Meiko Jensen、Jörg Schwenk、Nils Gruschka 和 Luigi Lo Iacono 在合著的一篇名为《你的云真的由你掌控吗——云管理界面的安全分析》的文章中讨论了 Amazon AWS 和 Eucalyptus 存在的安全漏洞，攻击者可以利用这些漏洞来完全控制受害者账户以及与之相关的存储数据。文章重点讨论了一种通过 SOAP 接口进行的 XML 签名攻击，并且揭露了额外两种跨站脚本（XSS）技术，攻击者可以利用这些技术从 web 管理界面侵入用户账户。Amazon 和 Eucalyptus 在这些漏洞被利用前对其进行了修复。
在传统的 XML 签名攻击中：
原始 SOAP 消息体元素会被转移到 SOAP 安全消息头的一个新添加的伪造包装器元素中。请注意，利用消息签名中的标记符属性 Id=“body”，签名还是指向此前被移动的消息体。因为消息体元素本身没有被修改（只是简单转移了位置），所以从密码学角度签名任然有效。其后，为了使 SOAP 消息的 XML 模式兼容，攻击者会更改本来指向原始 SOAP 消息体的标识号（比如，他修改为 Id=“attack”）。这样就可以开始向空 SOAP 消息体里填充伪造的消息内容了，由于签名验证无误，那攻击者定义的任何一个操作都可以被有效地执行了。
传统的 XML 签名攻击至少可以有两种方式来对付 AWS 和 Eucalyptus，其中一种对时间不敏感。这种攻击尤其在对时间戳不敏感的情况下几乎不需要满足什么前提条件，所有攻击者唯一要做的就是提供一个有效、经过签名的 SOAP 请求消息，而这可以通过 AWS 开发者在 AWS 支持论坛发布帮助请求直接获取。文章的几位作者抱怨造成这种安全漏洞的原因是 SOAP 处理框架中对任务模块的拆分。由于任务模块化，相同的 XML 消息将以不同的方式在不同的模块中访问，消息的完整性从没有得到过验证。作者们建议：
最好的对策办法就是增强签名验证功能和业务逻辑之间的接口。使用这种方法，签名验证可以紧跟在返回的布尔值后再加一些已签名数据的位置信息。业务逻辑再决定将要处理的数据是否已被签名。
作者们还揭露了两种脚本注入攻击，其中一种的目标直指 AWS 管理控制台用户，而另一种则利用了 amazon 商城界面和 AWS 之间的共享证书。前者利用了证书下载链接中的 GET 参数——用户用此链接下载 Amazon 签署的 X.509 证书。尽管如此，这种攻击的前提条件要求相当高，不仅包括使用 UTF-7 对注入的脚本进行编码，使其能够避开服务器逻辑从而对标准的 HTML 字符编码，还需要特定 IE 版本中某些特性的支持。第二种脚本注入攻击使用一种持续的跨站脚本攻击，利用了 AWS 为首次登录到 Amazones hop 界面的用户创建的登陆会话。这种攻击简单而有效：
攻击者必须要在某个商城物品、用户自创标签或其他实体上创建一个讨论主题。一旦主题创建成功，讨论主题的标题就会立刻显示而不会做任何特定编码，这样就给注入恶意 HTML 代码留出了空间。这使得我们能够加入一些脚本标签或其他活动标记来迫使用户代理在 www.amazon.com 域上执行 JavaScript。
文章研究人员与 Eucalyptus 和 Amazon 的安全工作人员一起合作，在文章发表前就修复了这些漏洞。但就 Eucalyptus 或任何其他私有云部署的情况来看，任然存在不利因素：
修复该安全漏洞存在的难题在于：Eucalyptus 部署在数不胜数的私有化托管服务器上。因此，每个 Eucalyptus 管理员都必须手动更新其服务器版本。假设存在大量的设施（Eucalyptus 声称其客户超过 25000 个），那我们真的怀疑能否在短期内修复每台服务器上的攻击。理论上这是依赖私有云基础设施最大的不利因素之一。
文章最后的结论指出了这种安全隐患将造成的影响规模，它可能出现在任何已有的云服务上，因此至少文章中描述的“黑盒”方法学是很有必要的：
这表明了这类系统本身的复杂性为产生潜在的安全漏洞创建了一个大温床。由此看来，在不远的将来云控制界面很可能成为某些有组织犯罪团伙最感兴趣的攻击目标之一。我们发现的所有安全漏洞，其最重要的威胁不在于会对单个服务器或者公司造成影响，而在于可以立刻影响到整个相关的云用户。另外，针对基于 Web 的云控制界面的跨站脚本攻击会对整个云安全产生严重的影响。
注册/登录 InfoQ 发表评论