当前位置：首页 > news >正文

nginx反向代理+负载均衡上传webshell重难点+apache漏洞

news 2026/2/10 6:49:05

nginx反向代理

nginx 负载均衡

负载均衡的策略
1、轮询：nginx默认就是轮询其权重都默认为1，服务器处理请求的顺序：ABABABABAB…

upstream mysvr { server 192.168.137.131; server 192.168.137.136;       
}

2、weight：跟据配置的权重的大小而分发给不同服务器不同数量的请求

upstream mysvr { server 192.168.137.131 weihet = 100; server 192.168.137.136 weihet = 200;
}

3、ip_hash：ip_hash:nginx会让相同的客户端ip请求相同的服务器

upstream mysvr { server 192.168.137.131; server 192.168.137.136;ip_hash;
}

搭建环境

github下载
在这里插入图片描述

cd /ant/loadbalance/loadbalance-jsp
docker-compose up  -d

这里我搭建环境的时候出了点问题，不知道为什么dockers-compose up -d 执行不了，然后我我把docker-compose 删了重新安装发现还是不行，然后我恢复快照重新搭建环境，最后解决办法是卸载docker 重新安装docker和docker-compose。

cd /usr/local/bin/
#下载docker-compose
wget https://github.com/docker/compose/releases/download/1.14.0-rc2/docker-compose-Linux-x86_64
#重命名
rename docker-compose-Linux-x86_64 docker-compose docker-compose-Linux-x86_64
#给执行权限
chmod +x /usr/local/bin/docker-compose

上述下载方式有问题，由于compose更新了，Docker Compose V2 是 Docker Compose 的主要版本碰撞版本。它在Golang中完全重写了（V1是用Python编写的）。撰写 V2 的安装说明与 V1 不同。V2 不再是独立的二进制文件，必须调整安装脚本。
然后我们采用下列方式重新安装docker

#在 Linux上 安装 Docker
curl -sSL https://get.daocloud.io/docker | sh
#安装 Docker Compose
curl -L https://get.daocloud.io/docker/compose/releases/download/v2.16.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
#给予执行权限
chmod +x /usr/local/bin/docker-compose

在这里插入图片描述

进入docker-nginx 查看一下nginx 配置。
做了轮询的负载均衡策略。

假定在真实的业务系统上，存在一个 RCE 漏洞，可以让我们获取 WebShell。
上传我们的一句话木马。
尝试用蚁剑登录

负载均衡上传webshell重难点

1、需要在每一台节点的相同位置都上传相同内容的 WebShell

假如说node1上有ant.jsp，node2上没有，这就会出现一会连接失败，一会连接正常的问题我们进入node2删除ant.jsp。
在这里插入图片描述
一旦有一台机器上没有，那么在请求轮到这台机器上的时候，就会出现 404 错误，影响使用。还好负载均衡的策略是轮询，还存在一定的规律，如果是其他策略，更难以把控。

2、无法预测下次的请求交给哪台机器去执行。

在这里插入图片描述
由于难点一测试时删除了 node2的ant.jsp，我们重新copy一下
docker cp ant.jsp 46c0af8b0ca3:/usr/local/tomcat/webapps/ROOT/ant.jsp
由于nginx服务器上配置了轮询负载均衡，所以我们无法下次的请求交给哪台机器去执行，有点飘忽不定。
在这里插入图片描述

3、下载文件时，可能会出现飘逸，导致下载失败

由于 antSword 上传文件时，采用的分片上传方式，把一个文件分成了多次HTTP请求发送给了目标，导致两台节点上，各一半，而且这一半到底是怎么组合的，取决于 LBS 算法

4、目标机器不能出外网

目标机器不能出外网，要想深入，只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel，但隧道随时可能断开连接，tunnel 脚本全部都会失效。

apache漏洞

1、Apache HTTPD 换行解析漏洞

Apache HTTPD 换行解析漏洞（CVE-2017-15715）
影响版本：2.4.0~2.4.29
影响说明：Apache HTTPD是一款HTTP服务器，它可以通过mod_php来运行PHP网页。在解析PHP时，1.php\x0a将被按照PHP后缀进行解析，导致绕过一些服务器的安全策略。
在这里插入图片描述
在1.php后面插入一个\x0A,php会解析成1.php%0a,从而成功解析。

2、Apache HTTPD 多后缀解析漏洞

Apache HTTPD 支持一个文件拥有多个后缀，并为不同后缀执行不同的指令。比如，如下配置文件：

AddType text/html .html
AddLanguage zh-CN .cn

