最后更新于2019年5月10日(星期五)16:56:45 GMT

Today (April 10, 2018)我们分享了Rapid7产品和支持服务中已经修复的六个漏洞. 你不需要采取任何行动:所有的问题都已经解决了. 我们披露这些漏洞是为了保持透明度, 感谢那些花时间负责任地报告安全问题的人, 并提供一些安全问题的提醒，您应该在自己的组织中进行审计.

动态生成的web服务器访问策略

为web服务器生成配置设置是一个很好的自动化领域, 根据需要，可以将策略和对策略的更改推广到大量服务器，而无需手动开销. However, 这也意味着如果遗漏了错误配置, 大量资产可能面临风险.

web服务器访问策略配置错误 insight.theredpillbooks.com 是否发现可能会泄露HTTPS数据. The Access-Control-Allow-Origin 策略设置使得处于中间人(MITM)位置的攻击者能够访问站点内需要对目标用户进行身份验证的资源. 具体来说，HTTP请求 insight.theredpillbooks.com 允许(通过CORS， 跨域资源共享)来访问域内的HTTPS资源. 此问题是不当访问控制(CWE-284)，有一个整体 CVSS v3得分6.3.

这个漏洞确实有一些重要的需求可以利用, 包括用户交互和具有MITM位置. 在一个示例场景中, 攻击者首先会在他们认为目标用户可能访问的网站中嵌入iframe. 一旦打开，该iframe中的JavaScript将作为目标用户发出请求 http://insight.theredpillbooks.com，包括需要对用户进行身份验证的资源和操作.

Rapid7没有证据表明这个漏洞被利用了. 已经存在的会话cookie需求可能会阻止上述场景的成功. 通过更改CORS策略的生成过程，只允许来自现有白名单域的HTTPS源请求，解决了错误配置.

Rapid7热烈感谢Jens Mueller 负责任地报告此漏洞以及在缓解期间与我们合作. 有关这类常见漏洞的更多信息，请参见 这篇文章由Jens撰写.

Password resets

当AppSpider企业用户请求重置密码时, 发送的电子邮件中包含了新生成的明文密码. 因为电子邮件不是一个安全的通信渠道, only secure, and expiring, url应该通过电子邮件发送，以允许用户重置密码. 此问题是“凭据保护不足”(CWE-522)，有一个整体 CVSSv3得分为4分.7.

在剥削方面, 其复杂性和风险都很高:恶意行为者必须能够拦截电子邮件, 但是能够以那个用户的身份登录并以他们的身份执行操作.

这个问题在版本3中得到了解决.8.189，于2017年11月部署. 重置密码不再以纯文本形式发送，而是包含一个有效期为24小时的URL. 注意，这个补丁被部署到AppSpider Enterprise的云实例中, 所以用户不需要采取任何行动来解决这个问题.

CSRF protection

在曝光版本之前 6.4.66，与自动操作管理相关的端点缺乏CSRF保护. 如果expose管理员创建或修改了自动操作, 处于特权网络位置的恶意行为者可以拦截请求并将修改后的版本发送到expose服务器. 这是由于对HTTP请求源的验证不足造成的, 使受影响的端点容易受到跨站点请求伪造(CSRF)攻击.

Rapid7 issued CVE-2017-5264 对于此漏洞. 它是CSRF (CWE-352)，有一个整体 CVSSv3得分为3分.1. 该漏洞已被修复 曝光版本6.4.66. Please note:如果您运行的是版本大于6的expose.4.66号，你应该升级到6号.4.如果可能的话，66或更新.

热烈感谢 Shwetabh Vishnoi for 负责任地报告此漏洞以及在缓解期间与我们合作.

测试服务器公开

几台内部易受攻击的测试机器被暴露在互联网上. 他们故意易受攻击，以便在PCI认证期间测试扫描系统, 但是，不必要地将它们暴露在互联网上可能会危及这些服务器，并对第三方进行恶意重用.

这些系统本不应该在这个时候运行, 但更大的问题是，无论如何，他们都不应该暴露在互联网上. 此错误配置是违反安全设计原则(CWE-657). 这个问题已经通过加强访问控制得到解决, 除非必要，否则禁止访问，并且在需要外部访问时通过VPN.

这个问题是通过shadowserver的警报报告给Rapid7的.关于rapid7属性的IP地址运行的网络服务暴露在互联网上. Rapid7热烈感谢 ShadowServer基金会 因为他们主动负责地报告了这个漏洞.

DNS和CloudFront

When using Amazon CloudFront, 通常在CloudFront中配置一个备用域名，以便在更熟悉的域下提供资源. 然后，必须为所需域添加指向CloudFront的DNS条目(CNAME记录)，以便正确路由请求.

