OpenStack安全情况分析

OpenStack…

内容纲要

OpenStack安全情况分析

因为实验室项目,之前两周一直在看OpenStack漏洞,覆盖了近两年比较有代表性的一些漏洞。确实应该做一些前瞻、总结及知识性缺陷的补完。

大方向上,根据云计算安全威胁(CSA联盟)针对公有云安全几大问题:

(1)云资源的滥用和盗用
(2)不安全的 APIs
(3)服务商内部恶意的员工
(4)共享技术带来的漏洞
(5)获得对底层基础设施平台的访问
(6)数据丢失/数据泄漏
(7)帐号或服务劫持
(8)Unknown Risk Profile

所以说,延伸到OpenStack安全,公有云OpenStack安全威胁需求主要体现在OpenStack组件安全、API安全、共享技术带来的漏洞、安全配置。

总结时,从安全视角可以把组件大概分为两类,一类是核心组件,一类是边缘组件。

核心组件特征在于漏洞不易出现,不过一旦出现则影响较大,同时信息泄露之类的常规低危漏洞发生于核心组件亦具有较高价值。边缘组件相对易出现高危漏洞,但组件未必被采用至生产环境。故项目分析仍应以核心组件为主要导向,根据项目组件情况对非核心组件针对性挖掘。

各组件漏洞情况及初步分析

Nova

管理计算资源,负责虚拟机实例的所有活动,包括虚拟机创建、开机、关机、挂起、迁移等等操作。

编号 要素 简略分析
CVE-2020-17376 隔离失效 通过对先前经历过热迁移的实例执行软重启,用户可以访问到目标主机设备
CVE-2020-10731 配置缺陷 rnova_libvirt容器中没有启用SELinux。这个缺陷会导致sVirt(隔离机制)被所有正在运行的虚拟机禁用。
CVE-2019-14433 信息泄露 经过身份验证的用户的API请求外部异常而最终出现故障,则底层环境的详细信息可能会在响应中泄漏

Nova作为compute,个人感觉上是把物理机资源统筹成一个上一级的资源,所以说,它的统筹失效是漏洞的核心,或者用户访问下探到物理层,或者统筹过程中出现配置缺陷,或者底层的信息上浮到用户,对Nova“统筹力”的攻击,应该就是出现漏洞的可能。

Keystone

提供身份验证服务、用户的角色信息、服务规则和令牌服务。Keystone为其它组件提供了服务和管理API接口,后端可以接其它认证服务,比如使用LDAP服务做为认证服务。

编号 要素 简略分析
CVE-2020--12692 签名校验缺失 EC2 API没有针对AWS签名V4的签名TTL检查。
CVE-2020--12691/12689 提权可能 用户可以通过对管理的项目创建EC2凭据,逐步变成另一个用户。
CVE-2020-12690 越权可能 OAuth1访问令牌的角色列表默认忽略,可能会提供意外的升级访问。
CVE-2019-3683 分配权限过高 特定情况下分配权限高于实际欲分配权限。

Keystone作为认证中心,出现漏洞往往就是在权限上,可能权限没有经过校验,可能权限会被提升,可能会出现越权访问,可能分配权限不符合使用者预期。起认证作用的组件,核心在于其他组件认定其可信,对keystone权限的质疑,理应是可能发现漏洞的途径。

Swift

功能类似于一个分布式、可访问API的存储平台,可直接将它集成到应用程序中,或者用于存储VM镜像、备份和归档文件。

Swift近两年没有出现漏洞,目前共出现了11个漏洞:

CVE-2017-16613 Bypass
CVE-2016-0738 DoS
CVE-2016-0737 DoS
CVE-2015-5223 +Info
CVE-2015-1856
CVE-2014-7960 Bypass
CVE-2014-3497 XSS
CVE-2014-0006 +Info
CVE-2013-6396 +Info
CVE-2013-4155 DoS Overflow
CVE-2012-4406 Exec Code

