Azure 应用服务漏洞造成数万个源码库泄露


Wiz 研究团队在 Azure 应用服务中检测到一个不安全的默认行为,该行为暴露了使用“Local Git”部署的用 PHP、Python、Ruby 或 Node 编写的客户应用程序的源代码。Wiz 团队将该漏洞命名为“NotLegit”,并指出这一漏洞自 2017 年 9 月以来就一直存在,很可能已经被利用。

Wiz 于 2021 年 10 月 7 日向微软报告了这个安全漏洞。微软方面在 12 月 7 日至 15 日期间向一些受影响严重的用户发送了警报邮件,目前该漏洞已经得到缓解;但还有一小部分用户可能仍处在风险当中,建议应适当采取保护措施。

根据介绍,Azure App Service(也称为 Azure Web Apps),是一个基于云计算的平台,用于托管网站和 Web 应用程序。有多种方法可以将源代码和工件部署到 Azure App Service,Local Git 就是其中之一。用户通过 Azure App Service 容器启动 Local Git 仓库,并将代码直接推送到服务器上。

问题在于,在使用 Local Git 部署方法部署到 Azure App Service 时,git 存储库是在任何人都可以直接访问的目录 (/home/site/wwwroot) 中创建的;Wiz 将此举称为微软的一个“怪癖”。而为了保护用户的文件,微软会在公共目录内的 .git 文件夹中添加了一个"web.config"文件,以限制公共访问。但是,只有微软的 IIS 网络服务器可以处理"web.config"文件。因此对于同样使用 IIS 部署的 C# 或 ASP.NET 应用程序,此缓解措施是有效的。

但对 PHP、Node、Ruby 和 Python 这些部署在不同 Web 服务器(Apache、Nginx、Flask 等)中的应用而言,这一缓解措施就会无效,从而导致容易受到攻击。“基本上,攻击者所要做的就是从目标应用程序中获取"/.git"目录,并检索其源代码。”

影响范围包括:

  • 自 2017 年 9 月起,在 Azure 应用服务中使用“Local Git”部署的所有 PHP、Node、Ruby 和 Python 应用。
  • 自 2017 年 9 月起,在应用容器中创建或修改文件后,使用 Git 源代码部署在 Azure 应用服务中的所有 PHP、Node、Ruby 和 Python 应用。

对此,Microsoft 安全响应中心在一份公告中回应称,Wiz 报告的这一问题导致客户可能会无意中配置要在内容根目录中创建的 .git 文件夹,从而使他们面临信息泄露的风险。

“这与配置为提供静态内容的应用程序结合使用时,会使得其他人可以下载不打算公开的文件。我们已经通知了我们认为因此而面临风险的有限的一部分客户,我们将继续与我们的客户合作,确保他们的应用程序的安全。”

Customer Impact:

  • 在内容根目录中创建或修改文件后使用 Local Git 部署应用程序的 App Service Linux 客户会受到影响。
  • PHP、Node、Python、Ruby 和 Java 应用程序编码以提供静态内容:
    • PHP:用于 PHP 运行时的图像被配置为在内容根文件夹中提供所有静态内容。微软方面已经更新了所有 PHP 图像,禁止将 .git 文件夹作为静态内容提供,作为纵深防御措施。
    • Node、Python、Java 和 Ruby:对于这些语言,由于应用程序代码控制它是否提供静态内容,微软建议客户检查代码,以确保只有相关的代码被提供出来。

不过,并非所有 Local Git 用户都受到了影响。在应用程序中创建文件后,通过 Local Git 将代码部署到 App Service Linux 的用户是唯一受影响人群。且 Azure App Service Windows 不受影响,因为它在基于 IIS 的环境中运行。

微软为此采取的具体解决措施为:

  • 更新了所有 PHP 图像以禁止将 .git 文件夹作为静态内容提供,作为纵深防御措施。
  • 通知因激活本地部署而受到影响的客户,并提供有关如何缓解问题的具体指导。还通知了将 .git 文件夹上传到内容目录的客户。
  • 更新了安全建议文档,增加了有关保护源代码的部分。同时更新了本地部署的文档。

由于报告了这一漏洞,Wiz 方面还获得了来自微软的 7500 美元赏金,但该公司计划将这笔资金捐献出去。


相關推薦

2023-09-20