为了安全地停用CloudFront发行版， both 这些步骤必须回滚:必须在CloudFront中删除备用域名，并且必须删除DNS CNAME项, 或者更改为不指向CloudFront. 如果只有备用域名在CloudFront中被删除，但DNS CNAME仍然指向CloudFront, 然后，任何CloudFront用户都可以将新的CloudFront分布与DNS CNAME条目相关联. 而被劫持的DNS CNAME将指向不同的CloudFront分发主机名, 该主机名仍将解析为CloudFront IP地址(类似于不同虚拟主机条目都来自同一IP的概念)。. 一旦请求到达CloudFront, 它将被路由到与备用域名相关联的分发.

在最近的一个案例中，DNS CNAMEs help.ges.r7ops.com and help-metasploit.ges.r7ops.com 指向CloudFront，但当时没有CloudFront发行版与这些域相关联. 而Rapid7没有对这些域的外部引用, 仍然指向CloudFront的DNS cname通过利用域名的真实或感知的积极声誉引入了网络钓鱼风险.

对此场景进行扩展:恶意行为者可以创建一个新的CloudFront分布，并将其与已经指向CloudFront的任何域相关联, 除非CloudFront分布与当时的域相关联. 这允许在攻击者的控制下链接到看起来很真实的url. 他们还可以将Amazon S3存储桶与他们新的CloudFront发行版关联起来，从这些url提供文件. 这样就可以通过添加SSL/TLS域验证证书, for example, Let’s Encrypt, as the ACME(自动证书管理环境)协议 用于验证域所有权只需要能够在被检查的域下通过HTTP提供文件. 这将使恶意url看起来更加可信.

通过将备用域与CloudFront中的分发重新关联，解决了此漏洞. However, 如果记者没有在CloudFront上发布该关联的话, 相反，这种联系是由攻击者建立的, 唯一的选择是删除DNS cname.

Rapid7热烈感谢Fredrik Nordberg Almroth 负责任地报告此漏洞以及在缓解期间与我们合作.

DNS和AWS弹性负载均衡器

在这个主题的另一个变体中, 指向已失效的AWS ELB实例的DNS条目也会带来类似的风险. 然而，至少目前看来，这个漏洞还不可能被利用.

在报告的特定情况下，CNAME记录 data.userinsight.theredpillbooks.com 指出AWS ELB实例不再活动并且缺少A记录. 如果恶意参与者可以使用与CNAME目标匹配的URL建立活动ELB实例, 各种攻击都是可能的, e.g. 可信的网络钓鱼尝试.

目前这是不可能的, however, 因为无法为AWS elb定制或指定所需的URL. 这种情况在未来可能会改变, 而且孤儿ELB也有可能被分配给其他人. Thus, 就像CloudFront的案例一样, 定期扫描DNS条目以查找此类断开连接是最安全的, 把它们去掉，避免任何风险.

此问题已通过删除受影响的DNS记录得到解决. 热烈感谢 Vineet Kumar for 负责任地报告此漏洞以及在缓解期间与我们合作.

摘要:外卖

  • 在为web服务器自动生成和部署访问策略设置时，请谨慎使用需要仔细的审计，以防止初始配置错误无声地扩展到其他服务器，并将其他基础设施置于危险之中.
    • 具体来说，应该将CORS策略设置为只允许来自现有白名单域的HTTPS请求.
  • 电子邮件不是一种安全的通信渠道. 密码重置邮件只应使用安全, and expiring, 允许用户重置密码的url.
  • 审计您的代码，以正确验证HTTP请求的来源:这是避免CSRF的重要一步. The OWASP CSRF小抄表 有关于CSRF审计和防御方法的丰富信息.
  • 审计现有的和新的测试服务器:它们需要能被互联网访问吗? 如果是这样，尽可能让他们使用VPN.
  • All DNS records, including CNAMEs, 指向CloudFront的点必须要么注册到一个活跃的CloudFront发行版，要么删除. 确保有适当的流程来审查和删除服务退役时的这些记录.
    • As of April 4, 2018, 当用户从CloudFront分发中删除备用域名时，亚马逊会在AWS CloudFront控制台中通知用户, 提醒他们相应地更新DNS条目(从而避免暴露于上述劫持)。. 这是不久之后添加的 最近的一项研究 wherein over 2,000 domains, 包括那些主要组织, 被劫持(在被转移回亚马逊之前).
    • 您可以通过广泛的服务提供商找到有关子域名接管的更多信息 in this article.
  • 定期审核所有现有的DNS条目，查找孤立的记录, i.e. 那些指向不能解析的名称或仅仅指向无响应地址的名称. 这些发现应予以审查, 如果断开连接是由于基础设施问题，并且仍然需要记录, 否则就会被移除.