浑浑噩噩的睡了一下午，突然有点不适应这种短期不用工作的生活了。公众号停更半年，没想到近几次发文全是为了抨击某些src不公平的一些结果（好在最后得到了应有的尊重)。当初和几位师傅一起创建这个公众号是想分享一些关于安全方面的技术文章，建立一个圈子，希望认识更多的师傅一起交流学习。后来陆陆续续发生了一些事情，公众号一直没有更新，其实并不是不愿意分享一些技术文章，更多的还是觉得在下才疏学浅，写出来的一些东西对大家没有帮助，很多师傅会嗤之以鼻。这半年来收获颇多，想记录一些自己的心得，遂写下这篇。
0x01 前言
由于工作方面接触，发现越来越多的中小型公司选择使用云平台，诸如:阿里云、腾讯云、华为云、七牛云等等，另一方面随着公用云的普及，也存在着一些风险，当然不是由于云平台本身的安全性欠缺，而是由于使用者在调用API时没有注意安全性而导致的。最常见的问题就是AccessKey及泄漏、配置不当导致攻击者接管存储桶及云控制台等危害。
以下是个人的一些浅见和总结，如有不当的地方还请各位师傅批评指正。
传统web安全和云原生安全的区别
-
安全威胁不同：传统Web应用程序主要面临网络攻击、恶意软件和数据泄漏等威胁，而云环境则需要应对更广泛、更复杂的安全威胁，包括无授权访问、虚拟化漏洞和配置错误等。
-
体系结构不同：在传统Web应用程序中，通常使用单一服务器或集群来部署和运行应用程序。然而，在云环境中，应用程序采用容器化、微服务和动态资源分配等方式进行部署，使得系统架构更加复杂。
-
安全责任共担：在云环境中，安全责任由服务提供商和客户共同承担。服务提供商负责保护基础设施和平台层的安全性，而客户负责保护业务层的安全性。
-
安全控制不同：云环境具有更强大的安全控制，例如身份认证和访问控制、加密、网络隔离和监控等功能，以确保数据和应用程序得到充分保护。
正文
Access Key和Secret Access Key是Amazon Web Services（AWS）的一种身份验证机制，用于授权用户访问AWS资源。
OSS AccessKey泄露
通过上面描述我们知道AccessKey如果泄露就会导致用户账户被控制，常见的泄露方式有以下几种：
-
APK反编译后的配置文件
-
小程序反编译后的配置文件
-
GITHUB关键字、JS文件、FOFA等。
-
spring未授权读取env或heapdump泄露
-
低权限的WEBSHELL查看网站的配置文件
-
任意文件读取漏洞读取bash_history
-
浏览器插件FindSomething
-
debug泄露
拿到ak/sk后的一些简单利用方式
-
第三方平台，如：行云管家
-
OSS/COS Browser、例如阿里、腾讯
-
aksk_tool
-
cf
这里演示几种常见的利用方法
cf
先进行配置
目前cf支持阿里、腾讯、华为、AWS四个云接管，下面用阿里云做示范
OSS Browser
阿里云 access key ID 和 access key secret 是访问阿里云API的唯一凭证。Access key ID 是类似身份的标识，而 access key secret 的作用是签名你的访问参数，以防被篡改。Access key secret 类似你的登录密码。
登录后可以进行文件增删改查等一系列操作
COS Browser也是一样的操作，这里就不再赘述了。
通过行云管家，我们可以进一步进行操作，同样的我们也需要ak/sk
使用行云管家，不仅可以访问OSS服务，还可以直接重置服务器密码，接管服务器,建立RAM用户等等操作
那么有长期密钥肯定就有临时密钥了，二者利用方式也不同，这里以腾讯云为例：
腾讯云获取临时密钥的过程如下：
账号中的访问策略包括用户组策略、用户策略、存储桶访问控制列表（ACL）和存储桶策略（Policy）等不同的策略类型。当腾讯云 COS 收到请求时，首先会确认请求者身份，并验证请求者是否拥有相关权限。验证的过程包括检查用户策略、存储桶访问策略和基于资源的访问控制列表，对请求进行鉴权。
流程如下：
小结
目前云上攻击的主要思路集中在以下几个层面：
-
突破网络隔离：传统的网络隔离边界（防火墙、路由器、交换机、VPN）、VPC（peering、endpoint、traffic mirror）、云专线（混合云、多云网络）、安全组等；
-
突破资源隔离：虚拟机逃逸、容器逃逸、物理机CPU/芯片侧信道攻击等；
-
突破权限隔离：IAM账号（AWS Landing Zone）、IAM策略（ABAC）、委托代理、联邦认证（AWS STS security tokens、SAML）等；
-
突破架构隔离：物理多租（单租户独享）、逻辑多租（多租户共享）等。
当然了，上文主要是以国内云厂商为例，以下是一些常见的的攻击场景（以AWS，Azure，GCP为例）
场景一：云服务认证Key泄漏（如AWS AK/SK或者Security Token等）
-
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或者云服务
二、利用公有云本身的服务（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漏洞挖掘与利用
-
云服务私有API寻找与测试（云服务Web请求分析，云服务SDK或者离线工具分析等） -
云服务公开API漏洞研究（输入输出校验，认证与鉴权绕过等） -
云主机中的应用的SSRF漏洞
场景五：容器逃逸
攻击难度：中-高
攻击路径：共享容器 -> 宿主机 -> 其他租户容器
利用方式：
-
容器逃逸漏洞
-
宿主机目录挂载（/var/run/docker.sock）
-
特权容器
-
Kubernetes安全
目前接触到比较多的就是这些，本人文笔不好，部分也有引用一些其他平台文章的内容，如果有问题还请师傅们多多指正，我会在第一时间积极响应。
那么上面聊了这么多，还是想在这里讲一讲我的工作、还有我的团队。
工作方面
加入外企也有半年了，也慢慢习惯北京的生活节奏了，非常感谢这段时间以来团队里各位师傅们对我的帮助，在这段经历里也不能说有多大的贡献吧，算是完成了在未入职前给自己定下的一个小目标，有时候常常因为不够自信、太过急躁导致出一些小差错，总是做不到尽善尽美，报告总是有各种各样的疏漏，在此也感谢在项目上的各位师傅对我的包容。
我的团队
在这半年里收获很多，这里也就不得不提到我的团队——Zero Two和ce two，团队的氛围很棒，一直都有在交流一些前沿技术和分享议题及个人的一些小技巧总结，让我受益良多。
在我初识云安全的时候团队各位师傅给予了我非常多的的帮助，工作和生活里受到了打击也是团队的师傅们一直在鼓励、安慰着我，支撑着我走到今天，现在回想起来在下实在是惭愧。
最后，再次感谢团队里的每一位师傅对我的帮助，希望日后有机会线下见面的时候能好好畅饮几杯
原文始发于微信公众号（Rot5pider安全团队）：近半年来的一些收获
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论