近期，我们邀请资深安全专家在“金融业企业安全建设实践”微信群、实践2群、读者群，进行在线直播分享系列。本期我们邀请到的嘉宾是王任飞（avfisher）。如需查阅更多嘉宾分享，请关注本公众号。

【活动预告】Red Teaming for Cloud（云上攻防）

【分享嘉宾】王任飞（avfisher）

【嘉宾简介】王任飞（avfisher），公众号安全小飞侠的作者，近10年的一线攻防经验，曾负责某知名国际互联网公司的中国区的Red Teaming和Global Bug Bounty项目，目前在国内某知名公有云厂商负责蓝军团队建设。

【活动时间】4月17日周五晚上20:00-21:00，60分钟。

【活动形式】嘉宾通过文字形式，在“金融业企业安全建设实践”、实践二群、读者群三个微信群内就“Red Teaming for Cloud（云上攻防）”话题进行同步直播分享（约四十钟），之后是互动提问和回答，约二十分钟。

请大家安排好时间，准备好问题，积极参与。

----------------------------------------------

以下是实录：

大家晚上好，感谢君哥邀请，很高兴有这个机会能和大家分享一下我近几年在Red Teaming for Cloud领域的一些经历和思考，欢迎大家多提问和交流。

下面开始我今天分享的主题Red Teaming for Cloud，本次分享分为以下几个部分：

  1. 介绍

  2. 团队建设

  3. Red Teaming for Cloud实践

  4. 案例

  5. 工具

介绍

在开始正式分享之前，先确定一下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 Team的概念和目标，我们就开始谈谈Red Team团队的建设，因为Red Team从来不是一个人的独角戏，他是团队作战。企业在想要开始Red Teaming行动之前，就需要：

构建一个可信、可管理、可审计的Red Team团队。

avfisher