DoS占3个,Bypass占两个,信息泄露占三个,其他类型都是单次出现,再加上近两年都没有出现,不建议在找到优秀的针对Swift漏洞挖掘方法论前过多倾注精力。

Horizon

Web管理面板。

编号 要素 简略分析
CVE-2020--29565 重定向 缺少对“next”参数的验证,可在Horizon中提供恶意URL并自动重定向。
CVE-2020--26943 RCE eval危险使用
12-17的18个CVE 危险等级普遍较低 13个XSS、3个逻辑相关问题、1个bypass一个

毕竟只是一个Web页面,有常规漏洞的点基本被审过很多次,CVE-2020-26943可能是唯一一个rce,而且Web漏洞的检测其实和整个OpenStack的漏洞检测有一定区别,根据漏洞情况分析,不建议过多精力投放到Horizon上。

Neutron

提供灵活地网络功能,为多租户环境下的每个租户提供独立的网络环境。

编号 要素 简略分析
CVE-2019--10876 DoS 一定情况的安全组配置可能会阻止Neutron在计算节点上配置网络
CVE-2019--9735 配置问题 iptables防火墙模块出现问题。一定配置下可阻止用户进一步安全配置
12-18的17个CVE DoS许多 DoS Bypass 4个,Dos 5个,Bypass 2个,其余存在信息泄露、权限提升等漏洞

DoS是此组件出现的主流漏洞,想想确实,Neutron是起网络配置作用的组件,众所周知网络配置很容易出现问题,如果在某个环节可以被攻击者控制,DoS就很容易完成。针对这个组件,理应较多参考DoS漏洞挖掘思路。

Glance

负责管理OpenStack集群中的镜像,可以创建、删除、编辑镜像基本信息。

近两年同样未出现漏洞,历史漏洞如是:

CVE-2017-7200 SSRF
CVE-2016-8611 DoS
CVE-2015-8234 Bypass
CVE-2015-5163 +Info
CVE-2015-5162 DoS
CVE-2015-3289 DoS
CVE-2013-4428 越权访问
CVE-2013-1840 +Info

DoS三个,信息泄露两个,绕过、SSRF、越权各一个,特征不算非常鲜明,漏洞样本也较少,近两年无新漏洞,不建议作为前期重点。

Cinder

负责为运行实例提供稳定的块存储服务,可以为设备提供创建卷、删除卷、挂载或卸载卷等功能。

编号 要素 简略分析
CVE-2020--10755 凭证泄露 不安全凭证漏洞。使用Dell EMC ScaleIO或VxFlex OS后端存储驱动r时,后端凭证'泄露于v3 Attachments API的connection_info处。通过泄露的凭证可以通过API调用读取附件信息。
CVE-2017--15139 信息泄露 允许在某些存储卷配置中新建的卷包含以前的数据。
13-15的4个CVE DoS/Info 2 DoS、2 Info

同样以DoS和Info为主,作为提供存储服务的组件,存储的内容外泄及存储服务崩溃是漏洞发生点。基于磁盘的较重型操作,恐怕不易于检测,不作为前期重点。

关于自动化的思考

综上所述,Nova、Keystone、Neutron相对较为具备系统性挖掘可行性,他们三个核心职能分别为统筹、认证、网络部署,再从他们共同的本质基础设施职能上出发。私以为从DoS型漏洞入手最为合适亦颇具可行性,一方面实现拒绝服务即有效,一方面针对这三个组件的拒绝服务都有可能会导致信息、权限上的问题,为更复杂的漏洞利用作前置。那么接下来,如何从代码层面实现自动化的针对性的DoS测试,考虑类Fuzz及链路跟踪。

harmoc
2 COMMENTS
  • 一个信安的菜鸟
    回复

    大佬对于openstack的fuzz有没有想法

    1. harmoc
      回复

      我能想到的可能也就是web相关的fuzz和api调用链的尝试。

发表回复

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