Dropbox Zero-Day Vulnerability Gets Temporary Fix

A zero-day vulnerability exists in Dropbox for Windows that allows attackers to gain permissions reserved to SYSTEM, the most privileged account on the operating system.

The unpatched security flaw affects standard Dropbox installations. It relates to the updater that runs as a service and is responsible for keeping the application up to date.

Dropbox has yet to release a new version that patches the flaw but a temporary solution is freely available in the form of a micropatch.

Short-term fix

Security researcher Decoder and Chris Danieli discovered the vulnerability and created proof-of-concept exploit code to validate the findings.

They say that they informed Dropbox of the issue on September 18 and allowed a 90-day period before making a public disclosure. The company responded saying that the problem was known and a fix would become available before the end of October.

Until Dropbox rolls out a better version, an interim solution can be applied via 0Patch, a platform that delivers micropatches for known issues before a permanent, official fix becomes available.

Describing the issue on Twitter, Mitja Kolsek, CEO of Acros Security company behind 0patch, says that a local low-privileged attacker can use it to replace executable run by a process with SYSTEM-level rights.

These tiny pieces of code correct only the vulnerable part and are applied in memory while the system running, so they work without rebooting. 

Kolsek was able to create the Dropbox patch faster with the help of CERT/CC vulnerability analyst Will Dormann, who provided technical clarifications and proof-of-concept code that showed how the bug could be exploited.

Technical details, no PoC

In a blog post this week, Decoder offers details for leveraging the vulnerability to elevate privileges on an already compromised host. The exploit code is not provided, since the purpose of the disclosure is to “share knowledge, not tools.”

The researcher says that they tested the privilege escalation vulnerability on version 87.4.138 of the software, which is the latest release at the moment of writing.

The method and techniques for exploitation take advantage of the Dropbox updater, which is installed as a service with two scheduled tasks that run with SYSTEM permissions.

The two researchers found that the ‘dropboxupdate’ service writes the log files to ‘C:\ProgramData\Dropbox\Update\Log’ where standard users are also allowed to add, overwrite, and delete files.

Furthermore, the SYSTEM‌ account makes a SetSecurity call on the files in this location, which opens the door to exploitation via hard links.

One of the challenges overcome by the researchers was to use a log file that could be used with the updater process.

The solution was to cause the update process to hang and performing hard link spraying by creating 999 links that respect a specific naming convention, all pointing to the target file. Of help in their endeavor were testing tools developed by James Forshaw of Google Poject Zero.

A test on the Windows license agreement file - license.rtf, in System32 proved that the solution works and allows overwriting files controlled by the SYSTEM‌ account.

After more poking around, the researchers also found a way to gain a shell with SYSTEM‌ privileges. They were able to achieve this by logging off and back on after overwriting DropboxCrashHandler.Exe with a malicious executable.

A video proving the success of this method is available below:

Local access is a prerequisite for exploiting this bug; nevertheless, compromising a computer is not difficult and a privilege escalation bug allows taking the attack past the initial stage.

Fixing the vulnerability requires stricter permissions a normal user has for the Log folder in Program Data. Dormann says that the number of privilege escalation vulnerabilities on Windows increased lately.

An explanation for this came from Kolsek, who points out that the likely cause for this are the default permissions on the Program Data directory.

It's all about *explicitly* setting permissions. Program Files is secure by default through inheritance. ProgramData is not.

— Will Dormann (@wdormann) December 19, 2019