Actually, I started to think about possibility to gain superuser privileges by deleting object in Documentum after I discovered a lot of vulnerabilities in D2 docbase methods – D2 has D2DeleteObjectMethod docbase method, which can be used to delete any sysobject in repository, and two months ago I did find an exploitation I was looking for. But to understand why it was a challenge I would like to perform some analysis of common security mistakes in Documentum software before disclosing the exploitation I found.
File hijacking vulnerabilities
If attacker is able to hijack certain files from Content Server filesystem, he is able to gain superuser privileges. Why? There are a couple of reasons:
- Hijacking of $DOCUMENTUM/dba/secure/aek.key file gives attacker a possibility to generate logon tickets. Here EMC invented some options to mitigate such attacks (you can use dm_crypto_change_passphrase utility to setup passphrase for aek.key and dm_crypto_boot to load password-protected aek.key into shared memory before starting content server, in recent Documentum releases EMC added the ability to manage aek.key using remote key management feature), but these options are futile – during installation content server registers certificate stored in $DOCUMENTUM_SHARED/config/dfc.keystore as privileged certificate with ability to perform trusted authentication, so hijacking of $DOCUMENTUM_SHARED/config/dfc.keystore file grants attacker superuser privileges
- Some log files contain security-sensitive information. BPM example: Why do EMC coders like static variables?, D2 examples: CVE-2014-2515 (D2GetAdminTicketMethod). Was it really fixed?, Is it worth to treat flu if patient has cancer?
All such mistakes are related to either incorrect logging implementation or wrong understanding of cryptography options. The only obscure thing here is why CVE-2014-2510 and CVE-2014-0622 vulnerabilities have different security impacts 🙂
Object creation vulnerabilities
It’s another family of vulnerabilities related to the fact that content server fails to check creator (or modifier) of certain objects in docbase when performing routine activities, Some examples:
I bet there is no chance that EMC will be able to fix such vulnerabilities due to some obvious reasons:
- EMC does not know what objects types in docbase are “dangerous” by design
- EMC tries to fix anything but not vulnerabilities – D2GetAdminTicketMethod is already a byword for EMC competence, another examples: What makes api/dmbasic suck, protected objects
Vulnerable docbase methods
In general, if you code docbase methods you are an idiot – there are another options to do the same without docbase methods. Some examples:
During last year I was able to analyze only dmbasic and dawk docbase methods, but how much of docbase methods do remain vulnerable?
This is related to the previous post.