From dropbox(updater) to NT AUTHORITY\SYSTEM

Original text by @decoder_it

Hardlinks again! Yes, there are plenty of opportunities to raise your privileges due to incorrect permissions settings when combined with  hardlinks in many softwares (MS included) 

In this post I’m going to show how to use the DropBoxUpdater  service in order to get SYSTEM privileges starting from a simple Windows user. I found and exploited this “vulnerability”  along with my usual “business partner” @padovah4ck.

Please note:  I’m not going to release any source code,  my goal is to share knowledge, not tools.

The DropBoxUpdater is part of the Dropbox Client Software suite, and according to the Software manufacturer, it is used for keeping the client up-to-date:


The updater is installed as a service and 2 scheduled tasks, and to be honest,  I really don’t know why… but let’s go on. Keep in mind that in standard installations they run as SYSTEM  and one of the dropboxupdate task is run every hour by the task scheduler.


Each time dropboxupdate is  triggered, it writes log files in this directory:

  • c:\ProgramData\Dropbox\Update\Log

Permissions are the following:


As you can see, users can add file in this directory.

Logfiles have a special format:


And the file naming convention is:

Users can overwrite and delete these files:


Even more interesting is a SetSecurity call made by SYSTEM on these files:


Seems familiar, isn’t it? If you read my previous post, you already know that this is exploitable via “hardlinks

But we have a problem here, we have to “guess” the logfile name,  that is the exact time (including milliseconds) and the PID of the updater process

Seems challenging!

After some testing we found this solution:

  • Be sure that no process “DropBoxUpdate.exe” is running (as standard user:
    c:\>tasklist | find /I “dropboxupdate”)
  • Intercept the DropBoxUdate.exe process upon startup by setting an opportunistic
    exclusive lock on the following DLL:
    • C:\Program Files(x86)\Dropbox\Update\\goopdate.dll
  • The process will hang and the user defined callback function will be triggered
  • Find the PID of the dropboxupdate process
  • Perform an “hardlink spraying” by creating 999 links with the naming convention
    mentioned before, starting from the current time (hhmmss) + 10 seconds (timeA).
  • All these links are pointing to destination file we want to own. It is possible to set at
    maximum of 1024 hardlinks to a file.
  • Wait until current time (hhmmss) is equal to timeA
  • Release the oplock
  • If everything works fine, we should match the correct file name in the range of 999 milliseconds.

Will it work? We have just to try it out, with the classic license.rtf  located in System32 folder. For testing purpose, you can directly invoke the scheduled task with admin rights instead of waiting the next hourly run.


Wow! It worked. Now you could overwrite any file where SYSTEM has full control.. and gain the highest privileges!

But let’s go a step further… would it be possible to rely only on Dropbox Client software to gain a SYSTEM shell?

Yes, of course! Remember the second scheduled task?


The task runs with SYSTEM privileges and is also triggered at the logon of any user. During our test we noticed that during the logon,  the DropboxCrashHandler.exe was also invoked (only if no other dropboxupdate process is running in other sessions):


So what was our idea? Set DropboxCrashHandler.exe  as target file, launch the exploit, overwrite the file with our “malicious” executable, logoff, logon again and our executable should be triggered!

Here you can watch the working POC. I presume that there are other possible escalation paths, it’s left up to you 


  • Dropbox has to be installed in “standard” way, with admin rights
  • We tested it with the latest Windows Dropbox Client release (87.4.138 at the time of writing)


We informed Dropbox about this issue on September, 18th. They answered that they were aware about the issue (but not with these techniques and complete escalation paths) and would fix it before the end of October. Since 90 days have passed before initial submission, I published the post.


Waiting for the new (hopefully  patched) release, meantime you could remove the “Create files” / write data” and the “Create folders /append data” permissions for “Users” on the  Log folder and you should be fine 


Generic hardlink “abuse” will no more work in future releases of Windows. In the latest “Insider” previews, MS has added some supplementary checks, so if you don’t have write access to the destination file you get an access denied error when you try to create a hardlink.

РубрикиБез рубрики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *