Wednesday, March 11, 2015

eDOCS DM Auto Logon Security Issue - The Risk


It's pleasure to see the rapid evolution of their understanding of the issue, for they have taken the SQL Passthrough feature out of the equation as it was pointed out :)

It's a pity to see that OpenText underestimates the risk to either make themselves feel easy about it or the customers :(

Here is what they claim:

       1.What exactly is the risk:
       •The risk is ONLY within your organization. No one without a network identity could cause any harm.

Both statements are incorrect. Here are the three input parameters needed and sufficient to get into DM with the Auto Login feature enabled:
  1. The name or IP address of the DM Server of the enterprise. An attack can be performed from any location wherefrom the DM Server is "visible". Thus, if the server is exposed to the Internet, then the attack can be performed from the outside of the enterprise's LAN.
  2. The NetBIOS name of the domain of the enterprise. Current and ex-employees of the enterprise know it. It's hard to keep it secret.
  3. A user name (the login). Commonly, this is the first part of a person's corporate email address.

That is, a custom application that exploits the vulnerability can be run from anywhere with the access to a given DM server and the person running the application doesn't have to have a network identity within the exposed enterprise.

       •The risk would require an end user capable of writing code.

True, code writing is required. To estimate the risk one should estimate the difficulty of writing such code. It may be impossible for Mrs. Jane Doe, an office assistant, but easy for Joe Smart, a student.

Tons of examples of accomplishing many different things with DM API (be it ActiveX or WCF) are generally available. Here is a great sample in OpenText Knowledge Center:
You would only need to change two lines of code at the top of AutoLoginSample.cs to see the Auto Login vulnerability in action:

string username = Environment.UserName;
string domain = Environment.UserDomainName;

Simply set the two fields with constant strings (a user name and NetBIOS domain name) instead of initializing them from the Environment object and run the demo.

Here you can find another demo project and I'm positive more of the kind exist:

1 comment: