CVE-2020-27358 and CVE-2020-27359

CVE-2020-27358 and CVE-2020-27359

These are my first two registered CVEs affecting the enterprise software RedCap. My first two public CVEs registered. I will quickly walk through how I found them and how they can be exploited. I found this bug at the start of a larger engagement I was on for a client. This client had many applications in scope including RedCap. The version of RedCap I had access to was 8.11.6 which both of these CVEs affect. These two vulnerabilities come from the messaging system within the application.

CVE-2020-2758 ( IDOR )

Poking around the messaging system I noticed there was a feature to export your message threads. Naturally, any export feature is juicy as it might lead to cross-account access to possible LFI (Local File Inclusion). With Burp enabled I intercepted the export request and analyzed the request. The application requests

Messenger/messenger_download_csv.php?title=filename&thread_id=THREAD_ID.

I started fuzzing the URL parameters first looking for LFI using the filename. No luck here. Next, I take a look at thread_id. I notice my thread ID is < 10. So I know they are not using UUIDs for threads. I use Burp Intruder to do a sequential interaction of possible threads and observe the response. Sure enough, I was able to guess valid thread IDs and explore the conversions. This allowed me to view message threads from other users. In the instance I was in there was limited data to be found in conversations. Regardless, it shows there were no access controls around the export functionality. This was rated as a 4.3 Medium.

CVE-2020-2759 ( Stored XSS )

As implied from the title this was a stored XSS vulnerability in the chat feature. This was fairly trivial to exploit it just came down to enumeration. The chat supports a rich message format and allows the user to embed images. Again here I am thinking of possible path traversal, XSS, or maybe RCE. I uploaded an image and intercepted the request. The request looked fairly normal with the image data and filename. I was not able to traverse directories but I found that the file name parameter was not escaped. In this implementation, the file name is used in the chat message to create a link under the image. I was able to escape the <a> tag and execute Javascript. This vulnerability allows for an attacker to send an XSS payload to any user on the platform and have the payload trigger without interaction. Unfortunately, I was not able to put together a PoC to add a new admin user as time did not allow but I am confident It would be possible. To trigger this XSS you just need to upload an image with the following filename.

\"><svg/onload=alert(document.domain)>