OpenStack调度算法逆向分析

OpenStack架构分析

Nova运行架构

OpenStack调度算法逆向分析 调度算法原理 过滤：对主机列表进行筛选 称重：对主机列表进行排序 选择分值最高主机作为调度目的地

OpenStack调度算法脆弱性分析 AA者已经攻陷了OpenStack管理网络，可以利用网络监听调度数据 调度算法泄露所造成的危害 调度算法 = 过滤器 + 称重器 + 随机参数 在监听足够数量的数据包的前提下，可以获取当前的过滤器和称重器，从而实现调度算法的捕捉 调度算法泄露所造成的危害 恶意宿主AA AA者伪装成宿主机，对目标VM发起AA 恶意同驻AA AA者伪装成VM，对同驻的目标VM发起AA

调度算法的逆向分析 具体步骤 协议窃听 过滤器猜解 称重器猜解 对AMQP报文进行监听 分析出报文中的主机信息 分析出报文中的请求信息 布尔型过滤器猜解 数字型过滤器猜解 称重器猜解 分析出Host Shifting模式实例 得到一次方程组 方程组求解，得到称重器权重

实验结果 过滤器逆向结果 准确率高达100% 称重器逆向结果 误差小于0.0172，准确率高达98.28%

虚拟机调度拒绝服务AA

虚拟机调度拒绝服务AA原理

AA实验 AA场景 4节点OpenStack环境：一个controller节点，一个network节点，两个compute节点（compute1和compute2），OpenStack Juno版本搭建在Ubuntu 14.04上 AA效果 使得compute1节点拒绝服务，使得新创建的虚拟机全都创建到compute2节点上

实验步骤1 用户创建两个server-group，为了之后可以指定虚拟机创建到某个物理机上

实验步骤2 在compute1和compute2各创建一个虚拟机，并各指定一个server-group

实验步骤3 在compute1节点超量创建虚拟机命令与结果

实验结果 新创建的虚拟机在compute2节点上

虚拟机创建过程中的文件注入AA

Nova创建实例的完整流程

脆弱点及威胁分析 Nova对创建虚拟机镜像过程中的文件注入缺乏有效检查 我们可以在创建虚拟机的时候将任意文件注入到虚拟机镜像中的任意路径

AA实验 以demo用户身份在创建虚拟机时进行文件注入 将本地的hostname文件注入到镜像中的/etc/hostname路径 注入文件：fileinjection 对/etc/hostname进行覆盖

实验结果

云计算平台服务接口分析及AA技术

自动化配置管理机制中的脆弱点 Foreman框架 通过Smart-Proxy代理各种应用程序完成各项功能 可以与Puppet集成使用,通常作为前端接入 可定制各种模板，关联模板生成的文件实现自动化安装

Foreman组件远程执行AA原理 可以利用代码缺陷，构造Payload进行AA 可利用获得的command shell执行任意代码，造成服务中断，信息泄露，文件系统被修改等后果 redirect_to函数重定向到用户当前所在的控制器，eval函数利用bookmark的controller名称属性来生成重定向路径 合法性检查有缺陷，仅是controller不能为空或者带有空格

利用Metasploit工具的AA实验 初始化注册选项 向服务器发送三次请求 第一次请求：利用提供的用户名和密码登陆服务器 第二次请求：获取当前session的令牌 第三次请求：通过获得的令牌向服务器提交创建书签的请求，触发payload

在服务器上执行ruby_string的64位编码版本时，将会从服务器反弹一个shell到LHOST的LPORT端口！ Payload构造 定义ruby_string 在服务器上执行ruby_string的64位编码版本时，将会从服务器反弹一个shell到LHOST的LPORT端口！ 生成64位编码版本的ruby_string

AA实验 实验环境 CentOS 6.6 Foreman 1.1 Metasploit Pro

实验结果 执行ls命令 执行init 0命令

Keystone组件 提供身份认证功能 RESTful API 角色概念

Keystone组件中的脆弱点 底层代码分析 假设有如下图所示的用户-项目关系 create_trust函数 token_to_auth_context函数 没有考虑链式授权的问题，在利用令牌创建trust的时候，只检查用于授权的角色是否存在于对应的项目中 admin, test, member 用户1 项目1 用户2 admin 项目2 admin 用户3 项目3 用户1 用户2 用户3 项目1的test权限 项目1的test+admin权限

AA实验 平台 方法 VMWare ESXI 5.5 + CentOS 6.6 minimal + OpenStack 2014.1.1 利用Keystone客户端在服务器上创建如前所示的用户-项目-角色关系，然后利用keystone的RESTful API，进行链式授权

实验结果 用户1创建客户端；然后利用客户端创建包含授权角色-test的trust trustor_client = client.Client(debug=True,…) trustor_trust = trustor_client.trusts.create(role_names=[‘test’,],…) 用户2利用用户1创建的trust创建客户端；然后创建授权角色为admin和test的trust middle_trustee_client = client.Client(debug=True,…) middle_trustee_trust = middle_trustee_client.trusts.create(role_names=[‘admin’, ‘test’,],…) 用户3利用用户2创建的trust创建客户端；查看用户3所拥有的权限（角色） third_trustee_client = client.Client(debug=True,…) print "The roles of third trustee: %s" %third_trustee_client.auth_ref.role_names