CVE-2020-1938漏洞分析

2020-03-03 19:04:22 阅读：1078 来源： 互联网

标签：协议 1938 AJP request 漏洞 2020 SC CVE Constants

前言

跟各类大拿比，写的很晚，尽量详细的写下此漏洞和挖掘过程中的思维CVE-2020-1938，官方威胁公告：CNVD官方说明

AJP协议

首先得了解下AJP协议，避免在深入挖掘此漏洞时遇到坑比如我，AJP说白了就是一种传输层协议，由tomcat出品，显然是一种面向连接，效率较高的传输协议，下面这个图百度的，基本就这么回事了。具体的协议内容见（下面在分析代码的时候会遇到各种getbytes的枚举，其中各数字代表应用层向下封装的头部分，物数网传会表应不多介绍了哈，了解下OSI7层模型）：官方AJP协议介绍文档
tomcat中AJP协议和http协议的工作方式
/conf/server.xml中可配置connector，这个也是官方临时修复建议需要注释掉的点也就是关闭8009端口，关闭了AJP协议，自然就没有此漏洞了，此漏洞需要借助ajp协议进行攻击。
在这里插入图片描述

漏洞成因

tomcat7.0.99举例：下载位置

首先看二进制的输入点，定位到ajp中调用socket的点，位置为/org/apache/coyote/ajp目录，索引socket关键字。

先看下安恒给的点AjpProcessor.java
在这里插入图片描述

预请求的prepareRequest()方法来自于父类AbstractAjpProcessor，找下

关键点在如下代码中，在这个之前呢，贴几个图，当然可以下一个tomcat版本自己看，各版本有细微差异，比如枚举的值有的直接就是赋值硬编码，可能是后来改进了。
在这里插入图片描述

下面的代码加上详细注释方便新手理解，因为一般相对了解javaweb的人都比较难看懂。

// Decode extra attributes
        boolean secret = false;
        //定义一个byte类型的参数attributecode
        byte attributeCode;
        //while()!=结构，当ATBcode=requestHM.getbyte()，atbcode=请求头信息类型转换的byte，当其不等于255（这个对应Constants.SC_A_ARE_DONE的值0xFF）时,执行下面的switch,case语句，这里是个恒true的循环。
        while ((attributeCode = requestHeaderMessage.getByte())
                != Constants.SC_A_ARE_DONE) {

            switch (attributeCode) {
//当case到Constants.SC_A_REQ_ATTRIBUTE时，这个枚举的值是10，在AJP协议封装里，代表attribute类型。
            case Constants.SC_A_REQ_ATTRIBUTE :
            //tmpMB在上面有定义，提取byte[]数组里面的子byte，再tostring转换为string类型，有同学可能不能理解为啥定义两个相同的n和v参数，这里是为了在下面一个进行判断一个进行赋值，tomcat的开发人员都是大佬，这样写可以避免参数的混乱。
                requestHeaderMessage.getBytes(tmpMB);
                String n = tmpMB.toString();
                requestHeaderMessage.getBytes(tmpMB);
                String v = tmpMB.toString();
                /*
                 * AJP13 misses to forward the local IP address and the
                 * remote port. Allow the AJP connector to add this info via
                 * private request attributes.
                 * We will accept the forwarded data and remove it from the
                 * public list of request attributes.
                 */
                 //赋值IP给request
                if(n.equals(Constants.SC_A_REQ_LOCAL_ADDR)) {
                    request.localAddr().setString(v);
                    //赋值端口给request
                } else if(n.equals(Constants.SC_A_REQ_REMOTE_PORT)) {
                    try {
                        request.setRemotePort(Integer.parseInt(v));
                    } catch (NumberFormatException nfe) {
                        // Ignore invalid value
                    }
                    //赋值协议https协议key给request
                } else if(n.equals(Constants.SC_A_SSL_PROTOCOL)) {
                    request.setAttribute(SSLSupport.PROTOCOL_VERSION_KEY, v);
                    //v的值直接setAttribute给request的属性。
                } else {
                    request.setAttribute(n, v );

上面的代码是核心漏洞输入点，既然找到了输入点，那么就要找AJP-REQUEST的输出点和REQUEST-RESPONSE的点。
接下来，就要利用到tomcat的内核连接器与容器的桥梁——CoyoteAdapter类了（百度。。。。。），下面的图是子类AjpNioProcessor的点，关于Adapter类如何处理request的其实不重要，很多人可能会苦读这块内容导致被绕晕。
在这里插入图片描述
接着就到了HttpServlet处理请求的点

在这里插入图片描述

在defaultservlet中包含获取的属性

到这里基本漏洞的原理就差不多了，最后就是注意一下file中会对path进行限制跨目录

至于jsp文件的处理基本也差不多，核心漏洞输入点在上文ajp-http中，输出处理不一样罢了。

复现方式可以利用脚本，也可以利用java客户端发送ajp数据包。

标签：协议,1938,AJP,request,漏洞,2020,SC,CVE,Constants
来源： https://blog.csdn.net/silencediors/article/details/104484178

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

CVE-2020-1938漏洞分析

前言

AJP协议

漏洞成因