LogicalDOC is a DMS (Document Management System) available either in a community (and free) edition, or in a professional (and expensive) version. This type of product is normally used to share and access doc from « everywhere » as they say on their website: « Your documents – Always accessible, from anywhere, at any time » which means web interfaces widely open on the internet.

During a pentest, we found that a client used one of this product (in community version 7.5.3, the lastest version available when we did the pentest), and, well, security are apparently not their main concerns. Note that for all these 0days we found, you need to be authenticated (even with the lowest privilege account you can find). Again we’ve choose to “responsible disclose” them.

XML External Entity (XXE) Vulnerability in XML parsing

Of course, in a DMS, file upload seems to be the main functionality and that often means a gold mine for a pentester. We first though of classic file upload vulnerabilities but none of them succeed. After deeper searches in different modules, we could find that once uploaded, all files were indexed in a database, and content parsed to be available in research fields. Most of all, a specific class is available to parse XML files.

Wait? Parsing XML? Smells good! Let’s try to see if XML parser is vulnerable to XXE and try to upload classic XXE exploits:

<xml version="1.0" encoding="utf-8" />
     <!DOCTYPE kikou [ <!ENTITY lol SYSTEM "file:///etc/passwd" >]>
	 <kikou>&lol;</kikou>

We could see errors in console that could indicate that the XXE works, but the content of the file (/etc/passwd in the example) was not dumped directly in the error logs. Let’s think about that for few seconds, parsers are used to index content of files (for search fields), so maybe the file pointed in the xml document is now available in search content. Let’s search for the “root” keyword (which is included in /etc/passwd file), oh, wait:

So, when you upload an XML file referencing an external entity such as /etc/passwd (in our case, LogicalDOC is running as root), the file will then be parsed and included in the indexing results. By guessing (or brute forcing) keywords that are presents in the file pointed by the external entity element -such as root in /etc/passwd-, search results will then reveal the content of this file. That is a pretty fun way to exploit XXE 😊

This vulnerability is critical, since each authenticated user can get system files (limited with rights relatives to the users launching tomcat). If the platform is using integrated SQL (which was not our case), attacker will be able to get logs of each SQL statement and get for example, all hashes (sha1) of users’ password of the platform.

CVE:  CVE-2017-1000021 ([https://github.com/distributedweaknessfiling/DWF-CVE-Database/blob/master/2017/1000xxx/CVE-2017-1000021.json] (https://github.com/distributedweaknessfiling/DWF-CVE-Database/blob/master/2017/1000xxx/CVE-2017-1000021.json))

Privilege escalation and bad rights partitioning

After XXE, we also noted that rights partitioning was not perform correctly at all. It is possible for an authenticated user even with the lowest level of privileges (guest account) to trigger all administrative functions, even if this user is not belonging to an administrative group.

For example, a user created with “guest” or “publisher” rights can trigger critical administrative functions such as:

• Listing all connected users and their ldoc-sid cookie (which is the session cookie);
• Change administrator or users’ password;
• Get and change application settings
• Change users’ settings, username;
• …

We just need to know the request format and put a valid ldoc-sid cookie! Requests format could be easily guessed by installing a local version of LogicalDoc. Example, listing all session token (admin included) using a very low privilege account:

Note that exploitation of this vulnerability is even possible as unauthenticated users in lower version of LogicalDoc :). So, keep in mind that in this version of the product, all users have administrator privileges.

CVE:  **CVE-2017-1000022 ** (https://github.com/distributedweaknessfiling/DWF-CVE-Database/blob/master/2017/1000xxx/CVE-2017-1000022.json)

Stored Cross Site Scripting (XSS)

And, the icing on the cake, a stored XSS has also been found during the test. In fact, it is possible for authenticated users to upload HTML file that contains malicious JavaScript. This JavaScript will then be executed on browser each time a user will get preview of the document. Just upload a file named “Sexy_Games_of_thrones_pictures.html” and it’s done 😊.

A user authenticated with low privilege could, for example, use social engineering to force an administrator to get a preview of the malicious HTML file and then steal his connection cookies (which, of course, are not protected with HTTP Only):

Et voilà 😊.

CVE: CVE-2017-1000023 (https://github.com/distributedweaknessfiling/DWF-CVE-Database/blob/master/2017/1000xxx/CVE-2017-1000023.json)

Timeline:

• Mid 2017-01: Vulnerabilities found in version 7.5.3 (and prior)
• 2017-30-01: Mail to LogicalDoc support on
• 2017-30-01: Response from support (fast!)
• 2017-02-06: Vulnerabilities patched in version 7.6.2 (note that changelog do not mention any of these vulnerabilities… ☹)
• 2017-04-06: CVE Requests to DWF
• 2017-07-07: CVE accepted and published:
  • CVE-2017-1000021 (https://github.com/distributedweaknessfiling/DWF-CVE-Database/blob/master/2017/1000xxx/CVE-2017-1000021.json)
  • CVE-2017-1000022 (https://github.com/distributedweaknessfiling/DWF-CVE-Database/blob/master/2017/1000xxx/CVE-2017-1000022.json),
  • CVE-2017-1000023 (https://github.com/distributedweaknessfiling/DWF-CVE-Database/blob/master/2017/1000xxx/CVE-2017-1000023.json)