In January of this year we found an EoP (Escalation of Privileges) or LPE (Local Privilege Escalation) in the Dropbox Windows application. The bug was already patched in the last Dropbox update. This vulnerability allowed an attacker with low privilege access on a machine to escalate to SYSTEM (highest administrator privileges).
As soon as we found this vulnerability, we reported it to Dropbox through their Bug Bounty Program. They informed us that they were already aware of the vulnerability and had been working on a fix since another researcher (name not disclosed) had recently reported it as well. However, no patch was yet available to the customers.
Local Privilege Escalation
In general a local privilege escalation attack allows privileges to be escalated on a compromised machine from a low privilege user to SYSTEM. More specifically, a file privilege escalation attack -such as the one found in Dropbox- relies on the abuse of file operations performed by privileged processes to achieve this goal.
An automatic Dropbox update from low privileges to SYSTEM
By analysing the Dropbox client for Windows, we realized that the update component was running with system privileges. Oh! What can go wrong?
With the aid of Procmon tool (as part of SysInternals toolkit) we were able to monitor the updater process behaviour and discover that this high privilege process was writing log files in the folder
This behaviour caught our attention and we investigated further.
The permissions of that Log directory were actually set by default as writeable by non-privileged users. The privileged process then set permissions on the log files that allowed any user to modify them.
Exploiting the vulnerability
In order to leverage this vulnerability, the writing of a file by the privilege process needs to be redirected to a more interesting folder, for example
C:\Windows\System32. If this can be achieved, then the DropboxUpdate process would write a file to the new target directory and set the permissions to allow a low privilege user to have write access on the files.
To achieve the redirection, the CreateMountPoint tool can be used, one of the amazing "Symbolic link testing tools" created by James Forshaw. By using CreateMountPoint an NTFS junction can be created. As Clément Lavoillotte states: "Junctions are an NTFS feature that allows directories to be set as mount points for a filesystem, like a mount point in Unix, but can also be set up to resolve to another directory (on the same or another filesystem)".
Simply, when using junctions, a sort of directory symbolic link to another target directory is created and -the most important thing- junctions can be created by low privileged users.
By using CreateMountPoint tool it was possible to turn
C:\ProgramData\Dropbox\Update\Log into a junction to
C:\Windows\System32 and redirect the privilege writing into an arbitrary and definitely more interesting directory.
To create the junction the following line was run on the Windows console:
Once the symlink is triggered by the DropboxUpdate process, the log files can be seen being written to the
Due to the weak permissions setting, the log file can then be replaced with malicious content. From here, there are then several ways in which an attacker can achieve privilege escalation.
Since the report to Dropbox has not been fully disclosed, we will not give details of the exploitation. However, it is possible to develop a working exploit using this vulnerability. The following video shows how a non-privileged user escalates to SYSTEM by abusing this bug: WATCH VIDEO
To protect yourself from this vulnerability, remember to update Dropbox to the latest version.
The EoP vulnerability we found in Dropbox client for Windows allows an attacker with low privilege access on a compromised machine to escalate their privileges to SYSTEM.
We want to acknowledge the role of SandboxEscaper's blog as an inspiration for this finding and highlight the valuable toolkit developed by James Forshaw for exploiting these kinds of vulnerabilities.
January 12, 2020 - Initial discovery.
January 13, 2020 - Report sent to Dropbox via Hackerone.
January 13, 2020 - Report is triaged and considered duplicated.
July 31, 2020 - A fix resolved the vulnerability.
September 3, 2020 - Our report is disclosed.
Security Researcher at Dreamlab Technologies