Shulou(Shulou.com)06/01 Report--

Apache how to resolve vulnerabilities and ssl remote command execution, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

Introduction to Apache newline parsing, multiple suffix parsing, and ssl remote command execution vulnerability analysis 1.Apache:

Apache HTTP Server (abbreviated as) is an open source web server that can run in most computer operating systems. Because of its multi-platform and security Apache Apache software foundation is widely used, it is one of the most popular Web server-side software. It is fast, reliable and can compile interpreters such as Perl/Python into the server through a simple API extension. [2] Apache HTTP server is a modular server, which originates from NCSAhttpd server. After many modifications, it has become the number one software used in the world.

two。 Vulnerability description: Apache newline parsing vulnerability:

Apache HTTPD is a HTTP server that runs PHP pages through mod_php. There is a parsing vulnerability in version 2.4.02.4.29. When parsing PHP, 1.php\ x0A will be parsed according to the PHP suffix, resulting in bypassing the security policies of some servers.

Apache multiple suffix parsing vulnerability:

In the case of multiple suffixes, as long as a file with a .php suffix is about to be recognized as a PHP file, it is not necessary to be the last suffix. Taking advantage of this feature will create a parsing vulnerability that can bypass the uploaded whitelist.

Apache ssl remote command execution vulnerability:

When testing for arbitrary file upload vulnerabilities, the target server may not be allowed to upload files with the php suffix. If the target server has SSI and CGI support enabled, we can upload a shtml file and execute arbitrary commands using syntax.

3. Vulnerability principle: Apache newline parsing vulnerability

The root cause of the apache parsing vulnerability is this $. In regular expressions, we all know that $is used to match the end of a string. Let's take a look at the meaning of the $symbol in a regular expression: matching the end of an input string. If the Multiline property of the RegExp object is set, $also matches'\ n'or'\ r'. To match the $character itself, use\ $.

So the root cause of this vulnerability is that the Multiline property of the RegExp object is set so that $can match the newline character.

Let's go into the docker environment and take a look at how apache2 is configured.

Obviously, the $symbol is used here.

Let's take a look at the configuration file for php in the modules of other versions of apaceh:

SetHandler application/x-httpd-php SetHandler application/x-httpd-php-source # Deny access to raw php sources by default# To re-enable it's recommended to enable access to the files # only in specific virtual host or directory Require all denied# Deny access to files without filename (e.g. '.php') Require all denied# Running PHP scripts in user directories is disabled by default## To re-enable PHP in user directories comment the following lines# (from to.) Do NOT set it to On as it# prevents .htaccess files from disabling it. Php_admin_flag engine Off

You can see that there are several more php suffixes identified here than in the docker environment. If the $here sets the Multiline property of the RegExp object, then this version of apache will also have a newline parsing vulnerability.

Php php3 php4 php5 php7 pht phtml

Apache multiple suffix parsing vulnerability: configuration file content AddType text/html. Html

AddLanguage zh-CN .c

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

So, in the case of multiple suffixes, as long as a file with a .php suffix is about to be recognized as a PHP file, it doesn't have to be the last suffix. Taking advantage of this feature will create a parsing vulnerability that can bypass the uploaded whitelist.

We will do an experiment in the vulnerability exploitation section.

Apache ssl remote command execution vulnerability:

SSI (server-side inclusion) is an instruction placed in a HTML page and evaluated on the server when the page is served. They allow you to add dynamically generated content to an existing HTML page without having to provide the entire page through CGI programs or other dynamic technologies.

In fact, the ssl of apache is more like the jinjia2 of flask, which is used to implement a dynamic interaction with the front end, but after configuring ssl, if the upload interface does not filter out the .shtml file, then it can include the commands we want to execute.

4. Vulnerability exploitation:

Apache newline parsing vulnerability:

Lab 1:

Here is a little knowledge of how to get inside the docker container:

View the mirror resource docker ps

Open a shell environment docker exec-it containerID / bin/bash for the container

For convenience, we install a vim inside the docker container.

Install the command apt-get update

Apt-get install vim

Before uploading and using it, let's create a file with a newline flag in the var/www/html directory.

Vim hack.php$'\ n'

Next, use the browser to access the file to verify success. Indicates that this vulnerability exists in this version of apache.

Lab 2:

Next, let's verify the loophole again by uploading (note: there is a big hole here)

Let's first take a look at the contents of index.php in the docker environment

Index.php

Notice that only one index.php file is given here, and here I thought the vulhub author had forgotten an uploaded html page, and I wrote it on purpose.

Upload

Open the upload page

After this is the endless road to report errors, Baidu, Google, change the directory, repair authority. From reappearance to giving up. After several days of delay, I made up my mind to solve the problem. After searching a lot of articles, none of them explained the problem.

I first wrote a normal upload PHP file.

After comparing it with the previous one, I finally know what went wrong.

There is no file name for uploading name through a self-written html file (note: here we must fill it in by ourselves) Why do this? Because of what vulhub gave.

The php file gets the file name through $_ POST ['name'].

$name = basename ($_ POST ['name'])

Note: getting the file name in this way automatically removes the newline character. Therefore, the vulnerability cannot use this method to obtain the file name.

$_ FILES ["file"] ["name"]

You can see that we uploaded it successfully.

Apache multiple suffix parsing vulnerability:

Next, let's do an experiment and modify the configuration file so that it can recognize our custom suffix file as a PHP file.

Be sure to restart the apache service after modifying the configuration file, but how can we restart the service without exiting the container in the docker environment? That's the order.

Service apache2 reload

You can see that our info.hacker.xxx.jpg is successfully executed in php format.

Apache ssl remote command execution vulnerability:

Most of the vulnerabilities in Apache are configuration errors, and many programmers are not familiar with these configurations or security configuration problems, so they write problematic code or catastrophic configuration files, which gives hackers the opportunity to cause serious consequences. Some configuration problems come with apache, and the consequences will be even more serious. So it's also important to write secure configuration files.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.