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:
DropboxUpdate.log-<YYYY>-<MM>-<DD>-<HH>-<MM>-<SEC>-<MILLISEC>-<PID>
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\1.3.241.1\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
BOUNDARY CONDITIONS
- 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)
DISCLOSURE TIMELINE
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.
POSSIBLE COUNTERMEASURES
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
SIDE NOTE
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.