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:

Query Builder Code Injection

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:

Symantec has released the Security Advisory SYM13-006 that addresses the discussed vulnerabilities in the SSIM version 4.8.1.