其给.html后缀增加了media-type，值为text/html；给.cn后缀增加了语言，值为zh-CN。此时，如果用户请求文件index.cn.html，他将返回一个中文的html页面。
意思就是说只要文件后缀中包含了 html、php的文件,他就可以被解析成相应的文件.
以上就是Apache多后缀的特性。如果运维人员给.php后缀增加了处理器：
AddHandler application/x-httpd-php .php
那么，在有多个后缀的情况下，只要一个文件含有.php后缀的文件即将被识别成PHP文件.
漏洞复现
环境运行后，访问http://192.1`68.137.131/uploadfiles/apache.php.jpeg即可发现，phpinfo被执行了，该文件被解析为php文件。
我们就可以利用Apache解析漏洞进行getshell。
在这里插入图片描述

3、Apache Solr 远程命令执行漏洞

Apache Solr 远程命令执行漏洞（CVE-2019-0193）
影响版本：Apache Solr < 8.2.0 的版本
影响说明：Apache Solr 是一个开源的搜索服务器。Solr 使用 Java 语言开发，主要基于 HTTP 和 Apache Lucene 实现。此次漏洞出现在Apache Solr的DataImportHandler，该模块是一个可选但常用的模块，用于从数据库和其他源中提取数据。它具有一个功能，其中所有的DIH配置都可以通过外部请求的dataConfig参数来设置。由于DIH配置可以包含脚本，因此攻击者可以通过构造危险的请求，从而造成远程命令执行。
在Apache Solr < 8.2.0 的版本中， DataImportHandler的dataConfig参数为用户可控，攻击者可通过构造恶意的dataConfig脚本交由转换器（Transformers）进行解析，而Solr在解析的过程中并未对用户输入的脚本进行检查，导致攻击者可在Solr服务器上执行任意代码。

solr 工作机制
1、solr是在lucene工具包的基础之上进行了封装，并且以web服务的形式对外提供索引功能
2、业务系统需要使用到索引的功能（建索引，查索引）时，只要发出http请求，并将返回数据进行解析即可

Solr DataImportHandler
Solr DataImportHandler可以批量把数据导入到索引库中。

DataImportHandler有如下功能：

1、读取关系数据库中数据或文本数据
2、根据配置从xml（http/file方式）读取与建立索引数据
3、根据配置聚合来自多个列和表的数据来构建Solr文档
4、使用文档更新Solr（更新索引、文档数据库等）
5、根据配置进行完全导入的功能（full-import，完全导入每次运行时会创建整个索引）
6、检测插入/更新字段并执行增量导入（delta-import，对增加或者被修改的字段进行导入）
7、调度full-import与delta-import
8、可以插入任何类型的数据源（ftp，scp等）和其他用户可选格式（JSON，csv等）

4、Apache HTTP 服务器的路径穿越和文件泄露漏洞

Apache HTTP 服务器 2.4.49 中的路径穿越和文件泄露漏洞（CVE-2021-41773）
影响版本：2.4.49
影响说明：在 Apache HTTP Server 2.4.49 中对路径规范化所做的更改中发现一个缺陷。攻击者可以使用路径遍历攻击将 URL 映射到预期文档根目录之外的文件。
如果这些目录之外的文件不受通常的默认配置“要求全部拒绝”的保护，则这些请求可以成功。如果还为这些别名路径启用了 CGI 脚本，则可能允许远程执行代码。

漏洞复现

curl -v --path-as-is http://your-ip:8080/icons/%2e%2e/%2e%2e/%2e%2e/%2e%2e/etc/passwd

5、Apache SSI 远程命令执行漏洞

影响说明：在测试任意文件上传漏洞的时候，目标服务端可能不允许上传php后缀的文件。如果目标服务器开启了SSI与CGI支持，我们可以上传一个shtml文件，并利用<!–#exec cmd=“id” -->语法执行任意命令。

漏洞复现
环境启动后，访问http://192.168.137.140:8080/upload.php，即可看到一个上传表单。然后上传一个1.shtml文件。

<!--#exec cmd="id" -->

在这里插入图片描述

然后用burpsuite 测试一下：

然后我们修改post 改成我们的1.shtml 运行后成功执行了<!–#exec cmd=“id” -->命令

SSI（服务器端包含）是放置在 HTML 页面，并在页面被服务。它们允许您将动态生成的内容添加到现有 HTML 页面，而不必提供整个页面通过CGI程序或其他动态技术。

例如，您可以将指令放入现有 HTML 中页面，例如：

<!--#echo var="DATE_LOCAL" -->
并且，当页面投放时，将评估此片段并将其替换为其值：
Tuesday, 15-Jan-2013 19:28:54 EST

各个服务器对SSI命令的支持各有不同，但 #include 和 #exec 是通用的。使用 SSI 的页面文件通常都使用扩展名.shtml，而不是.html 或 .htm，这样以便服务器能够辨认出哪些页面包含SSI指令，这些页面需要先经过服务器处理，翻译执行其中的SSI指令，然后才发送给客户端浏览器。 (当然有些服务器还是支持.html,.htm文件中有SSI指令的)。