Intezer 公司的研究员在 Microsoft Azure 中发现了两个漏洞。它们位于流行的云服务 Azure App Services 中，影响 Linux服务器，使用云资源的企业组织机构应当对此注意。如攻击者能够访问服务器，则第一个漏洞可使他们接管 App Service 的 git仓库并植入可通过 Azure Portal 访问的钓鱼页面。第二个漏洞可导致在应用程序中已拥有低权限的攻击者升级为完整的代码执行权限，并触发第一个漏洞。研究人员已将这两个漏洞告知微软，后者已在本文发布前修复。
云迁移使得老旧的安全实践基本过时，因为系统管理员必须了解如何适应并防御这个新平台。云安全仍然是相对较新的概念，因此非常有必要研究和记录使用这些新服务器时产生的新攻击面。从某种程度而言，其基础设施在某些领域并未记录，并不像 Windows或 Linux 系统那样已经过安全研究员的审查。本文将说明从 Azure App Services 中找到的两个漏洞，具体而言它们位于 Linux App Services 管理组件 KuduLite中，另外还说明了 Azure App Service 的运作原理。
Azure App Services 是一款基于 HTTP 的服务，用于托管 Web应用程序，可从微软 Azure Cloud 和内部部署程序中找到。本文具体指的是云版本。App Services 使开发人员只需编写一款应用程序就可用作 HTTP，之后推送给 git。之后 Azure将处理所有繁琐的部署细节并提供 Azure管理的域名。开始使用 App Services 时，用户必须首先创建一个将由 App Services 使用的机器 App Service Plan。该机器的主要目的是托管 App Service 的容器。用户创建 App Service 后，Azure 将创建一个由两个容器节点（管理器节点和应用程序节点）组成的新的 Docker环境。该管理页面是由微软开源项目 Kudu提供的。在 Linux 系统上是由更少有人知道的姊妹项目 KuduLite 提供的。Kudu 示例托管在管理器节点上，而该应用程序本身托管在应用程序节点上。我们主要集中讨论 KuduLite变体的情况。KuduLite 实例为用户提供系统诊断信息，包括 Docker日志、设置和其它环境信息。如果用户选择在 Azure上托管 app 的 git，则它由该 Kudu服务管理。另外一个有用的功能是在 Kudu实例上运行交互 bash 的 Web 接口，以及SSH 到应用程序节点的另外一个 Web 接口（一个单独的 Azure项目 webssh）。该 app节点内部的应用程序以 root身份运行，而且我们可以以 root身份将 SSH 连接到该节点。然而，当访问 Kudu 实例时，我们是低权限用户：该用户仅和 /home进行交互，无法写入其它目录的文件中。有意思的是，这个实例中安装了 ClamAV。
在调查 webssh如何将 Web 接口连接到该应用程序节点的 SSH 服务过程中，我们注意到它使用了硬编码凭证“root:Docker!”，访问该应用程序节点：
由于该应用程序节点的 SSH端口无法从互联网访问，因此这样做并不会带来任何危险。之前我们注意到 KuduLite实例也运行 SSH，因此我们在 KuduLite 实例上使用了相同的实例并以 root身份登录：
需要注意的是，App Service KuduLite 的开发人员确保管理员仅能以低权限用户身份进行登录，因此我们了解到这并不在计划内。现在我们已经控制了 KuduLite，因此能够完全控制 SCM Web 服务器。我们可以监听用户向 SCM网页发出的 HTTP 请求、增加自己的页面，并将恶意 Javascript 注入用户网页。最初，我们尝试从 SCM用户的服务器请求中窃取他们的 cookie，然而我们很快发现一个 nginx 中间人在 cookie 到达 KuduLite 之前就从请求中删除 cookie。另外，这些 cookie具有一个 HttpOnly 属性，也就是说我们无法通过客户端浏览器上的 JavaScript 窃取这些 cookie。微软提供的缓解措施在限制该漏洞的潜在危害方面非常有效。尽管已存在缓解措施，攻击者仍然能够利用该漏洞带来损害。攻击者可利用该漏洞在本应是 SCM 网页的地方植入钓鱼页面。用户也可选择让 App Services 管理 git服务器，由 KuduLite 处理。攻击者之后还可向仓库添加恶意代码，实现持久性并传播给使用同样 git服务器的其它实例。
第2个漏洞：本地文件包含或 RCE
第2个漏洞：由 SSRF 最终引发 RCE
第二个漏洞存在于非常类似于 Kudu API 的 KuduLite API 中。该应用程序节点能够在无需任何访问验证的情况下向 KuduLite API 发送请求。当 Web app 中存在 SSRF漏洞时，这种情况的问题尤大。设法伪造 GET 请求的攻击者或能够通过 KuduLite VFS API访问该应用程序节点的文件系统。
它将使攻击者轻易窃取源代码和应用程序节点上的其它资产。设法伪造 POST请求的攻击者可通过命令 API在应用程序节点上远程执行代码。
相反，在 Windows 系统中，从应用程序节点发送到管理器节点上的数据包被释放。最终，攻击者可结合利用这两个漏洞，因为一旦他们通过第二个漏洞实现代码执行（通过 SSRF漏洞实现），就能够利用第一个漏洞。
云使得开发人员能够以极快的速度和灵活性构建并部署应用程序。然而，基础设施常常可能存在不受控的漏洞。在 App Services 的案例中，应用程序和另外一个管理容器共同托管，而且如本文所述，额外的组件会带来额外的威胁。我们将问题告知微软，后者快速证实并修复了这些漏洞。最为通用的最佳实践，运行时云安全是重要的最后一道防线，因为它在漏洞遭攻击者利用后检测恶意代码注入和其它内存威胁。有兴趣的读者可点击如下链接，进一步解释了预运行时和运行时安全的必要性：https://www.intezer.com/blog/cloud-security/complementing-your-cspm-with-runtime-cloud-workload-protection/。
https://www.intezer.com/blog/cloud-security/kud-i-enter-your-server-new-vulnerabilities-in-microsoft-azure/
题图：Pixabay License
本文由奇安信代码卫士编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 www.codesafe.cn”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的
产品线。
觉得不错，就点个 “在看” 吧~