当云技术作为一种新型技术栈开始普及, 我们之前的攻击点又会如何变化.
其实之前的文章中已经有所提及这方面的内容了.
先回顾一下之前的部分 在最先前的导入部分我有所提及.
看看 CNCF 的技术愿景 https://landscape.cncf.io/
这些软件或者服务项目都被各位佬们盯得死死的.
新技术总是能给人们带来新的玩法, 但是同时也会伴随着新的攻击面. 这是发展带来的负面.
容器化是云时代的第一个技术上的变革.
准确点说 容器化和容器编排带来了云时代的开始.
较为常见的是以 谷歌重写内部的编排系统 命名为 Kubernetes 后捐赠给 Linux 开源基金会作为云时代的开始
当然这里不是研究历史的文章.
Container 主要给开发者提供了隔离的最小运行环境, 解决了 "我本地能跑, 但是远程服务跑不起来" 这种痛点问题. 可以看看我第一篇文章的 IaC 部分.
容器隔离了很多东西, 其具体方法是通过内核的一些新特性 cgroup 和 namespace 隔离开来多种系统资源, 使得传统的针对所依赖资源进行滥用的进攻方法的危害大大降低.
例如: 请设想这样一个场景: 应用程序和被攻陷的数据库资源, 在基于容器的库站分离时 这使得即便我们拿下数据库中所有权, 也无法让我们进行通过 dumpfile 或者 日志 的方法写一句话木马的操作来获取到 服务器 shell. 在这里的文件系统是隔离开的
但是容器本身仍然具有两类核心攻击面. 这里类似逃逸, 如下:
- 内核共享的调用/内存
- 没有良好分离的资源 例如 proc 等.
知道创宇当时给我的面试题 Release-Agent Docker Escape . 已经开源了, 我用 Obsidian 构建了知识网. 可以看看作为参考. 当然本文其实也是在这里编辑的
后者基本是开发图省事或者不禁意间造成的错误配置, 通常利用手段是称之为 LoLBins 的技术. 这是一个非常广泛的话题. 这里就不做过多的赘述
(举一个小小的例子 find 命令具有错误 suid 时, 可以通过
-exec /bin/bash -p进行权限提升等等)
谷歌开发的大名鼎鼎的编排系统 Go 开发的然后捐给了 Linux 基金会 然后有了 CNCF. 客套的话我们就不多说了.
类似的系统有 docker swarm 等但是用的真的很少, 而且有的是商业方案.
在小型的互联网企业中"比较"常见的配置是 开发测试一套 k8s 搭配 正式环境一套 k8s 环境之间相互隔离. 但是又非常的类似, 然后内部做分布式做微服务, 对外做一个 nginx ingress 的负载均衡和 API Gateway 等等. 再加之 k8s 的服务发现等等特性, 能大幅度确保在上线过程中拥有和开发测试类似的环境.
现在也有很多的公有的云服务具有这类的服务 可以直接买了然后开箱就用的. 虽然和你直接自己搭没啥区别 (x
随着这类服务的不断完善 一些公司也会渐渐的使用云来构建自己的服务.
如果初入 k8s 我较为推荐两个材料可以尝试阅读官方文档和 hacktricks 的云安全区渗透测试 k8s (用其中的 basic 作为阅读材料也可以使得我们快速把握 k8s 整个框架的要点) 尤其是后者.
K8s 主要的脆弱点需要注意如下的一些场景
- 上面提到的容器的问题
- 权限配置的问题 serviceaccount 这种凭据
- 还需要留意下是否存在 几个严重的 CVE 尤其是提权类的
- 控制端口 监控平台 管理平台 或者具有特殊权限的 Pod2 暴露
此外有一个好用的枚举工具叫做 CDK , 同样针对这些常见场景有 https://madhuakula.com/kubernetes-goat/docs/ 来进行实验.
集群的监控 web 端, 开发人员常常用于监控和测试整个集群的状态. 例如 weave ,当然这是一种管理工具, 也是一种 合法的 后门. 而且似乎已经有人那么干了.
众所周知 所有的 管理工具都是可以滥用成 黑客工具的 比如说 psexec 这种 sysinternals toolkit.
这里主要是一些公有云服务还有一些搭建的私有但是可接入的云(政务).
政务这里牵扯一些公民和组织的一些数据 例如交通一卡通, 疾控, 疫情防控, 党建, 团建 等等关系一些民生政务的服务, 然后由相关系统(例如学校 部分组织分部)对应的去对接或者外包来使用这些系统, 这种一般来说会有地区性的大数据公司和云服务商来做.
云的核心和 CTF 中常见的内网题并不太一样, 但是接触下来发现和域有一些些类似.
例如云偏重于高权限账户 AKSK STS 这类 凭据 的滥用 尤其是一些跨服务的凭证. 这类凭证丰富了开发者在系统内或者云端可以调用的资源, 同时也有助于红队和渗透队员扩大他们的战果 获取到更多更敏感的信息. OSS 等服务会有访问控制的策略等等, 非常类似域对象的 ACL.
因此往往在相对云渗透测试过程中我们会更加侧重于对于上文之前提到的资产, 尤其需要注意的是凭证. 尝试找到他们然后滥用他们, 辅以内网的一些奇技淫巧, 来达到我们的目的.
当然对于开发而言, 程序接入云使用云的服务, 通过云服务商提供的 SDK 和访问凭证 可以很方便的进行开发或管理处理云上拥有的资源. 同样 因为具有跨越服务的特点, 这些用到了其中的服务凭证也常常就成为了攻击者滥用的地方.
此外特别值得一提的是, 需要注意一些云环境的内网中还会有称之为元数据的内容 也就是 meta-data 服务. 这里同样可以泄漏不少有价值的信息, 比如 secrets 啦, Key 啦, 还有 [相当致命] 的 STSToken . 这直接导致 SSRF 可以直接获得对某些资源(OSS ECS)的访问能力, 因而形成了 SSRF 这类漏洞在云上的一种独特的利用, 以至于现在不少的文章在提及到云安全的时候提到这种攻击方法.
不过并不是所有的服务器都有这些内容. 这些往往需要特殊配置.
因为云通常是一些 toB (学生机个人网站托管等带有教育学习性质的不太算 toB, 量也不是很大) 的业务, 所以既然有对接的可能存在那么通常会存在相关的文档, 包括一些 API 调用方法 SDK 等等, 凭证的策略, 安全的策略, 甚至默认的账户密码. 如果对这个云的策略不是很熟悉, 强烈推荐去食用相关的文档 (不仅仅是公有的云, 相关私有的云服务和数据提供商基本都会有这些) 如果没有可以尝试扒一扒 SDK (大可能是 Java).
这些已经有大佬开始整理并且输出了文章和大量的工具, 甚至是一套类似 ATT&CK 的知识矩阵.
比如说 T-Wiki cf aws 还有 pacu 这类工具. 国外并没有国内云服务厂商的服务的利用工具, 基本上市面上可以看到的都是国人针对性开发的工具.
我想云很快应该会在虚拟的内网组建中和一些企业内部的网络链接起来, 通过特定的路由方式或者网络定义, 进行部分的融合, 互联互通, 资源共享, 建设内网.
这类情况可能会在一些特别的场景中遇到, 例如一些敏感信息要求不能放在云服务器和云数据库上但是业务系统还需要使用的时候等等.
这类可能是自己开发的系统和虚拟组网 也可以说例如云上域的 AzureAD. 当然不仅是业务, 也包括和更多的 OA 项目 组织管理等程序软件的协同合作 开发 提供服务.
可以期待一下.