DM API exposes a 'SQLService', the feature of eDOCS DM Server which allows a DM developer to execute SQL queries on DM database. At the first glance it may seem as a cool feature: a developer doesn't have to develop any specialized service for his own DM application extensions to get access to the database -- simply use DM API and enjoy the direct database access. I saw many custom built DM applications that employed this feature named SQL Passthrough. Developers love it!
All right, let's list what you can do with SQL Passthrough in eDOCS DM:
There may be more. You name it.
Thus, if we look from the security perspective, this feature is a huge security issue. Not for the fact that it is SQL injection prone, and not because it has no security access control, that could be either impersonation or a dedicated database login for such queries. The main security issue comes from the fact that you are not the only developer for your enterprise document management system. Potentially any DM user can bring his own custom built application and run SQL queries against the DM database.
In theory, by exploiting the SQL Passthrough feature, a hacker can even gain control over your Windows Server where DM Server is running: change an existing document's path stored in the database to the server's local path and upload an executable to that location via DM Extensions or DM API as an 'existing version' of the 'document'.
Just to sum it up, DM API SQL Service allows execution of arbitrary code on the DM database anonymously, and it cannot be disabled (see below). If you ever see such a 'feature' in an end-user product, EIM in this case, run away from it as if it is a wildfire.
Well, there is Allow SQL Passthrough in server options and eDOCS DM Administration Guide warns about potential security risk when enabling it. The checkbox in the server settings and the warning in the documentation may make one think that when Allow SQL Passthrough is unchecked, the feature is disabled. No, it's not.
OpenText (Hummingbird) developers had created SQL Passthrough for themselves in the first place and not for third-party DM developers as one may think. From DM Server logs you can see that eDOCS DM Extensions makes calls to SQLService, even if Allow SQL Passthrough is disabled. To accomplish this, DM Extensions always sends a constant string application name and a GUID to the server along with a user's login credentials. The application name and GUID are supposed to be a secret, but when OpenText sent out a customer alert regarding the Auto Logon security breach, they seemed so scared at that time, that were offering the GUID to anyone who would request it from OpenText Support. The application name and GUID - the so-called license key - that DM Extensions uses to unlock the full potential of DM API is very easy to discover by debugging the DM WCF Service. A hacker doesn't really need to ask OpenText for it. And it doesn't have to be a public knowledge to qualify as a security breach. It simply exists and OpenText cannot easily change these secrets because of their backward compatibility commitments.
Overall this SQL Passthrough is a huge security issue and, unfortunately, you, as a DM Administrator, cannot completely address it. However, there are still some things you can and should do to lower the risk of your enterprise documents destroyed or stolen:
Disclaimer:
The information here is provided as-is and without any responsibility of any kind. It is intended for eDOCS DM Administrators to help them understand the security issue and find ways of addressing it. The facts given are deemed true for eDOCS DM 5.3.1 P5 / DM 10 and earlier versions.
All right, let's list what you can do with SQL Passthrough in eDOCS DM:
- Run any SQL query on DM database server to the extent of DOCSADM database login permissions.
- Being a very powerful login by default, DOCSADM allows you reading and modifying any data.
- It also can read and modify database schema.
- Create and execute database code, e.g. stored procedures.
- If the database server is Oracle, DOCSADM can grant additional permissions to itself (by default it can).
- Queries are anonymous at the database level. That is, it's impossible to distinguish DM Server's core functionality queries from those originated from DM Server's SQLService queries at the database server, because all of them are executed via the DOCSADM login.
There may be more. You name it.
Thus, if we look from the security perspective, this feature is a huge security issue. Not for the fact that it is SQL injection prone, and not because it has no security access control, that could be either impersonation or a dedicated database login for such queries. The main security issue comes from the fact that you are not the only developer for your enterprise document management system. Potentially any DM user can bring his own custom built application and run SQL queries against the DM database.
In theory, by exploiting the SQL Passthrough feature, a hacker can even gain control over your Windows Server where DM Server is running: change an existing document's path stored in the database to the server's local path and upload an executable to that location via DM Extensions or DM API as an 'existing version' of the 'document'.
Just to sum it up, DM API SQL Service allows execution of arbitrary code on the DM database anonymously, and it cannot be disabled (see below). If you ever see such a 'feature' in an end-user product, EIM in this case, run away from it as if it is a wildfire.
Well, there is Allow SQL Passthrough in server options and eDOCS DM Administration Guide warns about potential security risk when enabling it. The checkbox in the server settings and the warning in the documentation may make one think that when Allow SQL Passthrough is unchecked, the feature is disabled. No, it's not.
OpenText (Hummingbird) developers had created SQL Passthrough for themselves in the first place and not for third-party DM developers as one may think. From DM Server logs you can see that eDOCS DM Extensions makes calls to SQLService, even if Allow SQL Passthrough is disabled. To accomplish this, DM Extensions always sends a constant string application name and a GUID to the server along with a user's login credentials. The application name and GUID are supposed to be a secret, but when OpenText sent out a customer alert regarding the Auto Logon security breach, they seemed so scared at that time, that were offering the GUID to anyone who would request it from OpenText Support. The application name and GUID - the so-called license key - that DM Extensions uses to unlock the full potential of DM API is very easy to discover by debugging the DM WCF Service. A hacker doesn't really need to ask OpenText for it. And it doesn't have to be a public knowledge to qualify as a security breach. It simply exists and OpenText cannot easily change these secrets because of their backward compatibility commitments.
Overall this SQL Passthrough is a huge security issue and, unfortunately, you, as a DM Administrator, cannot completely address it. However, there are still some things you can and should do to lower the risk of your enterprise documents destroyed or stolen:
- Disable Allow SQL Passthrough in server settings. It's insufficient as explained above, but at least you'll cut off lazy hackers who don't care about the secret GUID.
- Closely monitor the Application Event Log on your DM Server: If a SQL query ends with an error, the error is added to the log. You should analyze errors for suspicious queries. The challenges are A) DM Extensions generates a few queries which always yield an error - you'll need to filter out those and B) An intruder may be smart enough to ensure his SQL queries are correct and won't fail in your environment.
- Enable DM Server logs and monitor them in real-time for any calls to SQLService. You will need to find a way to distinguish calls made by DM Extensions or DM Webtop from those by an intruder.
- Work with DBA and tighten DOCSADM login permissions as much as possible: no schema updates, no permission grants, etc.
Disclaimer:
The information here is provided as-is and without any responsibility of any kind. It is intended for eDOCS DM Administrators to help them understand the security issue and find ways of addressing it. The facts given are deemed true for eDOCS DM 5.3.1 P5 / DM 10 and earlier versions.
No comments:
Post a Comment