阅读量:0
目录
一、概述
信息系统中的服务器、路由器、交换机、数据库、计算机终端以及各类软件系统，由于设计缺陷或管理操作失误，面临着极大的安全隐患和风险。云计算在操作过程中如果配置不当，也会给云计算服务带来极大的安全隐患。
二、ENISA云安全漏洞分析
ENISA（欧盟网络与信息安全机构）评估框架被视为NIST在欧洲的对应框架，它负责制订云计算的信息安全收益、风险与建议。ENISA确定了组织应该考虑的云安全相关的30多种风险漏洞类型，具体分布如下。
- V1：授权认证和计费漏洞。
- V5：虚拟化漏洞。
- V6：使用者间资源隔离缺乏产生的漏洞。
- V10：不能在加密状态下处理数据。
- V13：缺乏技术标准与标准解决方案。
- V14：缺乏代码托管协议。
- V16：缺乏控制漏洞评估过程。
- V17：可能在云内部发生的扫描。
- V18：使用者可能会对相邻资源越权访问。
- V21：合约没有写清楚责任归属。
- V22：跨云应用隐含相依关系。
- V23：服务水平协议可能会在不同利害关系人间产生互斥。
- V25：对用户不提供审核或认证。
- V26：认证计划不适合云端架构。
- V29：数据被存储在多个行政区域且缺乏透明。
- V30：缺少数据储存所在行政区的相关信息。
- v31：使用者条款缺乏完整性与透明度。
- V34：云服务提供商组织里的角色与责任定义不明。
- V35：云服务提供商组织里的角色职责实行不确定。
- V36：相关当事人知道太多非必要的细节。
- V37：不适当的物理安全处理。
- V38：错误配置。
- V39：系统或操作系统漏洞。
- V41：缺少或很差的持续运营与灾难恢复计划。
- V44：资产拥有权不确定。
- V46：可供选择的云服务提供商有限。
- V47：缺乏供应商冗余性。
- V48：应用程序漏洞或失策的补丁管理。
三、云计算相关系统漏洞
3.1 概述
漏洞是指系统硬件、应用程序、网络协议或系统安全策略配置方面存在的缺陷。漏洞可能导致攻击者在未授权的情况下访问系统资源或破坏系统运行，对系统的安全造成威胁。信息系统中的操作系统、应用软件、数据库、路由器、交换机、防火墙及网络中的其他硬件设备都不可避免地存在漏洞。
云平台上的漏洞形式主要有操作系统漏洞、数据库漏洞、虚拟化平台漏洞、云管理平面漏洞和不安全的API等形式。下面重点从云计算所特有的虚拟化平台漏洞、云管理平面漏洞、虚拟机漏洞和容器漏洞等方面进行介绍。
3.2 漏洞分析
3.2.1 Hypervisor漏洞
Hypervisor是一种运行在物理服务器和操作系统之间的中间层软件，可以允许多个操作系统和应用共享一套基础物理硬件。Hypervisor又称为虚拟机监视器，可以将其看作虚拟环境中的“元”操作系统，它可以协调访问服务器上的所有物理设备和虚拟机。历史上曾经出现过的Hypervisor高危漏洞有下述几个。
3.2.1.1 CVE-2018-16882
Linux Kernel KVM Hypervisor内存错误引用漏洞。
Linux Kernel是美国Linux基金会发布的操作系统Linux所使用的内核。KVM Hypervisor是其中一个基于内核的虚拟机。Linux Kernel中的KVM Hypervisor存在内存错误引用漏洞，攻击者可利用该漏洞造成拒绝服务（主机内核崩溃）或获取权限。
3.2.1.2 CVE-2017-17563
Xen Hypervisor内存破坏漏洞。
Xen是英国剑桥大学开发的一款开源的虚拟机监视器产品。该产品能够使不同和不兼容的操作系统运行在同一台计算机上，并支持在运行时进行迁移，保证正常运行并且避免宕机。Xen 4.9.X及之前版本中的Hypervisor存在内存破坏漏洞。攻击者利用该漏洞造成拒绝服务（主机操作系统崩溃）攻击效果。
3.2.1.3 CVE-2010-1225
Microsoft Virtual PC Hypervisor Virtual Machine Monitor安全绕过漏洞。
Windows Virtual PC是Microsoft虚拟化技术，Microsoft Virtual PC Hypervisor Virtual Machine Monitor存在安全绕过漏洞，攻击者可以利用这个漏洞绕过内存保护机制，获取敏感信息。
3.2.2 虚拟机漏洞
虚拟机逃逸指的是突破虚拟机的限制，实现与宿主机操作系统交互的一个过程，攻击者可以通过虚拟机逃逸感染宿主机或者在宿主机上运行恶意软件。
虚拟机技术的主要特点之一是隔离，如果虚拟机A越权去控制虚拟机B，则存在安全漏洞。当前CPU可以通过强制执行管理程序来实现内存保护，通过安全的内存控制规则来禁止正在使用的内存看到另外一台虚拟机。历史上曾经出现过的虚拟机相关高危漏洞主要有下述几个。
3.2.2.1 CVE-2019-14835
QEMU-KVM虚拟机到宿主机内核逃逸漏洞。
Red Hat Enterprise Linux(RHEL)是美国红帽(Red Hat)公司的一套面向企业用户的Linux操作系统。QEMU-KVM虚拟机到宿主机内核存在逃逸漏洞。攻击者通过使用该漏洞可能导致虚拟机逃逸，获得在宿主机内核中任意执行代码的权限。
3.2.2.2 CVE-2019-5514
VMware Fusion虚拟机端远程代码执行漏洞。
VMware Fusion是VMware公司出品的一款适用于Mac操作系统的虚拟机软件。VMware Fusion虚拟机端存在远程代码执行漏洞，攻击者可通过VMware Fusion在本地启动的WebSocket API接口来在所有已安装VMware Tools的虚拟机上利用该漏洞执行任意代码。
3.2.2.3 CVE-2013-5973
VMware ESX和ESXi虚拟机文件描述符本地拒绝服务漏洞。
VMware ESXi是一款免费虚拟机解决方案。VMware ESX和ESXi处理某些虚拟机文件描述符时存在安全漏洞，允许拥有“Add Existing Disk”权限的非特权vCenter Server User获得对ESXi或ESX上任意文件的读写访问。在ESX上，非特权本地用户可对任意文件进行读写访问，修改某些文件允许宿主机重启后执行任意代码。
3.2.2.4 CVE-2003-1134
Sun Microsystems Java虚拟机安全管理器拒绝服务攻击漏洞。
Java 2安全管理器(Security Manager)是针对系统完整性和安全性进行检查的工具。Java 2安全管理器的实现存在问题，远程攻击者可以构建特殊的类并运行，会由于NULL指针异常而导致JAVA虚拟机崩溃，因此可利用这个漏洞对Sun Java虚拟机进行拒绝服务攻击。
3.2.3 OpenStack漏洞
OpenStack是一个开源的云计算管理平台项目，是一系列软件开源项目的组合。它是由NASA（美国国家航空航天局）和Rackspace合作研发并发起，以Apache许可证（Apache软件基金会发布的一个自由软件许可证）授权的开源代码项目。
OpenStack为私有云和公有云提供可扩展的弹性云计算服务，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。近几年历史上曾经出现过的OpenStack相关高危漏洞主要有下述几个。
3.2.3.1 CVE-2020-9543
OpenStack Manila越权漏洞。
OpenStack Manila 7.4.1之前版本、8.0.0版本至8.1.1版本和9.0.0版本至9.1.1版本中存在该安全漏洞。攻击者可利用该漏洞查看、更新、删除或共享不属于它们的资源。
3.2.3.2 CVE-2019-10141
openstack-ironic-inspector SQL注入漏洞。
Openstack-ironic-inspector是一款硬件检测守护程序。该程序主要用于检测由OpenStack Ironic管理的节点的硬件属性。Openstack-ironic-inspector中的'node_cache.find_node()'函数存在SQL注入漏洞，其源于基于数据库的应用，缺少对外部输入SQL语句的验证，攻击者可利用该漏洞执行非法SQL命令。
3.2.3.3 CVE-2018-14620
Red Hat Openstack不安全检索漏洞。
Red Hat OpenStack是美国红帽(Red Hat)公司的一套开源IaaS解决方案。该方案支持私有云、公有云和混合云的创建和管理。Openstack-rabbitmq-container和Openstack-containers都是其中的容器组件。Red Hat Openstack 12版本、13版本和14版本中的Openstack-rabbitmq-container和Openstack-containers存在安全漏洞，该漏洞源于OpenStack RabbitMQ容器镜像在生成阶段通过HTTP不安全地检索rabbitmq_clusterer组件。攻击者可利用该漏洞向镜像生成器提交恶意代码并将其安装在容器镜像中。
3.2.3.4 CVE-2017-16613
OpenStack Swauth身份验证绕过漏洞。
OpenStack是NASA和美国Rackspace公司合作研发的一个云平台管理项目。OpenStack Swauth是其中的一个授权系统。OpenStack Swift是一个用于检索大量数据的云存储软件。OpenStack Swauth 1.2.0及之前版本中的middleware.py文件存在安全漏洞。当使用OpenStack Swift及之前版本的软件时，攻击者可通过向请求的X-Auth-Token包头注入令牌来利用该漏洞绕过身份验证。
3.2.4 容器漏洞
容器是一种轻量级的虚拟化技术，它提供一种可移植、可重用且自动化的方式来打包和运行应用。容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护。现在比较流行的工具是Docker和Kubernetes(K8S)。
容器安全问题主要包括下述几个方面。
3.2.4.1 容器镜像风险
容器镜像可能存在安全漏洞、镜像配置缺陷、恶意软件植入、未信任镜像及明文存储的风险。
3.2.4.2 容器镜像仓库风险
包括与镜像仓库的不安全连接、镜像仓库中的镜像过时和不完备的认证机制。
3.2.4.3 容器编排工具风险
包括管理访问权限不受限制、未经授权的访问、容器间网络流量隔离效果差、混合不同敏感级别的工作负载、编排节点的可信问题。
3.2.4.4 容器实例风险
包括运行时软件中的漏洞、容器的网络访问不受限制、容器运行时配置不安全、流氓容器。
3.2.4.5 容器主机操作系统风险
包括攻击面大、共享内核、主机操作系统组件漏洞、用户访问权限不当、篡改主机操作系统文件等风险。
通常，针对容器云的攻击主要是由外部恶意用户和内部恶意管理员从网络侧发起攻击，攻击对象主要包括容器化微服务网络攻击、容器云组件漏洞攻击、容器镜像仓库攻击、基于硬件管理接口缺陷的攻击和基于API接口缺陷的攻击等。
四、云安全相关配置错误
4.1 云安全常见配置错误
云安全的常见配置错误主要有以下五个突出方面。
4.1.1 存储访问
在存储桶方面，许多云计算用户认为“经过身份验证的用户”仅涵盖那些在其组织或相关应用程序中已通过身份验证的用户。“经过身份验证的用户”应是指需要身份验证的任何用户。由于这种误解以及由此导致的控件设置错误配置，存储对象最终可能完全暴露给公共访问环境。因此要安全设置存储对象的访问权限，以确保只有组织内需要访问权限的人员才能访问它。
4.1.2 密码、密钥等的管理
诸如密码、API密钥、管理凭据和加密密钥之类的信息是至关重要的，至今已经发生过许多上述信息在配置错误的云存储桶、受感染的服务器、开放的GitHub存储库甚至HTML代码中公开可用的安全事件。针对这种风险的解决方案是维护企业在云中使用的所有机密清单并定期检查这些敏感数据的安全防护状态。
4.1.3 禁用日志记录和监视
企业云团队中的安全负责人应该负责定期查看此项配置，并标记与安全相关的事件。存储即服务供应商通常提供类似的信息，这同样需要定期审查。
4.1.4 对主机、容器和虚拟机的访问权限过大
企业没有使用过滤策略或防火墙，而将数据中心中的物理或虚拟服务器直接连接到Internet，例如暴露在公共互联网上的Kubernetes集群的ETCD（端口2379）。针对此问题要保护重要的端口并禁用云中旧的、不安全的协议。
4.1.5 缺乏验证
由于错误配置的发生，人们经常看到组织无法创建和实施错误配置鉴别系统来核查配置。无论是内部资源还是外部审核员，都必须负责定期验证服务和权限是否已正确配置和应用。企业还需要建立严格的流程来定期审核云配置。
4.2 微软Azure TOP 20漏洞清单
微软采取了大量的物理、基础结构和操作控制措施来帮助保护Azure，但也需要额外行动来保护工作负载。启用Azure安全中心可以加强云安全状况。
Azure安全中心是用于进行安全状况管理和威胁防护的工具。在Azure安全中心内，使用Azure Defender保护混合云工作负载。由于安全中心与Azure Defender集成，因此它可以保护在Azure、本地和其他云中运行的工作负载。该服务支持持续评估安全状况，使用Microsoft威胁情报功能防御网络攻击，并通过集成控件来简化安全管理。但是如果在Azure安全中心针对常见账户和一些初始配置没有正确设置安全策略或者缺失某些安全功能，就会产生安全风险和漏洞。
Azure的TOP20漏洞快速清单主要体现在以下方面。
- 可从Internet访问的存储账户。
- 允许不安全转移的存储账户。
- 特权用户缺乏多因素身份验证。
- 缺少用于加入设备的多因素身份验证。
- 免费基础版Azure安全中心缺少很多必要的安全功能。
- 具有基本DDoS保护的Azure虚拟网络。
- 未加密的操作系统和数据磁盘。
- 安全中心缺少电子邮件通知。
- Azure Monitor中缺少日志警报。
- Azure NSG入站规则配置为ANY。
- 公共IP配置为Basic SKU。
- 面向公众的服务使用动态IP。
- 可匿名读取访问的Blob存储。
- Azure AD中的访客用户数量过大。
- Azure AD中不安全的访客用户设置。
- 对Azure AD管理门户的无限制访问。
- Azure身份保护功能默认被禁用。
- Azure Network Watcher默认被禁用。
- 并非对所有Web应用程序流量都强制执行HTTPS。
- Azure安全中心的监视策略不足。
好了，本次内容就分享到这，欢迎大家关注《云计算安全》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！
