探索云安全面临的常见威胁

文章目录

  • 全域可写的亚马逊S3存储桶
    • Docker
    • AWS Lambda
    • Kubernetes
  • 凭证管理不当

随着云服务的采用和普及,企业需要知道如何去保护企业的网络环境,本文对于云上会遇到的常见风险做了梳理,并为企业提供相关的解决方案。

如今,企业上云的数量已经稳步增加,中小企业青睐于其物理基础设施的经济性选择,而大企业则喜欢充分利用云服务的灵活性。然而,现在他们也都面临了一个挑战,尤其是那些刚刚上云的企业,他们还并不熟悉云上业务的运作方式、与纯本地系统的的差异。云设置经常不仅仅只涉及一个设施,经常要和物理数据中心想结合。

因此,这个挑战会延伸到安全层面,当云安全部署不充分或者对于配置参数不熟悉时,会存在许多风险。许多因素会导致工作负载和应用程序暴露在网络上招致攻击,包括错误的配置、技术的合理使用、运营经验和云系统防护,甚至是对于部分研发人员和云工程师的风险忽视。云系统的组成因素在很多方面是相互交织的,这会导致潜在攻击媒介难以追踪。对于刚开始使用云平台和服务的IT安全人员来说,安全这个任务十分艰巨。

2-AWS-01.jpg

2-AWS-01.jpg

在《解密Web云安全威胁》一文中,我们提供了在企业上云或者使用云服务时面临的威胁和风险案例。不管是云平台还是云服务,结果发现配置错误一直是云安全主要的陷阱之一,而且还会对订阅云服务的企业和托管在云上的软件用户有所影响。

全域可写的亚马逊S3存储桶

AWS凭借其多种产品,现在已经成为云行业的主要参与者。在AWS稳定版的产品中,Amazon S3或许是最受欢迎的,像Netflix、Reddit和Pinterest这些企业都在用它的基础设施。

我们在研究Amazon S3存储桶时看到的一贯趋势是,许多组织将它们放置在全域可写中,这是一种错误配置,允许未经授权的用户写入存储桶。比较知名的例子比如《洛杉矶时报》,该杂志之前有一个网络控制列表(ACL),该列表配置允许公众将访问路径写入存储桶中,该存储桶托管在其一个凶杀报告的网站上。攻击者可以在JavaScript代码中注入加密挖矿程序。

遥测数据还表明,对一些全域可写的存储桶网站攻击大部分发生在2019年间,同时还涉及一些恶意代码注入攻击,最终以网站表单形式提取数据。我们遇到的另一个问题是存储在Amazon S3存储桶中的恶意文件归类。大部分恶意文件使用旧的路径寻址方案。这意味着存储桶使用通用的Amazon S3主机名,而不是虚拟存储方案,在虚拟托管方案中,存储桶的名称包含在主机名中。这会给安全筛选器带来问题,因为阻止使用路径方案的恶意网站的主机名也同样会阻止其他非恶意站点。

云上可用的第二项主要服务是计算,目前这些服务主要集中于容器技术。在过去几年中,像一般的云细分市场一样,容器的采用率也很高。Docker、Kubernetes和AWS Lambda之类的软件推动了容器技术的发展,为希望简化其开发操作的企业提供了轻便高效的云部署。但是,配置失误或错误很常见,这些错误配置的系统有受到攻击的风险。

微信图片_20200422112438.png

微信图片_20200422112438.png

Docker

交付加密货币挖矿不断增加,一直困扰着Docker用户,这也是因为暴露在网络上的Docker容器所致。挖矿会严重影响用户的计算机,并且因自动扩展的云部署的CPU利用率过高而造成金钱损失。

攻击者有多种技术将挖矿代码注入未加密的Docker服务器。最简单的方法是直接在包含代码的映像中安装加密挖矿程序。另一种方法就是在启动过程中使用类似Ubuntu的常用基础映像来安装挖矿软件。

微信图片_20200422112454.png

微信图片_20200422112454.png

AWS Lambda

AWS Lambdas是无服务器事件驱动平台,可为应用程序提供轻量级且经济高效的解决方案,无需设置使用模式。一个常见的误解是Lambda受白帽保护,不能直接检索函数名。这种误解通常会导致未经适当身份验证的情况下执行功能。

但是,攻击者可以使用多种方法找到Lambda,例如,使用嗅探器侦听网络流量,或者通过检查Lambda使用并运行API网关站点的源代码。如果没有安全的Lambda身份验证,敏感信息有暴露的危险。

另外,由于开发人员的编码方式不同,在给定不正确的参数时,许多基于Python的Lambda函数会打印堆栈跟踪,这可能导致攻击者了解Lambda配置的基础信息。

微信图片_20200422112458.png

微信图片_20200422112458.png

Kubernetes

Kubernetes是一个用于管理容器工作负载的开源容器编排平台。我们使用Shodan发现2019年1月有32000台Kubernetes服务器暴露在网络上。与其他配置错误的例子一样,恶意分子可以利用网络公开访问Kubernetes服务或其任何组件。

Kubeletes

Kubernetes使用其Kubeletes子组件的API来管理每个节点中的容器。在旧版本1.10之前的Kubernetes中,Kubelet公开了数据端口10255和控制端口10250,这两个端口均可被利用。滥用控制端口更为明显,比如可用于安装加密货币挖矿软件,且端口10255可能包含潜在的敏感信息。

etcd

Etcd是一个分布式和复制的键值存储,充当Kubernetes的主要数据存储。它负责存储Kubernetes安装配置,并提供服务发现的存储后端。除了Kubernetes,其他应用程序(例如CoreDNS和Rook)都使用etcd。如果将其用作数据存储,则公开暴露的etcd可能会泄漏敏感数据,包括用于服务器和应用程序的凭据。我们使用Shodan发现了2400多个暴露的etcd服务器,包含Kubernetes和其他软件的混合。

凭证管理不当

尽管凭据使用经常被忽略,但却是云计算最重要的方面之一。由于企业无法像数据中心一样在物理上保护云系统,因此对凭证安全性的需求就变得更大。在保护凭据方面面临的一个挑战是许多流程通常需要访问身份验证数据和其他资源,这意味着用户需要保护数据和凭据免受泄露。

程序员经常犯的一个错误是,他们会无意间在GitHub等公共存储库上泄露凭证信息。有时会在网上发布的代码段中找到诸如API密钥之类的敏感数据,然后攻击者就可以使用这些代码片段来接管凭据使用的帐户,随后再进行犯罪活动,例如盗窃客户数据,在暗网出售这些数据。

我们发现的另一个问题是,许多经验不足的程序员经常遵循错误的云教程,其中许多教程鼓励在代码本身内部对凭证进行硬编码。如果代码发布到任何人都可以访问的存储库中,这将成为一个问题。

随着云服务采用率的增长,企业需要充分了解其面临的威胁,并做好适当的准备,保护其云系统。如果没有可靠的安全实施措施,云技术的好处就无法实现。本文研究分析的威胁并未涵盖云中所有潜在的威胁和风险,包括一些最重要的威胁。对于需要了解云的结构以及保护云的策略的IT和安全人员而言,这尤其重要。

*参考来源:trendmicro,Sandra1432编译,转载请注明来自FreeBuf.COM

发表评论

邮箱地址不会被公开。 必填项已用*标注