OpenText Document Sciences full of holes - multiple vulnerabilities found

News by Rene Millman

SQL injections and cross-site scripting vulnerabilities are among the flaws found in OpenText Document Sciences xPression.

Several flaws have been discovered in OpenText Document Sciences xPression (formerly EMC Document Sciences xPression) that could enable hackers to mount SQL injection attacks. Other flaws could allow cross-site scripting attacks.

According to a posting on Seclists, due to lack of prepared statements an application is prone to SQL Injection attacks. According to security researcher Marcin Woloszyn, a potential attacker can “retrieve data from application database by exploiting the issue.”

A second flaw makes it possible to inject Javascript into the application which will be reflected to unaware application users.

“This might allow an attacker to perform actions on behalf of unaware application users. In order to remediate the issue, proper input validation, sanitising and output encoding should be conducted on server side,” said Woloszyn.

There is also a flaw that where an authenticated user is able to read arbitrary system file due to path traversal issue. As well as that, another flaw in the Application XML parser is accepting DOCTYPE in provided XML documents, either directly or indirectly, using URLs.

“This can be exploited in various of ways, eg to read directory listings, read system or application files, cause denial of service or issue requests on behalf of server (SSRF),” he said.

Kevin Bocek, chief cyber-security strategist at Venafi, told SC Media UK that this vulnerability could allow attackers to read encrypted traffic, impersonate trusted machines and steal data all under the cover of encryption.

“For example, they can expose and steal encryption keys, which could allow them to move laterally through an organisation and exfiltrate data. It's possible for hackers to stay hidden for months, removing valuable data or spying on private communications amongst a host of other dangers,” he said.

Ilia Kolochenko, CEO of web security company High-Tech Bridge, told SC Media UK that these are pretty common security vulnerabilities that can be found almost in any web application.

“When using a third-party application, it is important to assess the risks associated with the quality of code (based on previously discovered flaws and other relevant factors), rapidity of security fixes release, as well as vendor's overall ability to properly maintain the code during the application lifecycle. A WAF can be a good way to reduce exploitability of most popular attack vectors, however they are unlikely to provide a reliable protection against all relevant threats. Therefore, continuous security monitoring and rapid bug fixes are very important,” he said.

Josh Mayfield, platform specialist, Immediate Insight at FireMon, told SC Media UK that the XSS vulnerability has been around for some time. 

“The endgame for using XSS is simple: it allows attackers to consume privileged data or content by impersonating legitimate users,” he said. “It's accomplished by taking cookies from a user that has authenticated into the web service, and using those cookies as a sign that the malicious source is trusted.  Attacks such as these bypass traditional security controls, when cookies are used for authentication.”

“Vendors should stop being naïve about security.  Prior to release, vendors should try to ‘break' their own security with Red Teaming, and stop seeing security checks as an impediment.  Which is worse, delaying a release for a moment to confirm security or lose every customer you have because of a missed vulnerability?  Which is better , adding a little time and cost to install seatbelts (in the early days when auto-manufacturers didn't want to install them) or losing all of your customers who are unable to use your product safely?” he added.

Paul Woods, chief architect at GeoLang, said that in general the way to stop attacks is to follow best practice, which is freely available online via the Open Web Application Security Project – OWASP.

“I suppose the real question is why do software developers not follow best practice when it is so freely available?” he said. “The answer might be poor management, or developers being incentivised to ship features quickly. Security is too often seen as an optional extra and it ends up in the bucket called 'technical debt'. Building secure software is expensive; total security is impossible anyway.”

Find this article useful?

Get more great articles like this in your inbox every lunchtime

Video and interviews