DRF File and PCDOCS Link Handler for eDOCS DM

Couple years ago I created a handler for DRF files, OpenText eDOCS DM document links. The purpose of the tool was to give users the ability to open eDOCS DM documents in read-only mode if they (the users) do not want to install eDOCS DM Extensions.

Today I'm publishing the tool, its full source code, and some basic documentation:
EDocsLinkHandler

The best part of this package is, of course, the full source code (C# / .NET 4 / Visual Studio 2013). It's my implementation of DM WCF API helpers, and it even includes unit tests! :-)

Although the helpers only implement the logon, search, and document download functionality, they may serve as a starting point for anyone developing for DM with WCF API. After two years since the code was written, I still like it, maybe with the exception of the way I implemented the DMSearchResults class... Well, consider it as a free demo. Enjoy!

eDOCS DM Auto Logon Security Issue - FAQ for DM administrators

Foreword:  Earlier today OpenText released a hotfix for this issue. The security hotfix is not available to me and I cannot test it. I hope it works well. Below is my version of FAQ on the Auto Logon Security issue.

Q. Which DM versions are affected by issue DM-32057?

A. All (DM 10 prior to P1, 5.3.1 P5b and earlier, 5.3.0 P5 RU5 and earlier).

Q. What can an intruder do to my library through the Auto Logon breach?

A. It depends on the intruder's goals and imagination. He/she can just sneak into the library and quietly read others documents or he/she can quickly scramble the entire library by replacing real documents with garbage through random logins. OpenText has rated the vulnerability as HIGH. A very good explanation was also given to what HIGH means.

Q. Can I detect an intruder?

A. I'm afraid you cannot. The only method I know is to enable server logs on all your DM servers and watch for suspicious activity by parsing the logs in the real time. The problem is that no one knows which suspicious activity to expect... If a user comes to you and says that the document history shows that she opened the document, which she did not, you'd better believe her than questioning her memory.

Q. Then what should I do to mitigate the vulnerability?

A. Disable Auto Logon in your DM environment as the DM-32057 bulletin suggests.

Q. Will my users like it?

A. No, they will likely hate you for this. They won't be able to understand why DM is the only application that constantly asks them for a password.

Q. Our users' Windows accounts are now locked more often after I disabled Auto Logon. Why?

A. Ask your users to be more accurate when entering their passwords. The DM Server does not tolerate carelessness.

Q. Can I disable the DM WCF service instead of disabling the Auto Logon feature?

A. You can, but this is insufficient. By disabling the WCF Host service you essentially disable the two out of three communication endpoints – HTTP and Net.TCP; the DCOM endpoint remains and can be utilized for an attack. Moreover, by disabling endpoints you reduce the DM Server's availability to your honest clients. UPD: DM WCF Service publishes 5 endpoints, not 2, in DM 5.3.1.

Q. Is it easy for OpenText to fix the issue in eDOCS DM?

A. Probably it was. A hotfix has been released for DM 5.3.x and DM 10. UPD: my opinion on the hotfix.

Q. Did OpenText know about this issue before?

A. They knew about it since 2013.

Q. Why didn't they fix it then?

A. I think they wanted to release DM 10 first. However, you should ask them, not me.

Q. I'm a hacker. The DM admin has just disabled the Auto Logon feature and I no longer can use other users’ logins... :(

A. Oh, man, I feel for you... Well, you can re-enable Auto Logon via the SQL Passthrough by executing a query like the one shown below using DM API:

  UPDATE DOCSADM.DOCSPARMS SET AUTO_LOGIN='Y'

Hey, DM admin: this is a good example of suspicious activity you must be watching for if you care.

Q. Is Auto Logon the only security breach in eDOCS DM?

A. No, it is not. More issues exist. Here are the other two.

eDOCS DM Auto Logon Security Issue - The Risk

OpenText has been collecting FAQ regarding the Auto Login security issue (DM-32057).

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:

eDOCS Web Services Samples Applicaton.zip

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:

DM WCF AutoLogin Sample

DM WCF AutoLogin Sample

I've put together some files in a folder on my Google Drive that
a) Demonstrate how to use eDOCS DM WCF API.
b) Illustrate the Auto Login vulnerability (security issue DM-32057), if your DM server is not patched.

The Creating Powerful eDOCS DM Client Step-by-step.pdf document describes how to start using DM WCF API in 7 simple steps.

Source.zip contains full source code (C# / .NET 4.5 / Visual Studio 2013) of the demo created with the instructions from the above document.

Demo.zip contains the executable compiled from the source code in Source.zip. You can launch it, if you don't want to recompile. Before launching the exe, you should open ConsoleApplication1.exe.config in Notepad and specify a) the name of your DM server (2 places); b) the user name in your DM library; c) the user's domain name.

Disclaimer: The instructions, source code and the executable are provided "as is", for demo purposes only and without warranty of any kind.

An Example of Unsecure Architecture Decision

There is a great help topic regarding the Auto Login feature in the eDOCS DM 10 documentation:

15.55 – Using OTDS with Auto Login in eDOCS DM

"The eDOCS DM Auto Login feature is based on the client side knowing that the current user has already been authenticated on the local workstation; because of this, the eDOCS DM relative authentication does not require the user to re-enter a password. This means that the user’s password is not available on the server side when the eDOCS security token is being constructed."

Simply put it says that when the Auto Login feature is enabled, it is a DM client application that is responsible for user authentication, not the server.

Now think what it means if anyone can create a custom DM client application with DM API.

If you grasped the idea and you liked it, you may also enjoy reading The Final Circle of Paradise book.

DM-32057

Finally Earlier today OpenText sent a security alert to its customers:

A security vulnerability has been discovered in OpenText Document Management, eDOCS Edition (eDOCS DM) that could allow an attacker to compromise the authentication mechanisms in eDOCS. This vulnerability is rated as HIGH.

"To compromise" is a bold declaration, considering the way "the authentication mechanism" is implemented in eDOCS DM!

Out of two solutions that the bulletin suggests, only one directly relates to the issue and is applicable.

The other "solution" consists of two parts, one of which doesn't fully shut the vulnerability and the other has nothing to do with it. It's a different story how the SQL Passthrough feature might get into the bulletin. I shall tell it to you one day. Overall, it looks like OpenText security specialists do not know their own product well enough...