Symantec Security Information Manager, multiple vulnerabilities (XSS, SQLi, Information Disclosure)

Hi there, we missed here for quite a while but one more time we are back with something (hopefully) interesting. In the past months we have worked together with Symantec vulnerability response team to address some critical issues that were afflicting the Symantec Security Information Manager. Our R&D Team discovered vulnerabilities consisting of XSS (both stored and reflected), Sql Injection and Information Disclosure, in the beginning of March 2013, SSIM versions 4.7.x and 4.8 resulted to be affected. Hacktive Security notified Symantec about the findings and started the process of Responsible Disclosure according to the following timeline:

March 6th, Hacktive Security R&D Team notified Symantec about the issues
March 6th, Symantec answered asking for some additional details about afflicted versions of SSIM
March 20th, Symantec verified and addressed the issues to developers for patching
May 3rd, Hacktive Security R&D Team 1st request for patch relase date
May 3rd, Symantec takes some more time for fixing.
June 22nd, Hacktive Security R&D Team warns Symantec about public Disclosure planned the end of the month
June 28th, Symantec updates, CVEs number assignment and relase date planned for new version of the SSIM planned on July 1st US Time.
July 1th, Symantec releases the security advisory and new SSIM version that fix the addressed vulnerabilities.
July 1th, Hacktive Security R&D Team disclose the research results.

Following a brief proof of concept of the issues: Java query editor of the SSIM resulted to be vulnerable to XSS attacks, a successful exploitation could possibly result in stealing user cookies or potentially leveraged to hijack an authorized user session. Hereafter an example of the injection on the query builder:

Calling the malicious query through the interface triggers the attack, is also possible to “publish” the query so that other users can recall it, resulting in a stored XSS condition:

The SSIM console does not sufficiently sanitize authorized client queries made against the database. A malicious user who has or can gain authorized access to a valid account could potentially inject arbitrary SQL database queries through the _sql_ parameter in the api.jsp page in order to further compromise the database:

Furthermore, the SSIM console does not properly restrict queries to web-GUI APIs which could be manipulated to potentially disclose sensitive information to unauthorized network users. This information could possibly be leveraged in any follow-on attempts to further compromise the application or network. Tests have shown that calling api.jsp and requesting for statistics it was possible to display informations about implemented rules without performing any authentication: