Share this:

Like this:

We are facing the following issue in our environment. The Content server version is 7.2 on Linux. This environment was upgraded from 6.7 about 5 months back…. bla-bla-bla something about stability and performance…

I have remembered that during last year I had participated in resolution of similar problems two or three times.
Here is a root cause: Randomness in virtual machines (don’t pay much attention to “virtual”)
Why did this happen after migration from 6.7?
The answer is simple: in D7 SSL connections are enabled by default, so, D7 consumes more entropy.
What to do?
Check Marginalia page.

Because this is so negligent Lawrence and Frohoff didn’t bother to report this directly to the Apache Commons project.

ASF failed to announce vulnerability properly – it is still not clear what versions of ACC library are affected: CERT/CC states that “both versions 3.2.1 and 4.0 of the Apache Commons Collections library have been identified as being vulnerable to this deserialization issue”, but Frohoff’s PoC is based on 3.1 (version 3.0, which Webtop is based on, is not affected). It seems that the only company which was able to properly evaluate security risks is a Cisco Systems – please check their security advisory, moreover I always respect Cisco for their security advisories: if you ask google about “This vulnerability was discovered by Cisco during internal testing” you get a bunch of references to Cisco’s advisories – could you provide any other company which is doing the same? I don’t think so. For example, EMC states that they also have internal security testing (full presentation is available here):

Note, that my proof of concept does not execute operating system commands like was demonstrated in Frohoff’s PoC – instead of that it creates Documentum user with superuser privileges. I have noticed that many researches like to describe how their proof of concepts work, so I will try to do the same, however if you get bored you can stop reading this post and get my proof of concept here.

Motivation

At first, initial proof of concept is bit boring: on the one hand we (Documentum users) already have a component which is able to execute arbitrary shell commands (I’m talking about Content Server), on the other hand such proof of concept assumes that attacker executes shell commands blindly, i.e. to understand wether service is vulnerable or not we need to somehow get information about whether command was executed or not, for example, we may use ping to send packets to monitored host, but what if victim service is located behind a firewall? So, creating a new user is more practicable.

At second, this blog is about Documentum, writing something like “take a look, D2 contains vulnerable java library” is boring.

First challenge

Well. The first challenge was to get DFC session without knowing any Documentum credentials, actually if DevOp is so stupid to leave default passwords for dmc_wdk_preferences_owner/dmc_wdk_presets_owner users unchanged we may construct DFC session using following code:

new DfClient().newSession("docbase", new DfLoginInfo("username", "password"));

Transformer getSession = new ChainedTransformer(
new Transformer[] { new ConstantTransformer(RuntimeContext.class),
new InvokerTransformer("getMethod", new Class[] { String.class, Class[].class },
new Object[] { "getInstance", new Class[0] }),
new InvokerTransformer("invoke", new Class[] { Object.class, Object[].class },
new Object[] { null, new Object[0] }),
new InvokerTransformer("getSessionRegistry", new Class[0], new Object[0]),
new InvokerTransformer("getAllSessions", new Class[0], new Object[0]),
new InvokerTransformer("get", new Class[] { int.class }, new Object[] { 0 }), });

Now there are two other challenges:

we need to somehow execute docbase queries

we need to somehow evaluate privileges

The third one is less important: at first, I know about 10 ways to evaluate privileges in Documentum (haha, keep me away from accessing your Documentum, otherwise it hurts me because I don’t like making a choice), at second, if you are lucky enough SessionRegistry may contain privileged sessions – just play with array’s index, at third, in order to evaluate privileges it is still required to execute queries.

Second challenge

It is not possible to invoke com.documentum.fc.client.IDfQuery#execute using ACC API – it accepts IDfSession as argument

com.documentum.fc.client.IDfSession#apply looks like what we need, but it accepts IDfList as argument, and IDfList has no serializable implementations

com.documentum.fc.client.impl.session.ISession#query(java.lang.String, boolean, boolean) – good candidate if we need to execute DQL queries only

The funny thing here is Content Server allows to create objects having out-of-sequence r_object_id, moreover, it seems that Content Server ignores docbase part of r_object_id – we do not need to execute NEXT_ID_LIST RPC command to acquire brand new r_object_id.

Webtop

Previously I noticed that Webtop contains ACC library of version 3.0 and it this version is not affected, unfortunately, this is only a half of the truth. If we consider the problem more globally, i.e. “if you accept serialized objects from untrusted sources you are lazy moron“, everything become more interesting. Well, all wdk applications have an extremely ancient servlet:

Amazing, wdk5-appletresultsink servlet allows to inject arbitrary value into HttpSession. Now, do you have any idea how PrivilegeQualifier and RoleQualifier work? Actually, they both do something like:

Doesn’t it look strange? A severe vulnerability exists for a couple of years, but instead of remediating it vendor wastes time for less severe things like DmSampleServlet. For a long time I was unable to understand what is the reason of such EMC’s behaviour, but yesterday everything got clear for me. What happened yesterday? Yesterday I got an idea that I discovered a super mega severe vulnerability in D2 – getting superuser credentials without knowing any existing credentials (suck to be you if you expose D2 into internet, previously I was able to say the same only about D2-Config, the only problem is my friends/colleagues are using D2, moreover some of them have D2 exposed into internet and releasing a public exploit will probably hurt them, so I have tried to contact EMC representative and if I won’t receive any response I will make it publicly available on Tuesday), and in order to confirm my expectations I was need to install D2 (yeah, I hate this procedure due to introduced useless RSA Lockbox). And what did the installation do with my DEV ENV? It marked all vulnerable groups as protected:

So, the only question is why this dar is not included in Content Server installation. I do not believe that it is caused by any compatibility issues (just imagine you have something dependent on dcs_privileged_users group and you install D2 – your functionality gets broken), it is just fault of release management:

one guys qualified Collaboration Services as a source of vulnerability (from my perspective this is wrong because Collaboration Services is a part of default Content Server installation) and assigned issue to corresponding team

Collaboration Services team fixed an issue (here should be a joke about one year required to fix a dmbasic script)

nobody included new version of Collaboration Services dar into CS patch

If you think I’m wrong, below are another examples of such faults:

ESA-2014-064 states that something was fixed in “6.7 SP2 P15 and later”, actually you may find a thorough explanation of what was “fixed” in What makes api/dmbasic suck blogpost, but EMC included a “patched” version of dmbasic binary only in 6.7 SP2 P17

ESA-2015-131 (CVE-2015-4535) is also interesting form this perspective (note I do not say that it is remediated), you can find a thorough explanation in Why do EMC coders like static variables? blogpost, the problem is both Content Server and Process Engine were affected (both contain mthdservlet.jar) but EMC released a “patch” for Content Server only

this servlet is used by D2 for the PDF widget viewer
I was supposing that the ticket is a one time ticket, but it is not!
I don’t know why, maybe EMC is using the same ticket during all the session but I would have used a one time DM_TICKET to avoid to use it multiple time

Strictly speaking Documentum tickets has nothing in common with one-time passwords. Let me explain. The main idea of one-time passwords is not to verify your credentials but verify you as a person, for example, I have a bank account in Russian bank (actually, I also have a bank account in Australian bank, but IT in Australia is so infant that it is not possible to provide a real-world example), in order to take advantage of their internet banking I do following: I open browser, enter internet banking URL and submit my credentials, after that internet banking asks me to submit a one-time password and, in order to do so, it provides me two options to get one-time password:

receive one-time password by sms

go to ATM and get a hard-copy with a list of ten one-time passwords (if I choose this option i)

I submit one-time password and now I’m able to work with internet banking, so, the bank assumes that the person who knows credentials and able to receive one-time password by sms (or able to go to ATM and get a hard-copy with a list of one-time passwords) is me, actually, it’s a kind of tradeoff between security and convenience – bank may create more comprehensive authorization scheme, but it’s hardly possible that after that anyone will use their internet banking.

Documentum tickets should be considered just as temporary passwords which are valid during a specific period of time (see also login_ticket_timeout in dm_server_config):

Share this:

Like this:

In order to finish writing my super blogpost I decided to walk through my blog and check which vulnerabilities were fixed and which weren’t and found a real gem – the current status of two-year old vulnerability (FullHD video is available here):