研究人员报告了一起发生在微软 AI GitHub 存储库上的数据泄露事件,其中包括 3 万多条内部 Microsoft Teams 消息的泄露;而这一切都是由一个配置错误的 SAS 令牌所引起。 Wiz 指出,数据泄露源于微软人工智能研究小组下的一个名为

2023-11-01

安全保护义务,部署的ElasticSearch数据库存在未授权访问漏洞,造成部分数据泄露。 北京市网信办依据《中华人民共和国数据安全法》第四十五条第一款规定,对三家企业分别作出责令改正,给予警告,并处5万元罚款的行政处

2023-01-29

表示,此次 Yandex 被泄露的代码使黑客有可能识别出安全漏洞,并创建有针对性的漏洞利用,这只是时间问题。

2021-11-16

t”(以下简称 ATW)是10月底我们报道的网传 SonarQube 平台漏洞被利用,大量源码泄露事件中的攻击者,但此次攻击并未得到博世的任何回应,ATW 也只能草草收场,陆陆续续地在 raidforums 论坛公布一些偷来的源码资料。而11月11日

2023-10-09

- FreeBuf网络安全行业门户】 3. 谷歌为攻击中利用的libwebp漏洞分配了新的最高CVE编号 谷歌已经为最近被攻击利用的libwebp安全漏洞分配了新的最高CVE编号(CVE-2023-5129)。这个零日漏洞在两周前修补过。【VMware Aria Operations for Networ

2023-01-07

目前可用的信息,未经授权的访问并不是由 Slack 固有的漏洞造成的」。 作为全球最知名的通信平台,被黑客盯上也是非常正常的一件事情。在 2015 年,Slack 受到了连续多日的网络攻击,当时黑客闯入其用户资料数据库,获取了

2023-07-26

参与组织比有执法部门介入的组织平均多经历了 33 天的漏洞生命周期。且相较而言,选择让执法部门介入的勒索软件受害者平均节省了 47 万美元的违规成本。尽管如此,研究中仍有 37% 的勒索软件受害者,在被勒索软件攻击

2021-12-17

继 CVE-2021-44228 和 CVE-2021-45046 之后发现的第五个 Log4Shell 漏洞。 距离 Apache Log4j “核弹级”漏洞的公开已过去将近一周,在此期间被记录的漏洞总共有两个,分别是 CVE-2021-44228 和 CVE-2021-45046。针对漏洞的补丁版本也早已发布

2021-12-23

的网络攻击,该攻击基于此前我们报导的 Apache Log4j 相关漏洞。强烈的网络攻击导致比利时国防部的一些活动瘫痪,如邮件系统就已经停机了好几天。 比利时相关发言人奥利维尔·塞维林 (Olivier Séverin) 表示:“国防部在周四

2022-08-29

这是一个用于识别加密制品(cryptographic artifacts)中常见漏洞的项目。 Paranoid 支持测试多个加密制品,其中包括如数字签名、通用伪随机数和公钥,以识别由编程错误或使用弱的专有随机数生成器造成的问题。 根据 Google 官

2021-12-16

Log4j 中近日被曝出了一个远程代码执行漏洞 CVE-2021-44228,对众多组织都造成了影响。对此,网络安全专家认为,鉴于该漏洞的普遍性和易于利用性,将需要花费数百年的时间才能完全解决这一隐患。而这数百年将会有多少程序

2022-06-01

减少缓冲区溢出和 use-after free (UAF) 等与内存相关的安全漏洞。数据表明,这些漏洞占所有软件安全漏洞的 70%。 auto* foo = new Foo(); delete foo; // The memory location pointed to by foo is not representing // a Foo object anymore, as the object has been dele

2021-11-12

较之下,官方版本的软件耗时多年、资金投入巨大,但却漏洞百出,已经引发多次不满。 拉锯战最终上升到对于瑞典政府数字化转型和开源协作方式的讨论上,民间的声音呼吁用开源的方式打造高度数字化工具,服务社会。

2021-12-20

Apache Log4j 的 2.0-alpha1 到 2.16.0 版本存在新的漏洞 CVE-2021-45105 ,此漏洞评分 7.5 ,且在刚发布的 Log4j 2.17.0 (Java 8) 中得到了修复。如果把安全公司 Praetorian 发现的第三个信息泄露漏洞也算进去,这应该是 Log4j 的第四个漏洞了。