Viden Labs has found an Insecure Direct Object Reference (IDOR) vulnerability in Synametric's SynaMan. This vulnerability is present in versions 4.9 and earlier.
This vulnerability has since been patched in version 5.0.
“Insecure direct object references (IDOR) are a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly.” - https://portswigger.net/web-security/access-control/idor.
The vulnerability can be exploited resulting in an access to (potentially sensitive) files in a SynaMan user’s home folder (including subfolders), that they do not have authorisation to access.
A SynaMan user named “internaluser”. This user was AD joined but doesn’t make a difference if they are not AD joined.
In internaluser’s home folder, there are two files:
- file-download.docx
- secret.txt
Figure 1: User Directory with Files
A download link has been created for file-download.docx and shared to a simulated external party.
Figure 2: SynaMan File Download Page
The web application test was performed from the 10.0.2.0/24 network, using Burp Suite on Kali.
The Windows Server 2019 instance is running an out of the box configuration, with the latest security updates applied, and port 443 inbound open.
SynaMan was configured in accordance with best practices, following guidance from the Synametrics Technologies website.
Outlined in Figure 3 below is an overview of the network setup for the lab test.
Figure 3: SynaMan Testing Topology
| Computer | Role | OS | Browser |
|---|---|---|---|
| 10.0.2.30 | Web Application Testing Server | Kali Linux (VM) | Burp Suite embedded browser |
| 10.0.3.50 | SynaMan Server | Windows Server 2019 (VM) | N/A |
Table 1 - Additional setup information
A vulnerability was found when an external party accesses a download link, either shared with them, or found by googling "pubopp?". The file download hyperlink contains a base64 encoded file name, including the path. This path can be modified to download other files from the user’s folder that have not been shared. While this requires an attacker to correctly guess a filename, tools such as Burp Suite make this brute-forcing trivial and automated. A graphical representation of this is outlined in Figure 4 below.
Figure 4: Graphical representation of GET request vulnerability
Shown below in Figure 5 is the resulting GET request when the download link is clicked.
Figure 5: Burp Suite GET request
Inspection of the base64 encoded filename (passed as the parameter named “fn”) shows the file location.
Figure 6: Burp Suite Base64 filename
Using Burp Suite, this can be modified to another file name, and substitute this in the GET request. For this example, we will use “secret.txt”, as we know this file exists in the folder.
Figure 7: Burp Suite Modified Base64 filename
Figure 8: Burp Suite Modified GET Request
Submitting the modified GET request allows us to download the file which was not shared, as shown in Figure 9 below.
Figure 9: SynaMan Unauthorised Download
The currently available security settings in SynaMan do not provide a control to mitigate this attack, however all downloaded files are logged.