Vendor: EMC Product: Documentum WDK-based applications, all versions Security impact: high All EMC Documentum WDK-based applications (Taskspace, Webtop, Documentum Administrator, EPFM) contain extremely dangerous web component – API Tester. The “API Tester” component wan’t designed with security in mind and allows authenticated users to execute arbitrary code on application server or elevate privileges on underlying Content Server. Below are the demonstrations of “API Tester” capabilities: 1. Path traversal - authenticated user may upload arbitrary file from application server to underlying Content Server and then download that file using standard web interface. The sequence of API commands is following: create,c,dm_document setfile,c,l,<path to file on application server>,crtext save,c,l Demonstation: https://youtu.be/vRcdPchZGkU 2. Arbitrary code execution - authenticated user may craft malicious JSP, upload it into underlying Content Server using standard web interface and then download that JSP onto application server filesystem. The sequence of API commands is following: getfile,c,<object id>,<path to file on application server> Demonstration: https://youtu.be/oW0x2HXmqww 3. Privilege elevation on underlying Content Server - if authenticated user issues API command with “__REQUESTED_PROTECTED_ROLES,S,dcs_privileged_users” argument, that command is executed on underlying Content Server with superuser privileges. Demonstration: https://youtu.be/Yxkc5orHtwY The first attempt to mitigate security issues described above was performed by vendor in 2014: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0629 - the description is completely misleading, but the gist of remediation was to limit access to API Tester component to superusers only. The problem is WDK applications get information about privileges of authenticated user from HTTP Session, and all WDK applications contain servlet (/wdk5-appletresultsink) which allows to poison HTTP Session. PoC: https://gist.github.com/andreybpanfilov/785173c085d818c4fbf913075a5ad421 I discovered this vulnerability on February 2016 and on June 2016 vendor announced the remediation for it - https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0914 (Un)fortunately the fix announced by vendor in CVE-2016-0914 does remediate nothing. Demonstration: https://youtu.be/OarCJ4vB36s __ Regards, Andrey B. Panfilov