(Pentest Apache #3) - The Nature of # (%23) Character | Mod Security Rules in Apache

In my earlier posts, I have talked about  some interesting issues in deployed modules in Apache and insecure configuration. Refer here:

1. (Pentest Apache #1) Exposed Apache Axis - SOAP Objects
2. (Pentest Apache #2) - The Beauty of "%3F" and Apache's Inability | Wordpress | Mod Security

In this post, I want to discuss an interesting issue that occurs due to misconfigured rules in modsecurity. It is not a severe issue but it helps the penetration tester to gain some additional information about the server-side environment. For example:- directory listing.

In modsecurity, NE is stated as No Escape. One can explicitly configure the rules with this flag to implement no escaping. For example: "#" will be converted to "%23" if NE flag is not set.  If NE flag is set , the "#" character is treated as such and processed accordingly.  For more about modsecurity flags, refer here: http://httpd.apache.org/docs/2.2/rewrite/flags.html.  An example taken from there:


"RewriteRule ^/anchor/(.+) /bigpage.html#$1 [NE,R]. This example will redirect /anchor/xyz to /bigpage.html#xyz."

If escaping is not set properly in addition to some misconfiguration issue, it could result in unexpected behavior. I have noticed this flaw plethora of times during a number of security assessments. Let's have a look at one of the real time example:-


URL pattern 1: http://www.example.com/temp/#htaccess.cl
URL pattern 2: http://www.example.com/temp/%23htaccess.cl

In case (1), if NE flag is set, the URL has to be processed with "#" character. In case (2), if NE flag is not set, the URL has to be processed with "%23", hexadecimal notation of the character "#". But due to misconfiguration, the behavior changes.

The tested server is : Apache/2.2.14. Actually, both URLs are responded with 200 OK responses. In case (1), the output results in directory listing. In case (2), the output results in content of the file htaccess.cl.

Case 1: Content-Type is text/html;charset=UTF-8

With # Character 

Case 2: Content-Type is text/plain

With %23 Character

It could be a one reason that file name starts with "#" character. But, the primary reason is the inability of Apache to understand misconfigured URL rewriting rules. Usually, if the URL rewriting rule fails, the web server should respond in 404 error message. In case of misconfiguration, the fall back step is the directory listing, atleast that what I have seen in practical scenarios (it could be different).

Inference: Play around with URL rewriting rules to detect bypasses which could result in gleaning additional information.

(Pentest Apache #2) - The Beauty of "%3F" and Apache's Inability | Wordpress | Mod Security

Tested Apache Version: Apache 1.3.37(Unix) (with different modules)

I was doing an open research and came across an interesting issue which helps a penetration tester to gather more information about the files present (directory listing) on the web server (specific web folder). I tested only one version of Apache for this. Let's understand this issue. The problem is present in Apache's ability to process the encoded value of "?" which is "%3F". 

Testing: During the validation, I found that wordpress was running on Apache 1.3.37(unix). Due to misconfiguration, it was possible to access the /wp-includes/  folder, which resulted in directory listing as shown below:

So, when I accessed the /wp-admin/ directory, it redirected me to the login page as presented below:

Tthe above presented screenshot shows the correct behavior of the wordpress or the Apache server when /wp-admin/ directory is accessed. Now, when I accessed the http://www.example.com/blog/ , the web server displayed the contents of wordpress blog such as posts and entries. 

Question : Is it possible to get the directory listing on accessing the /blog/ directory?

Answer : Yes, It can be done in some web servers such as Apache.

Question : How can it be possible?

Answer : I exploited the behavior of Apache in processing the encoded "?" character whose value is

"%3F". Amazingly, it worked. I constructed the payload as:   http://www.example.com/blog/%3Fpage_id=34. [One can use any id number or parameter]

Other examples:

http://www.example.com/blog/%3Fp_id=34

http://www.example.com/blog/%3Fpg_id=34

When I used the above stated payload, I got the response as follows:

This allowed me to get the listing of the /blog/ directory which really helped me to understand the presence of different files on the remote web server. But, If I used the payload as: http://www.example.com/blog/?page_id=34 without encoding, it did not work. So the encoding of "?" character resulted in failure of processing the request as desired by the Apache web server thereby resulting in directory listing.

Let's have a look at the HTTP response headers:

Request 1: http://www.example.com/blog/%3Fpage_id=34.

(Status-Line)      HTTP/1.1 200 OK
Date      Sun, 20 Jan 2013 19:22:59 GMT
Server   VHFFS / Apache/1.3.34 (Unix) mod_lo/1.0 PHP/4.4.4 with Hardening-Patch mod_ssl/2.8.25 OpenSSL/0.9.8b mod_chroot/0.5
Content-Type    text/html; charset=ISO-8859-1
Transfer-Encoding           chunked

Request 2: http://www.example.com/blog/?page_id=34

(Status-Line)      HTTP/1.1 200 OK
Date      Sun, 20 Jan 2013 19:23:48 GMT
Server   VHFFS / Apache/1.3.34 (Unix) mod_lo/1.0 PHP/4.4.4 with Hardening-Patch mod_ssl/2.8.25 OpenSSL/0.9.8b mod_chroot/0.5
X-Powered-By  PHP/5.1.5 with Hardening-Patch
Content-Type    text/html; charset=ISO-8859-1
Transfer-Encoding           chunked

In the request 2, the response contains X-Powered-By as compared to the first request. So, the PHP preprocessor plays a part in it.

Constraint: In this technique, one can only get the directory listing but will no be able to access those files

until unless there is misconfiguration issue.

Background: I forced Google to provide me with related information and I got the related links as follows:

1. http://stackoverflow.com/questions/9786853/apache-not-processing-encoded-urls-with-3f

2. https://issues.apache.org/bugzilla/show_bug.cgi?id=34602

Solution: Configure appropriate rewrite rules using mod_rewrite to prevent these types of vulnerabilities.

Check [1] for this

Note: If any reader has a specific view on this, please respond back.