标签归档：蓝军建设

云安全

云上攻防：Red Teaming for Cloud

前言

Red Team的概念最早来源于20世纪60年年代的美国军方，指的是一个通过承担对抗性⻆角⾊色来挑战组织以 提⾼高其有效性的独⽴立的团体叫做Red Team。 国外科技企业一般定义Red Team的目标有以下好几个：

  • 学习和利用已知真实攻击者的TTPs来用于攻击；
  • 评估现有防御能力的有效性以及识别防御体系的弱点并提出具体的应对方案；
  • 利用真实有效的模拟攻击来评估因为安全问题所造成的潜在的业务影响，为上层管理者提供有效的数据来量化和衡量安全投入的ROI。

Red Teaming行动的常见方法有以下几种：

  • 模拟直接威胁者：根据特定的威胁情报来模拟攻击者，所谓“以情报驱动的Red Teaming行动”，目前深受国际主流互联网企业的Red Team团队的青睐，例如针对某些特定行业或者国家的APT组织的TTPs的模拟；
  • 模拟已知威胁者：根据已披露的APT组织的TTPs来模拟攻击者，例如利用ATT&CK来规划和映射Red Teaming行动所需的TTPs；
  • 模拟未知威胁者：根据真实入侵的各个阶段收集到的具体目标信息实时地规划攻击路径从而模拟攻击者。

这三种方法其实应该算是Red Teaming行动在企业处于不同的威胁阶段时应该采用的不同方法，个人以为前两种应该作为甲方企业自身Red Team的主要工作方向，第三种可作为前两种的进阶补充或者乙方Red Teaming服务的工作重心。具体而言，第一种方法主要是模拟直接威胁者，通过威胁情报提前发现直接威胁者的TTPs并加以模拟来检测防守团队应对直接威胁的防御能力，这是Red Teaming行动的基本目标；第二种方法主要是模拟已知威胁者，通过模拟目前所有已知的攻击组织的TTPs来全面而系统地识别防守团队的防御弱点并帮助其提高检测所有已知威胁的覆盖率，这是Red Teaming行动的主要目标；第三种方法主要是模拟未知威胁者，通过模拟真实黑客的潜在入侵行为来检测当前企业面对未知威胁的防御能力，这是Red Teaming的进阶目标。 Red Teaming for Cloud，只是上面介绍的Red Team建设的一个子集，这篇文章重点分享一下在公有云环境下进行Red Teaming行动的一些个人经历与思考。

团队建设

企业在想要开始Red Teaming行动之前，需要构建一个可信、可管理、可审计的Red Team团队，具体包括：

方法论

  • 目标范围：场景化的具体的行动目标（如窃取客户财务数据，访问CEO的邮件，控制云服务管理服务器，控制云上租户的云资源等），攻击范围，授权许可，行动时间，行动约束（Rules of Engagement）
  • 情资搜集：威胁情报（0day漏洞研究与Nday漏洞利用、最新攻击手法等）和目标资产（IP、域名、员工信息、初始入口等）的收集
  • 行动计划：攻击计划与TTPs准备
  • 行动执行：实施攻击
  • 记录报告：文档记录，行动报告

行动流程

  • 攻击计划：
    • 行动准则（授权与禁止行为，授权范围，限制条款等）
    • 风险管理（提前识别和管理行动过程中的各种潜在风险）
    • 行动计划（威胁情报，ATT&CK TTPs等）
    • 报备与授权流程
    • 行动终止流程
    • 行动成本与预算
  • 攻击执行：
    • 备案的时间区间内
    • 备案的目标范围内
    • 备案的攻击IP与网络环境
  • 攻击完成：
    • 恢复所有修改
    • 移除所有payload和backdoor
    • 移除所有持久化控制
    • 关闭所有C2通道
    • 提交攻击报告与改进建议（执行总结，方法论与目标，攻击场景与范围，攻击过程与时间线，关键发现与改进建议）
    • 开始复盘会议（技术层面）

运营管理

  • 行为管理：
    • 权限管理
    • 政策控制
    • 物理控制
    • 软件控制
    • 内部共享资料库管理
  • 数据管理：
    • 事前情资数据
    • 攻击行为记录
    • 操作日志
    • 自动化数据收集与日志
    • 攻击行为截图
    • 事后攻击数据（攻击报告，数据归档，内部报告分发等）

实践

工欲善其事，必先利其器。一个好的Red Team，绝不是什么技术高级就搞什么，而是一定要有明确的场景化的目标和思路清晰的攻击框架来指导我们怎么一步步去达成我们的目标，比如：ATT&CK for Cloud。
 attack-for-cloud

