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及链路跟踪。