1、方法论：

  • 目标范围：场景化的具体的行动目标（如窃取客户财务数据，访问CEO的邮件，控制云服务管理服务器，控制云上租户的云资源等），攻击范围，授权许可，行动时间，行动约束（Rules of Engagement）

  • 情资搜集：威胁情报（0day漏洞研究与Nday漏洞利用、最新攻击手法等）和目标资产（IP、域名、员工信息、初始入口等）的收集

  • 行动计划：攻击计划与TTPs准备，如ATT&CK for Cloud

    (https://attack.mitre.org/matrices/enterprise/cloud/)

  • 行动执行：实施攻击

  • 记录报告：文档记录，行动报告

2、行动流程

攻击计划：

  • 行动准则（授权与禁止行为，授权范围，限制条款等）

  • 风险管理（提前识别和管理行动过程中的各种潜在风险）

  • 行动计划（威胁情报，ATT&CK TTPs等）

  • 报备与授权流程

  • 行动终止流程

  • 行动成本与预算

攻击执行：

  • 备案的时间区间内

  • 备案的目标范围内

  • 备案的攻击IP与网络环境

攻击完成：

  • 恢复所有修改

  • 移除所有payload和backdoor

  • 移除所有持久化控制

  • 关闭所有C2通道

  • 提交攻击报告与改进建议（执行总结，方法论与目标，攻击场景与范围，攻击过程与时间线，关键发现与改进建议）

  • 开始复盘会议（技术层面）

运营管理：

  • 行为管理：

  • 权限管理

  • 政策控制

  • 物理控制

  • 软件控制

  • 内部共享资料库管理

数据管理：

  • 事前情资数据

  • 攻击行为记录

  • 操作日志

  • 自动化数据收集与日志

  • 攻击行为截图

  • 事后攻击数据（攻击报告，数据归档，内部报告分发等）

Red Teaming for Cloud实践

有了配置齐全的Red Team团队，我们就可以正式实践Red Teaming for Cloud了，下面我重点谈谈实践这个部分。

工欲善其事，必先利其器。

一个好的Red Team，绝不是什么技术高级就搞什么，而是一定要有明确的场景化的目标和思路清晰的攻击框架来指导我们怎么一步步去达成我们的目标。

ATT&CK for Cloud就是其中不错的一个攻击指导框架。

(https://attack.mitre.org/matrices/enterprise/cloud/)

有了清晰的目标和攻击框架，我们就可以按照场景化的攻击场景来做Red Teaming，下面我会按照两个不同的大方向突破口，多个攻击场景，从简单到复杂来具体介绍一下。

以下常见的攻击场景，将会主要以AWS，Azure，GCP为例。

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

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

攻击难度：低

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

利用方式：

  • Github仓库配置不当

  • 云架构中的密码重用

  • 针对云租户账号密码的社工攻击（如AWS Credential Harvesting钓鱼攻击）

  • 云主机中Web应用的漏洞（SSRF，RCE，本地文件读取等漏洞）

  • 公共的存储桶

  • 信任的关联第三方数据泄露

  • 硬编码在网页或移动APP中的AK/SK。

相关案例：

  • AWS MFA Phishing: https://rhinosecuritylabs.com/aws/aws-phished-persistent-cookies/

  • AWS IAM Keys: https://rhinosecuritylabs.com/cloud-security/onelogin-breach-cloud-security-and-protecting-aws-ami-keys/

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

攻击难度：低

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

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

相关案例：

  • GCP: https://github.com/RhinoSecurityLabs/GCPBucketBrute

  • AWS:https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/s3_bucket_bruteforcer

场景三：云主机中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等）

相关案例：

  • AWS Elastic Beanstalk: https://www.notsosecure.com/exploiting-ssrf-in-aws-elastic-beanstalk/

  • AWS SSM: https://hackerone.com/reports/401136

  • AWS:https://blog.appsecco.com/getting-shell-and-data-access-in-aws-by-chaining-vulnerabilities-7630fa57c7ed

  • CloudGoat(AWS):https://rhinosecuritylabs.com/aws/cloudgoat-walkthrough-rce_web_app/

  • GCP: https://hackerone.com/reports/341876

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

场景一：云服务自身功能导致代码执行

攻击难度：低

攻击路径：云服务账号AK/SK -> 云服务功能（AWS SSM/Lambda/EC2 Instance Con

nect） -> RCE

利用方式：

  • 外部泄漏的云服务账号AK/SK（Github，Public S3 Buckets，硬编码在网页或移动APP中的AK/SK等）

  • EC2云上应用SSRF漏洞配合AWS Metadata API

相关参考：

AWS: https://github.com/RhinoSecurityLabs/pacu

场景二：云服务的公开API利用

攻击难度：低

攻击路径：云服务账号AK/SK -> 云服务公开API -> 云服务资源调用（OS镜像，容器镜像，

存储桶，数据库，Userdata等）-> 敏感信息泄露（数据，凭据等）

利用方式：云服务公开API的熟悉和利用，如AWS CLI/AWS SDK

相关参考：

  • AWS: https://docs.aws.amazon.com/

  • GCP: https://cloud.google.com/apis

  • Azure: https://docs.microsoft.com/en-us/rest/api/azure/

场景三：云服务第三方软件漏洞利用

攻击难度：中

攻击路径：第三方软件漏洞 -> 使用该软件的云服务 -> 云服务系统/平台 -> 其他租户数据

利用方式：

  • 收集云服务利用的第三方软件列表与相应的版本信息，如MySQL，ElasticSearch，Docker，K8S等

  • 第三方软件0day研究和Nday的收集与利用

相关参考：

RDS (MySQL): https://paper.seebug.org/1112/

场景四：云服务私有或者公开API漏洞挖掘与利用

攻击难度：中-高

攻击路径：云主机中应用SSRF漏洞或者云服务账号AK/SK -> 云服务私有/公开API漏洞 -> RCE/信息泄露

利用方式：

  • 云服务私有API寻找与测试（云服务Web请求分析，云服务SDK或者离线工具分析等）

  • 云服务公开API漏洞研究（输入输出校验，认证与鉴权绕过等）

  • 云主机中的应用的SSRF漏洞

相关参考：

  • Azure:https://nosec.org/home/detail/4358.html

  • AWS:https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/lambda_ssrf

场景五：容器逃逸

攻击难度：中-高

攻击路径：共享容器 -> 宿主机 -> 其他租户容器

利用方式：

  • 容器逃逸漏洞宿

  • 主机目录挂载（/var/run/docker.sock）

  • 特权容器

相关参考：

  • runC容器逃逸（CVE-2019-5736）: https://github.com/Frichetten/CVE-2019-5736-PoC, https://github.com/twistlock/RunC-CVE-2019-5736

  • Docker容器逃逸: https://www.exploit-db.com/exploits/47147

  • Docker容器逃逸之waitid()（CVE-2017-5123）:

  • https://github.com/nongiach/CVE/tree/master/CVE-2017-5123

  • GCP:https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/GCP/cloud_shell_docker_escape

场景六：虚拟机逃逸

攻击难度：高

攻击路径：弹性云主机 -> 宿主机 -> 同一宿主机上其他弹性云主机

利用方式：虚拟机逃逸漏洞

相关参考：

  • QEMU逃逸漏洞: https://github.com/ray-cp/vm-escape/tree/master/qemu-escape

  • QEMU虚拟机逃逸漏洞分析与利用(CVE-2019-14378):

  • https://www.anquanke.com/post/id/184949

  • QEMU虚拟机逃逸漏洞分析与利用(CVE-2019-6778): https://mp.weixin.qq.com/s/SgY1QsPmgU8iI4EUJfhznQ

  • QEMU虚拟机逃逸漏洞分析与利用(CVE-2015-5165, CVE-2015-7504, CVE-2015-7512): https://bbs.pediy.com/thread-217997.htm, https://bbs.pediy.com/thread-217999.htm, https://bbs.pediy.com/thread-218045.htm, https://www.freebuf.com/vuls/87673.html

场景七：云服务管理面网络入侵

攻击难度：高

攻击路径：公有云厂商办公网/DMZ区域 -> 公有云员工权限 -> 公有云管理面网络 -> 公有云生产网

利用方式：

  • 企业办公网/DMZ区域入口（钓鱼，OWA，VPN，WiFi，远程办公，物理入侵，DMZ区域对外应用漏洞等）

  • 传统的内网渗透入侵手法

案例

以上都是一些我们实际在云上做Red Teaming行动时常用的入侵场景，下面我分享在分享一些AWS/Azure/GCP相关的攻防案例，有些在上面的场景化的相关参考里已经提到了：

AWS

  • https://andresriancho.github.io/nimbostratus/pivoting-in-amazon-clouds.pdf

  • https://blog.appsecco.com/getting-shell-and-data-access-in-aws-by-chaining-vulnerabilities-7630fa57c7ed

  • https://blog.netspi.com/gaining-aws-console-access-via-api-keys/

  • https://rhinosecuritylabs.com/cloud-security/onelogin-breach-cloud-security-and-protecting-aws-ami-keys

  • https://rhinosecuritylabs.com/aws/aws-phished-persistent-cookies/

  • https://rhinosecuritylabs.com/aws/cloudgoat-walkthrough-rce_web_app/

  • https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/

  • https://rhinosecuritylabs.com/aws/s3-ransomware-part-2-prevention-and-defense/

  • https://rhinosecuritylabs.com/aws/aws-iam-user-enumeration/

  • https://rhinosecuritylabs.com/aws/aws-iam-credentials-get-compromised/

  • https://rhinosecuritylabs.com/aws/assume-worst-aws-assume-role-enumeration/

  • https://rhinosecuritylabs.com/aws/aws-role-enumeration-iam-p2/

  • https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/

  • https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/

  • https://rhinosecuritylabs.com/aws/escalating-aws-iam-privileges-undocumented-codestar-api/

Azure

  • https://nosec.org/home/detail/4358.html

  • https://www.youtube.com/watch?v=JEIR5oGCwdg

  • https://www.youtube.com/watch?v=SG2ibjuzRJM

  • https://blog.netspi.com/attacking-azure-cloud-shell/

  • https://rhinosecuritylabs.com/azure/cloud-security-risks-part-1-azure-csv-injection-vulnerability/

  • https://www.darkreading.com/cloud/two-vulnerabilities-found-in-microsoft-azure-infrastructure/d/d-id/1336932

  • https://www.mdsec.co.uk/2019/07/introducing-the-office-365-attack-toolkit/

  • https://blog.netspi.com/category/azure-penetration-testing/

  • https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-i/

  • https://research.checkpoint.com/2020/remote-cloud-execution-critical-vulnerabilities-in-azure-cloud-infrastructure-part-ii/

GCP

  • https://hackerone.com/reports/341876

  • https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/GCP/cloud_shell_docker_escape

  • https://rhinosecuritylabs.com/gcp/google-cloud-platform-gcp-bucket-enumeration/

General

  • https://rhinosecuritylabs.com/blog/?category=cloud-security

  • https://blog.netspi.com/category/cloud-penetration-testing/

工具

最后再分享一些在云上Red Teaming时会用到的一些工具，或者会根据需要开发一些专属的利用平台，以下这些公开的大家也可以参考一下：

  • https://github.com/RhinoSecurityLabs/Cloud-Security-Research/

  • https://github.com/RhinoSecurityLabs/Security-Research/

  • https://github.com/RhinoSecurityLabs/AWS-IAM-Privilege-Escalation

  • https://github.com/RhinoSecurityLabs/cloudgoat

  • https://github.com/RhinoSecurityLabs/pacu

  • https://github.com/nccgroup/ScoutSuite

  • https://github.com/NetSPI/aws_consoler

  • https://github.com/dagrz/aws_pwn

  • https://github.com/bchew/dynamodump

  • https://github.com/fireeye/ADFSpoof

  • https://github.com/LMGsec/o365creeper

  • https://github.com/busterb/msmailprobe

  • https://github.com/nyxgeek/o365recon

  • https://github.com/mdsecactivebreach/o365-attack-toolkit

  • https://github.com/NetSPI/MicroBurst

  • https://github.com/RhinoSecurityLabs/GCPBucketBrute

感谢大家的时间，我的分享基本上结束了，有什么问题欢迎提问交流。

提问环节

Q：我问一个，场景七，有真实发生过的案例吗？"

A：有，我经历过数次。

--------------------------------------------------------------------

Q：感谢鱼总，请教一个问题，在做Red Team攻击的时候，比如针对弱配置和漏洞的攻击，是做配置审计和漏洞扫描来进行攻击的理论验证，还是真刀实干做POC呀"，问这个问题是因为有两点。

1、对真实环境做攻击还是有可能造成不可控的因素影响生产环境，这个业务给Red Team的压力估计不小。

2、比起真实poc，有一些简单攻击如果理论上已经能完美验证，是不是更高效一点。"

A：Red Team一般会在保证业务正常不受影响的情况下，尽可能真刀真枪的干，而不只是POC，因为Red Team需要为行动目标负责。

--------------------------------------------------------------------

Q：Red Team一般存在于实力比较雄厚的大公司。Red Team和一般的甲方公司渗透测试团队，除了在人员编制和技术规范度上的差别外，最大的差别在哪？"

A：我认为最大的差别是行动的目的，简单而言，Red Teaming是为行动的结果负责在于突破现有防御体系达成行动预期的场景化目标，而渗透测试则更强调发现的安全漏洞。

--------------------------------------------------------------------

Q：小飞侠好，利用公有云本身的服务，其云服务账号不应该是多重身份认证的吗？如何有效获取ak/sk？

A：公有云的认证有多种形式，IAM AKSK， Security Token，MFA，但是大部分公有云服务的API认证基本上都是依赖AK/SK，具体方法可以参考，第一类突破口的场景一。

--------------------------------------------------------------------

Q：鱼总，谢谢分享，想问下你们会对红队的攻击行为做审计吗？(防止超出范围的测试，或者有恶意的测试)用什么方案审计？

A：会的，这就是我在开始说的，Red Team的运营管理，由于Red Team人员通常掌握了大量企业的攻击方法和技术，必须严格控制这些技术和方法不被滥用。

--------------------------------------------------------------------

Q：av总，蓝队在云安全相比传统安全需要着重关注哪些方面？

A：目前来看，公有云上的Red Teaming需要非常关注容器类，IAM权限类，安全配置类等问题，这是目前来说比较容易出现问题的点。

--------------------------------------------------------------------

Q：感谢鱼总，精彩。redteaming实战时给红队多高的网络权限是比较合理的，只是在公有云外部访问，还是授权部分内部资源的可达？

A：这个要根据场景化的目标来定，举个例子，如果你的目标时模拟内部入侵者，那么可以省去一些突破办公网的步骤；如果你的目标是模拟外部入侵者，那么你的权限就必须和外部黑客一样。

--------------------------------------------------------------------

Q：飞总，请教个问题，如何保证红队日常把发现的攻击场景都贡献给团队？有考核机制吗？

A：我个人的经验，有以下几个点。

1、Red Team的行动不是为了攻击而攻击，所以一个合格的Red Team行动的结果需要包含：详细的攻击路径，识别的风险点，解决风险点的建议。最重要的是要告诉防守团队问题出在哪，哪个地方有限制，攻击难度就会加大。

2、Red Team要以行动成功率/被阻断率/被发现率来量化和考核攻击难易程度。

--------------------------------------------------------------------

Q：我倒是想请教下什么前提下适合组建Red Team，怎么告诉老板红蓝对抗不是三五个人做的？

A：一般来说，一个企业只有拥有了基本的防御和检测的能力，并需要持续检验和改进这种能力时，Red Team才是一个非常不错的选择。如果一个企业连基本的入侵检测能力都没有健全，这种时候搞Red Team就好比空中楼阁，也没有实际的价值和好处。还有一种情况就是你需要利用真实有效的模拟攻击来评估因为安全问题所造成的潜在的业务影响，为上层管理者提供有效的数据来量化和衡量安全投入的ROI。

--------------------------------------------------------------------

Q：这个问题很好，我也再请教下鱼总在混合云这种复杂环境下，团队的建设，蓝队，红队，或者还有soc等，怎样组织架构和搭配是比较合理的？

A：这个问题，我之前也写过一篇文章介绍过我的看法和经验：

http://avfisher.win/archives/1064

--------------------------------------------------------------------

Q：可信、可管理、可审计，这个原则说得特别好。如何实现对Red Teaming的可信、可管理、可审计呢？

A：这个就需要从制度，流程，日常运营几个维度来做，具体做法，我上面已经提到了，更细化的东西需要按照公司的实际情况酌情裁剪，基本准则就是保证Red Teamer不随意做，不越权做，所有攻击行为要留下记录。

--------------------------------------------------------------------

Q：结合上面专家问过的和安全测试的区别，追问下哈，少数几个人的渗透测试，目标不局限于挖漏洞，而是对整个安全防护效果做渗透，比如社工、业务也含进来，是否就可以认为是Red Team了，如果不能，那Red Team和渗透测试团队的区别应该是什么？

A：这个问题，可以参照我之前写的一篇文章：http://avfisher.win/archives/1081

--------------------------------------------------------------------

Q：建立这样一个Red Team需要多少人员？

A：我以前在外企的团队和现在都不超过10人。

Q：能否借助外部力量？

A：当然可以，一般的大企业的Red Team都是内外都有，相互补充和促进。

--------------------------------------------------------------------

Q：鱼总，Red Team角度看，私有云和公有云的场景有哪些根本性区别吗

A：目前来看，公有云的攻击面（IAAS/PAAS/SAAS）要更大，私有云基本上就只有了IAAS服务，大部分都是当成传统IDC的扩展。

--------------------------------------------------------------------

Q：请问鱼总安全做到什么样的规模，或者说什么样的甲方需要思考开始去建设自己的红队？

A：一般来说，一个企业只有拥有了基本的防御和检测的能力，并需要持续检验和改进这种能力时，Red Team才是一个非常不错的选择。如果一个企业连基本的入侵检测能力都没有健全，这种时候搞Red Team就好比空中楼阁，也没有实际的价值和好处。

--------------------------------------------------------------------

Q：感谢鱼总的分享，请教一个aws waf的规则问题，aws的waf规则，最基本的只防SQL和XSS，请问下你们在Red Teaming 时，对于aws的waf规则加固来提升攻击门槛，可有一些建议。

A：AWS的WAF功能很一般，在防守时不要仅仅考虑waf的一个层面，要从主机层，netflow，cloudtrail等多维度来监控，另外做好IAM的权限控制，尽可能缩小攻击面。

--------------------------------------------------------------------

Q：鱼总提到的Red Teaming行动的常见方法第一种（模拟直接威胁者），能否再详细讲一下，谢谢

A：模拟直接威胁者是指企业有强大的威胁情报团队，可以提前有效获知同行业的攻击情报（TTPs），然后有针对性地模拟这些TTPs对本企业进行攻击，以检验本企业是否具备检测和抵御该种攻击的能力。

--------------------------------------------------------------------

Q：分享中提到的“场景二：云上租户的云服务不安全配置

攻击难度：低

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

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

相关案例：

GCP: https://github.com/RhinoSecurityLabs/GCPBucketBrute

AWS:https://github.com/RhinoSecurityLabs/Cloud-Security-Research/tree/master/AWS/s3_bucket_bruteforcer”这个点想请教下鱼总，在实际的攻击中 利用到的机会大嘛？这个点对应CSPM 目前看这个点还没有得到很多甲方用户的重视

A：这个实际攻击场景中很常见，国外很多数据泄露的案例都是从公开S3开始的。

--------------------------------------------------------------------

Q：谢谢鱼总的解答，还想再请教个问题，当前企业如果已经来到需要通过建设红队来衡量我们基本的安全体系能力的阶段了，其实做安全都是在花钱，但是很难汇报价值，有没有什么好的办法或许建议帮我们撬动公司做出这样的资源投入支持哈？"

A：我觉得最简单的方式，在没有内部Red Team时，尝试引入外部蓝军（比如hw这种），用实际行动打出效果，让老板看清问题所在（数据泄露，核心服务器被控制等），在逐步潜移默化向上管理慢慢影响，然后构建自己的Red Team。

--------------------------------------------------------------------

Q： 鱼总，有个问题请教，做全球性的漏洞奖励计划，如何管理参与方知情不报的风险？以往比如可以通过合同限定几年的沉默期或者，但可能还是会存在一定风险，是否有其他措施借鉴？

A：可以选择与众测平台合作，像hackerone、bugcrowd这些，这两家平台都有类似于private bug bounty program，可以和他们从私有BBP项目开始，限定参与测试人员数量和背景调查，让平台方控制风险，也将风险分摊给平台方，共同负责和约束。

群友补充：HackCrowd了解一下。

声明：本文来自君哥的体历，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。