以下是常见的Red Teaming for Cloud的攻击场景（以AWS，Azure，GCP为例）：

一、利用公有云上租户的不安全的应用与服务配置为突破口

场景一：云服务认证Key泄漏（如AWS AK/SK或者Security Token等）

攻击难度：低

攻击路径：云服务认证Key -> 云服务公开API/SDK -> 云服务资源访问/控制

利用方式：

  • Github仓库配置不当
  • 云架构中的密码重用
  • 针对云租户账号密码的社工攻击（如AWS Credential Harvesting钓鱼攻击）
  • 云主机中Web应用的漏洞（SSRF，RCE，本地文件读取等漏洞）
  • 公共的存储桶
  • 信任的关联第三方数据泄露
  • 硬编码在网页或移动APP中的AK/SK。

相关参考：

场景二：云上租户的云服务不安全配置

攻击难度：低

攻击路径：公共访问的云存储桶 -> 敏感凭证 ->  云服务资源访问/控制

利用方式：公共访问的云存储桶爆破

相关参考：

场景三：云主机中web应用自身漏洞

攻击难度：中

攻击路径：

  • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS SSM -> RCE
  • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS Lambda -> RCE
  • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS S3 -> 信息泄漏
  • RCE -> EC2 Metadata API -> IAM临时Security Token -> AWS EC2/S3/Lambda
  • RCE -> EC2 Metadata API -> EC2 Userdata -> 敏感凭证 ->  其他EC2或者云服务
利用方式：Web应用漏洞（如SSRF/XXE/RCE等）
相关参考：

二、利用公有云本身的服务（IaaS，PaaS，SaaS）的自身问题为突破口

场景一：云服务自身功能导致代码执行
攻击难度：低
攻击路径：云服务账号AK/SK -> 云服务功能（AWS SSM/Lambda/EC2 Instance Connect）-> RCE
利用方式：
  • 外部泄漏的云服务账号AK/SK（Github，Public S3 Buckets，硬编码在网页或移动APP中的AK/SK等）
  • EC2云上应用SSRF漏洞配合AWS Metadata API
相关参考：
场景二：云服务的公开API利用
攻击难度：低
攻击路径：云服务账号AK/SK -> 云服务公开API -> 云服务资源调用（OS镜像，容器镜像，存储桶，数据库，Userdata等）-> 敏感信息泄露（数据，凭据等）
利用方式：云服务公开API的熟悉和利用，如AWS CLI/AWS SDK
相关参考：
场景三：云服务第三方软件漏洞利用
攻击难度：中
攻击路径：第三方软件漏洞 -> 使用该软件的云服务 -> 云服务系统/平台 -> 其他租户数据
利用方式：
  • 收集云服务利用的第三方软件列表与相应的版本信息，如MySQL，ElasticSearch，Docker，K8S等
  • 第三方软件0day研究和Nday的收集与利用
相关参考：
场景四：云服务私有或者公开API漏洞挖掘与利用
攻击难度：中-高
攻击路径：云主机中应用SSRF漏洞或者云服务账号AK/SK -> 云服务私有/公开API漏洞 -> RCE/信息泄露
利用方式：
  • 云服务私有API寻找与测试（云服务Web请求分析，云服务SDK或者离线工具分析等）
  • 云服务公开API漏洞研究（输入输出校验，认证与鉴权绕过等）
  • 云主机中的应用的SSRF漏洞
相关参考：
场景五：容器逃逸
攻击难度：中-高
攻击路径：共享容器 -> 宿主机 -> 其他租户容器
利用方式：
  • 容器逃逸漏洞
  • 宿主机目录挂载（/var/run/docker.sock）
  • 特权容器
  • Kubernetes安全
相关参考：
场景六：虚拟机逃逸
攻击难度：高
攻击路径：弹性云主机 ->  宿主机 -> 同一宿主机上其他弹性云主机
利用方式：虚拟机逃逸漏洞
相关参考：
场景七：云服务管理面网络入侵
攻击难度：高
攻击路径：公有云厂商办公网/DMZ区域 -> 公有云员工权限 -> 公有云管理面网络 -> 公有云生产网
利用方式：
  • 企业办公网/DMZ区域入口（钓鱼，OWA，VPN，WiFi，远程办公，物理入侵，DMZ区域对外应用漏洞等）
  • 传统的内网渗透入侵手法

案例

下面是一些AWS/Azure/GCP相关的攻防案例：

AWS

Azure

GCP

General

工具

以下是一些在云上Red Teaming时会用到的工具：